Confessions of a software development manager

Part 5 The Speedster

Development teams everywhere have one form of speedster or another, their motives are almost always good, but like most comic book heroes there is almost always a downside.
In comic books and animation, or more recently television series and films, an innocent bystander or a family member gets injured or even dies, collateral damage is usually at an all time high, or the villain escapes, and all usually because the hero overlooks a major factor or misses a clue or is suspiciously naive and hands the villain an advantage.

Much like the super heroes in question,  speedsters tend to do more good than harm, and their failings can be categorised into the following subsets:

Negligence
Transgression
Impatience

Negligence is by far the most common trait of a speedster and ironically the one which absorbs the most time. As the old adage states "more haste, less speed". How many time have you witnessed a missing semicolon or parenthesis cause an issue? They are the the most common type of issues and are easily resolved, taking only a few seconds much of the time.

One speedster I know actually types his parentheses in pairs before inserting anything, and always does the same with quotes and tags.
This way he avoids missing closing things off almost all of the time.

Bizarrely enough, we actually dubbed him "The Flash".

#goodenoughforNoah

Misspelling a variable, class, function or procedure name is another common one and can be a real pain if what you type is actually the name of a valid item.
#bewaresimilarnames

My personal favourite is the copy and paste special.
A block of code is to be re-used with only a variable or procedure name to be changed in one or possibly a few places.
#checkyou'vechangedthemproperly
Compiler doesn't complain, code works perfectly well, just outputs the wrong value or sometimes doesn't output a value at all. This often happens when pasting the block of code more than once.
#pasteoneblockatatime
This can sometimes be difficult to spot when you are running tests locally and using minimal data where the two values could actually be the same. This also is a tendency of the speedster.
 #makethenumbersdifferent

Then of course there is the dreaded nesting scenario.
#formatyourcodeasyougoalong

How many times have you seen a spelling mistake on website? The last two I saw were "avaliability" and "severley". I would like to think that my spelling and grammar are quite good and there is little worse than having a walk-through or remote sharing session with a customer and spotting a spelling mistake on screen. At that point you have two thoughts, "do I point it out?" and "will they spot it?" 
I would prefer to point it out.
#getsomeoneelsetoproofread

Omission of small parts of a requirement are particularly annoying. Silly things like overriding a font for one part of the display, adding a fade out to a popup, changing line colours, adding a hover tip, all mostly one line requirements, sometimes only part of a line.
#readthestoriesorrequirementsproperly

Transgression in this environment is the deliberate omission of things. This is not normally done with malice but for speed. Things like adding comments on check in, making links and adding information into the call tracking system are sometimes overlooked with the self-promise of returning to do them later. 
In the past I have tried making comments compulsory on check in in several systems but the speedster will simply add their initials thereby circumnavigating the requirement.
#doitnowsoyoudontforget

The upshot of this kind of thing is that invariably someone has to spend time backtracking to find the information, normally much longer than the original task would have taken, and then the speedster still has to complete the task that was omitted.
#procrastinationisthethiefoftime-edwardyoung

Impatience  is my final subset for speedsters. In a team, people are often called upon to help and mentor others. Speedsters tend to lose patience when helping others, especially if the lesson doesn't seem to be sinking in. The speedster is often thinking about their own task and how long they have been away from it. Some speedsters can become frustrated and snappy, often sarcastic. If you have a speedster like this in your team you need to try and nurture their teaching ability, maybe even try and utilise their skills at specific times when they have finished a task and before starting a new one.
Often a speedster will try to help and be patient and then suddenly they are overcome with a primal urge to take control and speed up the process, the next thing you see is a change of pilot in the programming cockpit. The speedster has decided that the best way to get this piece over the line is to take control of the keyboard. I find that this is not normally the best course of action and the student, mentee or helpee can often fail to learn anything, usually because it is explained or typed at 100 miles an hour, and they feel foolish asking questions. My advice to this type of speedster is
#teacherscandowhatdoerssometimescan't

For most of us, the developments and software that we deal in are not likely to cause massive collateral damage or loss of life, but for some of the teams out there that are working on systems that are safety-related or weapons-related or life-saving, a speedster would probably not make the grade. Diligence, accuracy and precision, when combined, are powerful allies.
#fasterisnotalwaysbetter

Whichever type of speedster you have encountered, he will, no doubt, have a sworn enemy within the department, Mr Old School, whom you shall meet in the next episode. 

I leave you with the following quote:

If you don't have time to do it right, when will you have time to do it over?
John Wooden