|
|
|
|
|
You'll notice that I've changed the format of my newsletter a bit. There's still the Mentor Monologue; this time about when to try and adopt new tools. However, course and community updates will appear on my website from now on, as will my reading recommendations to you. As a consequence, each newsletter will now contain a section with links to all the latest blog posts. Let me know what you think about the new format!
|
|
|
|
|
Mentor Monologue
|
If you're following me on social media, you've seen me publish posts along the lines of "Added XYZ to my list of projects to check out." (To let you in on a secret, these posts are auto-generated from my Github stars. Automation is key in marketing as much as in DevOps, you know!) But let's take a step back for a minute, and ask ourselves: Is it really necessary to constantly check out new tools, and when is the right time to switch to one of them? This is another one of the questions frequently asked during my office hour live streams.
|
There are multiple contradictory aspects to the question of changing our tool set.
|
First, there's the learning benefit. I always advocate for curiosity because it's an effective driver to continuously broaden your horizon, to keep growing. Checking out new tools is an easy way to satisfy that curiosity. After all, new ones are getting released every day. It's useful to know what's out there, if only in case you get into a situation in which a certain tool comes in handy. I don't necessarily try out everything I discover right away because of another aspect that I'll cover next. But if a tool looks interesting, I'll at least save a bookmark in my notes so I can retrieve it when the need arises. (I publish these notes on the web, by the way.)
|
That brings me to a downside from which I suffer as much as everyone else: Checking out shiny new things is often more appealing, and most of the time easier than doing actual work. Have you ever tried a new terminal application, even though your current one is executing your shell commands perfectly fine? A new plugin that solves a problem you might perhaps encounter some day? A new editor, even though your current one already has more bells and whistles than a high school marching band? Installed a new desktop environment, a new operating system even, to see how it feels? I have for sure. Guilty on all charges. But let's be clear here, this is not work. This is distraction, a leisure time activity. At work, tools are supposed to help us achieve our tasks, not to steal our focus.
|
When I find myself procrastinating with shiny new objects, I often take a step back and look below the surface, asking myself "Why am I getting off track here?" Being mindful enough to notice when procrastination hits is a useful skill. Is it because I find this task quite challenging, or on the opposite, a bit boring? Is it because I'm in fear of negative feedback? Or am I reluctant to finish this work because of the uncertainty what'll come next? There are many reasons that make us susceptible to distraction. Identifying them helps us breaking out and getting back on track towards the finish line.
|
There's another hidden danger I'd like to warn you about. It's the cost of switching, which is much higher than just additional disk space taken up. If the new tool is not just a successor or fork of the old one (as with the transition from vim to neovim), we'll have to start from zero in terms of familiarity and muscle memory. Even if the old tool was similar, we probably won't reap the benefits of the new one without additional effort. I don't want to go full "sunk cost fallacy" on you, but it's definitely something you need to consider before leaving for greener pastures.
|
Let's get back to the initial question. When is the right time to try and maybe even adopt new tools? I'd say apply common sense. If you struggle with getting your current task done because of shortcomings of a specific tool, it can make sense to try something else right now. It's the old adage about sharpening the saw. When a woodcutter feels so much pressure that they don't even take a few minutes out of their day for maintenance, they're in for a bad time. You need tools that are up for the job, there's no way around that.
|
There's also no way around getting the job done, though! As long as you have everything you need, ignore all those greener pastures, and ship that thing.
|
That being said, we have to keep up with the times, too, right? So how do we reconcile the need to evaluate alternative, more modern approaches with our responsibility to deliver results? A good way to avoid succumbing to distraction at the wrong time is to give it space in a controlled manner. You know how it is with "all work and no play". It's important to give ourselves space to explore, to tinker, to satisfy our curiosity. Why should this principle only apply to children? Setting aside an hour for intentional fiddling every so often might help avoid losing multiple hours to uncontrolled procrastination.
|
Even if your current tooling is satisfactory, it can be reasonable to upgrade it, provided you are confident that it'll pay off in a way that benefits your job. One such case is when the new tool will provide you with features that your current one is missing, and —now that's important— that will enable you to meet your objectives in a more efficient way. For example, getting early feedback from a language server while you're editing code can improve your efficiency compared to only finding issues after running tests or triggering a CI pipeline.
|
Finally, let me take a completely different viewpoint and tell you that you should not get too attached to your tools in the first place. Focusing too much on tools can be detrimental. For people who aren't keyboard warriors like us, even deadly. During their training, firefighters run an obstacle course; first with their gear, then without it. Afterwards, they're told: "Look, you're much faster without your tools." What sounds silly and obvious is actually a very important psychological lesson. You see, mastering the handling and application of their tools is an essential part of a firefighter's job. They become an extension of their bodies. Throughout history, this had the unintended consequence that firefighters died in unexpected situations because they kept doing what was their expertise: using their tools. The right thing to do, however, would have been to drop their gear and run. Because that option didn't even cross their mind, they perished. Their belief in the power of their tools led them astray. They didn't realize that the usual approach wasn't valid any longer. That's why modern training methods teach them that a firefighter without tools is still a firefighter, and hopefully one who lives to experience their retirement.
|
|
Next time you're confronted with a problem for which you can't find a solution using your familiar tools, consider of there's an approach that doesn't involve them. An engineer without their DevOps tools is still an engineer. Maybe even more so.
|
|
|
|
|
Do you find my content helpful?
If so, please consider signing up for a membership in The Server Room! The BRONZE membership level will give you access to my community of DevOps practitioners. At the SILVER level, you can also take part in various community events. And with a GOLD membership, you get to attend my courses at no additional cost!
|
A membership in The Server Room is much more than just a gesture of appreciation.
It is an investment into your own growth.
|
|
|
|
|
|
|
Always update the BIOS first
|
|
Today, I spent hours trying to install Bluefin on an older laptop. The process always failed with Failed to write boot loader configuration. I tried vanilla Fedora Silverblue and ended up with the same disappointing result. Following a tip I found on the Bluefin Discord, I finally tried installing Fedora Workstation, and was able to do so successfully. Right after …
|
|
|
|
|
|
|
|
A rocky but encouraging start with Rails credentials
|
|
For the biggest part of this week, I've been working on upgrading the Rails versions of our managed hosting dashboard application. I started with Rails 6.0, and now I'm at Rails 7.1. Today, I struggled for a long time with deploying to the staging instance on Heroku. At the centre of my issues was that I had started using Rails …
|
|
|
|
|
|
|
|
Flatpak saved my live stream
|
|
|
|
I hope that the effort required for switching from X11 to Wayland will be worth it. I just spent my whole Sunday rebuilding my livestreaming setup. A little bit of background: For sending my camera and desktop video to Twitch and YouTube, I use the popular Open Broadcaster Software. Since I'm running an atomic Linux distribution, I had to find …
|
|
|
|
|
|
|
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!
|
|
|
I'd love it if my writing could reach more people like you. Does someone come to mind? Forward them this newsletter and suggest they subscribe themselves!
|
|
Jochen, the Monospace Mentor
|
|
    
|
|
|
|
