Beyond the Code: Four Lessons from a Solana MEV Journey

When the Code Stopped Being the Hardest Part

Somewhere between the AMM math and the on-chain debugging, something strange started happening. The bugs I was chasing weren't the hardest part of the day anymore. The hardest part was deciding what to work on, when to walk away from a failed approach, and whether the result I was looking at was actually progress.

Building a Solana MEV bot from zero teaches you Solana, AMMs, Rust, async runtimes, and roughly a thousand smaller things. But the lessons that travel — the ones that feel like they'll outlive this specific project — aren't technical. They're about how to think under uncertainty, how to wait without giving up, and how to choose what to give up.

This piece is about those lessons. Four of them, specifically: patience, data over vibes, trade-off intuition, and learning to live with not knowing. Each one started as a frustration. Each one became something the project actually depends on.

The Shape of the Journey So Far

For context, this isn't a victory lap. The bot exists, it runs, it does things. But the path here looks nothing like a straight line. There are stretches where the production rate is zero. There are weeks where the question isn't "how do I make this faster" but "is this idea fundamentally flawed."

That's the reality of building anything in a hostile, fast-moving market with no instruction manual. You don't get the satisfying montage. You get a slog with occasional moments of clarity, and you have to teach yourself how to keep showing up between them.

A 35-year veteran software practitioner Jim Grey put it bluntly: "The software we are building right now will one day be decommissioned and not be used anymore, probably before your career is over." That sentence reads cold at first. But it's actually the cure for a specific disease — the disease of treating today's broken pipeline as the most important thing in the universe.

It's also a useful reframe for a side project that won't ship a press release, won't make the front page of any tech publication, and may quietly retire in a few years when the market structure shifts again. The work matters because you're doing it, not because it's permanent.

Patience as a Technical Skill

The first lesson is patience, which I used to think of as a personality trait. Some people are calm by nature, some aren't, and that's that. Building something hard over a long period of time taught me patience is more like cardio: trainable, perishable, and the difference between finishing and stopping.

A senior engineer reflecting on eight years in the industry crystallized it as a simple principle: "Stay calm, things work out." Read on its own, it sounds like a fortune cookie. Sitting at a desk at 2 a.m. staring at a transaction that should have landed and didn't, it sounds like the only sentence in the world that makes sense.

Patience isn't passivity. It's the discipline of not making the situation worse with a panic move. In a baseball season, a .300 hitter fails seven out of ten at-bats and still goes to the Hall of Fame. The hitter who walks back to the dugout angry after a strikeout, kicks the watercooler, and brings that energy back to the plate is the one who hits .220.

In building this project, the watercooler is the codebase. A frustrated change at 3 a.m. is a regression at 9 a.m. The patience to close the laptop and look again with fresh eyes — that's not weakness, that's the move that produces working code.

There's also a particular kind of patience that's specific to long-horizon projects: patience with yourself for not knowing. The first time you encounter Solana's account model, the rent system, the gauntlet of versioned transactions, it feels like everyone else got the manual and you're trying to assemble IKEA furniture in the dark with a flashlight that keeps flickering. Impatience whispers that you should already understand this. Patience says: you'll understand it on Tuesday. Just keep reading until Tuesday.

The muscle gets stronger with reps. Each time I forced myself to walk away from a stuck problem and come back the next morning, the next walk-away cost me less ego. The friction between "I should already know this" and "this is the first time I've seen this" is where most of the impatience lives. Watching that friction shrink over months has been the most surprising development of the project.

Data Over Vibes

The second lesson is about trusting numbers over gut feeling — and the surprising amount of work it takes to do that consistently.

Early on, I made a habit of running with my intuition. A swap "looks profitable." A path "seems shorter." A pool "feels deep enough." Every one of those phrases is a lie I told myself to skip the work of actually checking.

Academic research has put structure on this. A study of Agile retrospectives argues that data-driven decision-making is "advantageous yet underused" — most teams reflect on what they remember instead of what their tools recorded. Git history, ticket trackers, code reviews — all of it sitting there ignored while teams have feelings about each other.

I caught myself doing the same thing on a project of one. The bot would land a few profitable transactions, and I'd build a story about why one strategy was working. Then I'd actually look at the logs and discover the wins were clustered around two specific market events, not the strategy at all. Vibes lied. The data didn't.

The fix wasn't more discipline. It was treating the question "what's actually happening" as more important than the question "what do I think is happening." It means writing down the prediction before looking at the result. It means measuring before optimizing — because intuition about hot paths is wrong as often as it's right.

This applies far beyond a bot. The same instinct that says a strategy is working when it isn't is the instinct that tells a manager their team is happy when they aren't, or a founder their product has traction when it doesn't. Vibes-based management runs on the same broken sensor.

The fix is the same too: data first, story second. If the story doesn't fit the data, throw out the story. The seductive part of vibes is they give you the conclusion without the work. The expensive part is they give you the wrong conclusion most of the time.

A useful corollary: when I genuinely don't know what the data is telling me, the right move is usually to instrument more, not to guess harder. Admitting the limits of your knowledge is a sign of maturity, as one developer reflected after seven years — the freedom to say "I don't know, never tried that." But "I don't know, and I'm going to find out" is the version that actually moves the project forward. The pause for honesty is cheap. The instrumentation that follows the pause is what changes the trajectory.

Trade-offs: Every Yes Is a Hidden No

The third lesson is one I'd intellectually understood for years but only really felt in this project: every decision in software is a trade-off, and being able to name what you're giving up is a different skill from being able to decide.

A Manning book on the subject — Software Mistakes and Tradeoffs by Tomasz Lelek and Jon Skeet — argues that trade-offs are inherent at every level of development, from junior to senior. What changes with experience isn't whether you face them. It's whether you can name them out loud.

A few concrete examples from this project. Adding a new DEX integration broadens the search space but makes every quote slower. Caching pool state cuts latency but risks acting on stale data. A larger transaction landing window catches more opportunities but raises the cost of every miss. There is no "right" answer to any of these. There's only "what are you optimizing for, given the current bottleneck."

The mistake I kept making was treating trade-offs as choices between good and bad. They're almost never that. They're choices between two goods, or two bads. The cost of pretending it's good-vs-bad is that you stop measuring, because you already "know" the answer.

Jim Grey, the 35-year veteran, has a related observation that hit me harder than I expected: "When you deliver work you're really proud of, you've almost certainly done too much and taken too long." The implicit trade-off is between craftsmanship and shipping, and most engineers — myself included — over-index on craftsmanship because it feels good. Sixty to eighty percent quality, he argues, is usually enough. The rest serves ego, not value.

For a side project with no boss, that sentence is dangerous in a useful way. Nobody is telling me to ship. Nobody is telling me a feature is good enough. The trade-off between "land this and move on" and "polish this for another week" is one I have to make alone, and every week I notice the temptation to choose polish for the wrong reasons.

The mental shift that helped: ask what's not getting done while I'm polishing this. The opportunity cost of perfecting one component is the entire other component I'm not building. Once you frame it that way, the trade-off becomes vivid. "Should I refine this caching layer for another three days?" becomes "Should I refine this caching layer instead of building the simulator?" The answer is usually no.

There's a Wall Street version of the same lesson. Investors talk about opportunity cost in capital allocation: every dollar in one position is a dollar not in another. In a side project, every hour spent on Component A is an hour not spent on Component B. Most engineers I know — including past me — treat hours as if they're free until the deadline arrives. They aren't. They're the most expensive resource in the project, and trade-off thinking is the only way to deploy them well.

A more general lesson lives underneath this: senior engineering isn't about always picking the right side of a trade-off. It's about not pretending the other side doesn't exist.

Living with "I Don't Know"

The fourth lesson is the hardest, because it's the one with no clean solution. It's about how to keep working when you don't know if you're on the right path.

Building something for a market that's evolving in real time means you can't research your way to certainty. The state of the art from six months ago isn't the state of the art today. The strategies that worked last quarter may not work this quarter. The infrastructure providers you depend on shift their pricing, change their APIs, deprecate features. You are perpetually a little behind.

A piece on navigating ambiguity in startup environments reframes this in a way I keep coming back to: "Embracing ambiguity can actually be a strength in a startup environment. It allows developers to be flexible and adaptable." The same piece offers a tactical handle: break the unknown thing into small, knowable tasks, and ride steady progress through the fog.

That tactical handle is doing a lot of work. The big unknown — "will this entire approach pan out" — is unanswerable today. But "can I get this one query to return results in under a second" is answerable today. "Can I add one more pool type to the search graph" is answerable today. Each small answer reduces the larger unknown by a sliver.

A Harvard Extension piece on design thinking applied to careers puts it this way: the practice "focuses on developing a growth mindset, a bias to action, and a willingness to tolerate ambiguity" — built on the belief that risk is acceptable and mistakes are learning opportunities. Translated to a software project: the only way through ambiguity is small bets. You make a small bet, you find out if it worked, and the result of that one bet trims the search space for the next one.

There's also an emotional dimension I didn't expect. Sitting with "I don't know" for long enough trains a different relationship with not-knowing. The first few months of the project, every unanswered question felt like a threat — what if this means the whole approach is wrong? After enough cycles, the unanswered questions started feeling like terrain features instead of monsters. You stop asking "is this safe?" and start asking "what's the next probe I can run?"

Research on uncertainty mindsets suggests this isn't just a personality difference: "How we frame uncertainty dramatically affects our experience of it." Reframing "this is terrible" to "this is challenging but potentially valuable" isn't toxic positivity. It's the cognitive move that lets you stay in the work long enough to find out.

There's an old saw about the difference between weather and climate: weather is what you experience this afternoon, climate is what you experience over years. Uncertainty about today's debug session is weather. Uncertainty about whether the whole project is worth doing is climate. The honest answer to the climate question is: I don't know, and the only way to get more information is to stay in the work. Anyone who claims certainty about the climate of a long-horizon project is selling something.

Why These Lessons Travel

Here's why these four lessons matter beyond a Solana bot.

The technology will get replaced. The specific chains, DEXs, RPC patterns, language choices — all of it has a half-life. Jim Grey's point about software being decommissioned before your career is over isn't just a humility move; it's a strategic observation. Whatever I learn about Token-2022 mint behavior or Anchor IDL conventions is depreciating from the day I learn it.

The non-technical skills don't depreciate the same way. Patience under failure, the ability to read data without forcing a story, the instinct to name trade-offs out loud, comfort with sustained uncertainty — those skills compound. They work in startups, in operations, in management, in totally different industries. They're the closest thing to a portable career asset there is.

This is also why I've stopped trying to be the most technically clever person in any given problem. Most of the leverage in this project hasn't come from picking the perfect algorithm. It's come from picking the right algorithm for the right trade-off, then measuring the result instead of arguing about it, then waiting long enough to know whether the change actually mattered.

There's a Harvard Business Review piece on career resilience that frames the broader landscape: traditional job security is dissolving in an era of layoffs, automation, and shifting regulations. The author argues for proactive resilience — identifying non-negotiables, building adaptability, deepening relationships, creating your next-best option. The interesting thing is how closely those moves map to the four lessons above. Patience to weather downturns. Data to know your actual market value. Trade-offs to choose what to build next. Comfort with uncertainty to act before you have to.

Building a side project that pushes you into all four pressures simultaneously turns out to be a remarkably efficient training environment. The bot doesn't care about your job title. The chain doesn't care about your seniority. The numbers either work or they don't. That brutal feedback loop is the gym for the non-technical skills.

It's also worth noting that none of these lessons are unique to crypto, or even to software. A small-restaurant owner figuring out whether to add delivery, a coach deciding whether to switch a team's offensive scheme, a parent choosing which school district to move into — each is making trade-offs under uncertainty, with imperfect data, and needing patience to wait for the verdict. The texture is different, but the underlying skills are the same. Building software in a fast-moving market is one of many ways to develop them.

Where the Journey Sits Now

I'm not at the end of any of these lessons. Patience still fails me when something is broken at midnight. I still catch myself building a vibes-based narrative around a result I haven't measured. I still occasionally treat trade-offs as a binary. I still want certainty I'm not going to get.

What's different is that I notice it faster. The recovery cycle from "I'm frustrated and about to make a bad decision" to "let me close the laptop" used to take hours. Now it takes minutes. The recovery cycle from "I have a theory" to "let me check the data" used to take days. Now it's usually the first thing I do.

That improvement isn't dramatic on any given day. But it's the kind of improvement that compounds over months, the way most real skill does. The big lessons aren't the ones I learned in a flash of insight. They're the ones I'm still learning, and the marginal improvement is what keeps the project alive.

A reflection piece on non-technical lessons in software made a point that captures this well: "No developer exists in isolation." I'd extend it: no software project exists in isolation from the human who's building it. The state of that human — their patience, their honesty with themselves, their tolerance for ambiguity — eventually shows up in the codebase. You can debug the code, but if the human's broken, the code keeps breaking in new ways.

So the journey continues. There's no neat conclusion to write. Each new month involves some combination of latency work, integration issues, and yet more market shifts I haven't predicted. The technical surface area keeps growing. The non-technical skills keep getting tested.

Those tests aren't a side effect of the work. They are the work. The code is downstream of how the human handles the four pressures above. If I keep getting better at those, the code gets better too. If I don't, no amount of clever engineering compensates.

Key Takeaways

• Patience is a trainable skill, not a personality trait. The discipline of not making the situation worse with a panic move is the move that produces working systems over time.
• Data beats vibes, but only if you build the habit of checking. Writing down the prediction before looking at the result is the cheapest, hardest thing you can do.
• Trade-offs are choices between two goods, not good and bad. Senior engineering means naming what you're giving up, not pretending the other side doesn't exist.
• Uncertainty is terrain, not threat. Breaking the unknown into small, knowable bets is the only honest way through.
• Non-technical skills are the portable career asset. The chains will change. The patience, judgment, and self-honesty don't.