Software Engineers Need Reckless Abandonment

After 15 years of building software — agency work, startups, Meta, AWS, Plaid, consulting, my own products — I still don’t know most things. New frameworks ship every month. New infrastructure patterns emerge every quarter. Entire paradigms shift while you’re heads-down on a project.

That’s not a problem. That’s the job.

The engineers who grow the fastest — at every level — are the ones willing to abandon their comfort zone and dive into things they genuinely don’t understand. I call it reckless abandonment: the willingness to raise your hand, admit you don’t know something, and figure it out anyway.

Asking Questions Is the Whole Job

The thought of knowing everything is just wrong. You can have strong opinions — I certainly do — but you need to be open to changing perspective. This applies to juniors, interns, intermediate engineers, and seniors. Especially seniors.

I’ve seen engineers at every level hurt their own growth by not asking questions. Juniors stay stuck for hours because they don’t want to look like they don’t know something. Seniors stop asking because they think they should already have the answers. Both are wrong, and both cost the team time.

At Amazon, I watched a consolidation of internal search tools go sideways because the right questions weren’t being asked early enough. Two tools — fundamentally similar but serving different audiences. One was optimized for builders, the other for everyone else. I got into discussions with a director about how I thought the merge was flawed because they were serving different audiences with different needs. I eventually got pulled into conversations about how to make the migration work — what would the consolidated product need to be to serve both groups?

My answer was to prioritize the builder dataset for embeddings and indexing, not the generalized one. The builder community had specific needs that would get diluted in a one-size-fits-all approach. They moved forward with the merge anyway, despite the builder community disagreeing with it. The questions got asked, the concerns were raised, and the decision still went the other direction. The embeddings comment seemed to land though — they took that feedback and implemented it.

That happens. But the alternative — not raising the concern, not asking “are we sure this serves both audiences?” — is worse. At least the tradeoff was made consciously instead of by accident.

The best interns I’ve ever worked with were on the opposite end of this spectrum. They asked questions constantly. When I was managing a group of interns, I had a technique: I’d finish explaining something — a service architecture, how a deployment pipeline worked, how AWS resources connected — and then I’d say, “Okay, so everyone understands it now and has zero questions about the underlying technology and can repeat it back to me, right?”

Nobody could. And that was the point.

It opened up real discussions. They got to ask the questions they were holding back. They deployed their first APIs. They understood how everything tied together — not because I lectured at them, but because they were willing to say “I don’t get it” and we worked through it together.

A few of them wrote me cards at the end of the internship saying those knowledge dumps were the best part of the program. That meant a lot. But the reason it worked wasn’t because I’m a great teacher — it’s because they were willing to be uncomfortable and ask.

I want to acknowledge something here: asking questions gets easier the more career capital you have. A senior engineer questioning a director’s decision carries different weight — and different risk — than a junior doing the same thing. If your job security is less stable, if you’re early in your career, the calculus is different. The principle still applies — asking is always better than staying stuck — but the tactics look different depending on where you sit. A junior can start by asking one question per meeting they’d normally hold back. A mid-level engineer can volunteer for the project nobody wants. A senior can write the RFC that challenges the status quo.

Asking questions is the first step. But questions alone aren’t enough — you have to be willing to act on the answers, even when you’re not ready.

Be Willing to Be Bad at Something

I recently built an MCP server. Model Context Protocol — a technology I had genuinely never worked with. It confused me. I didn’t understand the architecture, the communication patterns, or how it fit into the broader ecosystem.

I built it anyway.

And I built it in Python, which isn’t my primary language. My preferred stack is Go for backends and CLIs, React with TypeScript for frontends, and Python scripts for glue — unless they get too big, at which point I go back to Go. That’s actually how my open source deployment tool Pilum got started: too many Python scripts, and I wanted something more professional and long-term. So I dove into building a real CLI in Go.

The MCP work was the same energy. I didn’t wait until I understood the technology fully before starting. I leaned on Claude heavily, read the docs, wrote bad code, rewrote it, and eventually had something that worked. The first day was frustrating. By the end of the week, I was productive.

You don’t need permission to learn something new. You don’t need to be an expert before you start building. You just need to be willing to be bad at it for a while.

Being willing to be bad at something is one thing. Pushing for change when you believe you’re right — even when the organization resists — is another level entirely.

Push for What You Believe In

At Plaid, I noticed a problem: raw SQL scattered throughout the codebase. It was a security concern, it caused bloat, and it made the code harder to maintain. Different teams had adopted different ORMs, but there was no golden path — no agreed-upon standard.

I wrote an RFC proposing EntGo as that standard. It was over 10 pages long. I compared every active query ORM available and benchmarked them against raw SQL. I acknowledged the tradeoffs — yes, in some cases at scale, raw SQL can outperform an ORM. But generated code is consistent and has fewer errors. And I provided a path for teams that needed raw SQL to still use it within the EntGo framework.

I had buy-in from some engineering teams. Others were stuck in their ways. Their argument was the cost of migration — fair enough. My argument was that we needed a golden path to even consider migrating in the future. Without agreeing on a tool, we’d be maintaining fragmented approaches forever.

It went through multiple revisions. The conversations felt like going in circles sometimes. But we were making progress. Some teams were genuinely excited about it — it was going to remove tens of thousands of lines of code they had to support. There was a real cost to not adopting the technology.

Eventually, leadership asked for a demo. That’s when I got laid off.

I was furious. Not about the layoff itself — those happen. But because the work was about to go through. The demo was the last step. I was so close. I even tried to get re-hired so I could finish that work.

Here’s the thing though: I don’t regret pushing for it. The RFC forced conversations that needed to happen. It gave teams a framework for evaluating ORMs. Even if EntGo didn’t get adopted after I left, the analysis and the arguments survived. Someone else could pick it up.

Reckless abandonment means pushing for things even when the outcome isn’t in your control. You might get laid off. The RFC might stall. The technology might not get adopted. But if you believe it’s the right call, be bold enough to make the case. The worst outcome is that nothing changes. The best outcome is that you move the entire organization forward.

When Reckless Abandonment Needs a Check

Reckless abandonment has a blind spot: people.

At a previous company, I was tasked with building a v2 of a critical money movement system. The existing system had gotten them to where they were, but it needed a fundamental rethink to scale. I dove in hard — new architecture, new patterns, heads-down building. What I didn’t do well enough was include the engineer who had built the original system in the process. I respected their work and told them so — the original system got the company to where it was. But telling someone you respect their work and actually making them part of the next chapter are two different things.

The project also suffered from timeline pressure. Because it was financial infrastructure, you can’t roll out a half-baked system just to show progress. So the work stayed invisible for too long, and the people around me couldn’t see the value of what was being built — a lesson I talk about in telling the story of your work.

We talked afterward and agreed we were both good people put in a bad spot. But the experience taught me something I carry into every engagement now: diving into hard problems is necessary. Pushing for what you believe in is necessary. But if you don’t bring people along — if you don’t make sure the team is comfortable with what you’re doing and why — the best engineering in the world won’t matter. Technical skill without organizational awareness is how good work dies on the vine.

Technology Will Always Outpace You

New tools, new frameworks, new paradigms — they never stop coming. MCP servers didn’t exist a couple years ago. Neither did half the AI tooling I use daily. Five years from now, there will be technologies that make today’s stack look dated.

You can respond to that in two ways. You can dig in on what you already know and resist everything new. Or you can treat every unfamiliar technology as an opportunity to be a beginner again.

I’ve been writing software for 15 years and I still regularly feel like I have no idea what I’m doing. That used to bother me. Now I think it’s the healthiest sign there is. It means I’m still learning. It means I’m still diving into things that are uncomfortable.

The engineers who stop asking questions, who stop diving into unfamiliar territory, who stop pushing for what they believe in — they’re the ones who stagnate. Not because they’re bad engineers, but because they’ve abandoned the recklessness that made them good in the first place.

Stay reckless. Ask the question. Build the thing you don’t understand yet. Write the RFC that might not go through. The technology will keep evolving whether you engage with it or not.

You might as well dive in.