5 ms·

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

by pradn 9y ago

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.

cageface 9y ago
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.
- jimbokun 9y ago
  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.
  - warrenm 9y ago
    That's problem solving in a nutshell :)
- tehlike 9y ago
  Not overengineering is an art.
- catnaroek 9y ago
  How do you measure simplicity?
tehlike 9y ago
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.
- mikekchar 9y ago
  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.
  - hnzix 9y ago
    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.
    - whack 9y ago
      > 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?
gary_bernhardt 9y ago
One year of others' time saved over five years would make him a 1.2x programmer.
- jerrre 9y ago
  Not if regular programmers create extra work.
- sunstone 9y ago
  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.
- warrenm 9y ago
  You forget all the time he's saved himself over that period
kakwa_ 9y ago
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.

by pradn 9y ago

cageface 9y ago

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.

jimbokun 9y ago
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.
- warrenm 9y ago
  That's problem solving in a nutshell :)
tehlike 9y ago
Not overengineering is an art.
catnaroek 9y ago
How do you measure simplicity?

tehlike 9y ago

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.

mikekchar 9y ago
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.
- hnzix 9y ago
  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.
  - whack 9y ago
    > 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?

gary_bernhardt 9y ago

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

jerrre 9y ago
Not if regular programmers create extra work.
sunstone 9y ago
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.
warrenm 9y ago
You forget all the time he's saved himself over that period

kakwa_ 9y ago

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.