unicolet.org

Accuracy is more important than precision! Let me illustrate that with an example: I need to measure the length of a piece of wood, let's say its real length is 10cm. Accuracy is how close I am to 10cm in the measurement, and precision is the number of decimal places (or error range, if you want) you can read out. If I measured with an extremely precise instrument and it said the piece of wood is 9.855 cm (3 decimal places) and another one that gave me 9.9, the first one would be very precise than the second but less accurate. Ultimately the second measurement is just more useful for practical purposes. Same happens with planning and estimates. An estimate of 18.55 man days for a piece of work is only as good as it is close the real value. If the work happens to take 21 days, then just saying three weeks is more accurate (but less precise). So let's say you make a year-long plan: it's more important that the plan is accurate than it is precise because that will mean that wh...

Via The Register : He cited a use case at US healthcare company Vizient where the CTO asked employees what tasks bother them on a regular basis – the sort of thing everyone dreads having to do when they arrive at work on Monday morning. Armed with feedback from thousands of employees, the company automated the most-complained-about chores. The result? “Instant adoption, zero change management problems,” Brethenoux said. Employees then bought in to AI and started to make good suggestions for further AI-enabled automation.

Inspired by Matthew Skelton's comment on Wholehearted I decided to read the book . This is not a review of the book, merely a note of the most important (to me, at least) take-aways. Being "whole" Why is it called wholehearted? The answer is given in the introduction and this helped me file the book in the right "box": a thing is whole according to how free it is of inner contradictions. When it is at war with itself, [...] it is unwhole. Mike Burrows then gives examples of situations in which we experience that "magical chemistry" that makes performing (in a group of people) effortless. This is (at least to me) a powerful revelation and a great way to define what I get to experience from time to time when my organization just performs. When that happens we are whole. And it's an awesome experience. The other insight that I got is that a business is always "at war": with the market. But when it also goes to war against itself because of...

Besides the two breathtaking episodes on TSMC and Dr. Morris Chang , I am just 10 minutes into  The Art of Selling Enterprise Software (with ServiceNow CEO Bill McDermott) and then this quote blows my mind so much I had to pause listening to write it down: I always tell people in sales, and I said it then, performance is the price of freedom. I never wanted to sit in internal meetings and have a boss tell me what to do or how to do it. What I would just tell them is, I’ll be number one in the country or number one in the world. Just let me run. I'll just add that this should not be the case for Sales only. (I think I've found another favorite  podcast  😅 , and I got the t-shirt )

A bug opened since May 2021, just a bit over 4 years ago, has finally been fixed:  https://github.com/openzfs/zfs/issues/12014#issuecomment-2889132540 The fix itself is trivial, even though I am sure that finding the cause surely was not. But what really caught my attention was the CodeQL integration test  that was written to prevent this issue from happening again. I find CodeQL and similar tools (such as Opengrep/Semgrep) can be incredibly powerful in integration pipelines to prevent subtle, difficult to reproduce issues from happening again probably saving a lot of time in debugging and to write expensive integration tests. I'd be curious to understand if CodeQL fares better in this context than Opengrep because it is aware of the code flow, as opposed to "just" matching patterns (I think Opengrep understands the code structure, to some extent but I'm not 100% sure). I do find CodeQL intimidating and more complex than Opengrep though: with the latter I was able to ...

Funny enough, some of the most valuable advice (or practice) is counterintuitive. For example, Toyota's andon slows down the whole line momentarily to go faster in the long run. Limiting WIP ensures that work gets delivered on time and with less effort. One such piece of advice I came across in a Knowledge Project episode I cannot recall right now was: the most selfish thing you could do is to be selfless I intentionally changed selfless to not be selfish because I think it dials up the contrast, and better fits the example I'm going to narrate below. Also, as a non-native English speaker, I am ok with the slight difference there might be between the two terms. Most of the examples around being selfless involve helping others, giving away money, etc. Those make a lot of sense of course but are also relatively difficult to practice often enough (except maybe helping others, which can be tricky as it might trigger the hero/saviour complex) and while I was discussing this with my...