Code flows effortlessly from your nimble fingers, like fine cloth from a loom. Your face is serene, focused, content. Suddenly, a wrinkle appears in your brow, breaking that pleasant mask of serenity. The frown deepens. “That can’t be right…” What happened? A bug! A hairy bug lurks fiendishly somewhere in that elegant tapestry of code love. How did the bug slip past you? You were so careful! A frustrated hour passes, then two. You comb through each strand of code, retrace your steps through the intricate lattice of if, when, and for…
We sink so much time into the deep pit that is debugging. Yet for all the time we spend on it, there is surprisingly little literature written on the subject. A notable exception is Debugging: The 9 Indispensable Rules for Finding Even the Most Elusive Software and Hardware Problems, by David J Agans.
Deep work – it’s where the right stuff gets done. And it just happens to be the most enjoyable state of mind for a knowledge worker – that illusive state of flow. In his book, Deep Work, Cal Newport does a fantastic job laying out the What, Why’s and How’s of “deep work”.
“I’ll live the focused life, because it’s the best kind there is.”
Many programming books are “recipe” style books. I suppose they appeal to us “Novices” on the Dreyfus model of skill acquisition: Just gimme the recipe, and no one gets hurt. Or maybe they appeal to that other short-sighted fellow with a hankering for fish:
“Please sir, can I have a fish? I’m really hungry… I’ve got a family you see, and um, bills, and rent, a mortgage on my phone, and the Evernote subscription is killing me…”
Well, Code Complete(affiliate link) is not that book. Author Steve McConnell catches the fish, deftly removes the hook, and after dangling it in tantalizingly front of your face for a few seconds, throws it back in the water.
“You want a fish? Go and get it.”
Then, when your face resembles a flabbergasted house cat who’s just been deprived of its favorite squeaky toy, he puts a hand on your shoulder and leads a stunned you over to a plush red armchair that he just happened to bring down to the river, an armchair hand-embroidered with the words, “Codito ergo sum.”
Cristoforo Colombo (a.k.a Columbus) knew how to sail, navigate, sell a proposal. He was commissioned to find a new route to India. He didn’t find India. Fortunately for him and his career, he found something even more lucrative.
You’ve got skills, right? Coding skills, architectural skills, fried skills, skills gumbo, nun-chuck skills… But if you’re commissioned to write a piece of software that takes your stakeholders to India, how will they feel when they wind up somewhere in the Caribbean? You could pull a Columbus and try to convince yourself and everyone else that they really are in India:
You: “But this is India, I tell you! See? Look at those Indians. You there! Yes you, Indian! Come hither at once!” Stakeholder: Raises a doubtful eyebrow. Takes a long, exasperated breath. “Indian”: “Oye papi. ¿Sabe? Tu ta loco.”
The point is: you know how to code, but are you coding the right thing? How do you know? That’s where Specification by Example comes in.
Bertrand Meyer is a well-respected member of the programming community, having introduced useful object-oriented concepts practices such as “contracts” for methods and classes. He also literally (affiliate link ahead!–>)wrote the book on object-oriented programming (in ‘97, and it’s still in print). So when he writes a book on his response to the Agile wave, you get the urge to read it. It doesn’t hurt that it got honorable mention in the Jolt book awards, or that it’s a pretty quick read.
The core tenants of Essential Skills for the Agile Developer are presented as a series of “trim tabs” - Small lightweight practices and mindsets that are easy to adopt in the short-term but payout handsomely in the long-term.