Tell HN: I love programming but am sick of the software industry

Like anything there are good versions and bad versions. I think we've all been through bad code reviews and bad code review processes, so let's skip talking about those. On the other side, here's what good code reviews/processes I've been a part of accomplish:

1. The give the creator of the code the opportunity to rubber-duck. I've found that 80+% of all bugs found in code (before merging) are found by the programmer themself just by talking through what each change is meant to accomplish.

2. The give the reviewer(s) the opportunity to ask very simple questions and questions about how the code change relates to other major systems that the PR creator may not even be aware of. If there are any remaining issues with the change (the last 20%) this is usually where they are found. This isn't about where to put curly braces. If your team cares about that, use auto-formatting tools or something.

3. It gives somebody... ANYBODY... other than the PR creator, some idea of what the code does and why. This is absolutely critical as it spreads the bus factor. When something goes wrong and a programmer is sick, on vacation, or has left the company, it's critical that there be one or more other programmers who can pick up the mantle. They may not have deep knowledge, but they aren't coming into the code blind either.

4. Building on 3, it spreads the architectural knowledge and decision making of the code base among all the programmers. Code reviews shouldn't only be "run" by senior/lead programmers. Senior programmers should be getting reviewed by junior programmers as well. It's not ego or about teaching. It's about realizing we all make mistakes and we all contribute to the same end goal. Over time, everyone becomes aware of the systems at play and what's going on. When they are presented with a task, they have a much deeper understanding of what's involved, they can estimate better, and they are aware of who else to talk to or involve in the process. Junior programmers will get comfortable speaking up in architectural meetings and bring up good points. This is one way they become senior programmers.

Switching from the "hot" framework we started using last year to the "hot" framework that everybody loves this year is a step backwards from actually solving any problems. And two steps back from being able to maintain the resulting system. The world of startups is so very "now" focused that I think a lot of people (especially on Hacker News) forget that most programmers are still dealing with code written 20, 30, 40 and in extreme cases 50 years ago.

Better is great. Easier is great. But most old code can't be refactored, only replaced. Which means everything that interoperates with that old code has to either be replaced or it has to work exactly the same way. Sometimes that makes sense. Sometimes that's an absolute disaster.

Something that looks "simple" to you really can be too complex in a greater context. Rant all you want, this is just a fact of life. The software development profession has been so fascinated with shiny new toys for the past 25 years that we tend to forget that the hidden (and dangerous) part of the iceberg is not only in the past, but what we're creating now will just make it all that much bigger and more dangerous unless we're very careful.

But. I know places that are so stuck in the past that they are paralyzed and can't do anything at all. There certainly is plenty of "we've always done it this way" that needs to be thrown out the window. Introducing some new workflows or tools could really simplify things moving forward. The problem is knowing which is which. In order to know which is which you need someone who understands the system(s) at a "heroic" level.

I see us moving that way with things like "full stack" or "devops", but those are mostly only considering newer software. Making 30+ years of IT infrastructure work effectively and efficiently really is an epic task. And not one most CIOs I know of are at all capable of.

Sorry, I guess you triggered a flood of things I've been thinking about this past year. I guess I would sum it up by saying that your own rant is very personal and doesn't necessarily take the context that software is developed within into account.

The problem with AbstractFactoryFactoryBean isn’t the name. In the complaints about things like that, the names are used because they are well-chosen, appropriate names for the things being complained about.

The GOF design patterns are influential as boilerplate templates in certain language communities precisely because they solutions to commonly-encountered problems that are not easily reducible to generic, reusable components in those languages.

Design patterns — in the boilerplate template sense, though not the underlying concept — are a language smell, not a language-independent feature of the software industry.