3 ms·

Not only that, but if they wound up throwing away so much supposedly unmaintainable code, then he wasn't the great developer they thought he was.

invisible 9y ago
My feeling was that the spec they wrote and sold was "very hard." Rick neglected to push back (or did and was told too bad) and then the entire project was mismanaged. Maybe Rick was an asshole, but this post kind of blows my mind. I'm making some assumptions here but "two years" of delay isn't something one person causes (unless they're enabled to).
- g051051 9y ago
  Exactly...what was going on for 2 years that they could slam out a replacement in just a few months?
lucio 9y ago
If he had the respect of his coworkers, I'm guessing "Rick" was really a 10x programmer, BADLY MANAGED. You need somebody else who understand the project objectives and can put a limit to the development of "configurable" options. >Rick’s product supported a dynamic workflow with over fifteen thousand permutations. In reality 99% of our use cases followed one of three paths. The team hard-coded the workflow. This removed over 30% of Rick’s work That's a failure of the manager, not the programmer. The good programmers, the ones who enjoy their work, will choose a complicated but beautiful path, will choose to make a configurable workflow whose configuration is itself configurable in LISP. It's the manager job to know that the workflow can be hard-coded and then avoid complexity by the love of complexity (good programmers love complexity solved by intricate and beautiful code). If not managed correctly, 10x programmers will choose the most complex, self-configurable solution where a hard-coded workflow will do. TL;DR: It seems a manager failure. Top talent needs top management in order to focus great creativity in the narrow path of productivity clients will pay for.
- didibus 9y ago
  I've seen a lot of clients and managers ask for infinitely configurable software more often them I've seen devs introduce it as unnecessary complexity. It's often asked by businesses in the hope that afterwards all change are free and don't require a dev to make. Futile for sure, I constantly have to tell the business why that's not sane, and that they actually don't have that many use cases.
- aldarn 9y ago
  I think you misunderstand what "10x programmer" is intended to mean (even though I hate this term and think it is mostly rubbish). A 10x wouldn't make some ungoldly amount of complexity "just because", they would implement the simplest solution that meets the given requirements - hence they're "10x more productive" than other developers; this doesn't mean 10x LOC, just being pragmatic. The ones you describe are the non-10x. Anyway IMO you have more like 4 types of dev, the ones who fail to write fizzbuzz, the ones who can do the vast majority of what they are asked, the ones that can do everything and can self manage and stay focused on (and clarify) product requirements (probably what you mean by 10x) and the ones that have highly specialized skills (e.g. ML, graphics, embedded systems, etc).
  - addicted 9y ago
    Also a 10x Dev would usually go back to the product manager/client and say that feature X looks kind of redundant or a really edge case, but would take a significant chunk of time to code. Is it really needed for v1.0 considering it will cost 2 weeks of Dev Time? You obviously need to have a good understanding of your clients and their needs and the way they use your product to e able to do that, but many shops simply ignore introducing their developers to the actual users of the product.
- projektir 9y ago
  > That's a failure of the manager, not the programmer. The good programmers, the ones who enjoy their work, will choose a complicated but beautiful path, will choose to make a configurable workflow whose configuration is itself configurable in LISP. It's the manager job to know that the workflow can be hard-coded and then avoid complexity by the love of complexity (good programmers love complexity solved by intricate and beautiful code). I see this as a programmer responsibility... how is the manager even supposed to know whether it's hard-codeable? The trouble is often that the programmer doesn't get enough information to make this decision, but that's a different story.
Clubber 9y ago
Sounds like they graded him on feature completion rather than how he implemented the features. It's a one sided story though. I've seen projects fail due to constantly "rearranging the furniture."

invisible 9y ago

My feeling was that the spec they wrote and sold was "very hard." Rick neglected to push back (or did and was told too bad) and then the entire project was mismanaged. Maybe Rick was an asshole, but this post kind of blows my mind. I'm making some assumptions here but "two years" of delay isn't something one person causes (unless they're enabled to).

g051051 9y ago
Exactly...what was going on for 2 years that they could slam out a replacement in just a few months?

lucio 9y ago

If he had the respect of his coworkers, I'm guessing "Rick" was really a 10x programmer, BADLY MANAGED. You need somebody else who understand the project objectives and can put a limit to the development of "configurable" options. >Rick’s product supported a dynamic workflow with over fifteen thousand permutations. In reality 99% of our use cases followed one of three paths. The team hard-coded the workflow. This removed over 30% of Rick’s work That's a failure of the manager, not the programmer. The good programmers, the ones who enjoy their work, will choose a complicated but beautiful path, will choose to make a configurable workflow whose configuration is itself configurable in LISP. It's the manager job to know that the workflow can be hard-coded and then avoid complexity by the love of complexity (good programmers love complexity solved by intricate and beautiful code). If not managed correctly, 10x programmers will choose the most complex, self-configurable solution where a hard-coded workflow will do. TL;DR: It seems a manager failure. Top talent needs top management in order to focus great creativity in the narrow path of productivity clients will pay for.

didibus 9y ago
I've seen a lot of clients and managers ask for infinitely configurable software more often them I've seen devs introduce it as unnecessary complexity. It's often asked by businesses in the hope that afterwards all change are free and don't require a dev to make. Futile for sure, I constantly have to tell the business why that's not sane, and that they actually don't have that many use cases.
aldarn 9y ago
I think you misunderstand what "10x programmer" is intended to mean (even though I hate this term and think it is mostly rubbish). A 10x wouldn't make some ungoldly amount of complexity "just because", they would implement the simplest solution that meets the given requirements - hence they're "10x more productive" than other developers; this doesn't mean 10x LOC, just being pragmatic. The ones you describe are the non-10x. Anyway IMO you have more like 4 types of dev, the ones who fail to write fizzbuzz, the ones who can do the vast majority of what they are asked, the ones that can do everything and can self manage and stay focused on (and clarify) product requirements (probably what you mean by 10x) and the ones that have highly specialized skills (e.g. ML, graphics, embedded systems, etc).
- addicted 9y ago
  Also a 10x Dev would usually go back to the product manager/client and say that feature X looks kind of redundant or a really edge case, but would take a significant chunk of time to code. Is it really needed for v1.0 considering it will cost 2 weeks of Dev Time? You obviously need to have a good understanding of your clients and their needs and the way they use your product to e able to do that, but many shops simply ignore introducing their developers to the actual users of the product.
projektir 9y ago
> That's a failure of the manager, not the programmer. The good programmers, the ones who enjoy their work, will choose a complicated but beautiful path, will choose to make a configurable workflow whose configuration is itself configurable in LISP. It's the manager job to know that the workflow can be hard-coded and then avoid complexity by the love of complexity (good programmers love complexity solved by intricate and beautiful code). I see this as a programmer responsibility... how is the manager even supposed to know whether it's hard-codeable? The trouble is often that the programmer doesn't get enough information to make this decision, but that's a different story.

Clubber 9y ago

Sounds like they graded him on feature completion rather than how he implemented the features. It's a one sided story though. I've seen projects fail due to constantly "rearranging the furniture."