Pet Peeves

The following is a list of my top five pet peeves that I encounter in the software engineering field. It is meant to be a completely childish exercise in vetting frustrations with things I encounter on a weekly, if not daily basis. Without further ado:

#1) Learned helplessness - or "I'm too lazy and/or selfish to take five minutes to try and find the answer myself or learn to do it myself.

This takes the cake, in my opinion, as the single largest time suck any software engineer faces when working collaboratively with a team that is guilty of this foul. It is also probably my biggest pet peeve not only in software engineering but in any facet of life - I despise it when perfectly capable people resign themselves to asking for someone's help or advice without first having tried to do something or figure something out themselves. In our field, it generally takes 5-10 minutes tops to write a test case to answer a question or even less time to determine if there is documentation to answer it through this wonderful invention called google. If one can't find the answer in that amount of time by themselves, then it's time to ask someone. People learn more by finding the answer themselves than they ever will by having fed by others - and in doing so they don't risk interrupting the precious flow of their co-workers with questions they haven't bothered finding the answer for. Doing so is a selfish act and completely disrespectful of others who have strived to teach themselves so much.

#2) Anything involving a Microsoft product.
Yes, I'm quite biased - but for a good reason. Having to deal with anything Microsoft related when working as either a developer of applications or working with applications in a server deployment is just an absolute pain. For starters, a software engineer worth his or her salt will spend a sizable amount of time in a console while doing their work. Unfortunately for folks stuck administrating and or using windows machines, you have to install a combination of cygwin + Console just to have a halfway decent console experience... and even that experience is half-baked.

Furthermore, most applications and tools from Microsoft assume you are a complete buffoon and offer you only wizards and menus to configure your applications. These might be great when initially setting up an application but they often come with absolutely no way to configure them outside of said wizards and menus - thus meaning it is near impossible to script and automate changes to them.

Altogether, the user experience is just awful, full of interruptions, and a pain to do anything quickly in. The only way I could justify owning a dedicated Windows machine again is if I were to get back in to full time gaming... and even that is changing now with things like crossover.

#3) Calling directories a "folder"
This one annoys me to no end, but it's hard to explain why. If you are a non-technical end user, this is perfectly excusable. The whole folder/desktop terminology and graphical presentation was created as an analogy to make computers easier to use for the masses. However, if you are an engineer, you obviously don't fit that bill. So call the thing by its real name - they are directories, not folders.

I equate this to my mother-in-law, who can't name a single position on a football outside of quarterback, calling a 4-3 defense in football "a bunch of guys trying to tackle the ball". That's excusable because she has never played and doesn't know the lingo. However, if you were my teammate on the offensive line and you called a 1 technique simply a "Nose Tackle" when trying to identify alignment, then you ought to be smacked upside the head.

For those of you who don't know, what typically gets referred to as a Nose Tackle can be aligned in about 5 different positions in a down position (2, 2i, 1, shade, 0 - all of which make a world of difference), so simply calling that person a Nose Tackle is horribly uninformative, misleading, and just wrong. And for that matter, so is calling a directory a folder.

#4) Meetings that include brainstorming but with no actionable items or plan associated

See here for a recent diatribe against this.

#5) Using Email to Debug and Collaborate on Work

Email might be the single worst communication method possible to debug and resolve problems - outside of using a conference call with no textual methods to aid. Yet, pretty much every shop I've ever worked in (aside from my present shop) uses it as the primary means in which to collaborate. Email is intrusive, asynchronous, not fit for working on code, forced upon unwilling audiences, and encourages grandstanding and long drawn out replies. Really, what most folks need is a synchronous pub/sub communication mechanism, like irc.

See here also for a previous post on my adoration of irc for teams.