unicolet.org

This week on the  https://refactoring.fm/ community a member asked the difference between a good Engineering manager and an exceptional Engineering manager. In the conversations that followed someone suggested that " a good manager leads the team, a great manager creates a team of leaders ". That immediately reminded me of how in Turn the ship around , the author Captain L. David Marquet argues that leaders’ performance should be measured by how their reports perform after the leader has left. A few days later I was listening to the Knowledge Project podcast (I usually listen to most episodes two or three times to make sure I can get all the knowledge), and I made the connection of the above to tech debt. Someone who is a good leader but is required/essential for the performance of his reports is the transposition of code tech debt in the organization hierarchy. The organization trades going further in the long term for going fast in the now. Touch points between the two...

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

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

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

We've been told all our life to NEVER procrastinate. I think that's wrong. Sometimes, procrastinating is exactly what we should be doing. A few thoughts below. Unless it's something very very very very small, take as much time as you need to: think about the issue, and its importance understand the problem weigh PROs and CONs tinker with the code or the problem, throwing the solution away at the end evaluate impact outside our project: is it going to make things better for us, but worse for somebody else (i.e. optimize globally) find out how others have solved the same problem: it's very likely we're not quite the only ones working on this problem. How have others solved it? avoit NIH (not invented here) As a developer, you can do all of the above when you open the github (if you use github) issue: spend as much time as needed to clearly explain what is going on, and try to answer as many as possible of the questions above. Only after you are ready, start (and finis...

On the heartbeat podcast, host Claire Lew has a question that she uses to ask to each guest: what is one thing or several things that you wish you would’ve learned earlier as a leader? While listening to the podcast I've often wondered how I would answer that question, and I've had a few back and forth , until I settled on the classic the higher you rise the less power you have. You have more influence, but less power . This seems intuitively true to to me, and it does reflect in the experiences I've made in my personal journey, from individual contributor, to team lead, to lead of leads. However, I always had this sense of guilt about it, because it states a true condition but not how to operate within this condition. Sure, one way to address it is to write,write, write or repeat the messages, but those seem means, rather than an end. Instead I was looking for an end, to justify those means and to use them coherently. The answer came to me, rather unexpected, as these thin...

Fewer things have affected my leadership style in a direct, practical, quick-turnaround way than the Toyota Kata "show me". The picture below (link from O'Reilly Toyota Kata excerpt, found via Google) summarizes it, albeit in a short, easy to overlook form: From: https://www.oreilly.com/library/view/toyota-kata-managing/9780071639859/xhtml/spart4.html. For those with the physical book it's at page 225.   "Show me" is the mantra-ish question I ask whenever someone comes up with a proposal to do something, without clearly stating, or being able to explain, what is the root cause of the problem they are trying to solve. I am sure we all have experienced this, for example: a user asks that we add a feature so that they can edit a certain record, which is intentionally not editable. They might ask this because they often make a mistake in another part of the app, i.e. because of bad UI/UX. In this case we want (and have!) to fix UI/UX rather than adding another...

I find that most people employed in ICT know what a negotiation is, yet they inevitably fail to see one, even when it's placed right in front of them. I don't know the reasons (maybe our compulsively rational, binary mindset?) and I don't plan to study them. I will however claim,  rather ambitiously, that if we realize that everything is a negotiation, and deal with it accordingly, we can greatly improve the way we work together, and also be more effective. Some examples: a colleague reaches out to me and suggests we buy support for the Open Source monitoring product we use, because it's critical to our infrastructure. I say no, briefly arguing my reasons. We reach out to another team and suggest a change, they decline it. Are these negotiations? yes! and no! Yes, well of course they are: as the title says everything is a negotiation. At the same time, the conversation stops short of  the discussion with the intent to find a compromise , so it's only just a potenti...

Each week, in our weekly team meeting, we set out to explore complex/interesting topics. Recently we touched on learning to learn, and imposter syndrome came up, while discussing what can and what can't enable a "being good at learning" disposition. I'll admit that so far my reflections on imposter syndrome stopped at the personal belief that, if one can harness it, it can be turned into a positive force, a force that will encourage us to double-check our work, reduce bias, foster capacity to incorporate feedback, and thus lead to better, more sound results overall. In the weekly meeting multiple, different point of views were offered, and while considering this diversity it dawned to me how much of my own point of view is born out of my generally positive experience of working in ICT. I started out in 1996 when, at university, I was first exposed to computers, Linux, and the internet. I was lucky because the internet was just starting out, and so was I. Things were n...