Dave Haeffner joins us to talk about his path from QA Analyst to Software Developer, and the challenges of reverse engineering legacy software applications to improve quality. Along the way, he also started his own business as a consultant and trainer around Software Quality Practices and test automation, and then he moved internationally to begin work as a Software Developer, a job he has been able to continue since returning to the US. Dave spoke with us about the craft of building and testing software, about finding anchors and constraints when working on difficult problems, and inheriting legacy systems. Dave also explains why despite his background in software testing, he’ll be the first person to say a test should not be end-to-end!
Watch the video:
Show notes with links to jump ahead are below
Show Notes from Episode 4 – Dave Haeffner on his journey from QA to Software Developer
Timestamp links will open that part of the show in YouTube in a new window
- 00:00 Introductions by David and Arin. David notes how Dave is very philosophical, and how important is to have a good mental framework for your health and your work. Arin notes how much Dave cares about the craft of his work, and that shows in this episode. Arin also notes a particularly interesting part of the conversation when Dave talks about North Stars and constraints in our work.
- 03:43 Arin introduces Dave and they note how Dave worked with Arin and David early in their adventures building a company in Costa Rica.
- 05:05 Dave starts by talking about his transition from QA to a software developer. He is primarily known for his work in software testing and as a Selenium consultant. Dave talks about initially studying network engineering before he was into test automation. Eventually he felt like he was a software developer trapped in a QA person’s body. As he built out the infrastructure he needed for his test automation consulting business, he was building little custom apps that aided him and thah helped him hone his development skills and he became more interested in that than the content development around testing and the test consulting.
- 07:34 It was harder to become a software developer without experience, despite his test automation background, but eventually joined the R&D team at an Israeli firm and used that to parlay a family move to Israel for a couple years. He was working on bug fixes as well as feature requests, as well as working on content and education around their platform, so it played well into his past experience as well as his desire to do more software development.
- 09:16 The open source project he worked on through that company had a large user base and hundreds of thousands of users, so he also gained experience with working on larger scale systems.
- 10:22 Arin asks what changed about Dave’s mindset as he made that transition from QA to Developer. Dave talks about how his perspective didn’t really change much, he was already interested in the craft of software, and wanting to be in a team of experts. He read up on Kent Beck’s and Martin Fowler’s work, the Gang of Four book, and Michael Feather’s book on Working Effectively with Legacy code.
- 12:23 Dave was reviewing a lot of test code in his work that helped him to also learn the processes of abstraction, all of which influenced him as he became a software developer.
- 13:15 Dave talks about looking for constraints. When things seem really hard to work on and unbounded, look for the constraints on that work first, which can be business or technology driven. You can use those constraints as your North Star, and then from there look for anchors or cornerstones that you can orient from.
- 14:20 What’s changed? After knowing your constraints, then look for what has changed as you work on difficult problems. Then compare “what the book says” to reality via your constraints and the changes to help work up.
- 15:30 David talks with Dave about first principles – what is the common principle among all these disciplines? Dave talks about the first principles of how web and mobile technologies work, and understanding those allows you to tease out what to work on within a large problem.
- 16:45 Dave says “I’m the first person to say that this should not be an end to end test.” We shouldn’t rely on large round trips for most of testing, integration or unit tests are better because they are more constrained. This is a key principle to him in mobile and browser testing, and particularly important the more custom your application is.
- 18:30 David talks with Dave about inheriting a test suite on legacy systems and realizing that many automated tests don’t actually provide value. Dave notes how testing looks different based on when you write them. Writing a test before you actually code the feature, as TDD teaches, leads to writing better tests.
- 19:50 Working in a legacy application, the way progress happens is by working on small pieces and improving them as you go. Abstract out each part and add tests to it as you can in order to eventually get rid of monster functions in legacy applications.
- 20:45 These practices have helped Dave and the SDK team he works with to better abstract out features from across different language libraries and make the overall system easier to maintain.
- 22:30 “It has to get worse before it gets better” is often the case with working on a legacy application as you instill better practices and a better deployment pipeline. It’s often a combination of people, process and technology issues.
- 24:20 David brings up the topic of craftsmanship, and how you must devote yourself to a craft to really excel at it. David asks Dave about how he is able to work well in a remote environment, and how he maintains a focus on craftsmanship despite the distractions that can come with working remotely. Dave notes it’s hard with two young children, but you can shut down tools like slack/trello, silencing your phone, and staying focused on top priorities before looking at other items on the backlog. Having a good amount of high quality coffee, and taking a coffee break when the frustration is too much is very important.
- 27:25 David talks about the problem with email is that others are demanding part of your time, and how you have to change your approach to when and how you answer your emails. Don’t let them distract you from what you have to work on first.
- 28:30 Dave talks about how during a sabbatical that he took, he completely deleted his social media and did a hard reset on his communication practices. This allowed him to get away from doom scrolling and focus on the closer relationships that matter. It feels good to say “No, I didn’t see that” when people talk about controversial social media posts.
- 30:20 Arin notes how Dave has a very holisitic view of software development based on the variety of roles he’s had professionally. What advice would he give those also looking to make a transition from QA to software development?
- 31:30 Dave talks about the importance of the sabbatical that he took, and how it allowed him to review what was important to him. He notes that it was important for him to decide to join a company based on the people, and that he could be there as his whole self and continually learn. A challenging role can be where the growth happens. Working for good companies and for strong compensation usually flow naturally from that.
- 34:40 David’s takeaway today is to never stop learning and growing. The only way to grow as a software developer is to keep making deep dives into yourself and discover the things that make you passionate.
Links from Episode 4 – Dave Haeffner on his journey from QA to Software Developer
- Dave is not on social media! Wise man. So enjoy some links of things he talked about instead.
- The Selenium Guidebook – Dave Haeffner’s guide to Selenium and automated testing from his consulting days.
- Kent Beck – Author of the Extreme Programming book series, and Test Driven Development expert.
- Martin Fowler – Author on Agile and Software Development topics
- Working Effectively with Legacy Code – Classic book by Michael Feathers
- Design Patterns: Elements of Reusable Object-Oriented Software – The “Gang of Four” book by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, a classic software development book that is still widely respected today.