The Mechanics Of Code
Out Of Date Warning
Languages change. Perspectives are different. Ideas move on. This article was published on February 16, 2012 which is more than two years ago. It may be out of date. You should verify that technical information in this article is still current before relying upon it for your own purposes.
Since the dawn of programming, programmers have attempted to define their industry, often by using outside industries for comparison. This can be traced back to the fact that programming itself is unique: it’s unlike any field in existence. Most programmers hate being called “coders”: it seems pedestrian, somehow beneath what we do. Many times we like to call ourselves “engineers”, but this title doesn’t really fit. Though we do engineer things on a regular basis, engineering is a field in which the time to completion is relatively set by physical laws, not the complexity of the job.
As I spent time this past week watching my mechanic work, it occurred to me that much of what I do is act as a mechanic for my software. My job is to inspect, disassemble, replace bad parts, lubricate, make faster/more efficient/less squeaky, and to maintain software that has largely already been written, engineered, and released. There’s the occasional new feature to be developed, and this is surely the engineering portion of my job, but 70% of the time my work revolves around being a software mechanic.
Thinking on the common issues faced in software development, it seems that a mechanic fits better than an engineer in other ways, too. For example, a mechanic must be able to take symptoms of a problem and troubleshoot what’s wrong; an engineer rarely does. A mechanic must be able to provide an estimate of the work to be completed and often the cost; this is a more rare thing in the engineering field. A mechanic is expected to make it work, make it beautiful and make it easy to use all at the same time – few of us would accept a radio that worked but was ugly or a starter that functioned but required a complicated set of steps to use. Engineers get to stand behind what must be, and let others (architects) make it beautiful.
My intent is neither to elevate mechanics or disparage engineers; their functions are simply different. The software developer must be both at different times, which complicates things. And though mechanics are often thought of at a lower station of life than an engineer or architect, the reality is they serve an extraordinarily important function.
I’m proud to be a Software Mechanic. Are you?
Learning design patterns doesn't have to suck.
Design patterns open a whole new world of possibilities. So why are you avoiding them? This brand new book will help you finally understand these wonderful programming techiques!Learn design patterns TODAY »