FWIW I’m a former senior-less junior that programmed himself into a hole. My blog and conference talks are exactly the material that I’d loved to have had ~10 years ago.
Not sure if I’d have been smart enough to take my advice though. ;)
>Every change would inevitably break tests (not functionality!) and developers were spending more than half their time wrestling with the test suite.
I find that this invariably happens because the team tries to test implementation at a very low level rather than behavior at a high level.
I blame an overemphasis on unit tests over integration testing (e.g. J B Rainsberger's inane rant) and tutorials that imply that, for example, if you build a class you have to have some tests for that class.
At a previous company, someone established a "rule" that every "new function or method" needed its own test. Unless you lucked out with a lax reviewer (like me!) , your code would not pass review if this wasn't followed. Meanwhile, there were basically zero integration or e2e tests. People spent more time adding and maintaining useless tests...
These sound like checksum tests. If you touch anything, they fail. That's all they do now, alert you that yes, you touched that code, now go figure the new checksum for the next poor soul.
There were lots of brittle mocks. I think we even did mock out the Ruby equivalent of the HTTP client.
Every change would inevitably break tests (not functionality!) and developers were spending more than half their time wrestling with the test suite.
All of us could have used this article.
Please always strive to improve your practice. Commit things that aren’t perfect, but try to internalize best practices over time. Gradually raise your own code quality bar as you get better.
Learning from posts like the OP is super important if you don’t have a good senior Eng on your team. A group of smart juniors can easily code themselves into a hole of left to their own devices. I know this, because I did this.