Author Archive

On Keeping A Journal and Journaling

Wednesday, January 1st, 2014

I've kept a journal since I was 11. That was in the mid 80's. I hadn't heard the word “journaling” until about a year or so ago, and lately it appears that giving advice and howto information about journaling is a bit of a cottage industry. I had no idea so many people were in demand of this information, but in a world where you can subscribe to multiple very successful monthly magazines about running, I shouldn't be so shocked.

I should also not be shocked to learn that people have heard some of the benefits people tout about journaling and want those benefits for themselves. But maybe some are skeptical and wonder “is journaling really all it's cracked up to be?” For those folks, let me say this: I've read a few of the blogs myself, and while I'd say the authors are mostly 1 or 2-year “veterans” who don't really get it yet, the benefits they say you can get from journaling are not only possible, they're just the tip of the iceberg.

The key to getting started, though, is probably to completely ignore everything you've read, go get a Pilot v5 pen, and some kind of blank book, and just start doing as you please. Beyond encouraging words and listing the benefits, what the books and blogs are telling you to do is, quite honestly, bullshit. They're either trying to put arbitrary rules around it, or telling you about the process they themselves find useful… for them. Some things I read seemed utterly destructive to some of the benefits. Tread carefully around advice, from me or anyone else.

Journaling is ultimately a personal thing. All of it. Not just the process, but the goals or what you want to get out of it. Furthermore, most of the goals I've achieved over multiple decades of journaling (and they are both countless and priceless) happened not because I willed it to be so and structured my process or writing to meet them, but by happy accident. I was benefitting from journaling long before I even realized what journaling had brought to my life.

So the idea that you can learn to journal strikes me as pretty odd. But I do encourage you to do it. Just find some quiet time, a blank page, and a pen, and spill it. Even if it looks boring. In the meantime, if you have questions best answered by someone who has been doing this for more than a year or two, let me know and I'll be happy to help if I can.

What Geeks Could Learn From Working In Restaurants

Tuesday, September 4th, 2012

I spent a long time in my teens and early 20’s working in restaurants. To be honest, I loved just about every minute of it. It’s exciting, you’re never idle, and it’s usually not boring: you either get immediate gratification from happy customers leaving a nice tip, or you’re on the defensive, thinking on your feet to save an experience after something has gone wrong. 

In contrast, technology, I’ve found, requires more of an investment to get to the gratification of a job well done. I’ve also always felt like certain aspects of technology, like coding, are somewhat therapeutic for me, whereas restaurant work mostly wasn’t. And, occasionally, technology work can be monotonous and boring.

In spite of the quite dramatic differences between the two working environments, I sometimes find myself thinking about restaurants when I’m working on software or systems. It turns out that some of the tenets of restauranteurism, or just waitering or bartending, can be applied to work in the tech sector. Allow me a bit of license to riff on some of them here:

  • Treat your station as a single table. If one table needs a refill on a drink, chances are so do one of the other 4 tables that are all within 10 feet of that one. Save yourself some running by checking with all of the tables when one asks for something. In geek terms, this maps to looking for wins across multiple projects in your environment. Does your app need user authentication or a mail transport service? Chances are other projects do too. Looking for these kinds of wins can also help distribute the load of creating the requirements, and foster a sense of shared ownership in the result. 
  • Anticipate the need. Your customers shouldn’t have to ask for everything they need. Ideally they wouldn’t need to ask for anything they need, because you’d keep an eye on their drinks, you’d notice that someone wasn’t eating their salad and suspect something is wrong, you’d know that having kids means the first thing to the table is a huge stack of napkins, etc. The point is, there’s what’s happening now, and what is, in your professional opinion, likely to screw that all up. Your experience will likely guide you to solutions that are likely to keep that from happening. If not, you’re about to get more experience. Just like in technology 😉  
  • Presentation counts. All restaurants fiddle with the light levels, the music rotation, how food is placed on the plate, the garnishes added to drinks, and any restaurant you’d want to eat in is fastidious about tiny, tiny details from sweeping the entry foyer, to replacing tablecloths, to tossing old-looking napkins, to replacing chairs with tiny pinhole tears in the leather. Why? Because a restaurant is, in the process of serving you, also constantly selling you through your experience there. Of course, your software should do this, but you can get deeper than that: all of those ideas you have that nobody listens to, or you can’t get approval for? You’re missing some details. You don’t have any metrics, or you’re giving a geeky experience to a business-y audience, or you’re not presenting your idea in the form of an experience, or you’re creating a vision of a present instead of a product in the mind of the person with the checkbook.
  • Presentation can’t save poor quality. You can put all kinds of shiny AJAX-y Bootstrap-y stuff all over your site. It could be the nicest UI in existence. If the service doesn’t work, you’re toast. And those ideas you’re trying to sell internally? You’d better be confident they’ll work and have a solid execution plan, because a couple of bombs and no amount of presentation goodness is going to get you to “yes” again.
  • Consistency! Food quality, presentation, service… the entire dining experience, from the moment you set foot on the property to the moment you leave, should ideally be completely 100% consistent. Completely predictable. Zero surprises. It makes the restaurant easy to get to know, because if you’ve seen one, you’ve basically seen them all. Now think about the naming of your variables. Do you abbreviate here and write it out there? Think about how you package your software. Do you sometimes provide an XML config file and sometimes INI format? Think about your code layout. Do you sometimes use inheritance and sometimes composition, when either will do? Do you sometimes test? Do you sometimes… anything? Small inconsistencies add up. I believe we’re pretty much all guilty of them sometimes, but we should all strive to minimize them. 
  • Minimize Complexity. Very little inside of a restaurant is complicated or complex. Inevitably, the friction points where small complications live are where problems arise. A huge number of issues within a restaurant are human error: mistaken orders, mismatching food to table when the tray is assembled, food under- or overcooked, drinks made wrong or sent to the wrong table, miscalculated bills, forgotten requests for drink refills or side orders, the list goes on for an eternity. Ironically, computers are employed to help with some of it, and the food service world is better for it on the whole. In technology, and I’m sure in most jobs, most of the issues are more with the people than the technology. From forgotten feature details to overlooked metrics, from miscommunicated load projections to undocumented security policies, the clumsy inner workings, and inter-workings of human beings gets us every time. 
  • Mise en place! This is a French term, and I don’t speak much French, but in a kitchen it means “have your shit together and easy to reach, kid”. Chefs on a line will have a shelf or some other space that’s within arm’s reach where they put bowls and bottles of things they need all the time. The pre-meal time for a chef is spent double-checking that this small area is picture perfect, double-checking that refills and extras will be easy to grab during the shift, and making sure there’s no excuse for failure. I see teams fail at this quite a lot, actually. The mise en place for a technology worker are all of those things that need to be in place in order for a service to go to production. Metrics and monitoring. Hardware allocations. Infrastructure service dependencies. Security concerns. Power! I cannot count how many times a service has gotten to the week of deployment before a request to allocate storage in production was created, or the number of times hardware arrived before anyone thought about where it would be plugged in, or what that would do to the uptime provided by the UPS during an outage. 
Overall, I’d say it’s been for my progress in the technology industry to have grown and learned lessons from experiences in other industries, even if those experiences sometimes came from rather menial roles. Also, as my great grandmother used to say, all of that sweaty, smelly work was also good for me: “It builds character!” 

Is this thing on?

Wednesday, April 16th, 2008

Since the recovery from my recent outage, I’ve noticed that none of the normal feed sites where my posts normally show up caught the last post, so this is a test post to see what’s going on, if it was a temporary glitch, or what.

If you didn’t see the post linked above, please read it if you’re happy with your web host. I’m looking for a new one :-/

Ok, that’s it. It’s “lose”. Not “loose”.

Wednesday, April 9th, 2008

Every. Single. Day. This. Happens.

I read a *LOT* of online technical documentation. Come to think of it, I read a *LOT* of documentation offline as well. I also occasionally read things like blogs and comments and stuff. In all of my reading, I have found that the most prevalent mistake made by the writer in terms of grammar and spelling is using the word “loose” in place of “lose”. So here’s the rule:

“Lose” is a verb, as in “I will lose my job if I do that”, or “Please lose my number”. Other forms include “losing” as in “I’m losing my mind”, and the ever-popular “loser”, as in “That Anonymous Coward is such a loser”.

On the other hand, the word “loose” is an adjective, as in “he’s got a few screws loose” or “that development team has somewhat loose morals – I’ve seen them at conferences”, or “loosely coupled”.

How about this: if you want to describe loss, lose the extra “o” — copyright me, today. 😀