CTO Weeknote 2022.7: Taking time off, monolith vs microservices, conflicts in remote teams

Hello DevOps people!

This is Jochen, and here’s what’s new at Opsitive!

Working on Opsitive

Running my new DevOps learning platform as a side project will be a challenge. I already have a demanding job, as well as a family, not to mention a body and mind which require more attention each passing year. My main challenge is diverting some of my time to grow my DevOps community, but in a way that doesn’t hurt my existing responsibilities. Getting this project off the ground in a sustainable way will require me to pull out all the stops of what I know about efficiency.

That’s why this week, despite having taken time of work (please don’t judge me, more on this later), I’ve put a lot of thought into what processes and tools I need to publish a newsletter at a consistent frequency. As someone who has done countless attempts at blogging regularly–and failed–, I know full well how hard it is to publish on a regular basis. And with Opsitive, I feel that the stakes are much higher than with my little personal blog because I want to build a community, which is known to require consistency from its makers.

In order to keep things fresh and flexible, I’ve decided not to copy the common approach of curating a list of interesting links, and preceding it with a personal editorial. Instead, I’ll be adopting the weeknote method where I’ll journal my experiences and learnings of each ending week. To put a bit of a twist on it, I’ll also publish it in video form.

Welcome to my first Opsitive weeknote!

Taking time off

I love my job. I love the freedom of running my own business. I love the satisfaction of getting positive customer feedback. I enjoy working in a field that lets me learn new things every day. On the flip side, there’s a long list of things that must be done, an even longer list of work that would also be nice to get finished, and there will never be enough time for it. All this makes it hard for me to switch off when I go on holidays–like this week.

On the other hand, I know what’s going to happen if I pig-headedly keep working: I’ll get head and body aches, run a fever, similar to the flu, which will confine me to bed for two or three days. These are my typical burnout symptoms. That’s why this section is mostly a note to myself that I need to make an effort of getting my mind off work. By coincidence, my kids have their midterm break this week, which makes for a great opportunity to spend more time with them than in front of a screen. With the current series of storms subsiding by the end of the week, I’ll also be able to enjoy the outdoors for longer stretches than usual.

In the grand scheme of things, I’ll try to force myself into a routine of recharging by scheduling my next week off immediately when the current one comes to its end.

I’d be interested in how you prevent your batteries from depleting. Share your holiday aka vacation strategy with me on Twitter!

Monolith vs microservices

DigitalOcean has published an easy to understand article about the differences between monolithic code bases and applications composed of microservices. Read “Monolithic vs microservice architecture: Which is best?” if you’d like to make a confident decision between the two architecture models. The main take-away for me is that the price for breaking up a code base into smaller and simpler microservices is the higher complexity of the whole, which will grow over time and needs to be managed. This kind of fundamental architecture decision will have consequences for the whole lifecycle of an application. You don’t want to make it on hype alone.

In memoriam Lorinda Cherry

Earlier this month, Lorinda Cherry, a long-time member of the original Unix Lab, died. In 2018, she received the Pioneer in Tech Award from the National Center for Women and Information Technology. As a woman in tech, in early tech no less, Lorinda had to fight many obstacles throughout her career. Once, during her work at Bell Labs, where she was hired as a Technical Assistant despite her college degree, she received a statement of benefits that explained what her wife would receive upon her death. When she contacted HR to confirm that they meant spouse, they said no and demanded she return the statement (which she refused). AT&T eventually had to concede to equal treatment of husbands, but only after losing a costly court case.

Shortly after the creation of Unix, Lorinda joined its development team. She’s the author of several well-known tools, for example the bc calculator and the eqn tool for rendering mathematical formulas. She also pioneered the rendering of phototypesetter copy on terminal screens. Her work on text analysis, and especially her contributions to the Writers Workbench suite, got her an appearance on the Today Show.

Still, Lorinda Cherry was one of many women who got little recognition for their many contributions to the progress of information technology. I’ll think of her every time I pop into my terminal for a quick calculation.

Why virtual teams have more conflict

Lindred Greer, a professor of organizational behaviour at Stanford Graduate School of Business, published an article in which she explains how remote collaboration can be a petri dish for quickly escalating conflicts. She identifies as the main cause of these conflicts the reduced amount of context and nuance in digital communication, for example the lack of tone and facial expressions in written messages. I can confirm from my own experience that we tend to fill these information gaps with an emotional response. I’m also guilty of often writing in an impersonal style that just covers the objective matter at hand but is missing the necessary cues for the tone in which it should be read.

Greer recommends building trust in new teams by starting off working co-located or at least using video calls. When team members had the opportunity to get to know each other better, they’ll have an easier time making sense of written communication.

Here a few of her tips for managing conflict in virtual teams:

• Match team members with appropriate tasks. This requires them to rely on each other to succeed.
• Set clear goals that keep the team on track.
• Create team-wide rewards to foster alignment and teamwork.
• Be patient. Building trust takes time.

Working in a distributed team has many benefits, but this is one of the aspects where we have to put in the necessary effort to make sure it generates the right results.

Writing internal documentation

I’ve read an article from Zapier that explains how to write internal documentation that works. It’s about general operations docs, and it applies nicely to technical teams, too. In the following, I’ll outline my main learnings from the article.

First, don’t get bogged down by the details. If you break everything down into minute details, your documentation will be hard for your audience to digest, and hard to maintain for yourself. And you’ll have to maintain it because outdated details will confuse people, which is the opposite of what you’re going for. For example, I’m now removing most mentions of tool and service names from our company runbook because they’ll need to be changed every time we replace them. And we tend to move on quickly if we feel that a service doesn’t meet our expectations. Even complex issues can be described in a simplified way. Your audience will have to go in-depth after reading your documentation anyway; most documentation is only supposed to be guide them in the right direction.

Another important advice is to keep your processes straightforward. If your processes are complicated, so will be their documentation. Here’s a great quote from the article: “Your processes–and the documents explaining them–should aim for what helps the most people, not what helps a few people the most.”

Make sure to replace jargon with plain language. The people who will rely on your documentation the most will have no clue what’s going on. Write your documentation with newcomers in mind. This goal will require you to fight what Steven Pinker coined “the curse of knowledge”: overestimating the knowledge level of non-experts. By the way, that’s going to be my main challenge in writing my DevOps course materials.

Finally, include broader context about each team. By going beyond the technicalities, you can establish your company’s character and style. Helping people know and understand your culture will improve communication and teamwork.

This article has inspired me to give our company runbook a bit more TLC.

That’s it for this inaugural Opsitive weeknote. I hope it was interesting and useful! Any constructive feedback is appreciated — send it to me on Twitter.

I do live coding sessions on Twitch every Tuesday and Friday at 4pm Irish time. Pop in at twitch.tv/fullstacklive and say hi!

You can also reach me on Twitter as @geewiz.

If you’d like to get my updates in your inbox, subscribe to my newsletter below!

Until next time, take care!
Jochen