Successive Approximations

Craft vs Trade - Programming

Craft vs Trade - Programming

I was having a conversation with a friend just starting out, later in life, on his journey as a software developer, and we were talking about code schools and college degrees.

There seems to be a paradox, that some companies hire code school graduates and have success when others don't, while at the same time not all companies have success hiring junior developers straight out of college. So what determines success?

One model that might explain this apparent paradox is that some programming is a craft and some is a trade. Some programming is like being an electrician: you can go to a trade school, learn a certain set of skills, and deploy them repeatedly in slightly different configurations.

On the other hand, some programming might be more like a craft, say architecture, where every project is unique. Each project has a unique set of constraints that the architect has to balance. Every project involves some new technique or material or process that the architect has never used before but uses their judgement to say should be a good fit for the project. This requires learning from the case studies put out by other architects, keeping up with developments in materials and techniques, and so on.

To wit, you wouldn't want the architect (or even a BS in Electrical Engineering) trying to run the wiring for an entire street of houses by the end of the week. You want the guy who knows the job, knows his tools, and knows when to get shit done.

Programming has facets of both. Some projects skew more one way than another. Some developers skew more one way than another. Bad things happen when just treat them as though there's no differences.

Ben Berry

I don't have comments on my posts, but if you want to reach me, email me at my first name at