Testing
My first proper full-time position 10 years ago was a mid-level Rails dev at touchlocal.co.uk, big tower near the MI6 headquarters in London. Exiting times and a perfect start to put the mere six months experience I had with Rails into use. The first two weeks I was assigned to fix the test-suite, which had been neglected over the last busy months before launching the product, as it is common.
I still consider this as one of the most important moments in my career and writing tests stuck with me. Once the test-suite was usable again, brought up to the then current codebase, it quickly showed benefits in an application with a front- and back-end, where work on a data model requires tests on many more places than the user-story was narrated around. In any sized team, especially with new developers joining in, the potential fallout of a small change to a method gets harder to estimate. Automated tests are the only help and can surpass even the knowledge of th elongest involved team-member.
Nowadays I have a small team to lead at Naiku and find myself in the position that I have to remind my team to write not just good code but good specs alongside. The emphasis is on good specs, because there are so many ways to write tests that aren’t worth the effort. Edge-cases with bad user-input or unassigned variables must be covered just like the method’s best case. Writing tests for every of your methods will also push you to split methods, making the problem easier to test.