Doing a Good Job

Published: Fri 04 September 2015
By EWS

In Revival.

NOTE: This article was originally published in early December, 2009. I'm republishing it (category: Revival) as a nod to content that drew interest at that time, as I said I would do at the point of reboot.

I’m going to say something shocking...

Your degree that you worked for for years doesn’t mean a whole lot.

I can say that, because I was living proof. I studied for six years to get a masters degree.  At the end of it all though, there was only one pertinent question:

Can you do a good job, consistently?

And, I’m ashamed to say that at that time, as a fresh start in my first job, I could not reply “yes” to that question, at least according to my present-day definition.

‘So, what does “good” mean?’ you may ask. Good point.

It can be argued that it’s in the eye of the beholder, but “good” can be characterised by a range of things and it’s pretty much universally recognisable:

  1. It’s complete.  The proverbial i’s have been dotted, and t’s crossed.  It’s been checked, and cross-checked.  Complete has an “aroma” to it—you actually want someone to look at it—you’re proud of it.
  2. It’s timely.  Part of “good” is sticking to your word—you said it would be finished by the end of the week?  Make it so, by hook … or by crook.
  3. It’s succinct.  There’s been an effort to ruthlessly focus on what’s important.  Just because the annual budget is important, it doesn’t have to be voluminous.
  4. It’s correct.  That means you’ve proof-read it, and possibly even got someone else to proof read it.  If it’s code you’re writing, you’ve written automated tests to confirm that it behaves the way it’s intended to.
  5. It has built-in continuity.  Someone needs to extend it or enhance it?  No problem, there’s a Readme that bootstraps you … and the code is “literal” (not necessarily Knuth’s definition, but aspiring to be).  The way to nail this one is to regularly put yourself in the next persons shoes.
  6. It’s transparent.  It’s built to be absorbed by other human beings—there are no gotcha’s.  If it’s code, it isn’t too “clever”.
  7. It fails fast.  When you build something, you need to be in the place where you know it’s going to fail.  Good is not perfect.  So when it fails, even when the condition seems innocuous, fail fast and fail hard.  That’s because too much energy is expended on hiding and fretting than failing and fixing.
  8. The thing to notice about all the points above is that they’re not actually taught at school, not explicitly at least.  For me, that’s ironic—because knowing what I know now, I would take someone who’s got those things down pat any day over someone who has a PhD but who can’t deliver.

So, it’s worth ruminating on today: “Am I doing a good job?”.

Comments !

social