Nerdherding for Beginners

I am often frustrated when discussing complex things or long lists of actions with some nerds. Not because the nerds don’t get it (at the time). Not because I find it difficult to express things (well I do sometimes but let’s ignore that for now). Its because some people seem to think they they have such a large brain capacity that they don’t need to write down any of the three or four dozen key pieces of information they receive over an hour long discussion.

Things get forgotten if they aren’t written down. So for the sake of us all write it down! Nobody is going to think that you are inferior if you need to take notes in order to remember a bunch of important stuff. Oh, and for the love of all things good and beautiful at least pretend that your nerdherder might say something worth writing down and bring a notepad and pen to any discussion.

Successful software is created by teams that deal with risks. The likelihood of things going badly should be a key measure by which decisions and alternatives are evaluated.

Mike Clarke has written a neat post especially for all you nerds out there who need help to convince your managers that a continuous integration and build machine would be a good idea.

Yesterday afternoon I ordered some books (including Tipping Point by Malcolm Gladwell on Clarke’s recommendation - better be good!) and they were in my letterbox before I left for work today. I ordered them through Bookware who I’ve used a few times now. Each time the experience gets better - highly recommended for all you Aussie nerds out there.

I found out tonight (via an unnamed little birdy) that a manager at a company I used to work at was sacked. When I heard this I am embarrased to admit that I felt not an insignificant amount of schadenfreude. This person is basically good but has personality flaws that make her horrible to work with and verging on incompetent in the roles she had (people responsible for HR matters should, as a general rule, be likeable, approachable and be able to form a realistic picture of the capabilities of staff).

The reason for my schadenfreude is that I resigned from a job I loved (partly) to avoid having to work with her anymore and, more importantly, because some years later she basically decided who at this company should be made redundant (after she and the rest of the management team there f**d up the place). “Surely it’s okay for a HR-style manager to make such decisions?” you ask. Well, yes, except that competent people were sacked in favour of significantly less competent people she just happened to be friends with or liked. It was pretty blatant.

So, in the end I don’t feel too bad about the schadenfreude. I can always pretend that I’m glad that the universe is in balance - karma has proven it exists once again.

Important caveat for people still working at this company - not everyone who wasn’t sacked at the company was a waste of space. C’mon guys you know I don’t think you’re incompetent. Except for Nick B.

If a bunch of programmers are left to their own devices they probably won’t produce very useful software. This is true even for a bunch of really smart programmers.

Developing a single feature at a time over multiple (internal) releases is a faster and more successful strategy than developing multiple features in a single big bang release.

The essential ingredients of good software are self-aware teams, reasonable organisation/management skills and a modicum of leadership. Bad software is often caused by poor or negligent management that fails to secure the essential ingredients.

Customers rarely know what they want until they are shown something they asked for that isn’’t what they want.

Due to their work-habits, some developers are vastly more efficient than others. Similarly, work habits allow some teams to be extraordinarily more efficient than others.