Hi there,
I'm in Germany for two weeks, visiting family over Easter. But I'm much too happy with my new writing habit to allow travel and holidays to break the streak of my newsletter!

Mentor Monologue

In my work as a CTO, I'm thinking about friction a lot. I'm using a physics term here as an analogue for everything that slows us down from completing our tasks. This kind of friction can have substantial financial and human cost, which is why I find it important to notice and mitigate it when ever I can.
In mechanical systems, reducing friction can significantly improve efficiency. Lubricants, for example in an engine, not only help improve fuel efficiency and performance, they also reduce wear and tear, and thus help minimize the need for maintenance and replacement. The same applies to the human body. Friction wears out joints and tendon sheaths, even more so if they lack proper lubrication. (That's why I'm so interested in mechanical keyboards and their ergonomics.)
Another area where reducing friction is an important goal is sports. For instance, athletes wear sleek, low-friction clothes that allow them to run, cycle or swim with minimal drag. In winter sports, the application of wax on the base of the equipment reduces friction with the snow, enabling smoother gliding and higher speeds. Sometimes, reducing friction requires taking a break from our activities. Even though the Zamboni disrupts ice skating regularly, it's an accepted necessity to allow the skates to glide on a trace of water between them and the surface of the ice instead of sinking into slush.
In all these examples, reducing friction allows for more efficient use of force, resulting in better outcomes than simply increasing force alone. My question is: How can we apply this to our work in IT? Where can we achieve better results by reducing friction instead of just pushing harder?
One source of friction in our work as engineers is poor communication. Ineffective or unclear communication within teams or with stakeholders can lead to misunderstandings, delays, and rework. In other cases, it's not the communication that is flawed but the information. This can be due to insufficient requirements gathering, or poor planning in general. Unrealistic expectations and timelines, inadequate resource allocation, or failure to identify potential risks, can result in project delays, budget overruns, and most certainly increased stress for the engineers working on the project.
Sometimes, we engineers are our own source of friction. Inadequate testing and quality assurance, including limited test coverage or ineffective bug tracking and resolution processes, can lead to the release of software with defects and vulnerabilities. When a team lacks proper documentation, filling knowledge gaps, let alone onboarding new team members, become much more tedious and error-prone. Rushing to deadlines or taking shortcuts without proper consideration for the long-term consequences often leads to the accumulation of technical debt. This technical debt will then make future development more challenging, as it requires additional effort to refactor and maintain the codebase.
Where most of us feel friction the most in our daily work is when we lack proper automation and tooling. Among the repetitive work that should be easy and, ideally, automated are tasks like infrastructure setup for development, testing and production, build processes, testing and deployment. Automating these DevOps processes can free up enormous amounts of dev time for more fun and interesting engineering work. For that reason, they are high on my list of courses I'm going to offer in the future.
Finally, there's the friction that comes from an insufficient focus on personal well-being. Working long hours without breaks or not prioritizing self-care is likely to lead to reduced productivity and even burnout. A culture that does not value personal well-being will have a severely negative impact on the overall work experience in engineering and beyond.
An engineering organization that drives with the handbrake on is not sustainable. Sure, pushing the pedal down harder will mitigate the problem for a short time, but you will inevitably end up at the side of the road watching everyone pass you by, and with lots of expensive damage. It's a much better idea to reduce friction early in a proactive approach that emphasizes clear communication, thorough planning, robust documentation, effective testing, proper resource allocation, pervasive automation, and fostering a collaborative and supportive work environment.


As part of my preparations for the launch of The Server Room, I had to find a way to integrate the Discourse community platform with my WordPress website on which people will sign up for their membership. I'm using the WordPress plugin Paid Memberships Pro to manage memberships in The Server Room, but it doesn't have any integration with Discourse. On the other hand, there is the WP-Discourse plugin that can turn WordPress into a Single-Sign-On provider for Discourse, but it doesn't have any integration with PMPro. In the end, I had to build this bridge myself. In a late coding session, drawing on PHP coding skills I acquired thirty years ago, I built my first little WordPress plugin that hooks into both PMPro and WP-Discourse to only allow TSR members access to our forum platform. One task done, but quite a few more to do before I can launch The Server Room. Make sure to use the time by subscribing to the launch waitlist so you don't miss the 50% founder discount that will half your membership fee!

And if you want to know in advance about my next live stream, course, community hangout and other events, be sure to check out the Events page on my website!

Recommended reading

As an online teacher, I always recommend additional material to my students with which they can expand their horizon. Here's a list of reading tips I've curated for you.

How to write good epics

I especially like the advice "The best way to write good epics is to not write epics at all. Don’t try and force yourself to create epics from the outset. Start with your stories and as you create more, some epics will naturally form."

Goodbye SASS, welcome back native CSS

It's great to see that the native web technologies like CSS are evolving to a point where they eliminate the necessity of additional tooling, at least in some situations.

The one about the web developer job market

In my office hour live stream last Friday, we discussed this long analysis of the current job market in IT engineering, especially in web development. Spoiler: It doesn't have a happy ending. But Baldur Bjarnason's article is insightful, and maybe a necessary reality check.

Unemployed agilists

Let me complement the previous link with this one. While this series of blog posts by Johanna Rothman is aimed at agile coaches and Scrum Masters, it is full of advice that can be valuable for anyone looking for a job in IT.

Thanks for reading!

I hope you found my News from The Server Room enjoyable and helpful. If you have any feedback or questions, simply reply to this email!
Take care!
Jochen, the Monospace Mentor