unicolet.org

After a 7 year break, I returned to  IDI - Incontro DevOps Italia  and it was a blast. Here are my first impressions: AI dominated conversations. It is clear that team or organization-level guidance is important and software development and operational best practices like small PRs, and low MTTR are crucial. Sprints could/should be made shorter (1w or less). Question is: how to keep a healthy ceremony-to-work ratio with shorter sprints? Spec-driven development helps capture the details of the work being done, which is also useful for later rework/inspection but might also be important for compliance reasons 🤔 Finally someone using Backstage (to build self-service ops). List of sessions I attended: Leveraging the edge for observability GitOps, Observability e AI: come chiudere il ciclo dell’AIOps Don’t fear the bot: mastering AI tools before they master you (most fun and engaging) Scaling DevOps Without Scaling Ops: Our Platform Engineering Journey sshlogin: securely authentic...

I wish, one day, to have the dedication to pursue designs like the former Apple Sleep Indicator Light: the animation was designed to mimic human breathing at 12 breaths per minute  Just amazing. Via:  https://unsung.aresluna.org/just-a-little-detail-that-wouldnt-sell-anything/

I've been following Martin Stellar for some time and I find his material has made me a much better Product person. His writing is simple, clear and engaging, especially his free academy material . I thoroughly recommend you follow Martin Stellar on LinkedIn and read his materials.

I recently came across " Things I’ve learned in my 10 years as an engineering manager " by Jampa Uchoa and I loved it so much I wish I wrote it. Here are my favorite parts:  Everyone needs to care about the product : the most evident symptom of this is not happening is when we decide to hire QA or UX because we think they have the knowledge to fix the problem. Instead, the problem stays the same, and the flow of work breaks down. 60% of your job is being the cheerleader: the author mentions being the cheerleader for the team, and I would argue that we should also be the cheerleaders for the product. Your goal is for your team to thrive without you : I don't recall who said that leaders should be evaluated on their team's performance after they've left. It was probably former Navy captain David Marquet in "Turn the ship around! "

Via https://www.anildash.com/2025/09/09/how-tim-cook-sold-out-steve-jobs/ There's no point in having fuck-you money in the bank if you never say "fuck you"!

I'm kind of surprised Slack hasn't yet put out an AI feature. The potential is immense, imagine how many times the same question is asked and answered in a workspace... 

This year my xmas gift is the MP3 version of a seminal album of the '90s which is impossible to find on streaming services: Kruder & Dorfmeister's The K&D Sessions TM It does sound great!

Mostly out of curiosity and desire to learn I've tried to run open models locally on both LM studio and ollama, but I quickly realized the limitations intrinsic to my hardware (just a high-spec'd laptop). Curious to try AWS Bedrock I eventually settled on the following setup: litellm exposing Bedrock models (Qwen, atm) locally on an OpenAPI-compatible API (yes it's a mouthful). This works great for any tool that can be configured to use an OpenAPI-compatible API like Quill meetings . Getting VS code to work with this setup was more challenging as it required VS Code Insiders (the bleeding edge, AFAIU) and even in that case VS Code tends to forget settings or use them inconsistently. For example it always uses copilot for the inline code actions. llm  required some tweaking too, in particular the setting suggested in this comment . I am very impressed with litellm which provides accurate usage tracking per team or account. The potential for offering llm access on an interna...

 Perspective is worth 80 IQ points Alan Kay’s line “Perspective is worth 80 IQ points” isn’t about literal intelligence. He’s pointing out that the ability to shift viewpoint, reframe a problem, or see a system from a higher level often produces more insight than raw analytical horsepower. Many problems look hard only because they’re being viewed from a narrow frame. Change the frame, and what looked complex becomes obvious or solvable. Why Perspective Feels Like “+80 IQ” A few mechanisms: Reframing reduces complexity. Seeing the structure of a problem—rather than its surface detail—often collapses the difficulty. It mimics what we associate with “smartness.” Most people get stuck in the default frame. They try to optimize inside an assumption instead of questioning it. Someone who steps outside can leapfrog them without being “smarter.” Systems thinking detects leverage points. Understanding how components interact exposes shortcuts, invariants, and constraints th...

My notes on:  https://jenson.org/games/ which I found via:  https://youtu.be/1fZTOjd_bOQ?si=kCGSE2uNczIJjiQ- Alan Kay quote is hard to understand until an insight from a user test “changed my perspective”. First learning (on the surface, we go deeper and beyond it) pretty soon: Games have the ability to force situations, such as running into a canyon and having nowhere to go but up a ladder. Apps on the other hand, usually have the opposite, offering a broad toolkit of choices. Games, I thought, can exploit narrative to force situations which made their life easier. However this does not mean that games have it easy, on the contrary most games fail: You have to design a great game to get people to have the confidence that practicing is worthwhile. And we start going deeper right away now: Raph convinced me to forgo any quick and easy ‘cookbook of tricks’ approach to this problem and go deeper and understand better how games are built, from the bottom up First bit of wisdom: M...

You can't say you understand today's AI landscape without listening to this massive (4 hours!) Acquired episode on Google, focusing on its AI roots . Over three episodes, Acquired has a little over 12 hours worth of podcast just on Google! Well worth it IMO for  the greatest business in history . Selected highlights: [07:23]   basically every single person of note in AI worked at Google with the one exception of Yann Le Cun who worked at Facebook This is truly mind-bending to think about, especially considering that Google is (at the moment) not the first name that comes to mind when we think about AI (LLMs) today. But the real kicker comes a few minutes in when we learn that did you mean? (launched in 2001!!) and google translate  (2006) are the first practical application of language models to its search business which made it exponentially more effective. About 25 years ago, Google was already running machine learning in production, at fantastic scale (about 15...

Once again , some supremely well-thought and useful content from Oxide:  https://rfd.shared.oxide.computer/rfd/0576 This time it is about the use of LLMs within Oxide , here are my main take aways: start from values ! A phenomenal example of how values can be so much more than the vanity checklist that most companies use them for focus on the receiving end : why should I spend time reading something that the author did not think was worth enough spending the necessary time to write it? Again, goes back to their strongly writing-oriented culture and values corollary of item number 2: self review AI-generated code before asking others to review it!

After the recent npm attacks  there have been many recommendations to leverage dependency cooldown as an additional mitigating factor. Dependency cooldown works by instructing the package manager to ignore releases that are younger than a certain threshold. The reasoning is that a vulnerable package will eventually be detected (and removed) in less time than the threshold, therefore preventing the attack. This, combined with dependency pinning (including transitive dependencies!), is a very powerful tool, but introduces an issue for anyone using internal dependencies. For those the cooldown will have the undesired side-effect of blocking internal dependency updates which might contain urgent fixes. I haven't checked all package managers, but I did check some of the most popular languages. Also, cooldown is not supported everywhere and sometimes is supported with noteworthy exceptions. Nodejs Use or switch to pnpm and use a combination of minimumR...

Thoughtworks just published volume 33 of their Technology Radar . I found some interesting gems in it that I thought were worthwhile re-sharing: LiteLLM : I've been playing around with it to share AWS Bedrock models over a local, OpenAI-compatible API and I am impressed with the breadth of features (for example budgeting). The AI ecosystem is vibrant and flourishing. Continuous Compliance : so happy to see this mentioned! Personally I would expand the term to include other compliance tools like Vanta and I am convinced that this kind of automation and software will be essential for organizations to scale while meeting increasing regulatory demands. AGENTS.md : as someone who reads Simon's Willison blog, this is no surprise and a welcome confirmation (another file to watch out for:  CLAUDE.md ). Oxide : I wrote this post almost exclusively to mention Oxide 😅, a company I admire. Whenever people ask me about my cloud exit strategy, my answer is: Oxide. Here's why .

Excellent insight on conterfactuals in the context of (some of) the analysis of that latest AWS outage (emphasis mine): Counterfactuals are seductive. They tidy up messy stories . “If only we’d done X.” “If only they’d noticed Y.” They sound analytical, but they’re fictional . As the saying goes, “If my grandmother had wheels, she’d be a bicycle.” Once we start changing the facts, we’re not talking about reality anymore: we’re imagining a different one that didn’t happen. It’s easy to laugh at Joey, but we all do it. Just look at all the hot takes on the large AWS outage this week. We look back at a failed project, a near miss, an incident or accident, and feel the seductive pull of “they should have..” or “they shouldn’t have…” because we crave causality and coherence. When something goes wrong, we want to believe that there was a single point of failure that we can fix for next time, reassuring ourselves that it won’t happen again. But as Dekker reminds us,  “…[counterfactuals] ...

The advice I like to give anybody who’ll listen to me, is not to wait around for inspiration. Inspiration is for amateurs; the rest of us just show up and get to work . Chuck Close -  via Farnam Street  - emphasis mine I saw Mark at MOMA a while back and was blown away by the superhuman attention to detail

I feel that terms like full stack developer and generalist ran out of steam and don't capture the attention they should IMO, enter versatile . I came across it while listening to  Scaling Manufacturing  and, surely enough, when I went to check Oxide Principles , Versatility is listed under Values:  Versatility: while we must naturally specialize, our bold mission also demands that any of us may need to apply ourselves in a new domain – and indeed, that many of us will be doing this much of the time.

Businesses cannot remove developers without losing the understanding needed to build and maintain software. Tools like outsourcing, no-code, or AI can speed work but cannot replace comprehension. Design platforms and practices that amplify developers' context and collaboration instead of trying to eliminate them. Source -  via LinkedIn Reminds me of  Enough AI copilots! We need AI HUDs

There's not a lot of content out there talking about physical product manufacturing, so when I saw the episode on Scaling Manufacturing on my podcast queue I jumped right into it. Here are my highlights: Testing - while manufacturing - as early as possible If you've been aware of DevOps and Continuous Integration this will sound rather obvious, but it's always interesting to see these principles working in areas outside of software development. Medusa : Oxide's front plane loopback board which helps identify issues with high performance cabling as early as possible Reverso : a "mock" compute sled which allows Oxide to test the cable back plane without needing a compute sled Single sourcing components as a relationship investment Apple is - famously - another company that does single-sourcing (can't find the quote ATM). Here's how Oxide explains it : it's been really great working with our suppliers and they really are Oxide fans. Um, which is nic...

Wiring the Winnning Organization has the best illustration of why Agile works: (hope it's fine to manually copy it - not a scan or picture)