June 20, 2008

Smart and Can Be Trusted

Posted in development at 1:59 pm by lugnuthorsefly

There’s a venerable article on hiring by Joel called Smart, and Gets Things Done.

More recently, Steve Yegge has written an piece, called Done, and Gets Things Smart

All of which are part of the tiresome and long-running rock-star programmer debate, but it did give me pause for thought about the kinds of programmers I’ve worked with over the years and the categories I’ve started to (no doubt unfairly) group them into.

DISCLAIMER: If you’re a former or current colleague of mine the rest of the article is not about you. It’s about other people. You are a unique sunbeam that cannot be so cavalierly stereotyped.

The Categories:

1) The Truly Useless

These are the people that cannot be trusted to do anything right. They have somehow graduated without learning to program at all. They need constant guidance and handholding and generate negative productivity by sucking time from other people.

They seem to survive by either

a) Finding a company with poor hiring practices that lacks the nerve to fire them, or

b) Endlessly taking 3-month contracts (which are never renewed).

Sometimes these folks are just in the wrong job. In one case a former programmer eventually let go went on to thrive as a testing and QA specialist.

These people are why you need a decent programming test as part of the interview process. A programming test won’t distinguish the great from the good but it will filter out the Truly Useless.

2) The Toilers

These are the people that can get stuff done and do it well within their areas of expertise but will generally have trouble with

  • Doing significant design work.
  • Finding a solution to a problem that involves doing something architecturally different (realising that replacing a slow RDBMS solution with a persistent in-memory hash table might be a good idea for example).
  • Learning something new (like a scripting language).
  • Taking initiative to suggest and implement significant changes.

There seem to be a couple of different kinds of toiler.

  • The JobsWorth: Some people just want their job to be as easy as possible. They don’t want the hassle of doing anything extra or agitating for change. They just want to put in their hours and get paid. I think some people are afraid of responsibility, too.
  • The Struggler: They can do it, but it’s hard work. The code gets done but they spend days baffled by mysterious bugs. Everyone’s a struggler at some point, I certainly was. As I get older I’ve realised I’m not necessarily smarter than a new graduate, I just get more done because I can fix that bug they spent 2 days on in five minutes because I’ve seen it before (3 years ago, in fact, when I spent 3 days fixing it).

3) The Go-To Programmer

This is Joel’s Smart and Gets Things Done programmer. My definition is: this is the person you can trust to solve a hard problem; the programmer with the smarts, experience and imagination to get around most of the problems encountered in a software project without handholding. This programmer will, for example:

  • Trace a bug into another subsystem in an unfamiliar language to fix it rather than saying “that’s the Java programmer’s problem”
  • Realise that there’s a big ‘ol lump of work between “code complete” and “software is released” that need to be planned for.
  • Be proactive about overcoming roadblocks rather than halting and waiting for guidance.
  • Not act like the team leader is the only person allowed to do design.
  • Come up with the complex load-balancing architecture that saves your website.

Ideally, your whole team (and you) is this sort of programmer. Go-To programmers are like gold to a PM or team leader because you can trust them to get things done and not bollocks them up.

4) The Rock Star

Some stuff is just really really hard. Like making streaming work on a 1x CD-ROM, or making leading-edge 3D engines and that fact is that the vast majority of us wouldn’t be able to solve these problems at all in any amount of time.

But do your projects have problems like this? I’m guessing not.

March 18, 2006

Non-negotiable rules of UI design #2

Posted in development at 11:52 am by lugnuthorsefly

For Pete’s sake try and cope if the network is down.

Due to a recent relocation of my home PC I’ve been experimenting with a wireless router. This experiment is not going well but I won’t go into details because apparently my mother-in-law reads my blog and I find myself unable to describe the experience without using language more suited to the Bile Blog.

Anyway, it seems that any number of programs I use assume I have internet connectivity and completely fail to behave when I don’t.

Take iTunes, for example (the Windows version), which flat-out refuses to run at all unless the internet is up. I just want to listen to some #%!&’ing mp3’s for !@#$’s sake!

February 1, 2006

Non-negotiable rules of UI design #1

Posted in development at 3:40 am by lugnuthorsefly

“Any window that contains, or can possibly contain a scrollbar must be resizable”

We all have big monitors these days. There’s no excuse for not doing this.

January 5, 2006

The funkiest thing

Posted in development, java at 11:25 am by lugnuthorsefly

Back in the good ‘ol days (by which I mean the dot-com boom) I worked for a quite cool web animation company that suffered the misfortune of building things that, while they were technically very accomplished, no-one actually wanted (such as 3D banner ads and two dollar pig movies).

In late 2001 the founders of this company did the only sane thing and shut down the 3D animation side of the business and segued artfully into the shady world of P2P copyright violation, which was more financially viable but may result in them going to jail.
All of which is beside the point.

My point (and I do have one) is concerned with the interview process at BDE, which went through a number of revisions (some of which were known internally as “heard of 3dsmax? you’re in!”, “impatient frenchman” and “Boss’s girlfriend’s brother”). At one time we went in for what I like to call the gangbang interview, which involved the prospective candidate being interviewed by 6 or more BDE programmers and asked essentially random questions designed primarily to make the asker look smart (we thought we were shit-hot because we were almost (but not quite) in the games business – mostly it was a pose but some of us weren’t faking).

In these interviews, one of our developers (who was responsible for the Sega Saturn port of our 3D engine, poor guy) always asked the same question: “What is the funkiest thing you’ve ever done?”

At the time I thought it was a terrible question, not relevant to the technical requirements of the job and likely to lead to a blank kangaroo-in-the-headlights stare from the geekier applicants as they relived their worst not-cool-enough nightmares from high school.

Now that I’m older and (possibly) wiser? I think the “funky” question (or something like it) is an excellent question for job applicants.

Actually, the question itself isn’t as important as its intent, which is to detect some evidence of passion for software development.

And I have selfish reasons for this. I want to work with people who are passionate. It’s more rewarding and more fun. I also don’t think it’s hard to make the case that it benefits the organisation, too (except for extreme boundary cases like the guy who hacks on the Linux kernel until 3AM and then sleeps at his desk all day).

I don’t do heaps of interviewing but I’ve got a few things I always always ask:

1. If you’ve worked with two (or more) languages (say Java and C++) I always ask what you liked about each one and which you prefer. I don’t care which you prefer, I care that a) You have some understanding of the tradeoffs and b) you have an opinion.
2. What stuff do you do in your spare time. If you like development enough to do something in your spare time then you’ll likely care enough to do it well at work. In my experience the justajob crowd tend to be the worst for cut’n’paste evilness.

3. Can you speak with some animation and enthusiasm about something you’ve worked on in the past.

None of these are prerequisites. They’re a big help, though.