Welcome to the Rest of Your Work Life

Last week a dozen people at my office lost their jobs because business changes had made their positions unnecessary. Among those cut loose were most of the folks I hung out with at work events as well as one of my closest friends.

I thought I’d write about my own experiences with sudden re-introduction to the job market, but I realized that this might be an example of making the pain of others all about me. I’ll save that for another day.

Instead, in an effort to be useful, here are some suggestions for dealing with life sans work.

  1. It’s not you. Obviously it’s happening to you, but a layoff is not a judgement on you or your performance. This isn’t important merely for your morale; it’s vital for interviews. Why did you leave your last position? The business dissolved it. Sticking to this neutral truth indicates not only that you weren’t at fault but that you possess the maturity to speak about it objectively.
  2. Stop and smell the Pop-Tarts. It’s important to take the job search seriously. Set aside time to devote to locating opportunities and adjusting your cover letters to suit them. But it’s vital to attend to your spirits. You’re under stress, so you need to cool off. Do something you enjoy every day, whether that’s reading, playing games, or hanging out. Don’t be afraid to have fun; you’re still allowed!
  3. Keep a schedule. If you’ve been using an alarm clock, keep setting it. You still have work to do! Exercise? Keep it up. Maintain as much routine as you can. It’ll help lessen the disruption of your (hopefully) temporary new situation.
  4. Get a kitten. I’m pretty clearly running out of advice, but I have a spare kitten yet. I’m just saying. He’s cute, and sometimes he poops in the litter box.

I hope everyone finds a new position quickly. They’re all talented folk, so I’m sure they’ll be fine.

Advertisement

Coding Fiction

It’s not entirely analogous, but there are ways in which programming is like writing fiction. Maybe it’s because I do both, and my lessons from one activity inform how I perform the other. Nonetheless, even if the connections are forced by my perspective, they are able to be connected. So here’s where I see them being similar, or at least having common usable approaches.

It’s easier if you have a plan. It doesn’t have to be exceptionally detailed, and it doesn’t have to be set in stone, but whether writing a program or a story it helps to have an idea of what the end result should be. I know that some folks like to just start writing and see where it takes them, and that’s fine. Whatever works for you is the way you should do it, right? Me, I find it a lot easier to put words down if I know what tone I’m going for and have some loose structure in mind.

You’d think that knowing what you’re trying to accomplish would be a given for programming. After all, there’s a requirements document and everything! Well, for most of my career I’ve been on agile projects, and very few of them had a requirements doc. Far too many, in fact, had us start writing code before we even knew what the project was about. There was one project at HoneyPot where we spent $1 million on development before the client had agreed on requirements. That went over poorly.

Entire sections may need to be rewritten. This is a hard lesson for writers, but it’s widely understood. What seemed like a great passage when written might need to go because of pacing considerations. Or a part of the plot wasn’t working, and you needed to rework the scene to support a revision. It’s all part of the process.

For many programmers with whom I’ve worked, touching code a second time amounts to failure. The ingrained model is “One and Done” — a sort of measure twice and cut once approach to coding. This of course assumes you have full and correct requirements, which you won’t. Ever. It’s simply unrealistic to believe that new requirements won’t lead to a rewrite of part of the code base. Nonetheless, I’ve seen a developer literally on the edge of tears because yesterday’s code didn’t support today’s business needs.

It’ll never be perfect. I spent 10 years rewriting the first three chapters of a novel. Those three chapters were pretty great! In that time Stephen King pumped out enough books to fill a shelf. Big, thick, hippo-choking books. Done is better than — well, not done. There’s a point called “good enough”, and it’s probably lower than you think. Just read a best-seller; you don’t even need complete sentences anymore.

I mentioned that programmers don’t like to revisit code. One tactic they use to avoid it is to make their code as perfect as they can imagine, able to take on everything they can think of. But you can’t think of everything, and there’s a point beyond which you’re spending time solving a minor problem when major work needs doing. Do a good job, but let it go.

Lastly, and most importantly, whatever gets the job done is right!

Magical, Farting Elves

Network diagnostics are not a strong point of mine, so when things get screwy at work I’m pretty helpless.

Today, for about a half an hour, the network completely forgot I existed. I lost access to servers, code repositories, email, and a number of internal apps. Some of my co-workers suggested that I should check that my passkey still worked, but others pointed out that I might just leave if it didn’t.

To stay sane (and because IM still worked) I chatted with a co-worker while struggling to get my access restored.

Me: You know how you had network problems the other day?
C-W: Yeah?
Me: Now I can’t log into anything.
C-W: oy.
Me: My computer locked me out, and I could only get back in by restarting it.
Me: But anything that requires a password is hosed.
C-W: Freak week.

13 minutes later…

Me: It’s exactly as though my password expired, only it shouldn’t have.
Me: I didn’t get 1000 reminders. šŸ˜‰
C-W: Weird.
Me: Aaaand now it works again.
Me:
C-W: Lucky you!
Me: Someone must have fed the elves.
C-W: Or farted.

Yup. Farting elves are the cause of so many of our problems. If only there were a way to treat their tiny little flatulance.

That is One Ugly Mug

There were no more packets of the flavor of coffee I drink at work, so I rummaged through the cupboards in our kitchenette to see if there were any boxes hidden away.

That’s how I found the ugly mug.

I -- Wow, no.

I — Wow, no.

I can only imagine that someone left it here out of spite. Surely nobody actually tries to drink out of this horrid thing.

May I Freshen Your Documentation?

There’s a post-it on a cupboard at work that explains how to make coffee. I wrote earlier about how these instructions were modified to convert the measurements to decimal.

The coffee maker was recently replaced with a Keurig pod brewer. The only thing to measure now is the size of the coffee cup. No more scooping; just pop in your pod in push the button.

So we can toss the instructions now, right?

Wrong! As developers it is our responsibility to update documentation!

I see the Keurig. Now what?

I see the Keurig. Now what?

All of the previous text has been commented (crossed) out, and “see Keurig” has been added to the document. Good job, developers! Keep documentation relevant!

Hall Passing

There’s a hallway at work that is so narrow that only one person may use it at a time. It extends for around 10-12 feet and provides several daily opportunities for hilarious collisions. This constricted space was created by the installation of a large cube, purportedly to create an open work area.

A convex mirror has been placed at one end of the passage, and I don’t know anyone that actually checks it for oncoming traffic. Usually we just round the corner and discover that a Zax is already in transit. Then we back up and smile awkwardly until the way is clear.

The cube wall is about 5 1/2 feet tall, so I can see over it. I’ll sometimes see the tops of heads bobbing along, which cues me in that someone might be about to run into me. Or vice versa, to be fair.

Diagram of hallway created by cubical

Every day we have to clear Spartans out of this narrow passage.

This morning as I crept down the hallway, over the wall I noticed a thatch of dark hair approaching the intersection. This matched the scalp of a programmer I’ve worked with for a few years. Perhaps a bit loopy from my sinus medicine, I decided to spring out in front of him.

I leapt sideways out of the alley, facing my victim with my arms spread wide.

“AAAAH!” I yelled.

The release manager nearly spilled her tea as she clutched at her heart.

Sheepishly, I apologized for scaring her. She was very kind about it — even thanking me for preventing a collision — but I felt really stupid about the whole thing.

I slunk away, wondering if I’d have gotten that good of a reaction from the guy I’d intended to scare.

Stasis Meeting

A while ago I attended a meeting about how to hold meetings. It was as useless as you’re probably thinking, consisting mainly of such generic tidbits as “start on time” and “don’t allow gadgets” with absolutely no discussion of how to enforce any of it. It was a waste of time, like the majority of meetings, but it didn’t approach the destructive idiocy of the status meetings that first made me a Java developer.

I told you (in Billing Time) that I became a developer because of my unpublishable novel. That led to work with HTML (which I knew), JavaScript (which I did not know), and VBScript (which I did not want to know). My path to becoming a Java developer had to with the time-honored management practice of throwing more mummies on the fire.

I’ll take a slight detour to explain that turn of phrase. The British supposedly used mummies to fuel trains in the desert because they were plentiful and wood was not. I’ve never cared to look into this claim because of fear that it’s probably true. At any rate, to my mind it’s a perfect analogy for the conventional strategy of throwing resources at a problem without considering how best they might be used. Other, tactful people call it putting butts in chairs. I call it throwing mummies on the fire.

This time the fire was a HoneyPot project that was behind schedule and I was the mummy.

My task was to write a Java application that would take test data out of a database and construct XML to use for testing. The team needed this but nobody had the time to do it. No problem. That’s an easy task, and an entirely reasonable request of someone who knew what any part of that meant.

Why did anyone think that it was a good idea to have me do it? I was available, and as I said everyone else was busy. The team was working 12 hour days as it was, so asking them to add this work to their load would be even more insane. Still, I had trouble believing that I would be of much help.

Then I went to my first status meeting.

For three hours, the entire team sat and took turns giving an amazingly detailed report of their progress since the last meeting. They were asked to revise their previous estimates and explain any and every slippage. Then there was a general attempt at removing blockages. All of this took only about 10-15 minutes per person, but with at least a dozen developers that adds up.

What nobody said was that they’d all get a lot more done without the daily status meeting.

I realized that no failure on my part could possibly make this situation worse. It took me a few weeks and a lot of mental anguish, but I delivered a tool that would suffice for one of the four cases they needed. They were so far behind, that they were glad to have just that.

There were two valuable things I gained from that project. The first was enough confidence in my ability to learn to carry me forward as a consultant. The second was an understanding that management views meetings as a special, magical period of time that does not come out of their budgets.

Grounds for Dismissal

In the kitchenette nearest my “office” there is a note about how to make office coffee. One part of the note specifies that “3/4” cup of grounds should be used. I don’t drink this weak sauce, so I don’t know how long it’s been since this measurement was amended to “0.75”.

Joking about this seemingly pointless edit, I was informed of the sad necessity for it. Someone had managed to misread “3/4” and used 3-4 cups instead.

My first thought was that whoever did that was probably the same jerk that’s been throwing trash into the recycle bin. My second was that I missed out on the best coffee we’ll likely ever have here.