33. Making The World’s Best Pencil

Chris Ferdinandi on Greater Than Code, Ben Orenstein on Maintainable, Susan Rice on Coaching For Leaders, Courtland Allen on Software Engineering Unlocked, and Matt Stratton on Hired Thought. 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 March 16, 2020. 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. CHRIS FERDINANDI ON GREATER THAN CODE The Greater Than Code podcast featured Chris Ferdinandi with hosts Rein Henrichs and Jacob Stoebel. Chris is a proponent of plain vanilla JavaScript. He says that modern web development has grown so much in scope and complexity that it makes it difficult for beginners to get started and it can negatively impact the performance of the web for users in ways that developers with fast machines don’t always feel. One of the reasons things are the way they are today, Chris says, is because a lot of backend developers migrated to the front end because that was where the exciting stuff was happening and they brought with them their approaches and best practices. The front end, however, is a very different medium. In the back end, you have control over how fast the server is, when things run, the operating system, etc. On the front end, you have none of this. People are accessing what we build on a variety of devices that may or may not be able to handle the data we’re sending and may have unpredictable internet connections. If a file fails to download or the user goes through a train tunnel and we’ve built things in a modern JavaScript-heavy way, the whole house of cards falls apart on these users. Chris would like people not to abandon JavaScript altogether, but to be a little more thoughtful about how we use it. Modern web development involves a few things: frameworks, package managers, and doing more and more things (such as CSS) in JavaScript. All of this JavaScript has the effect of slowing down performance because 100KB of JavaScript is not the same as 100KB of CSS, a JPEG, or HTML because the browser needs to parse and interpret it. Because of these performance problems, single page apps have become more popular. But now you’re recreating in JavaScript all the things the browser gave you out of the box like routing, shifting focus, and handling forward and back buttons. You’re solving performance problems created by JavaScript with even more JavaScript, which is the most fragile part of the stack because it doesn’t fail gracefully. If a browser encounters an HTML element it doesn’t recognize, it just treats it as a div and moves on. If you have a CSS property you mis-typed, the browser ignores it. But if you mistype a variable in JavaScript, the whole thing falls apart and anything that comes after that never happens.  For Chris, a better approach to web development is one that is more lean and more narrowly-focused on just the things you need. His first principle is to embrace the platform. For example, a lot of people don’t realize that DOM manipulation that used to be really hard years ago is really easy these days in vanilla JavaScript. Also, many of the things that JavaScript was required for in the past can be done more efficiently today with HTML and CSS. He also says that we need to remember that the web is for everyone. Because we are often using high-end computers, the latest mobile devices, and fast internet connections, we forget that this is not the experience for a majority of web users. We build things that work fine on our machines but are painfully slow for the people who actually use the things we build. They ended their discussion with reflections. Chris’s reflection was about learning JavaScript and web development for the first time. He says that people learning shouldn’t be made to feel like they need to dive in to the latest trends, but should instead find a way to learn the fundamentals. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/170-the-case-for-vanilla-javascript-with-chris-ferdinandi/id1163023878?i=1000466076138 Website link: https://www.greaterthancode.com/the-case-for-vanilla-javascript BEN ORENSTEIN ON MAINTAINABLE The Maintainable podcast featured Ben Orenstein with host Robby Russell. Ben believes that, in a maintainable codebase, the code should match how you think about the world. When speaking about the domain with your teammates, do you use the same terminology that the code uses? Do you use the term “user” but the code uses the term “customer”? Getting your terms consistent is a specific case of a more general principle of implicit and explicit knowledge. Maintainable systems have as much knowledge put into them as possible so that they become sources of truth. Ben’s definition of technical debt is a technical shortcut you took intentionally after weighing it against alternatives and deciding it was worth it in the short team with the eventual intention of eliminating it. He says it is hard to get time on a schedule dedicated to cleaning up technical debt, so it is your professional responsibility to clean it up as you go. Ben says that asking permission to clean up technical debt as you deliver a feature is like asking permission to do your job well. He says that the idea of “We’ll go fix this later” never happens and, if you don’t believe him, grep your codebase for the string “TODO”. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/ben-orenstein-someday-well-go-clean-that-up-doesnt-work/id1459893010?i=1000466511242 Website link: https://maintainable.fm/episodes/ben-orenstein-someday-well-go-clean-that-up-doesnt-work-_fGCpf6F SUSAN RICE ON COACHING FOR LEADERS The Coaching For Leaders podcast featured Susan Rice with host Dave Stachowiak. From the time she was seven, Susan would hear her parents fighting loudly and violently when she was trying to sleep at night. When the fighting got scary and out of control, Susan would step in. Sometimes that meant talking them down and sometimes that meant separating them. The mediation she did with her parents taught her how to interact with parties who were intractably opposed. This developed in her a lack of discomfort with conflict, disagreement, and argument. She said that this helped her to be willing to stand up and not be conflict-averse. This reminded me of the Buster Benson episode of Lead From The Heart I summarized in my last article. Dave asked Susan about a section of her book Tough Love in which she described some feedback she received from former congressman Howard Wolpe when she was Assistant Secretary of State. He warned her bluntly that she would fail as Assistant Secretary if she did not correct course and she came to agree with that. She was only thirty-two at the time and had never held a position like this before. In 1998, six months into her tenure, a series of crises hit. Africa’s “first world war” broke out and, then in August of 1998, Al Qaida attacked the American embassies in Kenya and Tanzania, killing twelve Americans and over two hundred Kenyans and Tanzanians. This was both a horrific loss and a policy blow for those who were working on Africa at the time. Rather than addressing the pain they were all feeling head on, her approach to dealing with it was to charge through it as she did her parent’s divorce. This wasn’t a leadership style that would work in that context and Howard Wolpe gave her the tough love she needed at the time. Over the Christmas holiday, she reflected on what he had told her and realized that he was right. She had to be more patient. She had to be more respectful and solicitous of other people’s views and perspectives. Dave asked what she did first to make this change in her leadership style. Susan says she started by being more humble. She brought people into decision-making even if their recommendations were not ones that she ultimately accepted. She says, ”You can get a long way leading a team, even if many members of the team don’t actually agree with the direction you’re steering towards, if they feel that their advice, perspective, recommendations have truly been heard and appreciated.” Dave asked how she ensures in meetings between high ranking officials that everyone is genuinely heard even when she doesn’t agree with everything they are saying. She says it is not just what happens when you’re sitting around the meeting table. It comes down to the preparations going into the discussion: the quality of the paper that lays out the issues and the actions and the coherence of the agenda. Managing the meeting, though, is the hardest part. You have to make sure the options are given due consideration and everybody gets a chance to express their judgment. Apple Podcasts link: https://podcasts.apple.com/us/podcast/456-how-to-be-diplomatic-with-susan-rice/id458827716?i=1000466472793 Website link: https://coachingforleaders.com/podcast/be-diplomatic-susan-rice/ COURTLAND ALLEN ON SOFTWARE ENGINEERING UNLOCKED The Software Engineering Unlocked podcast featured Courtland Allen, founder of the Indie Hackers podcast and community with host Dr. Michaela Greiler. Michaela asked Courtland what was different about Indie Hackers compared to the earlier startups he had founded that made for its success. He said that for Indie Hackers, his notion of a business idea changed. Back in 2009, if you asked him about a business idea, he would have described a product idea and wouldn’t have been able to say much about how to get the product in customer’s hands, how much to charge for it, or even who the customer was. With Indie Hackers, he was thinking about all aspects of the business. She asked whether the original Indie Hackers idea was to build a community. Courtland said that while there was no desire to do a podcast at first, he always had a plan to build a community. He had multiple phases for Indie Hackers to go through to get to where he wanted it to be. Phase one was a blog where people who wanted to earn financial and creative freedom though revenue-generating side projects could go to find interviews Courtland had done with people like themselves. He figured these blog readers would subscribe to his newsletter and from there he would build a community forum where people could help each other. Somewhere along the line, the podcast was added based on community demand. Michaela asked how Courtland managed to keep Indie Hackers successful as a business when similar communities are struggling. Courtland believes that there are a few principles behind the success of Indie Hackers. The first is that you are much more likely to generate meaningful revenue quickly if you are charging for something that each customer is willing to pay a lot of money for. Regarding building a successful community, you have to start with your marketing. A community is a chicken-and-egg problem where the whole value of a community is the people inside it, making it really hard to start from nothing. With Indie Hackers, he started with content that brought in the people who could form the community. Courtland had thousands of people coming to the website before he turned it into a community. Another example is dev.to. Its founder, Ben Halpern, spent years just growing his Twitter account, tweeting funny jokes and helpful tips for developers. When he launched his community, he was able to advertise it from his Twitter account. A second thing you need to build a community is to seed it with discussions. As Courtland also described in an episode of Software Engineering Daily that I summarized in “Lighting Up The Brain and Joining A Gym”, he started his community by having conversations with fake accounts that were secretly also himself. Ben Halpern kickstarted the dev.to community with discussions with his friends. Choice of topic is critical too. You want a topic that you can talk about forever. The dev.to community’s topic is software engineering. It is the perfect topic because lots of people are learning and trying to learn from each other and there are countless issues and frameworks to talk about. Similarly, there are countless topics and subtopics around founding companies. As Courtland also said on Software Engineering Daily, you also need to think about the timing for when people get together and the space your community takes up. If you throw a party in a small room, you only need ten people to make that party feel like a success, but if you throw it in a football stadium, you need forty thousand people for it to feel like a success. It is the same with an online community. If you constrain it by saying something like, “Our community is just one discussion thread every Sunday at 3:00pm,” then even with ten people, that community can feel like it’s thriving. He talked about how he got advertisers interested in Indie Hackers and how he eventually got Indie Hackers acquired by Stripe and now no longer spends time selling ads. Not much has changed, he says, now that he is an employee of Stripe because Indie Hackers and Stripe were aligned from the beginning. Michaela asked why he decided, despite his desire to write as little code as possible, to create custom software for the Indie Hackers forum when he could have chosen third-party forum software. Courtland said he wanted Indie Hackers to have a strong brand and it is hard to have a strong brand if the thing you’re building looks like everything else. So he put a lot of time making the community unique. He spent a lot of time on the name of the community and the design of the website, all in support of having a strong brand. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/starting-profitable-business-in-six-weeks-courtland/id1477527378?i=1000465925620 Website link: https://www.software-engineering-unlocked.com/episode-12-profitable-business-courtland-allen/ MATT STRATTON ON HIRED THOUGHT The Hired Thought podcast featured Matt Stratton with host Ben Mosior. Since his move from Chef to PagerDuty, Matt’s focus has shifted from software delivery and infrastructure code to incidents and outages. Ben brought up Matt’s talk “Fight, Flight, or Freeze — Releasing Organizational Trauma.” Matt’s motivation for creating this talk was his own treatment for PTSD and a discussion with J. Paul Reed where they kept seeing similarities between Matt’s experiences and what companies go through when they experience an incident. Trauma occurs when our response to something is ineffective. Two people can have a similar experience and it can be traumatic to one person and just a bad day for the other. We respond to perceived trauma physiologically the same way as actual trauma. Events that are reminiscent of trauma that occurred to Matt as a child trigger him to have the same physiological response today. Organizations do the same thing. An organization that has an outage that is similar to an event that happened before and, say, cost them a million dollars a minute, will react the same way. Just as an adult re-experiencing a childhood trauma because of a triggering event shouldn’t necessarily respond the same way, an organization needs to learn how to respond differently to these similar stimuli. Matt talked about the window of tolerance beyond which you become activated and have an unhealthy response. He says that it can get spiky or you can get stuck-on or stuck-off. If you are stuck-on, you have anxiety and other symptoms. If you are stuck-off, there is lethargy. In an organization, we can get into a hyper-aroused state fearing any type of change, getting into analysis paralysis, or becoming over-vigilant. None of these states are healthy and they trickle down into the emotional health of employees. The good news is there are things we can do to help the organization be better. Ben added that a lot of therapy is about building up the language to describe what is happening so that when it happens or when you are reflecting back later, you can share the experience and develop skills to lengthen your window of tolerance. Matt talked about how in cognitive behavioral therapy we try to identify when a distortion occurs, knowing that the feeling we experience is not something we can change, but our response to it can be changed. In an organization, we can do the same thing. Matt is striving to excise the word “prevention” from his vocabulary and instead become more resilient when something bad happens. For a person, this can mean that you can have something happen and then you can get back inside your window of tolerance quickly. For an organization, this means that an incident can happen and we can restore service and get on with business. We need to normalize incident response. It is not an anomaly to have an incident. The irony is that we’ve gotten worse at responding to incidents as we’ve gotten better at distributing on call. Back in his days as a sysadmin, Matt was on call constantly and incident response was business as usual. Today, if you are doing a healthy on call rotation with developers on call in their own domain, you can be on call for a year and experience just two incidents. Then, when you have an incident, you freak out. You don’t want to be trying to remember how to do incident response and you don’t want to think of the response process as an exceptional thing that we only sometimes do. Ben connected this to the book The Fifth Discipline. He says we always feel like we have to do something in response to something bad happening. The other thing the book points out is that whenever you are doing an intervention, yes, you may have short term actions that buy you time, but at all times, you need to be building capabilities. When you normalize incident response and you regularly show people what it looks like to work together in a high-pressure situation, you learn to respond to incidents in healthy ways. Matt says we need to run our failure injection exercises and game days like real incidents. This is also an opportunity to train your incident commanders. In these scenarios, we know what’s wrong and we can bail out at any time. Then, when a real incident occurs at 2:00am some morning, the people who did the exercise associate the real incident with the calm exercise they did in the office on an afternoon. Sometimes there are people who want run an exercise and not tell the incident response team what’s wrong. Matt has to explain to these people that it is not an exercise in troubleshooting or to stress test your people. You don’t need to inject stress into the people who work for you. You want to do the opposite. When we are doing incident response all the time as part of the regular cadence of work, when a real incident occurs, we will associate it with the positive physiology of our response during the exercise. That means we should treat every incident the same, even false alarms. If you get a few minutes into responding to an incident and realize it is a false alarm, finish it out as an incident. Get on the bridge and do as you would in a real incident. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/6-organizational-resilience/id1479303584?i=1000466488009 Website link: https://hiredthought.com/2020/02/24/6-organizational-resilience/ 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