agge

If you create a graph of what changes are needed to allow for other changes, eventually leading to your goal.

Then by definition you have the smallest safest step you can take. It would be the leaf nodes on your graph?

So we make it many small commitable refactorings instead :)

There is a great interview that talks about the process and what it is about more generally: https://youtu.be/HbjWOvxJjms?si=5ta-JOyfFLub2yX_

I think there are similar methods, such as nested todo-lists. But DAGs are exceptionally good for this use case of visualising work (Mikado graphs are DAGs).

Using a Mikado style graph for planning any large work in general has been really useful to me. Used it a lot at both Telia back in 2019 and Mentimeter at 2022.

It gives a great way to visualise the work needed to achieve a goal, without ever mentioning time.

Stealth marketing by someone completely unrelated to the book, 11 years after the book is released. Seems unlikely.

I’ve been in three teams that has done Mob Programming full-time. In one team it was for two years and a half years.

I have lots of side projects when I get home. Love sitting by myself coding, listening to music, running a video on my second monitor. I work on some hard problems, and get a lot of stuff done.

But I have never been at a workplace where the problem was that we needed someone to grind out as much code as possible.

Doing mob programming essentially means the team works on one thing at a time. It shortens the lead time for that one thing as much as possible. That allows you to gather feedback on the solution as fast as possible. Iterate as fast as possible. Which is why you feel as you are getting so much done, even though you can go a day barely typing yourself.

And you can’t do this solo. It’s rare to find one person with all the skills necessary to change our system end-to-end efficiently, and have them never be sick or slip on a banana peel.

IME the perfect size team has been between 2-4 engineers. And the rest of the team filling in with skills depending on the domain: - data science - banking - design - marketing Etc.

It’s not always comfortable. I’m somewhat of an introvert, and I feel a group of 3 is a lot easier to work in than a pair.

But you get a lot of the right things done, and fast.

There so much to be said about this way of working, upsides and downsides. Hoping to hear a lot in this post from people with experience.

Laughed when I read ”We where 11 engineers that could be fed with 2 pizzas”. But you are in Sweden? You can feed maybe 3-4 engineers with 2 Swedish pizzas. Which is also coincidentally a very decent team size ime!

I work in my Vision Pro through most of the day. The avatars are passable for joining pair- and mob programming sessions. For more personal meetings I use the camera on my laptop. It’s so very useful to have a large screen in the right place that feels comfortable.

The weight doesn’t bother me at all the way I thought it would. Turns out the most uncomfortable part of using the Quest 3 to me was the heat! The Vision Pro stays consistently vented through hours of use.

I have removed all my screens and wires from the kitchen, replaced them with a plant. Can’t imagine going back.

If an AI could write your tests, doesn’t that suggest the test are just checking implementation details? Unless you describe your business rules in detail.. as a test for example! How could the AI then write those rules as tests.

Perhaps you could automate the boring parts I guess. But maybe that suggests we are working with a poor abstraction that doesn’t allow us to be as terse and precise as we want to be?

Hilarious. He created a homepage for his password: https://zeeslag.ichi.city/mypassword.html

This resonates with my thinking as well. Although something I’ve always been missing from people talking about agile in general, is more specifics on how collaboration can happen. Especially collaboration with ”the customer” (customer is a terrible term). I’ve learnt so much more from reading blogs by Teresa Torres than from any agilist about how to actually learn from what you deliver.

Sass is very much still useful today. Mixins, used sparsely, can be very powerful and avoid large doses of redundancy. Also variables with good names make the job a lot easier than communicating around hexvalues.