Last week was the promotional week of a partner – what an event! On the first day we saw in minutes the volume we used to see in days. As one would expect, despite the preparatory work, the API started to take more and more time to respond, or as we put it in our jargon: latency was increasing. Not waiting for the incident to happen, the team went all hands on deck to identify the bottleneck and reduce it even before users could perceive the problem.
Luckily, most days aren't like that. It's nice to have scalability issues though, as it reminds us of the time when we were eagerly waiting for the first call to the API and the first purchase made using our Buy Now, Pay Later solution. It also reminds us of the first time a partnership wouldn't deliver what was expected. My experience at Hokodo has been a rollercoaster ride of more than three years of fun and excitement. I’ve learned a lot, which is my drive in any job.
In those years, my methodology has only slightly changed. I'm an early bird, so my day and my first focused session of work usually starts at 05:30. Every now and then I replace it with a short workout. It's only interrupted, around 07:00, by my young daughter asking for her bottle of milk from her room, like a nestling crying and begging for insects. The next two hours are dedicated to family time, having a good breakfast and preparing the little one for the day.
After dropping her with her nanny and one espresso—the second, to be fair—freshly made with the bean of the moment, I start my second focused session. This one is usually reserved for coding or reviewing code. The latter is an important exercise done by software engineers: no new code goes into production without having been read and tested by at least one other member of the team. Besides the evident benefit for software quality as bugs can be discovered earlier, it's also a good occasion to learn new parts of the system, cool tricks in the language or framework and generally upskilling the reviewer as much as the reviewee. Finally, it helps standardise the coding style across the team, which in turn makes reading code in other parts of the API easier for everyone, increasing productivity and reducing the onboarding hurdle quite naturally.
After a short break around 10:30 comes the last part of my morning routine. It can be about finishing a heavy code review, progressing on my own stuff or occasionally some morning meetings. When I say coding, as a Tech Lead, I obviously code way less than when we started 3 ½ years ago. Coding sessions might be replaced by exploration of a particular problem or specification of a solution.
My lunch break is either shared with my wife when she works from home or with Netflix. Or both…
Early afternoons are usually reserved for 1-to-1 catch-ups and team meetings of any sort. I've never been a big fan of meetings, but with an organisation doubling in size every six months, we need strong alignment and sharp prioritisation. I believe that not liking meetings is a strong advantage of hosting one as it keeps you focused and determined to squeeze the most out of a session.
When the last meeting is over, it’s time for a final, short, focused session at the end of which I try to take a step back to see what I've achieved today and plan for the next few days.
At 17:30, the little one is coming back home and Dad reports to duty! Screens are turned off and after a few hours of code reading, now is storytelling time. The monster is not a bug anymore, but a wicked wolf or an evil witch. Shhh…