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.


  1. Umm, okay, but you’re kind of missing the high-expense things like conference attendance. I can pay for all the books and computer hardware I need, but what about a conference fee+accomodation+1st class transatlantic tickets?

    • Dmitri, the cost of that trans-atlantic conference is much cheaper than the cost of a recruitment cycle because you’ve just lost a developer.

      The difference is that you have to pay for the conference on a known schedule. You’ll pay much more for the loss of a good developer at a time that is not of your choosing. Add to that the reduced productivity while you are waiting for the replacement to arrive and get up to speed.

  2. I absolutely agree with you 100%. And you just called my boss a dipshit 🙂

  3. Excellent points (and fun to read!). I don’t find contradiction between Uncle Bob’s quote and what you’ve written — I fully agree with both of you. But I agree that Bob’s stuff could have been abused by unprofessional employers, and I like the way you tell the other side of the story.

  4. God says, “All-mighty -breakers doubted house sharpen preventedst hasten withering recent thirsts Whatsoever defection incommutable stretching seducing emotions Minerva fuller uttereth fools
    royalties “

  5. REDACTED. Enjoyable post other than that.

  6. Mark – you’re *so* talking to me here with this post… I work at an awesome company, but my current role is to go to a not-so-awesome company and help introduce new development practices. What you describe here just echoes that office…

  7. Mark – Agree with you. I can see *so* many points which apply to my previous employer… Result: it’s was liquidated 2 year ago!

  8. ferventcoder says:

    This is awesome!

  9. My big fear as a developer who recently moved into senior management is to become a complete tool, like you’ve described here. I think I almost did it as well – close call. Thanks for the nudge!

  10. calvinallen1983 says:

    Wow, did you work at my _last_ employer at some point?

  11. I think Uncle Bob is right in his message to developers and you are right in your message to employers. It’s like telling pedestrians that cars have right of way while also telling drivers that pedestrians have right of way – it theoretically makes an accident less likely.

    Developers should definitely keep their skills sharp, otherwise how will they get a better job. Employers should train people, otherwise how do they get a better product!

    Thanks for the great article.

    • I wish to express my respect for your kineahe-rtddness in support of those people that have the need for assistance with this important theme. Your personal commitment to getting the message all over was definitely powerful and has surely permitted some individuals just like me to arrive at their desired goals. Your own informative tutorial can mean much to me and especially to my office colleagues. With thanks; from all of us.

    • Rabbim sen herseyin dogrusunu biliyorsun.beni temize cıkar .bilip bilmeden iÅŸledigim günahlarımı affet.kalbime veridigin bu aÅŸkın karsılıgı yoksa kurtar benı bu azaptan.haksızlıga ugramaktan bıktım.isyan etmiyorum allahım ama dayanack gücüm kalmadı.caresizlere yardım eyleyen allahım yardımına muhtacım. Kardeslerim benim ögüte duaya ihtiyacım var sesimi duyan bana yardım etsin

    • Normally I don’t read post on blogs, but I wish to say that this write-up very forced me to try and do it! Your writing style has been surprised me. Thanks, quite nice article.

  12. DotNetRockStar says:

    Winning. Great post. 100% correct

  13. Thanks. I really like your post. It is the summary of my career, and for a lot of dev out there, I think. Unfortunately, as a dev, the more I study, the more my employeers tends to deliberately IGNORE new ideas or refactoring. In other words, it seems to me as a PRECISE CHOICE to keep the level as low as possible. Many thanks from a Heretic Dev.

  14. Ismail Mayat says:

    Excellent post. In the past have worked in slave camps with screw you attitude to devs. Thankfully my current employer is a professional employer!

  15. building failure says:

    @GrowingApps because they know that if they take these ideas on board, you’ll be more valuable, and thus they’ll have to pay you more. You’ll be better trained, but it won’t cost them a cent to maintain their existing mess rather than let you clean it up. It’s a short-term, selfish view, but it’s the way they think. The dollar in their hand right now is more valuable than a killer application making ten dollars 6 months from now. And they can always hire more developers, who have up-skilled themselves, right? Why should they have to pay for your training and improvement when they can hire someone else who already has it?

  16. In my professional career spanning decades, I have rarely found an employer that was willing to invest in employee training and/or employee time spent on-the-job mastering new technologies. I have seen job postings that specifically stated that employees were expected to stay current on new technologies on their own time. I even had one former employer specifically state that policy at a company meeting, when a fellow employee pointed out that a balanced life included time with one’s family. As the CEO arrogantly said to the entire workforce, “What other choice do you have, if you want to keep your job?”. That company is no longer in business.

    What I repeatedly see in current job postings is that almost all employers do not want to pay for your learning curve on any subject. They want your current employer to pay for it so they can steal you and avoid the time and expense of training.

    Lee Crain

  17. Unprofessional employers always have an excuse for not funding training and development. Most often it is because they view staff development as an expense rather than an investment. Your choice is to take it on yourself or move on. What has worked for me is doing consulting work on the side where I could learn new technologies and tools that my employer would not pay me to learn. The downside is, of course, that my employer gets the benefits of my new skills for free. Remember Joel Sposky who used to write the Joel on Software blog? I remember him remarking once that he was astinished at how many really good developers worked for s#!thole companies. I thought, “Well at least now I know I am not alone.”

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: