Overdue Reflection

Reflecting on my three plus years at Indeed, I think my greatest takeaway would be learning about test driven development (TDD).

Prior to my last role, I treated writing tests as separate from the implementation code I had to write to deliver software. I failed interviews with take-home assignments because my submission didn’t have “proper” tests. I also fared badly in pair programming interviews because I didn’t know what to say when asked “what should we test next?” Up till that point, I’d worked on entire codebases with zero to few feel-good tests (in hindsight more like integration or e2e tests), often added as an afterthought. Test driving implementation felt foreign.

This changed when I joined Indeed on the International Payments team. This team practised TDD – writing a failing test before writing the code to pass the test and deliver a tiny slice of the user story. The team also practised pairing. Every day I was scared yet excited going to work, knowing that I would be sitting beside another engineer, struggling to figure out what to test next and what’s the bare minimal code to pass the test.

What was hard to get used to:

• developing a feature/user story in small red-green-refactor increments, as opposed to coding up the entire feature and then writing a few tests to test the happy path.
• running tests in a continuous mode (once you save any file changes, the tests will run automatically), as opposed to manually running a test suite.

What helped me to get it eventually:

• reading “TDD by example” written by Kent Beck, which had concise and instructive examples. One cool example was test driving the implementation of a unit testing framework using the same unit testing framework.
• practicing TDD, resisting going back to the old ways, even when not pairing.

Conclusion

Personally, the benefits of TDD extend beyond well defined user stories. I find that the test-first approach which forced me to think small was especially helpful for tasks which I actually don’t write any tests:

• timeboxed hacking and prototyping to assess feasibility
• debugging
• writting terraform (what’s the least we can write before running a plan)