Habits of great software engineers

Tuesday night, somewhere between sip three and four of espresso, I caught myself rewriting the same helper function for the third time. That’s when it hit me: the job was never just the keystrokes. Code is the visible part, sure, but most of my day is conversations, design docs, ripping out dead logic, reading somebody else’s five-year-old Perl (why, past me, why?) and then—finally—writing a few solid lines. The brush isn’t the painting.

If every developer were reduced to a pure coder, we’d crank out syntax all day and still miss the point. Would any of it matter to the user? Probably not. The difference between shipping something useful and shipping random bytes usually comes down to habits that have nothing to do with the IDE.

So, habits. The bits that separate “pretty good” from “I want that person on every project.” I’ll barely touch on syntax here—other people teach that better—but I will talk about the behaviors I keep seeing in engineers who quietly raise the bar for everyone else.

TL;DR (because you might be skimming on a train with bad Wi-Fi) I cover:

1. Focusing beyond the code – coding sometimes eats 20 % of a week, sometimes 80 %. Depends on the team. Either way, pure typing isn’t enough.
2. Efficiency & antifragility – progress without fragility, no hero-sprints that break the next release.
3. Joy of tinkering – side quests keep the flame alive (balanced with screen-free time so you don’t fry).
4. Knowing the why – peek under the abstraction once in a while; the runtime has stories to tell.
5. Thinking in systems – your single line can nuke compliance. Ask how the puzzle fits.
6. Tech detox – keyboards off, brain on. Turns out sleep still debugs best.
7. The art of approximation – napkin math before cloud invoices eat the budget.

Purely subjective, based on two decades of messing things up first.

Focusing beyond the code

Yes, you need to write tight, readable code—entry ticket stuff. But the engineers I keep hiring obsess over everything around those lines: the pull-request narrative, the rollback plan, the person who has to maintain it at 02:00. They read code at least as much as they write it, occasionally deleting more than they add (that last bit took me years to appreciate).

I could be wrong, but I think empathetic communication beats raw LeetCode speed once a project crosses five people. Someone on my team spends a significant portion of their day reviewing and explaining. The net output? The whole squad ships faster because fewer bugs survive code review.

If you want pure coding drills, grab these classics—still the fastest way I know to sharpen the blade:

• Cracking the Coding Interview, McDowell [Amazon]
• Introduction to Algorithms, Cormen [Amazon]
• Clean Code, Martin [Amazon]
• Coders at Work, Seibel [Amazon]

(No affiliate magic here—links are plain old hyperlinks.)

The Pursuit of Efficiency

Efficient engineers create this weird aura—projects glide instead of grind. One colleague of mine still codes 80 % of his week (small infra team, tight scope). Another writes maybe 10 % and spends the rest unblocking eight juniors. Both feel fast because progress never stalls around them.

I’m not pushing hustle culture. I mean antifragile flow: short feedback loops, buffers for the unknown, graceful degradation when prod catches fire at 03:00. Speed with airbags.

🏄 Do something small to move forward; motion beats elegant paralysis.

Stuck on a nasty concurrency bug? Slice off a failing test, pair for ten minutes, walk the dog, come back. Even a new exception after hours of slog is forward momentum. (I celebrated one at 01:12 last Thursday—might’ve woken the cat.)

The Joy of Tinkering

Side projects are my R&D lab. One weekend I’m wiring WebRTC for a home cam, the next I’m abusing Rust macros just because. That playful space keeps skill decay at bay and reminds me why I fell in love with this mess of a profession.

But—and this was a hard lesson—endless tinkering collides with actual rest. I now run a simple rotation: Saturdays are “build something goofy until dinner,” Sundays are laptop-free unless prod is down. The contrast helps me show up Monday with curiosity instead of eye strain.

George Hotz hacking on LLaMa is the textbook example—watch the grin. That’s the energy I’m talking about.

Knowing the Why

The abstraction stack is tall, but occasionally climbing down pays off. Peek into how Blink paints or why CPython’s GIL exists (spoiler: history and expediency). Suddenly those performance quirks make sense, and your mental debugger levels up.

You don’t need PhD-level depth everywhere. Just enough to form quick mental models: “This call is O(n²); that’s fine for 500 items but not 50 k.” Once you can answer why an error bubbles up, you fix it faster and explain it to the PM without hand-waving.

1. Problem Solving: underlying logic points the flashlight at the bug.
2. Decisions: intuition about caches, protocols, complexity.
3. Bridge Building: easier chats with design, ops, even legal.
4. Innovation: the cool stuff usually lives between layers.

I’m still fuzzy on some kernel internals, by the way—this is a journey, not a checklist.

Thinking in Systems

A single line that lets balances go negative tanked FTX. One more minute of “what else does this touch?” could’ve saved billions. Extreme example, same lesson: your micro-change always lives inside a macro-system.

I try to model impact in two hops minimum. If I tweak YouTube’s recommendation weight, what does that do to infra load, creator revenue, public perception? Sometimes the exercise kills the feature; that’s still a win.

Unit tests prove trees; end-to-end tests prove forests. You need both.

Recharging Beyond the Pixels

Eyes ache, shoulders lock, dopamine spirals—screens are fantastic until they aren’t. A short trail run resets my brain far better than doom-scrolling Twitter threads on architecture. (Side note: I still fail at this once a week.)

🏄 Step away long enough to remember why the feature matters to humans.

The paradox: time you “lose” offline often pays back with clearer thinking and fewer reverts. Treat it like maintenance downtime for your neurons.

The Art of Approximation

Rough numbers save real money. I keep a tiny cheat sheet: RAM ≈ roughly 25 GB/s per core, NVMe read ≈ around 3 GB/s, cross-region latency ≈ somewhere around 150 ms. They’re ballparks, nothing more, but they tell me early whether an idea is laughable.

Before spinning up a petabyte-scale log pipeline, scribble the math on a napkin. If the back-of-the-envelope cost is the price of a nice car per day, maybe sample first.

If the video above doesn’t give you an “aha,” check your pulse.

Transfering Knowledge to Other Problems

The best bug fixes I’ve shipped stole ideas from unrelated domains: compilers influencing React diffing, physics engines inspiring load balancers. Pattern recognition beats memorizing answers.

🏄 Every bug you solve today is a reusable lens tomorrow.

Static knowledge fossilizes; transferable principles travel.

Making Hard Things Easy

If you can’t explain epoll to a junior in five minutes, you don’t understand epoll—happens to me with TLS handshakes all the time. The moment I can teach it, I know I’ve internalized it.

Sharing knowledge isn’t charity—it lightens your pager load because more teammates can debug the thing.

Enjoyed the read? Join a growing community of more than 2,500 (🤯) future CTOs.

Email address

Subscribe

Free, no spam, unsubscribe at any time.

Playing the Long Game

Quick hacks feel good until quarter three when the feature needs a tenth tweak. I still take shortcuts—sometimes you must—but I log the debt right away. Future me is grumpy enough without surprise interest.

Think chess: watch the endgame, but survive the next move.

Worthy Mentions

Developing a Code Nose

Bad code smells—literally triggers a little nausea once you’ve seen enough of it. Convoluted conditionals, duplicate branches, passive-aggressive comments. You’ll spot it faster the more repositories you read. Reading is the gym.

Strong Opinions loosely held

I love strongly typed languages. I also rewrote a service in TypeScript last month after swearing I never would. Conviction plus adaptability—that’s the sweet spot.

This list might already feel like too many rules. Fair. Some devs swear the only two habits that matter are “get things done” and “communicate.” If trimming the list helps you move, trim away. Parsimony is a feature.

That’s it from me. Curious what habits you’d add—or delete. Comments are open.

UPDATE 21 Jan 2024: Prefer video? I rambled through these points on YouTube. Watch here and roast my lighting setup.

---

Other Newsletter issues:

• Networking as an introvert CTO
• Rules of Thumb for Software Development Estimations
• What does a CTO actually do?
• Things they didn’t teach you about Software Engineering