Developers discuss and debate clean code all the time. They even debate what constitutes clean code. The discussion about clean code is as old as languages themselves; entire languages (I’m looking at you, Python) have been written around the philosophy of easily readable code.
But why should you care about writing clean code? What does it matter? Especially if you work on a small one or two person team, why should you care about clean code?
Years and years ago, somebody coined the term “slashdotting.” In essence, it’s the experience when your website is linked to by a larger website, overwhelming your servers with a crush of traffic.
Hacker News can have this effect, especially if your website reaches the front page for any length of time.
When you buy a book on Amazon, the transaction ends when the book gets packaged up and shipped (or delivered wirelessly over Whispernet). There are no updates (typos are corrected over Whispernet, but content is not updated), no connection to the author, no new versions when the material changes. For most books this is just fine: novels don’t have “updated content” and cookbooks rarely change either. But for technical books this sucks: technology changes quickly, and with the release of one minor version, your technical book (which you spent so much money on) is now totally worthless.
Paper books are notoriously hard to update, and you certainly don’t receive a new copy for free when a new edition comes out. Even the technical books that do get updated still require you to purchase a whole new copy! College students will tell you about “edition hell”, where professors (who receive a free version of the book) update the edition with minor changes, and ruin the used book process. Everybody has to buy a $90 textbook, because there are no used ones in the “required edition.”
For as long as I can remember, writing a personal bio has been a tough challenge. You know how this goes: you’re applying to a conference, writing a resume or creating an “About Me” page on your website. You have to write down information about who you are, what you’ve accomplished and what you think other people will find interesting about you. All of a sudden you’re frozen in fear: writing about yourself is hard! You don’t know where to start, what to say or what other people will think. Writing a personal biography sucks.
I feel it’s time to do something about this problem. And so, I’ve begun developing a new service called Build A Bio. The Build A Bio service will connect you with a copywriter who will craft a biography for you. All you’ll have to do is answer some straightforward questions honestly. No more trying to guess what other people find interesting; no more struggling to write in the third person; no more fear!
Two craftsmen make chess sets. Beautiful chess sets. One craftsman uses old style tools: chisels, files, hammers of all sizes. His preferred material is stone; he carefully carves the pawns, the queen, the rooks and the knights with exquisite detail, like his father, and like his father’s father. Another craftsman uses more modern technology to melt and mold metals. He uses fire, molds, and tools that can withstand tremendous heat and pressure. His boards are different colored metals. His pieces are just as exquisite, just as delicate, just as beautiful as the other craftsman.
Years ago, I worked for a company that had a strictly governed bug fixing process. The bugs to be fixed per release were specifically regimented, right down to the amount of hours available to fix each issue. Developers were expected to meet or beat their estimates, and failing to do so meant overtime (since the deadline was immutable). With effectively every working moment spoken for, there was never any free time for innovation, invention or creativity (at least on the schedule). Developers were effectively bug fixing or feature building machines, with no input into the process or product features.
Unfortunately, this seems to be an all too common trend in the development industry. Employers, who love the ability to measure things, disdain the fact that engineering is first and foremost a creative art, that cannot be effectively measured. They attempt to install artificial measures of productivity like tests written, lines of code added, bugs solved, and number of bugs reopened by the quality assurance team. Sadly, these measures all fail to effectively measure the effectiveness of development teams, because the developers themselves see immediately through the schemes, and learn quickly to game the system.