https://www.youtube.com/watch?v=28S4CVkYhWA - here's Woody Zuill presenting on the subject. Nowadays this practice is also known as Software Teaming, or Ensemble Programming.
The major problem I see with these "performance reviews" is putting everything into the same bucket: feedback, compensation, career ladder progression—which I could go on about, but this isn't the point I'm trying to make.
In the end of the day, what _really_ matters is if people are getting compensated fairly compared to their peers. Sure, some people like to play the power game and get excited with becoming a "newly-made-up-title-that-sounds-important-but-I-dont-get-paid-more". But these people are only playing a game, very likely unawarely, that was already set by the company.
It all comes down to how a company lays out its incentive models. And, truth be told, the vast majority of the software companies out there do a terrible job at it. The people in "charge" don't know better and end up replicating what others do: a Taylorist approach (https://en.wikipedia.org/wiki/Scientific_management). It goes without saying that, for a company that requires knowledge work, this isn't the best approach. A lot of perverse incentives crop up (https://en.wikipedia.org/wiki/Perverse_incentive).
A better model, from my perspective, is one that dissociates feedback from compensation. This usually goes hand-in-hand with a more transparent culture; with self-managing and self-organizing companies:
If they allowed the postfix cast syntax to work for non-interface types too, it could have been a single chain, actually (you could do `.(Iterator[int, float32])` inline instead of needing the extra variable.
Note that the original implementation in the article modifies the collections in place, in which case this issue doesn't come up at all: you can't put strings in an array of ints. My implementation creates copies of these collections so that the concept of mapping to a new type actually makes sense.
It is a consequence of (a) Go's implicit relationship between a concrete type and the interfaces it implements and (b) Go's "heterogenous" translation of generics (like C++, unlike Java). Together, this means you can't know which methods you need a priori. All proposed solutions to date essentially compromise on (a) by limiting the generic "implements" relation to things known at build time, or on (b) by making generic methods "homegenous" (aka boxed) and thus slow (see https://github.com/golang/go/issues/49085#issuecomment-23163... for an elaboration of this approach); or, they involve dynamic code generation.
It's broadly similar to the reason why Rust won't allow generic methods on traits used to construct trait objects. It seems superficially like a reasonable thing to want, but actually isn't when you consider the details. (The sister comments link to the specific reasons why in the case of Go.)
I recall reading some details around this on https://blog.merovius.de. Maybe it was this article: https://blog.merovius.de/posts/2018-06-03-why-doesnt-go-have.... Compilation speed plays a big factor when deciding which features are added to Golang and I think they'd have a hard time maintaining the current compilation speed if they remove this limitation.
Back when the Go team announced generics, I had a go (pun intended) at it: https://github.com/gtramontina/go-extlib -- might resurrect it one day. `lo` is pretty comprehensive though.
And yet, there they are… clueless… pushing down traditional management practices that incentivize the exact opposite of what they "say" they want: collaboration. Unfortunately. * sigh *
For a lot of management, "collaboration" means, "You do what I want and you get paid for it." And not, "We'll work together to figure out how to make this work for both of us."
https://www.amazon.com/First-Break-All-Rules-Differently/dp/... is a great book on how effective managers actually take their employee's strengths and weaknesses into account, and lean on their employee's strengths. (Trying to fix them is probably a lost cause.)
Modern coaching and performance management have moved heavily to strength-focused approaches for exactly that reason. Hell, over 20 years ago I was introduced to StrengthsFinder, which is built on exactly that model.
The real problem is most of the managers I've worked along side either don't want to/like to/care to coach, or were never taught how to do it well, having come out of an IC background where they, too, probably never experienced effect performance management. And, ironically, they often get moved into management not based on their natural strength as a coach/manager/mentor, but rather based on their strength as an IC (because, again, their own management likely doesn't understand how to take a strengths based approach to identifying and elevating potential leadership candidates).
The book I recommended made the recommendation that a move to management always come with a pay cut, and most managers should have someone reporting to them who makes more than they do. I consider both recommendations to be excellent ideas. People should go into management because they think that they are suited to it, and not because it somehow seems like the next step in their natural career progression.
Funny story. Ian Siegal, founder and CEO of ZipRecruiter, first went into management because the programming team told the CEO at CitySearch, "Hey, this junior HTML guy is good with people, we'd rather report to him than the dufuses that you keep hiring as CTO."
Turns out that he was good with people, and was a good manager.
Personally, every time I see somebody say "collaboration" on the context of management, it means "you individual contributors go and work with each other". I have never seen it used in terms of collaboration with managers.
I take not mentioning hypermedia in a post discussing REST as a huge red flag. The author mentions Roy Fielding's dissertation, but apparenly they didn't read it thoroughly.
Furthermore, I believe that a huge confusion comes from not understanding what a "resource" is: it is not a database table*; it is not your domain model*; it is a _representation of state_. Like this very orange page you're looking at. This whole page is the resource identified by https://news.ycombinator.com/item?id=35014395. Just like the stylesheet for this website is a resource identified by https://news.ycombinator.com/news.css.
* It may be, if that's the _representation_ you want.
REST is such a bastardized term. At this point it’s often used synonymously with JSON/HTTP or simply meant to contrast between SOAP, GQL, gRPC, etc. without respect to its actual tenants.
The naming of "resource" is a bit unsettling. From the perspective of the server, it seems natural to think of all databases and external machines. "Representation" sits better with me, but ultimately in the code, I would prefer to name the REST endpoint as a "service".
These aren't bullshit jobs, or at least the two on mostly unrelated. These are "real" jobs that need title inflation because title is cheaper than cash. The article uses the example of building receptionists.
Receptionist may or may not be strictly necessary for any particular building, of course, but it's indisputable that a building receptionist is a real job. Eg a large office or residential building where you have a large number of people coming and going throughout the day. Part security guard, part front office mail clerk, part janitor, part concierge. More than enough random little tasks that are difficult enough to automate in the edge cases.
The article also mentions "Sanitation technicians", which are about as far from a bullshit job as you can get... someone has to clean the shit.
There is notable overlap between bullshit jobs and inflated titles though. Poke around any large corp and you'll find plenty of "Global Head of Value Engineering Strategy" types, often 'heading' a team of 1, namely themselves.
Hence "reminds me". Indeed they aren't the same, but I disagree that they're unrelated. I'd recommend getting past the article and book titles to understand how these jobs come to be in the first place.
