> Pure pioneers look like the fabled "10x programmer" on the outside, but leave a hellscape of technical debt in their wake.
"I've made the MVP"
"Ok, let's have a look... uh, if any of five remote servers so much as sneezes, this service will crap itself and die"
"It's fine, it'll restart itself after a few seconds thanks to some aws magic"
"And any ongoing transactions?"
"Details, whatever..."
I also think there's a middle ground. I see myself as the pioneer type, but you have to start building a semi-solid base, not just throw stuff together at random. I've seen a number of 'pioneer' folks who just throw together the sloppiest thing ever and move on. Hopefully the article writer isn't one of those...
As an aside I wonder if almost everyone would prefer to be the pioneer, but ends up getting stuck in process-land and maintenance hell.
I mean it depends on the context. I've built the mvp version my startup in a few weeks of not sleeping, doing a hundred things the wrong way [1]. But the goal was not to build a proper system, but to build something to prove there's a need for that, which allowed us to raise money and fix the issues later.
And I'm still having trouble explaining to our engineers that sometimes it's okay to accrue tech debt if it serves a business purpose. We can have the most technically sound product but if the money runs out the game is over. Startups are a crazy sprint, not a well paced marathon.
The problem is if the tech debt is not a conscious decision you're making
> We can have the most technically sound product but if the money runs out the game is over.
I think most engineers are just not used to ever thinking about time and money as a constraint - they're just things abstracted away from them so they can do good work (or they've worked for companies where those aren't constraints). Just being up front with them about the fact that these constraints exist will usually change how they think about a problem (in my experience at least).
> The problem is if the tech debt is not a conscious decision you're making
100%. The entire debt metaphor fails if you aren't knowingly doing something that you're going to have to "pay off" later.
It usually takes several of these conversations for them to start thinking like that.
Why it works in our case is because I acknowledge it's a debt and then later we pay it back. A huge problem devs have is - there is a push, promises are made, and then something new and urgent comes along.
I do agree, most devs usually work in large companies where money and salary is an abstract thing several layers removed from them.
When I was a developer I used to despise some of the places I worked at, but now when I'm trying to start a company I see them in a much different light and see that a lot of things made sense
Oh agreed, it's a lesson to learn, just like the rest of their engineering practices were learned. You don't usually absorb stuff like that fully by having someone tell you once.
> Why it works in our case is because I acknowledge it's a debt and then later we pay it back. A huge problem devs have is - there is a push, promises are made, and then something new and urgent comes along.
I don't think it works any other way. A lot of times the only difference between "intentionally accrued tech debt" and "shoddy work"/"bugs"/"brittleness"/etc is communication.
> A huge problem devs have is - there is a push, promises are made, and then something new and urgent comes along.
If you're constrained by time and money, this is usually the case. You accrue tech debt to meet constraints, and you pay it off over time, not necessarily immediately. It's just normal roadmap prioritization. All you can do as an engineering leader is correctly advocate for the urgency of tech debt, communicate interdependency issues ("we must pay down this tech debt before we can tackle feature X"), and pay off some debt when it makes the most sense.
That's why for me it always comes down to leadership. At least in Europe, which doesn't really understand software, developers are put under management of people that do not understand the craft at all.
I personally hate the fact that agile, which started off as a couple people saying "we're all professionals and grownups here, let's talk regularly about how to combine this abstract thing we do with actual client needs" is now a whole industry.
There's now a whole profession of "scrum masters", most of whom haven't the first clue how to actually do anything much, and none of whom are needed - the scrum master was just the guy coordinating, a monor extra duty that could even rotate. But no, we have people hanging on to our industry, claiming to add value, who spend their days fussing over jira... it's a tragedy.
I agree - but also technical isn't important at that phase, business value is. And often technical architecture needs change as product fit, market fit change.
As an aside I wonder if almost everyone would prefer to be the pioneer, but ends up getting stuck in process-land and maintenance hell.