This week we discussed Section 2.3.3 through the end of Chapter 2.
Section 2.4: Productivity in the Age of Hypergrowth
- If your company is growing, you essentially have a new company. Dennis is feeling this in his current role, and he may be considered one of the “old timers.”
- Geoff thought the idea of self-healing systems was interesting, where other people come to the rescue when there’s a problem. The author did say this was rare, though.
- We discussed the numbers around the overhead of bringing on new people. Jameson wondered where the author got these numbers, asking, “Isn’t it an ‘it depends’ issue?” Jamie said the State of DevOps Report, which is backed by research lines up well with the numbers claimed in the book. You might be less productive on planned work while you’re training somebody; however, it is the best work long-term because you’re a force multiplier.
- Most of us have had experiences with interviews where it takes more time than we’d expect. There’s prep work, the interview itself, and typically multiple debriefs. Dennis added that if you have multiple interviews in one day, your schedule gets so chopped up that you’re effectively useless between meetings.
- Your training process needs to be strong to onboard people efficiently. One trigger for starting documentation is when you change your routines from one thing to another. Jamie said that instructions (i.e., how to build and deploy) should ideally be automated.
- Documentation is usually the first thing to drop in a time crunch. We also shared experiences of where the senior developers were the ones that did the least documentation because they relied on internal knowledge and assumed other people shared that knowledge.
- Rewrites are fairly common. When the book talked about “systems” in 2.4.2, we think it means the technology and the people. Houston raised an issue with having to re-implement your systems twice every three years; this seems unsustainable. Geoff shared an aphorism from a previous team lead: “There’s never enough time to do it right; there’s always enough time to do it over.”
- Geoff asked Jamie how you architect something to not need significant rewrites. He said start with a monolith and then refactor. From Michael Feathers’ Working Effectively with Legacy Code, look for seams for where you’d tear something off and exchange it with something else. For example, you have a seam between your sleeve and the body of the shirt, meaning you could swap out the sleeve with another one without having to replace the entire shirt.
- Migrations between one system and the one to replace it cause major slow-downs.
- Conway’s Law — organizations build systems that mirror the communication structure of the org
- Jameson likened the idea of rotating people on/off interviewing roles to that same practice used in manufacturing. People train up on how to do other parts of the job, which keeps frustration and complacency at bay.
- We discussed hiring up on one team vs. hiring piecemeal and broadly. Jameson said that you may not be able to find suitable candidates to complete one team by your timeline. You may need to take what’s available.
- The book recommends using new-hire boot camps and recurring education classes as you grow.
- We all liked the idea of an ownership registry that outlines who owns what so that you don’t have to guess when you have a question.
- There was some lengthy discussion about hiring seniors vs. growing juniors and how we manage expectations when we hire.
- Cargo cult — when you think performing the rituals is what gets you the outcome
- Speaking of adopting technologies just because they’re new… Jamie said the other side of being on the bleeding edge is getting cut (e.g., not having a knowledge base when you get stuck, library suddenly gets no support, vendor gets acquired).
- “…the best solution to frequent interruptions I’ve seen is a culture of documentation, documentation reading, and a documentation search that actually works.” It’s harder to bootstrap a culture of documentation than a culture of unit testing.
- Regarding avoiding unnecessary rewrites, Geoff imagined that 1) people don’t intentionally architect systems incorrectly and, 2) if you design for scale first, then seemingly trivial tasks are almost incomprehensible because the system is so modular. This can also lead to premature optimization where you try to make your system as flexible as possible, but now it’s too generic to quickly grok.
- Having a single person as a gatekeeper (e.g., can’t commit to master unless the tech lead approves) is an antipattern. Having gates is still useful to keep you from making avoidable mistakes.
- Dennis had an actionable takeaway from this section: Block out time to focus so you can 1) avoid interruptions, and 2) build in slack for yourself.
Section 2.5: Where to Stash Your Organizational Risk?
- A common highlight for the group: “What I’ve found most successful is to identify a few areas to improve, ensure you’re making progress on those, and give yourself permission to do the rest poorly.” Do good enough. Jamie’s analogy: “Getting a 90 on a test is still an A just like getting 100 is an A.”
- “As an organizational leader, you’ll always have a portfolio of risk, and you’ll always be doing very badly at some things that are important to you. That’s not only okay, it’s unavoidable.”
- “You may be the best suited to manage the risk, but you’re almost certainly in the best position to take responsibility.” Jameson said this is a core concept from Extreme Ownership.
Section 2.6: Succession Planning
- Some people think succession planning is unimportant unless you’re near retirement. You need to think this through because it’s necessary not only to help you move out, but also to move up. If your manager puts you up for promotion, but it will take you a significant amount of time to train your replacement, you may lose that opportunity.
- Geoff has a reminder on his calendar each month to emend his job description to include new activities or responsibilities.
- Houston and Geoff worked together at a previous employer to craft an individual job description for Houston that included responsibilities beyond “implement features, fix bugs.”
- Jameson said writing out all the things you do is also useful for onboarding new people; they can understand your role more easily.
- We liked the idea of “go on vacation for 2-3 weeks and see what flops;” we’re not sure how many orgs would support this, though.