When I joined my current company, we were a small team and built things quickly. We could write code and if it turned out that it didn't work, then whoever was the author would have to fix it.
This, of course, is not good software engineering.
We did realise that testing was something worth doing but it wasn't fun, so we hired an external company to write tests for the code we'd written. This seemed like a really smart thing to do as it let us code more and "not check our own homework" but this was still not good engineering.
Later, with a change of CTO, the tests came in-house. For any code we wrote, we'd also have to write unit tests ourselves. The goal was to achieve 100% code coverage. I didn't enjoy this, and I didn't think that it worked terribly well either. Engineers write tests that pass for the code they've written and thus the tests are much less likely to catch edge cases. Perhaps this was a step backwards. For sure, what it did for me was to put me off engineering and drive me out of core development. I moved to technical pre-sales where it's still useful to write code for demos and POCs but that code doesn't have a long life, the expectation being that it is thrown away soon after use.
Even though "unit testing" has been superseded by "test driven development", my mistake was to not embrace the idea that we should write automated tests, even though our approach to them was flawed.
Jump forwards 5 years, and we'll see the fallout from this.
Now I want to get back into engineering but virtually every job requires TDD and you are expected to show your understanding during a - live! - coding interview. I have no idea where to start.
Until this stuff is learned and (importantly, practised, on top of how to pass all the other stuff that goes on in modern technical interviews) then working in software engineering almost anywhere just isn't going to happen.
Fortunately there are some good resources online to help with this. For me, the most important lesson learned so far is the *why* of TDD, and why it's better than crafting unit tests after the code has been written. Dave Farley's Continuous Delivery YouTube channel [1] and Modern Software Engineering book [2] have been particularly useful. In fact, I am excited to work this way; this is a shift in understanding about how to build software well and ultimately, to be proud about the final product.
[1] Dave Darley's Continuous Delivery YouTube channel
[2] His Modern Software Engineering book
And so it's time to practice what I've been reading, and therefore a project is needed...