Subscribe / Unsubscribe Enewsletters | Login | Register

Pencil Banner

How to go from coder to consultant

Matthew Heusser | Sept. 11, 2015
If you've had it with office life – or office life has had it with you – maybe it’s time to become an IT consultant. Here’s how to avoid the pitfalls along your path…and some tips to get started.

business meeting people silhouettes
Credit: Vector Open Stock

As a writer for and other publications, my job is to tell the story of other people. Yet over the past few months, readers have been asking for my story – how I went from contributor to consultant, including lessons learned along the way. 

As a consultant, I'm reluctant to do this; every time the focus has shifted away from the client to me, things start to get odd. On top of that, advice-about-advice always reads a bit "meta" for my taste and can sometimes make the giver of such advice come off like a snake oil salesman. 

When the people at Software Testing Conference Atlanta asked me to do a talk on “From box-checker to trusted advisor,” I finally relented, and decided to pull the curtain back a bit, talk about the difference between the two roles, how to change your perception in the workplace and, yes, a bit of my story. 

Roles, perceptions and reality 

If you were trying to run a company in 1900, you might try to break the work down into easily described pieces that require less skill. That makes the work predictable, the workers cheap and keeps the unions at bay. McDonalds, Walmart, and Ford Motor Company are famous for having great success with this idea of "separating the worker from the work," which originated from Frederick Winslow Taylor’s famous turn-of-the-century treatise The Principles of Scientific Management. The basic concept is to make an assembly line out of the work, using terms like stable, predictable and repeatable, and removing the need for skill, expertise or experience. 

Except we know that IT doesn't work that way. It doesn't even appear to work that way on the surface. Most companies hire by pursuing resumes of the perfect candidate, with, for instance, exactly 3-5 years of Ruby on Rails experience using PostGres, with specific lists of JavaScript libraries on a particular flavor on Linux. It’s as if expertise can only exist for hard, technical skills. The more senior you are, the less likely you are to fit in just the right checkboxes, making changing jobs harder. 

There are other kinds of expertise. 

Clean code, design patterns and awareness of technical debt – these things apply to every programming language. There is also context. If you take a team of maintenance programmers and put them on a new product, they'll be more likely to fail. Conversely, a team that’s never had to maintain a codebase can make a maintenance project a mess. The awareness of the difference – of what good code looks like – requires a kind of expertise. It’s a kind of knowledge that defies a simple list. It doesn’t show up in simple programming exercises like FizzBuzz and certainly isn't in the HR manual. Yet this kind of expertise, of how to do the job well, makes all the difference in human performance. Alistair Cockburn’s article, “Characterizing people as non-linear, first-order components in software development,“ may have a fancy title, but what it says is correct: Passionate, learning/growing, competent people do exponentially better than mediocre yet qualified staff. 


1  2  3  4  5  Next Page 

Sign up for Computerworld eNewsletters.