I joined to the project that was developed by one guy. He was an amazing developer with plenty of ideas and skills. He had also the best knowledge about the system – its domain, architecture, used solutions, hidden tricks, and workarounds. In every single task, I needed his support because I didn’t understand how things worked. My main goal was to retrieve as much knowledge as possible from his head. The reason was simple – his contract is ending in a month. I wish I didn’t know about it before.

The project had the long to-do list of features. Some of them were partially implemented. Some other functionalities had specified time–frame because of the seasonal nature of the project. Everything was important from the business point of view.

There were no tests, no code’s style guide, no documentation (besides a few out of date README.md files across repository). I didn’t want to touch anything because the code was unstable and cause a lot of side–effects. After one month of torment, I thought – “f*ck it, let’s make it works”.

I share this story because it was one of the most important moments in my career as a software developer. The moment when you realize that if you want to go further you can’t hide behind lack of knowledge and misunderstanding of someone’s else solutions. I decided to explore it and treat it like my own code. I provided fixes, improvements, and changes. Finally, I took pleasure in making things better.

That led me to another thought – the code is common good.

Working as the only one developer

I don’t know how popular is working as the only developer in a project. On the beginning of my career, I worked in this way for a very short time. Most of the projects were like single–shots – do it and forget it. It was very convenient because it allowed me to test my ideas. Otherwise, It was hard to care of the code if you had limited amount of time and the pressure from the top.

It was a lie. Almost always these projects came back both for simple improvements and further development. Even if they didn’t come back to us, they were transferred to other companies. The legacy code I produced wasn’t a problem for me – it was a problem for other developers. I realized it when I received the legacy project the first time.

Although working as a one-man band has a lot of advantages, it has also a lot of pitfalls. The one is very destructive – you cannot challenge yourself with other developers. You have limited chance to speak about the project, about the potential solutions, you cannot validate your ideas and nobody does the code review for you. You are behind the wall so you are fully responsible for your work and the education. Your commit messages are the only single letter, you have plenty of jokes in comments in code with the hope that someone will see it and laugh. You don’t write tests because you know that everything works as expected.

If this description fits you, be sure to read on.

Consequences of the bad code

If you work as a professional developer, the code which you produce belongs to the company. Even if you are the only one dev in the project, you work for (or on behalf of) your company. If the project is successful, the team may grow.

Working in the team is a completely different story. But let’s focus on the code.

Every project has an entry barrier – it depends on the complexity of the project and domain but also on the code style, documentation, technical debt, tests, and all used hacks and workarounds. If you don’t take care of these things, the entry level will be higher and higher. The introduction of a new person to the project will take a long time causing extra costs for your company.

A climbing man as a metaphor of a new developer in a project
New developer in a project. Photo by Lionello DelPiccolo on Unsplash

Also, when a developer is leaving a company, somebody else has to come to his place. Leaving the project without any documentation, tests, with the code in a state resembling a rubbish dump is very selfish and irresponsible. It isn’t only a harm to the company but also for coworkers and the rest of developers.

Our goal as professional software developers is to create software that supports business, resolves problems and makes money. Software which produces other problems isn’t a good investment.

We should take care of the code all the time during our daily work. The most difficult situation is when the team is split to people who don’t take care of the code and the rest, who take the responsibility for what they produce. Whom to blame if something goes wrong? Is it really a team?

Another phenomenon is the disconnection from the code written by someone’s else. Some developers avoid changing this code because they don’t feel responsible for it. Since the code is in the code base, it’s a common good of the whole team. We all can comment and blame but only a few people are able to give a constructive feedback or even help.

Is it all the consequences? I think the topic isn’t exhausted yet. But they are problems that I already met. I’m sure that you can write a few more comments.

How to be a responsible developer?

I wanted to ask “How to write a good code?”, but this is very subjective and depends a lot on technical aspects. Instead, I decided to ask about responsibility, because a responsible developer writes a good code. It’s a natural implication.

I don’t know the easy-to-follow guidelines that make every developer accountable. That’s something that everyone has to discover. Instead, I have prepared a simple list which bases on my experience.

1. Treat code as a common good

No matter if you are only one developer or you are working in the team. The responsible developer always keeps the code in the good condition. Try to reduce the technical debt and make the code more understandable. Don’t disconnect yourself from someone’s else code – treat is as your own and makes it better.

2. Don’t blame your teammates

Because the code is common, in case of error, the whole team fails. You can always check what someone else introduces to the code base. Don’t you have a code review process? It’s a nice time to make it as a part of the development process.

3. Write code easy to read

Developers spend most of the time reading the code. Make this process easier by writing code which is easy to read and understand. How to do this? For instance, I use the return early method to make my code more readable.

4. Write code easy to remove

Isn’t something necessary? Remove it. Code which is easy to remove is also easy to change. Less code in the code base means less code to read and maintain. The good code' deprecation strategy is very helpful.

5. Write tests

This is a proof that the code works as expected. It’s also a good documentation. Don’t treat tests like separate tasks, it doesn’t make much sense.

6. Deliver solutions, not problems

Even if you don’t have a good information to your manager, product owner or somebody who is in charge, try to show other potential solutions, not only problems.

7. Don’t be a blocker

Don’t you want to learn something to improve your skills? Do you block opportunities for others? Instead, take as much as possible from them. Don’t you take care of the code style? Take advantage of auto-formatters – it isn’t a big deal.

8. Don’t be an asshole

Be kind and helpful. Simply. Even if your contract is ending and you don’t have good relation with your managers, try to do everything to make the work easier for your teammates and future developers. You can meet them in one of the next companies.

Summary

I started from a short story about the situation that had a big impact on my career. The key is to understand that companies don’t hire people to help them, they hire because they need help. They are looking for someone who is able to solve their problems and who introduces something fresh to the organization.

I could wait and complain that the code is ugly and unmanageable. The company didn’t take care of the good knowledge transfer. But I didn’t. Instead, I did my best to make the work better for me and other developers. Ultimately I changed job but I left leaving things in the best form.

Purposely I don’t write about the tools and methods how to write a good code. It isn’t a key in this article. The point is to realize that we all more than just developers – people who write code. We solve complex problems, we give our customers the value, we make someone’s else life easier, we work together – whether we like it or not. Let us respect our work and take responsibility for what we do.


Featured photo by Štefan Štefančík on Unsplash