NB Attributes for Developers to Have

I recently did a talk at JS in SA and this is it:

Intro

At a conference like this, I’m almost guaranteed that I’m not the smartest person here. That realisation doesn’t help my nerves at all, especially since most of my talk is based on opinion.

Here’s some background on me to help show that I’ve got some street cred. At work I’m called either the “Grumpy Bastard”, or “Oupa”… Apparently I’m old because I started coding back in 1984 – I was 7 at the time so it wasn’t anything amazing. I did my first paid teaching gig around 1989, and my first paid coding around 1991/2.

I’ve been at my current company for the past 10 years moving from Developer, to Team Lead, to Development Manager, to Operations Manager. So I’ve moved from programming computers to programming people – across all departments in the company. Based on this role change, my talk has a bit more of an “Operational” (inter department) focus.

If you have any concerns or questions, I’m available online or in person to talk about it. I would love to learn and change my opinions, or help you understand my thinking if I’m too vague.

The Plan

I’m going to start by talking about some basic concepts that I hope you’ll all agree with, and I will then move on to some of the more opinion based thinking.

I am explicitly not going to talk about the following two things:

Balance – I’m hoping Martin will touch on this when he does his talk on “zen, Burnout and Programming”.
Conflict – Theo has his talk dedicated to this topic, so I won’t try to do the same.

“Smart and Gets Things Done”

I first saw this quote back in 2005 when I was starting to hire developers more regularly. It comes from Joel Spolsky’s great “The Guerilla Guide to Interviewing” ¹ (He has also written a book on the topic ²) There are two halves to this:

Get Things Done

If you don’t get things done, you don’t deliver your product. If you don’t deliver your product, you don’t get paid. If you don’t get paid, you don’t eat… and if you don’t eat, you die. Nobody wants to die, so you need to deliver.

Smart

So you deliver, but at what cost? What if the short-cut you take now costs you maintainability. So in 3 months time you can no longer deliver work or changes quickly. Now suddenly because you “got things done” in a silly way, you are no longer able to deliver. And if you don’t deliver, you don’t get paid. If you don’t get paid, you can’t eat… and if you don’t eat, you die.

The down side of “smart” is that you can over-think your solutions. So if you plan a system that is easy to understand, can scale to all possible future scope required, and is amazingly performant, you could end up spending two years designing the system and not delivering it. And again, if you don’t deliver, you don’t get paid. If you don’t get paid, you can’t eat… and if you don’t eat, you die.

So you need to use both halves. In my mind, the act of becoming smart must enable you to get things done – so learning the right tools and techniques helps you “be smart” faster” so you can deliver better solutions.

Be Self Aware

You know how to make computers do what you want them to do, but do you know how to get the best out of yourself? There’s a lot you can gain from learning about yourself. Try looking at things like:

Clifton Strengths Finder ³
Gamification ⁴ ⁵
Psychology ⁶ ⁷ ⁸

Larn about productivity tips and techniques to understand how you cna arrange your work time to your benefit:

Flow – That state where you’re “in the zone”, energised by the focussed work you’re doing. Mihaly Csikszentmihalyi
Getting Things Done (GTD)
Pomodoro
“Don’t break the chain” – Seinfeld
“Big Rocks” – Covey

Once you know how your brain ticks, you are able to be more productive. Being more productive is a great way to motivate changes in your work environment. Understanding yourselve lets you explain yourself and your needs better to others.

Communicate Well

A common problem I’ve seen is communication between a Developer and Business … and vice versa.

Here are some examples of developers not quite communicating well:

At one of my first jobs there was a developer who wasn’t happy that when it rained a LOT, mud would wash into his parking bay. His way of raising the problem with the rest of the company was to scoop up mud and drag it through the office. It didn’t go down quite so well.
I’ve been in a meeting where a developer started shouting at the client because the client was asking for something that fell outside the developers view of what a client would need to do. In the end the relationship burned out and the two could not work together anymore.
I’ve seen developers who refuse to work on something without using Technology X, not understanding the business difficulties in implementing it or the pressures on delivery. This has lead to projects that can’t be implemented, or that take twice as long as the client has available.

This communication is not just from developers, I’ve seen examples from Business too:

Businesses who expect people to work longer hours, without extra pay, continually. Businesses who expect people to “do more, with less”.
One business I was in would reward their Sales for selling the client on short delivery times by giving them large bonuses, but there was no thought for the developers who had to work 18 hour days for weeks to meet those deadlines. The developers would get into trouble for sloppy work, or delays in delivery.
There are also those businesses who don’t understand technology – almost the opposite of the developers who hold business hostage. In this case businesses expect things that can’t happen, pressurise developers to deliver in unmanageable timeframes, etc.
And then there’s the project managers who think that interrupting you every 5 minutes to ask “Are you done yet?” will help you to be more productive, instead of the horrible time waste it causes you because they’ve just dragged you out of the zone.

While I pick on both halves of this problem, you can’t expect that others will change – you need to look at how you can change your actions to bring about change for yourself, and possibly in others.

When it comes to communication, you need to look at how you communicate. You need ways to bridge the gaps between development’s priorities and business’ priorities. Don’t forget that there are loads of ways of working that are specifically designed to help with this. Look at tools/techniques like “Agile” / Lean / MVP.

One last thing that we need to be aware of is picking the right communication medium – Phone, Voicemail, SMS, Instant Message, or eMail. Don’t email in anger, calm down a bit and the nuse the phone – helps you to focus on the fact that the person you’re angry with is a person and not a faceless being. Don’t leave a voicemail when you need an instant reaction.

While I’ve focussed on things “not to do”, just remember that you probably have really good reasons to do what you do. So you need to be able to trust who you are and why you’re made that way. Your skills and thought patterns have an important bearing on the business you work in. ⁹

In the end it boils down to this: Trust your gut, but don’t communicate with it

“The Guerilla Guide to Interviewing” ↩
Book: Smart and Gets Things Done – Joel Spolsky – Amazon ↩
Clifton Strengths Finder – Find broad areas of skills/strengths you have so you are able to play more to your strengths, instead of focussing on your weaknesses. ↩
Reality Is Broken by Jane McGonigal shows a lot about how to use “fun” to improve engagement ↩
Coursera – Gamification – by Kevin Werbach (twitter) – This free course covers a lot of what motivates people and why. It’s a great way to learn how to design systems and people’s reactions to them. (Including your own) ↩
Behavioural Economics – e.g. Dan Ariely‘s Predictably Irrational ↩
Positive Psychology – Viktor Frankl‘s views on purpose. ↩
Body Language – there’s a lot to this, but a short example: Amy Cuddy, TED, “Your Body Language Shapes Who You Are” ↩
Melissa Marshal, TED, “Talk Nerdy To Me” ↩