Comment by sheepmullet
10 years ago
In general I disagree. I learned far more in 6 months at a "high quality" shop working excruciatingly slow than I did in the 5 years at the previous job where I banged out code as fast as possible.
I feel like when you focus on speed you very quickly learn just enough to get the task done quickly. And then your progress stalls.
Perhaps it depends on your goals.
I find that when I'm doing any work that involves modifying existing code, there's a huge difference in how quickly I can work when I'm touching code that was originally written by people with different work styles. Usually I can sail through the more methodically-written stuff. When the time comes to make changes to code written by the people most fond of uttering, "The perfect is the enemy of the good," though, progress slows to a crawl. Adding new features without introducing new defects to that code is like trench warfare.
That said, much like the article says, the fast workers did tend to get assigned more new tasks. I think maybe this was a huge win for them. From a wider perspective, though, it's a bit tragic because it results in this inexorable downward spiral in terms of code quality. Of course that worked out well for them too because more defects meant more opportunities for them to cape up, swoop in, and save the day. I can't remember who it was who said, "Beware of your firefighters, they are probably your chief arsonists," but there's a lot of truth in that statement.
In that boat right now, but instead of 5 years in, 1.5 years in. I've been reading books on design patterns (we barely use them, you should get an idea of how bad it is here) and just in general trying to be better.
Good on you. I left a place a little while back that taught me all the things I now know to look out for when I eventually start my own business or interview at new places.
Read Refactoring by Fowler. You'll learn far more why and how from his prescriptions than the GoF's descriptions.