> My life got much better when I realized that I actually don't like "programming".

I like programming, but hate most things around it.

Under-documented code with odd patterns, no comments and bad discoverability, like the code doesn't want you to explore it and work with it, but you instead have to dig in a whole bunch to understand what you're looking at, while you're already juggling the problem domain in your head.

Same extends to working with projects themselves, like having a placeholder README, no ADRs, no information about why certain choices have been made, no investment into tooling or automated linting etc., especially if some things are expected to be done manually by the developers ("order the variables this way", "format the code this way", "you must manually create these N layers of abstraction to make the code consistent"), also things like having no examples of how to use some of the abstractions and if it's a front end project, no examples of the components in isolation, separate from where they're used in the main codebase, no gallery of sorts. Maybe things like manual deploys, or environments with no monitoring/APM/uptime alerting and other bits of tooling that are pretty much essential, no clear information about how things are run on the servers etc., where working feels like some form of archaeology and detective work.

Also things like bike shedding, yak shaving, cargo culting, taking practices as gospel (DRY/SOLID come to mind, though they have their place), infrastructure aspects like not having your local DB that's safe to break, slow compilation, flaky tests, bad tooling, outdated packages and dependencies. Throw in conflicts of interest and opinion that aren't managed well and you have a recipe for burnout, the kinds of situation where people are pretty much "against" you and what you're trying to do, e.g. holding up a release over unrelated, non-blocking concerns, or having drawn out discussions about how to write code, when it doesn't feel like you're working "together" to make things better for everyone. Even when there are disagreements, it's possible to get to that better place, but often time egos go unchecked, instead I actively try to be kind to others in code review etc. nowadays.

Although humorous, posts like this still ring true in many respects: https://www.stilldrinking.org/programming-sucks

But honestly, a lot of working in the industry also sucks due to technical concerns. This might be a more personal example, but I was trying to write some load tests in K6 for a web API. The API uses STOMP on top of SockJS (using WebSockets when available). K6 has support for WebSockets, except there's two packages, one of which is experimental. I quickly realized that SockJS wouldn't work, so I had to get rid of it in the project (since IE doesn't need to be supported anyways), but even then I realized that STOMP isn't supported out of the box, in part due to the protocol never really taking off: https://stomp.github.io/ I could find an extension, but getting it working also proved to be a bit of work: https://github.com/walterwanderley/xk6-stomp What sucked in particular was not only not having that much documentation about how to manage multiple subscriptions at the same time, but also the fact that reads were blocking instead of Promise based, though that might be due to how everything integrates with K6, it's not like I can shoot off a background thread. Eventually I got some jank implementation working that's based on blocking until a short timeout (like 2 seconds) after which the next subscription is done and data from it read, but it feels like if the industry was a bit more coherent we'd have like 2-3 solutions for similar use cases all of which would work well, instead of the current disjointed mess. This also applies to everything from OSes, to back end languages, front end libraries/frameworks etc., though I guess the variety is needed even if painful, so the better ideas survive the test of time. Until someone does some CV driven development and adopts a technology that's not ready.

That said, a lot of those things can be made better, as long as you care enough (and hopefully are rewarded for making the work not miserable).