Nobody knows bad code like Justin Searls—he writes bad code effortlessly. And it's given him the chance to study why the industry has gotten so good at making bad software. He co-founded Test Double, an agency focused on fixing everything that's broken about software.
Justin Searls has been a guest on 3 episodes.
-
Episode 54: Code Style and Community with Sam Phippen and Justin Searls
January 30th, 2019 | 47 mins 16 secs
code, communication, developer
On this episode, we’ve got Sam Phippen and Justin Searls back for their third round on the show. Both of them have been working on new Ruby tools to better standardize your team’s style and code formatting. We talk about why they’ve decided these tools are important, what their philosophy of coding style is, how coding style relates to the Ruby community, and how they evaluate code when given a code sample to look at.
We’d like to hear from you. How does your team handle differences of opinion in code style? Let us know at
techdoneright.io/54
or on Twitter at@tech_done_right
-
Episode 33: Back in the Testing Weeds with Sam Phippen and Justin Searls
March 28th, 2018 | 41 mins 27 secs
developer, testing
I'm back in the testing weeds with Sam Phippen, lead maintainer for RSpec-Rails, and Justin Searls, co-founder of Test Double and author of testdouble.js. We talk about long-running test suites: are they bad, or just misunderstood? Does parallel CI solve all testing speed problems, or just some of them? Then we move to a wider view, what does it mean to test your library as part of a larger ecosystem. And, how can we leverage coverage or CI information to make for more useful testing tools over the lifetime of a project.
-
Episode 004: In The Testing Weeds With Sam Phippen and Justin Searls
February 22nd, 2017 | 49 mins 16 secs
developer, testing
Sam Phippen, Justin Searls, and Noel Rappin spend this episode talking about the value of test-driven development (TDD) as well as its cost. They discuss the kinds of problems that developers are likely to have after they learn TDD and attempt to apply it to a large application. Learn why Rails is both great and terrible for automated testing, and how testing can influence the structure of your code.