Leon Mika

Working on large software projects — complete with Jira boards, code coverage requirements, and peer reviews — it’s sometimes easy to forget that you can actually use the skills you have to solve the little problems you encounter in your job.

If you need to do something, and that thing can be done easily just by writing a small script, then don’t be afraid to go ahead and write one. It doesn’t need to be a fancy script. Doesn’t need to have unit tests or even be checked into a repo. It just needs to solve your problem.

This is probably one of the most useful things I’ve learnt in my career.

I’ve been seeing this message an awful lot recently when I’m trying to use mobile data. I originally thought it was Telstra, but now I suspect it’s Android, as restarting the phone seemed to have fixed it.

Earlier this morning:

Me: (writing in my journal) Nonna, my 91 year-old grandmother…

Autocorrect: Did you me “Donna”?

Me: No, undo change. (continue writing) good news is that Nonna…

Autocorrect: Did you me “Gonna”?

I can forgive MacOS for considering nonna a spelling error, since it’s not an English word.

But I do see why auto-correct on MacOS can be frustrating. Apart from the two completely random corrections it made for the same word, it also doesn’t seem to get the hint when I undo the change. I would have thought that action is a pretty strong signal from the user to just leave the word alone, at least for the moment.

I’d be curious to know if a brand new user to Facebook would be able to get any value from it. Looking at screenshots of their app redesign, the whole thing looks convoluted and unintuitive. Is the sole purpose of Facebook now just to keep existing users from leaving Facebook?

I am feeling some very minor after-effects from the booster I took yesterday (nothing serious, just the expected cold-like symptoms). I was curious as to whether it was anything like I experienced in January, when I got my last booster. I went to my journal to see what I wrote about it. Unfortunately for me, there was nothing there.

To be fair to my past self, there were some other events going on at the same time which I did write about. But I was left pondering this morning about why I didn’t write anything about how I was feeling back then. My guess is that I probably didn’t think it was worth writing about at the time. “Feeling a little off” was probably something that I thought was quite trivial, and wouldn’t be relevant later on.

I was wrong: it was relevant. Otherwise I wouldn’t be going back in time to find out.

I guess there’s a lesson there: write it down. Write everything down, even if you think it might not be relevant at the time. The simple fact is you don’t know. It may very well be relevant months or years from now. Better to written down too much than not have anything written at all.

Of course the trick is working out what “everything” consists of. If you’re writing down what constitutes your daily routine each day, I’d imagine you’ll be spending most of your time documenting the same thing over and over again. I guess a good decision process is if you’re unsure about particular thing, then it’s probably a good idea to just write it down anyway. You may think it’s unnecessary at the time, but again, you don’t really know.

I’ll try to get better at this myself. In fact, part of this post was taken from this morning’s journal entry, just below a description on how I was feeling today.

Boosted. 💉💉💉💉

(also muffined up once again 🧁)

🔗 Publishing your work increases your luck (via Github’s The Readme Project)

I found this very inspiring. Given where it was published the subject matter is about software, but I believe that it could apply to pretty much any creative endeavour.

Had sprint review today. Overall, it went really well. Much better than last time. We didn’t quite clear the board but that was mainly because we finished the work we planned for and were simply pulling in tickets from the backlog.

I subscribe to a newsletter that sends “reminder” emails if I skip an issue. If I don’t open one of the email newsletters I receive, then a few days later, a copy will be sent with a forward of the form “looks like you skipped an issue. Here what you missed.”

These reminder emails are bad, and here’s why:

1. It gives the impression of hustling me. I appreicate the time you take to publish something that I see value in, but sending these reminders feels like your forcing your content onto me. Like I just got to read this content. Really, you must read it! And, oh! You forgot this one day? Well I’ll make sure you don’t forget it (and me) again. Please, back off! I’ve received your content and I’ll get to it when I get to it, if I feel like it, after I’ve read all the other newsletters I received. Please don’t push me to read it on your schedule.

2. It just confirms that they’re tracking what I open. I mean, I know this aready, but it does bring it front of mind.

If you’ve got an email newsletter, please don’t do this. It could just be me, but I don’t read every issue of every newsletter I receive, apart from a few exceptions. If I’ve subscribed to yours, then know that I get value from your content. Really, I do; I wouldn’t have subscribed otherwise. But sending these reminder emails out do not do your content any favours.

Trying a new cafe this morning. I drive past this place all the time, and I keep telling myself I should try it. Fortunately it’s only a 15 minute walk from home.

Listening to the ATP #491 discussion on code formatting right now. I guess I’m not the only one that converted from BSD braces to K&R because it was the style used by “everyone else” (Go requiring this style helped a lot here). I will stand on liking the cuddled “else” though.

This is how I usually spend my Saturday mornings. One difference today was that a train-replacement bus drove by roughtly every 10 minutes or so which, given that it was the weekend, was more often than I expected (not that that’s a bad thing).

A lot of Slack messaging and organising calls with others today in order to get something finished for next week. These sorts of days are exhausting: where you’re simply reacting to things. Starting to settle down now though, given that we’re nearing the end of the day.

Had an excellent design session meeting this morning, but after 1.5 hours of talking, my voice is absolutely horase. Might need to consider improving my speaking skills and possibly even my voice strength. A microphone or headset might also be helpful.

Moving my work journal over to Micro.blog.

That blog has been bouncing around CMS’s for a while now, and there’s always one or two things I’ve found lacking. It got to the point where I’ve began building my own CMS, and although it’s closer to what I’d like for this work journal — and includes a few features that other CMS’s lack, like private posts — I’ve been thinking about what’s missing, like image hosting and syndication, and realising that spending the time to build them would just be time I don’t spend on other things.

And honestly, the reason why I’ve been unhappy with all the other CMS’s I’ve tried is because I was hoping for something which easily supports posting short updates with the occasional long post… something similar to Micro.blog. Well, something like that already exists, and it’s called Micro.blog.

So I’m going to do the “kill your darlings” thing and try having this journal hosted here for a while. Sure it will mean that I don’t get things like private posts (which were honestly the only unique feature about that homegrown CMS) but I can probably make it work. At least there’ll be one less distraction.

🔗 Mentality

This might be a good one to bookmark and come back to occasionally.

🔗 Stop checking the news before you do deep work

Yes! I always fall into this trap.

Trying my Pixel 6 caseless for a little while. It was starting to interfere with swipe gestures which was getting a little annoying. Might be some other benefits with no case, such as being able to carry a physical notebook again.

Went to see Hamilton at Her Majesty’s Theatre last night (a little ironic, I know). I’ve seen the Broadway recording, so I didn’t come in “cold”. But it’s nothing compared to seeing it live. Absolutely faboulous. Highly recommend.

How is it that I can make a change in one area of an Android app, like add a new fragment, and a completely unrelated area of the app (the DB models) decides to stop building correctly? Sometimes it feels like the whole dev. environment is held together with masking tape.

I’ve turned off analytics for this site. It’s been more than a hinderance than anything else. It got to the point where I actually stopped visiting my own site just to keep my visits from showing up the data. How crazy!

Here’s what’s been happening at work with me recently. I write it here as an exercise in how I can learn from this. They say that writing can help in this respect so I’m going to put that logic to the test (in either case, just having this documented somewhere could prove useful).

We’re working on a pretty large change to the billing service powering the SaaS product sold by the company I work at. Along with our team, there are two other teams working on the same service at the same time, making any changes they need to release the product stuff they’re working on. All our teams had our own deadlines — which are pretty pressing — to get stuff delivered either last month or sometime this month.

Knowing that this was a change that could impact these other teams, I came up with the idea of using an epic feature branch, which will be used to track our changes. This will leave the main branch relatively free for the other teams, who’s changes would not be as invasive as ours, to proceed with their plans and release when they need to without us blocking them. Great idea — everyone can work at their pace.

Of course, if it was such a great idea, this blog post would be a lot shorter. 😉

This started out well. We were doing our thing, making our changes and committing them to this epic branch, occasionally pulling updates from main when we started to fall behind. The other teams were merging their changes on main, and the CI/CD pipeline was dutifully deploying what they merged into the dev environment.

Then, after a couple of weeks, things started to go a little wrong. The changes from the devs started to pile up in the “Ready for QA” column of our Jira board. The team was a little concerned that the changes we were making couldn’t be ready for testing until they were all finished and merged. Given the way the tickets were written, this seemed like a fair enough argument (I was the one that wrote the tickets BTW), but this delayed testing of the changes to the point when we we only had a few days to complete our testing and push it out to production before we hit our deadline.

Once the QA team was ready to proceed, disaster. Many of our changes had bugs or issues that we didn’t foresee, and had to be fixed or new tickets had to be spun out. We had to delay rollout by more than a week (at the time of this post), which made the business quite unhappy. Making things worse was the use of the epic feature branch and the automated deployment of main to Dev. The other teams were still doing their thing on main, and when they merge a change, it blew away our changes. This resulted in the QA team coming to the dev team with issues which, after investigation, were largely because the our changes were not even there.

One other thing I didn’t forsee was that when we get to the point of merging our epic feature branch into main, I had little confidence that it would be integrated correctly. The sole reason for this is that the test team hasn’t been testing our changes from main. They’ve been testing the epic branch just fine, but all those conflicts that were resolved during resyncs from main, plus the actual large-scale merge of our branch: what’s to say that we didn’t miss something? We’re just right back to delaying our testing near the due date.

So this is where we are now. All the bugs (that we know of) have been addressed and I’m hoping to merge our changes into main today in preparation for what I hope to be one last test before we roll it out.

So, what did I learn from this? I can think of a few takeaways:

1. Continuous integration — not the automated build kind, but the consistently merging into main kind — is not only important, it’s bloody vital. Not doing this means that you’re left with little confidence in what the testing team is actually testing is what would be pushed out to production. Using the epic feature branch was a mistake. Always merge to main, and test from main as often as you can. You may need to push out changes that are turned off, but as long as you design for this, this should be fine (feature flags FTW).
2. Letting tickets pile up like they did was another mistake. Ticket flow is important: not only for the team, who’s morale is tied to whether we will pass the sprint or not, but also in finding any problems early enough that you have enough time to react to them.
3. This is probably something on my head: don’t spend too long doing a design. I spent a week on one when one probably could have been written up in a few days (to be fair: the scope of the work has not quite been locked down when I was doing the design work, which did delay things a little). A quick design also means getting feedback sooner.
4. I think the largest takeaway is trying to check the businesses expectations on what can be delivered and when. This I find the hardest thing to do. I’m a bit of a “aim to please” type of person, so it’s not easy for me to say something like “we can’t do that in that time.” Instead I tend to be quite optimistic about what we can deliver. I have to get better with this.

The saga is not quite finished yet: you may see another blog post on this subject soon enough. But hopefully things will settle down after this.

Given how often I’ve been typing it recently, you would have thought I’d know how to spell “Los Angeles” by now.

Hmm, the folio keyboard I’m using for this iPad is starting to flake out occasionally. Sometimes when I unfold it, the iPad doesn’t recognise it and throws up the on-screen keyboard. Restarting the iPad seems to fix it, so I’m not sure if it’s a battery age thing. 🤔

Got offered a free sample of a “lamington scone” at the bakery I went to today. Tastes pretty much as you’d expect. 😋

Good to see that there’s still room for innovation in scone technology. 😉