Switch into ecommerce or marketing. Product companies suck.
Product companies: selling your software as a product means you're always going to feel like you're on an assembly line. Except you're not the assembly line worker, you're the assembly line.
Ecommerce and marketing companies: you build software that enables the company to sell some product. You're not the assembly line, you're not even working on the assembly line. You're designing the assembly line and building the machines. You're the engineer.
Whatever you do, always avoid companies that treat engineering like an IT cost center. The work culture is always dogshit and you're the first to go in a downturn. Look for somewhere that is "engineering first" or "developer driven" (e.g. somewhere a dev is high up on the org chart.)
Interesting. By joining an e-commerce or marketing company, doesn’t it also mean that software is seen as a cost center since it’s not directly the product being sold?
This is why I added the caveat. It's a culture question mostly but figuring it out is obvious when you think a bit about the kind of work you're doing. If your work is customer facing, there is a good chance you're selling a product. If its for internal use, there is a good chance you're selling something else and instead you're raw business value add, i.e. clear business benefit, given a budget with expected and clear returns. Left alone to make the magic happen.
Or to put it another way, if you're adding core value to the business proposition or enabling their core business you're probably not going to be seen as a cost center. If you're R&D or innovation focused, probably not a cost center.
For example, working on a Wordpress site for a newspaper, probably cost center unless they're extremely tech focused. NYT comes to mind, but they straddle the line between saas product and not. They're selling the subscription service which puts you in product camp but they also have engineering functions that work on enabling their writers produce content. The content is the thing being sold, not your software so its probably some mixed feels over there.
I should probably extend the original "ecommerce or marketing" to any more traditionally non tech business model that has built itself as a tech company.
For example:
Working on a website for an architecture firm = cost center.
Working on cad plugins for an architecture firm to use internally = probably not.
And again, caveats, even for ecommerce you could be considered a cost center if the business is more like a traditional brick and mortar but they've "started selling online".
I do wonder whether this is as much of a problem as people think. Most of the time it only becomes a problem when people start doing stupid things to override the parent instead of refactoring a new class out from under it.
The author doesn't disagree with the HTTP RFC at all.
All the author disagrees with is mixing the http server layer and application client layer status codes in the same client response being given to users.
The only argument anyone should be having here is if they believe their api should speak HTTP to their client or if their api should speak through HTTP to their client.
Personally?
I think trying to shove business level response logic in HTTP (or REST for that matter) to be monkey butt level stupidity.
HTTP was built as a RESTful protocol to serving files up to web browsers. And it works great for that.
However, it was not designed to handle the 25 unique and user-readable or not-user-readable errors my one /authenticate route can throw back at the user at different times.
REST and HTTP by extension excels at simple CRUD or file serving operations. But it's just not suitable for these kinds of API's.
Here's an example:
If my HTTP speaking API needs to respond with an error, how should my client handle it?
How should I differentiate errors that should be displayed to users and errors that should be used only for debugging?
If you need to suggest that my client needs to parse out the errors or differentiate between server and api errors in order to be able to show these errors to users then you've sort of proved my point that HTTP isn't a suitable solution to this problem - you're already wrapping an extra non-HTTP protocol inside HTTP, you're just only doing it for errors instead of all application responses.
> It would be difficult or impossible with most observabilty platforms to make it parse the http response
Yea, because they've all been built on top of the same faulty assumption. This isn't a counter argument to the OP in any way and I'm kind of surprised you're not the only one bringing this up as some kind of gotcha.
Obviously platforms would need to be handle and treat http and application layers differently. This is as much a given as the fact you'd have to update all your client code to wrap and unwrap the application layer on top of the http layer.
The observability of your application would actually increase as you'd be able to differentiate between an increase in application failure modes from an increase in http failure modes. That's actually really valuable.
Product companies: selling your software as a product means you're always going to feel like you're on an assembly line. Except you're not the assembly line worker, you're the assembly line.
Ecommerce and marketing companies: you build software that enables the company to sell some product. You're not the assembly line, you're not even working on the assembly line. You're designing the assembly line and building the machines. You're the engineer.
Whatever you do, always avoid companies that treat engineering like an IT cost center. The work culture is always dogshit and you're the first to go in a downturn. Look for somewhere that is "engineering first" or "developer driven" (e.g. somewhere a dev is high up on the org chart.)