Twisted has been supporting asynchronous / event driven applications way before asyncio. Twisted, and Glyph, have also been encouraging automated tests for a very long time.Twisted uses a technique that should be usable by other applications, even those using asyncio or other event driven architectures.Links:Community Service Award Recipient Glyph Lefkowitz — The PSF article I was referring to early in the episode Twistedtwisted/kleintwisted/treqdjango/daphne — Django Channels HTTP/WebSocket serverScrapySo Easy You Can Even Do It in JavaScript: Event-Driven Architecture for Regular Programmers - YouTubeFeature test - twitter engineeringPython Testing with pytest — Some reading for Glyph if he wants to learn to love pytestpytest-twistedpygamePyodideBrython

Ryan Cheley joins me today to talk about some challenges of managing software teams, and how to handle them. We end up talking about a lot of skills that are excellent for software engineers as well as managers.Some topics discussed:handling code reviewsasking good questionsbeing honest about what you can't do with current resources and datadiscussing tradeoffs and offering solutions that can be completed faster than the ideal solutionbalancing engineering and managingmaking sure documentation happensremote teams encouraging collaborationencouraging non-work-related conversationswatching out for overworking

Don't you just love technical interviews, with someone who just saw your resume or CV 5 minutes ago asking you to write some code on a whiteboard. Probably code that has nothing to do with anything you've done before or anything you will do at the company.No? Neither does Nathan Aschbacher.  So when he started building the team at his company, he decided to do things differently.Hiring is one of the essential processes for building a great team. However, it's a high noise, low signal process.Nathan Aschbacher has a relatively unorthodox tech hiring approach.  He's trying to make it very humane, with a better signal to noise ratio. Nathan is not intereseted in bizarre interview processes where the interviewer doesn't know anything about the interviewee beforehand, all people are asked the same questions, and people are asked to code on white boards.Instead, he states "if the goal is to try to figure out if the person can do the work with your team, and your trying to build the team that you are adding this person to, they need to know what the team is like, and determine if they want to be part of the team, and the team needs to know what the person is like and if they would be addititve to the team.So what's Nathan's process:Screening resumes and CVs, looking for internal motivation to become an expert at something.Basic phone screen, very informal.A couple 2-3 hour pairings with someone on the team with whatever they are working on.Debriefing both the candidate and the team afterwords.Giving the candidate an opportunity for a second impression and following up on difficulties during the pairings.We discuss the process, and also:trying to remove the barriers to team integration treating people as humans And of course, there's the story of how Nathan ended up interviewing someone with Zoo experience an no technical experience for a technical role. Of course, it was a misunderstanding of a job requirement around experience with ZooKeeper. But it's a good story.

We talk with Adam Johnson about his new book, "Boost Your Django DX". Developer experience includes tools and practices to make developers more effective and efficient, and just plain make software development more fun and satisfying.  One of the things I love about this book is that it's not just for Django devs.  I'd guess that about half the book is about topics that all Python developers would find useful, from virtual environments to linters to testing.  But of course, also tons of tips and tools for working with Django.Links:“Boost Your Django DX” Released — Adam's announcementBoost Your Django DX — The book

Lean TDD is an attempt to reconcile some conflicting aspects of Test Driven Development and Lean Software Development.I've mentioned Lean TDD on the podcast a few times and even tried to do a quick outline at the end of episode 162.This episode is a more complete outline, or at least a first draft.If you feel you've got a good understanding of TDD, and it's working awesome for you, that's great. Keep doing what you're doing. There are no problems.For me, the normal way TDD is taught just doesn't work. So I'm trying to come up with a spin on some old ideas to make it work for me. I'm hoping it works for you as well.I'm calling the new thing Lean TDD. It's inspired by decades of experience writing software and influence from dozens of sources, including Pragmatic Programmer, Lean Software Development, Test-Driven Development by Example, and many blog posts and wiki articles. The main highlights, however, come from the collision of ideas between Lean and TDD and how I've tried to resolve the seemingly opposing processes.Full TranscriptLinks:Lean TDD | pythontest.comepisode 162: Flavors of TDDWhat is Test Driven Development (TDD)? | Agile AllianceTest First Programming / Test First Development | pythontest.comepisode 7: The Waterfall Model and “Managing the Development of Large Software Systems”episode 51: Feature TestingThe testing renaissance — Twitter Engineering blog post about Feature TestingLean software development - Wikipedia

Exploratory testing is absolutely an essential part of a testing strategy. This episode discusses what exploratory testing is, its benefits, and how it fits within a framework of relying on automated tests for most of our testing.Full Transcript

"There are five practical reasons that we write tests. Whether we realize it or not, our personal testing philosophy is based on how we judge the relative importance of these reasons." - Sarah MeiThis episode discusses the factors.Sarah's order:Verify the code is working correctlyPrevent future regressionsDocument the code’s behaviorProvide design guidanceSupport refactoringBrian's order:Verify the code is working correctlyPrevent future regressionsSupport refactoringProvide design guidanceDocument the code’s behaviorThe episode includes reasons why I've re-ordered them.Full TranscriptLinks:Five Factor Testing - Sarah Mei

A recent Twitter thread by Simon Willison reminded me that I've been meaning to do an episode on the testing trophy. This discussion is about the distinction between unit and integration tests, what those terms mean, and where we should spend our testing time.Full TranscriptLinks:Simon Willison's Twitter ThreadThe Testing Trophy and Testing Classifications — Kent C DoddsWrite tests. Not too many. Mostly integration. — Kent C DoddsOn the Diverse And Fantastical Shapes of Testing — Martin Fowler

The idea of having a software as a service product sound great, doesn't it? Solve a problem with software. Have a nice looking landing page and website. Get paying customers. Eventually have it make enough revenue so you can turn it into your primary source of income. There's a lot of software talent out there. We could solve lots of problems.  But going from idea to product to first customer is non-trivial.  Especially as a side hustle.  This episode discusses some of the hurdles from idea to first customer. Brandon Braner is building Released.sh. It's a cool idea, but it's not done yet. Brandon and I talk about building side projects:finding a target audiencelimiting scope to something doable by one personbuilding a great looking landing pagefinding time to work on thingsprioritizing and planninglearning while buildingeven utilizing third party services to allow you to launch fasterand last, but not least, having funFull TranscriptSpecial Guest: Brandon Braner.Links:ReleasedTailwind CSS Tailwind UIFigmaHerokuGoogle App Engine

Who should do QA?How does that change with different projects and teams?What does "doing QA" mean, anyway?Answering these questions are the goals of this episode.Full TranscriptLinks:Test Automation - Who Should be Involved? | Thoughtworks