In this episode, Ian and Andrey talk about Florida, children, stupid teenagers, growing up, stories that go nowhere, growth hackers, hiring a content engineer, unit testing, John Carmack, spending $13,000 on marketing automation software, motorcycles, and baseball tickets.
Download the episode and view show notes.
EDIT: I found a photo of Rebecca, the motorcycle I mentioned in this episode. The rider is Ania. She was a developer at Antair.
Great episode. Agree with you that too many developers build for cool points instead of what’s best for the business.
I’ve found this is a good reason to have a non-technical co-founder (in my case, my wife). When I start spinning wheels on stuff-that-doesn’t-matter to potential customers but satiates my geek curiosity, she calls me on it.
Yeah, that’s worked pretty well for me also. It helps my wife is pretty technical (though not a programmer). Definitely something you single guys should keep an eye out for 
I had to stop twice while out running this morning because I was laughing so much at this episode. With @andrey driving around feeding stray cats and @ian potentially hiring a growth hacker in order to make an example of them! 
The people in cars queuing in traffic along the road I was running must have wondered why this crazy woman was running along (in hi-vis gear because it was still dark) cackling to herself.
Thinking about the previous episode and physical products you might like https://cuttingedgeknives.co.uk - this is a knife company started by a web design agency, some details of the story here: http://www.welcomebrand.co.uk/work/cutting-edge-knives/
Haha, that sounds like it would be a bit of a funny scene. You never know, maybe they were listening in the cars!
I have to start running so I have more podcast listening time.
Ah, like the knives. We have to do some kind of physical product.
Being a developer, so far I have been a silent listener. But since Ian and Andrey got technical on the podcast at length, I felt it’s OK to leave a comment that’s also techie in nature
To begin with: I absolutely agree with both of them that Resume Driven Development is dangerous and that the right tool for the right job expression is there for a reason.
Yet I have to add a shade of gray to that “unit testing is stealing from the client” sentiment
I myself am a TDD person, and I have seen people produce equivalent code without automated tests - both approaches have been demonstrated as able to deliver working software, so if there is no requirement/need otherwise (please, do test medical software and car controls!) and it’s a conscious choice, I think you should code whichever way you feel comfortable and productive. After many years of practicing the test first approach, I think I can match the productivity of most non-test first people I’ve worked with - at least I certainly haven’t been fired yet for being less productive TDD, by definition doesn’t have to take longer than the code only approach (if I’m not flamed off after this comment, I’m happy to discuss it in more detail 
).
Love the show, and Andrey is totally great for giving away that motorcycle!
Hey Ian and Andrey,
I don’t agree with your opinions you offered on unit tests, although it does sound like one of you inherited a unit test catastrophe.
Even a small, 4-screen app should have a few judicious unit tests. Not to test what happens when a button is clicked - that is not a unit test. And not to interact with a database or other systems.
The unit tests you have are, for example, to test that the code you have written that can detect which of three possible date formats is used. Or to test that any of several different dates get interpreted correctly. That is, testing a unit of code in the form of a method or function, which is what the “unit” refers to in unit testing.
Then, when a bug report occurs with a date not being handled correctly, you can add a unit test for the troublesome date, fix the problem, and be confident that your fix did not break the handling of any other dates.
This approach is beneficial in just about every product, is free of “100%-coverage” mantra, and helps rather than hinders rapid development.
My mantra is that the whole set of unit tests in your project must run in no more than a few seconds, and must not rely on you introducing major architectural changes to your project.