Hacker News Reader

Comment by zdw | Hacker News Reader

The absolute best technical person is a meld of these two.

Pure pioneers look like the fabled "10x programmer" on the outside, but leave a hellscape of technical debt in their wake.

Pure process people are so busy building their perfect ivory tower they miss the actual goal of getting stuff done.

Somewhere in the middle, where you've figured out how to move fast but also avoid causing the tech debt you've encountered in the past is the right place to be.

This usually boils down to having good boilerplate when you start something - for code, that might be a trivial but well understood linting and testing framework that you can add at the start of a project, or a simple way to start documenting a business process.

View on HN

> 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

[1] https://medium.com/@magicsandbox/mvp-the-art-of-cutting-corn...

There's thoughtfully accruing tech debt and then there's thoughtlessness. I've met pioneer types who were much more of the latter than the former.

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.

> 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.

> I personally hate the fact that agile...

Oh god, it's horrific.

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 think the split makes more sense as process versus "heroes" (which is an old view I used to hear at process training classes). Rather than depend on key people able to solve any problem via "heroic" efforts (e.g. all-nighters or long weekends where they rewrite everything or learn an entirely new skill), you follow a reasonably-intelligent but slower process that has worked historically and can make progress even with average contributors.

Management of course loves (perhaps even needs) to make a commodity of employee skills, so process is always pushed early and often. But even the heroes will get burned out or reach a point where the product is just too big to handle otherwise.

> you follow a reasonably-intelligent but slower process

To my knowledge, few early-stage start-up succeeds this way. It's great to think we can make up for the pioneer-style solo contributors with any army of process IC's but I have yet to see that happen during the early years. You can just look at any current tech company and see that's the case - all of them had pioneers at the beginning that pushed forward incredible progress. Google, Microsoft, Intel, Cisco, Sun, SGI, Facebook are just some recent examples that come to mind.

I can certainly believe that's true because opportunities which can be solved by top-down process-driven progress can be addressed by market leaders and leave little opportunity for startups. Though I don't know that a sample of superstar companies makes for a definitive dataset. I know of multiple companies no one has ever heard of who are dominating their niches (that no one cares about, until you hear how much money they are making), and the most important factor to me looks like risk-taking, good positioning, and good timing by the leadership, not anything special in terms of technical achievements or flexibility by employees.

> not anything special in terms of technical achievements or flexibility by employees.

Pioneers are not limited to programmers - it's more a mindset and mode of execution that cannot be sustained in larger orgs.

Alternatively, build a team with a mix. Sometimes having a person passionate about process can be very helpful when they have a little tension with the pioneer types.

I've found this to work extremely well. I tend to err on the side of caution, building well tested systems with carefully planned failure modes. I work very well with people who drive hard and spit out a ton of rapid prototype code that's full of bugs. It's frustrating, and there's often tension. But the end result is the best of both worlds.

True.

They drove me a little crazy, but one of the best people I ever worked with was a “test enthusiast” and believed that anything not automated was going to eventually cause us trouble.

It was good friction and made one helluva a system that managed to serve a couple hundred thousand remote clients while basically on autopilot for several years now.

For sure. It means you actually have to be intentional about what you test. Best team I ever worked on had two loud, friendly, utterly opposite engineers when it came to excellence vs velocity. But it made us really talk through why we chose the things we did.

A team with a mix is best if it's not a mix just in terms of personnels but in projects and the way incentives are structured.

The culture within the team can go south sooner than one realizes if the 'process' types feel they're constantly cleaning up the mess of pioneers (who tend to get more attention in general for their shinny projects). And on the other hand the pioneers may perceive process-types folks resist any new changes and are stuck supporting outdated technology. The truth usually lies somewhere in the middle.

I'm a fan of this take.

Having the right mix, with good leadership, can balance out the worst qualities and enhance the best ones.

Alternately, with poor leadership and allowing personalities to run amok, you can find a team in a toxic situation.

So you'll need a good, experienced, team-building hiring manager who understands the balance of the necessary skills and personalities.

i hate pocess people with passion.

I am currently working on team that one guys rejects every single PR that doesn't also come with a description of change in Changelog.md .

Maybe don't, they keep the world from falling apart at its duct-taped seams.

You aren't giving us enough context to know whether that changelog requirement is a good one or not. But if your team has agreed on the process, either convince them to change the process, or try to understand why your (hopefully reasonable and competent) colleagues believe it's necessary.

>. But if your team has agreed on the process

what if your team is dominated by process people.

> try to understand why your (hopefully reasonable and competent) colleagues believe it's necessary.

only explanation that everyone agreed to was that "it makes it easier to see what changed"

> what if your team is dominated by process people.

If that's not your jam, consider a new job.

> only explanation that everyone agreed to was that "it makes it easier to see what changed"

Maybe it's safety critical software or there are downstream clients? Maybe it's open source? Maybe it's not actually every PR and we have an unreliable narrator? The post did start with "I hate process people", after all.

For what it's worth, I'm notoriously not a process person. But I've seen and respect stability they can bring to a team and product

dude.. i am not lying or have an option currently to change my job. I don't want to engage with you after that ridiculous accusation.

fwiw way back i used not see the point of changelogs, but after experiencing what it's like to consume a lib or use software without one, also how useful they can be when you need to know what's changed, it i've changed my view on them.

yea i can see it for software libs. This is a greenfield crud app that doesn't have any real users yet and still in a quasi-prototype stage.

Reply on news.ycombinator.com