Stories about Software


How Do I Find Good Recruiters?

I’ve fallen off my cadence with answering reader questions of late, so I’d like to correct that today.  The question in question is a fairly straight forward one about how to find good recruiters.  This one is actually lifted from a comment some time back that I thought would be more conducive to a post than a comment response.

I would like to ask you how you get to “good” recruiters? My experience with recruiters has been rather negative and I’m wondering if I’m doing something wrong here.

First of all, it’s had to imagine that you’re doing anything wrong.  From the perspective of the job seeker, this is not a difficult transaction.  It’s a lot more likely that the problem lies with the recruiting field in general.

What Makes Them Good?

I’ve had a lot of experience with recruiters, both on the hiring and applicant ends — enough to know well how the game works.  I’ve explained this before, about a year ago.  Short form version is that the typical recruiting firm will take nothing from the applicant, but will take 15 – 20 percent of the first year’s salary from the company that makes the hire.  This cut will be refundable if the applicant leaves within something like six months.  The recruiter’s game is thus to make a match and hope it sticks for 6 months.


Recruiters’ customers are thus hiring companies, and not you.  It’s like Facebook — you’re the product, not the customer.  The majority of recruiters are in the business of selling humans (that happens to be developers) to companies.  The good recruiters are in the business of selling a match to both the human and the company, since this is the best way to build reputation and avoid the six month refund blues.

But most recruiters are not good — they’re shooting for quantity over quality by treating you as the product.

Read More


Learning a Healthy Fear of Legacy Code

Editorial Note: I originally wrote this post for the SmartBear blog.  Check out the original here, at their site.  While you’re at it, have a look around at some of the other authors posting there as well.

The life of a developer would be pretty much nothing but rainbows and unicorns if all we did was add new code to code bases. Imagine a world without maintenance programming, debugging, and scratching your head while squinting at confusing, existing code. It’d be pretty nice, right?

Unicorn with Rainbow

Sadly, we don’t live in that world. The result is that most of our efforts in software development involve a blend of new and old code. We write some new code, stuff it into some existing code, and then try to figure out how the two things will behave together in production. Consequently, both writing and reviewing code necessarily involve a kind of constant, subconscious risk management. “Hmm… should we really touch this code?”

There’s rarely a set of explicit heuristics that guide this decision; it tends to be a matter of feel. It’d be nice if there were a way to be a bit more deliberate about it.

Understanding Legacy Code

“Legacy code” is a rather nebulous term.  Even the wikipedia entry offers multiple, possible meanings.

  • Code that relates to a no-longer supported hardware or software dependency.
  • Code inherited from someone else.
  • Code that’s part of an older version of the software.
  • Code that isn’t covered by automated unit tests.

When I think about what pops into my head when someone says, “legacy code,” none of these things would surprise me.  I could imagine any or all of them being true.  But for me, legacy code really translates to, “code you’re afraid to touch.”

Read More


Code Review and How Enterprises Can Miss The Point

Editorial Note: I originally wrote this post for the SmartBear blog.  You can check out the original here, at their site.  Check out my posts and some of the others and take a look at their products as well while you’re there.

If you work for a smallish company, as part of a modestly sized software development group, the path to a code review policy is likely a short, direct one.  It could be as simple as a respected team member or the manager saying, “hey, let’s start doing code review.”  But whatever the impetus, the participants will tie the process closely enough to the desired outcomes from it to adapt it as needed.

The Capital E Enterprise

At the enterprise level, the calculus changes considerably. And when I say the enterprise, I mean The Enterprise – a size and scope mammoth enough to demand capitalization, even when the rules of grammar do not. These are companies so big that those who work at and have worked at them will assure you that there is simply nothing out there that’s comparable. There are, they will tell you, an entirely different set of rules that apply. And they’re more or less right.

The Enterprise loves structure and hierarchy, usually of the command and control variety. The scale is so immense that the only structure up to the task is a pyramid reminiscent of a military chain of command. The organization lumbers along like a battleship, powerful, majestic, and requiring incredible teamwork, cooperation, and precision to change direction in any way.


In this environment, code review tends to make its way to development team in a very different way and for very different reasons. Of course, even in a massively homogenized environment, one size does not fit all for the development teams. But the cog in a larger machine dynamic makes the following sort of scenario much more likely.

Read More


With Code Metrics, Trends are King

Editorial Note: I originally wrote this post for the NDepend blog.  Head over there to check out the original.  NDepend is a tool that’s absolutely essential to my IT management consulting practice, and it’s a good find for any developer and aspiring architects in particular.  Give it a look.

Here’s a scene that’s familiar to any software developer.  You sit down to work with the source code of a new team or project for the first time, pull the code from source control, build it, and then notice that there are literally thousands of compiler warnings.  You shudder a little and ask someone on the team about it, and he gives a shrug that is equal parts guilty and “whatcha gonna do?”  You shake your head and vow to get the warning situation under control.


If you’re not a software developer, what’s going on here isn’t terribly hard to understand.  The compiler is the thing that turns source code into a program, and the compiler warning is the compiler’s way of saying, “you’ve done something icky here, but not icky enough to be a show-stopping error.”  If the team’s code has thousands of compiler warnings, there’s a strong likelihood that all is not well with the code base.  But getting that figure down to zero warnings is going to be a serious effort.

As I’ve mentioned before on this blog, I consult on different kinds of software projects, many of which are legacy rescue efforts.  So sitting down to a new (to me) code base and seeing thousands of warnings is commonplace for me.  When I point the runaway warnings out to the team, the observation is generally met with apathetic resignation, and when I point it out to management, the observation is generally met with some degree of shock.  “Well, let’s get it fixed, and why is it like this?!”  (Usually, they’re not shocked by the idea that there are warts — they know that based on the software’s performance and defect counts — but by the idea that such a concrete, easily metric exists and is being ignored.)


Read More


What It Really Means to Niche Down

It’s been a rather frustrating few weeks for me, at least in terms of getting things done at home.  One of the cables on my garage door got off of its track somehow, and my time is at a premium, so I set about hiring someone to fix it.  I went onto Angie’s List to see if I could find a contractor that specialized in solving this sort of problem.

Looking for that was probably stupid, however.  I realized my mistake when I got onto the site and did a search for contractors.  I tried searching for terms like “fixes garage doors” and got empty results back.  Stymied, I started looking at contractor profiles and seeing that they really didn’t match in any way even remotely like that.  Here’s what a typical one looked like.

  • Extremely proficient in hammer, table saw, drill driver, and crowbar.
  • 5 years of experience cutting cables, tying knots, and winding metal cables around spring-loaded spools.
  • Limited experience with reciprocating saw and lathe.
  • Regularly determines the correct situation for using a screw versus a nail.
  • Strong preference for DeWalt tools.
  • Capable of carrying tools in a bag, box, or wheeled assembly as dictated by the job.
  • Excellent oral and written communication skills.

*Smacked forehead*  Of course!  I’d been going about this all wrong.  I was looking for an expert to solve my problem, when what I really needed to do was spend a lot of time learning the minutiae of what exact skills, tools, and techniques were necessary to solve that problem.  Once I’d spent a few days doing that, I could then make a still ill-informed guess as to which contractor’s experience might prove relevant to my situation.

That’s exactly what I did, and, though you’d assume this would go well, somehow, it didn’t.  The first guy said he had a lot of experience with steel cables, things that twist, and larger fixtures.  As a bonus, he expressed an intimate knowledge of how water would impact the garage door apparatus.  I had no idea how this was relevant, but he sounded like he knew what he was doing, so I hired him.  After two days, I came and found that he hadn’t fixed the door, but he had installed a sink that was blocking my car in.  When I demanded to know why he’d done this, he confessed that he was really more of a plumber, but that he wanted to learn about garage doors and just assumed that they were more or less the same thing.

Sink in Garage

The next guy didn’t build anything that blocked my car in.  As a matter of fact, he didn’t build anything at all.  He just came in for a few days, laid all kinds of screws, nuts, bolts, and magnets on the ground, and then proceeded to arrange, re-arrange, and re-re-arrange them ad nauseum.  Each time he’d do it, he’d squint at the broken garage door apparatus and mutter to himself about it being important to have the right organizational framework to tackle this problem.  When I finally let him go after a few days, he’d managed to build a small pyramid out of 2 inch screws.  I’m not going to lie; it was impressive.  But it was also useless.

Knowing that this was stupid, I did what any reasonable person would do.  Instead of hiring someone to solve my problem, I hired someone that could both understand what I was trying to do and who could also make sense of all of these contractor profiles.  All it cost me was an extra 20% of the job total.

Read More