This kind of thing is why I hate working for larger corporations.
There’s a tipping point where an organization grows large enough that you can no longer trust your colleagues.
It’s a weird inversion where managers advocate for employees that act favorably towards them when everyone else in the trenches know they are awful or incompetent.
Reducing costs (and then trying to drum up community goodwill by "releasing" an open source tool) is not the same thing as generating revenue. https://github.com/Azure/peerd does not have a "pricing" section.
Location: Oregon, US
Remote: Yes
Relocate: No
Technologies: Too many to list. Go, Python, Node, Terraform, k8s, AWS in daily use.
Resumé: https://www.linkedin.com/in/jalheid (PDF available on request)
Email: hamwisespamgee1@gmail.com (This email is for public sharing due to scraping bots.)
I wonder how that could be possible? There are proportionally so few of us old-timers around to begin with, given how much smaller the industry was and how rapidly it has grown over the last 20-30 years.
> People who stress over code style, linting rules, or other minutia remain insane weirdos to me. Focus on more important things.
Considering anyone who is any good is gonna automate these things… and they are very important for long term maintenance and readability and predictability…
… probably the author is terrible. Sad to waste a decade.
I mean their intentions are good but if I worked at a place that made me use that error package I'd not have a good time
In general with golang, if something is not idiomatic Go then don't try too hard to fit constructs from other languages into it. Even the use of lodash like packages feels awkward in Go
Go ahead try to implement something like cross-origin requests or multipart encoded form uploads just using the body semantics you described. I’ll wait.
Also that is not a controversial take. It is at best a naive or inexperienced take.
Both of those happen in the context of web browsing rather than existing in APIs in a vaccuum; I'd argue that there's absolutely no reason why the mechanism used to request a webpage from a browser needed to be identical to the mechanism used for the webpage to perform those actions dynamically, which is pretty much my whole point: it doesn't seem obvious to me that it's useful to encode all of that information in an API that isn't also being used to serve webpages. If you are serving webpages, then it makes sense to use semantics that help with that, but I can't imagine I'm the only one who's had to deal with bikeshedding around this sort of thing in APIs that literally only are used for backends.
There’s a tipping point where an organization grows large enough that you can no longer trust your colleagues.
It’s a weird inversion where managers advocate for employees that act favorably towards them when everyone else in the trenches know they are awful or incompetent.
reply