Podcast appearances and mentions of jonathan cutrell

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?