How’s your bedside manner? Do you think about how you interact with people with less experience or knowledge than you? You should. At a very specific task level nerds almost always know more than everyone about their work. Consider the code feature or document you have just finished. Unless you have paired with someone for the entire task you know the most. In fact, almost everyone is trusting that you have done a good job and that you have done it the best way. This includes most of your colleagues, your boss and especially your customers.

At higher levels of abstraction or with larger tasks the effect is reduced but still there. The chances are that your boss knows much less about your current project than you. Ditto for the customer.

If you are more of a nerdherder than a nerd then your boss and customers are definely at your mercy with regard to information and trust.

When you deal with all of these people who know less than you and are relying on you how do you interact with them? Do you think about the fears they have? Do you respect the trust they are putting in you? Do you take time to ensure they understand as much as they want to and are capable of?

Understanding the goals, fears and concerns of the people who rely on your expertise and judgement will help you do a better job. It will also help you to advance your career - nobody likes working with someone who doesn’t seem to care about others and no (sensible) manager would consider placing such a selfish person in a position of increased responsibility.

One of the more frustrating things that nerdherders (and nerds) have to deal with is omnibus information - those annoying emails or bug reports that contain an often random collection of requests or problems all mashed together in a series of loosly connected paragraphs and long lists of dot points. They are hard to archive/file and if an email reply is warranted then the different issues get in each others’ way. When they are but in front of your more organised and anal-retentive nerds they say to him/her “I am sloppy and don’t care about information, I can’t keep track of my thoughts and don’t really care if you do either”. Basically, this sort of information is less useful that it could be and makes the job of those interpreting it harder than necessary.

Making it easy for your friendly local nerds to serve you better can be done by following a few simple guidelines. So without further ado here is the Nerdherding guide to helping yourself with requests to nerds:

1. If you want to talk about two unrelated issues or problems then send two emails or create two bug reports. They can then be nicely moved through any process without tripping anything else up.
2. If you feel the need to conserve bits and simply must combine multiple unrelated issues then please clearly number or label each separate item. I’m amazed by often in my career I’ve had to deal with work requests containing dot-point lists - its embarrasing for everyone when I have to say “tenth dot point in the second list”.
3. If you have to communicate a high priority issue with other less important issues then please separate out the high priority issue. Its less likely to get lost in the noise and means that the less important issues won’t be ignored.

P.S. I must admit that sometimes I tend towards the “organised and anal-retentive” end of the spectrum.

Once in a while a software project begins to go wrong. You know the score. Each day another critical bug appears in module X or the completion date for feature Y slips by a day. The team keeps working hard and produces stuff. Every day you are sure you’ve broken the back of the problems but then another appears. It saps your spirit and makes the team doubt themselves.

There’s a secret that comes with experience that you probably know. In fact there’s a saying that pretty much sums up the secret:

“If you find yourself at the bottom of a hole then the best thing to do is to stop digging.”

Apply this idea to the project going wrong. Is it really just a series of small incidents that, through a run of mind blowingly poor luck, have all started to bedevil the project one after another? Perhaps a more likely explanation is that there is a fundamental problem that is now showing its head. Is your development process out of control or inappropriate for your team or the project? Perhaps you have a poorly designed module that is poisoning the well. Maybe there is a bad assumption in the business design of the application. Who knows. But maybe, just maybe, there is a single more fundamental reason why the project has gone of the rails. Your mission is to discover the fundamental problem. Good luck.

Recent posts

Nerdherding for Beginners is written by Michael Harmer, released under the Creative Commons Attribution-Noncommercial 2.5 Australia licence powered by WordPress and designed by XiAP Design Studio.