Ask HN: I love programming but hate the industry. Can anyone relate?

Someone who's consistently working extra spoils the situation for the rest of the team. They'll eventually end up having the most knowledge and experience since they're working with the code more and they'll almost certainly be the most productive person on the team. When it's time for reviews, raises, and promotions who do you think a naive manager will flag as the all star top performer on the team? One can argue that that's fine and they deserve the raises and promotions because they're working extra, but it ends up putting the team in a very unhealthy place where the other team members can't really compete with the workaholic unless they too start working extra.

No-code is more likely to be written by people who are direct experts in the business domain, unlike the telephone game that is the development cycle in most software orgs.

I think I understand. Someone who doesn't have anything better to do might as well contribute their idle time to working, as long as it's voluntary and without expectation.

I might agree were the worker a shareholder or founder or otherwise long hours were the explicitly stated, well-compensated expectation when hired.

For the average full time employee, absolutely not, particularly not even for junior/entry-level. Spending unpaid evenings and weekends at work prevents someone like yourself from acquiring and maintaining a social life, emotional resilience, physical health, community support, romance, poetry, moments that make life worth living. I'll be damned before I participate in the crushing of souls like that, my own included.

That said, there are roles for people who cannot live another life. If that's you, do not waste your ambition as a full time employee. Be a founder, or work in finance. Or at least a freelancer with unlimited hours. Be compensated for your time.

Otherwise, pick up a hobby. Hit on that cute barista. Learn to play ukulele. Join a tabletop RPG club.

Your argument is quite usual in this sort of discussion and it mostly comes from dev managers or TLs who are almost gone to the 'other side'.

I (everyone?) agree that software development is not only programming/writing code. It also system design, documentation, finding solutions, troubleshooting, load testing and so on. And yes, it is also gathering and understanding requirements and collaborating with other teams. But if your average developer only has 20% of time for coding and everything else goes to meetings, you are doing something terribly wrong. Simply because the time of the developers is used inefficiently, unless you are doing something very simple (from technical point of view) and cut costs on other roles, so devs are doing everything. Usually it means that there is no proper Product/Project management and technical leadership. You can build a lot better and faster if your developers have time to focus on development itself without going to constant meetings to understand this sentence in requirements. Even during my 'worst' (from dev time perspective) years as a TL I spent ~40-50% of my time to management/communication work. It allowed team of 5 devs to be almost distraction free (less than 3 meetings per week per dev), because I worked as proxy for them.

In my experience adding good technical PM between devs and other managers can greatly increase devs efficiency and more importantly - their happiness

I spent much of the first 15 years of my career at companies that would rather ship crappy software tomorrow than good software next week. The stress level was high because we were always in a rush, and management always was always pushing to get more out of every developer, like wringing the last drop of juice from an orange before they threw it out.

We often worked overtime so we could write the code we were assigned to write. We couldn't do that during office hours because office hours were for meetings, answering email, and fixing bugs in the crappy code we pushed out last week. Because last week's code was counted as "done," fixing it didn't count as "progress." We weren't getting anywhere unless we produced something new, and that only happened after hours.

A few years ago, I started working at a university in the US, where things move much more slowly. I started having the time to properly architect software, to rewrite chunks of code when necessary, and to write much more thorough tests so I'd have fewer surprises when we got to production. The saner pace and the ability to be thorough made the work enjoyable again.

The academic world in general tends to move more slowly and cautiously than the start-up world, and that academic mindset creeps into even the non-academic parts of the university. The go-slow-and-be-right attitude is good for designing and building complex systems.

That said, universities are a mixed bag. Get into the wrong department, and you might find yourself maintaining crappy software that no for-profit enterprise would ever run. You might find yourself in even more meetings, with more politics, about things that matter even less.

But if you manage to find a decent project with a decent manager, the university can give you back your work-life balance, along with some of your sanity. You'll even find a little extra energy to put into your side projects, because the job hasn't wrung you dry.