20. Multi-vitamins and Two-way Doors

Karen Catlin on Retaining WIT, Jonathan Cutrell on Maintainable, Dr. Aneika L. Simmons on Hanselminutes, Sarah Wells on Engineering Culture by InfoQ, and Dave Thomas and Andy Hunt on Tech Done Right by Table XI. I’d love for you to email me with any comments about the show or any suggestions for podcasts I might want to feature. Email [email protected]. And, if you haven’t done it already, don’t forget to hit the subscribe button, and if you like the show, please tell a friend or co-worker who might be interested. This episode covers the five podcast episodes I found most interesting and wanted to share links to during the two week period starting September 16, 2019. These podcast episodes may have been released much earlier, but this was the fortnight when I started sharing links to them to my social network followers. KAREN CATLIN ON RETAINING WIT The Retaining WIT podcast featured Karen Catlin with hosts Jossie Haines and Jordanna Kwok. Karen, who is a leadership coach and diversity advocate, got interested in tech when she saw an issue of Money magazine with a cover story about successful women with computer science backgrounds and her father pointed out the connection between a career in software and Karen’s love of crafting, puzzle-solving, and mathematics. She started her career in 1985, which was a peak year for women in Computer Science. In that year, 37% of the Computer Science degrees went to women. It dropped to a low of 17% but has started to go up again in recent years. Karen started a coaching practice because she wanted to help women who wanted to grow their careers and stay in tech. She soon realized that, even if she could be the most amazing coach on the planet, her clients would still be facing an uphill battle because they were working in companies that were not the meritocracies they claimed to be. This led Karen to explore an idea: “Instead of trying to fix the women, let’s start fixing the men.” She says there is a role for every man who is working in tech to create a more inclusive workplace on his work team and at his company. Karen says that mentoring programs are a great opportunity for people to pass on advice to someone who hasn’t had the same amount of experience, but there is a trap: studies have shown that most of us mentor people who remind us of our younger self. Karen’s advice is, if you’re doing mentoring, mentor someone who doesn’t look like you. Don’t have a mini-me protégé. Another piece of advice from Karen is to pay attention in meetings. Look out for interruptions. There is research showing that men interrupt women much more than the reverse and that women who are getting interrupted tend to step back and not participate in the rest of the meeting or future meetings. So, when you see people getting interrupted, say something like, “Jordanna was making a great point. I’d like to hear more about that.” Another thing to watch for is what Karen calls “bro-propriation”: a woman says something in a meeting that falls flat and then, later on in the same meeting, a man says the same thing and gets all the credit. An ally can say something like, “Hey, I see that you agree with the point that May was making earlier.” Discussing hiring, Karen says she used to grab old job descriptions and add new requirements to them, reasoning that all the old requirements are still relevant. She says that you should instead try to get your job description down to just five requirements. Research has shown that women apply for jobs when they have all the skills listed in the job description while men apply even if they have little more than half of the listed skills. Karen also says to have objective criteria to use for every single candidate. Ideally, use the same interview questions. She told a story about moving to Silicon Valley with her partner Tim and applying to work at the same company in the same software engineering role. The two of them had interviews the same day. Driving home at the end of the day, Tim related to Karen that his interviews were among the most difficult he had ever had while her own experience was that the interviews had all been easy. The interviewers had dumbed down the questions when interviewing her. They were both offered jobs, but she decided not to take her offer because the company didn’t respect her enough to ask her the same difficult questions they had asked men applying for the same position. She then spoke about the importance of public speaking in gaining visibility and how it can help with both recruiting in the case of giving external talks and with getting your ideas considered.  Apple Podcasts link: https://podcasts.apple.com/ca/podcast/karen-catlin-on-being-better-allies/id1458996260?i=1000440710563 Website link: https://www.retainingwit.com/karen-catlin JONATHAN CUTRELL ON MAINTAINABLE The Maintainable podcast featured Jonathan Cutrell with host Robby Russell. Jonathan is the host of the Developer Tea podcast and is a senior engineer at Clearbit. Robby asked Jonathan what he thinks are the characteristics of a healthy and maintainable codebase. Jonathan says testing and having a consistent way of testing is critical to maintainability. He also looks at the size of each concept the code expresses to see if it can fit in a person’s head. Robby asked how Jonathan’s teams have achieved consistent testing. Jonathan says that human beings are pretty good at being about 90% consistent, which is almost worse than being 0% consistent. He says to take the load off the human engineer and, for those times when you still need to put the load on them, have a way to proceduralize things such as by having a checklist or template. Robby asked what Jonathan thinks developers often get wrong when they talk about technical debt. Jonathan says that debt is an easy term to throw around because, in the financial sense, it is a very clear concept. Technical debt does not have so clear a definition. You need to evaluate what your team cares about and what has been costly from a business perspective. Some things that we may think are debt are just emotionally difficult to accept: code that we wish was different but isn’t actually causing any real problems or even forecasted to cause problems. One factor that Jonathan thinks should be consistently considered technical debt is code that is staying around but for which you don’t have any kind of validation.  I liked Jonathan’s metaphor for attempting to refactor code that is not under a lot of churn. Picking up code that isn’t changing much and improving its design, he says is like paying off low-interest mortgage debt. There are probably better places to expend our effort. Developers tend to treat decisions around technical debt like one would treat the decision to clean up your house. You have the sense of ownership over your home and, regardless of whether there is risk of future problems, we feel the need to clean things up. They talked about why Jonathan started the Developer Tea podcast. Jonathan wanted a podcast that he could listen to on an afternoon walk for five to ten minutes and learn something new. Most podcasts at the time were much longer and more entertainment-driven, and he wanted something that focused on the more human aspects of the job in a short, inspirational form. He says that the podcast has been one of the most rewarding things he has done in his career. The most rewarding experiences have been when people send him emails about how an episode or series of episodes have shifted the way they think about a topic or even about how they think about their career. They talked about whether there is a correlation between healthy code and healthy teams. Jonathan says there is data around teams in general that says teams that good relationships with their manager and the people they work with have the highest performance and the lowest turnover. These good team dynamics have visible effects on the code. Strong teams, Jonathan says, eradicate fear. These fears are things like fearing that someone is going to judge you poorly when they look at your code. Second, the best teams also know how to come up with the best ideas, which involves one or more team members being able to give up their own idea without attaching a sense of failure to letting that idea go. Third, members of strong teams recognize the humanity of everyone on their team. Robby asked what developers get wrong when evaluating their peers. Jonathan says that people, in general, tend to see everyone around them as inadequate as a way to containerize the rest of the world. This bias helps us to make decisions without being riddled with anxiety about them. The downside of this shows up when we are tasked with evaluating another person. This feeling that everyone else is inadequate combines in a bad way with our natural loss aversion when we try to make sense of things. Most failures are the result of factors that could not be controlled or predicted. With hindsight, when a project is late, we try to think of why it was late and we often come up with a reason, rightly or wrongly. We don’t often come to the conclusion that the project failed because something random happened. As a result, performance reviews tend towards the negative side unless we actively bias away from that. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/jonathan-cutrell-healthy-teams-know-how-to-eradicate-fear/id1459893010?i=1000447238745 Website link: https://maintainable.fm/episodes/jonathan-cutrell-healthy-teams-know-how-to-eradicate-fear-LgRTt32R DR. ANEIKA L. SIMMONS ON HANSELMINUTES The Hanselminutes podcast featured Dr. Aneika L. Simmons with host Scott Hanselman. Scott asked Aneika about the talk she gave with her husband Anjuan, “Managing The Burnout Burndown” at the Lead Dev conference: https://www.youtube.com/watch?v=e2dgOfedI3A. She talked about burnout having multiple dimensions including emotional exhaustion and depersonalization. When you are burned out, the people you work with start to lose, in your eyes, their personhood. Scott asked about how having a culture that depersonalized employees, such as by referring to them as “resources”, might lead to burnout. Aneika talked about how having a culture that values the highly-engaged software developer counter-intuitively increases rather than decreases burnout. She talked about managing burnout with the help of your relationships. When Aneika is looking burned out, Anjuan will often say, “Aneika, let’s go for a walk.” She talked about the American notion of the “protestant work ethic” and how the work itself is valued and makes the worker feel important and gives them a sense of meaning. Those that are not working are made to feel like they are not contributing. Scott connected this to how many Americans do not take all of their vacation days. Aneika talked about the difficulty of achieving work-life balance when pleasing your boss means disappointing your family and vice versa and she described how stress is the cause of many illnesses, telling her own story about getting a sore jaw while working on her dissertation because the stress caused her to start grinding her teeth. Aneika suggested building relationships with your boss and your team so that they see you as a person and not just as a contributor. When they see you as a person, they are less likely to attempt to make you feel small when you need to take time for yourself. Here's Aneika on the relationship between engagement and burnout. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/managing-the-burnout-burndown-with-dr-aneika-simmons/id117488860?i=1000447003518 Website link: https://hanselminutes.simplecast.com/episodes/managing-the-burnout-burndown-with-dr-aneika-simmons-1caMsclq SARAH WELLS ON ENGINEERING CULTURE BY INFOQ The Engineering Culture by InfoQ podcast featured Sarah Wells with host Shane Hastie. Sarah is the technical director of operations and reliability at The Financial Times. When Sarah joined FT in 2011, the company was full of smart people, but they were hampered by a frustrating set of processes. During the last eight years, they adopted a DevOps culture with a focus on automation. When she joined, it took an average of 120 days to provision a new server. They stopped tracking the improvement when they got it down to minutes. They moved from 12 releases a year to many thousand releases a year. This required pushing decision-making down to the individuals making the changes. Shane asked about how to achieve a culture of safety and experimentation. Sarah says it has to come down from the top. You cannot have a CIO or CTO is saying, “What went wrong? Who did this?” You optimize for the speed of release and for speed of fixing. You do incident reviews, but their goal is to improve things for next time, not lay blame. If you drop a database in production as a developer, that is not your fault. The fault is that it is too easy to do that. Shane asked what a culture of experimentation looks like at “the coal face.” Sarah referenced Linda Rising in saying that it is not an experiment if there is not a hypothesis and if it can’t fail. As soon as something costs a certain amount of money, very few organizations are willing to write it off, so if you’re going to experiment, it has to be something cheap and quick. Sarah gave an example of an experiment to test a design change in which they would show the star-rating on the list of film reviews. The thinking was that this would increase engagement. The experiment showed that engagement went down instead because people were less likely to click to see the full review once they had the star-rating. Shane asked about how Sarah limits the blast radius of changes. Sarah says that by releasing small amounts of code frequently and having an architecture like micro-services to keep components extremely decoupled, you are better able to understand the code you are releasing and the change is localized and less likely to affect distant parts of the product. You can also design your website to have graceful degradation when a particular service is not returning results. Shane asked about Sarah’s preference to buy rather than build. Sarah referenced Simon Wardley’s value-chain mapping and establishing the core thing a business does. For FT, the core business is news, so something like doing their own container orchestration is not part of that. Originally, they did their own container orchestration, but once Kubernetes was available, they moved to it. In discussing the sunk cost fallacy, Sarah says you always have to fight to invest in the technical stuff, so you need a good relationship between the tech leads and the product people to explain the benefits of particular technical decisions. You also need to accept that things change and you won’t always get it right. The flip side of moving fast is that sometimes you get it wrong. She related a quote from Jeff Bezos in a letter to shareholders about one-way door and two-way door decisions. For decisions that are likely a one-way door, invest time in getting them right, but for most decisions, you should just decide, commit, and revisit. Shane asked how the listeners who are working on monoliths that release once a month can get to where FT is at today. Sarah says that you need a continuous delivery pipeline so it takes no time at all to get a release out. The second thing is architectural changes. Get to zero-downtime deployments. The cultural aspects are things like process. Reduce anything that requires permission from an external team. It has to be possible for a team to just get going. She referenced Accelerate by Forsgren about the research that says not to have change approval boards. Architects get embedded in the individual teams instead. You want your engineers to be T-shaped, having one specialty but also having some skill in all areas. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/sarah-wells-on-fts-transition-to-devops/id1161431874?i=1000446732957 Website link: https://soundcloud.com/infoq-engineering-culture/sarah-wells-on-fts-transition-to-devops DAVE THOMAS AND ANDY HUNT ON TECH DONE RIGHT The Tech Done Right podcast featured Dave Thomas and Andy Hunt with host Noel Rappin. I realize that this is the third time in as many weeks that I have included a podcast episode featuring Dave and Andy talking about the 20th anniversary of The Pragmatic Programmer, but they keep saying different and interesting things on each podcast they visit that I keep wanting to share it. In this podcast, Dave described what being pragmatic means to him. He says that being pragmatic means doing what works, but nobody knows what works. The cool thing about software, which is also the scary thing about software, is that we are constantly reinventing the entire field. Every project is new: it has new circumstances, new technologies, and new requirements. When you don't know what to do, being pragmatic means exploring as much as you can to find out what works, having in place a system of feedback to tell you whether it is working or not, and taking steps that are reversible so that, if you make a mistake, you can go back and fix it. This, Dave says, is the essence of the book. Noel added a fourth variable, the team, that is different every time, and asked what the pragmatic approach is for how a team works. Dave says that a team is a voluntary collection of individuals. You don’t have a team that you put people into; you start with a group of people and try to turn them into a team. The book dedicates a chapter to teams that echos the previous chapters on individuals because teams need to know all the things that individuals need to know: they need to realize that they are going to make mistakes, they need to figure out when they’ve made a mistake, and they need to know how to fix those mistakes and minimize them in the future. As a programmer, your job is not to write perfect code; your job is to create something that does what the customer wants. If there are bugs along the way, that is not an exception; it just the way it is. The same applies to teams. When teams adopt that approach, they lose the incentive to blame people for things and they take on collective ownership. Andy says that the one thing that is unique to teams is an underlying trust of each other member of the team. You are much better off with relatively small, stable teams. Every time you add someone to or remove someone from a team, it is a new team and you need to start over building relationships, building trust, and learning to work with each other. Noel asked how they would compare The Pragmatic Programmer with the Agile Manifesto since they were involved in the creation of both. Dave suggested thinking of Agile methodologies like XP as a roadmap and The Pragmatic Programmer as your car. Noel said that, in re-reading The Pragmatic Programmer, he was struck by the emphasis on taking small steps and “not getting in front of your headlights”. Andy says that is critical idea because we fall into the trap of taking on too much at once all the time. Small steps, Dave added, also mean you can more easily undo and you are less likely to fall victim to the sunk cost fallacy because your sunk costs are smaller. Noel asked if the way in which developers learn has changed in the last twenty years. In reference to books versus StackOverflow searches and watching videos, Dave made the point that the distinguishing aspect of a book is that the content is curated; putting it together was difficult; it took a long time for the author to organize their thinking to make it clear and approachable and to produce something authoritative and easy to read as a whole. Noel asked Dave about the pragmatic value of automated testing. Dave says that when he gets too comfortable doing something, he tries to stop using it so that he doesn’t get stuck in a rut and so that he doesn’t start to believe something religiously simply because he has been doing it a long time. He had been telling people for years that it is good to test and he had never done the experiment of not testing. He decided not to test for a period and was surprised by the result. He kept an eye on bug rates and it was just as buggy as ever, his productivity went up a little bit, and his designs were just as flexible as before. His explanation is that, having done the requisite ten thousand hours, it is now so ingrained that he doesn’t have to test to get the benefits of testing. He still feels that tests are useful when working with others and as a regression barrier. He sees his experiment with not testing as another example that nothing is sacred: if you’re truly being pragmatic, you should always be experimenting. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/episode-68-pragmatic-programmer-at-20-dave-thomas-andy/id1195695341?i=1000446898661 Website link: https://www.techdoneright.io/68 LINKS Ask questions, make comments, and let your voice be heard by emailing [email protected]. Twitter: https://twitter.com/thekguy LinkedIn: https://www.linkedin.com/in/keithmmcdonald/ Facebook: https://www.facebook.com/thekguypage Instagram: https://www.instagram.com/the_k_guy/ YouTube: https://www.youtube.com/c/TheKGuy Website: https://www.thekguy.com/ Intro/outro music: "waste time" by Vincent Augustus