7 Years as a Software Engineer: What Actually Changed πΌ
25 Mar, 2026 β’ 4 min read
Seven years in software: from green builds that still felt wrong to owning ambiguity and scope. Honest notes on career, craft, and what still feels hard.
Listen
Playback speed
Green build. Staging fine. I still walked away feeling off π»
The code did what we agreed on. The agreement was the broken part. That week stuck with me more than any refactor I have shipped since.
Seven years in, I still write code. I also still Google things I have looked up a hundred times, and I am fine admitting that. The job stopped being mostly syntax ages ago. It moved into requirements nobody wrote down, roadmaps that pretend six things are one thing, and the gap between what product imagines and what the system can honestly do. You feel that gap in your calendar before you feel it in the compiler.
I am not going to give you a promotion timeline or a framework bingo card.
Here is what moved in how I work, and what I would say to the version of me who was scared of sounding dumb in standup π
π§ The first shift: when βit runsβ is not the win
Early on I treated success like a checklist. Tests pass β
PR merged. Done. That bar matters. You cannot skip it.
The first time it failed me was ordinary. Everything behaved in staging, users were still unhappy, and the bug was the assumption behind the feature, not a null pointer.
These days I slow down before I type. Who is this actually for? What happens at 10x traffic? What is the cheapest way to prove we are wrong? I used to think those questions were someone elseβs job.
They are the job π―
Hackathons taught me scope is the real villain π Side projects taught me demos follow their own physics. HackerRank taught me the expensive problems sit between intent and reality. Same muscle, different costumes.
π«οΈ Ambiguity stopped feeling like a personal failure
Junior me assumed if I asked enough questions in one Slack thread, uncertainty would pack up and leave.
It does not work that way. Some fog only lifts after there is a real thing to poke at.
I stopped pretending I had it all figured out on day one. I try to pick a step we can undo, say the tradeoff out loud, and invite correction early. A rough prototype still beats a three-day thread. A written assumption beats a silent guess every time βοΈ
I mentored at a hackathon once, on the other side of the table. The struggling teams were rarely lazy. They were drowning in parallel goals π Helping them kill features felt like coaching courage, not debugging. I still use that instinct when a roadmap tries to ship six epics like they are one.
βοΈ Speed, quality, and the lie of having both for free
You have heard both sermons.
Move fast and break things. Quality is non-negotiable. Real teams live in the middle and rarely say the quiet part out loud.
What helped me was naming the tradeoff in a room full of people. If we optimize for learning speed, we accept rough edges and we instrument them. If we optimize for reliability, we skip shortcuts and we staff for that choice. The painful failure mode is when leadership says one priority and the calendar and incentives say another. Then you get slow and brittle together.
No prize π₯
I still misread that alignment sometimes. I just catch it faster.
Sounds tiny. It cost a lot of Tuesday evenings to get there π©Ή
π¬ Communication is not fluff. It is part of the ship.
I am not the person who βonly wants to code.β Not because I love calendars π
Because when alignment drifts, it shows up as reverts, sharp tickets, and that quiet distrust nobody puts in writing.
A decent PR description. A diagram someone can find next month. A short note on why we picked this shape. Those things feel soft until you pay for not having them.
When I built this portfolio in public, I realized people read the thinking, not only the pixels. Same thing shows up in code review and design feedback. They are judging whether they can trust your judgment.
π§ Competence and confidence refuse to stay in sync
Call it imposter syndrome or call it a brain that loves your mistakes more than your wins.
Same glitch.
I stopped waiting for the doubt to vanish. I keep boring receipts now. What shipped. What broke. What I fixed. What someone else shipped because I unblocked them.
Loud moments under pressure helped once. They do not cure anything. They just remind you that you have done hard things before. Without the small receipts, one bad deploy on a random Tuesday eats the whole story π
π§° What actually aged well
Syntax turns over. Tools churn π
The skills that kept paying were unglamorous. Reading a stack trace without ego. Tracing a bug across services and saying which layer lied π Knowing when a library saves time and when it hides the learning you still need.
Any fool can write code that a computer can understand. Good programmers write code that humans can understand.β Martin Fowler
I still enjoy a gnarly bug.
I enjoy it less when the gnarl exists because nobody wrote how the system is supposed to behave. Docs are not admin homework. They are kindness to whoever is on call at 11 PM π Future you counts.
π€ Leadership without the title
Influence is not a level on a ladder.
It shows up in a clearer ticket, a safer rollback plan, a review comment that teaches instead of scores points. Sometimes it is saying I do not know when everyone else is improvising confidence π€·
I have spent five years at HackerRank now π± Sustained product engineering, for me, is not heroics. It is ownership. It is the quiet work of keeping a platform understandable while it grows.
βοΈ What I would tell past me
Ask earlier. Ship smaller. Write down why you chose something, not only what you built.
Guard your attention the way you guard uptime, because it is the same finite resource.
Busy is not the same as useful. I am still learning that last one β³
πͺ¨ What still feels hard
Saying no without becoming the villain in someone elseβs story. Estimating when the information is incomplete, without faking precision. Staying curious when the backlog is shouting. Remembering the win is not owning the thread. It is leaving the system less confusing than you found it.
Seven years is not mastery π
It is enough repetitions to spot the same traps: fake urgency, complexity sold as intelligence, teams confusing motion for progress. Enough time, too, to feel grateful for people who raised the bar π and a little gentler with myself when I was the bottleneck.
If you are earlier in the curve, the takeaway is smaller than everyone makes it sound.
Show up. Say the risky true thing. Make the next step obvious. Keep building.
The code is only one part of the craft β¨