This may seem like a weird question to ask because the mindset of most developers is that code projects are neither moral nor immoral, they’re simply programming files that perform various functionalities. I would like to think that most developers take pride in their work and therefore want to write code that adheres to best practices, however, given schedule and budget constraints many projects devolve, with the top goal becoming ‘to simply work’ and being completed as soon as humanly possible. However, this mindset can lead to issues such as missing edge cases for features and poorly organized codebases that are difficult to maintain.

Regarding the question of “is writing bad code immoral?” I heard a great story from one of my Computer Science professors at Texas Tech, Dr. Michael Gelfond, which is where I got the idea to write this post. During one of our lectures, he posed the question and then told a story. A few decades ago when he was a programmer working for a software organization he ran into a nasty code bug. It took him several days to figure out that the previous developer had built a poorly constructed function that was causing the module that he was working on to break. After he told us the story he asked us again if writing bad code was immoral, most of the class answered that it wasn’t. But then he asked if we murder someone a few days before they were going to die, “is that immoral?” To which everyone answered with a unanimous ‘yes’. He finished his lecture by saying, “Well wasn’t it immoral that the last developer’s code stole two days away from my life?”

That story and question has stuck with me for years and now my answer to the question “is writing bad code immoral?” is a resounding “yes”! As developers, we should take pride in the work that we produce, not just for our clients’ or employers’ interests, but simply due to the fact that our goal should be to be true craftsmen in everything that we do. Coding is the closest thing we have to magic in this world and I feel honored to be able to work with it on a daily basis along with being able to teach others how to do the same. And with that in mind, it should motivate us to have a clearly defined goal of being excellent at our craft.

One of my all-time favorite baseball players was Joe DiMaggio and he had a great quote that I think is very applicable to developers. He said,

“There is always some kid who may be seeing me for the first time. I owe him my best.”

I try to apply this in all of the code projects that I do, it’s easy to fall into lazy habits, however, I remind myself that someone might be looking at this project and it could be the first impression they have about me as a developer and if I took shortcuts, even if the application works, it could reflect badly on the work that I do.

This doesn’t mean that you can’t make mistakes, quite the opposite actually. I’m constantly striving to become a better developer and because of that, I’m always trying to work on building features and projects that I haven’t created before, which naturally leads to mistakes during the learning process. However, there is a clear distinction between mistakes that get made while you’re trying to build an ambitious feature compared with project bugs that pop up due to laziness and poorly written code.

How to Write Better Code

So if writing bad code is immoral, what can be done to combat it? Thankfully we have a nice set of tools and workflows that can be implemented. Here are a few of the ones that I’ve found to be the most effective:

• TDD/BDD – Regardless of your thoughts on a test or behavior-driven development, there’s no denying that if it’s implemented properly it can lead to a well-constructed codebase. TDD naturally leads to following best practices such as low coupling and small methods, and with its refactoring step I’m a huge fan of using it to ensure that an application is built the right way.
• Continuous Integration – Assuming that you have a comprehensive automated test suite, continuous integration tools such as CodeShip or Travis will make sure that code will not be pushed to production until it’s passed the full test suite. I’ve had a number of times where CodeShip has blocked a bad deploy that would’ve taken down a site. Additionally, it gives the development team a report on what needs to be fixed if a bad deploy is attempted.
• Pair Programming – This is one of the most powerful tools you can use as a developer. If you’re not familiar with it, Pair Programming is the process where you and another developer both take turns working on a project at the same time, preferably in the same room and on the same computer. When one of you is coding, the other developer is watching and giving advice or warnings. Whenever I’m building a complex feature I will always use pair programming since it’s akin to working with two brains on the same feature.
• Continuing Education – No matter how long you’ve been a developer, you’ll never reach a stage where the learning ends. Each day I try to learn something new, whether it’s from tutorials, books, or blog posts from other programmers.

I hope that this has been a thought-provoking post and will help you on your journey towards becoming a code craftsman.