Hacker News Reader

Comment by pradn | Hacker News Reader

I'm in a team right now which I believe has a 10x programmer. He picked a simple threading model to prevent tons of wasted time on deadlocks and other threading issues. It's also easier to reason about and get new people on-boarded. When he reviews code, he finds bugs that prevent days of debugging down the road and suggests simpler architectures that make the code easier to understand and change. He has had this effect on ~20 people over ~5 years. I would not be surprised if he saved us ~1 year of dev time collectively.

View on HN

Simplicity is the silver bullet. The longer I work as a developer the more value I see in it. The single biggest mistake I see good but inexperienced developers make is building overly complex & unnecessarily abstracted solutions.

Exactly, and to elaborate on your point, take a problem that seems complex and difficult to break down, and find the simple pieces that can be tied together to solve the complex problem.

To me, that's programming in a nutshell. Or at least what it should be.

That's problem solving in a nutshell :)

Not overengineering is an art.

How do you measure simplicity?

To me part of 10x mindset is seeing most things as a business with an objective. Sometimes that objective gets lost in the name of process. You start accepting projects even when it is not adding a value to the business, but i is done becaude someone wants it. This leaks from the top down. Part of that 10x is to avoid work that is useless.

Implementing unnecessary features also complicates the code. There is a network effect for complicated code -- the more complicated it is, the more complicated you need to make it to add functionality. It's really incredible how fast you can slam the breaks on a project simply by not questioning if you should be implementing something.

On the other hand, feature poor software is not necessarily simple. Simplicity is hard to achieve. It requires a lot of thought and usually a fair amount of iteration. "Don't touch that code because it doesn't have a good ROI" is also a surprisingly good way to slam the breaks on a project.

Maintaining velocity (or even increasing it) requires a delicate balance of avoiding work that will harm you and encouraging work that will help you. There needs to be a dialog between stakeholders and developers that's 2-way to accomplish this.

a delicate balance of avoiding work that will harm you and encouraging work that will help you

Yes this swings both ways. I worked at a startup where every feature improvement was shouted down as a waste of opportunity cost.

They found a decent local maxima but their growth stalled and they degraded into a consultingware company. The more ambitious devs bailed because there was no room for growth.

> I worked at a startup where every feature improvement was shouted down as a waste of opportunity cost.

I'm curious - what were the devs doing with their time, if feature improvements were constantly being vetoed? Were they being kept busy with other tasks which you consider lower-priority, or were they just sitting idle?

Write code to have an impressive features list in the product, even if half of them have 3 bugs per line of code.

It's not a strategy I approve, but it can be effective from a commercial stand-point, specially if the half that doesn't work is the half barely used in real life.

It was specially true in the past, with on premise software where clients were in a kind of lock-down with the software provider. Today, as we move more and more towards SaaS, this approach is far more risky because your client could easily switch to another service provider.

>I'm curious - what were the devs doing with their time, if feature improvements were constantly being vetoed?

Yeah it was a really weird culture, there was definitely some quiet time where I would propose a product improvement but still get no traction. Eg the product website was really embarrassingly 90s, they would let us A/B test customer deployments but not their own site.

There also was a lot of repetitive content scraping tasks that should have been improved and resulted in excessive pager duty (hard to explain but think fragile regexes that parsed customer HTML). That was the last straw for me, I'll do pager duty but not every night just because the PHB is a fool.

They mostly burned our time on trivial consultingware requests instead of improving the core product. I eventually started sneaking core enhancements in by padding out the customer work and just not telling anyone.

This is the same PHB who threatened to fire me because I had to rush my partner to hospital with a concussion. Wonderful human being that.

I will be sarcastic, ironic and voluntarily provocative: he is an idiot, if he was a real 10x developer, he should have chosen a complex code architecture only understood by him, that way he would have been the only one able to implement and maintain features inside the code base, making all the other developers 0.1x and consequently he would have become a 10x developer himself.

More seriously, this kind of situation can happen without ill intent, simply have a fast developer with a strong personality and he will become the lead for everything and the only one able to understand the code base.

Also the velocity of an individual developer can be overvalued and mistaken for a 10x, it's certainly easier and faster to write spaghetti code instead of a well designed/architectured code base, but doing so can have dramatic effects down the line, or even immediately for the other developers in the team. Yet it can be a quality in critical situation (like our startup will shutdown if feature X is not implemented in 2 days).

It can be hard to differentiate between a developer like I describe and a real 10x developer you describe. The applications we designed can be quite difficult to implement depending on the complexity of the domain specific logic the application deals with. Sometimes it's impossible to recognize between complexity caused by the application architecture (generally avoidable) or complexity inherited by the overall domain logic (nearly unavoidable).

And lastly, it's never, ever as black and white as I describe.

That being said, your colleague seems like a really good developer, able to see the big picture and steer a code base in the right direction. I hope for you that he will part of your team for a very long time.

One year of others' time saved over five years would make him a 1.2x programmer.

Not if regular programmers create extra work.

That was after he picked the simple threading model. Had he picked a baroque threading model it might well have been 10x the effort for the entire project.

You forget all the time he's saved himself over that period

Reply on news.ycombinator.com