unicolet.org

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,