Captains Log, Supplemental

Captain’s log, Stardate 43539.1. We have moved into orbit around Bre’el IV. With the assistance of the planet’s emergency control center, we are investigating a catastrophic threat to the population from a descending asteroidal moon.”
“Captain’s log, supplemental. We are no closer to finding a solution to the deteriorating orbit of the Bre’el moon, but with the arrival of Q we now have a good idea of the cause.”
“Captain’s log, supplemental. We have sustained light damage from an attack by an alien species known as the Calamarain. They apparently have a grievance with Q – no doubt one of many lifeforms that do.” (TNG: “Deja Q“)

The Captain’s Log takes you through the high notes, letting you know three things:

  1. What happened
  2. What’s happening now
More importantly, it tells you this when it’s happening. Let’s say, God forbid, that Wesley Crusher destroys the ship in a fit of teenage angst and all we find of the ship is the jettisoned Captain’s Logs. Would you rather the last few entries say:
Captain’s log, Stardate 51734.1 “Wesley Crusher has rejoined the ship after an extended stay with the Traveler. In the intervening time, he has grown angrier. Dr. Crusher is relieved to see her son, but concerns about his mental stability remain. I’m asking Dr. Pulaski to run a full scan on him to be certain.”
Captain’s Log, supplemental. “Dr. Pulaski has run the scan, and determined that there is a creature of unknown origin inhabiting Wesley Crusher. In his more lucid moments, Wesley believes he received the parasite during a visit to Risa’s notorious South Pole.”
Captain’s Log, supplemental. “The parasite has taken over Wesley crusher completely, and has used the knowledge of the Enterprise to jettison the Warp core and shut down life support. There is currently no way to get off the ship. This will be my final log as captain of the Enterprise. Her ship and crew have served well, and are in keeping with the finest traditions of Starfleet. I am transmitting this log on subspace Starfleet Command, Priority One.”


Or this:

Captains Log, Stardate 51734.1 “Wesley crusher came onto the ship today and proceeded to shut down life support and jettison the warp core. There’s no way to leave the ship.”

The first one, of course. It sounds better. it’s more complete, and in case your ship is found adrift with all crew dead, at least someone has an inkling of what happened to you.

Just like in code.

You fix a problem, you go on vacation or win the lottery, or quit.  As soon as you step off the plane in Tahiti, there will be a bug with what you fixed.  The programmer tasked to fix this bug is going to want to know what you did. He has source control for that; but he’s also going to need to know *why* you did what you did. What alternatives did you consider? 

I’ve written about this before.  

The bug report is your chance to concisely list the relevant issues with a bug, how you are going about fixing it, and most importantly, what didn’t work.  Maybe I’m senile, but I can’t remember what I fixed 6 days ago, let alone 6 weeks ago. The bug report helps me keep a running log of what I’ve tried and what I haven’t.  In instances where it doesn’t make sense to put it into a defect tracking system, I keep a personal notebook. It goes with me everywhere, and it contains details on any solution I’ve ever tried. It’s my own personal Captain’s Log, and privately I call it that.

If you’re just publishing Changeset numbers and the word fixed in bug reports, you’re doing your teammates a disservice. Programming is hard enough as it is, don’t make it any harder by not ‘showing your work’.


Caring for Your Recently Acquired Programmer

Congratulations! You were just given a new Programmer!

Pop Quiz:

Do you…


  1. outfit your programmer with the standard office equipment?
  2. order custom equipment specialized for software developers? 
  3. ask your programmer what he needs to get his job done? 


 If you answered (2) or (3), you’re on the right track. otherwise, you get a nice little tombstone when your developers leave, a la Oregon Trail:


Software developers do three things:


  1. Concentrate really hard. 
  2. Type a lot. 
  3. Sit on their fourth point of contact for extended periods of time. 


How does the standard office equipment fare against these requirements?

Poorly. At best.

The monitor is a 15 inch LCD as one screen, and a laptop screen as the second. With any luck it’s a desktop with two monitors, but sadly they’re both 15 inches.

In some unspeakable instances developers have *one* monitor.  Prolific developers and bloggers have already beat this subject to death. To save you time, here’s the right answer: High Quality monitors. At least two of them. Really big ones. Like 24″-30″. 

Back to my flattened rear end. Office Chairs are expensive, no doubt.  Office chairs that meet our needs? Even more so. I bought a Herman Miller Mirra chair a while back based on recommendations from people I trust, and it’s the best decision I ever made. Believe me when I say that I’m halfway tempted to take it with me to work:

The final piece of the puzzle is a really fast computer.  Really fast. Not “Oh, I bought this from Dell” fast, but “We needed to custom order these” fast. 

I could spend and entire blog post on that alone (and probably will), but here’s a good rule of thumb: If you can buy it without having to customize it, it’s wrong. Your action word to the Sales rep should be ‘More‘.

Overall, this will cost about $4000 a developer. Another 2-3 grand for the PC.  In return, you get a developer who is happier, more productive, and is less likely to jump ship when one of your competitors wises up and starts offering these perks.

Don’t think about it as a cost, think about it as a savings: For any developer you lose, you’re going to lose a lot more than $4000 to replace them.

A tale of two companies

There are two kinds of companies in this world: The kind that sell you software, and the kind that use software to sell you something else.

There’s also the PGA. Someone forgot to inform them about the technology revolution.

The companies that sell software are easy to spot. You see their products in stores that sell… software. The companies that use software to sell you something are everywhere else. The golfers are on the links, chasing balls and cursing the gods.

Both kinds of companies have a bottom line in mind, they just think there are different ways to get there: Software companies know that good software (or a cornered market) is the key to making lots of money. Those other companies figure that software has something to do with making more money, but aren’t quite sure how that works. They aren’t even sure how to handle software teams.

And you have software developers caught in the middle. 

We love what we do. In the majority of instances, we started programming or tinkering with computers when we were young, and it made us happy. We kept doing it. Lawyers can’t file a brief at age 5, but kids can program at age 5. When we grew up, we figured that everyone would see how much we like software and just leave us alone to make it. They had other plans. Meetings, diagrams, excel spreadsheets, quarterly reports, and cost/benefit analyses.

You show them great software, and they want you to make one of those things I just talked about, and try to fit the software in it somewhere, as if it were a line-item on a spreadsheet, or a font of magic in a diagram. In a meeting, it’s just a lot of buzzwords: We’re going to synergize our multiple offerings across the blogosphere with social media while using diverse delivery platforms to ensure a higher conversion rate. Or something. 

Then, they pat you on the back, and tell you to go make their dream a reality. Then they leave for the golf-course. You sit down, read through piles of reports, looking at snazzy diagrams, and staring at numbers some accountant told you you’d have to meet.  

It’s just about at this point where it hits you: They have no idea what it takes to bring pure thought stuff into something that ships and doesn’t suck. They have the gold, they make the rules, or so the conventional wisdom goes. You start banging out functional requirements, technical specs, and if you’re lucky enough to have a UI guy, he does the user interface stuff, and you two collaborate. If you have a team, you divvy out the work, collaborate on the design if needed, send the questions back to the customer. He’s probably on the golf-course with your boss, or he is your boss.