Move your feet | Hacker News Reader

Move your feet

swanson.github.com

350 pointsswanson79 comments

My father used to give me similar advice when I struggled with physics problems: "Keep your pencil moving."

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."

Or, to use a local quote, "Startups rarely die in mid keystroke. So keep typing!"

http://www.paulgraham.com/die.html

That sounds both promising and scary. Especially considering that octopart.com, featured in this article 5 years ago is on decline: http://www.quantcast.com/octopart.com

Starting up is tough.

We've been focused on increasing engagement, conversions and API traffic and have made quite a bit of progress there but those metrics aren't included in the Quantcast stats.

Are you able to pay yourself market salaries yet? 6 years passed since Octopus started...

I think these are all variants of what we call 'pre mature optimization'.

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.

I agree 100%. More if I could - the best way is to just get stuck into it and get some momentum. Though I think reasonably early on you step back and check you're doing things optimally.

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.

Would you mind expanding on the details of your running form that you think are "bad"? Did you attempt to change these immediately? Change to what? How'd it go?

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 did you do wrong?

The OP's argument is wrong. BOTH activities require learning the basics.

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 running with correct form is not an intrinsic, instinctual human ability

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'

If by latest running shoe you meant latest cushioned, arch-supporting, spring-embedded running shoe, I disagree. That kind of shoe will cause you to run very poorly and will probably injure you, unless you pay careful attention to your form and practice hard. If, on the other hand, you meant a barefoot running shoe (partial to Vivo myself), those induce a much more natural form and make it easier to maintain. I've been running with a barefoot shoe for years with just three principles, which I discovered mostly on my own by feeling it out before finding out that I was right: 1) Pelvis aligned with the ground, 2) Spine erect, shoulders back, 3) Strike ball first.

Running correctly is natural/instinctual. Running poorly is what we are raised to do in crappy over cushioned shoes. Watch videos of barefoot kids running, their form is great

What's wrong with "bad" form? The guy ran his races, maybe had fun, didn't mention injuries. What's the problem?

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.

I asked a friend who is a sports medicine doctor about this. She said pretty much what you said:

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 won't speak for all runners, but for me, running with incorrect form is a fast way to make myself immobile.

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.

On what surface do you run?

You have to make the distinction between injuries caused by too-much-too-soon and long-term injuries caused by the method of running. 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.

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. [1]

http://en.wikipedia.org/wiki/Barefoot_running#Health_and_med...

This seems to be a reasonable review of long-term injuries (specifically osteoarthritis):

http://www.jaoa.org/content/106/6/342.full

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".

An article by Cal Newport goes into depth on when "just get started" makes sense, and when it's a bad idea: http://www.iwillteachyoutoberich.com/blog/getting-started-is...

Wow, that was an awesome piece that I hadn't seen, thanks for linking to it.

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.

In short, if you're starting a business, get started. If you're submitting a publication to one of the most exclusive journals in computer science, think things out first. Fair enough.

Programming is a skill, which means that learning programming languages and techniques is not as simple as accumulating facts. No written guide to programming, no matter how thorough, will ever be sufficient because there are countless details which have to be left out, details which you can only assimilate while engaging in the practice of programming.

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.

> No written guide to programming, no matter how thorough, will ever be sufficient [...]

Unless, perhaps, if you include exercise and solving them as an integral part of that written guide.

Well, yeah, but where would anyone ever find something like that?!?!

Are you asking seriously?

Negative.

Wanna improve your running? Start doing squats. The way to build up speed is to increase the force each step has against the ground. Moving your feet is fine, but if you train your body to push off the ground with more muscle you will certainly go faster.

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.

I agree 100%. Squats (actually leg extensions and leg curls are better for runners) are the secret, the thing people who didn't bother to do the research don't know. They don't have the edge.

Paralysis via analysis is bad, I agree with the post's main point. But mindlessly grinding is equally bad.

Great engineers ship. It's helpful to remember that no matter what you write, someone will be able to criticize it. It's a lot easier to write code that does its job than it is to write code that's going to be critically evaluated by a huge panel of theoretical, hyper-critical programming gods.

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.

Good tip, though we all know half of the web is built using that throw-away-soon / it's-just-an-mvp code. there is nothing as permanent as temporary code.

Even more common is the code that was never written.

The funny thing is that TDD is actually a great way to break paralysis analysis. State what you want your new feature to do, get it working, improve it, or don't... you've got your ass covered so you can always make it more "perfect" later on without worrying about breaking anything. Without the safety net there's a pressure to get it right first time as it might be too risky to change it later.

This is true only once you've decided on your tools, and rails has such an outrageous selection that I can see people getting stuck before they start.

Should I be using Test::Unit or RSpec? Maybe Cucumber? Should I be testing this functionality as unit tests, functional tests or integration tests? Should I seed the database with fixtures or factories? If I want to use factories, should I use Machinist or Factory Girl? How am I going to test client-side functionality? Selenium tests, or webrat or javascript unit tests? If I'm using javascript unit tests, then do I use Jasmine, or QUnit, or Mocha?

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.

Great perspective. I called my dad last night and he told me he'd been thinking about "this LastPass thing you keep telling me about" and that he wanted to try it out and asked me if it basically was the gold standard or are there other companies that do it better.

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.

But that is why Rails promotes defaults. Only once you begin to see shortcomings with the defaults do you need to start looking for something else that may be a better fit.

Ha! Remember this comparison with java back in the day? http://www.youtube.com/watch?v=PQbuyKUaKFo

Even more than that, I've found that TDD allows you to work out in your head how you want everything to work black-box style, and worry about the implementation second. By starting with a list of inputs and outputs that you expect, it gets you started moving toward your goal immediately. And if you don't have that list, then you already know what step one is.

trying to write out documentation on how to use something is as helpful as TDD in some cases for the "making you figure it out before you start".

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.

I built my first and second rails projects without writing any tests. These were very small projects, just a few weeks of work on the larger one. By the time I was two weeks into the second project, I knew I was wasting a lot of time because I kept doing similar tests in the console when writing or modifying new code. But by that point I already felt like I had too much uncovered code to start writing tests. Cause if someone looked at it and saw just one test, what would they think ? (I know, right?)

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.

That's the problem that can be witnessed in software development teams too. Analysts are over-represented in our craft so there's a real risk of analysis paralysis. A potential remedy is a more impulsive type on the team who prefers to start playing with the problem. You should be careful not to stop him from doing that. If there's no such a person then someone, preferably a leader, should move on to prototyping if the project got stuck.

All that applies to individual software development too. If you see no progress because you are constantly analyzing then start prototyping.

Enjoyed the post thoroughly. Been working in software for 6 years now and I can remember countless instances where I could not get working code out because I wanted to achieve perfection. It wasn't until last year when my mentor told me the same thing, don't be shy of typing, write the damn code. I am happy for you that you have this figured out early in your career.

Best advice I got from a friend about programming is: make it work, then make it better, then make it faster.

Nice post, I can relate a lot as a fellow engineer and a wanna be runner. haha I think in software a lot of what impedes progress is attitude and reputation protection. Since we assume there is a "correct" way to do things we spend a lot of time trying to learn that instead of just shipping something. My thought is that we have a fear to put something non-optimal out there because we think another engineer is going to look at our code and assume we are an idiot if we didn't execute every detail to perfection, or didn't use some particular pattern that's popular. I think this is kind of sad since solving problems and creating something interesting is really what software is all about. When you're starting to be a runner I think the attitude is different, people respect the effort of just getting out and doing something. We also know the body isn't going to respond instantly, pushing too hard to fast will cause injury instead of improvement. Yet somehow in knowledge work we assume learning time is zero, even though we know this is never actually the case. Hopefully some day the culture will shift to more like that of running, until then it's more of an individual battle to have the courage to just ship something.

- Dave Mathew (@mathewda)

True. But not forget that you have tens of years experience of walking and running before you decided to improve your running. If you would have that many years of Ruby experience you would have better chance to get to TDD nirvana too.

This. That said, since the OP is already a developer I would think he has sufficient base to dive into a RoR project should he desire.

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.

Yeah, this spoils the analogy somewhat. Human beings are born to run. To get better, all you need to do is run a lot.

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.

Hmmm, While a agree with the general gist, I've seen many MANY projects fail because of "just starting".

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.

I can relate to this quite a lot.

Protip: Now it's time to go outside, the satisfaction of running outside exceeds that of running on the mill by far!

The form is also quite different. I cannot run on a treadmill due to my gait (though while I run outside I do concentrate on improving my form).

I have been doing professional RoR development for a couple of years. I have made several attempts to use proper TDD, but always revert back to old habits.

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.

I've only recently become much better about testing and TDD in general and it's only since I actually started trying to do it. It's much more rewarding than I ever gave it credit for and it gives me an opportunity to keep my code from violating a lot of bad design practices.

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:

    def save_image(s3_library=AWS::S3::S3Object)
      s3_library.store(...)
    end

I just was working on this today. Typically you would put your AWS call in the method - this separates it into an injectable dependency that you can mock and set expectations on in your tests. In fact, once you start doing this, you quickly realize why the Law of Demeter is such a good idea! Stick to testing only the behavior of the current class and relentlessly stub and set expectations for collaborators - each collaborator already has its own set of unit tests (presumably) so testing the results of collaborators does not add value and makes tests harder to maintain.

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.

My problem with TDD is that I never know what I need to test, until I've at least started spec'ing the project, and I don't do that on paper. I do that in code.

I face this issue as well. I see the value in TDD but at the beginning of a project I often end up wasting a lot of time churning through articles on TDD and researching the documentation of various test frameworks because figuring out what I need to test before I start writing code never seems to click with me. I believe it's a skill that I simply need to improve but my progress is slow-going which often gets frustrating.

This reminds me the best running advice I ever received. In a comment when asked how to run fast, a very accomplished ultra runner replied, "If you want to run fast, run fast."

Nice, I also like this one: "You begin running as fast as you can, and then gradually increase your speed." (sounds better in Hebrew, taken from the cult movie "Operation Grandma")

Or: "It doesn't get any easier, you just go faster." -- some dude who was a pretty good cyclist.

You can hurt your knees quite easily by "grabbing any pair of shoes"... like I did. It took me 3 months to recover. Before you start running, buy a pair of shoes that better fit your body type[1]

[1] http://www.therunningadvisor.com/running_shoes.html

In addition, I advise most people not to run in concrete. I used to pound the pavement (literally) on a daily basis and I am pretty sure my knees are in worse shape for it.

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.

Or scratch that and go barefoot. Let your feet do what they were meant to do by themselves: running!

Yep. The problem with modern shoes is that they give people the bad habit of hitting the ground with their heel, the shoe compensating the shock with some kind of absorption.

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.

For the beginners: Just start very gradually. Your calves will get extremely sore in the beginning. Soreness isn't harmful, but it's painful.

An interesting corollary to "Move your feet", instead of overanalyzing, is that you can't get good at something without doing it repeatedly. When you do something over and over again the analyzing mind starts noticing things that often turn out to be useful. The problem with the mind is that it does not really seem to know when it has enough information. As in the running case, the best thing would be to go out running (not too often at first, to avoid injuries), and gather information about running. But the mind does not mind to just analyze and analyze the same insufficient information available.

Aka "just fucking do it". The #1 cause of startup failure is making yourself very busy pretending to work

Ship.

Yep, "Perfect" is the worst enemy of "done". Users don't view source before they open their wallet. Don't write bad code, but don't avoid writing code, as it will be never be perfect.

I'm not sure that programming and running are both skills that are innate to humans. I started running because I was inspired from reading Born to Run. I basically went out and did it. Little training is required. There is some skill involved, but mostly just heart. One has to learn the skill of programming. I can't tell my son to "go program", but he can "go run".

Nice analogy!

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

Very well written, honest and so true, I can relate so much, reminds me of this excellent post: http://www.zemanta.com/fruitblog/i-bet-you-over-engineered-y...

Yep.

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.

I disagree with the sentiment that the best way to move forward is always to start hacking. I too tried to learn TDD by simply writing tests first, which was frustrating and unproductive.

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.

I think the last part of the post where he meets the ex pro runner is key. There's the old adage of "practice makes perfect" whereas in reality it's "perfect practice makes perfect". Learn how to run properly first (much harder than it looks) then start to add the miles / pace. Chi Running is a fantastic book for this (although it's incredibly verbose). A key thing I learned there is the value of a metronome to aid in cadence.

I guess this is true for many activities, not all. If my to do list app has bugs, the worst that could happen is some users will get annoyed and leave. If my medical equipment software has bugs, people might seriously get injured or even die. In the first case, just start and get it done makes a lot of sense. In the second case it doesn't.

Nice article and nice advice though.

I don't think that's the point of this article. The real point is that you learn through actually doing stuff. You can read as many books as you want about designing your medical equipment, but I can be pretty much anything that you won't get it right the first time anyway. So read just as much as you need to get you started, get to real work, and soon you'll find out what else you have to read about. And so on and so on. Try, fail, educate yourself, repeat. With your to do app release after 3-4 iterations, with medical equipment release after 30-40. But keep on trying and actually doing, vs meditating about it.

This is how I see this article, and therefore it applies to both, to-do apps and more serious stuff.

Also depending on your goals though, for recreational purpose, it probably doesn't matter what approach one takes. I can't compare playing golf with running. Golf is probably a thousands times harder than running just to get started. To get the thing right and do it well in the long run, start with the proper form is crucial.

This is a common problem we've been encountered through time. When I find something news, I will search "the best of" .. right after that. And leading to that is a lot of search, research, finding cool things. Now I rather create work things then make it sexy like ladies later :D

I still believe in reading books and solidifying your fundamentals first before jumping into a big project. I've learned the hard way that just jumping into and try to figure out things as you don't understand does not work for everyone.

Yeah, specs are that hard.

Now I know my disease, a septic shock variant of analysis paralysis.

Reply on news.ycombinator.com