keithplayer's comments

The benefit of using a library directly is your 3rd party library checks will warn you when a CVE is found in the version you are using. If an LLM creates the same functionality from copying a version of a library, you might be getting a version that already has known vulnerabilities, and you probably won't be pulling in any fixes/improvements in future until you find them.

StaffEngaged https://staffengaged.com/

A few years ago I had the idea for a service that would allow you to better understand what type of coaching and feedback managers were giving staff. Still in beta, but there are a few ways to make this service more useful for first line and functional managers.

I think the HN relevant use case would be looking at this from the opposite side. You've designed 2 games (or algorithms) and both result in a winning state. But when they are used alternately, they lead to worse outcomes. A made up, possibly bad example that's using similar 'rules':

Start with: 1 large fixed size data structure and 1 cache Algorithm A: Checks as it is iterating whether the cache is full. If not, it generates the cache data (SLOW) but can then iterate over the entire data structure quickly. First time it does this is a loss, but 2nd pass through the data structure leads to an overall win. Algorithm B: Prefers an empty cache. If cache is full it will delete it. It can iterate over the entire data structure fairly quickly. Each time is considered a win.

Now you have a program with many different features and everyone knows that it doesn't really matter if you use Algorithm A or B because they are both programmed to work safely together and if you test a feature using one of the algorithms it will be fast either way, so it's left up to personal preference. The fun begins when the full program starts alternating from algorithm A to B.

I agree and the following is more related to the text you quoted.

I interviewed at GS and as soon as I saw the room of clearly exhausted and joyless developers, I could see they actually valued the appearance of work more than productivity.

The 40-hour work week was introduced for a reason: https://cs.stanford.edu/people/eroberts/cs181/projects/crunc...

It is sad that 100 years after Ford made the discovery people still don't get this. Team A consistently working 40 hours per week will output more work than Team B working 60+ hours per week. That's true for 60, 80 and especially 95+ hours.

If a team member says they worked on Jira #X and will continue working on it other members should be asking for the technical details. Everyone should be giving 1-2 sentences of the technical details of what you worked on yesterday and the same for today. It is up to the team to question what is happening not just for accountability and ensuring people aren't going off on already explored paths, but also to ensure the standup is actually interesting. A blocker isn't the only reason other team members might need/want to get involved in what someone is working on.

As mentioned often "that won't work" is a good way to cut off all creative thought processes and should be limited, but there are definitely times when a quorum of uninformed parties are about to commit to 'an investigation' where someone calling it straight is appreciated