[noam_k]

I can't agree more, and I can't disagree more. There's a great deal to be learned by experimenting yourself.

My workflow is:

* Learn the concept

* Implement it

* Research prior art

* Throw away my first implementation and rewrite it properly

(Edit: formatting)

[chubot]

Yeah I kinda think people are always "learning from their last mistake" (and that's definitely true for me)

- Sometimes you hack, and you end up with a mess. And then the lesson you learn is to study the prior art first.

- Sometimes you spin your wheels reading stuff that isn't actually applicable to the problem you have. Then the lesson learned is to "do the simplest thing that could work", "solve 80% of the problem with 20% of the effort", etc.

So to me, programming is really a cycle of learning, and you can't really generalize the order of doing things ... It's iterative stumbling and learning, in both orders :)

[rkangel]

Yes - I quite often get into research paralysis where I keep looking and trying to work out the solutions to different problems I'm going to encounter and never getting started. Whereas if I start protoyping I learn a lot very quickly.

[yard2010]

This is the way. Unfortunately this is not going to work, not in a startup environment. You probably do everything except the throwing away and re-implementing part..

[rob74]

Nor in any environment where a client is paying you to develop something. Try showing them an MVP and then telling them "ok, now I know how to do this I will throw it away and redo it from the beginning". Not to mention that, with unclear and constantly changing requirements, you are unlikely to ever arrive at a point where you can say that...

[8n4vidtmkvmk]

+1 I think there's something to be gained by just trying it your way first. Maybeyou'll come up with something new and insightful by not tainting your brain first, and if not, you will at least gain a deeper understanding of the problem space.