Posted on 25 June 2004 under
GeneralI believe that the best way to distinguish between an average nerd and a nerd with inherent potential is to see how they react to magic in a project.
What do I mean by magic? Magic has happended when:
- a problem is solved by a seemingly unrelated action (e.g. changing the order of unrelated actions stops a system failure).
- a chunk of code is copied en masse into a new project and nobody understands how (or even why) it works.
- a recurring but seemingly random crash disappears.
When magic happens the more average nerd simply shrugs, maybe thanks the coding gods, and then simply moves onto the next piece of work. A quality nerd will get nervous. She will try work out why the magic worked. Many theories will be tried out. Experiments will be run. Co-workers will be consulted. In short, the better the nerd, the more effort expended on rational investigation rather than simply accepting good luck.
As I said earlier, I have found the reaction to magic in software to be a fantastic indicator of nerdly quality and leadership potential. What about you? Do you believe in magic? Do you think its a good indicator of nerdly quality?
Posted on 17 June 2004 under
GeneralI know that this is probably irrelevant to most experienced software engineers out there (forgive me if I’m telling you how to suck eggs) but this is advice I have had to give to plenty of software engineers in the past. Please don’t do too much at one time without making sure everything works.
There is nothing like the exasperation you will cause co-workers when you explain that you don’t know if it was changes for feature 98b (2hrs), 98c (8hrs) or 98d (8hrs) that cause the system to crash at random. Stop and test before you go on. Please. Its silly unprofessional to plow on, pretending you have finished when you haven’t.
If you think you aren’t able to test before a couple of days of work have been completed, then you really aren’t trying very hard. Re-order the tasks. Introduce a cut-down version of a feature that will allow you to stop at that point and ensure things are working okay. It is rarely necessary for an application to be “in pieces on the floor” for any significant length of time (>2 days) in an unworking state.
Another instance of this trap is when you are asked to debug a complex application that just started to crash. Never ever change more than one thing at a time in the code or its operating environment before seeing if the problem has been fixed. You will need to know what was wrong before anyone will be satisfied that the problem was really fixed. Saying that it was either because you increased the heapsize or fixed a filehandle leak probably won’t be good enough, so why embarrass yourself?
Posted on 17 June 2004 under
GeneralNerdherder: So, Nerd76, how is task98 going?
Nerd76: Good.
Nerdherder: How good?
Nerd76: Its finished.
Nerdherder: Does anything else need to be done on it?
Nerd76 [looking a little sheepish]: A few things. I need to test it against widget33 and check it in.
Nerdherder [sighs, takes axe from behind whiteboard and neatly decapitates Nerd76, then places the dripping axe on the meeting room floor next to the whiteboard]: So, Nerd77, how is task99 going?
Nerd77 [looking nervous]: Good.
Nerdherder: How good?
Nerd77: I only need to test it against widget34 and check it in, so its not finished.
Nerdherder: Thanks, Nerd77. Nerd78…
It constantly amazes me that people who can be infuriatingly literal and seeming devoid of anything apart from pure (machine) logic don’t have any qualms about declaring something that is obviously unfinished to be finished.
The problem is, of course, that many nerds see the writing of code as the work they do. All of the other stuff is simply busy-work that they need to endure so they can write code. Since many nerds don’t view any non-coding tasks as real work, they inadvertently think of tasks being completed once the coding aspects have been finished.
What can we all do about this?
- If you need to get information out of nerds about tasks then be sure to determine (and define) exactly what “finished” means. Asking “Is there anything else to be done on task883?” doesn’t hurt.
- If you are a nerd please please please please be careful not to declare something finished until everything you need to do to finish the task has been done. You never know when that meek and timid nerdherder might snap and grab the axe hidden behind the whiteboard.