In the two previous parts of our series we talked about the first steps in the developer profession and about what is really worth learning at the start of your career.
Now we come to the moment almost every Junior fears.
The first Code Review. The first comments on your code. The first fixes.
And the first thought: "Did I really write this code so badly?"
Calm down.
Each of us went through this at some point.
Code Review is not an exam
This is probably the biggest misunderstanding among beginning developers.
Many Juniors take comments on their code very personally. Stress appears. Uncertainty. Sometimes even frustration.
Yet the goal of Code Review is not to prove that someone made a mistake. Quite the opposite. It is one of the most important elements of the process of creating good software.
Thanks to Code Review:
- we reduce the risk of errors,
- we improve code readability,
- we learn from each other,
- we maintain consistency across the project,
- we transfer knowledge between team members.
The best teams do not treat Code Review as control. They treat it as a daily exchange of experience.
"You have 37 comments"
Sounds scary? At first, yes.
A first Pull Request often looks exactly like this:
- Comment.
- Fix.
- Another comment.
- Another fix.
After an hour you feel like the whole code should be thrown away. That’s normal.
Just remember one thing. A senior does not fix your code to show their superiority. They do it because in a few months you will be writing much better code.
And that is the point.
A good Senior doesn’t only say "wrong"
The best developers we’ve worked with always explained:
- why something is worth doing differently,
- what the consequences of the current solution will be,
- what alternatives exist,
- which solution will be easier to maintain in a year or two.
That is a huge difference.
Because you can say: "This is wrong."
Or you can say: "This works, but if we develop this module in six months, it will be much easier to maintain in this structure."
In the second case you learn something much more valuable than the fix itself. You learn a way of thinking.
Clean Code does not mean pretty code
This is another concept that is often misunderstood.
Clean Code does not mean code that looks fancy. It is not about the number of empty lines. It is not about function length. It is not even about specific patterns.
It is about something much simpler — code should be readable.
If in six months you open your own project and don’t remember what you meant...
...then the code was probably not readable enough.
There is a saying: We write code for people. The compiler only checks syntax.
And there is a lot of truth in that.
Don’t fall in love with your own code
This is one of the most important lessons.
Code is not a work of art. It’s not a painting. It’s not a sculpture.
It is a tool to solve a specific problem.
If someone proposes a better solution...
...it’s worth considering.
Not because someone has more authority. Because maybe it really is better.
The ones who learn the most are developers who can say: "You’re right. Let’s do it differently."
"It works on my machine"
Alright. We finally had to reach this famous sentence. Every software house has its version of this joke...
Imagine a situation.
A tester reports a bug.
The developer replies: "It works on my machine."
The tester checks again — it doesn’t work.
The Project Manager looks — it doesn’t work.
The client also checks — it doesn’t work.
But... on the author’s machine it still works.
Sound familiar?
Most often the problem is not in the code itself.
There can be many causes:
- different data version,
- different environment,
- cache,
- configuration,
- permissions,
- browser,
- operating system,
- a case nobody anticipated before.
That is why a professional developer does not end analysis with the sentence: "It works on my machine."
They ask another question.
Why does it work on my machine but not elsewhere?
And that is when real debugging begins.
"It’s just a small change"
This is another sentence that brings a slight smile in most software houses.
The client says: "It’s just a minor fix."
The developer already knows that in a moment they will open a file that no one has touched for six years.
And that "minor fix" will turn out to be changes in five modules, three integrations and two databases.
That is why experienced developers approach the word "just" very carefully.
Most famous sayings from the industry
Every profession has its sayings. Developers do too.
A few of them almost everyone knows:
- "It works on my machine."
- "It’s just five minutes."
- "It’s not a bug. It’s a feature."
- "But I didn’t change anything."
- "It crashed in production."
- "Just one more deploy."
- "Definitely cache."
- "A quick fix before the weekend."
- "This should work."
And probably the most dangerous: "We’ll push this to production on Friday after 4:00 PM."
If you work in IT...
...you’ve probably just smiled.
A developer does not work alone
This topic is often overlooked. In reality, most projects are team efforts.
A developer collaborates with:
- UX designers,
- UI designers,
- project managers,
- testers,
- DevOps,
- administrators,
- analysts,
- clients.
Therefore, as important as technical knowledge are:
- communication,
- listening skills,
- knowledge sharing,
- responsibility,
- mutual respect.
The best code won’t save a project if the team cannot collaborate with each other.
Glossary
Code Review
The process of having code reviewed by other developers before deployment. It aims to improve code quality, detect bugs and share knowledge.
Pull Request (PR)
A proposal to introduce changes to a project. This is the stage where Code Review most often takes place.
Clean Code
An approach to writing code whose main goal is readability, simplicity and maintainability, not the number of applied design patterns.
Debugging
The process of finding and removing the causes of errors in an application.
Cache
A mechanism that stores data temporarily to speed up application performance. It is also often the source of many puzzling issues during testing.
Summary
The longer we work as developers, the more we come to one conclusion. The best developers are not those who make the fewest mistakes.
The best developers can:
- find the root cause of a problem faster,
- draw conclusions,
- learn from others,
- accept constructive criticism,
- continuously develop their craft.
So Code Review is not an obstacle. It is one of the most valuable lessons you can receive at the start of your career.
In the final part of our series we will talk about the path from Junior to Senior. We will explain why a Senior Developer is not someone with ten years of experience, but someone who can take responsibility for a project, think in business terms and help other team members grow.
