|
|
|
|
|
In this second issue of News From the Server Room, I'll answer the question if you have to work 80 hours a week to get good. I'll tell you about the launch of my DevOps community, and leave you with a bunch of good reading recommendations.
|
|
|
|
|
Mentor Monologue
|
I'm not exaggerating when I say I was shocked by a question from a viewer on one of my recent office hour live streams: "So I heard from a developer that he would code and learn for like 80 hours a week when he started in order to be come an amazing engineer. I can barely do 8 hours a day and I want to be an amazing engineer. Advice on that?"
|
Here's the TL;DR: Working 80 hours a week is neither healthy nor effective. I'd go as far as to saying it's impossible. Sitting in front of a screen for 80 hours? Yeah, maybe, if that's your thing. But doing actual work for 80 hours? You might very well be fooling yourself, but you're not fooling me.
|
Now, before we get into how many hours of work per week you really should invest into your growth, let's first consider the side effects of spending 80 hours a week, that is 16 hours every weekday or more than 11 hours every single day, working on your engineering career. Even if we count the necessities like eating and pooping as part of work time, it'll still leave only between 8 and 12 hours per day for the non-work parts of your life like, you know, hobbies, social life and sleep. And it's scientifically proven that for most people, any amount of sleep below 7 hours a night is not enough for their physical and mental recovery. In other words, if you sacrifice sleep for other things for more than a very short time, you're going to ruin your health. Let's see how not only your career but your whole life flourishes while you're dealing with the consequences of burnout (or falling asleep driving your car).
|
Total work time also has severely diminishing returns; in other words, putting in more and more time will yield less and less additional results. Effective work requires effective rest. Why do you think Ford and his fellow industrialists themselves introduced the 40-hour work week? And that was just about physical work. Every athlete knows that muscle growth doesn't benefit from endless training; there needs to be downtime during which the body can recuperate and grow to meet demand. For our brain, it's similar, but it's even more limited in how long it can work at high performance. For knowledge workers, an 8-hour day is like a 16-hour day for the industrial labourer. It's just not possible to keep your focus for that long, not only because people keep interrupting you, but also for physiological reasons. The brain needs time and rest to build new tissue such as the myelin that grows around neurons.
|
There's also the aspect of how much you can even achieve on your own. There's that story of someone who shipwrecked on an island with just a chess board, and ten years later returned as a grand master. That's bullshit, because you need other people to beat the Dunning/Kruger effect, i.e. you don't know what you don't know. The only way to find the solutions that your brain couldn't come up with by itself is collaboration. Grand masters learn from other grand masters, amazing engineers learn from other amazing engineers. That's why I'm so excited about The Server Room, the community of DevOps practitioners I'm going to launch soon.
|
The good news is that success is not about the total time you spend working at all. Rather, it's about how much focus time you can get in. In his book "Deep Work", Cal Newport explains how he manages to thrive as a busy author and academic: "Three to four hours a day, five days a week, of uninterrupted and carefully directed concentration, it turns out, can produce a lot of valuable output." Just 15 to 20 hours of focused work will do the trick, and still leave plenty of time that you can spend schmoozing and snoozing.
|
|
Please don't blindly believe those tech bros who tout how they built their success on relentless work. Even if there's a kernel of truth to their claims, what they don't tell you is that they also had the means to mitigate the many negative consequences of their self-abuse. Instead, I recommend that you read the book "Time Off: A Practical Guide to Building Your Rest Ethic and Finding Success Without the Stress". It's full of good advice on how to make continuous progress in a sustainable way.
|
|
Changelog
|
In my Mentor Monologue above, I mentioned The Server Room. That's the name of the DevOps membership community I'm in the process of launching. My goal for TSR is to build a long-term community of DevOps practitioners who help each other grow. Truth be told, my to-do list for the launch is still pretty long. For example, I'm in the process of integrating the community platform, based on the open source forum software Discourse, with the Monospace Mentor website. I'm also going to create a bunch of initial seed content. For that reason, I don't expect the launch to happen until early April.
|
Running a community at the level of quality I'm envisioning needs to be sustainable, which is why access to TSR will require a paid membership. For the launch, I'm going to give away 20 "founder" memberships at a 50% lifetime discount. All you have to do to is to subscribe to the launch waiting list, and you'll get the discount code via email when The Server Room finally opens.
|
|
You can learn more about the many benefits you'll get from a TSR membership on my website, which is also where you can sign up for the launch waiting list. Don't miss your founder discount!
|
|
|
|
|
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.
|
|
|
|
|
Do you feel trapped in your current work situation? Are you unmotivated and apathetic towards projects and deadlines? You may be dealing with emotional exhaustion.
|
|
In this article, Ann-Laure Le Cunff highlights a state that I call "The Big Meh", when suddenly you can't find the motivation or energy to do things that you enjoyed before. The article also has a few easy tips how to recharge your emotional batteries.
|
Even though I'm more into the practical side of things, sometimes I do enjoy a bit of computer science. Network topologies, follower relationships, Git commit history — these are all graphs. Even though graphs as a data model are well understood mathematically, programming languages don't seem to support them in any substantial way. By interviewing a bunch of competent people, Hillel Wayne finds plausible reasons why.
|
With even Microsoft announcing a Windows version of sudo, the venerable authorization tool seems to have a bright future. But maybe it shouldn't?
|
|
Deadlines often are as arbitrary as the estimates they're based upon. In my team, we've long abandoned them because instead of progress, they just created pressure. In this article, Eric Elliott proposes a demo-driven workflow instead.
|
|
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!
|
|
Jochen, the Monospace Mentor
|
|
|
|
|