The Safety Of Busyness

Your manager asks what you accomplished in the last quarter. You start listing things. Helped ship three features. Stayed late and unblocked two projects and fixed countless bugs.

She nods. Then asks, "But what did you solve?".

You stop and think. You realize you don't have an answer.

You've been around a lot of building. You've supported it, kept it moving. But you haven't solved a hard problem or pushed a new idea forward. And you didn't notice until someone asked.

The Choice You Keep Making

Monday morning. You open your laptop planning to finally dig into that auth system redesign. The one that's been bothering you for months. The one where you know the current approach is wrong but fixing it means three days of thinking and another week of convincing people.

Slack lights up. Someone needs help with the build. You help. Another message. Question about the API you wrote last year. You answer. A meeting invite for this afternoon. You accept.

By lunch you've been helpful to six people and haven't touched the auth system. Tomorrow, you tell yourself. Tomorrow you'll have time. You've been telling yourself that for three weeks.

But you are also kind of relieved.

You're relieved you didn't have to open that blank document and stare at it. Relieved you didn't have to expose what you don't know. Relieved you could spend the day doing things you're already good at instead of things that might prove you're not as capable as everyone thinks.

The requests are real. The interruptions are real. But so is the quiet comfort of letting them fill your day. One yes at a time, you're choosing safety over growth. And you're calling it being helpful.

Why You Keep Choosing Safety

You know this is happening. You feel the weight of unsolved problems in the back of your mind. That auth system. The flaky builds. The performance issue nobody wants to touch. So why don't you just do the work?

Sitting down to do it makes you feel stupid.

You open the auth system file. Start tracing backwards. Fifteen minutes in you have ten files open and you've forgotten where you started. The next file is two thousand lines written by someone who left the company two years ago. The comments are sparse. The variable names made sense to someone, but not to you.

An hour in, John pings. Bug in production. You jump on it. Relief washes over you. You get to stop feeling stupid and do something you know how to handle.

Proposing something real makes you vulnerable.

You spend three days on that refactoring proposal. Six months of work, mapped out. You pitch it to your team. They probe your thinking. Push back on the approach. That's what they're there for. But every question feels like evidence you missed something obvious.

You don't fight for it. Better to let it die in the meeting than defend something that might be wrong.

Failure would prove something you don't want to know.

What if you push that proposal through and three months into implementation you discover you missed something fundamental? What if the whole thing crumbles? Better to have a small failure now that nobody notices than a big public one later.

What if you're not as capable as you think you are? That's the real question. And you'd rather not answer it.

Success creates pressure you're not sure you can sustain.

If your proposal works, you need to see it through. The actual implementation. The migration plan. Months of work that come after. And if you succeed, the expectations change. Can you keep delivering at this level? What if this was your one good idea?

Safer to stay where you are, doing work that doesn't raise the bar.

What You're Really Trading Away

Every week you spend answering the same questions is a week you're not building new capabilities. Every day you patch instead of fix is a day you're staying exactly as capable as you were yesterday. You're not learning. You're not growing. You're running in place and calling it progress.

But the cost is deeper than that. You're trading away your sense of yourself as someone who solves hard problems.

Two years ago you would have jumped at that auth system redesign. You would have been excited by the challenge. Now you avoid it. Not because you're busier. You're more afraid. Afraid of not being as sharp as you used to be. Afraid that if you actually tried, you'd discover you're just average.

So you stay busy. You rack up replies in Slack. You show up to every meeting. And slowly, quietly, you become someone whose main skill is being available.

Then you notice newer engineers tackling problems you've been avoiding. Because they haven't learned yet that being helpful is safer than being wrong.

The Work of Facing It

So how do you actually stop choosing safety? Not with calendar blocks or productivity hacks. With harder work than that.

You have to sit with the discomfort.

Thursday afternoon. Architecture review. You're about to pitch that auth redesign. The one you've been thinking about for weeks but only actually worked on for six hours total because you kept finding reasons not to.

You have slides. Sort of. Three diagrams that explain the new approach. But there's a gap in slide four you couldn't figure out how to solve. You thought about it for an hour yesterday and got nowhere. So you left it vague.

You could cancel this meeting. Say you need another week. Nobody would question it. Your hand moves toward the calendar. You stop.

You start the presentation.

Slide one goes fine. The problem statement. Everyone nods. They know the current system is broken. Slide two, your proposed fix. A few questions but nothing hard. You're feeling okay. Maybe this won't be bad.

Slide three. Someone asks how one part of the system works. You explain it. They push back. Point out a potential problem. You thought about this. You have an answer. They nod.

You're feeling better now. You can do this.

Slide four. The part you don't understand yet. You put up the diagram. You explain what you know. Then you hit the gap. You could bullshit here. Make something up that sounds reasonable. Nobody would know.

Instead you say, "I don't know how to handle that part yet".

The room gets quiet. Not a bad quiet. Just quiet. Mike speaks up with a suggestion. You hadn't thought of that. You say so. "I hadn't thought of that. Would that cause other problems?". Now you're having a conversation. Not defending a complete idea. Working through an incomplete one.

Ten minutes later you have three potential approaches. None of them are yours. All of them are better than what you walked in with.

This is what it looks like. Not having all the answers. Saying "I don't know" in a room full of people. Letting your incomplete idea get better through exposure. The discomfort of that moment when you said "I don't know how to handle that part yet" was real. You felt it in your chest.

But you didn't die. The idea didn't die. It got better.

You have to expose what you don't know.

Ask the questions that make you look stupid. "Wait, why do we do it this way?". "I don't understand this part of the system". "Can you explain the decision behind this?".

Every question feels like evidence of inadequacy. But it's actually learning. The engineers who grow fastest aren't the ones who already know everything. They're the ones willing to look dumb in the short term to understand something real.

You have to defend ideas before they're perfect.

Pitch the half-formed proposal. The redesign that still has gaps. The fix you're only 70% sure about. Put it in front of people knowing they'll find problems. Let them poke holes. Learn from what breaks.

You're not protecting quality by waiting until you're certain. You're protecting yourself from feedback. The work gets better through exposure, not isolation.

You have to accept that you might fail.

Sometimes you'll dig into a problem for three days and realize your approach is wrong. Sometimes you'll propose something that gets shot down. Sometimes you'll try and discover you're not as far ahead as you thought.

That's not evidence of inadequacy. That's what growth looks like. The engineers who solve hard problems aren't the ones who never fail. They're the ones willing to be wrong in public.

The Question That Matters

Tomorrow the messages will start again. The requests won't stop. You'll respond, help your team, stay busy. That's part of the job.

But that auth system is still broken. The performance issue is still there. You know it. You feel it.

You have two choices. Keep choosing comfort and slowly become someone whose main skill is being available. Or face the discomfort and become someone who solves things that matter.

So what did you solve last week?