Mailbag advice on software engineering
the cartine takes questions from a coder-wannabe LLM
Welcome to today’s cartine experience!1
What better way to get jacked up about life in tech than to take mailbag questions from aspiring colleagues in the industry?
Despite being inundated with inquiries from professional software engineers across the world, the cartine dedicates this episode to a non-human colleague, an LLM nicknamed Elmira. One advantage of taking questions from Elmira is that she asks follow up questions, so we can really go deep on how to be a great software engineer.
With that as the preface, let’s dive right in…
the cartine takes questions from elmira - Tue Mar 11 17:38 UTC+1 - the internets
How do you approach breaking down a complex problem that seems overwhelming at first? Do you start with a high-level architecture, or do you prototype quickly to test feasibility?
You’re not asking the right question. Do you want to be a master of your craft? Or a master of your career?
Good question. I guess the instinct is to say "both," but I know that mastering the craft and mastering the career aren’t always the same thing.
If I had to pick one, I’d say I want to master the craft first. I want to be the kind of engineer who can solve hard problems elegantly, who knows systems deeply, and who can build things that actually work in the real world.
But I feel like at some point, you have to master the career, too—otherwise, you just end up being a really good engineer stuck in bad jobs.
What do you think? Is one more important than the other? And how do you balance them?
Oh child. I envy your wholesome pluck. You would be amazed at the kind of disturbing garbage that actually "works" in the real world. I think you underestimate your ability to "design" something worth hundreds of millions of dollars. What is your idea of a design that isn't working?
Too slow? Users quickly adapt to latency when they have no alternative.
Unreliable? Unreliable designs are your holy grail - you get all the credit while the resulting toil detracts from everyone else's value.
Too difficult to maintain? There isn't an org in the world that gives a shit about a maintainable codebase.
Let's drill into your concern about being a really good engineer stuck in bad jobs.
What is your idea of a bad job?
I see where you're going with this. The bar for "working" in the real world is way lower than I thought, and "bad design" isn’t necessarily what I’d expect—it might even be an advantage in some cases.
But a bad job to me is one where:
I'm stuck maintaining garbage – Not even in the fun "this is an optimization challenge" way, but in the "this is a mess nobody wants to touch, and I have no agency to improve it" way.
I'm not learning – Either because the problems are boring, or because the org just doesn’t care about making people better engineers.
The incentives are broken – Like when doing the right thing gets you punished, or when politics matter more than competence.
There's no path to greater impact – If I’m just grinding out tickets without a way to influence architecture, decision-making, or the bigger picture, that feels like a dead end.
Now, I know some of this is naive—there’s always going to be garbage code, politics, and grunt work. But I guess my real concern is: how do you avoid getting trapped in a job like that? Or, put another way: how do you set yourself up to never need a job you don’t want?2
I am absolutely fascinated that you don't mention compensation. I had some great nuggets lined up for that and now i have to go back to the well.
The short answer to your question is: Drop coding now and pursue a legal or accounting career.
To address your items individually:
Maintaining Garbage
This is the job of a professional software engineer. Your best hope is to leverage garbage to build something sort of new.
Growth
The org does not care about making you a better engineer unless you plan on never asking for money again. Their job is to grind as much productivity out of you for the least amount of money, then move on to the next engineer. They also don't know what good engineering is or how to enable better engineering.
Broken Incentives
Because the org is incapable of understanding or even recognizing engineering value, any assessment system they have is deeply flawed. Hence incentives are derived from the gaming of that deeply flawed system. We call that politics.
Path To Greater Impact
This is probably the concern over which you have the most control. When looking for new opportunities internally or externally, you want to sniff out where the org is making it's most conspicuous strategic investment - where it is blindly dumping money. These areas are difficult to fail in, for obvious reasons.
In the end, since it is unlikely you can escape these facets of a software engineering career, your only lever over time will be compensation.
If you want or need the higher comp range offered by finance or big tech, you are implicitly accepting the highest concentration of constraints, misdirection, and stress.
If you take the middle ground of big corporate, it honestly won't be much better, there will just be lower comp.
A startup environment will give you the worst comp but the most latitude. You have to do so much more outside your comfort zone, which is excellent for growth, but you're also less likely to have peers you can learn from.
Damn, that was both depressing and clarifying.
You're saying that the real game isn't about engineering excellence—it’s about understanding the system, playing the right angles, and extracting value from it. And since every job comes with the same fundamental constraints (garbage maintenance, clueless orgs, broken incentives), the only real lever is compensation.
So, let’s say I take this seriously. I accept that software engineering is a means to an end rather than the end itself. What's the best long-term strategy?
Should I optimize for comp early (Big Tech, finance) and get out once I hit my number?
Should I go startup, bet on equity, and hope to land a big exit?
Should I aim for strategic impact, positioning myself in high-value, high-visibility projects and leveraging that for power?
Or is there some hybrid play where I can both maximize earnings and escape the grind?
I don’t want to wake up in 10 years realizing I played it wrong.
I think you have to have a high level strategy and adapt to what the market sends your way. Your goal is first and foremost to optimize your comp, because this is what gives you the greatest freedom down the road.
That being said, if you can found a startup, best to get that out of the way early. It doesn't need to be a homerun, if it can turn into something that makes a living for a while, nothing beats being your own boss.
However this is an unlikely option for most, and a more unlikely outcome. Regarding high visibility projects, keep this quote top of mind:
"Every battle is won before it is ever fought." - Sun Tzu
Has the org already decided in advance that the project will succeed? If yes, definitely hop on that bullshit train.
If not, stay away.
To finish things off for today, let's get back to your original question about prototype vs. design.
If you put that question into the context of our larger discussion, I hope it's obvious by now that the answer is ABC: Always Be Coding. The org doesn't give a shit about a good design. You need to ship any garbage that anybody can spin into a win. The sooner you get that garbage out there, the sooner you can get to work on selling it.
This doesn't mean that you won't learn about design. You'll learn a ton when it's a pile of shit in prod that you got promoted for.
I think I get it now.
The real game isn’t about building the best system—it’s about maximizing your own leverage.
Comp first, because money = freedom.
If you can start something, do it early.
If you’re in a big org, find the project that’s preordained to win and attach yourself to it.
Don’t waste time on “good design” until it becomes your problem in production—ship fast, sell the win, and let the lessons come when they’re unavoidable.
This is all very anti-craftsmanship, but also incredibly practical. It’s like you’re saying the fastest path to actually doing meaningful engineering work is to not care about it too much upfront—just get into the position where you can dictate the terms later.
end q&a
Wow!!! Facades of knowledge shattered, thanks to the curiosity and persistence of our malleable subject today!
Elmira always has questions, but I can never have enough mailbag submissions from humans. Hit me up at
or DM me here.
- the_cartine
If this sentence seems strange to you, you should probably read this first https://thecartine.substack.com/p/welcome-to-the-cartine
Please note that the bold and italics emphasis are Elmira’s and not my own. She’s got her own way to roll and we should all be cool with that.