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.
🔗 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!
The Feature Epic (Featuring the Epic Feature Branch)
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:
- 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).
- 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.
- 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.
- 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. 😉
Spent all frickin morning in meetings. Hardly got any work done — ironically the type of work the business is hounding me to get finished ASAP.
Going to have some lunch and then I’ll be turning off Slack notifications so I can keep my head down. 👨💻
Woke up to my devices being unable to connect to the WiFi. It must have gone out during the night somehow. First time that’s happened in a while.
And yes, turning it off and on again fixed the problem.
End of sprint ceremonies today. Could have gone better.
We failed the sprint quite hard. Not entirely our fault: we actually got a lot done, but we couldn’t deploy them until we got the go ahead from management. This meant we couldn’t mark the tasks as complete and get the points for the work. This bought the mood down somewhat. The retro was also a bit… sombre? Maybe sombre’s not the right word but there was a general feeling of things not going as well as they should.
Mixed this in with some concerns about a feature we are responsible for that was buggy and was blocking a release of another teams that had to go out today. It’s never a good feeling when you had to roll something back. Much less so if that thing is something that no one really has a good grasp on. Lot of trying to work out whether it was even safe to rollback.
This feature has been a huge pain for us for the past several weeks. It’s one of these things that is so fiddly, never quite finished, always getting kicked back to the devs because the QA team has found something else that’s not working quite right. I don’t fully blame the team for this either: it was handed to us from another team with the belief that it would be relatively straightforward to finish, which proved not to be the case. Also not fully appreciated is the amount of time it takes to become familiar with a piece of code that you have had no real hand in developing yourself.
I think me being a little hands off on with this feature was a slight mistake. There were other things that I was focused on — and I’ll be honest: it’s hard for me to keep my focus on something that I felt was less important than the thing I was working on. I thought that letting those in the team most capable with doing the work, and just letting them get onto it, was the best approach. I try to take this approach with most things: I know for myself that I can’t stand having someone breath down my neck while I’m working on something. I don’t know: maybe I should have had more of a finger on the pulse. Just a light one, so that if others need to know what’s going on, I could answer them.
Yeah, I’m loving squad leadership. 🙁
At least the demo went well.
I’ve been finding myself using Day One for general note taking, like ideas, things to remember, etc. I think the reason is because it’s on all my devices, and it feels a bit like a permanent record. Google Keep feels more like a scratch pad. Shopping lists, etc will remain there.
🎙️ No Mercy / No Malice: All Ears
First one of these newsletters that I actually listen to in podcast form, and I really enjoyed it. Happy coincidence that the subject today probably explained the reason why.
🔗 Google loses two execs: one for Messaging and Workspace, another for Payments
Two thoughts I came away with after reading this.
The first is an attempt to understand how Google can think that they can put out anything — the version of US Google Pay app for example — and expect people to flock to it. I no expert, but I’m not sure why the physics of user adoption should be any different if you’re a multi-billion dollar company. People will use your software if it’s good, and they won’t if it’s not. And if you force people to change their habits because you want to completely throw out your existing version for “reasons”, you’re giving users an opportunity to choose whether they want to even continue using your stuff.
It happened to me when they shutdown Inbox. I had the opportunity to change to something else, which I did: Fastmail. Since I was forced to change my habits, I may as well have changed them for the better.
The second — and this is probably obvious — is that the a good indication of the health of one of Google’s app is how often they rebrand it. Since it’s launch, Gmail has always been Gmail. I can’t even name what Google’s messaging app is called now.
I’m personally a bit of a fan of unit tests (at least when it comes to writing code for work — for my own stuff… not so much), but I can see why people are put off by it. Apart from being a little tedious, it really does slow development down.
The amusing thing about turning 37 today is that it felt like I’ve been 37 since maybe September last year, so all in all I don’t feel so bad. Just need to ride that feeling for the next 12 months. 😏
(Not helping is that I missed-type 37 as 38 twice while writing this post).