Along similar lines, John Carmack once said: "If you aren't sure which way to do something, do it both ways and see which works better."
Starting up is tough.
Start. Starting and finishing is very important. Even if what the first iteration of that produces is actually horribly bad. By the time first iteration ends, you will be in enough momentum to make next iterations awesome.
One day I started running, just like the OP: I put on some shoes and ran. Eventually I followed a co-worker into a 5k race, 10k, half marathon, and eventually full marathon.
Much later I started a new job where one of my co-workers was an ex-pro runner. We went running one day and had to stop me right at the beginning: my running style was awful - I mean I got from point A to point B, but even with 1000s of kilometers under my belt I hadn't gotten good at it! It took me ages to unlearn and relearn to run.
In you 5k to marathon training, what sort of paces did you typically train at? Was it all a jog or did you do any speed work?
Thanks, from a curious bystander.
What parent, and the OP, did wrong was not understand that running with correct form is not an intrinsic, instinctual human ability. You must learn to do it correctly.
That has to be the most ridiculous sentence I've read on hn in a while. Obviously running with the latest running shoe will skew 200,000 years of human evolution, but humans are very much well adapted for running 'correctly'
I say this as a barefoot runner. I've stopped caring about "running naturally" or similar nonsense. If you look at the research, things that correlate with injury are mostly doing "too much, too soon". There are a couple other things, but from this I conclude that if you do something gradually (like build from 5k to a marathon over some years), then you are minimizing your risk of injury. But if you do something non-gradually such as couch to 10K, or 10K with form A to 10K with form B, you are increasing your risk of injury.
Certain types of shoes that may or may not prod you into some "more correct" form do not correlate with lower injury rates. I don't think much research has been done on bare feet, but reading barefoot runners' forums leads me to believe injury rates are at least in the same ballpark as any other group of runners.
1) Injury rates are about the same no matter what shoes you wear. (or don't wear)
2) Quick changes in intensity (couch to 10k etc...) often lead to injury.
3) Cross training reduces likelihood of injury as does proper stretching.
4) What works for some people doesn't work for others. (eg. for some people barefoot running is better but that isn't true overall)
I've had bad knees since I was 16, with surgeries to boot. Even 20 minutes of running used to require an ice pack for half an hour, and walking would be difficult for at least the next two hours. I suspect it's somewhat genetic, since both my father and brother also have frequent knee injuries.
Barefoot running has allowed me to increase both my range and my speed without causing any pain or swelling.
As for long-term injuries (non-transitional), the jury's still out, but all clues so far point towards barefoot or minimalist shoes being the most beneficial. 
I've seen some of the studies referenced in that review, and what I gathered is that elite level running (in shoes) correlates with signs of osteoarthritis (seen in x-rays), but does not correlate with increased symptoms of osteoarthritis (runners did not report more pain than non-runners). If I recall, this was from the small study that included only Finnish elites. Other studies (the Lane study) have not found an increase in signs of osteoarthritis in non-elite (shod) runners.
Anyway, it's an interesting question.
> To say that barefooters have just as many injuries as other runners might simply be a consequence of many people transitioning too fast from inch-thick heels to barefoot.
It may indeed. I'd just like to add that I personally know shod runners who never get injured (former coach), so any hypothesis that claims "shoes lead to acute injury in all cases" is simply false. Of course, the more interesting question is what happens in "most cases".
I think it could be summarized as: If resources are sufficient and exact implementation does not matter, just get started, but when resources are scarce and there are many different possible ideas, with hugely different potentials, just starting won't get you very far.
No one would suggest that you could become a world-class singer by
merely going through a book on the subject. With these physical
skills, it's obvious that learning involves doing something other than
just absorbing knowledge. I think that, with programming, its nature
as a skill is often overlooked because it's knowledge work. The key
thing to keep in mind is that you must actually do programming in
order to learn languages and techniques.
In Matt's case, he was also trying to develop a new habit - using TDD.
Many aspects of programming are like this. Perhaps you want to start
documenting your code more or you want to start doing daily standup
with your team or _whatever_. These are all habits, some involving
just you and some involving your team or organization. Recognizing
them as habits will allow you to apply techniques for successfully
developing a new habit.
Unless, perhaps, if you include exercise and solving them as an integral part of that written guide.
Computer programming/rails learning is a lot of the same. Not sure what you mean by going right into the mastery of the language. In most compsci/programming stuff there are a lot of fundamental similarities between languages and really the differences can be challenging at first but are easy adaptable after a few examples and maybe a seg fault or two.
I guess my point is that every art form has a proper way of preparation. Move your feet, sure you will get better, but if you only follow this montra you are sure to run into a wall.
Paralysis via analysis is bad, I agree with the post's main point. But mindlessly grinding is equally bad.
A good thing to do when you find yourself paralyzed in a rut is to tell yourself you're going to write the first one as a throw-away prototype, whose purpose in life is to explore the solution space and learn what you need to do it right. Give yourself the freedom to do whatever on that first version. The learning is always the most valuable part of any deliverable anyway.
The answer to most of these questions is really just a matter of personal preference, but you can see how easy it is to get overwhelmed even after you've decided to do TDD on Rails.
I told him that I could discuss the options with him for a half hour but the point isn't to pick the best password manager, the point is to use a password manager. There are 10 different companies in this space and telling him about all of them will only create a barrier to entry. The huge wins you get from the macro-optimization of starting far outweigh any micro-optimizations between different providers.
Where TDD shines is giving you a tiny testbench to see that your implementation is heading in the correct direction before you get too far.
The real reason is some kind of fear, that I do not exactly understand. Luckily, these were very small projects and never became anything I had to actually support or the tragedy would have been a lot more substantial - as it is my main loss was my own education.
My third rails project I forced myself to write specs and NEVER use the console for anything that slightly resembles testing - even if its just "trying things out". I put it all in tests and code and spent the effort to get my testing setup really fast and slick.
I've written dozens of tests now and still have a lot to learn but I'm definitely seeing a lot ofvalue. Hopefully it is not just cognitive dissonance. I've spent way more time on tests than on the actual code. I expect though that part will get better. I've been programming for sixteen years, but only testing for a few months.
One thing that really helped me is having some examples - the first I looked at were the tests that come with Devise, the other was the specs in Diaspora (http://github.com/diaspora/diaspora) . They have like 1700 tests for that rails app. I'm doubt they are a paragon of testing virtue, but it is a hell of a lot more relevant than the same trivial examples I've been reading in blogs for the last decade.
All that applies to individual software development too. If you see no progress because you are constantly analyzing then start prototyping.
- Dave Mathew (@mathewda)
Perhaps if his domain were radically different (say, embedded systems) he would need to explore the fundamentals of web application architecture before putting together a rails app.
That said, I still remain on team "learn the fundamentals", and have yet to find a truly compelling reason to take the "grok as you go" approach. Maybe I'm just stubborn.
Compare this to swimming. There's no guarantee at all that you'll get better just by practicing - gliding through the water is more a matter of technique, and it doesn't come naturally to most people. One usually needs expert coaching.
I think programming is probably more like swimming than running.
Coming from games I can whip out C/C++/OpenGL and get something bouncing on the screen. I can prototype. But at some point I need to add in artists and designers at which point it will be months till I have anything close to Unreal or Unity.
But I don't know Unity or Unreal so I stick with C/C++/DirectX and then hit that wall.
I assume the same is true for other areas. I could write webapp in cgi/perl/html/js or cgi/python/html/js or php/html/js those are what I know. But if I chose Rails or insert-framework-of-the-month-here I'd gain so much functionality.
Back to games. I could hack an iOS game together in ObjectiveC/C++ or I could choose a framework and get free server side highscores, free in app purchase framework, free social network integration, etc... etc... etc...
So yes, you can fail because you never take the first step. But you can also fail because you don't realize that the few hours it takes to make a working prototype is actually only 1% of the work you have to do to ship and that if you'd have chosen a framework/engine you'd start at the 50% or 75% mark instead of the 0% mark.
Protip: Now it's time to go outside, the satisfaction of running outside exceeds that of running on the mill by far!
I can think of four reasons why this happens to me:
a) there aren't many good examples of applications built using TDD available. see http://s831.us/PM6jkb ,
b) TDD becomes very difficult when your application incorporates complex 3rd party data sources and APIs,
c) feels like you are writing the application twice (once in Cucumber/RSpec and once in RoR),
d) pressure to "get something done" results in backsliding.
By contrast, I have been running for exercise the last couple of years. Running is not competing with an established habit and I see immediate benefit from almost each run. I highly recommend getting a FitBit or Nike+ SportWatch GPS and signing up for a stretch goal. For example, successfully ran the Dipsea this spring. Now training for half marathon in October.
Addressing a few of your points:
b) Absolutely, it's not easy to keep testing when incorporating 3rd party data sources and APIs. I've found that Dependency Injection is a hugely useful tool for attacking this kind of situation. Take this small snippet:
c) It sure does feel like you're writing the app twice and I've fought with myself over this very issue. I have compromised with not forcing everything to have a test and instead to test things that aren't default crud. Alternatively, look at it as an investment in maintainability and refactorability.
I recently switched away from using Cucumber to using Rspec's built-in integration testing methods and I feel a lot happier writing integration tests. I encourage you to evaluate why you think Cucumber is a good idea and seriously consider discarding the layer of indirection that gherkin introduces.
If you want to run, find a nice track (that isn't asphalt) or a nice grassy or dirt trail. It's a bit dirtier, but it feels way better.
The "secret" is simple is to simply run using the ball of the foot (the fleshy part at the end). You run on the tip and use the heels as a natural shock absorber and preserve your knees. This will have the added benefit of strengthening the heels as well.
With that in mind, running barefoot is pretty safe (and you can do it outdoors with Vibram-like shoes).
I do that kind of running regularly as part of the warmup routine at my Taekwondo dojang.
Kent Beck, rediscoverer of TDD (who surely can't be expected to have analysis paralysis on how to do TDD), actually wrote about exactly this a while ago: http://www.threeriversinstitute.org/JustShip.html
Nike hit gold with "Just do it" 'cause it really does sum things up.
If nothing else, throwing yourself into something will give you a context and sense of the immediately relevant parts of the subject that will make your eventual research and preparation much more effective.
That approach seems similar to learning to program by typing random words into iPython until something happens - it could work, but it's going to take you months to even discover a "for" loop. It's better to read a tutorial and the documentation while experimenting.
I finally caught on to TDD after watching the screencasts at destroyallsoftware.com, and I highly recommend it to others wanting to learn. TDD is a completely different way to develop, not just an additional step on your old routine.
Nice article and nice advice though.
This is how I see this article, and therefore it applies to both, to-do apps and more serious stuff.