unicolet.org

Agency, skill, and mastery are topics on which I have so many thoughts, and I am still discovering myself. This writing summarizes my position as of roughly April 2024. Agency, as pictured below, is to take on things, doing hard things without waiting for conditions to be perfect or otherwise blaming others or your circumstances. Examples of low agency: I could develop so much faster if only the code was not so crappy!  We would be already finished if this or that team had done their job properly!  If only my boss (or company) understood me, I could really do great things for this Company or my team! High agency behavior:  I'll try to make changes to the code/add tests/etc as I work on parts of it so that I will, over time, be faster. Let's see if there are ways that I/we co

The XZ backdoor has been covered extensively in various writings, but I had to listen to this episode because it features Andres Freund, who discovered the backdoor: https://oxide.computer/podcasts/oxide-and-friends/1843393 And of course, Bryan Cantrill did not disappoint. His energy and passion, together with the unique views and understanding he has around topics that are otherwise trite and thought to be well understood , to me looks pretty much like how a reality distortion field would work. The big revelation for me is that we've all been featured in a movie. You know the classic movie plot in which one person finds something out, and then they go about telling everybody about it, and nobody believes them but they take it upon themselves to save the world? That's what happened, well except everybody took Andres seriously from the beginning this time. And the world was saved. Pheeewww. Well, it was saved this time.

Today , I came across ArchUnit  which lets you enforce architectural choices on any Java codebase. For example you might want to enforce that certain domain object methods are only accessed by the persistence layer classes, but not in, let's view-related classes, with the exception of tests. This can be helpful to avoid spaghetti code, with all classes depending on each other. Java packages can help in this regard, but they are a rather coarse filter. Additionally, a unit test adds an immediately clear and conspicuous layer of intention to the codebase by expressing certain design choices that might be otherwise overlooked, unless a careful code review catches them. It's pretty clear to me that Java, even with all its shortcomings and despite Oracle efforts to sabotage it , offers the best development environment in terms of tooling, IDEs, support, and libraries. Notice that in the video, the host Ted M. Young is wearing the Change Behavior beanie, the other beanie is Refactor

I recently picked up People and Performance by  Peter F. Drucker . If you're keen on understanding what is this manager job that everybody talks about (especially if you're new to management) this book will set you on the right path. I've thoroughly enjoyed reading it and I wanted to make a visual summary for my own use. I think it came out nice enough that it might be worth sharing it, so here it is:

Warning: this post is in a stream-of-consciousness form. Approach it accordingly. Figma recently posted a couple of articles ( one and two ) on the challenge they are facing to keep their database infrastructure up with the massive growth they are going through, and how they're solving it. The last article especially was re-shared in some of my circles, and my initial gut reaction to the articles can be summed up in the immortal words of Jeff Goldblum in Jurassic Park : “Your Scientists Were So Preoccupied With Whether Or Not They Could, They Didn’t Stop To Think If They Should” . After I (admittedly) quickly read the article a couple of times, I still did not "get it". IMHO is a red flag as critical infra stuff like that should be simple: simple to understand, simple to operate, simple to troubleshoot, simple to restore. Had I been in their position, what would I have done? I could have left the article at it, but I've made it an habit to never say something "n

Once again I am writing about a few things I learned from the Knowledge Project podcast. In this episode Sean Parrish (host) and Dr. Gio Valiante talk about getting out of the fear of failure . I found the discussion supremely valuable and decided to draw a small diagram to make sure I assimilated and retained the essential points. The diagram is below and is provided without further comments, as those are, well, in the podcast itself. Diagram from "The Knowledge Project Ep. #181"

I came across Bloom's taxonomy of higher order thinking while listening to another Knowledge Project podcast episode  Dr. Gio Valiante (Part 2): Failure and Success . I found the concept intriguing, with reference to learning organizations and learning in organizations. I made a little drawing to help me remember the hierarchy, and then did a bit of research on the topic based off the first Google search results for "Bloom’s taxonomy of higher-order thinking". First thing to note is that this is Bloom's taxonomy of the Cognitive domain. The wikipedia page lists two additional taxonomies in the Affective and Psychomotor domains. Other online resources about higher order thinking rename or reposition the last three levels, as shown in the bottom part of the drawing above. How can I use this newly discovered information? I guess really my question is: how can I use this newly discovered information? And right now I am thinking at two ways: how can I index the hiring

The XY problem is something I've been acutely aware and watching out forever. In software development. I usually refer to it as  describing the issue in terms of the solution instead of the problem. And as with all things, they're very easy to see in one context, and jump at us unexpected and undetected in others. This is how I felt when I came across what is essentially a ROI question for a platform team (in the Team Topologies declination) and in the thread somebody simply unpacked it for me and everybody else: you have a XY problem: X: are we spending too much on product + engineering? Y: we need to determine the appropriate level of investment or budgeting And there it is, a problem I can work with, instead of responding to the trap. The conversation happened in the Rands Leadership Slack , which I wholeheartedly recommend you join regardless of your role.

Youtube rarely makes great recommendations anymore, but this time it did. Yday found this recording of a CppCon presentation from 2016  ( slides ) in my feed and made some time to watch it. It's pretty long, due to an extended Q&A section at the end which I mostly skipped, but well worth watching. The presentation itself is great and masterfully explores the reasons why we're still using C instead of C++ (especially if C++ is such a better alternative?) from a psychological/sociological point of view. The presenter quickly shows that technical arguments are just not effective, and also explains why. I've greatly enjoyed it because it aligns with some of my leadership beliefs, and also because I don't understand (or I guess I don't have the same frame of reference) people who pick C as their preferred programming language. I've done a bit of C programming while I served in Mapserver PSC maintaining the Swig/Java bindings and to sum my experience up: what

 From:  https://simonwillison.net/2024/Feb/10/almost-every-infrastructure-decision-i-endorse-or-regret/ ( Simon Willins blog is highly recommended) Ever wondered what other companies have tried, what worked and especially what did not? This post has you covered, well, for one startup at least. Content like this takes away a lot of the guesswork, cuts through the marketing lipstick and the presentation-driven-development material you often find at conferences. Appsmith, renovatebot, and homebrew caught my attention. Homebrew especially as I was not aware it could be used on Linux as well, and I could see how it might help us with developer productivity. At Proemion we stated rolling out a customized version of the Thoughtworks Radar , aimed at providing general guidance on tools, platforms, languages and techniques across teams and departments. It's probably the closest thing we have to the above, and it's currently not public, but we might turn it into a public writeup in the

Context: perfecting the art of managing up, and in particular, reporting to the board of directors. Another great podcast episode from The Knowledge Project/Farnam Street in which they touch on various topics, but one caught my attention. At a certain point they talk about a period of underperformance and this sentence caught my attention: I understand what you are doing and why you’re doing it, and I understand what you are not doing and why you are not doing it. See you next month. And I was thinking at the current AI hype, but then again I think it applies to any hype in technology, as we seem to experience this on a pretty regular basis (AI, crypto, microservices, big data, cloud, nosql, SOA, etc). So I think in the future I'll borrow this practice and, in addition to covering what we do, I'll also cover what we are not doing and why . On the theme of AI a couple of data points that I think are relevant: looking at impact of AI on financial results . I mean, at the end,

Notes and thoughts on the book with one of the longest titles ever, so I'll refer to it as "HP Laserjet" from now on. BY the time I got to read it, I had been aware of this book for a while as it's not exactly new. It never really attracted my attention as it focuses on systems that I was never involved with. This changed recently (past two years) and after purchasing Industrial Devops I made the connection to this book again due to a mention in a promotional post for Industrial Devops. The TL;DR for this book is that it's worth a read: it reinforced some convictions I already had, and went a bit in more depth on others. In both the HP Laserjet book and Industrial Devops I felt the part about certifications was notably absent. Since that's usually an expensive, delicate part of physical products design, I am perplexed at the fact that it's not covered in more depth. Another remark is that some aspects that are strongly highlighted in this itrevolution n

This xmas I was looking for a game for my kids. While the various app store have a lot of them I find that they all require in-app purchasing, which is difficult to handle when kids are involved. Since I liked to play Mario Kart on the Nintendo 64, I decided to look if there was a newer version for iPad. There is a remake from Nintendo (besides a zillion clones with what I presume is a doubtful reputation) so I installed that. The experience was, to use an euphemism, lackluster. After the installation I was taken to first "training" game in which I already realized I did not like the control logic. You have to use the finger to steer, instead of tilting the tablet, which I felt would have been the best experience. I still decided to push through and try it with the kids the next day. After I announced that there was a new game, they gathered round, and I proceeded to open the app. There was an update to download, to which I said yes. And then I had to wait 15 minutes. Not sur

I don't remember exactly how I came across this podcast, but it should have been through somebody in my mastodon circle:  https://500songs.com/ Anyways, I've now listened to two episodes (spread over a few sessions) and I'm blown away by the sheer amount of detail that you get to discover about the covered artist or song. And that explains why each episode is rather long, I think the two I listened to are over 2h each . Music has always been an important part of my life and knowing trivia or facts about a certain artist, album or song has always been meaningful to me, in order to better appreciate the music and augment the listening experience. If you feel the same you won't regret diving into this podcast. The two episodes I listened to so far are: https://500songs.com/podcast/episode-163-sittin-on-the-dock-of-the-bay-by-otis-redding/ I chose this one as incidentally I was listening to Otis Blue at the same time. I was amazed that the whole album was recorded in just 2