From neugierig.org

For example, imagine two applications A and B that are identical except in one way: application A has an additional test suite that collects a set of slow, flaky tests, which require painful manual updates.

Now suppose someone showed up to B with a patch making it like A: “Hey, this patch adds a bunch of tests. Note: they take a very long time to run, when they fail it doesn’t necessarily mean something is wrong, and when you change things in the app you will have to do a lot of tedious work to update them. Oh and also, though I’m giving you the code now, you’re on the hook forever for keeping it going into the future.” Would you accept the patch? I wouldn’t. And if that is so, you could reasonably argue you should also just delete the tests in application A.

This is an amazing way to look at existing code you need to revisit. The cost of maintenance is higher than the sunk cost of writing the code in the first place.

I’ve always wondered how the hatch and docking mechanism made way to the astronauts between modules. Here is an awesome video explaining the docking sequence/mechanism and how the crew managed passage

This article hits home on the mentorship issue I’m facing at the moment, and on why I accepted an offer last week and will be leaving my current position in 3 weeks.

I miss having a mentor

It’s been 17 months since my manager left, with still no technical replacement in sight. I really miss the challenging, high-level debates.

Amazing sunset tonight #melbourne

I just resigned. It feels super strange. This is only my second full-time employer since I started my career 13 years ago.

They gave me the opportunity to migrate to Australia permanently. It’s not nothing.

New week. Happy Monday everyone

🎬 Currently watching: Tenet. Wish me luck!

Just got off the phone with an HR person who sent me an offer for the established Australian company. Really exciting opportunity!

Turns out spending 3.5h today in job interviews, two of them back-to-back, was a lot more tiring than I thought.

I’m in bed at 9pm, unable to concentrate on a talk show video on Youtube…

😴

Just had the nicest interview in a while, and also the weirdest, back-to-back.

Both are for a similar role, although one is pre-seed and the other one is Australian-owned and established.

Both are in domains I know next to nothing about.

I hope I get an offer from the established company because it’s a safe bet. But at the same time I really want to know more about the security company…

We’ll see how it goes next week I guess, nothing is going to happen before then.

Just pushed a commit with config file sourcing in the bash script to store the micro.blog app token

Commit details

I just published the first version of a bash script to quickly post to micro.blog using either the text in quotes after the command, the default $EDITOR or vi.

The source is available here and I’m using it to post this text!

Transitioning from a waterfall to an agile thinking can be very hard, and there’s nothing harder for some people than to understand how innovation works at an agile shop.

Receiving feedback from your customers on a feature you’re working on because they asked you too is usually easily understood, but what about Research & Development?

The answer to that is pretty simple: get your customers on board!

Talk to a few of them, the most involved ones, new customers even, and see if your idea for the next feature could help them. Your customers shouldn’t always be the ones asking you to implement a new feature or solve a problem they have.

The next question, harder to answer to, is: “what is then the priority between regular work and innovation work?”

I think there shouldn’t be a priority between the two, because if you get your customers on board with your innovation work, it’ll become regular work. The business value of R&D will get higher because now the people paying for your product want the new feature you’re talking to them about.

This article from December 2019 by Pete Hodgson (@ph1) is food for thoughts for non-technical people taking the Agile notion of self-organizing teams literally.

Imagine you’re hosting a dinner party, and your friend Sally asks what they can contribute. Some of the guests are vegetarian, so you ask Sally to make her well-loved lentil curry. You explain to Sally why you’re interested in the lentil curry - some guests are veggies - but tell her she’s welcome to bring something else if she’d prefer.

As Sally starts to prepare the dish, she realizes she’s all out of lentils. Luckily, Sally both understands the vision (contribute a vegetarian dish), and has autonomy on how to deliver that vision. We call this Aligned Autonomy.

Sally decides to change the plan, and makes her famous green bean casserole instead. This is a good outcome - Sally’s understanding of the situation on the ground improved, she adjusted the plan accordingly, and we were able to achieve our objective - a wonderful dinner party.

A big thanks to @icecrime for sharing this old post. This comes at a perfect time for me