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

I forget what job it was I was interviewing for but I remember being stunned at the open lack of process they had in place for trying to bother unifying all these teams to be on the same platform framework etc and instead deliberately let sub teams work with tooling that worked for them and didn't create a lot of overhead trying to coordinate and sync and share a common codebase. Every place prior to that day I had only heard of people going for long stretches to impose a company wide uniformity in tooling. All the costs associated with getting everyone on the same page was always taken as a worthy cost to pay and that future date in the promise land would have made it all worth it.

The folks in this other company just flat out said not worth it, just get your stuff done, ideal development scenarios and perfect harmony and alignment have too much hidden costs to bother with.

It's naturally a pro and con scenario but it was pretty refreshing to hear of folks so unconstrained by this self imposed constraint every other shop had imposed on themselves.

But I think that's what truly makes it "engineering." Programming and solving problems are fun in a vacuum but tech is just a lot more than that. Being able to produce a solution to a problem today doesn't mean that the same solution will work tomorrow. That's why we have to _engineer_ a solution, not just produce one.

I'd argue this is true of any engineering discipline. For example consider this analogy: we build bridges to solve the problem of being unable to cross to the other side. But we could also solve this with, say, a boat, to paddle ourselves across the body of water instead; in fact, that's a much more immediate solution that solves the exact same problem. But is it sustainable? Is it scalable? Can it handle traffic? To address these concerns, we _engineer_ a bridge.

Software that's meant to service a lot of people can't just be written to solve a particular problem today -- it must be _engineered_ so that it's future-proof, which is to say, easy to scale, easy to read, easy to refactor, etc. So often the simplest programming challenges become particularly difficult and often interesting engineering challenges.

Finally, to actually answer your question, it entirely depends on the company, the size of the team, and the commitment to code quality and engineering that that team has. Working at Google on the search team, for example, wouldn't be a great fit for you because every line of code you write has to be engineered! But working at a startup might.

But this comes with tradeoffs. Often times, the solution you write will have to be rewritten if you want your product to succeed. Refactoring and re-architecting things are a necessary evil as technology, hardware, and languages + frameworks change over time. I've worked at places where I've found myself repeatedly having to work on the same things over and over again because of how poorly engineered they are! If you enjoy programming and solving new problems and you want to have a career doing that where presumably you're building some sort of product, you have to engineer at least somewhat reasonable solutions today so that you can work on something new, exciting, and cool tomorrow.

I'd be interested to know what percentage of companies are "true" agile. Based on my personal experience, it must be very low.

I think you just need a different workplace. A much smaller company? Academic/non-profit/scientific? The latter might mean a lot less money (that's where I work), but you might love it more.