DALLE generated chalkedgoose programming logo

Improving Your Software Development Practices

Hurting Harold meme.

I want to make three things clear for aspiring software engineers. One you suck at coding we all suck, Two more is almost always not better, Three worry more about what your code is doing and less about how your code is doing it.


We all have to admit that we all act like terrible programmers sometimes, and we all need to compensate for that. In other industries, we’ve built protective vests, hardhats, safety ropes, durable eyewear, and other tools to protect our soft and weak human shells from damage. Just like our bodies are not impermeable to the ails and dangers of this world, neither is our brain or anything else that is created using human intelligence. Because of this, we need to always be checking and verifying any software that we build; we need to be over-prepared for failure in a way that allows us to continue to ship and launch code. This needs to be done through automated testing like end-to-end tests, unit tests, and integration tests. We as humans simply cannot work as much as our machines, but luckily we control them and can tell them what to do. Another precaution is stricter standards and the implementation of quality assurance tools like linting and code quality tooling. The very last step of the process should be human verification; this is the last line of defense and most often the weakest one. But sometimes humans can catch things in humans produced code much better than any machine could due to environmental or engineering limits. Be judicious in what standards, processes, and code you let fly in your project.


More code and tools are seldom an improvement, and you should always strongly consider whether or not a tool or block of code actually adds any value to the product. 15 and 50 bugs per 1,000 lines of code is the industry average according to the Quora tech community; this number can increase or decrease due to an infinite amount of variables. One thing is constant less code is statically proven to result in fewer bugs. There are several ways to combat the creation of more lines of code; one easy one is to switch from a language that requires far more lines of boilerplate (this is important) to one that requires far less. People are often sticklers for performance; for example, switching from writing C++ to Python has exponential changes in overall performance, which can sometimes be essential. More often than not, it does not matter because developer time spent writing boilerplate, fixing bugs, and struggling to review incredibly jumbled sources costs far more than any of the performance losses ever could. The Functional programming community are vast proponents of writing less boilerplate, and this often results in superior code (yes I said superior) aside from my personal biases and love for ReasonML and Clojure I still recommend you check out what they are working on just be careful not to become a full-blown purist like I once was. Some modern languages you may be using might be implementing some cool things inspired by the FP community like Immutable Data Structures and powerful Iteration and Pattern matching functionality.


Focus more on your codes goals than your code itself. I have a saying “putting the objective in object-oriented code” (love the irony), which applies here since we often spend so much time focusing on performance, code refactoring, and get caught up in affairs bike-shedding we often forget what we’re producing code for. Is the code we are writing to monitor life support systems? Communicate with planes? Or is it being used to stream someone’s favorite show or share a social media post with their group of fixie riding, Ruby writing, pug, and cat-loving friends? They like to go to Blue Bottle or Half Moon Bay with on weekends.

Made in 🇪🇸 without the S.