The Professional Employer

Robert C. "Uncle Bob" Martin is, let’s say, notorious for his views on what it means to be a professional software developer. Bob has dedicated his life to being the best he can possibly be at a career he is passionate about, and that is admirable. But his position on certain aspects of a career in software can be a little extreme. I’m writing this because of a discussion on Twitter around a piece he wrote for O’Reilly’s 97 Things, wherein the first (and by inference most important) point is that you, as a developer, must take personal and total responsibility for your continuous professional development.

If you are a professional, then you are responsible for your own career. You are responsible for reading and learning. You are responsible for staying up-to-date with the industry and the technology. Too many programmers feel that it is their employer’s job to train them. Sorry, this is just dead wrong. Do you think doctors behave that way? Do you think lawyers behave that way? No, they train themselves on their own time, and their own nickel. They spend much of their off-hours reading journals and decisions. They keep themselves up-to-date. And so must we. The relationship between you and your employer is spelled out nicely in your employment contract. In short: They promise to pay you, and you promise to do a good job.

~ Robert C. Martin, The Professional Programmer

When I first read that, I instinctively agreed with it because I, like Bob, am basically addicted to coding and can’t think of a better way to spend my time.

I’m not about to completely reverse that position. I do believe that the ultimate responsibility for keeping your skills sharp and up-to-date lies with you. But Bob’s take on the issue effectively absolves employers of any responsibility, and that is just plain wrong. Partly because it is unfair to the employees, but also because it is bad business.

What is an unprofessional employer?

Let’s say you are a medium-sized company, whose main project is a Windows Forms application written in VB.NET, ported from Visual Basic 6.0 about 10 years ago. At the time .NET appeared, you grudgingly organised some classroom training for your development team to help them make the transition from VB to VB.NET, but since then, you’ve essentially left them to get on with it. Your app is probably still running on .NET 2.0, and your developers are maintaining it with Visual Studio 2005, unadorned with productivity plug-ins and with no hint of automated testing. You don’t invest anything in training your developers, or even in encouraging them to learn new things. In fact, you go out of your way to make it hard for them to learn, by believing in 100% “utilisation” which actually forces people to work 9 hours a day so they can minutely account for the 8 you pay them for, and means they’re utterly banjaxed by the time they get home and can barely shift themselves off the sofa.

What happens next?

Out of a team of six to eight developers, you may have one, possibly even two, who are passionate enough about programming to be doing it in their spare time, learning new things, new technologies, new techniques. Let’s say you’re lucky, and call it two. Those two devs know enough to do a complete rewrite of your core product that would bring it bang up to date and give you the edge over that other company that’s just launched a web version of their app. But they can’t do that, because the rest of the team don’t have the relevant skills. In fact, none of the cool stuff these devs have learnt or taught themselves in their own time can actually be used in your product, because the other developers wouldn’t be able to maintain it. Of course, what’s actually happening is that those two devs are using this stuff they know anyway, whenever they can get away with it, and the other developers let them and just ignore those bits of the code. When those two enthusiastic, motivated developers finally get ground right down, wise up and dump you for a better job at a better company, you’re basically screwed. You might be able to recruit new people with the relevant skills – a proper understanding of JavaScript, say, or some functional programming knowledge – but they’ll never get up to speed with your codebase, and they won’t have any of the domain, business or market knowledge that just walked out of your front door.

And really, if they’re remotely competent, why would they want to work on your crappy VB.NET Windows Forms product?

So now you’ve got an ageing application with, effectively, chunks of magic dotted around the codebase. You’ve also got a team of increasingly stressed and unhappy developers, who really just want to do a good job and then go home at the end of the day, but who find themselves copying and pasting bits of magic and cargo-cult programming to stop your house of tatty cards from falling down. It’s a losing battle, though. They know it, you know it, and your customers know it too. They’re looking back at the market, and they’re looking at that competitor of yours who launched the web version of the app, and hey, would you look at that, the six month embargo has passed and one of your old lead developers is working there now. Ouch.

At this point, there’s nothing you can do. You just go into fire-fighting support and maintenance mode, with a dwindling customer base, until the ends no longer meet and you turn off those Pentium-based tin cans you call "developer workstations" and grab whatever stationery you can on the way to the recruitment agency. The last two or three developers left when the lights go out might finally wake up and get themselves at least up to speed with ASP.NET 4.5, or they might just find a job maintaining a legacy app in a large enterprise somewhere.

Where did it all go wrong?

With you, in a nutshell. You don’t understand software development. You think these interchangeable human resource units just “know how to program”; you don’t understand that what that means changes on an a regular basis. Hey, you’ve had the last eight versions of Microsoft Office and you can’t see any difference from one to the next, so when successive versions of Visual Studio come out you assume it’s the same deal. When they tell you it’s going to take two weeks to get the code working in the new version, you say “hell with that, we’ll stay on the old one.” When someone asks if they can take a paid day to travel to a free conference, you tell them it’s impossible with the current deadline, but next time, sure thing, buddy! There’ll be all kinds of jam tomorrow, just as soon as you magically get us out of the jam we’re in now.

You’re an unprofessional employer, and you deserve everything you get.

What is a Professional Employer?

The most important aspect of being a professional employer of software developers is that you should treat them with respect. If you’re a software company, these people are pretty much the alpha and the omega. At the end of the day, if they suck, you suck. Yes, you need sales and marketing and accounts and everything else, but all that exists around the development of the software; that’s the product, the thing that gives your company its value.

If you’re an enterprise with internal development resource, then you’re entrusting the smooth running of your organisation to your developers. If they suck, your organisation won’t function properly and it will lose money.

So respect them; nurture them; give them the time and support they need to stay, if not at the top of their game, at least no further from the top on a year-by-year reckoning. Here are some things you can do to keep your half of a learning bargain with your developers:

  • That 20% time thing that Google do? They don’t do that to be nice. They do it because it works for the company, and not just as a recruitment PR exercise. The stuff their employees do during that 20% time is all new and exciting and learning new things. OK, you’re not Google, you might not be able to do 20% time, but how about 10%? Hell, to start off with, why not just set aside the last Friday of every month for people to work on their own things? If nothing else, it gives those two devs who’ve been teaching themselves new stuff a chance to pass that knowledge on to the rest of the team.
  • Pay for every single one of your developers to attend one conference every year. What this means is going to vary from company to company. Ideally, you’ll send them to BUILD or VS Live or RubyConf or something, but if the budget won’t stretch to that, you should pay at least their expenses, and if possible a day’s salary, to attend a free conference (like the Developer Developer Developer days in the UK). (Why the day’s salary, if it’s a weekend event? Because that extra money helps to persuade the developer’s other half that it’s a weekend day well spent.)
  • Include a subscription to an online webcast training resource, or Safari Online, as part of your developers’ package. It’s a few bucks a month, and by the time you haven’t paid the tax on it, it’s practically nothing.
  • When you’re devising your performance metrics for annual reviews, add some bonus-related incentive in there for personal development. Points for blogging, or attending user group evenings, or giving a brown-bag presentation on a new technology on that last Friday of the month we talked about.
  • If you and your developers “just don’t have the bandwidth” for these activities, because everybody is always flat-out, private-parts-to-the-wall panicking to try and keep the bug list count down in double figures, then hire some more developers*.
  • While I’m at it, those Pentium-based “developer workstations” with the 15” monitors, the ones you got a great deal on from your Account Manager at Dell? They’re shit; they’re an insult; you might as well give your developers quills and cuffs and an extra lump of coal on Christmas. You don’t have to buy everyone a Mac Pro, but as a rough rule of thumb, you should spend at least 5% of a developer’s salary on their workstation. And no, that doesn’t mean take that 5% off their salary. Seriously: don’t make me come round there.

* Yes, I know, hiring more developers is not always the answer, but when you’ve got a team of three or four developers supporting a combined user-base numbering in the tens of thousands, maybe it is.


    In summary, then, yes, we as professional software developers must take the ultimate responsibility for our careers, but if companies want professional software developers to work for them, then they need to take some responsibility too.
Share on facebook
Share on google
Share on twitter
Share on linkedin


Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.