unicolet.org

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...

One notable thing I did in my first 25 years was in answer to an odd request I got from a customer of a customer (don't ask). This particular organization had lost control of their own authoritative DNS (public DNS) and needed a hand to recover the zone hosted there. Unfortunately this was the only DNS so taking it down to mount the disk would have resulted in unacceptable downtime and there was also the risk that the disk had been encrypted (they were not sure). So many things were unknown about this server that even a reboot was considered risky. So, what we ended up doing instead was mirroring the network traffic on the switch to a new server, run tcpdump on all DNS traffic for a couple of weeks, and then through a series of specially crafted tshark + awk commands we rebuilt the entire zone file (which was not very large, thankfully). We reviewed the zone file with the customer, loaded into a new server and then swapped it in while keeping the old system running. I never heard f...

From time time there's an episode of Oxide and Friends that has content interesting enough that I feel like putting up with the hosts chattiness. To be clear: I love it, but time is a scarce resource so sometimes I stop after 10 minutes talking about Silicon Valley. Anyhow I listened to this episode and loved this quote so much, it makes me want to apply at Oxide!

After some postponing due to a busy April, I've eventually made time to listen to another Refactoring podcast episode: How to Coach CTOs . Here are my customarily short notes on the most important takeaways. I added this episode to the compilation of my favorite podcast episodes . Focus on your strengths This is brilliant advice, which is often overlooked, even though it surfaces in lots of places (Drucker, Munger, Rumelt, Covery). I'd pair it with Munger's advice to, erm, minimize your errors (he calls it avoiding stupidity ), which I interpret as a more active version of focusing on strengths. Understanding the fear(s) of your peers This is not covered in the episode, but I thought it would make a great complement to understanding their goals and their objectives. I wrote about fear last year and it's been very valuable for me to unpack executives requests and ideas. Relationship with peers Can't believe this advice is actually free: Many early-career CTOs strug...