Hacker News Reader

Comment by andreasgonewild | Hacker News Reader

You know someone is certified when you have to scroll code sideways because the names don't fit the screen. I thought we already agreed that process is the opposite of progress? I mean come on, RequestCourseRegistrationInteractor, who are you trying to impress here? These processes were designed to turn humans into machines; to decrease the dependence on creativity and skill at the cost of additional effort and complexity; to enable large groups of unmotivated developers to deliver mediocre software reliably; which makes them sub-optimal for any other use case.

View on HN

I think you are opposing it for the wrong reason.

There should not be a lot of room for creativity when implementing specific business rules. The goal should be clarity and readability.

These convoluted patterns obscure the logic and confuse the reader with their pointless abstractions.

I think you are confused. The whole point of software is to create something that didn't exist before, building the same software over and over again doesn't make any sense. I'm not talking about creativity in interpreting business rules, I'm talking about creativity in building software.

Who have you agreed with? Software has to be predictable and easy to maintain. It is great if you can predict what the class does based on its name. It is also great if you know what you have to search for based on the name of pattern. Software is there not to express the creativity of a given programmer, but rather to meet the requirement of the technical tasks.

We are all here to express our creativity, that's priority #1 and the only reason we ever went anywhere but in circles. I don't mind descriptive names; these names are not descriptive, these names are part of the process. This is how you really do it: 1) start from the problem you are trying to solve, 2) solve the actual problem in the easiest way possible to get experience, 3) improve the solution until it says exactly what you mean. Bottom up, not top down; skills and creativity, not rigid rules; that's how you build great software.

Most of the programming problems have been solved before. Some of the solutions turned out to be solid programming patterns. Before you write a single line of code, you check if there is a "standard" way of solving the given problem. That way the code is more maintainable and more people will be able to work with your code.

So we've been told. Part of my point here is that code like this is the opposite of more maintainable. Writing code for clueless people to read and understand is a loosing game for everyone, that energy is better used to cultivate skills collectively. This is about not having to differentiate between individuals, about being able to treat a bunch of coders as a code-factory; which is very convenient but neither efficient nor humane.

Reply on news.ycombinator.com