Avoid “autopilot” behaviour when developing

I love coffee. And there’s a pretty good coffee place close to where I work that I regularly frequent out of the addiction I have now acquired for caffeine. Not to mention that I may possibly  need it in order to turn me into a less “abrasive” individual in the morning. 🙂 For the passed week or so, the conversation has gone a little like this:

Barista: Hi there, what I can I get you?

Me: I’d like a medium white americano, to have in please.

Barista: Americano?

Me: Yes

Barista: What size?

Me: Medium please.

Barista: To take away?

Me: No, to have in.

Barista: Would you like milk with that?

Me: Yes.

Now, this happens almost every time I go, and it got me thinking about some particular traits I’ve picked up on while working with some inexperienced software developers. When given a requirement, they almost instantly go into autopilot, and just begin coding, not always asking the right (or even at all!) the much needed questions that they should. On the other extreme, as in the case of the barista, sometimes they ask all the questions which were already answered in the first statement! As you can imagine, both ends of the scale result in a lot of wasted time. Clearly this barista was(and still is!) on autopilot, just asking the usual questions, and not really listening.

Inexperienced software developers have a tendency to just want to get stuck in a code away. I’ve been there, done that, and also subsequently been burnt by it. Resist this urge. Don’t assume you know the domain well enough to begin coding. Look at the problem you’re trying to solve first. Listen to the requirement and the context its in, and try to ask the right questions, and especially try not to ask the same questions which have already been answered, except for in the case where you are confirming your understanding.

I honestly think that if every developer did this, fewer bugs, fewer misunderstandings, and fewer under delivering to expectations would occur. If you need a little help on fighting the urge to code, then I’d suggest that you use the 5 Whys approach. If anything, this approach should help you contextualise the problem, and promote a discussion to lead you to ask the right questions before rushing in to code.

Advertisements

One thought on “Avoid “autopilot” behaviour when developing”

Comments are closed.