Home / Backend / Developer’s code of conduct

Developer’s code of conduct

One of the things you will learn when you are working on a project for a long(er) time, or join a company that has legacy code to maintain, is that there are different levels of quality. And what you will also probably find out, is that the code that has not been touched for a long time, is of a lower quality level than the newly written code.

When looking at legacy code, one of the most common reactions of a developer is “what were they thinking?!?”.

Personally I think it is a good thing when you realise the code was written by yourself. This would mean that you have progressed as a professional developer. But what if you express this out loud and the original developer overhears it? Imagine how he or she would feel at that moment. How would you like it if someone else told you the code you wrote was really bad?

Let us try and focus on the code for a moment.

Is the code really that bad?

It probably is used in production and is working as it should. Apparently there are no bugs in it, otherwise it would have been changed. And it has business value, or it would have been removed from the codebase. A professional developer does not intentionally write ‘bad’ code.

Why is it built that way?

One thing to keep in mind here, is that technology changes over time. The way systems are designed changes over time. Developers get new insights and so on and so forth. When the code was written, it was good code. It probably was reviewed by other developers as well. They were all professionals, doing the best they could. Another things that could have happened, is that the code grew that way over time. New features might have been added which made the code look less nice. A developer might have been under pressure to deliver the feature back then and might not have taken the time to clean up everything.

The most important thing you should realise when you see ‘bad’ code is, that it can be improved… You should be a professional and change it, so that you are proud of the code. And one year later, if you look at the code again, you might still see it as good code, but you might also realise that is has turned into ‘bad’ code again.

So in conclusion, some sort of ‘code of conduct’ with regards to handling legacy code can be written down. In short it would be something like:

Do not bash on other people’s code.

If you think it is bad, change it… improve it… make the code more beautiful and improve to the best of your effort. Stop looking at how it was, but focus on how it could (and should) be.

Interested joining BVA Auctions?

Take a look to our vacancies

About Marcel van den Brink

Marcel van den Brink is a software engineer with 20+ years of experience in web development. He is passionate about the development process, CI, CD, metrics and getting the most out of a team.

Leave a Reply

Your email address will not be published. Required fields are marked *