gtramont

Xiao Xiao and Ninjai *chef's kiss*

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.

Here's a list of mutation testing tools for various languages: https://github.com/theofidry/awesome-mutation-testing

If you're looking for an option for Go, https://github.com/gtramontina/ooze can be of help. It was heavily inspired by https://github.com/zimmski/go-mutesting

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:

- https://en.wikipedia.org/wiki/Maverick_(book) - https://www.reinventingorganizations.com/ - https://mooseheadsonthetable.com/ - https://www.humanocracy.com/

Team-set salaries is one that I like a lot. Unfortunately, it isn't as wide spread. Here's a few more resources on it:

- https://www.percival.live/post/team-set-salaries-tss - https://www.infoq.com/news/2022/03/tss-company-wide-compensa... - https://www.youtube.com/watch?v=M1rMMmO_iO0

Hopefully I planted a few seeds.

Unfortunately the chain approach breaks down when if you need to `map` to a different type, for example. Go does not allow generic typed methods.

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.

Came here looking for this comment. It seems that Kent's re-discovering (re-inventing?) event sourcing…?

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 *

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.

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.

Reminds me of the late David Graeber' BS Jobs: https://web.archive.org/web/20220901173213/https://www.strik... and the book that followed.

That's an interesting question. I've been meaning to write something about it for ages. Here's a brief:

People, vision and ways of working. With time, I've developed my values and principles that makes me practically unemployable if I don't turn a blind eye to some of them. Alternatively, I could start my own company.

    * Small, empowered, and trully cross-functional team;
    * Highly collaborative in ensebles;
    * Unified flow with limited WIP;
    * No middle-management;
    * Little-to-no hierarchy;
    * No titles or levels;
    * Team-set salaries;
    * Organic team growth;
    * Test-driven;
    * Trunk-based;
    * Continuous delivery;
    * No perverse incentives;
    * …

Like XP, they complement each other. So, in order to actually reap the benefits of a practice, other practices ought to be adopted too. Many of the cargo-culted practices and problems fade away when doing things fundamentally different. And very few places challenge the status quo (especially when it comes to management). Forming a (real) team is very hard, and very fragile. Like trust, which I didn't mention above, as I believe it to be a natural consequence of building such an environment.

Needless to say that it is pretty much impossible to find a place like this. Although, with some compromises on my values and principles, I consider the current company I'm working with way above average; granted, I helped shape the culture, which seems to be diluting/changing now as the compromised values are missed. The company is trending towards mediocrity in that sense.

Another option that it is worth exploring: https://hyperview.org/

"Slack handles this well" That's questionable… ':) — Though I get it now. And that's indeed a need! Reminds me of when we needed to setup IRC bouncers to not lose history. Thanks.

> Make Slack and Discord communities Google-searchable

Isn't Slack an acronym for "Searchable Log of All Communication and Knowledge"?! Then they either failed miserably at making it searchable to the point of requiring an entire new business to make it so, or I'm not seeing the point of Linen.

After taking a stab at some more functional approach with generics in Go — https://github.com/gtramontina/go-extlib — I do agree that some of it does feel shoehorned. Although for some other constructs, it feels quite nice. As I mentioned on the readme of the linked repository, this post https://hypirion.com/musings/type-safe-http-servers-in-go-vi... presents pros and cons nicely.

Closely related: https://www.manim.community/

(disclaimer: I've never ran I company myself, but have been part of numerous teams and experienced some growth pain; so the following is my [sort of] one-sided view of the picture)

That's a pet peeve of mine. Adding more people feels more like a company "ego" inflation injected by VCs so they "look good" and valuation goes up. External pressure. It can make good ideas and teams de-rail fast… processes will be introduced, knowledge silos will emerge (because how else would you justify your job in 6 months?), great people will leave because what they don't feel connected anymore. And you rarely observe this in bootstrapped companies.

There's this false pretense that adding more people will yield more "product". And that we need 1 person for infra, 1 person for backend, 1 person for web front-end, 1 person for iOS mobile, 1 person for android mobile, 1 person for… Outsiders only see these "labels" and head counts.

Growth != more people.

(ps. sorry if this looks unfinished and rant-y; I'm not exactly in a good mental space and needed to vent out a bit…)

This is amazing! Thanks for the link.

Maybe the following links can help in understanding hypertext/hypermedia?

http://amundsen.com/hypermedia/hfactor/

https://gtramontina.com/h-factors/

"Logging is a feature", as the authors of Growing Object-Oriented Software Guided by Tests state. As such, we need to treat them as we would treat any other feature. One relatively straightforward way of adding logs is by decorating your objects. Logging decorators.

For example, if `Client` is defined as an interface, we can have two concrete implementations. One that holds business logic – `NetClient` – and one that holds logging/developer logic – `VerboseClient`. As we inject dependencies, we can compose a client like this: `NewVerboseClient(NewClient())`. This way you may even test you logging logic by composing it with different implementations of clients (one that always fails, for example) to test the different kinds of logs.

Take a look at https://hypothes.is/

The same ideas still apply. Take a look at this explanation: http://vvgomes.com/javascript-dependency-injection/ -- suggestion for after you read the post: depending on your needs I'd recommend not using the default value as, from a dependency perspective, you end up tightly coupling the two. Hope it helps!

Related: http://docopt.org/ – There are implementations for various languages. Whenever I need to write something that has a CLI, this is my default option…

Good point on trivializing other people's work. I can definitely see how it can be interpreted that way. Just to be clear: that was absolutely not my intention. It was more like a "this reminds me of some good old times, does anyone else share the same nostalgia?" type of comment. So, again, sorry if I rubbed you (or anyone else) the wrong way. And I appreciate you taking the time to expand on what I thought was a simple comment.

Thanks! To be honest, mea culpa, I didn't look anything up before asking that question. Glad I did, though. Care to expand on the lessons learned?

Thanks for the link! Seems neat!

This was meant to be a joke. At the same time, it was meant to foster people's curiosity/education on what our industry has tried before. Sorry if it rubbed you the wrong way, though.

Now an absolute honest question… how long do you think it'll be before we come across something like VRML again?

VRML, anyone? :-)