unicolet.org

Integrity : (from integer) to be whole or complete. In Jim Dethmer's meaning the word drops its ethical connotations and assumes the meaning of energetic wholeness and being fully alive . radical responsibility : we move from blaming others and external circumstances to taking full responsibility for our actions and emotions feel your feelings : sweeping emotions under the rug is a sure way of not being whole with ourselves and will eventually move us from being in control to being controlled by the amazing amount of energy that it takes us to suppress those emotions candor : when we hold back we detach, and when we detach can't feel energetic wholeness be impeccable in your agreements : in Charlie Munger's words be dependable. When you cannot keep your agreements, say so as early as you can Sources: https://fs.blog/knowledge-project-podcast/jim-dethmer-2/ https://conscious.is/concepts/the-four-pillars-of-integrity   Addendum: on Rituals A ritual is an invitation to somet...

We are essentially taking expertise and making it a commodity, and I think that as generally democratizing, I think many of the things I mentioned, if you have wealth, you have a lot of access to, and if you don't, you don't . What a cool thing that we've made this like universally accessible. From: https://www.acquired.fm/episodes/how-is-ai-different-than-other-technology-waves-with-bret-taylor-and-clay-bavor  (slightly edited)

A while back I listened to this conversation between Martin Fowler and Luca Rossi on the refactoring podcast. Since then I made a note to write down the most important things I learned (or re-discovered), but always postponed until today I was able to make some time for it. Here's my take on the two most important things in that one hour long conversation. Dosage The concept of dosage is very familiar and very important to me. I've already written about it, under the name quantity . I appreciate how Martin Fowler was able to find a better (and fancier) name for it. Context Software engineering, being as elusive as it is as a proper engineering discipline, is perhaps one of the most studied and written about fields of engineering . And yet, we struggle to come up with truly universal practices that work everywhere. One way to understand why some things work sometimes and don't work or fail miserably other times is by considering the context that was present when the solu...

My uncle taught me this thing when I was a teenager about how he used to price his business. He ran a plumbing company. What he did was basically the first 75% of hours were priced at 100%, so the regular rate, but at 75 to 80% [of hours], he would increase the rate; at 80 to 100% [of hours], he’d increase it, and at over 100% of a normal work week, he’d increase the rate even more . And he was super transparent with people about this, like, “I’m really busy right now. I hate to give you this quote, but to do the job properly, here’s what we’d have to price it at.” From  Ryan Holiday: How to Win the War with Yourself [The Knowledge Project Ep. #208]  

What we call perception is other people's reality Have you ever heard somebody say: yes, but we are perceived as <adjective>? as a way to say we're not quite like that, it's their fault for not seeing us differently, etc. In other words we're not taking responsibility. Stop right there and remember that how we are perceived is other people's reality. And it's our responsibility to change it , should we not be ok with it. And it's our fault if we don't. As the saying goes: we have to deal with world as it is, not as we wish it it would be

A wise man said: Our ideas can be either ignored or misunderstood. And we don't get to choose. After a certain point it does not matter how much we refine our communication, it will never mean exactly what we think it does. And that's why it's more important to listen, than to talk: so that we can correct what must be corrected and ignore the rest because it will be distracting.

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

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

Continuing my series on the first 25 years in ICT ( previous post ). I've made some mistakes in my career, here are the two most important ones, in ascending order (most serious last), My second biggest mistake is, in hindsight, a trivial network masking error that ended costing a customer a large internet bill (when internet was still metered) and overflowed into an investigation. The investigation ended without consequences but was nonetheless worrisome. The setup was as follows: a flat internal network with a proxy to control outgoing internet traffic. The firewall had rules that only allowed certain hosts (servers, and the proxy itself) to access the internet without restrictions. Everybody else had to go through the proxy. My mistake was adding a rule for a new server, but instead of setting the source ip in the rule to ip/32 in CIDR notation I set it to ip/24, effectively allowing all network to bypass the proxy. This went undetected for a while, at least until the first unu...

Another illuminating quote from Matthew Skelton , posting about Mike Burrows book Wholehearted : Don't re-organize people; re-organize purpose This made immediately sense to me, as I often find that teams that struggle to perform are teams that don't have purpose or have lost it or are so removed from their outcomes that they mechanically complete the next thing. Also, this once again shows how crucial the role of the chain of command is for providing this purpose (the why), making a compelling case against micro-managers, or we-need-a-process-for-everything managers.

One of the things I like the most about Accelerate is how it puts the focus on Culture and how a (measurable) Culture affects information flow. In other words, you can have a great working place and be business-effective (the two are not mutually exclusive, in fact they compound each other). Also, Accelerate introduced Generative Culture to a wider audience. Recently, I read the  Poor Charlie's Almanac and one of the things that caught my attention was the inversion principle . In my words: Inversion says that, often, the best way to solve a problem is to ask ourselves how to cause the problem, and then stopping/avoiding doing that I've set a goal to apply the inversion principle more in my activities, and today I said: what if I applied it to Culture? Being the lazy person that I am I asked Claude the following question: you are a manager in a medium-sized organization. How can you actively disrupt the flow of information in order to reduce the organization's effectivene...

There's many things that motivate us, and like tools from a toolbox, we pick the one that we find to be the most appropriate for the occasion. Spite Driven Development can be a powerful motivator, as long as it's not the only one. SDD essentially works like this: someone slights us, and we resort to proving them wrong by (over)doing exactly the thing that they don't think we can do. This is all fine, in the short term. SDD comes with a few caveats: SDD can feed on resentment and feed resentment equally. Feeding our resentment uncontrollably is an excellent way to end up being miserable SDD leave us hollow when we've accomplished our mission, because it an external motivation . We won, now what? Maybe the other person moved on or does not care, or even worse they genuinely compliment us! if we don't succeed we might end up attaching our sense of worth or identity to the thing we are trying to accomplish. It's easy to see that this is not-a-good-thing™ Profession...

Since I could not find a quickstart to run opengrep with the full set of rules from their fork I thought I'd document what I found out. Setup Download the opengrep binary from github and make it executable with chmod +x . Clone the rules repo: git clone git@github.com:opengrep/opengrep-rules.git and clean it up to make it usable to opengrep: cd opengrep-rules rm -rf ".git",".github",".pre-commit-config.yaml", "elixir", "apex" find . -type f -not -iname "*.yaml" -delete rm -rf .github rm -rf .pre-commit-config.yaml Ensure opengrep can load the rules with: opengrep_manylinux_x86 validate . The same can be done for custom rules maintained in a separate repository. AFAIU Multiple repositories can be specified by repeating -f option as needed, see below. We are now ready to scan a repo, from the repo root directory run: opengrep_manylinux_x86 scan \   -f <path_to>/opengrep-rules \   --error \   --exclude-rule=VAL some ti...

Today April, 1st 2025 marks the 25 years anniversary (quarter of a century sounds more impressive, doesn't it?) working professionally in ICT. My first working day as an ICT professional was on April 1st 2000. I had just graduated from uni (literally the week before) and one of the profs offered me a position at this company. The daily commute over bus and train was about one hour and a half, but I got to work on something really fancy: writing a c-shell script to daily sync data over ftp from an Oracle 7 database running on AIX (looked a lot like this one ) to a Bull mainframe. Development occurrent from a Windows NT4 workstation over telnet (I think). c-shell was a b1tḉh to work with and vim wasn't available (only vi IIRC) so my productivity wasn't great but I got it done and it ran until one of the two system (AIX) was eventually decommissioned. The AIX system might still be in the basement at my $OLDJOB. After that I moved on to more interesting e...

Came across this interesting article  by Nicole Tietz-Sokolskaya on sw ownership vs stewardship (think of Github codeowners feature) and I love how it explains why stewardship is a much better term to use in this context: Owners are concerned with the value of what they own. Stewards are concerned with how well it can serve the group. And this makes all the difference in producing better outcomes.

TL;DR: impressive 🤯 I wanted to play with D3 to create a visualization, so I picked an example ( Bubble chart) and then started hacking at it (literally) in VS Code. Before long, I realized I had just downloaded Cursor , but not had an occasion to try it out. I thought this might be as good as any. Opened the project folder and its one HTML file, then stated prompting away. It got all the modifications right: add axis labels add labels to the bubbles change the tooltip to show all the data of the particular record; one of the attributes is confidence and goes from 0 to 1: Cursor guessed it is a percent and formatted it as such!  added a line showing the break-even point Cursor edited the file for me, and I just had to accept the change, save, reload in the browser. Made some tweaks myself where it was simple enough. Much better than copying and pasting in the chat. Where it blew my mind was when I resized the chart and added a section below which I titled "Explanation:" ....

I recently added Acquired to my go-to podcast short list and picked the Enron story from 2022. The story comes out hot on the heels of the FTX scandal/tragedy/fraud because of their similarities (and why the regulation that came after it helped prevent other Enrons). It's a long episode (1h 50m) but it's narrated so well and the story is so riveting that I didn't even notice. Theres this passage that I found interesting about half-measures and how they can and will be gamed (emphasis mine):

Many moons ago I was an enthusiastic user of OpenDNS  (when it still was a standalone company), then between one move and the other I forgot to enable it again and found Google/Cloudflare to be equally capable and fast. However I always missed the protection capabilities of OpenDNS, and today I spent some time looking for alternatives. That's how I came across Quad9 : an open DNS recursive service for free security and high privacy. Importantly: Quad9 is operated by a Swiss public-benefit, not-for-profit foundation with the purpose of improving the privacy and cybersecurity of Internet users. Quad9 is headquartered in Zürich and is subject to Swiss privacy law (Swiss government extends that protection of the law to Quad9's users throughout the world, regardless of citizenship or country of residence). I enabled Quad9 on my home router and then proceeded to test it. But first I had to find a malicious url, which funnily enough is harder than I thought :D Quad9 does not support ...

In his book Clear Thinking , Shane Parrish explains how to avoid finding the perfect solution to the wrong problem have two meetings: one to define the problem and another to find the solution(s) At least to me, it seems immediately apparent how a well conducted post-mortem facilitates exactly that. In the first phase we gather the data, establish facts and timeline. Once that is written down (emphasis on written!) we can start exploring solutions to prevent, detect and/or mitigate. At the same time, what we're achieving is slowification  (i.e.: taking work outside of the normal flow and make time to analyze it), which is another critical step towards continuous improvement. It's a simple process, but not an easy one.

Came across this inspiring post by Psych Safety on Ikigai last week, and I immediately felt I had to save it here, if not for the sake of better interiorising it by writing about it. The post immediately resonated with me because it captures exactly how I felt, many moons ago, when I came across the Internet, around 1996. I felt that the internet, with its rebel, distributed architecture would have changed the world, and for the better. I wanted to be a part of it because I thought I would be good at it, I would enjoy it and I could earn an income at the same time. 25 years later I still find that it's the same combination of things that motivates me the most deeply and ultimately allows me to be effective: Am I good at this (or willing to improve)? Does this benefit others and have a positive impact on the world? Will this help me make a living (or am I consciously choosing to do it for free)? Does it feel good? Do I love it? If I had to point at something that I feel is missing ...

In the past years we've heard all kinds of statements on LLMs and sw development: from AI will replace developers to AI lowers code quality . I think it's a bit of both, and the reality most organizations will face is that they'll need BOTH humans and AI. The optimistically proclaimed cost-savings from replacing humans with AI will most likely not materialize in the long term. By following Simon Willison blog in the past two years, I came to the conclusion that the most effective humans are those that can bend and craft their own AI tools and are willing to go to the extreme extent of completely reworking their coding workflow to suit this new technology . For example, see Harper Reed's LLM workflow  or Simon's Willison own setup . Everybody else who's "just" relying on the IDE integration of chat will reap limited benefits, because this approach is tailored for the human and not the LLM. I would also argue that platform, integration and helpdesk/sup...

Most people quit before they reach their best work. Excellence lives in doing a bit more than others. From:  https://fs.blog/brain-food/february-16-2025/  

From:  https://www.abortretry.fail/p/work-at-the-mill On the 15th of December in 1995, DEC made the AltaVista search engine publicly accessible on the World Wide Web. The search engine ran on two machines named Scooter and Turbo Vista. Scooter had a 20GB hard disk and 1GB of RAM and it did the page fetching/crawling while Turbo Vista had 250GB hard disk and 2GB of RAM and handled the index and web serving. Naturally, these were both Alpha machines. The company took advantage of its head count to test the system with 10,000 employees trying it out prior to launch. While the minicomputer and workstation company might seem out of place on the Web, Digital had registered dec.com in 1985 and digital.com in 1993. Let us not forget, DEC’s wonderful hardware had even powered many of the earliest networks that comprised the early internet. AltaVista was success. The site had approximately 300,000 hits on its first day of public availability; by the end of the year, the count had grown to 19...

Dirt cheap and easy, just two things: give them the best IDE you can afford a large screen display (27" or above)

Via:  https://changelog.com/news/131 Bill Maher is new to me, and in a bit over 8 minutes he just became my favorite satirist. In a new segment called New Rule Bill Maher lamented the shitty status of technology driven forced improvement which I'm the first to admit, a lot of times, does not make our lives materially better. He makes the examples of streaming services which drive the user experience back to where we were 20 years ago (or worse), disappearing car handles and apps to do everything. As a European I can't really relate on the car valet experience, but I do find infuriating the growing number of restaurants forcing me to scan a QR code, register with my email, and then squint at my phone screen trying to decide what to order. Bring paper menus back 😠 It's a well worth watching 8 minutes. Especially if you work on the field. The lack of ethics in our field is really showing, and TBH I think we got away easily in this critique. It could have gotten much worse...

A note-to-self kind of post on a playbook to turning around a struggling sw engineering team. Core principles always behave trustworthily slow down and make time to address problems do you have the right people? if you can't get consensus, seek consent Foundational engineering best practices With regards to engineering best practices, the following are foundational and should be part of the execution somewhere between steps 4 and 8 of the playbook: trunk-based development continuous integration no separate tester or devops team (this can be relaxed after the team begins performing), seek out a stream-aligned team instead SCRUM with its process is useful to align the team and at last one main stakeholder automate as much as you can, especially the parts that come up often for discussion; one obvious but often overlooked example are customized coding styles (use the consent-over-consensus principle to reach a decision) If the team resists them or does not make progress, then see the...

Debating whether to go no-code but worried about unclear licensing, the dreadful we-need-to-rewrite-it dram down the road or django/rails/spring boot and its relatively higher upfront cost? There's a third way: quasi-code with Apache Camel . It still amazes me how few people know about the swiss-army knife of integrations.

I was reading this interesting analysis on Nvidia competition (as usual, his blog should be on your feed) from Simon Willison and this bit caught my attention (emphasis mine): Technologies like MLX, Triton and JAX are undermining the CUDA advantage by making it easier for ML developers to target multiple backends - plus LLMs themselves are getting capable enough to help port things to alternative architectures . I found it curious that the very same thing that's been fueling Nvidia's success could also help reduce/eliminate their moat.

When you have, when your engineers know what the right answer is, but they also feel that the right answer is culturally unobtainable, you have a cultural problem. Bryan Cantrill on Intel after Gelsinger @ 33:22

Another golden nugget from The Knowledge Project podcast in episode  Dr. Jim Loehr: Change The Stories You Tell Yourself [The Knowledge Project Ep. #193] : time only has value in its intersection with energy or how I have it memorized: time has no value without energy . And how I picture it: one hour on the couch has not the same value as one hour studying or exercising. And this becomes even more important when we consider our relationship with others. Dr. Jim Loehr continues (emphasis mine): Well, I will tell you, time has no value, has no valence, has no force. Until time intersects with energy, you really have nothing.” I mean, you’re just there. You can be present with your family, but because you’re there, is that going to move the needle toward being a loving, caring mother or father? And the fact is no; you’re going to have to invest energy aligned with the mission. Time doesn’t give you anything except the opportunity to make the investment of the one thing that moves the...

John Cutler has been posting some supremely interesting content on LinkedIn recently, and I felt I had to save it somewhere for finding it more easily later. This is one is about attributes of good and bad process: Good Process Encourages mindfulness. Flexible to local concerns. Adaptable, frequently challenged/improved. Mostly "pulled" because it is valuable. Core principles understood. Encourages conversations/collaboration. Co-created/designed with "users." Value to all participants. Increases confidence in outcomes. Distilled to core "job" (lightweight). Achieves desired consistency with minimal impact on resiliency. Improves global outcomes. Delivers value to end-customers. Guide/tool/navigate/remind. Enhances trust/safety. Bad Process Encourages mindlessness. Inflexible to local concerns. Set in stone. "Just because..." Mostly "pushed" onto participants. Automatic/forced adherence. Reduces quality/quantity of conversations. Desi...

One of the things I always tell to those who come to seeking advice on a process improvement is the following: prepare for the inevitable downturn: things will get better in the short term, but then something bad will happen and things will get much worse than they are now. This is ok, and totally expected. Be prepared for it, know that the only way forward is through and then things will really get better. Then I usually draw this curve in the air with my hands: Most people stop at the first downturn, and that why most process improvements fail. Enough failures and people stop believing in any improvement at all, creating a death spiral. Another way to look at this is to think about is described in Gary Gruver's book A Practical Approach to Large-Scale Agile Development : [...] after you have chosen an approach you don't need to worry about getting the advantages of that design because it will come naturally. Where you need to provide management focus is on addressing the dis...

Besides Entropy , the Buffett/Munger duo is another rabbit hole I find myself going down into often in these last days of the Xmas break. I liked this quote in particular: We can handle bad news, but we don't like them late

Technical Debt is Entropy In Software  (via lobste.rs ) made me run dow a rabbit hole of Entropy/Second Law of Thermodynamics. Youtube is full of videos on the topic. This  by Sabine Hossenfelder is one is the most clear and practical explanations I found so far. Another one is this interview with Stephen Wolfram .