Code is the tool, not the job. A good engineer solves the right problem, makes changes that are safe to ship, communicates clearly, finishes what they start, and leaves systems and teammates better than they found them. These are learnable habits, and they matter more to your growth than any single framework.
What people tell me
I can write code and I am learning new frameworks, but I keep hearing that being a good engineer is about more than code. People mention ownership, communication and judgement, and I do not really know what that looks like in practice. I want to know what I should actually work on if I want to be seen as a strong engineer, not just someone who completes tickets.
A composite of the messages behind this question, with personal details left out.
Key takeaways
- The job is solving problems for people. Code is how you do it, and sometimes the best solution is less code.
- Good engineers understand the why before writing the how, and ask when it is unclear.
- Shipping safely matters as much as shipping: tests, small changes, monitoring and a way back.
- Clear writing is an engineering skill. Pull request descriptions, updates and design notes all count.
- Reliability builds trust: finish what you start, and say early when you cannot.
The job is not writing code
If you ask a company why they hired engineers, nobody says "to produce code". They say they want to solve problems for customers, keep the product working, and move faster than competitors. Code is the tool for all of that, and like any tool it can be used well or badly.
This shift in view changes what "good" means. A good engineer is someone the team can hand a problem to and trust that it will be understood, solved sensibly, shipped safely and explained clearly. Writing the code is one step in that chain, often not the hardest one.
Six things good engineers do
When I think about the engineers I most want on a team, they share these habits:
| Habit | What it looks like day to day |
|---|---|
| Understands the problem | Asks who this is for and what success looks like before starting |
| Chooses simple solutions | Picks the boring, maintainable option unless there is a real reason not to |
| Ships safely | Small pull requests, tests where they matter, thinks about rollback |
| Communicates clearly | Writes good PR descriptions, gives updates before being asked |
| Finishes things | Handles the edge cases, documentation and cleanup, not just the happy path |
| Makes others better | Reviews carefully, shares what they learn, answers questions kindly |
None of these depend on a specific language or framework. All of them can be practised from your first week.
Understanding the why
The most expensive mistake in software is building the wrong thing well. Before starting a task, a good engineer can answer three questions:
- What problem is this solving, and for whom?
- How will we know it worked?
- What is explicitly out of scope?
If you cannot answer them, ask. A two-line message such as "Before I start, is the goal to reduce failed payments, or to show clearer errors when they fail? The approach is different" saves days of rework and shows judgement.
Shipping safely
Anyone can push code. Good engineers think about what happens after:
- Keep changes small. A two-hundred-line pull request gets a real review; a two-thousand-line one gets a skim.
- Test the parts that would hurt. Not everything, but money, data, permissions and anything that has broken before.
- Think about failure. What happens if the external API is slow, the input is empty, or the job runs twice?
- Know how to undo it. A feature flag, a migration that can be reversed, or at least a plan.
- Check it in production. Look at logs or metrics after release rather than assuming it worked.
Communication is part of the engineering
Many technically strong people stall because nobody knows what they are doing or why. Writing well is not a soft extra. It is how engineering decisions spread through a team.
Practise on small things. A good pull request description says what changed, why, how you tested it and what reviewers should look at closely. A good status update says what is done, what is next, and what is blocking you. A good question shows what you already tried. These take minutes and change how people see your work.
Ownership without heroics
Ownership does not mean working all night or doing everything alone. It means that when something is yours, people do not have to chase it. You follow up on the bug you reported. You update the ticket when plans change. You say "I will not make Thursday, here is why, and here is what I can deliver" on Tuesday rather than Friday.
This is the quality managers mention most when describing engineers they trust, and it is entirely about behaviour, not talent.
How to practise this before you have a job
You do not need a team to build these habits:
- Write a README for each project that explains the problem, the decisions and the trade-offs.
- Use pull requests on your own repositories, with descriptions, even when you merge them yourself.
- Add basic tests and error handling to one project instead of starting a new one.
- Contribute a small fix to an open source project and go through a real review.
- Explain one of your projects to a friend who is not technical. If they understand the problem it solves, you understand it too.
In a hiring conversation, these are the things that make you sound like an engineer rather than someone who followed tutorials.
If you are still stuck
Read The Habits That Make an Engineer Worth Routing Work Through, Six Rules That Keep a Codebase Worth Working In and What Actually Happens Between Your Pull Request and Production. If you want someone to look at your specific situation, join Sefism and, as a member, book a 1:1 session.
Was this answer helpful?
Read next
- The Habits That Make an Engineer Worth Routing Work ThroughEvery team has one or two engineers other people route work through, and what they have in common is not raw technical strength. It is that when something is given to them it comes back, and when it will not, you hear about it early. Fifteen habits that build that reputation, none of which require a title or permission.
- Six Rules That Keep a Codebase Worth Working InEvery one of these gets quoted as an acronym in code review, usually by somebody who read the expansion and not the reasoning, and applied without judgement they produce worse code than if nobody had heard of them. Separation of concerns, DRY, KISS, YAGNI, test driven design and writing for the next reader, each with the thing it protects against and the way it goes wrong.
- What Actually Happens Between Your Pull Request and ProductionMost engineers learn CI/CD as a sequence of buttons rather than a system, which works right up until the pipeline goes red and nobody knows which stage failed or why it matters. The five stages walked through one at a time, what each is protecting you from, why builds pin their versions, the difference between rolling, blue green and canary releases, and the ten second skill of reading a failed stage.
Your situation is not quite this one?
Members get written answers to their own questions, a roadmap built for them and feedback on their projects. Early access is open to X and Instagram followers and university students. Prefer to talk? A free call works too.