Ask HN: Do you hate software engineering but love programming?

IMO that is the gold standard for 80% of professional software. Ship. Fix bugs if needed. Ship.

If your org wants to do pointless cargo cult process junk and this troubles you, switch employers. Preferably to a place with old steady hands.

Software engineering is not the problem. Problem are orgs that invent pointless process and encourage the managerial types to get some more process in. Not all shops are like that (yet… at least).

I suppose you can probe this at the interview. Too little process and too much are both res flags. Too little:no CI, no testing, that sort of stuff. Too much: like porn, you know when you see it.

I wouldn't assert that this isn't valuable in most organizations; but it drives further into the OP's point that if non-technical people weren't involved in the process, things would simply Be Better; and large swaths of very real, numerous organizations do feel like work programs for people inventing work for themselves.

Allow me to tell a story: I take on an epic of work. The final stage of this epic of work is to build out some UI stuff for a feature. Things get missed, we're approaching this final phase, boss says "oh crap, we need to coordinate with design to get some designs; I'll set up a meeting". The soonest they can get us in is two weeks. I spend three days twiddling my thumbs, then decide to Just Do It. We have component libraries; its like five UI components on an admin dashboard; just do it. I implement it; deploy to staging; then DM one of the designers "hey, I just released a new UI feature; if you have ten minutes today do you mind taking a look and giving feedback?" He had one piece of excellent feedback, I implemented it, and we shipped.

Allow me to tell another story: Two days ago, someone from customer support DMs me and says "We got a security vulnerability report (links to ticket); are y'all the right team to look at this?" We were. I PR the fix, share with the team, done.

Third story: Customer support DMs again. Hey we got a report from a customer about some odd behavior on this endpoint. Me: "Do you mind opening a ticket? That just helps us track it a bit better." "Sure man no problem (links ticket)". "Gravy my dude, I'll take a look at that tomorrow, sound good?" "Awesome!"

There's nothing about any of these stories that would fly with many MBA Orgs' idea of "The Software Engineering Process". They certainly don't fly with our process. It still happens. Why not? Once you start asking five-whys down the reasoning behind things like "it causes interruptions" or "engineers don't like talking to people" you eventually arrive at something proximate to: The MBAs invented a sandbox to justify their existence, they're here on a VC-fueled work program, and everyone has to play in their sandbox.

Things are not better in that sandbox. Companies are less efficient. Employees have higher average misery. Revenues grow slower. But many are blind to it because the MBAs, if nothing else, are great at Talking Good, and we don't know anything else.

(To be extremely clear: I'm adopting the terminology of previous comments, but think "technical" to mean "product-oriented", Product Managers and Designers count, and "MBAs" to mean "People & Process Oriented". Ex-Engineering Engineering Managers are gray area; but I think once you start viewing that role through the lens of buzzwords MBAs love like "Leaders" e.g. "To Lead Your People" e.g. "Inspire" "Mentor" etc; they can only be technical, and need to be more Product-oriented than People/Process-Oriented.)

That's called making it up. While it may have worked for that organization, I assure you it falls it a heap 99.9% of the time large software is developed that way.

There are so many engineers out there that are basically coddled children who get paid handsomely to sit in a chair and write code, and have no concept of where their handsome pay comes from.

Thankfully, this era is coming to an end and companies will be/are already taking a hard look at who is driving business value and who is not.