Podcast appearances and mentions of jonathan cutrell

Right now, the questions we have about our careers feel existential. We keep coming back to the same theme: how do you prepare for an industry that's changing this fast, and what mindset actually works in this new reality? One skill keeps surfacing as the answer — your ability to update your own mental models. In today's episode, I want to push on that further and put some of software engineering's most beloved thinking models under scrutiny. Some of these models served you well for years. Some of them now deserve to be challenged, replaced, or thrown out entirely — and learning how to tell the difference is itself the skill that will determine whether you hit a ceiling. Move Past "So What" Questions: The typical engineering objection to agentic coding is that it produces quality issues. But the people deciding to adopt these tools already accept that. Our job is to stop arguing the surface-level point and start asking the real one: so what do we actually do about this new economic reality? The Economics of Acceptable Loss: Abstraction always leaves something to be desired. An agent's code may not match what a staff engineer produces by hand over months — but that gap is usually an acceptable trade against shipping something two, three, or four times faster. Understand the cost-benefit picture instead of pretending the cost doesn't exist. Abstraction Has Always Done This: This isn't new. The calculator dissolved the specialization once required for complex math. Spreadsheets commoditized ledgering and accounting. Agentic coding is the same pattern arriving for our work — making something that required deep specialization suddenly far more accessible. Roles Are Blurring: As these generic tools raise everyone's ability to abstract, the boundaries soften. You're already seeing product managers open pull requests and engineers making product decisions. The neat lines around "what an engineer is" are not as fixed as they used to feel. Why Your Hard-Won Wisdom Is the Target: If you've spent years in this industry, your models were bought with blood, sweat, and failed projects. That experience is real wisdom — and it's exactly what I'm asking you to be willing to challenge, because the thing that always worked for you is the thing most likely to become a ceiling. This Skill Survives Either Way: Even if you think AI is mostly hype and I've been infected by it — fine. The ability to challenge your pre-existing models is a critical skill regardless. It's how you keep growing as you get more senior instead of repeating what used to work. Models Are Approximations: The whole point of a model is to approximate the reality around us. That's their value and their limitation. When the underlying reality shifts this dramatically, holding tightly to an old approximation stops being wisdom and starts being a liability.

If you're a software engineer right now, you likely feel like your world is changing overnight. We are writing half or less the amount of code that we wrote even a year ago, which represents a seismic, groundbreaking shift in our industry. For many of us, this career has always been engaging for deeply creative and intellectual reasons—and that excitement is still here. But our mental models of what it means to be a good engineer, and what it means to keep improving, have gone a little stale. In today's episode, I want to talk about a distinction that I believe will become the cornerstone mistake for seasoned engineers: confusing _practice_ with _adaptation_, and leaning on the wrong one at the worst possible moment. Two Surfaces Coming Into Contact: Picture your knowledge, skills, and toolset as one surface, and the actual state of the art as another. We've always known the surface area we could learn far exceeds what we can learn, which forces us to place bets on a learning strategy. What's changing is how fast that second surface is moving underneath us. Improvement by Practice vs. Improvement by Change: Practice is wielding what you've already adopted—smoothing out errors, building muscle memory, refining what you already know. Adaptation is fundamentally folding something new into your repertoire. Both are real forms of improvement, but they are not interchangeable. The Cornerstone Mistake for Senior Engineers: Later in your career, the time you spend adapting naturally goes down as you settle into practice. The biggest error I'm already watching engineers make is moving too quickly toward practice when the industry is loudly calling for adaptation instead. Inspect and Adapt—at the Right Altitude: Sprint retros were never really about getting marginally better at the thing you already do. The intent of "inspect and adapt" is to step up one level and examine the system. The trap is treating adaptation like a minor refinement—getting a little better at prompting—when it should mean asking whether you're thinking about prompting in the wrong way entirely. Question the Ratio, Not Just the Output: Real adaptation looks like asking whether you have the right mix of human and agent on a problem. Are you leaning on the agent for things you shouldn't, or failing to lean on it for the things you should? Have you genuinely thought about how sub-agents or an agent team are working the problem you're producing? A Spectrum, Not a Binary: On one end, you make micro-adjustments to your refinement process. On the other end of experimentation, you ask whether refinement—or even having engineers plan the work—is the right thing at all. The point isn't that practice is dead; it's that the industry is changing fast enough that the adaptive end of that spectrum deserves far more of your attention than it used to. Episode Homework: Take something you currently treat as a practice problem—"how do I refine tickets faster?"—and step up a level. Ask the adaptive version of the question instead: "Is refinement even the right thing anymore?"

If you've heard that your job in the agentic coding era is to "become a manager of agents," you may have noticed something doesn't quite fit. Most of us never trained to be managers, and frankly, that's not the role most engineers want. In today's episode, I unpack what that shift _actually_ means — it's closer to a tech lead or architect mindset — and zoom in on a specific interviewing and on-the-job skill that will help you stay employable: how you think about, talk about, and take ownership of failure. Don't Just Bring Star Stories — Bring Failure Stories: Interviewers don't only want to hear how you succeeded. They want to know what you do when the pressure's on and things fall apart. If every story you tell is a highlight reel, there's a built-in social signal that you're hiding something. Get comfortable telling the other kind of story. Identify the Real Problem, Not the Proximal One: The most common failure story I hear in interviews is "the knowledge transfer was bad" or "the docs weren't good." That's not wrong — it's just incomplete. The senior mindset asks why that happened. Why didn't we have docs? Why was context insufficient? Walk it back until you hit something actionable but not too abstract. The Systemic Diagnosis is the Leveled-Up Answer: Fixing the proximal cause fixes this instance. Fixing the root cause fixes the system that keeps producing instances like this. When you connect what you learned to a systemic adjustment, you stop sounding like someone who survived a bad project and start sounding like someone who improves the organization around them. Ownership Means Owning the Outcome, Not the Task: Use the homeowner metaphor. A homeowner doesn't personally fix every leaking pipe — but the outcome of the home is theirs. As an engineer, your scope of ownership has expanded dramatically in the agentic era. You're now responsible for outcomes of code you may not have even read, and the deciding skill is how you carry that responsibility. The Word to Pair With Ownership is Relentlessness: Not in an anxious, burn-yourself-out way. Relentlessness means following a thread to its natural end — through escalation, through asking the next question, through finding the right person if it's not you. It's the antidote to "I'll let someone else handle it" syndrome. You Don't Have to Do It All Yourself: Relentless ownership is not "carry every task across the finish line personally." If you're not qualified, the owner's job is to find who is, communicate risk to stakeholders, and keep the trail alive until the outcome is resolved. That's the differentiator between a senior thinking engineer and a junior one working through assigned tickets. Failure Is Usually a Lapse in Ownership: If you make a list of five things you've failed at (and you should), you'll often find the through-line isn't lack of skill — it's that you stopped escalating, stopped following up, stopped staying with the thing until it was actually resolved. Episode Homework: Write down five real failures. For each one, ask: where did I stop being relentless? What system produced this outcome — and what would I change upstream next time?

What happens when you discover that a book that fundamentally changed how you think is built on a shaky foundation? In today's episode, I share my own struggle with the replication crisis surrounding Daniel Kahneman's *Thinking Fast and Slow*, and I use it as a springboard to talk about a much bigger skill: knowing how to update your beliefs when reality shifts underneath you. This isn't about throwing out science or losing trust in your heroes. It's about developing the muscle to replace old explanations with better ones — a skill that has never been more important for software engineers. The Replication Crisis, Briefly Explained: Understand the difference between reproducing a study (re-running the analysis on the original data) and replicating one (recreating the study from the ground up), and why a surprisingly large portion of well-respected psychology research, including studies cited in Thinking Fast and Slow, doesn't hold up under scrutiny. Base Rates Matter: Kahneman didn't pick uniquely bad studies. If you randomly sampled from the broader academic literature, you'd hit the same failure rate. The lesson isn't about one author — it's about how we evaluate any body of knowledge. The Beginning of Infinity Framework: Drawing from David Deutsch's book, explore the idea that all progress is rooted in the assumption that we are fundamentally incorrect, and that improvement comes from continually building better explanations on top of incomplete ones. Beliefs as Calibration, Not Truth: Your beliefs about what makes a good engineer, what makes good code, or what makes a good career move are not eternal truths. They are calibrations to your current reality, and that reality is changing fast. The Ego Trap of Old Beliefs: Notice the very human, very subtle pull to defend things you previously argued for — not because they're still right, but because admitting otherwise creates a discontinuity with your former self. This is one of the biggest blockers to learning. Two Competing Explanations of AI Adoption: Walk through a worked example of holding two predictions about AI in tension and asking honestly which one better explains the reality you're seeing — at both a macro industry level and the micro level of debugging a system. Moving Goalposts Aren't a Conspiracy: A lot of what feels like shifting goalposts in our industry is just goalposts moving on their own. A big part of our job as engineers is figuring out where they are now and predicting where they're heading next. Episode Homework: Pick one belief you hold strongly about your work — about what makes a good engineer, about a tool, about a process. Try to deconstruct it into its parts and ask whether a better explanation exists for what you're actually seeing.

Developer Tea is a podcast for developers designed to fit inside your tea break. Jonathan Cutrell started the podcast in 2015 and now has hosted over 1000 episodes. We interview Jonathan Cutrell about the early days of Developer Tea, Spec.fm, developer content, and more. Links https://jonathancutrell.com https://twitter.com/jcutrell https://spec.fm/podcasts/developer-tea https://designdetails.fm https://spec.fm https://twitter.com/chantastic https://developertea.com https://twitter.com/DeveloperTea https://www.charitynavigator.org Contact us https://podrocket.logrocket.com/contact-us (https://podrocket.logrocket.com/contact-us) @PodRocketpod (https://twitter.com/PodRocketpod) What does LogRocket do? LogRocket combines frontend monitoring, product analytics, and session replay to help software teams deliver the ideal product experience. Try LogRocket for free today (https://logrocket.com/signup?pdr). Special Guest: Jonathan Cutrell.

Dungeons and Designers is where design nerds, get nerdy. We are a Master of One Network podcast where 4 designers play Dungeons and Dragons with guest designers, many having never rolled a D20. Episode Summary Our crew is joined once again by Jonathan Cutrell as they finally find Floon!. Episode Notes Sign up for our newsletter, view our equipment, and check out our store at dungeonsanddesigners.com Cast Will Truran Dan Truran Zach Wilkinson Courtney Leach Social Instagram Twitter Jonathan Cutrell Developer Tea Twitter Visit www.mof1.network to see what else the Mof1 network is putting out each and every week!

Dungeons and Designers is where design nerds, get nerdy. We are a Master of One Network podcast where 4 designers play Dungeons and Dragons with guest designers, many having never rolled a D20. Episode Summary Our crew is joined once again by Jonathan Cutrell as they return to the sewers. Episode Notes Sign up for our newsletter, view our equipment, and check out our store at dungeonsanddesigners.com Cast Will Truran Dan Truran Zach Wilkinson Courtney Leach Social Instagram Twitter Jonathan Cutrell Developer Tea Twitter Visit www.mof1.network to see what else the Mof1 network is putting out each and every week!

Dungeons and Designers is where design nerds, get nerdy. We are a Master of One Network podcast where 4 designers play Dungeons and Dragons with guest designers, many having never rolled a D20. Episode Summary Our crew is joined once again by Jonathan Cutrell as the search for Floon continues and they make their way to a gang's warehouse Episode Notes Sign up for our newsletter, view our equipment, and check out our store at dungeonsanddesigners.com Cast Will Truran Dan Truran Zach Wilkinson Courtney Leach Social Instagram Twitter Jonathan Cutrell Developer Tea Twitter Visit www.mof1.network to see what else the Mof1 network is putting out each and every week!

Dungeons and Designers is where design nerds, get nerdy. We are a Master of One Network podcast where 4 designers play Dungeons and Dragons with guest designers, many having never rolled a D20. Episode Summary Our crew is joined by Jonathan Cutrell as the search for Floon continues and they head to the Skewered Dragon Episode Notes Sign up for our newsletter, view our equipment, and check out our store at dungeonsanddesigners.com Cast Will Truran Dan Truran Zach Wilkinson Courtney Leach Social Instagram Twitter Jonathan Cutrell Developer Tea Twitter Visit www.mof1.network to see what else the Mof1 network is putting out each and every week!

Today we're talking to Jonathan Cutrell, Host of the Developer Tea Podcast, and Director of Technology at PBS. And we discuss how resisting failure is akin to resisting reality. Differences in how you plan at a larger organization vs at a startup, and being comfortable recognizing the fluidity of your passions in life. All of this right here, right now, on the ModernCTO Podcast! 

This week's episode of Conversations with Tech Experts features Jonathan Cutrell, Director of Technology at PBS and host of the DeveloperTea podcast. Jonathan joins Experts Exchange CEO Randy Redberg and Director of Bus. Dev. Thomas Bernal to discuss the pursuit of knowledge and the importance of learning within a community. They start the show with Randy and Thomas asking Jonathan his opinion on the best way to showcase the community aspects of Experts Exchange. Then, Jonathan gives a rundown of his career - which includes starting one of the top tech podcasts - "DeveloperTea," and working his way from web designer to the Director of Technology at PBS. They then dive into why having a strong community around you is vital to a prosperous technology career. Jonathan then tells us why a certain type of AI is the next big thing in tech - and finishes with his Big Idea: zooming out your perspective.

AndrewBeeple: https://www.theverge.com/platform/amp/2021/3/11/22325054/beeple-christies-nft-sale-cost-everydays-69-millionDungeons & Designers: http://dungeonsanddesigners.com/MadMaxMiniatures: https://www.instagram.com/madmaxminiature/MMM Etsy: https://www.etsy.com/shop/MadMaxMiniatureLaurenBojack Poster, Eric is Eric: https://www.instagram.com/erik_as_erik/Botanica Tarot Deck: https://www.instagram.com/p/CMIa39ypEMa/Kevin Jay Stanton: https://linktr.ee/kevinjaystantonThe Drawing Board: https://youtu.be/OIfL69ps15gWolfwalkers: https://www.cartoonsaloon.ie/The Grammys, W.A.P. Performance: https://www.youtube.com/watch?v=UnBZLFB7kLoPatrickAround: https://www.around.co/Marriage or Mortgage: https://www.imdb.com/title/tt14037542/Developer Tea: https://developertea.com/Jonathan Cutrell: https://jonathancutrell.com/

Today's guest is Jonathan Cutrell - Director of Engineering at PBS & host of the Developer Tea podcast.In this episode we discuss:How and why he started Developer TeaThe why behind things we do as developersWhat drives the actions we takeThe psychology of remote workingHierarchies of developer rolesand much much more!

Welcome to another episode of Develomentor. Today's guest is Jonathan CutrellJonathan Cutrell is a communications and media studies graduate who started his early career as a writer and editor before entering the world of development. He’s held a variety of roles including software engineer, director and CTO. These days, he’s an engineering manager and fellow podcaster who started the Spec.fm podcast network. Spec.fm currently hosts 12 different podcasts and sees an average of 100,000 downloads a weekIf you are enjoying our content, click here to support us!Episode Summary“What a lot of people get out of journaling I get out of making podcasts.”“I think the best way to think about Developer Tea, and incidentally to think about almost anything, is in the smallest possible chunk you can consume.”“Frankly, I think Developer Tea is as much of a me talking to myself as me talking to the people that listen to it.”—Jonathan CutrellKey MilestonesHow did Jonathan get into tech and how was he able to get into early leadership roles like Director of TechnologyHow was Jonathan able to hold so many management roles? What drew him to management?Jonathan hosts the podcast called Developer Tea. What was the inspiration for starting the show?Spec.fm consists of 11 different podcasts focused on developers and technology. How did Jonathan create this platform?As a manager and a podcaster, Jonathan focused much of your career on helping developers succeed. How did Jonathan find this niche?What does Jonathan look for when hiring and building teams?Additional ResourcesCheck out our previous interview with Podcaster Charles Max Wood – Charles Max Wood – From Programmer to Full-Time Podcast WizFollow Jonathan’s podcast Developer Tea – @DeveloperTeaVisit the spec.fm podcast network – https://spec.fm/Follow Specfm – @specfmYou can find more resources in the show notesTo learn more about our podcast go to https://develomentor.com/To listen to previous episodes go to https://develomentor.com/blog/CONNECT WITH JONATHAN CUTRELLLinkedInWebsiteTwitterFollow Develomentor:Twitter: @develomentorFollow Grant IngersollTwitter: @gsingersLinkedIn: linkedin.com/in/grantingersoll

This week we continue our discussion with Jonathan Cutrell about the future of work. This time, we're talking about teamwork. We tackle a few important questions. How do you invest in a team that is separated by hundreds of miles? How do you find moments to spark trust where serendipity is at a minimum? And how do you make sure everyone is heard and feels good about their work? If you work remote — or hope to work remote — these questions are at the forefront of your mind as you decide whether or not to DM that co-worker or waffle between which emoji expresses your sentiment best. We got you. This episode is brimming with tips and tricks for you.

This week we sit down with Jonathan Cutrell. He's the host of the beloved podcast Developer Tea and co-found Spec, the very Network that this show belongs to. Now, when podcasters get together and talk. They talk... for hours. So this is part one of a two parter. Today, we glean from Jonathan's transition from musician to developer. We discover how constrained systems like music primed him for life as a developer, and the ways in which all systems being infused with our humanity. We talk about how to keep doing work you love and finding, or creating, a company that will help you do.

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 podcast@thekguy.com. 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 podcast@thekguy.com. 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:

Jonathan Cutrell, host of Developer Tea and Senior Engineer at Clearbit, discusses the history of the podcast, motivation for creation, learning to say 'no', and what it means to truly be 'remote-friendly'. Clearbit Developer Tea Podcast Spec Tea Break Challenge Jonathan on Twitter See open positions at thoughtbot! Become a Sponsor of Giant Robots!

This week Robby interviews the host of the Developer Tea podcast, Jonathan Cutrell. They discuss what constitutes debt, how to build a strong team, and more! Helpful Links: Thinking, Fast and Slow by Daniel Kahneman Developer Tea Podcast Follow Jonathan on Twitter Jonathan on LinkedIn Subscribe to Maintainable on: Apple Podcasts Overcast Or search "Maintainable" wherever you stream your podcasts. Loving Maintainable? Leave a rating and review on Apple Podcasts to help grow our reach. Brought to you by the team at Planet Argon.

In this episode, Dave and Jamison answer these questions along with special guest Jonathan Cutrell:: I’ve been job hunting while employed (gasp), and I have a number of opportunities that have advanced to the in-person interview. Most of the requests I’ve seen have said that they’ll be 4-5 hours in the office (which seems fairly typical). The problem is that I don’t have unlimited vacation, and I feel dishonest taking so many days off. How can I navigate new opportunities without disrespecting them, or completely failing in my current responsibilities? Hey guys, great show (though I think, as with all shows, it could probably use more discussion of badgers [yes, I said badgers!]). I’m about to start a new job (I took the time-honored and hallowed show advice, though I’m leaving on great terms with my old job) and will be coming in as that fanciest of newly-invented titles in software, Staff Software Engineer. This is the only third time I’ve started a new job [not counting odd jobs in high school and college], and I’ve never stepped into a leadership role before when starting. What are the most helpful things you’ve done or seen other engineers do when joining a team in a technical leadership role? Thanks! Follow Jonathan Cutrell on Twitter @jcutrell and subscribe to the Developer Tea podcast: https://spec.fm/podcasts/developer-tea.

My guest this week is Jonathan Cutrell, host of Developer Tea, a podcast about the skills required to be a good developer. We discuss introversion, podcasting methods, the Spec network and more. Jonathan Cutrell on the web Developer Tea @developertea @jcutrell jonathancutrell.com Mentioned in the show Background Introverts/Extroverts - Layout.fm False Dichotomies - Developer Tea Whiteboard Adelle Charles 960 Grid Podcasting ShopTalk Ruby Tapas Back To Front Roman Mars 99% Invisible Spec Design Details Bryn Jackson Brian Lovin Sponsor Message Reactive Conf are kindly offering 10% off any conference ticket to listeners of Inspect. Simply enter the code INSPECT while making your ticket selection. Head over to reactiveconf.com to find out more and buy tickets.

Jonathan Cutrell is the founder and host of the Developer Tea Podcast and the Director of Technology at Whiteboard. In this episode we cover: - The core skills of a good developer and advice on learning to code - How Jonathan got his pilot’s license and learned to fly planes - Jonathan’s lessons from 300+ episodes of the Developer Tea Podcast So whether you’re looking to learn how to code, start a podcast, or fly a plane, this episode will give you everything you need and more.

Part 2 His ultimate goal and mission in life is to teach others how to empower their impossible goals. (That may sound really heady if you’re like me, but go try to write your own mission statement – it’s not easy.)

His ultimate goal and mission in life is to teach others how to empower their impossible goals. (That may sound really heady if you’re like me, but go try to write your own mission statement – it’s not easy.) The reality is, we often accidentally li

“Our field moves so quickly that learning is kind of a fundamental skill – not every field is that way.” Continue reading… The post Developer Tea with Jonathan Cutrell appeared first on Software Engineering Daily.

Thank you everyone for making 2015 a great year for the show! Episodes mentioned in this show How We Really Create (travandlos.com/38) Set and Achieve Better Goals (travandlos.com/10) How I increased my creative output 150% by simply changing the way I sleep (Polyphasic Sleep) (travandlos.com/38) Burnout – What it is, how to avoid and overcome it (travandlos.com/22) Steal a collage education (travandlos.com/23) Expectational Debt (travandlos.com/52) The loss of thought (travandlos.com/37) Full-Process Designer (travandlos.com/26) Sometimes We Fail Hard (travandlos.com/44) Chase the Carrot (travandlos.com/11) Guests Jerrod Eroundu - (travandlos.com/42) Jonathan Cutrell - (travandlos.com/36) Travis McCleary - (travandlos.com/9)

Jonathan Cutrell is Director of Technology at Whiteboard, an interactive design and development firm. He also hosts of Developer Tea podcast. We talked about his experience speaking at CSS Dev Conf, his podcasts, and Whiteboard.

Jonathan Cutrell is Director of Technology at Whiteboard, an interactive design and development firm. He also hosts of Developer Tea podcast. We talked about his experience speaking at CSS Dev Conf, his podcasts, and Whiteboard.

Jonathan Cutrell is Director of Technology at Whiteboard, an interactive design and development firm. He also hosts of Developer Tea podcast. We talked about his experience speaking at CSS Dev Conf, his podcasts, and Whiteboard.

Guest: Jonathan Cutrell @jcutrell Full show notes are at https://developeronfire.com/podcast/episode-064-jonathan-cutrell-firm-commitment

In today's episode, we talk about FoMO (the fear of missing out) as it relates to deciding what tools to use. Thanks to today's sponsor, Linode! Get root access on super-fast linux cloud servers in just a few minutes! Use the code DeveloperTea10 to get $10 off on your new account. Visit http://linode.com/developertea to get started today!

Questions we discuss How long have you been doing DevTea? What is the elevator pitch of DevTea? why did you start? What is the most popular episode about? What is your favorite episode about? How much time goes into an episode? What before that? Anything public? You have a very clear message on DevTea, What was involved in developing that unique voice for yourself? I've noticed that you've incorporated more hard skill based discussion into Devtea, what difficulties/ insights have you come across from trying new things? If you were to coach someone in gaining their own unique voice, where would you start? Where do you turn for content ideas? We were recently asked this: Once you make awesome content, how do you get people to notice it? You recently co-founded a podcast network, spec.fm. What is your goal there? Why start a network? What has been the outcome so far? What do you hope your listeners will take away from the work you do?