Craft code is one of the hardest deliverables that any client and provider will ever negotiate and almost always ends up with mutual compromises. Before we get into why this is, first take a look at a story:
Jacob was frustrated. His customer clearly didn’t understand the process and kept asking for contradictory things. He set out to build the requested tool shaking his head at the questions the customer had asked him, “If I just get two instead of four it’s half the work and half price right?”, “It has to be very light but withstand a lot of use”, “Can I get that double bladed? That shouldn’t cost much extra right?”. Of course when Jacob told the customer that it would be done next week the customer tried to negotiate with him to deliver it the next morning.
As Jacob shoveled coals into the fire he marveled at the discussion. Heating and tempering metal took the time that it took. It couldn’t be rushed, at least not if you ever wanted to ever use the ax that he was crafting. Customers never think about the setup time either. They get all excited by the sight of sparks flying and assume that is the real work. But to even get that far a thousand details had to be considered: what temperature to heat the metal to, the exact places to hammer the metal so that it would not warp, the quantity and quality of the metal that Jacob was now selecting.
“Ah, this ingot will be just about right! Strong enough to hold up to years of use but light enough that an able bodied man should be able to work the whole day without exhaustion.”
It was a delicate balance but Jacob had repaired many an ax head and had learned how thin he could make the blade before it bent.
How this applies to “Craft Code”
Developing computer software is the process of building interfaces between people and the world. The science that gave us the computer has given way to the craft of building increasingly ergonomic tools. Like the blacksmith, the software developer must learn how to shape the raw material into something made for humans. Nothing is ever simple and reality tends to be inconvenient. Perhaps it makes more sense to draw from the traditions of craftsmen instead of factories and scientists.
In a world that wants to eat its cake and have it too, the usefulness of a piece of software often comes down to how well it strikes a balance between between competing priorities. A feature that adds new capabilities may also make the app harder to use. Day to day, a developer must make decisions on limited information that can have large impacts to development time and the eventual usefulness of the product. The decision to go with one framework over another may make one feature set trivial and another painful. More often, there is more than one possible solution but not a single “right” answer. Each solution represents a slightly different set of tradeoffs. The complexity must exist; will we handle it in this object or in that one?
Concluding the story
The concepts and syntax of programing can certainly be taught through formal education. The deep understanding of tradeoffs can only come from experience, though. Some experience can be shared; an apprentice blacksmith may be guided in her craft by the master blacksmith who draws from the powerful ability of the brain to extract patterns from memories. It critical that the apprentice be able to observe the outcomes of her decisions. It is also beneficial to struggle through the consequences of someone else’s choices. Siloed experience leads to naive decision making. Real world examples of best practices combined with mentorship providing insights at key moments provides the shortest path to becoming a master developer.
Let us know what your experience has been like in the comments below or feel free to contact us.