If Statement Energy

There's a funny curve in engineering that nobody warns you about. Early on, every problem looks like a chance to prove you can build something. Later, it becomes a chance to prove you can build it right. Then you start hearing words like scalability, resiliency, and observability, and suddenly every task feels like a prelude to a whitepaper. And just when you think you've mastered "thinking big." you meet someone who's been doing this longer and they quietly say: "Why not just use an if statement?"

Experience changes what "good" looks like. Juniors chase understanding. Mids chase correctness. Seniors chase stability. Principals chase calm. But under it all, we're all chasing the same thing: clarity.

For neurodivergent engineers, that curve rarely runs in a straight line. Maybe you jumped from "learning frameworks" to "mentoring others" before anyone gave you a title. Maybe you oscillate between building big systems and tearing them down to feel in control again. Growth doesn't always look like a ladder sometimes it looks like a loop, or a messy mind map on a whiteboard at 2 a.m.

The longer you're in this field, the more you realize that wisdom isn't in knowing more, but in caring less about the wrong things.

Junior: "Can it work?"

The first stage is pure curiosity. You're just trying to make things do something. It's equal parts chaos and joy. You Google every second line. You copy-paste from Stack Overflow and whisper "please work" as you hit save.

It's not elegant, but it's honest. Juniors are explorers, they want to see the lights turn on. The biggest skill at this stage isn't syntax, it's persistence. You're learning how to stay with a problem long enough to understand it, not just fix it.

For neurodivergent devs, this stage often feels like sprinting uphill. The noise of tutorials, frameworks, and "best practices" can be paralyzing. But what looks like distraction is often pattern-hunting, your brain building an intuitive map of how things fit together. That's gold later.

Mid-Level: "Can it be right?"

Somewhere around year three, something shifts. You start seeing the code you used to just copy. Suddenly everything feels wrong. You rewrite, refactor, abstract. You build factories for things that used to be one-liners. You learn about dependency injection, SOLID principles, and why everyone keeps arguing about single responsibility.

It's the season of control, you want to prove you can make things clean, safe, scalable. The trap? Overengineering. You start solving problems that don't exist yet, trying to show mastery instead of trust.

For ND minds, this can be a burnout zone. Perfectionism sneaks in disguised as professionalism. The key here is learning that "done" is better than "ideal," and that clarity beats cleverness.

Senior: "Can it scale?"

By now, you've built enough systems to know they will break. You start thinking about the edges. How does it handle load? Failures? What happens when ten teams touch the same repo?

You zoom out. You draw diagrams. You think in trade-offs. But here's the quiet truth: Senior engineers don't always write the most code, they prevent the most bad code.

For neurodivergent seniors, this stage often means learning how to translate chaos into structure. You might not love meetings, but you start appreciating context. You realize architecture isn't just about systems, it's about how humans talk to each other through code.

Staff / Principal: "Should it exist?"

This is the full-circle moment. You've seen enough rewrites, enough migrations, enough "v2"s that died before launch to realize: not every problem deserves a solution.

You stop chasing elegance and start chasing impact. You say no more often. You build less. You trust more. The "if statement" becomes a symbol, not of simplicity, but of experience.

For ND folks, this can be the most freeing stage. You finally have permission to design around how your brain actually works, fewer moving parts, more focus on meaning. You start mentoring others not by telling them what to build, but why not to.

The real arc

It's not a ladder, it's a loop. You'll revisit every stage again and again. Some days you'll feel like a junior debugging CSS. Other days, like a principal questioning existence itself. That's the job.

Experience doesn't flatten curiosity, it refines it. Every step teaches a new version of the same truth: simplicity isn't the absence of skill, it's the result of it.

Every engineer eventually learns that complexity is easy, it's simplicity that takes courage. The longer you stay in this field, the more you realize that restraint isn't laziness, it's leadership.

You start measuring success not by how much you build, but by how much you didn't have to.

If you're somewhere in the middle of that arc, wondering whether you're doing enough, you are. The skill isn't in knowing every pattern. It's in knowing when to stop adding one.

Simen (and Buffer, quietly nodding at your if statement)