My former colleague that I looked up to told me, “Effective people are chronobenders.” It all started with fire, lever, pulleys, and wheels. Humans began to multiply power. About two centuries ago humankind underwent the industrial revolution. Since then humans have been racing with time with its fastest steed, the automation.
A software developer is one family of the chronobenders. A software developer’s main asset is the ability to automate and reuse. They build reusable software to enable people to work much faster and more consistently.
Due to the enormous demand for software and the equally enormous amount of available developers, countless software has been built to this day. We have software almost everywhere, computer, console, smartphone, robotic vacuum cleaner, etc. Those kinds of software that you can interact with are only the surface level software, the tip of the iceberg. There’s a gargantuan chunk of invisible software and hardware to bridge the simple “swipe to unlock” feature of your phone with the ones and zeros in its memory and processor.
You might think, in the far future, a sentient species will uncover smartphones from the 2x century, puzzled. They’ll be like, “What did people in the 2x century do with these metallic soap?”. You’re right about that except for one thing, we’re already there. It’s very common for a developer to see a piece of code from last year like they see the great pyramid of Giza.
Codes and hard works are wasted because of this phenomenon. Developers of the new generation make the same mistakes the old made. Software gets slower due to old piece of legacy codes are misunderstood.
In software development, there are aspects beyond automation and reuse. Software, like the pyramid, is built by many people that may come and go. Like the pyramid, all involved must move in the same direction lest the project will fail. Assuming, unlike the pyramid and as per today’s norm, there’s no mental slavery involved in software development, synchronizing the vision of all involved in the project a.k.a. knowledge transfer is an important aspect of software development.
A novice mage may cast an ancient spell he doesn’t understand to enhance his/her ice spell, not knowing that the ancient spell naturally generates fire element. To counter this, the mage must double his/her willpower output to make sure the ice effect is not overwhelmed by the fire from the ancient spell, draining his/her mana faster. Only if the fire effect of the ancient spell is well documented in the scroll, the novice’s energy would still burn bright.
Code Like You Write Crowdsourced Article
Writing code for communication and education is one way to pass down knowledge. The next person who touches the code must be educated by the knowledge of the previous holder. Of course, writing an educative code is another level of challenge to writing code that just works. C2’s articles, SelfDocumentingCode and LiterateProgramming, explain this topic to great details. A recent example I see to build this kind of code is the Rust community’s attempt to push people to write Rust code in an idiomatic way. They have a GitHub repository dedicated to it.
The principle also applies to the interface, the layer where it interacts with other entities. It can be either the application programming interface, command-line interface, or user interface. A good interface usually abstracts away complexities from the consumer, but a great interface enables its consumer, if they desire, to understand its inner concepts. A great Rest APIs implies to its consumers accurately the business logic behind them. A great abstractive library has an abstraction written so well so there’s so little to no chance the abstraction would leak. No abstraction leaks if there are no abstractions (proceed to upload “roll safe” meme).
Last but not least is the documentation. It is important to have a documentation and user manual to explain part of the software that is not apparent. It is also very important if you decide to write documentation for your software, to also maintain the documentation so that it does not become obsolete and useless. Now, who is amongst software developer readers hasn’t cursed at a library without the proper, correct, and complete documentation?