Comment by wvenable | Hacker News Reader

Comment by wvenable | Hacker News Reader

Like others here, I don't consider 10x programmers to be someone who writes 10x the amount of code. In fact, most 10x programmers actually write less code but get more done with it.

Personally I think the narrative works better when you think there are 1x programmers and 0.1x programmers. And a very large number of developers are actually between 1.0 and 0.1. These 0.1x programmers somehow manage to solve problems by simply puttering away at it over time. For example, these programmers might start out reading a web service into an XML file, re-opening that XML file to process the result, copying that file someone else that is never read again, taking the result and inserting it into a database table, reading the table to create an aggregate result, and then finally inserting that result into another system. And they do this all day long every day for every problem they come across.

Not everyone is quite that bad, there are 0.5x programmers who know better than that but still manage to write 6 classes to solve a problem that could be done in a single 2-screen long function.

Tools and processes can help and code reviews are pretty invaluable. Any good process will have weeded out 0.1x programmers already and they will settle in those places without them.

> 6 classes to solve a problem that could be done in a single 2-screen long function

Isn't the former promoted as better programming? IoC, decoupling, Law of Demeter, testability etc

Promoted? Yes. Actually? No.

So, genuine question, why?

You scatter the code all over the place, making it harder to understand and less flexible (less flexible, because if you want to change something, now you have to change it in six places).

Best practice doesn't mean "make as many classes as possible" although I would probably break up two-pages into a few different functions (large functions, even when they are good code, invite programmers who come later to add to them in a messy way).

If you have to change it in six places it just means that you did something wrong. Keeping those six places in the single file is not the solution either: next time you will need something similar, but not exactly the same you will copy that file. And next you will find yourself changing twelve places.

The good rule of thumb is not to refactor into reusable parts unless you need to do something similar. It isn't hard, at that point, to split things up. Premature design is like premature optimization -- you do the wrong things, or things you never need to do.

And yes changing things in six places means you did something wrong, but that's easy to do when you start by splitting things into six places. The worst, of course, is when developers don't change it when it needs to be changed and instead just keep adding. Once you have something so designed it makes removing and changing code more painful than adding code.

Both of the examples above are actual things I've seen. As for this one, it was not better programming, it was just over-engineered. I think that over-engineering is a stage all developers go through in their career. What is considered "better programming" certainly contributes to the problem.

It took 4 times as long to produce the solution that was 4 times bigger and more complex than it needed to be. Maintaining that huge body of code forever is more than 4x the effort over time than a single small function. And that's how you get a 0.25x (or less) programmer.

There is probably a good middle ground. If it's a "once off" sort of task, then there is no need to over-engineer it to perfection.

The sweet spot has a nice tradeoff between extra-time spent, and ease of migrating to a full-blown complicated and extensible solution. For me, I generally write my code in that middle ground. Stubbing out parts of my solution and then coming back to fill it in. In that sense, having separate functions with clearly-defined input/outputs or portions of work, aides me in completing my solution.

All of those things being "better" include an implicit "...in the context which these best practices were studied" which usually means large teams of just-OK programmers writing Java code that mostly doesn't need to perform very well but will be changed a lot, and needs to be very consistent in style and pattern so that when an intern comes in and pokes it as his first commit he can't do any serious damage.

You can imagine a million ways those assumptions break down, as well as a million ways they seem to but should actually be stuck to. Knowing the difference is the tough part.

Reply on news.ycombinator.com