Comment by shardinator
10 years ago
I have to agree. My personal experience suggests if you want to get good at something, keep doing lots of it and aim for speed rather than perfection. You'll end up being speedy and get closer to perfection, than if you just try for perfection.
But one good counter example does come to mind - designing a database schema.
I'm trying to wrestle with what the difference might be. I think Markov processes, e.g. processes where the future state depends on a prior state, are relevant.
Maybe we could say tasks are either "strongly Markvoian", that is, how well we do them now will influence our future work and hence we should really think them through, e.g. designing a schema. Weakly Markovian, in which case there may be some future impact but not much, and so we exercise caution but "done is better than perfect". And finally non-Markovian - e.g. throwing out the garbage, cooking dinner, most emails - getting the thing done is simply a pass/fail and so we just have to do it, quality is relatively unimportant.
I think what I'm saying is, most tasks will be weakly or non-markovian, so we should "move fast and break things", but every now and then there'll be something we need to do that is strongly markovian. For such things we should be prepared to take a step back and give ourselves a little extra time, so things don't blow up further down the track.
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.
I can think of lots of more things, where doing them fast initially makes sure you'll never learn them:
* Typing on a keyboard
* Sharpening a knife
* Driving a car.
It seems more like a question of doing things a lot and very focused, than focusing on speed initially.
All of my car/motorcycle track instructors were big believers in "Slow is smooth, and smooth is fast".
Basically go slow and work on the correct form/line/being smooth/etc... Once you have that down, you are ready to go fast and you will be better/faster than someone who hasn't gotten the flow down at a manageable speed first.
I used to teach guitar and always had to tell students to practice it slowly, but perfectly first, and only try to speed things up once they had the basics mastered.
Speed is impressive, but you literally have to learn to walk before you can run!
Tried to teach myself to touch type. I can kind of do it, but its just so slow compared to my normal typing.
Measure your writing speed. Aim for 70-80 WPM. If you get that speed then it's a) enough and b) it doesn't matter at all if you "touch type" properly or have invented your own typing system.
5 replies →
It depends on your goal. Even with database schemas, iterating quickly optimizes for learning and skill improving. Aiming for quality tries to optimizes for creating a quality product faster. Still, taking some time for skill honing might be better than trying to design the perfect system on your first try.
I'd say it depends on your current skill level rather than on a task property like "strongly Markovian". Learning has diminishing returns. At some point more learning is not worth it anymore.
Don't bang frenetically on walls too. It's very very good to be able to reach deep understanding without hyperfast iterations. There will be times where you don't have that luxury too. Make haste slowly, balance.