The Habits That Make an Engineer Worth Routing Work Through

The habits of great software engineers are mostly about reliability

Every team has one or two engineers other people route work through. They are not always the strongest technically, though they are usually quite strong. What they have in common is simpler: when something is given to them, it comes back, and if it is not going to come back on time, you hear about it early rather than late. When people talk about the habits of great software engineers, this is what they are describing, even when they use words like "senior" or "ownership".

That reputation compounds faster than technical depth does. It decides which projects you are offered, whose opinion gets asked in a design discussion, and eventually what you get promoted for. And it is made almost entirely of habits that are unglamorous and completely learnable. None of them need a title, permission or a supportive manager, which is exactly why they are worth building early, whether you are in your first job at a software house in Lahore or on a remote team spread across four time zones.

Below are fifteen of them, written as situations and the default you want in each.

Why reliability beats raw talent on a team

This is not just my opinion from years of working on teams. When Google studied what made its teams effective in Project Aristotle, it looked at 180 teams and found that who was on a team mattered less than how the team worked together. Psychological safety came first. Second was dependability, which Google defines as members who "reliably complete quality work on time" rather than shirking responsibilities.

Microsoft Research asked a related question from the individual side. In What Makes a Great Software Engineer?, researchers interviewed 59 experienced engineers across 13 divisions and identified 54 attributes of great engineers. A large share of them were not about raw coding ability at all, but about decision making and the effect an engineer has on the people and products around them.

So when a student asks me what makes a good software engineer beyond writing code, my answer is: the habits below, practised until they are boring.

Fifteen habits of great software engineers

Being easy to work with

1. Resolve ambiguity before you build. Thirty minutes of questions at the start beats a week of work aimed at the wrong target. The fear that asking looks uninformed is backwards: asking early looks careful, and asking on the day it is due looks like something else entirely. If requirements are genuinely fuzzy, my answer on what to do when your manager gives vague requirements has a simple script for it.

2. Estimate in ranges, and say what would narrow them. "Three to eight days, and I will know which after I have looked at the export path" is a genuinely useful sentence. A single confident number is a promise you cannot support, and people plan around it as though you could. Ranges are not a sign of weakness. They are honest information about uncertainty.

3. Surface a blocker the same day. Blockers do not improve with age, and their cost is almost entirely in how long they stay invisible. Nobody has been thought less of for flagging a dependency on Tuesday. Plenty have been for revealing on Friday that Tuesday was already lost. If this feels uncomfortable, read how to say you are blocked without looking incompetent.

4. Announce a slip as soon as you can see it. The damage from a missed date is rarely the date itself. It is that other people planned around something that was quietly not going to happen. Early bad news is a favour and it is received that way. The same logic applies to mistakes: if you break something, say so first and fix it second, which I cover in made a mistake in production: tell your manager or fix it first.

The work itself

5. Ship something small and real in your first week. A tiny fix, deployed properly, end to end. You learn the build, the review process, the deploy path and the people, which is most of what slows a new joiner down, and you do it while expectations are still low. My first 90 days in a new developer job answer builds on this, and what actually happens between your pull request and production explains the pipeline you are learning.

6. Deliver visible increments on long projects. Three months of heads down work followed by a big reveal is a bet that nobody's understanding changed in the meantime. Something demonstrable every week or two lets the direction be corrected while correcting it is still cheap. It also means your work exists in other people's heads, not only in your branch.

7. Keep notes while you debug. A running list of hypotheses and results stops you testing the same theory twice at hour four. It also turns straight into the pull request description, the postmortem note and the answer for whoever hits the same issue next month. If you want to get better at the debugging itself, see how to get better at debugging without asking AI first.

8. Do the thing that unblocks other people first. Your own throughput is worth less than the team's. The task with three people waiting behind it outranks the more interesting task that only you care about, every time. Choosing that way is noticed quickly, and it is one of the clearest signals that you think about the team rather than your own ticket list.

Reviews, in both directions

9. Label which review comments block the merge. Say plainly which comments are required and which are preferences the author may ignore. Reviews stall mostly because nobody can tell the difference, and an author who cannot tell treats everything as mandatory and resents all of it. Google's public code review guide recommends exactly this, with labels like "Nit", "Optional" and "FYI". The whole guide is in the library as Google Engineering Practices, and how to give code review feedback without creating conflict covers the tone side.

10. Separate yourself from the diff when you receive feedback. The reviewer is describing the code, not you, even when the wording is graceless. Engineers who take review well get more of it, which means they improve faster, which is the entire mechanism. If a comment is unclear, ask why instead of complying silently. The answer is usually context you did not have.

11. Give juniors the method, not the answer. Where you would look, how you would narrow it down, what the error is really saying. Handing over the answer solves today at the cost of the same question next week. The method is the part that transfers, and teaching it is how you start to multiply your impact.

Being known for it

12. Write the meeting summary nobody else writes. Four sentences: what was decided, why, who is doing what, and by when. It takes five minutes, prevents the same discussion recurring in a month, and the person who writes it has a quiet and disproportionate influence over what the decision is remembered as. If you are the quiet one in meetings, this is also the easiest way to be heard, which I wrote about in will being quiet in meetings hurt my engineering career.

13. Write the document the third time you answer the same question. Answering repeatedly feels helpful and scales to nobody. A short page you can link to is worth more than the twelve conversations it replaces, and documentation keeps working while you are asleep. The free Google technical writing courses are the fastest way I know to get noticeably better at it.

14. In an incident, let one person coordinate. Someone holds the timeline and says who is looking at what, and that person is usually not the one deep in the logs. Uncoordinated help is how three engineers independently restart the same service. Volunteer to coordinate once you know the system; it is one of the fastest ways to earn trust across a team.

15. Send a short weekly note. What shipped, what is in progress, what is blocked. This is not self promotion. It removes the need for anyone to ask, and it means that when your work is discussed in a room you are not in, there is an accurate account of it available.

How these habits look from the outside

The reason these habits matter is what other people experience when you practise them, and what they experience when you do not.

Notice that nothing in the left column requires you to be the cleverest person on the team. That is the good news.

Habits that are harder than they sound

A few more belong on any honest list of habits of great software engineers, and they are harder than the fifteen above because they involve saying something uncomfortable.

• Saying no properly. This mostly means saying what would have to move for the new thing to fit, rather than refusing outright. "I can take this if the export work moves to next sprint, which would you prefer?" is a no that keeps trust.
• Finishing things. A trail of ninety percent complete projects is the most common reason strong engineers stall. The last ten percent (tests, docs, the cleanup, telling people it exists) is where the value becomes real.
• Leaving code slightly better than you found it. At a rate the reviewer can absorb, not as a surprise refactor inside a bug fix. My post on six rules that keep a codebase worth working in goes into what "better" means. If you want a shared vocabulary for design conversations in review, Grokking SOLID Design Principles is a compact way to get it.
• Answering the question that was asked. It sounds trivial. In practice a great deal of frustration on teams comes from someone asking whether the deploy is safe and receiving four paragraphs about the caching layer. The engineers people rely on answer first, then explain.

How to be a reliable software engineer: a four week plan

Habits stick when you add them one small group at a time. This is the order I would suggest.

When you eventually change jobs, these habits become your best stories in behavioural rounds, because they come with specific situations and outcomes. Grokking Modern Behavioral Interview is a good guide to turning them into clear answers, and my answer on how to become an engineer your team trusts goes deeper on the trust side.

Learn it on Sefism

• Career growth roadmap and the career growth cheat sheet
• How to become an engineer your team trusts
• Twelve moves that take you from mid level to senior for what comes after these habits
• The Missing README, a practical book for new engineers on exactly this kind of work
• Google Engineering Practices for code review done well
• Grokking Modern Behavioral Interview for turning these habits into stories when you change jobs

FAQ

What are the habits of great software engineers?

Clarifying before building, estimating in ranges, flagging blockers and slips early, shipping small increments, reviewing kindly and clearly, unblocking others first, and writing things down. Most are about reliability rather than raw technical skill.

How can I be a more reliable software engineer?

Tell people about problems as soon as you see them, give estimates as ranges, and deliver something visible every week or two. Reliability is less about never slipping and more about nobody being surprised when you do.

Are soft skills more important than technical skills for software engineers?

You need both, but technical skill is the entry ticket and soft skills decide how far you go. Google's Project Aristotle found how a team works together mattered more than who was on it.

How do I give code review feedback without upsetting people?

Label each comment as blocking, optional or a nit, explain the reason behind required changes, and comment on the code rather than the person. Approve improvements even when they are not what you would have written.

How long does it take to build a good reputation on a new team?

Usually a few months of consistent behaviour. Shipping something small in your first week and flagging problems early from day one speeds it up considerably.

Ask your own question

If your situation is different from the ones above, the career questions library has honest answers to the questions students and engineers ask me most.

Want a learning roadmap built around you, written answers to your own questions and a place to talk through what is happening at work? Create your free Sefism account. Members can also book a one to one session when they want to talk it through.

Stay in touch

• LinkedIn: where I share roadmaps, career advice and honest takes on hiring. Follow, or message me.
• X (Twitter): short practical thoughts on engineering and careers.
• Instagram: quick tips and a more personal side.
• Sefism Discord: meet other students and engineers working through the same job market and share what is working.
• Sefism on YouTube: walkthroughs and talks.