Many developers are best described as lazy. Not lazy in the fat slob on a couch, eating potato chips while they don’t even throw enough effort into playing World of Warcraft, but rather they’re like lizards on hot rocks. They will not move from a comfort zone, aim for elegant, no maintenance solutions, and generally follow the cow road approach to development through a problem.
Never heard the way cow roads were built? My grandfather explained the concept to me. A road engineer, before there was a Civil Engineer’s exam, would drive a cow forward with harness and leads. Up hills, through valleys, to shallow fording a river and through deer trails. A cow you see, is lazy and instinctively chooses the way that uses the least energy, employs the best advantages of terrain to advantage. But cows get stuck in briers, lose their way in the forest, have to be rescued by cowboys when a nasty storm comes up? These are true, a Cow isn’t smart, a cow is simply wise when it comes to being lazy. The cow may lead you astray, but typically if you can’t get a cow to move up a mountain, after driving him forward, and she keeps lying down, rather than moving forward, it’s time to get the dynamite out and blow a pass through the mountains.
Programmers subscribe to the cow metaphor. Follow the herd and lay gravel and then pavement behind you in a smooth grade that people can work through. Find cracks or problems in the pavement? Patch it, feature enhance it, and move on. Given the Pigs and Chicken metaphor of Agile development, I think that the cow metaphor is also appropriate, despite the Zen master focus many attribute to the modern Agile developer, the lazy cow is still Zen, still in keeping with the mentality of clean, re-factored code that reads easily.
The Novelist is no less a lazy cow than the developer. They research furiously for the route to a good manuscript and a way to tell their story. Their outlining is akin to the planning session, their mandatory writing sessions like the developer’s quiet hours, while they try to focus on specific projects and get the work done. While often, a novelist might sit on his warm rock and bask in the completion skills and efforts they have, the good novelist knows that they have to constantly change, learn and adapt themselves to the market and the endeavors they choose.
I comment on novelists, only as an outsider looking in. While I’ve written several novels, I haven’t managed to publish them yet. I write at least 1750 words a day on one of them, typing furiously to complete this or that story in the twenty minutes I throw at them. At 190,000 to 250,000 words per novel and 360 days of honest writing a year, that’s more than 2 novels a year worth of writing, but as any novelist, even an amateur might tell you, there’s fat to be trimmed and set aside or thrown away.
Software development, especially on independent and open source projects learns much from these good habits. Writing 1000 lines of code in an hour is actually quite easy once you’ve outlined your problems. Many writers write with a solid outline and I know few developers who write their best code without the framework.
Clean code, a book I can’t recommend and both fight with my dying breath enough, has many examples for building solid code. Early on they talk about functions or methods having and doing only one thing well. I’ve read writing books that talk about the elegant, short sentence that does a dozen things, but is a singular focus and idea. I think clean code was talking about that sort of thing. If you write a beautiful method, that joins 4 methods together, has no technical debt, had the JUnit written first, and has readable variables and functionality that transfers the knowledge of what it says and does to any developer in less than a second, then you have achieved that synthesis of code that novelists call their golden sentences.
How can I sum up my first post about this topic?
Good Habits for writers and Novelists:
- Set daily goals, for authors, at least 1500 words a day, for coders, make it a number of classes and or lines of code that at least amounts to an hour a day, every day, even on your birthday.
- Write small, cow road sentences or functions, that do a lot, with a little, plow through where you need to.
- Use dynamite when the problems are too big. Ask for help, blow through your problems, get them done.
(Author’s note: Some of my posts have been sitting in draft mode for several months. I decided to release the last two, mainly because I commented about both of these as advice in the last week or so. They’re not as polished as I’d like, but I’m hoping their serial nature will force me to come back and fix a few of these.)