Hacker News Reader

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).

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.

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.

> 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.

The buck stops with the manager. Every time. Only a poor carpenter blames his tools and people are a managers tools.

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.

> good programmers love complexity solved by intricate and beautiful code.

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').

A good programmer solves the given problem in the most simple, decoupled, way possible. Their solution will inevitably be easy for other devs to jump in and understand and work one with breaking the rest of the code base.