Is development the right career for me?

That Slack message from someone on my team — dropped at 11 p.m. right after our deployment window — read: “Is development even the right career for me?” I’ve whispered the same line to my coffee mug more times than I’d like to admit, usually after the CI pipeline flames out for the fourth time in a row.

I don’t have a one-size-fits-all answer. Every job, from surgery to carpentry, comes with its own brand of headache. We’re all just picking the least irritating set of problems and hoping the upsides outweigh the Sunday-night dread. (I should be upfront — this is based on 15-ish years of my own trial and error, not a survey of many careers.)

Your career, your rules. Decide how much of yourself you’re willing to trade for a paycheck and a dopamine hit from green tests. Some weeks you’ll play overtime hero; other weeks you’ll log off at 5 and go climb a wall or bake sourdough. The sliders move, and you’re the only one holding the controller.

The myth persists that “real” engineers eat, sleep, and breathe code. Bootcamps love that line. So do conference keynotes. I don’t buy it — or at least I no longer buy the idea that everyone has to fit that mold. Plenty of brilliant developers close the laptop at quitting time and refuse to think about pointers until Monday. Others hack microcontroller firmware for fun on Saturday mornings and come back to work refreshed. Both crowds ship valuable software.

Small correction to the old comparison I used to make: lawyers absolutely study off-hours. Most jurisdictions require continuing legal education, and my doctor friends cram for certifications on their own time too. The difference is that JavaScript frameworks mutate monthly while contract law ambles along — but nobody is entirely spared from homework.

About that manager who wonders why your GitHub graph goes gray on weekends: the question might be genuine concern (“Are you bored?”) rather than judgment (“Why aren’t you coding?”). If weekend tinkering lights you up, fantastic — hobby projects can sharpen skills and, honestly, feel like play. If you’d rather paint miniatures or binge Korean dramas, that’s equally fine. I’ve seen seniors on both ends of the spectrum, and I can’t correlate either habit with code quality in any rigorous way.

Tools and frameworks will keep multiplying. Today it’s Bun, yesterday it was Deno, tomorrow it’ll be something with an even cuter mascot. You don’t need to ride every wave; you do need to spot the ones that threaten to swamp your boat. Development extends far beyond web stacks anyway — robotics, medical devices, climate research, even art installations need people who can bend silicon to their will. Picking one of those directions can buy you years of stability and some fascinating dinner stories.

I’ve also watched folks step away from full-time coding and later leverage that knowledge in hybrid roles: product managers who can still read logs, researchers who automate lab equipment, founders who understand just enough to talk to the “wizard” in the corner without feeling helpless. Walking out of the IDE doesn’t mean locking the door forever.

Where possible, push for exploration on company time. Suggest a Friday spike, run a tiny proof-of-concept, lobby for conference budgets. Management usually prefers structured learning over surprise production incidents — frame it that way and you’ll get more yeses than you expect. (I could be wrong, but this has worked in three different teams I’ve run.)

One last note on the P-word: passion often trails competence, not the other way around. Cal Newport’s “So Good They Can’t Ignore You” makes the argument better than I ever could. In my experience, mastery builds momentum, and momentum feels a lot like love for the craft. So keep sharpening, at whatever cadence keeps you sane, and see where that leads. The question of “Is development right for me?” may never vanish entirely — but it does get quieter when the features you ship start to sing.