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.
Fork the dependency and use that, to have a stable non-changing base which you use. And additionally, make the original project a dependency but don't actually use it. This way you'll get CVE information from your tooling.
If you fork a dependency and change features, the CVE information on original depenency is now no longer valid for your code. Your additions or removals can induce new CVEs, or render CVE for original lib a moot point.
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.
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.
> also to ensure the standup is actually interesting.
If you have to put forth effort to keep the standup interesting, you are admitting that the people see no value, which means that you are meeting just for the sake of meeting. If you see value in meeting just for the sake of meeting, why not talk about what you did on the weekend instead?
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
I'd agree with this. The article specifically mentions the need to analyze rather than jump to conclusions, and "That won't work!" is usually a case of the latter. If TWW is the result of an analysis, then it is definitely not what I was referring to in the article.
