Patrik
Wise words of the week
- If anything can go wrong, it will (Murphy’s Law).
- Software: the question is not if there is a bug, but when it will be discovered.
Journal
Murphy’s Law describes my week. As I said last week, I fear errors and this case just happened. I spent the better part of the last two work days handling an issue. The initial problem was actually very simple, I commented out 3 lines of code to test some hypotheses and eventually forgot to uncomment them. This was exactly 1 year ago to the day (happy bugaversary!).
And here comes Murphy’s Law. As I uncommented the 3 lines of code, another part of the software crashed. This meant another investigation to determine why this was happening. This problem presented an interesting challenge: I could implement a proper solution that would take a couple of days, or I could find a quick fix to prevent the crash. Since releasing a solution quickly was urgent, I had to choose the latter option, but then I will have to come back and pay this technical debt.
Generally, the process for handling issues is pretty clear.
Transparency: don’t try to hide or use corporate speak around the problem, be brutally honest. It helps everyone and actually generates some trust because it makes it clear we aren’t trying to hide things.
No blame: associating problems with blame is the sure recipe for souring relationships and ensuring nobody will ever report a problem again, so it’s clearly a no-go.
Assess the damage: figure out the extent of the problem. Some problems affect no one, while others can affect everyone.
Communicate: once the extent of the damage is clear, decide whether to communicate personally or broadcast to everyone.
Fix the problem: obvious, but still important to do correctly.
How did I use AI this week?
I didn’t have time to explore new tools this week, so my AI usage was pretty much the usual use of Cursor in auto mode while coding to help me where I felt unsure (generating SQL code) or it was very boilerplate (generating unit tests for the code).
Though I would advise proceeding with caution with the latter: AI will assume that the code is correct and generate tests that enforce what is computed. If there are errors in the code, AI will generate tests that ensure that the error is not fixed. So, as much as AI is useful, I think the TDD (Test-Driven Development) approach of writing the tests before coding is still superior. It also helps shape the code in the right way.
Marc
The build
This week was calm in terms of new development on my side. It was intense for Patrik though, because of a pesky bug we found.
On another topic, we’re exploring the idea of a paid package with some hours of coaching, as we get more and more of these requests. We just have to be careful that this request isn’t bad onboarding in disguise, which brings me to the following point.
The edge
The new inline documentation helps. But two different clients asked for 1:1 support calls, which shouldn’t be the case. So we still have to improve the onboarding.
We’re also thinking about a more gamified concept, which would remove onboarding per se altogether.
Anyway, a lot of food for thought, with too little time this week ^^
Note to a friend
When we have a bug (implying the computation or a user interface element), Patrik and I agreed that we’re a transparent company and we let our clients know. My previous work experiences have shown me time and again that this is the single way to have long-term success. So if you’re building your startup nowadays and wonder whether you should inform a client about a problem, don’t think twice, do it. Your future self will thank you.
Tool of the week
Gemini Nano Banana 2 image generation tool! It’s a bit unrelated to FI Planner, and more to my Mustachian Post blog. But hey, this tool is so good at image generation and also at manipulations like changing embedded text. I couldn’t live without it anymore. Or I could, but a/ my blog images would be less fun, or b/ it would take me so much more time…