I used to work like this, and the reason I was productive is I didn't write tests nor did I have to wait around for the compiler to run every few steps. Being a

I used to work like this, and the reason I was productive is I didn't write tests nor did I have to wait around for the compiler to run every few steps. Being able to visualise the result for your code is something that comes with experience, and usually on the web this is a lot easier when you're applying the same ~10 concepts over and over. But in a team, I would much rather have someone practice TDD than be perceived as more productive. Your code will stand the test of time and be easier for others to work with, which will cost less down the line (maintainability cost + fixing bugs cost, inevitable and a huge time sink without tests). I am now trying to think in a TDD manner and it's frustratingly slower, but ultimately a lot less stressful when I have something I can point to and objectively say it fits the requirements / business rules.