Weeknote 6

A more practical week this time! One when nothing was finished, but quite a few things have been started. 


The 12in23 is spreading!

Outside work, I continue on my #12in23 challenge – completing the first two languages. But that aside, it was great to see that quite a few colleagues joined in on the fun (and learning) after talking to them about it the week before. We are now sharing profiles on Exercism.org and learning together. Where will this lead?

Practising mob programming

Talking about learning, on Friday, I led a small workshop in mob programming with three data engineers using cyber-dojo.org. It went well, and I think we all learnt something. More importantly, we might have addressed some negative feedback from the last half a year of pairing in our data engineering. Drivers were reporting how stressful driving in a pairing session can be. But focusing on the need to share an idea before it is encoded, the fact that it is the navigator who comes up with ideas and the driver just codes it in, solved that problem, I think. 

It was the first such workshop I ran in the department, and it won’t be the last. It’s a natural continuation of discussions about software engineering with my coding colleagues who are not in software engineering professions. 

Applying Team Topologies

But that’s not the limit of last week’s experiments. After some convincing and some negotiating, we have started a very small-scale experiment in Team Topologies in Civil Service applications. We have set up a very small enabling team which will work to support three stream-aligned service and delivery teams.

The team is forming very fast, and I’m really looking forward to what we can do. But the fact that we were able to start is already exciting. Despite all the Government Digital Services talk about modern ways of working in Digital Data and Technology in Civil Service over the last decade, the governance structures don’t support anything but a service team well. 

So we are dipping our toes into something new, and I really want to see where it takes us over the next few months. 

Explaining programming

Talking about things new. I have spent some time in my career explaining software engineering to others. How to explain it to somebody brand new to the subject so they understand? It is not easy. It requires patience and tactfulness. The more you know, the harder it gets, as there are layers upon layers of abstractions and “assumed” understanding you have that a beginner has not. 

I’m starting a new personal challenge next week. My wife, who hasn’t written a line of code before, is thinking of changing her career. What to? That’s to be decided! But she wants to give programming a go to see if that digital thing I’ve been doing for years is something she would enjoy. 

So, here I am at a professional and personal challenge for 2023. How do you explain programming and maintain a personal relationship with somebody new to programming? Wish me luck! And any suggestions will be very much appreciated! 

Flutter State Management – Endless Possibilities!

Recently I got back to Flutter with an idea for a cross-platform mobile app. The developer experience of both Flutter and Dart is second to none, but the myriad of state management options can give anybody a headache. Where to start? What to settle on? Provider? Riverpod? Redux? BLoC? GetIt? MobX?

I am still deciding!

So, it will not be one more of those many posts arguing for the superiority of one of the approaches over the other. Instead, I would like to share what I have done to help me figure it out in case it is helpful to you.

To help compare the pros and cons of the different approaches to state management in Flutter, I have implemented a simple application multiple times in many different ways. I still don’t know which one is better, but I know how they differ. The code is available on GitHub. Have a look. Make up your own mind.

Weeknote 5

The week flew by as I had many interesting, in-person interactions this week. I have spent three whole days in our London office. But that also meant I had some time on the trains to read. 


Trying different ways of data engineering

The week’s culmination was a three-hour meeting on Friday with all Data Engineers in my profession. In August last year, we started experimenting with our ways of working, and it was time we had a retrospective. Over half a year, I have asked them to work in different ways, drawing a lot from software engineering practices, focusing on collaboration, and sharing the burden and knowledge remotely. 

I won’t go into detail here just now. I think it deserves an article of its own, and perhaps to be published somewhere else. Let’s just say, that the results are better than I expected. Working in pairs (not necessarily pairing), dedicated coaching sessions on non-work related mini projects were a success. There are some things to improve, but the ideas are working, and we are improving our mostly remote collaboration. 

The #12in23 challenge

I have been working on my own skills too. At the beginning of the week, I have learnt about the 12in23 challenge organised by exercism.org. It’s about learning a little bit about 12 programming languages in 2023. Obviously, I joined in. I started with COBOL, C, C++ and C#. I have done some C programming, and I’m reasonably proficient in C#, but I haven’t done anything in C++ for some 20 years, and I have never programmed in COBOL. 

Why these four? It happens that these languages have been created more or less 15 years apart. Trying to do simple exercises in all four over the week gave me a new perspective on how technology and programming developed over the last 65 years. 

I do recommend it. It’s good fun 🙂

Is 2023 the year of cloud repatriation?

There appears to be more and more talk online about cloud repatriation. Last week I read quite a few recent articles about it. It looks like many organisations rapidly moved to the cloud during the pandemic. Many must have used the “lift and shift” approach and stopped there. Now, they struggle with the raising costs. According to one of those articles, 93% of companies repatriating (moving back out of the public cloud) are quoting the cost as the main factor. 

I think many of the moves were not thought through, or followed through, and this is just normal correction. I wonder what the year will bring in this regard. 

Weeknote 4

This week I spent my time trying to dig myself out from under a virtual pile of emails. I was trying to make a good start to reach new levels of productivity, but with so many things in progress, that was never going to happen. Maybe next week?

And so, I didn’t get to do anything interesting with data this week. I didn’t build any digital services either. But not all was lost. I got to experience digital public services – a truly demoralising experience! I managed to do some coding with Woody Zuill and Kevin Meadows too. 


We need to make public digital services better. 

That is probably true about many of them, but especially in healthcare. We talk a lot about accessibility and user-centric design. In healthcare, they talk about delivering patient-centric care. So how is it possible to create such a monstrosity at the connection of the two worlds? 

Not only are the services not very accessible, but they are also used in strange ways. Do you want to register for a GP appointment? You can only do it online and only between 8:00 and 8:35am. You got to the place with an appointment, but you need to schedule another. No, it is not possible to do it at the reception. It has to be done online. But there is no mobile reception inside, so you must go outside in the rain to book an appointment. Who comes up with these schemes? 

Eventually, I ended in a phlebotomy waiting room. There were some twenty chairs and just three of us patients. The receptionist

went on a rant about patients not turning up on time or even on the right day. It is not his fault, he says, the patients don’t read or cannot understand the emails. Fair enough. It might not be his fault. But who is responsible for failed communication which appears to be working only for one side of the dialogue? 

Human-Computer Interactions with Acute Disability

The problem is even more serious. In services like that, relating to healthcare, standard accessibility just isn’t cutting it. We design and test with users who are long-term sufferers of various conditions. People like that are used to their conditions, have adapted, and know conventions we can use to help them use our services. 

But people who need medical help often have a sudden onset of the ailment. They can be distressed, distracted, not at their best. I regularly see people in such situations and see how modern, accessible technology fails us. Last week I was put through the mill myself and nearly lost all my faith in both the digital and the healthcare simultaneously. 

And I don’t think it is only me. I heard somebody make a very pertinent joke this week on the radio. The Government Communications Headquarters, the GCHQ, used to recruit code breakers by posting cryptic puzzles in the newspapers. Now they don’t have to. They simply offer jobs to people who manage to get a GP appointment. 

It shouldn’t be like that. We must be able to do something!

Good, digital services matter

Digital services and products can be a matter of life and death. Why is it that software with a distinctly 1990s feel is used in emergency services? If a healthcare professional used 1990s medicine, they would probably lose their professional registration. But if they use 1990s IT systems to deliver patient care, that’s OK. 

Let’s do something about it!

Rant Over. Promise.

Let’s talk about Software Teaming

It used to be known as Mob Programming. A practice where a group of people develop software using a single computer. I tried it before. I really like pair programming. So when an opportunity presented itself, I couldn’t say no. On Friday, I joined Woody Zuill and Kevin Meadows and two others for a 90-minute session of Software Teaming. If you haven’t heard those names before, check out their book Software Teaming: A Mob Programming, Whole-Team Approach

Besides Woody, Kevin and me, there were two more people on the call. One person who never programmed before and somebody who has done a little bit, but not in the language we have chosen. Nevertheless, by the end of the session, we were programming effectively together. Everybody had a go at coding. Everybody has learnt something. 

I have learnt a few things myself. First of all, there is cyber-dojo.org. Don’t know it? Check it out! Second, I have never done pair programming right – not in the strict sense promoted by Woody and Kevin. They say for this to make sense, the idea has to cross from one head to another before it enters the machine. And so the driver does only what they are told by the navigator. Watching somebody code with an occasional comment or suggestion is not enough. The navigator designs the solution, and the driver is executing. They compare it to being a passenger and a driver in a cab. It really works. I want to do it more. 

Weeknote 3

The fourth weeknote. The new year’s first reflection covers the previous year’s last week. What did I do? I took some days off and didn’t do any work last week. Let’s reflect on that!

It is great to work in a place where I can take some time off without worrying about what I will find coming back. With some strategic reset I was able not to think about the regular work projects. I don’t have to worry about what I will find when I return, and I don’t have any FoMO symptoms either (Fear of Missing Out).

And it’s not that I don’t have anything interesting or important to do there. Quite the opposite. I’m already looking forward to Tuesday when I will re-engage with it all. It’s just that the place is full of great people who will carry on doing great things whether I’m there or not. I’ll try to help a little when I’m back, but I can rest and recharge for now. (Mind you, I’m typing these words after almost two weeks of not checking my office emails, teams or slack messages!)

And recharging I needed. After a few things I have done earlier in the week – I’ll write about them in a moment – we took a four-hour drive Lan i’r Gogs. We stayed in a nice little place with no mobile reception for two nights. The first night I went to bed early and slept for 15 hours straight! 2.5x my norm. The need for that nap sums up the year 2022 for me. 

But it wasn’t all sleep last week. I have done some reading, some thinking, and some writing: 

  • I have refreshed and written up an idea stuck in my head for the last year. In short, it’s about digital volunteering and gamifying first aid volunteering experience. Check the links for more detail. I had good feedback and a few offers of help. Thanks! Let’s see what we can do in 2023. 
  • I blogged about the connection I made while reading Digital Body Language between how we communicate with each other and how differently we write code. 
  • I watched an interesting short video from Cal Newport about the 20% paradox. Is this the solution to my personal productivity goal of 2023
  • I have spent a lot of time thinking about continuous professional development and how what we do (or don’t do) in the digital space differs from what I do in my volunteering roles. There is so much that should be said, I think, in this subject. And yet I cannot find the right words. I started (for the third time) writing about it this week, but it didn’t go anywhere. 

And the weeknotes? I will continue the experiment for a little while, and we’ll see what happens. 

Happy New Year!