Week 7, 2025 - Goose Chase

Yesterday, I visited the new exhibition at the Light Art Museum in Budapest with my daughter Chloé, where the above installation is on display too. Years ago, when I first heard that they were turning a struggling market hall into an exhibition center, I was frustrated. Our office used to be close to this place, and sometimes we grabbed lunch there. It seemed to me that the place had everything to succeed as a food court with better marketing, more restaurants, and a slightly different interior. They tried to do something like that, but then Covid came and destroyed everything. I haven’t been to the place since, thinking that the LAM is just another selfie-optimized tourist trap, like many in the city. Well, I was wrong! There were many serious, thought-inspiring, or just beautiful pieces, we almost spent two hours there. The one I enjoyed most was Onirica (), an immersive dream-simulation room, involving the best use of AI video I’ve ever seen. Definitely worth a visit, especially if you can go on a weekday morning and avoid the crowds.

📋 What I learned this week

My Substack newsletter is slowly growing. I managed to keep the weekly cadence and am still motivated to continue publishing Engineering Management challenges. Earlier this week, I built a backlog of two dozen or so high-level situations that I can use in the future, so I should have plenty of material to continue. The best feedback I got was from one of the readers of this blog: he’s organizing a small club at his company to discuss the challenges with fellow EM peers. I’m humbled and encouraged to continue. Subscribe if you want to follow - this week, you can think about preparations for a skip-level meeting with the manager of your boss, my approach coming next Thursday.

🎯 What I want to try next week

There are two big topics that I keep on pushing back since the beginning of the year.

First, I started again using the Pomodoro Technique. Since then, I settled with the Session App as my main timeboxing tool. There are a lot of details I love in this app, and thinking through them is best done in an article.

Second, I’m putting the finishing touches on my personal AI-augmented habit tracker, there are a few small changes left to do before I can call it (first version) done.

These are pet projects that I work on when I don’t have more important things to do, but keeping things forever in progress kills my focus, so I hope to close one with a writeup next week.

🤔 Articles that made me think

The Death of the Junior Developer / The Rise of the Junior Developer

AI's impact on the earlier steps of the engineering career ladder. Both articles have good points: a lot of the tasks that juniors were asked to do can be done in the same or better quality by LLMs, in a fraction of the time and at practically zero cost. On the other hand, using an AI to show you how to do something (and not doing it for you) is a supercharged tutor who's always available – again, practically for free. With focus and determination, learning is much easier and faster today than it was before LLMs.

There was one aspect I found missing from these posts: team dynamics. Healthy engineering teams have a good seniority diversity, not just because juniors can do the trivial stuff, but because a team is a living, interacting, collaborating organism. A mentor is growing by helping a junior too, and sometimes juniors can provide the spark to solve a problem. (Not even talking about the fact that today’s juniors are tomorrow’s seniors.)

The Sense and Nonsense of Pull Requests

Food for thought from Sander Hoogendoorn about the way Pull Requests / Merge Requests can hold back an engineering team from reaching their full potential. He ties everything around trust and shows how when all the circumstances are already there to create and maintain it (not just trust in people but trust in systems and processes too), the PR practice is an unnecessary, distraction-causing obstacle. To illustrate his point with the popular meme:

I usually approach the downsides of the PR practice from the other way around: prioritizing review speed above all, and avoiding starting something else while waiting for a review. I think you need a unique combination of circumstances (team size, code health, product domain, etc) to pull off abandoning PRs… but regardless of processes, I wholeheartedly agree with optimizing for ease of recovery and not for fewer bugs.

🪿 Something cool: codename goose

I played for an hour this week with this open-source, locally running orchestrator / agent. I was curious how close we really are to non-developers creating applications.

Based on these 60 minutes: very.

I tried to act like a novice user: my “specification” for the Game of Life simulation project was vague and rambling, and I didn’t help in debugging at all (didn’t even look at the code), just repeated that things were not working. For example, since Goose can access my screens too, during a font size problem where captions extended their buttons’ area, I just told it to check what the current version looks like, find what’s wrong with it, and fix it.

I uploaded the resulting game and all my prompts here. (Bonus: the readme file was generated entirely by Cursor based on the Python code, another cool LLM use.)

I’m pretty sure this approach of development falls apart with more complex problems, and I haven’t touched important questions like maintainability, security, energy consumption, etc. But this is just an early iteration of an idea, and for that, it blew my mind.

That’s it for today, watch something inspiring this weekend,

Péter