When we think about writing clean code, we often think of code written with purpose where each line is perfectly thought out. Code that was planned out before it was written. So well-planned that the first time we run it, it just works. No errors, no flaws, first go. But why is it that for most of us, when we write code, it is far from this ideal?
A lot of times writing code can feel like being in an intense battle with your machine. No matter what you do, the errors just keep coming. To make matters worse, the error messages are unspecific, which means that when you google them, you get nowhere. Your frustration keeps rising, and the bug that you thought would be a quick five-minute fix, ends up taking hours!

. . .

I think that the perception that we have of what clean code is and how it’s written is flawed. That perception is dangerous because it can scare off a lot of beginners. The reality of programming is often far messier, where you pretty much write a line of code and all of a sudden an error occurs in the old part of the codebase that someone really should take a look at and refactor, but since you’re under a time constraint, you end up writing a quick fix and list like that, the tiny feature that you were going to implement has become a complete mess.

Code will always be messy at first unless you’re working on a project where you’ve done all of it before, where you know exactly what to write and where to put it, which is sometimes the case. If you’re doing anything that’s new to you or that you haven’t done a thousand times before then the experience is a lot different. Do not worry because there will be code reviewers and assigned documents that are to help you write clean code.
At the end of the day, in most software engineering jobs, things are not as well organized as you would expect. Mostly, the code that you write on a day-to-day basis is subject to a lot of outside factors. I mean things like time constraints, old code basis that is not maintained or even other people’s bad practices.

The expectation that you’re going to be able to write a piece of code that works perfectly, and is purposeful every single time, is far from what writing code looks like. You should still, of course, aspire to do all those things, but in most companies, it’s not only your job to write a clean piece of code. There’s also a trade-off between writing clean code and being efficient. Thinking that every code you write has to be perfection is neither realistic nor what anyone expects from you. Trying to write perfect code is super inefficient because to do that, you need to spend so much time thinking through everything that you do, and that ends up slowing you down.

The way that you should usually work or think about your work is to write, refactor and review. That is, you first focus on writing the code and making it run without errors. After you’ve got to spend some time refactoring the code you’ve written, it’s easier to refactor existing code than it is to write it like that from the beginning. Finally, once you’ve spent a bit of time refactoring and essentially cleaning up your code, you can send it in for code review. After review, I would say that you have successfully written a pretty solid piece of code while also maintaining a reasonable level of efficiency.

What I’m mostly trying to say is that the perception that we have that clean code is equal to perfect code is usually far from the truth. That is why big companies have practices like code reviews. The first implementation of something is usually far from perfect. Even though it may be inefficient to write clean code from the start, it doesn’t mean that you shouldn’t try. The fact that writing clean code is inefficient is not an excuse for writing bad code. The aim should be to write the best code you can at the time.

As you write, you often know a fast and a sloppy way of doing something and the slower but more proper way of doing it. This is when you should opt for the slower, more proper way. Instead of writing three nested for() loops, it may be worth spending a couple of minutes trying to figure out if you could come up with or google a recursive function that could remove some of the loops.

I believe that most of us know when we are being sloppy and just cannot be bothered doing things the right way, even though we know how to do it the right way. This is when I would suggest spending that extra amount of time doing it the right way from the start. On the other hand, let’s say that we’re implementing a new feature. Usually, there are a lot of ways to implement the said feature. In this case, I would not suggest spending several hours trying to research the most optimal way of implementing that feature. Instead, I would prefer just implementing the feature in the best way that you can, and then spending some time on refactoring that and making your implementation a lot more elegant.

A trendy term right now is “action bias”. It means being biased towards taking action over inaction. That is how you should be thinking when you’re creating clean code, meaning you can spend time researching things and trying to do it better, but you’re biased towards taking action. I think you’ll be well off if you keep that in mind as you code.
The thing to understand is that clean code is the product of several people working on a project together and not just one individual. I believe a lot of people feel like crappy programmers because their code looks like a giant mess.