3 ms·

I am not a developer, but a founder and product designer, so take my opinion with a grain of salt please. From my perspective, what separates great developers

I am not a developer, but a founder and product designer, so take my opinion with a grain of salt please. From my perspective, what separates great developers from good ones is the ability to accurately predict how long something will take to build. This helps so so much with product development, sales etc. You also need to be able to build things quickly and correctly, but as long as you can say how long it will take, you're doing your team a HUGE favor.

jolmg 7y ago
That probably depends on how similar a given project is to projects done in the past. I suppose that a developer that does the same kind of thing (like Web CRUD apps) over and over would be able to accurately determine how long a new one would take, but if their work often varies in domain (a webapp, a compiler, a bootloader, a console emulator, a 3d screensaver, an email client, a sound editor, etc.), then I think not. In other words, I think how accurately one can predict the time it takes depends on how repetitive the work is, and I don't think doing more repetitive work necessarily means that a programmer is better.
invalidOrTaken 7y ago
Unfortunately, this is only one signal among many, and it's not a reliable one. It's like saying a good gambler is one who is lucky at the slots. Sure, but... You'd be better off injecting a large amount of uncertainty into your estimates, and planning around that. If that kiboshes a project, it kiboshes it. Better to fire your devs because you have nothing (feasible) to work on, than to fire them three months later because the project was late, because you have to pay them in the second scenario.
- stephencoyner 7y ago
  Creating a large window to account for some uncertainty is fine. My main point is in working with some less experienced engineers they'll say "This will only take 2 days" and it takes two weeks. This kills teams. I think less experienced people do this because they are excited / eager to please, but it only hurts in the long run.

jolmg 7y ago

That probably depends on how similar a given project is to projects done in the past. I suppose that a developer that does the same kind of thing (like Web CRUD apps) over and over would be able to accurately determine how long a new one would take, but if their work often varies in domain (a webapp, a compiler, a bootloader, a console emulator, a 3d screensaver, an email client, a sound editor, etc.), then I think not. In other words, I think how accurately one can predict the time it takes depends on how repetitive the work is, and I don't think doing more repetitive work necessarily means that a programmer is better.

invalidOrTaken 7y ago

Unfortunately, this is only one signal among many, and it's not a reliable one. It's like saying a good gambler is one who is lucky at the slots. Sure, but... You'd be better off injecting a large amount of uncertainty into your estimates, and planning around that. If that kiboshes a project, it kiboshes it. Better to fire your devs because you have nothing (feasible) to work on, than to fire them three months later because the project was late, because you have to pay them in the second scenario.

stephencoyner 7y ago
Creating a large window to account for some uncertainty is fine. My main point is in working with some less experienced engineers they'll say "This will only take 2 days" and it takes two weeks. This kills teams. I think less experienced people do this because they are excited / eager to please, but it only hurts in the long run.