Career
Work-Life Balance as a Developer: What Nobody Tells You Until You're Already Burned Out
March 202610 min read
Career
Developer culture glorifies overwork. Shipping at 2am, 'just one more feature', the mythology of the 10x engineer grinding through weekends. I've been seduced by this at various points — late nights debugging, weekend deep-dives into a new framework, skipping social plans because 'I'm in the zone.' Now in my final year at Swiss German University while working part-time at Commsult Indonesia, I've had to get serious about work-life balance not as an abstract principle but as an operational necessity. Here's what I've learned from doing it wrong first.
Software development is particularly susceptible to overwork for structural reasons: the work is intrinsically interesting (you can always find one more thing to optimize or learn); the results are invisible to others (unlike physical fatigue, mental exhaustion isn't visible until it's severe); and the culture rewards visible productivity (commits, PRs, Slack activity) in ways that incentivize long hours over sustainable pace. The Indonesian tech work culture adds a layer: startup culture imported from Silicon Valley — 'hustle', 'move fast', '996' (9am to 9pm, 6 days a week) — has taken root in Jakarta's startup scene and is normalized in ways that can erode boundaries gradually before you notice.
Developer burnout doesn't always look like collapse. More often it looks like: loss of curiosity (you stop wanting to learn new things, which is unusual for a developer); decreased code quality (more careless bugs, less careful design); social withdrawal (canceling plans because 'I need to catch up'); and a specific kind of exhaustion that doesn't resolve with sleep. I've experienced lighter versions of these during crunch periods — exam season + work deadlines + side project commitments all overlapping. The signal I now watch for is when programming stops being interesting. That's usually the first sign that something needs to change.
My particular work-life balance challenge is the triple demand: university coursework (SGU has demanding final-year requirements), part-time work at Commsult (real deliverables, not just learning), and side projects (portfolio, blog, experimentation). Each is valuable. Together they can consume every waking hour if you let them. The solution I've arrived at — not perfectly executed, but directionally correct — is treating them like budget categories: a fixed allocation of hours per week, not an open-ended commitment. University gets 20 hours/week. Work gets 20 hours/week (I'm part-time). Side projects get whatever remains after I've slept 7+ hours and exercised.
Weekly Time Budget (Final Year Student + Part-Time Dev)
─────────────────────────────────────────────────────────
Allocation Hours/week Notes
─────────────────────────────────────────────────────────
Sleep (7h/night) 49 Non-negotiable foundation
Lectures + study 20 SGU final year coursework
Part-time work 20 Commsult Indonesia (DevOps/ERP)
Personal + social 30 Family, friends, exercise
Side projects 8 Protected weekend mornings
Admin + commute 21 Meals, transit, daily tasks
Unstructured 8 Buffer — do not schedule
─────────────────────────────────────────────────────────
Total: 156 (of 168 hrs available/week)
─────────────────────────────────────────────────────────
Rule: protect sleep and personal time first.
Everything else fits within what remains.Implement a weekly shutdown ritual: every Friday, spend 15 minutes writing down everything that's in progress, what the next step is, and whether it needs attention before Monday. Then close the laptop and genuinely stop until Monday morning. This ritualized stopping is harder than it sounds for developers — there's always something you could do. But the mental decompression from truly stopping is what prevents the slow accumulation of stress that leads to burnout. Saturdays are for humans, not computers.
The work-life balance advice that works for me as a developer: time-blocking by context, not by task (I block 'deep work' times and 'admin/meetings' times — tasks flow into the appropriate block rather than fragmenting the day); building in transition time between work and personal time (a 20-minute walk after closing the laptop before joining family or social events — this physiological break helps context-switch out of work mode); and separating 'interesting problem' time from 'productive work' time. The interesting problem time — exploring a new framework, reading about a new concept — gets done in my personal time and isn't counted as work. This prevents the blurring where everything feels like work.
This sounds obvious but isn't practiced: physical health is the foundation that makes sustainable developer output possible. Jakarta's sitting-heavy lifestyle (commuting in cars, working at desks, long screen hours) is particularly hard on backs, eyes, and circulation. I do 30 minutes of physical activity most mornings — not because I'm a fitness fanatic but because I notice the cognitive difference on days I do vs. don't. Eye health: the 20-20-20 rule (every 20 minutes, look at something 20 feet away for 20 seconds) is legitimate — I have colleagues who've developed serious eye strain from unbroken screen time. Posture and ergonomics matter more than most developer blogs acknowledge.
# Friday shutdown ritual (15 min — non-negotiable)
shutdown_checklist = [
"Review open PRs and add next-step comments",
"Update task board: what's done, what's blocked",
"Write 3-bullet summary: did / blocked / next Monday",
"Set Slack status to away until Monday 08:00",
"Close all browser tabs related to work",
"Close laptop lid. Do not open until Monday.",
]
# Burnout early-warning signals to watch for
burnout_signals = [
"Programming stops being interesting",
"Making careless mistakes you normally wouldn't",
"Dreading opening the laptop in the morning",
"Social withdrawal (canceling non-work plans)",
"Sleep that doesn't restore energy",
]
# If 3+ signals present: take a recovery day. Not optional.
Indonesian work culture has specific pressures worth naming. Family expectations around career trajectory and financial contribution create external pressure that many Indonesian developers don't discuss openly but that significantly affects their work intensity. Showing parents that the tech career is paying off — by always appearing busy, productive, and succeeding — can drive overwork as much as any intrinsic motivation. Navigating this is personal, but naming it is the first step: the pressure to always be working is partly external, and those external sources can be addressed directly rather than by working harder.
Many developers carry a backlog of side project ideas they feel guilty about not working on. This guilt is a specific type of work-life balance problem: not overwork, but the cognitive load of undone ambitious projects. The solution isn't to work more on them — it's to either commit to them on a realistic schedule or explicitly deprioritize them. An idea that 'I'll work on when I have time' will never have time. Either put it on the schedule or put it on a 'someday maybe' list that you review quarterly and prune ruthlessly. Reducing the guilt backlog is a work-life balance intervention.
If you work remotely — or even hybrid, which is common in Jakarta tech after COVID — the physical boundary between work and home dissolves. The laptop is always there. Slack notifications arrive at dinner. The temptation to 'just check something quick' at 10pm is constant. The tactics that create artificial boundaries: a dedicated work space (even if it's just a specific chair and specific lighting), explicit work start and end times, and notifications turned off outside those times — not on silent, off. The psychological effect of never truly being off-call is cumulative and significant.
Work-life balance isn't a state you achieve — it's a system you maintain through ongoing attention. Some weeks will be worse than others. Crunch periods are real. The goal isn't to never work hard — it's to make intense periods temporary and recovery intentional. The developers I admire who sustain long careers without burning out treat recovery like a professional obligation, not a luxury. They take vacations completely (no Slack, no PRs). They have interests outside programming that genuinely engage them. And they've internalized that the quality of their best work hours matters more than the quantity of all their hours. That's the mindset worth developing.