How to Hire Developers Who Don’t Suck Using This Crappy List

You’ve just had to escort Steve out the door. He was your most recent hiring flub. That poor schmuck. But what went wrong? He had the 4.5 years of .NET 4.5 and even a master’s degree in software engineering.

He seemed like a perfect fit. He matched all the main criteria that you were looking for. He WAS the job description. You recall telling your colleagues that you found the elusive purple squirrel. Only you didn’t because he was a major dud, right?

He thought there was nothing wrong with writing .NET code using Notepad — no need for IntelliSense, he would say. He also loved picking fights with his coworkers. That and he liked to show up around noon, so he wouldn’t miss lunch. He was also the guy that when your manager ordered pizza insisted all the pizzas only have tomato sauce for a topping.

He was vegan and was trying to force his dietary choices on everyone else. He also had a bad peanut allergy, so if you opened a little bag of peanuts, despite being 10 cubes down from him, that you got from your most recent Delta Air Lines travels, he would run to HR to complain. He also thought that Putin taking over Crimea was awesome and said it was about time. That asshat he was.

Well let’s try not to make that mistake again. But how?
Here are the biggest mistakes I see managers make time and time again.

  1. First mistake is hiring based on .NET or Java trivia — like .NET 4.5.2 specifics, etc. I’m not suggesting experience in these technologies equates to trivia, yet too much focus on specific technologies (especially specific versions of the framework, etc.) will ensure you will not find the best candidate. I think there are more important things you should be focusing on. Programming is a profession, not a vocation. If they have a couple of years of somewhat recent .NET experience, that should be good enough for most .NET related jobs.
  2. Next up is putting too much emphasis on education. Having an MS or PhD might correlate to a stronger candidate, but too much emphasis on fancy degrees means you are overlooking what is most important. (This is coming from someone with a master’s.)
  3. Then there is the fixed experience bracket mistake. Often the typical 3-4 or 4-5 year experience bracket. Most of these brackets are arbitrary and only help to exclude good candidates that have less or more experience. If you use brackets, just be very flexible with them.
  4. Lastly, Similar to item 3 above, the 10+ year experience myth. Some fields require 10+ years of experience before true proficiency but many don’t. I’ve seen too many managers focus on this when they are looking for a high-caliber person.

So what should you be looking for?

  1. A passion for developing software. How do you measure it? It oozes out of their pores. This is the most important criterion above all others. It’s only a qualitative feature, which is why many people neglect this trait. Look for this during a phone screening.
  2. A portfolio of code, usually open source, on GitHub or a similar code-sharing service. Is their code any good? Have one of your top team members review it first before making the call.
  3. Does the candidate have a programming blog? This isn’t required, but it correlates rather highly with a candidate who is passionate about software — a very good thing. Are their ideas good? Are their articles well written? What better way to get some insight into their writing skills, too.
  4. A history of getting things done. The resume usually demonstrates this well.
  5. Upward career growth. The resume usually also demonstrates this well.
  6. Past vetting at top schools or firms. Top schools and companies tend to be more selective, so if they made it past the vetting process of such a school or company, that’s a good thing.
  7. Good social and communication skills. Don’t confuse introversion with poor social or communications skills. You don’t have to be an extrovert (note, I actually don’t buy into these labels) to be a good programmer.

Also make sure to do a phone, FaceTime or Skype screening. During the phone screen, look for passion and strong communication skills. And make sure to be skeptical of a job hopper. Some job hopping is OK, but too much is a yellow, if not red flag.

However, don’t worry about gaps in employment. Yes, if excessive, that would be a concern, but why penalize a person who took care of a sick parent, spouse or child, or their own health issues? Maybe they were in grad school or traveling and learning about other cultures.

Those should be considered good things. It’s called a sabbatical. Sometimes this is a must. This is especially true considering the long recession the world has seen the last few years — the so-called Great Recession.

Programmers are a unique breed. I would surmise the average programmer has well above an average IQ. Finding the right candidate isn’t easy, but hopefully using these tips will help you when you’re considering candidates in the future. Now there will be no more Steves in your future. Well, we can only hope.


You Do Bug Tracking, Right? (…or Reward Bug Entries with a Banana)

Let me start out by saying I don’t like bananas, but I noticed Delta Air Lines often rewards their business-class customers with a banana towards the end of the flight. Well, actually it’s a basket of things you can pick from, but one item that often stands out to me is the bright yellow banana.

I think this is Delta Air Lines’ way of thanking its customers for not being “pains in the butt” or having flight rage and causing the flight to get diverted. Here you go. You were a compliant high-paying passenger. Now here is your banana. I guess scientists do consider us to be in the primate family.

In particular of the ape variety, so maybe that’s a smart move on their part. My wife, when we travel on vacation, always goes for the banana. I get anything other than the banana.  Well, getting your developers to use a bug tracking tool is like getting your kids to eat their peas — or me to eat a banana.

Nobody likes entering bugs or the more formal term we used in grad school: defects. You may hear some people refer to them as issues. That sounds almost pleasurable. Well, isn’t that a common thing a wife might say to her husband when he leaves the seat up. We have an issue! Or are husbands suppose to leave it down? I can never remember.

Nope, bug tracking just isn’t all that popular. Well, maybe you got that one odd guy that some groups have. He loves entering bugs or “defects” into the tool. He also loves assigning them to all the teammates he doesn’t like. He doesn’t like many of his teammates, mind you. He’s not a very popular guy in the group.

What technically is the “right” way to do bug track’in? Do you let the stooge enter it. Should all bugs only be entered by the test group. One really old guy who’s been at the company forever. He’s the only one that is trusted to use the tool or knows how to use it. And, you have to give him an index card with the bug on it per his specifications. He later “keys” it into the system.

This is a bug system that runs on an IBM AS/400. He actually uses the term “key” it in. Thank god he doesn’t punch it in with punch cards or paper tape. But before he keys it in, he has an assistant, who is a scribe, transcribe the index card to another format that is easier for the test guy to read. He has this intermediary, the scribe, because he prefers reading the handwriting of the scribe as the scribe has excellent cursive.

I shouldn’t call him a stooge though should I? You know the guy that is overzealous with entering bugs. At least he enters bugs. Many people will see a bug and pretend they really didn’t see it for fear that they will have to go into that darn bug tracking database.

Joe will say to his coworker Mary, “Mary, you didn’t see nothin’ didgya?” She responds with, “I saw nothin’.” They give each other the pinky handshake and then hit the showers go to lunch.

I haven’t met a bug tracking or database system I’ve liked. Most just feel inadequate, like a PB&J without the J, or are just a pain in the keister — and not the cute Kim Kardashian kind either. Why? Well, for starters, most people aren’t trained on the tool.

Second, there tends to not be a good method or standard developed in the department on how to enter one of those pesky bugs. As an aside, should a really bad bug be called a cockroach? If so, I had one of those in a rather nice NY hotel last year. I hid while my wife killed it — not really, we wouldn’t hurt a poor cockroach.

He was released back to nature. It was 2-3 inches long. Anyway, do you let the stooge, the hyper-vigilant guy, actually “assign” them to his coworkers?

Well, the tool is not all bad. It does function as a nice starting place for a project meeting. Yes, a guy with a master’s in software engineering — and a software management consultant — recommending a software project meeting. Who would have thunk.

Well, I’ve worked at firms that just dump the bugs, or cockroaches, into a bug tracking tool and it’s as if they went into a black hole. Has Sir Steven Hawking retracted the existence of black holes? No, but there was something he was retracting regarding them — maybe is was that light couldn’t escape? I’ll look into that later…. Anyway.

What I recommend and have advocated for clients and former employers is simple. Well, actually, usually it starts with me telling them to put out that funny looking little cigarette because we’ve got work to do.

My pretend former client liked to “relax” and self-medicate and needed the marijuana for his aliment: an upset stomach from eating too many munchies (he lived in one of those modern states that let you do anything you want) — this wasn’t flyover country. OK, for real, use the tool to capture the bug. Be as specific as possible. None of these weak bug entries like the following: “Darn thing didn’t work when I pressed a button.”

Which button? What didn’t work? See what I mean. I’ll admit even a really weak entry as I described is better than nothing though. At least someone could go badger the person who entered it and ask for more information.

During the project meeting, the manager can turn up the heat on the employee and get more information. I’m not recommending the manager publicly flog or shame the employee, but it could be gently used to show why we need more information — a teaching moment.

There is a lot of oral traditional and history with teams that have worked a long time together with few new entrants. However, I recommended some standards be documented for using the tool and entering a defect. The standard can be helpful to a newer recruit and can also serve to document what you are currently doing.

This can also be very handy if an internal or external auditor is expected to make a visit. One less thing to think about before the auditor arrives with his clipboard and gruff demeanor. No amount of fancy dinners and martinis will get you a passed audit from this guy.

The act of writing a standards document will ferret out best practices, too. Often the document isn’t always so useful in and of itself but serves as a record of what decisions the team has decided on. I don’t speak “Agile,” per se — I do advocate for agile processes when they apply, however.

I don’t speak XP/Extreme programming either, or any of today’s newfangled and “improved” process methodologies. If you want to call process improvement a sexy thing like Agile or Scrum, go for it. I kind of think the software process community is overloaded with acronyms.

If you are doing webapps, mobile or anything similar and your strongest value is being quick to change and quick to deliver — release early and release often — and want to lean on an agile process, great. If you like having morning meetings where the group stands on one foot (I’ll call this Yoga Scrum), fine. I advocate pragmatic and proven practices — call them common sense approaches.

Well, after you get that bug in the data base with lots of specifics such as how to reproduce it, etc., it is time to hold that weekly meeting to go over the entries with your team. During that meeting, you can help assign priority and responsibility or defer it for a future release.

So to recap,

  1. Find a good bug tracking tool.
  2. Enter detailed bugs (the more specific the better).
  3. Have weekly meetings to discuss the bugs, prioritize and assign responsibility, etc.
  4. Rinse and repeat.

So, no, I don’t think you need to reward bug entries with a banana, but getting your team trained and documenting effective processes and procedures can go a long way to getting bugs entered and tracked effectively.

Why SQA Groups Need to Go Back to the Name Drawing Board

Does your company use the SQA (Software Quality Assurance) term to refer to the test or so-called software quality assurance group? If so someone screwed up.

Your mom probably “assured” you growing up that you were going to be amazing? Right? Did you turn out amazing? Well, she wanted you to be amazing and what that meant to her was rich, so you could buy her the largest house on the block. In that case, her attempt to assure you was more or less wishful thinking or a hope and a dream.

It only seems fair considering you had that oversized cranium with that huge brain of yours she had to squeeze out of her. (Programmers tend to be pretty smart with big brains.) She’s never forgiven you since, has she?

So, SQA is a misnomer because no business leader would only want to be “assured” that their software was good — i.e., high quality or passed etc. The proper term is Software Quality Ensure-(ance) (SQE). (Note: ensure doesn’t have the same noun form as assurance, so the group should probably be called the Ensurers of Software Quality — ESQ.) So you could tell people you work in the ESQ group — funny.

You want the group to ensure the quality of the software — that it meets specs/passes, etc. To ensure is to guarantee. In this case, high quality software will be delivered to your customers. To assure means to declare earnestly — to tell positively. This is much different from “to guarantee.”

A salesman “assures” you his company offers great post-sales service. “No worries,” he says. What you really want is for him to ensure it — to guarantee it, and in writing!