I've been a big fan of clean code for several years. I have read many books on this topic and hundreds of articles. There is still much to learn as this is a continuous process and never ends. You might be wondering why only for a few years and not right from the start. Much depends on how the employer deals with this issue. At some point, it's all about finding an employer who encourages them to start with clean code, and there are co-workers to work with to make it happen. Clean code is a process that never ends.

It's never too late to start this topic. I recommend it to any software developer at some point. You start looking at software development from different perspectives. You like your code more and more and you get a better feeling for your work. Software development is an art in my eyes because you create something from scratch that you had in mind beforehand and you want it to look nice.

In my career, I have seen that many can develop software, but very few can develop clean software. Why is it so important to develop clean software, some will ask? It's going to be converted to binary anyway, and if it's running, it's running. No question, but the job of the software developer is also to write the code for himself and his colleagues and not just for the machine.

At some point in your career there should be a decision: should I invest my main daily time troubleshooting God classes, or can I invest my time simply expanding the software and working mostly on feature requests? Working on bugs is the worst job ever for any developer. I remember working on just bugs at a company for a few months and it kind of got depressing. Also, don't forget that in most cases, customers don't pay for bug fixes. Of course, it depends on the bug whether the customer pays or not, but that's a big loss for any company that wastes their developers' time fixing bugs instead of developing new features to stay competitive and get more revenue from it to pull.

But what is the relationship between the God classes and bugs? Well, you can imagine or surely everyone has seen that in classes with 20,000 lines or more, there is so much coupled code, unclear solutions and old implementations from previous versions of the programming language that nobody feels like changing anything because nobody knows what the implications would be. This fear of changing and improving code eventually leads to bugs.

Everyone knows that software development is a development process, it's obvious from the name. Business needs are constantly changing as every business is very dynamic and you should be able to act very quickly and implement these changes in your software. If you can't, you lose time to market or the ability to compete in the market. And this is where the role of clean code comes into play. If your code is well managed, decoupled, abstract, works with interfaces and all logical parts are encapsulated in the right classes, you can implement business needs and new features very quickly and stay competitive.

Of course, anyone developing something will tell - but I know where to add a new feature or change this and that very quickly. Yes, because you have it in your head. But that is not the point. Software development is teamwork. If you're on vacation tomorrow and someone else needs to implement the next business change, they won't understand your thinking and will mess things up because they didn't have the information you have in mind during your development process. This way of thinking is unprofessional and I encourage every developer to think about it and hopefully change their mindset at this point. As developers, we are part of a team, we are part of the company, and we must act for the team, the company, and its revenue. We can't be a one-person show, thinking about the outcome of our work and the future of the software and the company. We should be accountable for our actions.

Nobody is born with clean code skills and nobody knows them at the beginning of their career. In my opinion, it's better not to know them, otherwise, it won't make any difference when you start using them, and also at the beginning of your software development career, you should focus on the programming language and the way to create running software, not whether the correct software design pattern was applied or what SOLID principle was used.

When the time comes and you feel comfortable with the programming language, you should start investing time in reading some clean code books and experimenting on your side projects until you are confident to use this knowledge in your daily work. If you work in a company that doesn't care if the code is clean or not, I don't recommend discussing refactorings and code changes for cleaner code with your leader or co-workers, as you won't have much success. If you ask me, I would soon be looking for a new company where clean code is a requirement and the developers can produce clean code. This way I can continue to develop my skills and later become a better developer and mentor for the juniors. If your current employer lives behind the moon and doesn't hear about the positive effects of clean code, you're wasting your time there, lagging behind the other developers in the market and becoming uncompetitive over time.

In the last year, I had 70 interviews with developers from different countries in Europe. Since our customers are very large companies and corporations, it is our job to provide them with the best developers we can have for their development tasks. Clean code is one of the skills we need in development interviews. Unfortunately, only 5 developers were able to solve a refactoring task that I created with my experience and where I expect to see how the code can be refactored from a class solution that does all the actions to a multi-class clean code solution, where each class has its role, everything is decoupled and communicated using interfaces and value objects. It's not as easy as it sounds. This type of refactoring requires developing a clean code mindset, finding the starting point and then getting all the surrounding components to talk to each other. You need to know many of the most commonly used software design patterns, SOLID principles, and of course lots of practice. I remember a developer telling me in the first interview "I read a bit on this topic yesterday afternoon and I think I can make them". Of course, I stopped the interview right away because I don't want to lose my time and the time of others.

There are many books and articles on the subject. I would recommend starting with the bible of clean code "Clean Code: A Handbook of Agile Software Craftsmanship" by Robert C. Martin, and moving on to "The Clean Coder: A Code of Conduct for Professional Programmers" from Robert C. Martin and then to "Refactoring: Improving the Design of Existing Code" by Martin Fowler. These 3 timeless books are the starting point for any clean code enthusiast. You will understand the concept of clean code and hopefully build a new mindset for your daily work.
Then it's just practice, practice, practice. With the new mindset, you will see many opportunities in each class of your old work to change something for the better. You can make better suggestions to your co-workers in code reviews. Your daily work will be happier because now you not only have the challenge of getting the software working but also having it clean.

Happy coding!