Towards better code , Thoughts on improving

Let’s face it, we have have been writing software for decades now. We can no longer claim to be a new domain and pass-off nascency as an excuse for shipping sloppy code. Most of us can tell the difference between good code and bad, but how do we go about creating beautiful instead of merely reading about it? software Well, let’s make an attempt here. This article is not going to teach you the zen of software maintenance. Rather it is just a dump from memory, sorted in order to ensure data persistence. Hopefully, some value is realized along the way. pseudo-random Empathize through code Speak so others will listen … write so others will read There is elegance in brevity. Code golfing might help you win , but the will always be missing. The empty chasms serve as bigger obstacles to collaboration than the longest of obfuscation blocks. JS1k lines-not-written Even when writing a simple wrapper for data retrieval, I have always found it useful to leave comments as markers along the trail. A few well-placed comments can save numerous man-hours of backtracking and spelunking, especially in highly collaborative teams. When the number of developers involved, , exceeds one, the need for clarity becomes non-negotiable for large projects. The catch is that is not an instantaneous measurement. Even if it is the same person reviewing code a few months later, becomes greater than 1 and the rule still applies. n n n (Don’t) Rewrite to update Projects which neglect the need to be inclusive rarely get updates. Rather, functionality updates and even minor fixes are delivered via system rewrites. Like many programmers, I sometimes jump to write fresh code rather than read old ones. This may be understandable as a side-effect of not following the previous section, but it is still a sub-par decision when developing software. Old code probably comes with many guarantees that your new solution does not. For one, the existing code works, while yours is still in the domain. We have version control software for a reason, use them. theoretically-faster Delete your way to perfection Every block of stone has a statue … the task of the sculptor is to discover it.– Michelangelo, probably Be proud of removing lines of code. I look forward to days when my commits show more red than green. Verbosity is a not a required dependency for clarity. In fact, clearing out decision paths and trimming circuitous execution cycles improve readability and reduce the search space as future bugs emerge. git no-longer-relevant If your manager ever asks you how many lines of code you have added to a project, I have only one piece of advice — run; . fast and in the opposite direction Abstractions are not forever We all love abstractions, they save us from repetition, allow us to stand on the shoulders of giants and are the secret to becoming a 10x rockstar-ninja. Okay, jokes aside, I have to admit, abstractions are really valuable tools. They allow us to leverage existing code as assumptions that can be when writing higher-level code. abstracted away However, you have probably also heard about . If not, the link is right there, I’ll wait, Joel is a much better writer than me. The Law of Leaky Abstractions Understanding the costs of abstraction is a crucial step in the journey of a developer. Learning to look for hidden costs is a crucial step in growing as a programmer. The earlier the realization is made, the easier the wakening from deceptive fantasies. One of my answers to is the opinion that the raw accumulation of practice becomes indistinguishable from innate talent. Peter Thiel’s contrarian question directed By making a concerted effort to write better code with each passing day, my hope is to get to a point where developing software has a much tighter execution step from thought to silicon. , I work at and usually blog about in building data-powered AI for ecommerce companies. A note before you leave Semantics3 my technical adventures To know more, check out , or to stay updated. our blog follow me on Medium