Write less code
Several years ago at a HackNashville event, I remember one of the best programmers in the room curiously showcasing what was basically a Keynote presentation at the end of the hackathon. The presentation amounted more or less to a suggestion that everyone in the room write less code.
I didn’t really appreciate this very unorthodox hackathon project at the time, but after endless client projects, a few failed startups, and now some businesses that are actually progressing quite well, I think I am starting to understand what this very gifted programmer was hitting on.
As the old saying goes, when the only tool you have is a hammer, everything looks like a nail. As young software developers, we (and I definitely include myself here) tend to see most problems in a software context. There’s nothing wrong with this, but where I have fallen short in the past is placing the role of software within the wider context — namely, the market or human problem at hand.
Sometimes we as software developers get lost in the wide array of tools, frameworks, paradigms, languages and methodologies being sold to us. We confuse the means with the end and as a result fail to quickly deliver value. We fail to see the value of simple, understood tools that do exactly the job which they need to do and no more.
I used to think that great software developers were the ones who spoke at conferences, wrote frameworks and libraries, contributed to languages, and other such more academic pursuits. What really matters, though, is the impact of the work — how soon your code solves the problem you set out to solve. All those complex software engineering machinations tend to evolve naturally in well cared for projects as necessity requires.
Richard Feynman once gave a commencement speech at Caltech in which he coined and decried “Cargo Cult Science” — or the idea that by simply impersonating a thing, you can do what the thing does. He discussed Islanders who, having seen runways constructed during wartime, men waving flags around, and planes dropping supplies — thought that the planes dropped the supplies because of the cleared ground and men waving flags. So, the Islanders, after the militaries had departed their island bases, tried to bring the supply drops by waving flags around, making plane replicas and radio dishes from thatch, and other such ridiculous things.
We do the same sorts of things in software — we wave around things like frameworks and management methodologies without a clear understanding of how those things are going to bring about our expected end result. Perhaps the Islanders, for instance, would have been better off instigating another war if they wanted to bring back the supply drops.
I’m not decrying experimentation, learning, striving for quality, using complex tools, etc.— I’m just finally ready to take the advice of that programmer all those years ago — write less code, just the code you need.