RLP's Computing Blog

Bootstrapping Your Way To Being An SRE

Article Info

  • Last Updated On January 9, 2023.
  • Originally Posted On September 27, 2018.
  • Posted in: psychology, sysadminning.

Recent Changes

About


DISCLAIMER: I AM NOT REPRESENTING ANY EMPLOYER, CURRENT OR FORMER, IN THIS DOCUMENT. IF YOU DO EVERYTHING HERE YOU STILL MIGHT NOT GET HIRED.

Introduction

I’ve had a lot of people ask me how to break in to the SRE end of the tech pool.

The career path for people wanting to be developers is fairly well understood these days, but the ops side of things is extremely opaque. Also, no-one teaches it formally in any serious way that I’ve ever heard of (feel free to email me if you have counter-examples, I’d love to hear about them!).

It’s basically an apprenticeship-driven field, which leaves total newbies out in the cold. And yet, I do in fact interview people who have never had an SRE job that I would be pleased to hire, and go through that apprenticeship process with them. This document attempts to describe the experiences and mindset that those people have, and how you can get that for yourself, if you actually want to do this sort of work.

Please note that people who enjoy this sort of work are rare, and you really don’t want to do this sort of work unless you enjoy it; you will, eventually, come to hate it, and then you’ll start being bad at it, and that’s no good for anyone. You can read my essay on tech worker natures for a long-form discussion of this (note that as of Oct 2018 it’s not actually done yet, but there’s a decent amount there).

Terminology

“Systems Administration” / “Sysadmin”, “DevOps”, and “SRE” all refer to the same basic thing, which is being responsible for the maintenance and operation of computers running a service of some kind for users. It may or may not (usually not) include responsibility for the service software itself. Where those terms vary is in how much time is spent directly manipulating systems (i.e. typing commands to change a system’s state) vs. writing automation and scripting to manage system state for you, vs. writing software that manages your automation and makes automation decisions for you. Sysadminning is more of the former and SRE is more of the latter, typically, but it varies wildly between teams, from “little or no time spent writing real, complex software” to “writing software is basically all we do”. Normal is somewhere in the middle, with an overall industry shift towards more software writing in the last few years.

Manipulation of systems is often referred to as “operations” or “operational work”, and a team that does more of it as “ops-heavy”. A team that does more code writing is often referred to as “dev-heavy”.

I will use the term “SRE” throughout this document, even when referring to operations work, mostly because it’s shorter to type.

It’s worth noting that even on teams with a heavy software focus, building software as an SRE isn’t typically a multi-month process the way it is on pure development teams. Again, there are certainly exceptions (the most notable being Google, which treats “SREs are developers” as something of a religion, or at least that’s how it appears from the outside).

My Basic Suggestion

Play with systems. Build your own. Hook them together. Draw pictures of the structures you build (one of the resumes that most impressed me was the one that came with a Gliffy (or something like it) diagram of a 3 tier systems architecture she’d been playing around with).

What systems to play with and how to do it is a bigger topic. Let me be lazy and point you to a few other people’s ideas, and then I’ll add some of my own.

Other People’s Writings And Resources

Blog Posts

The best discussion I’ve found on the topic of how to play with systems to level up your SREing from scratch is Getting Started in Systems Administration and Automation in a “DevOps” world. This is a great list of steps to take to get used to both the tools and the mindset.

It’s important to note that for someone who should be doing SRE work, more-or-less all the things suggested there are fun. Like, I personally don’t get a big kick out of playing with monitoring, but everything else on that list I’d play with for hours for fun on a weekend. If that’s not you, consider whether this is what you want to be doing.

Interested in becoming a Site Reliability Engineer? is a great post on the mindset behind dev-heavy SRE work. The first video, in particular, summarizes the SRE mindset really well. For the practical side, all the digitalocean tutorial links are fantastic.

Hacker Tools is maybe mildly off topic?, but seems to be a good lecture series on some of the basic tools you’ll need to know and use.

Books

The best book I’ve found for the general philosophy and mindset of this field is the two volumes of “The Practice of System and Network Administration” by Thomas Limoncelli (the third edition). (In fact, I buy copies for all of my subordinates.)

This is an absurd amount of reading, though, so I have a list of which parts I consider important in another section below.

Here are some other books people have recommended in this space; I’ve not read any of these myself:

Another book in this space I have read is Site Reliability Engineering: How Google Runs Production Systems. It was pretty good, but as a guide it’s only really helpful if you’re already a programmer, and frankly people who are fundamentally programmers are not what I want in an SRE anyway, although that’s certainly how Google does things.

Training Websites

Just found (Jan 2023) https://roadmap.sh/devops/ ; I’ve not played with it in any detail but it looks super neat.

I’ve heard some good things about the DevOps track at Linux Academy.

I’ve heard that the following online schools are good for learning Linux internals: Linux Academy, Pluralsight, Udemy.

I’ve personally hired several people from Holberton, because at least they have a DevOps track. Even so, it’s pretty weak, honestly, but it’s better than nothing.

Professional Organizations

I’m not a member of any of these myself, but I’ve heard good things about them:

More Of My Thoughts On What To Play With

Honestly, I don’t have a lot to add to the two blog posts I linked above on this topic, but I will say that I recommend building at least one ye olde LAMP stack for reasons that’ll become clear in the next section.

By this I mean a webserver, an application server to run an app you have chosen or written, and some kind of database back end. Then you can expand it out; add another web server, load balancing of some kind, add replication to the database server, add load balancing to the database backend, etc. Virtualization is really good these days; you can run a bunch of dockers on a cheap-ish system and connect them in complicated ways, so doing all this shouldn’t be too expensive.

Many of the suggestions from the blog posts above are along the same lines, or directly relate; setting up monitoring, for example, is a great idea.

While this is becoming a bit of a niche skill set, you can learn a lot by buying your own desktop system (or building it from parts), installing Linux on that directly, building your LAMP stack on that system, and running it out of your normal household internet (although some ISPs make this very difficult; also, you’ll probably want to do something like https://www.noip.com/free ). If you build from parts, you can make a decent server these days for under $500; https://pcpartpicker.com/ is good for this. Note that for a server you shouldn’t need more than $20 for a video card, or just use onboard video if your motherboard has it.

Taking something you’ve build on your own hardware and re-deploying it to a cloud system, or vice versa, will also teach you a great deal.

When you’ve done all that, see if you can get someone to break it for you. Find an experienced sysadmin, give them an account with root access, and have them break the system in some way. Go figure out how to fix it. (I might be willing to do this if you email me, but I’m very busy so no promises.)

How To Prove You Can Do The Work

Once you’ve done all the playing and hacking and you feel like you have some idea what you’re doing, you’re left with the harder task of trying to convince people that you can do the work, so they’ll hire you.

If you really have built multi-tiered systems with load balancing and monitoring and so on, and you understand what you did and can talk about it in detail, you will be fine once you get to the interview stage. I mean, any given company might not hire you for whatever reason, but someone will.

The trick is getting that far.

One thing that can be very effective, and is the reason that I suggested putting together a web-based system specifically, is to have a link from your resume to your running system that you’ve been playing with.

Make sure the link in your resume is actually clickable to get to your site, or you’ll look incompetent.

Embed a description of the system and how it works into the system itself, or have an obvious link to that info. Ideally with Gliffy-style diagrams. Or have a cover letter that describes the system with diagrams. Or both.

Other ideas:

Spend a bunch of time on Server Fault answering people’s questions. A high score there, prominently displayed on your resume, is likely to get hiring managers to take you seriously.

Spend time heavily involved in a large open source project that managers might have heard of. Become known in those communities for your excellent work. This is both a direct route to a job (as people in the community are likely to ask others in the community when they have a job opening) and something you can mention prominently on your resume; “I’ve had 15 PRs merged against Kubernetes mainline” is going to get just about any SRE hiring manager to at least phone screen you.

Resume/CV Suggestions

These suggestions are very much about what I want as a hiring manager. They may or may not help you with anyone else.

In the first stages of resume management, I might have several hundred to go through. All the standard resume advice, like “don’t talk about your objective, talk about what you can do for the company” is great when I’m actually reading your resume, but that’s stage 3, and you need to get there first.

I therefore recommend having two cover letters. The first should be 100 words or less, ideally much less, and should say what you can/want to do and what you’ve done that’s relevant. Example of what I might have done for this sort of thing 20 years ago, if I knew then what I know now:

My name is Robin, and I’m ready to be your next Linux Sysadmin. I love automation and reducing toil. I have been running web-facing Linux systems at home for about 3 years, including being entirely responsible for a couple of non-profit websites, including http://www.lojban.org/ , which I run out of my house with 90+% uptime. I am great with shell scripting, and comfortable in a wide variety of programming languages (Perl and C in paricular).

After that, have a normal cover letter as usual, for all the reasons everyone says; a Google search will be happy to tell you how to do this in great detail. I suggest specifically mentioning experience you have in technical problem solving, which is usually not well covered in a normal resume format. Mention specific technical problems you’ve solved in some detail, or link to a page where you mention such accomplishments. Make it clear that you have systems-level experience. Describe your personal projects. Link to directly to a web-based system you run, and do so prominently; if you have a complex web-based system you’re managing, that link should be very close to the top of your longer cover letter and should be visually striking (i.e. in a different color) and should work when people click on it. You should include such a link in your first cover letter, too, if you have one to give.

On the resume itself, please bold or otherwise highlight specific technologies you’ve worked with. When I’m in the initial resume scanning phase, it’s very helpful to have my eyes able to bounce around and find “Puppet” all nice and bold, and then I can read the rest of the sentence and see what you were doing at that job.

Consider throwing in a bit of color; have important words be green or red or blue or something. After 200 resumes, a bit of color is really nice. Just a bit, though.

A note on resume words used to describe technical experience, with programming languages as the specific example but this applies to anything:

  • “Familiar” means “I can FizzBuzz in this language whilst drunk”; if you can’t even do that, just don’t mention it, I don’t care. Unless it’s some absurdly rare skill that you’re proud of.
  • “Comfortable” means “If you hand me a thousand line library in this language that is not too terribly written, I’ll understand what it does in detail a couple of hours, and can easily proceed to modify and extend it”.
  • “Proficient” or “Skilled” is the same as “Comfortable” except it’ll take you more like 30 minutes and as you read you’ll have all sorts of snarky things to say about the code.
  • “Master” or anything like it means “Dear hiring manager, please find the person at your work that is most skilled in this language, and bring them to the interview to try to prove that I’m not actually as good as I think I am”1. Seriously, if you claim anything like mastery with a technology, expect to be attacked in the interview. If you can take it, though, this is itself a great way to win at your interviews. If you have skill bars, a full skill bar will have the same effect.

Pro-Tip: If you’ve been working with any non-trivial technology for less than 5 years and you claim mastery, I’m going to move on to the next resume because you’re clearly having a Dunning-Kruger problem.

Appendix: Sample Job Information

Below is parts of two letters that I sent out when trying to hire for an ops-heavy SRE group. You may find it useful for understanding more about how this sort of work works.

Some important things you should be aware of:

  • This email is going out to many people, so if you don’t follow the instructions, it might take us a long time to review your response!
  • Most SRE positions around here do not involve working on any customer-visible COMPANY products. We run the machines that run the web services; we don’t work on the web services ourselves, typically.
  • Most SRE positions around here do not, typically, involve writing new software. The coding we do is more about modifying and debugging extant software. There is definitely some programming involved, you do need to know how to write shell scripts and be able to script in at least one of Ruby, Python or Perl, but these are not developer positions.
  • In particular, despite the mention of Java below, my group is not hiring for Java developer positions. Some teams are supporting Java-based software, so familiarity with Java and JVM tuning is useful, but that’s not the same thing.
  • Almost all of our work is on Linux systems, and Linux experience is a requirement.
  • We love to see support experience (IT, helpdesk, that sort of thing); please mention if you have any.
  • If you have any direct experience with Linux systems administration, DevOps, or SRE work, please mention that.
  • There seems to have some confusion when I used the word “customers” in a previous mail. On most teams around here, your peers at COMPANY are the users of the systems you support. Very few of these jobs involve interacting directly with COMPANY customers.
  • An on-call rotation, or on-call schedule, means that, when you are on call, you will be paged in the middle of the night if the systems your team works on are having problems. It has nothing to do with time spent working on different teams.

Job Description:

TEAM is looking for Site Reliability Engineers to build and run the services that hundreds of millions of customers use every day. We are hiring high quality engineers with a diverse set of experiences and skill sets for positions on COMPANY’s public facing web properties & internal services. The best candidates will have both strong Linux / Systems expertise and demonstrated Software Development skills. Our customers count on us to provide extraordinary availability, scalability and security for services.

In this job you will be expected to do things like:

  • Collaborate effectively, in a friendly and professional fashion. On most teams, your peers at COMPANY are the users of the systems you support.
  • Manage system security, keeping security issues top of mind in all aspects of your work.
  • Automate repetitive systems management tasks (such as package installations, writing of configuration files, user management, that sort of thing) using any of a number of internal tools and configuration management systems. Most teams use Puppet in one form or another, although there are also teams that use Chef and Ansible. A drive to automate is at the core of what makes a great SRE!
  • Debug and modify tools and systems written languages like Ruby, Python, Bash (shell scripting), Go or Perl.
    • Many (but not all) teams are also looking for Java experience, and experience performance-tuning JVM applications.
    • On some teams you might write entirely new pieces of software to make your team’s job better, although for many teams new software is not a core part of the job.
  • Debug problems with Linux systems, or with the connections between them. Many of our teams do not use much virtualization, so knowledge of Linux internals is essential. Some knowledge of networking is also important.
  • Participate in an on-call schedule, the severity of which varies wildly by team.
  • Bring your best to internal technical discussions, trying to both learn and teach whenever you can so that we can make the best decisions in every situation. Great collaboration is a huge part of our work.

Day-To-Day For SREs:

(If you’re interested in the long-form version of this section, I recommend the two volumes of “The Practice of System and Network Administration (3rd Edition)” by Thomas Limoncelli.)

“Systems Administration” / “Sysadmin”, “DevOps”, and “SRE” all refer to the same basic thing, which is being responsible for the maintenance and operation of computers running a service of some kind for users. It may or may not include responsibility for the service software itself. Where those terms vary is in how much time is spent directly manipulating systems (i.e. typing commands to change a system’s state) vs. writing automation and scripting to manage system state for you, vs. writing software that manages your automation and makes automation decisions for you. Sysadminning is more of the former and SRE is more of the latter, typically, but it varies wildly between teams, from “little or no time spent writing real, complex software” to “writing software is basically all we do”. Normal is somewhere in the middle, with an overall industry shift towards more software writing in the last few years.

The main things a sysadmin needs are the ability to learn quickly, a desperate need to solve problems, and an intense desire to automate (that is: to make computers, instead of humans, do repetitive or well-understood work). Note that “automation” in this sense means things like automatically installing packages, writing config files, setting up users, that sort of thing. Test automation is a different, but related, set of skills. Both are necessary for most SRE roles, but there is usually a lot more systems automation than test automation.

The skills listed below aren’t necessarily skills we expect you to start with, but they are skills you need to be interested in developing.

On most teams around here, a significant chunk of work will be a longer term project (typically “longer term” is weeks to small numbers of months). This typically takes from a third to 80% of your time. Examples of projects:

  • Upgrading an entire fleet to a new version of some piece of software (Skills: Linux, Shell Scripting, Configuration Management (Puppet))
  • Building out systems in a new datacenter (Skills: Linux, Shell Scripting, Configuration Management (Puppet), Networking)
  • Creating a new internal tool, or adding a significant feature to an existing one (Skills: Automated Testing, Programming (typically Python, Ruby, Java or Perl))

The rest of your time will be smaller tasks performed as they come up. Note that for most SRE groups, your customers are other people within the company. Some examples:

  • Answering an internal support request (i.e. a customer needs help using a tool your team supports) (Skills: Team Knowledge, Friendliness, Teaching)
  • Adding a minor feature to a tool, typically by customer request (Skills: Programming (typically Python, Ruby, Java or Perl))
  • Debugging of various kinds:
    • systems-level problems, like a host that can’t boot or a network connection that can’t be made (Skills: Linux, Shell Scripting, Networking)
    • software problems, like a tool that crashes on valid input (Skills: Debugging/Problem Solving, Programming (typically Python, Ruby, Java or Perl))
    • performance problems, like a database that is unexpectedly slow under normal load (Skills: Debugging/Problem Solving, Linux, Knowledge of the software in question, Networking)
    • security problems, like a host that is running software it shouldn’t, or a tool that is allowing something unexpected (Skills: Debugging/Problem Solving, Linux, Security Analysis, Networking)
  • Teaching a customer about what tools you support and/or how to use them properly (Skills: Team Knowledge, Friendliness, Teaching)

Almost all SRE jobs have an on-call component. This means you’ll be part of a schedule, typically 1 week on and 3 or more weeks off, during which if something goes horribly wrong you will get alerted. The frequency with which you get alerted will vary wildly between teams, from “2-3 per week” to “5+ per night, plus a bunch during the day as well”. In the latter case, you will typically not be expected to produce other useful work when you are oncall. What happens when you get alerted might be things like: - The alert is a known false-positive, so you acknowledge it and go back to sleep. In a good SRE position, this will be followed by real work to make the false positive stop happening. - The alert has a known procedure executed with it, which you execute. In a good SRE position, all such alerts will eventually be automated away. - The alert is new and surprising. You will use your knowledge of the system in question and its software, as well as general Linux and Networking knowledge typically, to attempt to debug and resolve the problem. If you can’t, you’ll call other people to help. Such issues are usually resolved in an hour or so, but most long-time sysadmins can tell you of that one call that lasted 12+ hours.

Do you want to influence the tools and processes of hundreds of SREs who collectively manage tens of thousands of machines?

My team builds, maintains, and manages the back-end systems that are behind the back-end systems that are behind the biggest COMPANY services, such as [snip]. That wasn’t a typo; we build the systems that build the machines that run those services. We have direct influence over more than [lots of] bare metal boxes scattered all over the world, almost all running Linux (and almost all are OEL specifically). Our customers are back-end SREs, both for the services mentioned and several others. Our work typically starts when the system is racked and on the network, and ends when it’s ready to run user-facing software.

Exactly what you’ll end up doing in this role is extremely flexible, but here’s some things you should feel confident you could accomplish your first year:

  • You will have taken charge of one of our major systems, becoming the subject matter expert. These systems include, but our not limited to:
    • Our machine provisioning system (homegrown on top of Kickstart) and attendant low-level systems (i.e. DHCP and PXE troubleshooting)
    • Our software packaging and package distribution system (homegrown on top of mrepo and Jenkins)
    • Our login/directory system (aka LDAP)
    • Our monitoring and alerting system (entirely homegrown; alerting has a mild resemblance to Nagios) and making sure that all alerts are actionable
    • Our DNS system, which pulls data from our homegrown CMDB in extremely complex ways
    • Front-line support (we all do this, but having someone with that as their primary job is helpful)
  • You will have become known to our customers, and to your peers, for your expertise in your chosen area.
  • You will have kept a keen eye on security issues in every project you work on, and you will have contributed to improving security in the systems that were already in place.
  • You will have contributed great code to our configuration management system (Puppet on top of a homegrown CMDB) or any of our many automation systems (which are mostly Perl and Ruby, but also some Python and a bit of Go, and of course tons of shell scripting (Bash) to hold it together).
  • You will have become known to our customers, and to your peers, for your helpfulness, ability and willingness to teach and mentor others, and friendly demeanor.
  • You will have become known to our customers, and to your peers, for your expertise at debugging and fixing operational issues, such as problems with system configuration, system provisioning, and user access.
  • You will have successfully influenced people on other teams to adopt our tools, or improve their automation, or any number of other persuasions that will make their lives better and reduce toil.
  • You will have participated in our on-call schedule (which, honestly, is pretty light as these things go; maybe 3 off-hours events per week) and will have contributed to making it better and reducing the toil associated with it.
  • You will have actively participated in many, many discussions inside our team and with other teams designed to identify and pursue the best solutions to our automation and systems management problems. You will have brought to these discussions your strong opinions and respectful, collaborative attitude.
  • You might have also established a particularly strong relationship with a single other team, such as the monitoring team, the security design team, or one of the property SRE teams. This will have allowed you both to influence them more effectively in their pursuit of automation and toil reduction, and to keep the rest of our team apprised of upcoming initiatives that we need to know about.
  • You might have also taken on the challenge of writing an entirely new piece of automation, including customer-facing documentation, operational documentation, extensive automated testing, operational design, release and deployment. There’s not a lot of room in our environment for entirely new pieces of automation, though, so this doesn’t happen often.

Appendix: The Practice of System and Network Administration: The Good Parts

So I just finished both The Practice of System and Network Administration (3rd edition, just came out) and The Practice of Cloud System Administration, and thought I’d share.

The short version is: these books are absolutely essential for anyone in a sysadmin or DevOps role, and very important for any customer-facing developer that wants their stuff to not break (in that latter case, especially the Cloud book).

What surprises me most about them is that no-one made me read them. People recommended them at various points, but no-one actually said “You must read this it is a requirement of your job”. Having read them, this seems an absurd mistake, and I am in fact requiring my subordinates to read at least some of them.

This is by far the most comprehensive reading I’ve ever heard of on why we do what we do, and why it matters that we do it in particular ways.

The problem is that these books, especially the first one, are Giant Tomes(tm). Really very large. I have some advantages when it comes to reading giant books2, so I thought I’d share my thoughts on which parts are especially important and worth reading:

Essential Parts

Volume 1

Entirety of Part 1 (i.e. chap 1-4)

“Even Mirrored Disks Need Backups” — just before Section 15.2

9.1.3 Leveraging a CMDB

10.3 Configuration Management Database

Ch 22: We’re trying to do DR work as an org right now, so this is pretty essential.

Chapters 29-31. These are more important for philosophy, rather than specific steps. You might already know all of it, but maybe not, and it’s important to find out what you might not know.

Ch 47 is important.

Ch 49-52 are extremely important. 53 and 54 are important for managers.

Ch 55 and 56 are for when you are doing basically OK as a team and you want to go for being awesome.

Appendix A is a great index into tasks (i.e. “I’ve just found out I need to upgrade the OS on every host in 5 datacenters; now what?”)

Volume 2

All of part 1 except Ch 3 are direcly applicable, and basically boil down to “Here’s what modern service-oriented architectures look like”. If you’re simply being handed a solution and you don’t care why the architecture is the way it is, you can skip them, but for next-level sysadminning you’ll need to know this stuff.

Ch 7 & 8 are absolutely essential.

Ch 12 is essential.

Appendix B is a great history lesson

Other Extra-Good Bits

Volume 1

6.1.3 Product Line Selection (just a page or so)

Chap 13 - Server Hardware Strategies

Chap 14 - Server Hardware Features (less important)

15.1 - Server Models and Product Lines

Chapter 7 is not all directly applicable, but several parts of it are foundational and it’s not easy to point to the good parts, so, the whole thing.

Chapter 8: Intro, 8.1, you can skip 8.2 as it boils down to “automate your OS installation”, 8.3, 8.4

Managers should probably read Chapter 12

Ch 16: Intro, 16.1, 16.6 ; 16.7 is a fun read but not important for us

16 and 17 are needed if you’re building a new service

17.4.3 Dependency Alignment

17.5 Decoupling Hostname from Service Name

17.6 Support

Ch 18: All, although I ignored the details of the math myself

Ch 19: Only if launching a new service or rebuilding an old service pretty much completely. This definitely had influence on the Puppet 4 process.

Everything in Part 4: Services is worth reading, I’m just calling out the most important bits.

Ch 21: Again, this had a considerable influence on the Puppet 4 process

Ch 23 and 24 are great if you need to brush up on your networking.

Ch 25 and 26 are great if you want insight into what GDCS needs to put up with. :)

Ch 27 & 28: Worth reading if you do a lot of customer-facing work. It’s more useful for the attitude than for direct applicability because it’s about helpdesks, but still worth it.

Ch 33 is good for how to identify all the parts of something you’re gonig to upgrade and be sure you hit everything

Ch 36 is good for deciding how centralized a particular service should be

Ch 38: All except 38.2, 38.4.1 (SNMP)

Ch 43 is generally useful if you’re directly managing storage. 43.3.3 is important.

Ch 44 is important if you directly manage non-trivial backups, especially to tape.

Ch 45 is essential for my team; not so much if you’re not managing software repos.

Ch 46 is important and not very long, although it may be a bit basic for some of you.

Volume 2

Ch 3 if you’re trying to choose between managing your own systems or using something like PIE or other internal cloud-like solutions.

Ch 9 and 10 are important if you are part of a release management team (i.e. if you deploy in-house software, which my team is unusual in not doing)

Ch 11 is important if you need to know how to upgrade live services in place. The concept of a flag flip is especially interesting.

Ch 14 is important if you’re not happy with your oncall process.

Ch 15 is important if you’d like your systems to fail less.

Ch 16 is somewhat redundant with the monitoring bits in vol 1, but more formalized.

Ch 17 is only relevant if you run your own monitoring.

Ch 18 is important for everyone at my work given that we now have an official lead time of 6 months on new computers.

Ch 19 is about how to measure your awesome.

Ch 20 is about how to increase your awesome; it’s redundant with 55 and 56 from vol 1

  1. I really wish I could have come up with an excuse to interview the person who claimed Haskell mastery on their resume, because that’s the language I use for hacking projects at home and never in a million years would I claim mastery. That would have been either really enlightening or, more likely, really entertaining. At their expense. (Any urge I might have ever had to claim mastery at Haskell was utterly destroyed by Typing The Technical Interview, which I can follow basically none of).↩

  2. I read books using text-to-speech while I do chores. It is possible to carefully ramp up your speed over time this way, to the point where I now read at 400wpm whilst doing other things, so a slow day for me is 20,000 words of reading. This has been super awesome and I highly recommend trying it out.↩