How do I learn to write clean code as a junior developer?

First, this is normal

Almost every junior developer I have worked with went through exactly this. Working code is the start of the job, not the end. Code is read far more often than it is written, and your reviewers are teaching you to write for the next reader. A long list of comments means people are investing in you.

The problem is not the comments. It is that you are fixing them one pull request at a time instead of turning them into habits.

Turn review comments into a checklist

Start a note today. Every time you get a review comment, write it down in your own words. When the same comment appears a second time, move it to a short pre-review checklist. Before you send any pull request, read your own diff against that list. Within a few weeks, most of those comments will stop, because you will be catching them yourself.

One habit a week

Books on clean code contain dozens of rules, and trying to apply all of them at once does not work. Pick one habit a week and apply it everywhere you touch:

• Names that explain themselves: no data, info, temp or Manager. Rename with your IDE the moment you find a better word.
• Small functions: if you need a comment to explain a block, extract it into a function with a good name.
• No flag arguments: send(message, true) becomes two clearly named functions.
• Guard clauses: handle invalid cases at the top and return early, so the main path is not nested.
• Specific exceptions: never catch everything and carry on; catch only what you can handle and add context.
• Comments that explain why, not what.

Let tools settle style

Formatting arguments waste everyone's time. Set up the formatter and linter your team uses, run them on save and make sure they pass before you push. Then reviews can focus on design, which is where you learn the most.

Learn to refactor safely

Clean code in real code bases comes from many small, safe changes, not rewrites. Learn your IDE's shortcuts for rename, extract function and inline, and run the tests after every step. Keep refactoring and behaviour changes in separate commits so reviewers can check both. The Gilded Rose refactoring kata is the best practice for this: do it once now and again in a month.

Where to learn it on Sefism

• The Software design and clean code roadmap has a full stage on clean code, another on refactoring and a last one on code review, giving and taking it.
• The software design cheat sheet has a smell to refactoring table you can keep open while you review your own diff.
• Refactoring.Guru's code smells guide is free and has before and after code for every smell.
• Google Engineering Practices explains what reviewers look for, which tells you what to check first.

Send smaller pull requests

Finally, make your changes easier to review. A small pull request that does one thing, with a clear description of what and why, gets careful comments. A huge one gets tired ones. Smaller changes also mean fewer comments at once, which makes each one easier to learn from.

If you want a second pair of eyes on your code or your checklist, create a free account and book a session with me. You can also read more answers on the questions page.