The Coder’s Axiom

The Coder’s Axiom hackernoon.com3 years ago in #Dev Love38

Originally published by Brian Piere on March 7th 2019 What if there was a way to remove opinions and personal preferences from the equation and unambiguously determine what code is better given two competing solutions? The only thing that developers have to agree upon is the axiom itself. With unanimity reached on this single point, mountains of subjective discussions suddenly become irrelevant and valuable time is reclaimed. Deference to unwanted authority is unnecessary as we make progress to a decentralized world. A handrail becomes available for developers to help them make countless decisions throughout their days. The haunting feeling of uncertainty is replaced with welcomed confidence. I came up with this idea about 5 years ago and it has withstood intense scrutiny from developers and architects at various companies since then. I think about it countless times throughout the day as I write pristine code that is extremely difficult to criticize. And without further delay, here it is… Baring any approaches which contradict the objective, the smallest file-size post-compilation trumps any alternative. There are two inverse things to play with in that statement. The Objective: Of course that can mean a lot of different things. Maybe you need to add more code because the objective requires a certain level of performance, security, features, or the project must be finished before a deadline. Post Compilation: Because the axiom is centered around post-compiled (or post-minimized) code, it circumvents any discussions about code comments, variable naming, or syntactic sugar. A compiler can remain theoretical which provides quite a bit of leeway. What about Judging Pre-Compiled Code? How to determine what code is better “pre-compilation” requires a different discussion and it’s a judgment to be made after considering the “post-compiled” solution. That being said, it’s hard to argue that following precedence isn’t a top consideration. What About Dependencies? It goes without saying that dependencies inflate the size of a codebase post-compilation. As a general principal in life, who wants to argue that dependence is better than independence? Remember the Left Pad debacle? In a perfect world, without deadlines, a codebase should stand on its own… minimalistic, elegant, and consistent. Of course the objective is going to appear at some point and put time constraints on a project. That’s when it makes sense to reach to the shelf and pull in a dependency which inevitably has more code inside that you’ll require. Drawing a Line Between the Platform and Its Codebase Realistically a developer/team has to stand on the shoulders of others. However there’s leeway when it comes to placing the dividing line between a codebase and its infrastructure. If I build a project on AWS that doesn’t mean that any of Amazon’s code has to be considered when evaluating some post-compiled solution against another. What about the software stack (i.e. React, Node, Java, Linux, etc.). It can be a matter of debate what is the infrastructure/platform versus a dependency. Generally speaking however, I’d consider something like React and Typescript a dependency which involves a transpilation routine and that results in a final build file (post-compilation). Java and Node.js don’t show up within a build file (ignoring something like Docker) so I wouldn’t consider those platforms/languages to have any impact on debates which utilize the Coder’s axiom. In many cases, when two competing solutions are evaluated,  » Read More

Like to keep reading?

This article first appeared on If you'd like to keep reading, follow the white rabbit.

View Full Article

Leave a Reply