I have mentored more than ten engineers over the last few years. Some went on to become exceptional technical leads, while others stayed roughly where they started. The difference was rarely raw talent.
It was almost always their habits.
Specifically, it comes down to how quickly someone learns from what they build. When two engineers start with similar backgrounds, the one who asks better questions, writes clear notes, and reflects on past mistakes will grow much faster over three or four years.
Here are a few habits that distinguish engineers who keep improving from those who get stuck.
They write code for the next reader
Write for the person who has to maintain your code later. That person might be your teammate next month, or it might be you six months from now when a production alert goes off.
This sounds obvious, but it is easy to test: pull up a pull request from three months ago. Can you understand why changes were made without digging through old Slack threads?
Engineers who write for future readers choose descriptive variable names that show intent. They leave comments explaining the reason behind an unusual workaround rather than describing obvious syntax. Their error logs tell you what went wrong and how to fix it instead of printing generic errors.
It can feel slightly slower while typing, but it saves hours during every subsequent code review, bug hunt, and onboarding session.
They use code reviews to teach and learn
There are two ways people approach code reviews.
The first is mechanical: glance through the diff for typos, approve it, and move on to your next task.
The second is collaborative: treat each review as a window into how your teammate thinks, and an opportunity to discuss design choices together.
Strong engineers ask open questions during reviews: "What led you to choose this approach over caching the result earlier?" When they suggest changes, they explain the context: "If we split this helper function now, adding the new payment provider next sprint will be much simpler."
It takes a few extra minutes per review, but it builds team-wide shared context quickly.
They clarify requirements before writing code
One habit I try to encourage early on: do not start coding in the first hour of getting a new feature ticket.
Spend that time understanding the core problem. What are we trying to solve? What are the edge cases? What is explicitly out of scope?
I have seen developers spend an entire week building exactly what was written on a ticket, only to realize the original request missed what the business actually needed. The real cost was not just the wasted sprint; it was the confusion of building the wrong solution.
Good engineers ask questions early so ambiguity gets sorted out before code is written.
They are comfortable admitting uncertainty
Junior developers often hesitate to ask questions because they worry about looking inexperienced. That hesitation is completely normal, but it gets expensive when unresolved questions turn into hidden bugs down the line.
The healthiest teams make it safe to say, "I am not sure how this piece works yet." Being honest about what you know and where you need a second pair of eyes is a sign of engineering maturity.
I make a point to model this openly. If I do not know how an external API behaves, I say, "I am not sure yet, let me test it out first."
They know when a solution is ready to ship
Some developers struggle to finish tasks because they keep finding one more micro-optimization to tweak. While attention to detail is valuable, delaying releases indefinitely often leads to diminished returns.
Experienced engineers know the difference between a correctness bug that must be fixed, a clean-up task that can be scheduled later, and a cosmetic preference. They can ship solid, reliable code today because they recognize the value of getting feedback from real users.
Building a culture that compounds
When conducting 1-on-1s and reviewing architecture plans, I focus heavily on these daily practices. Framework details and syntax are easy to look up; strong problem-solving habits are what determine how effectively someone uses that knowledge.
The engineers who grow fastest are curious about their own progress. They look back at code they wrote six months ago and spot ways they would improve it today. That continuous loop of trying, reflecting, and refining is how great engineering careers are built.