There's a quiet trap in software engineering careers. The job is built around continuous output — features, tickets, releases — and the cadence rewards engineers who say yes, ship fast, and don't push back. In the short term that looks like high performance. Stretch it out over five or ten years and it looks like burnout, shallow expertise, and a strange feeling that you've been very busy without ever getting much better at your craft.
I've watched this play out in myself and in colleagues, and I've spent the last few years deliberately rearranging how I work to avoid it. This is a collection of the things that have actually helped. Some of it is about boundaries with management, some about time, some about calendars, some about the messy reality of doing knowledge work in a personal life. None of it is revolutionary. All of it is the kind of thing that's easy to know and hard to do.
Learn to say no
The single most important professional skill I've developed in the last decade is the willingness to argue with my manager. Not constantly, not aggressively, not on small things. But on the things that matter, where I think the team is making a mistake, I push back. And I keep pushing back until either I'm convinced I was wrong or my concerns are genuinely engaged with.
This is harder than it sounds, and it's especially hard if you come from a culture where deference to seniors is the default. I grew up in India, where respecting elders and authority figures is taught from childhood: at home, at school, at college. That's a beautiful value in many contexts. In a corporate environment, when it crosses over unexamined, it becomes a career-limiting habit.
Respecting someone and agreeing with them are different things. You can respect your manager deeply and still tell them, in clear professional language, that the decision they're proposing is wrong. The two are not in conflict. Treating them as if they were is what produces the engineer who quietly executes bad ideas for years.
The mechanics of saying no well are worth thinking about. It's not "no, that's a bad idea." It's "I'm not sure that's the right approach, and here's why. Can we talk it through?" It opens a conversation rather than closing one. It assumes your manager is reasonable and acting in good faith, which is usually true. And critically, it makes it possible for them to update without losing face, which is what most people actually need in order to change their mind.
Engineers who never push back end up with two career problems. They build a reputation for shipping things even when the strategy is wrong, which gets them associated with the failure when it lands. And they slowly lose the muscle for independent technical judgment, because the muscle atrophies when you stop using it. The senior engineers I respect most are the ones who, kindly but firmly, say no when no is the right answer.
The time math nobody teaches you
The other shift that mattered for me was getting more deliberate about how I split my working hours. Management wants new features shipped 100% of the time. That's not malicious — it's just what their incentives reward. But humans aren't built to operate at 100% feature delivery, and engineers who try to do so end up shallow, burned out, and slowly less useful over time.
Ironically, AI is built to operate that way. Constant output, no learning curve, no fatigue. Management has noticed, which is part of why AI is being pushed into every workflow. But the lesson I draw from that isn't "engineers should become AI agents." It's the opposite: we should lean into the things AI can't do, and we should grow ourselves in ways that compound over a career rather than burn ourselves out delivering one feature at a time.
Here's the split I've landed on. Adjust the percentages to your context, but think of it as a starting point rather than a prescription.
The 20 / 20 / 20 / 40 split
Self-growth 20%
Learning new things, reading papers, exploring tools, side experiments. Curiosity is what turns a naive engineer into an informed one.
Technical debt 20%
The refactor you never got to. The flaky test. The crash repro ticket gathering dust. The TODO you wrote six months ago.
Team multiplier 20%
KT sessions, unblocking teammates, improving processes, mentoring. Force-multiplies everyone else's 40%.
Shipping 40%
Actual feature work and product delivery. With AI, writing code is fast — reviewing it carefully is the real cognitive load.
The reaction I usually get to this chart is some variant of "there's no way I can spend 60% of my time on things other than shipping." I'd gently push back on that. The 40% I spend shipping is meaningfully more productive than it would be if I were grinding at 100%, because the other 60% feeds into it. Cleaning technical debt makes future shipping faster. Mentoring teammates raises the floor for everyone. Personal growth means I'm bringing better ideas to the table.
Spending 100% of your time shipping isn't a productivity strategy. It's a depreciation schedule. You're consuming a skill set you're not replenishing, and eventually the bill comes due.
Spending 100% of your time shipping isn't a productivity strategy. It's a depreciation schedule.
Calendar management is career management
The time math only works if you protect it on your calendar, and most engineers I know don't. Their calendars are reactive: meetings get added by other people, focus time gets fragmented, the few hours of deep work that actually move a project forward get pushed to the evenings or to weekends. That's not sustainable.
Four practical rules I've come to swear by:
Block a focus slot every day and mark it busy.
Two hours minimum, ideally in the part of your day where you actually think clearly. Not "open to interruption." Not "happy to be pulled into a quick sync." Genuinely blocked, on the calendar, marked busy, with the same authority any other meeting would have.
Reserve office hours so people can find you.
A predictable 1–2 hour slot where teammates know they can drop in. This isn't optional, because if you're invisible all day people will book meetings instead. Office hours are how you give availability without sacrificing focus.
15–20 minute standups are enough.
Daily standups exist to surface blockers, not to give status reports. If someone needs deeper unblocking, that's an office hours conversation, not a meeting that should be expanding from 20 minutes to 45.
Make tea breaks intentional.
Breaks are essential. They restore focus and they build relationships. But unstructured chit-chat sessions silently eat into focus time, and "let me get coffee with so-and-so" can quietly consume an hour you needed. Take breaks deliberately. Make them count.
Here's roughly what a good day looks like for me:
Calendar shape, not calendar content
The shape matters more than the exact times. Two real focus blocks. One predictable availability slot. Meetings clustered, not scattered. Breaks that I actually take.
The thing nobody tells you about calendar discipline: nobody else will protect your time. Your manager won't. Your teammates won't. The Jira board definitely won't. If you don't draw the lines, the lines don't exist, and your week becomes whatever other people decided your week should be.
Work-life balance, honestly
This is the part I find hardest to write about, because the honest answer is messy. I don't have clean 9-to-5 work hours, and I don't think most knowledge workers actually do.
The reality of software engineering is that the work doesn't always cooperate with office hours. I'll be stuck on a bug all afternoon. I'll go to bed. The solution will pop into my head right as I'm drifting toward sleep, and the urge to just test it real quick is so strong that I'll end up at my computer for 90 minutes at 11pm. That happens. It's part of doing creative technical work. Pretending it doesn't, or being precious about strict hours, isn't going to make me a better engineer.
What I do believe in are a small number of non-negotiable rules that keep the flexibility from turning into "always working." These have stood up across years of my career:
Flexible hours, fixed boundaries.
The version of work-life balance that gets sold to engineers is rigid: clock in, clock out, no exceptions. The version I actually believe in is fluid hours bounded by hard rules. The flexibility is what lets you do good creative work. The rules are what stops the work from eating everything else.
The long view
The connective thread through all of this is that a software engineering career is a marathon. Most career advice optimizes for the next year, the next promotion, the next perf cycle. Those things matter, but the engineers I've watched do this well — the ones who are still curious, still sharp, still excited about the work after twenty or thirty years — optimize for something different. They optimize for being someone who can keep doing this indefinitely.
That means saying no when no is right. It means refusing to spend 100% of your time shipping. It means treating your calendar like a deliberate artifact, not an inbox. And it means having boundaries strong enough that the flexibility of the work doesn't quietly consume the rest of your life.
None of this is anti-management. Good managers want their engineers to grow, to push back when it matters, to invest in technical debt, to mentor others. The problem is that most management systems incentivize shorter time horizons than is healthy for the people inside them. Your job, as the engineer, is to push the time horizon back out. That's not insubordination, that's the longest-running form of professional self-respect there is.
You're going to be an engineer for thirty more years. Maybe more. Spend at least a little of every week investing in the version of yourself who has to do it. Thanks for reading ✦
Comments