Credit: Vector Open Stock
As a writer for CIO.com 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.
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.
Sign up for Computerworld eNewsletters.