
Move your feet - swanson
http://swanson.github.com/blog/2012/08/27/move-your-feet.html
======
noahlt
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."

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

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

~~~
dennisgorelik
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.

~~~
andres
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.

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

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

~~~
Kiro
What did you do wrong?

~~~
zacharycohn
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.

~~~
hnriot
_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'_

~~~
jrajav
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.

------
SatvikBeri
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...](http://www.iwillteachyoutoberich.com/blog/getting-started-is-bad-
advice/)

~~~
jorleif
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.

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

~~~
eru
> 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.

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

~~~
eru
Are you asking seriously?

~~~
mattdeboard
Negative.

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

~~~
muhuk
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.

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

~~~
eranation
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.

~~~
unoti
Even more common is the code that was never written.

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

~~~
phleet
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.

~~~
latortuga
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.

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

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

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

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

------
mathewda
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)

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

~~~
doktrin
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.

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

------
tzaman
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!

~~~
yawgmoth
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).

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

~~~
dpcx
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.

~~~
Scottopherson
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.

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

~~~
eranation
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")

------
rodolphoarruda
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>

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

~~~
epsylon
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.

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

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

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

~~~
stakent
Ship.

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

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

------
skrebbel
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>

------
eranation
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...](http://www.zemanta.com/fruitblog/i-bet-you-over-engineered-
your-startup/)

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

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

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

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

~~~
rytis
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.

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

------
nXqd
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

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

------
vassilevsky
Yeah, specs are that hard.

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

