Many software companies are a joke

Dear author, you're one of those people who are capable of more and need to take an unfortunate step back.

Given there are so many people who flocked and are still flocking to IT based programming jobs because of the promise that "one day you will be the next " level push.

I've met people who burn themselves out trying to write hundreds of lines of good code in a day. I've had new colleagues come in, publically slate my code, only to have to retract their comments in private several months later once they actually understood what it's doing.

The author is probably one of the types, that left as seniour architect could have build something better with people around him adding polish and other "perceived value" to a customer. (Perceived value in this case being everything from corporate branding to translations to internal tooling).

Most "complex" problems from the non-IT world don't need a full stack all singing all dancing latest npm, all the RAM in the world and a full Oracle site lisence. Most could be solved by some talented coders (3 or 4 max) doing the grunt of the work with others around them adding perceived value to allow the company to add a zero to the net value of the product, and it could be deployed in-house on a 2nd hand server with redundancy built for <$30k for it's whole lifetime. And that's assuming it's not just an app to sell that requires no hosting.

Excellent comment, just wanted to add to this:

> Delivering a product that solves end user needs and is as maintainable and reliable as possible" is the only truly important thing, and only some of that is code.

that it should also bring money, or enough money, to be more precise.

It may sound strange but lots of products that fall on your very on-point definition fail to bring enough money in order to keep the lights on (and then some), this is a point that gets lost on many software developers. For context, I've been a paid programmer for 15+ years now, mostly in small companies, maybe as part of bigger companies/projects the view is a little different and "bringing in money" is not seen as that important for the developers.

Another take on it is that in a big company, even incredibly mundane and boring software can scale to a level that is stupendously valuable once it goes into production. Hence the company can completely afford to have an entire team working away writing 3 lines of useful code a day. It is way more important that the code is created in a way that can mesh with the rest of the giant corporate behemoth (so yeah, documentation, meetings, etc etc) than it is that it is done fast.

> Imagine a dentist who is passionate about pulling teeth out ... That's a great metaphor for code-before-you-know developers.

A key difference between a big decision and a small decision is what it's like to change your decision afterwards.

I don't think we can compare reverting a pulled tooth vs 2 hours of programming the "wrong" thing.

In the programming case, you may have went down a rabbit hole that wasn't correct but at least now you're 1 step closer to the right solution. You probably learned something and the business can write that off as R&D.

In the pulled tooth case, well, I'm not sure I want to Google that haha. Is it possible to fully replant a pulled tooth in a way where it's 100% healthy and you'd never notice it was pulled? I know there's implants but I mean the real natural tooth, complete with its root. I'm sure the process in any case would not be fun for the person who needs the work done.

You could classify one of these as a small decision and the other one as large.

I still think planning and understanding the problem before coding most things is a very good idea btw, but I would feel way more comfortable experimenting with code in short periods of time vs experimenting in a dental chair / operating room.

> complaining about needing to do documentation, or basic project management?

Some engineers are allergic to teamwork. I deal with coworkers with a similar attitude on a daily basis.

The most frustrating aspect of it is that companies are usually bad at acknowledging someone is a bad fit for a project or a team, even when they are shown solid evidence.

A big part of it has to do with how broken the interviewing process is - the focus at the moment is almost entirely on coding exercises and ignore tasks that many developers perceive as boring but can be crucial, such as writing documentation. It leads to mixed results where you end up hiring some engineers with T-shaped skills along with absolute code monkeys.