Weekly review cw 25

The Power of Pair Programming

This week, I had a particularly productive day. It was preceded by a daily meeting in which I requested assistance with a complex workflow between the frontend and backend (more details below). We started by discussing the day's goal, then booted up the IDE and started a programming session. (This time with WebStorm, and it didn't run smoothly. WebStorm has become increasingly unreliable and unstable over time.)

The discussion about how to tackle the solution led to a better solution than I could have developed on my own. The joint implementation wasn't necessarily slower because we worked on the frontend and backend in parallel, then pieced together working parts.

As a result, both developers have mastered the entire flow, understand the decisions and how the solution was arrived at, and can specifically search for the cause of a problem or, if new features are introduced, assess their feasibility and effort because they understand the entire stack. The latter aspect, in particular, is a significant yet often overlooked benefit of pair programming. Shared knowledge of the application saves a lot of time later on. After all, we read code much more often than we write it.

Asynchronous Workflow with Server-Side Events

As part of our current patient documentation project, we opted for server-side events to control dashboard updates from the backend. We were able to leverage this decision with our new feature. The current challenge was as follows:

• A patient is either marked as deceased in the detailed view, or a prescription is cancelled with the reason "Patient deceased."
• The result is identical in both cases: The patient should be marked, the current prescriptions should be treated according to their state, and a doctor's report should be created.
• During the process, a progress indicator in the form of a spinner should be displayed to the user.
• As soon as the process is completed in the backend, the spinner should be hidden in the frontend, and a notification about success or failure should appear.

The pair programming session involved displaying the spinner and then hiding it again, controlled by the backend. We wanted to implement the hiding using server-side events. It was essential to consider that two users could be working on different patients simultaneously. Since server-side events always communicate with all active front-end applications, this case had to be considered separately.

We identified and resolved a few additional pitfalls during our discussions. In programming, the happy path always accounts for 20% of the effort, and thus, 80% of the feature is implemented. For borderline and extreme cases, it's the other way around – 80% of the effort for 20% of the function.

This aspect makes prototypes that validate the happy path and already appear finished so elusive for business, so much time and money still have to be invested before productive use. But that's a whole other story.

New Focus in My Exercise Program

The limited mobility is affecting my table tennis game. Thanks to a pain-free shoulder, I've begun training again, slowly. The effects are dramatic and bothering me. Complaining doesn't help. So, I need action: I've reduced my running to once a week to maintain my level and focused more on strength and mobility.

• Monday Table Tennis + Yoga
• Tuesday Yoga
• Wednesday Table Tennis + Yoga
• Thursday Yoga
• Friday Table Tennis
• Saturday Gardening 🥵
• Sunday 17 km run

If you'd like, follow me on Strava.