2
points
gtramont
Joined 138 karma
[ my public key: https://keybase.io/gtramontina; my proof: https://keybase.io/gtramontina/sigs/LKfQIT3YjaXRo6G2jVqVtMelBDHt81oOCfsHlikOJO4 ]
- gtramont parentXiao 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.
- 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.
- 2 points
- 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://www.hackerneue.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.
- 1 point
- Reminds me of the late David Graeber' BS Jobs: https://web.archive.org/web/20220901173213/https://www.strik... and the book that followed.
- 4 points
- 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.
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.* 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; * …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/
- > 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…)
- Maybe the following links can help in understanding hypertext/hypermedia?
- "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/
- 1 point
- 3 points
- 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!