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?
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.
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.
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.
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.
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.
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.
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 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.
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")
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]
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.
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.
[+] [-] noahlt|13 years ago|reply
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|13 years ago|reply
http://www.paulgraham.com/die.html
[+] [-] kamaal|13 years ago|reply
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.
[+] [-] mrspeaker|13 years ago|reply
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.
[+] [-] pmahoney|13 years ago|reply
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.
[+] [-] unknown|13 years ago|reply
[deleted]
[+] [-] Kiro|13 years ago|reply
[+] [-] SatvikBeri|13 years ago|reply
[+] [-] jorleif|13 years ago|reply
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.
[+] [-] aswanson|13 years ago|reply
[+] [-] nonrecursive|13 years ago|reply
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|13 years ago|reply
Unless, perhaps, if you include exercise and solving them as an integral part of that written guide.
[+] [-] rickdale|13 years ago|reply
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|13 years ago|reply
Paralysis via analysis is bad, I agree with the post's main point. But mindlessly grinding is equally bad.
[+] [-] unoti|13 years ago|reply
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|13 years ago|reply
[+] [-] ollysb|13 years ago|reply
[+] [-] phleet|13 years ago|reply
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.
[+] [-] wccrawford|13 years ago|reply
[+] [-] jeremyjh|13 years ago|reply
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|13 years ago|reply
All that applies to individual software development too. If you see no progress because you are constantly analyzing then start prototyping.
[+] [-] sood|13 years ago|reply
[+] [-] AtTheLast|13 years ago|reply
[+] [-] mathewda|13 years ago|reply
- Dave Mathew (@mathewda)
[+] [-] drunkenfly|13 years ago|reply
[+] [-] doktrin|13 years ago|reply
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.
[+] [-] neilk|13 years ago|reply
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.
[+] [-] greggman|13 years ago|reply
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|13 years ago|reply
Protip: Now it's time to go outside, the satisfaction of running outside exceeds that of running on the mill by far!
[+] [-] yawgmoth|13 years ago|reply
[+] [-] stevewilhelm|13 years ago|reply
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.
[+] [-] latortuga|13 years ago|reply
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:
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.
[+] [-] dpcx|13 years ago|reply
[+] [-] wmat|13 years ago|reply
[+] [-] eranation|13 years ago|reply
[+] [-] wiredfool|13 years ago|reply
[+] [-] rodolphoarruda|13 years ago|reply
[1] http://www.therunningadvisor.com/running_shoes.html
[+] [-] JonLim|13 years ago|reply
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.
[+] [-] pilgrim689|13 years ago|reply
[+] [-] jorleif|13 years ago|reply
[+] [-] ezl|13 years ago|reply
[+] [-] stakent|13 years ago|reply