>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.
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).
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.
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.
If a carpenter doesn't pay attention and a sharp saw cuts their hand off or ruins an expensive piece of wood maybe they need training in how to run saws. Or perhaps they just need less powerful saws until they get more experience.
Management is a lot more than going to meetings and ordering people around. The ability to successfully staff and orchestrate a project is no small skill and one can't just jump in and expect success. Lot of people think they can do it, but there are very few really good managers in my experience. Most are hacks who can't actually do the job and don't even understand what it entails. As evidenced by the article.
I can't speak for good programmers, but while I admire elegant and insightful solutions where possible, for the other 99% of the cases I prefer the simplest effective solution (and with simple definitions of 'simple').
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).