Skip to main content

Posts

Leadership tech debt

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
Recent posts

Agency, skill and mastery

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

XZ Backdoor: we all were in a movie

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.

ArchUnit: enforce architecture in Java codebases

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

Drucker: the manager

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:

Brain dump on the recent Figma database infrastructure articles

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

How do we get out of the fear of failure?

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"