> Dig into past research.
> If you're excited about an idea, it's super tempting to sit down an immediately get going. But you shouldn't do that until you've done some cursory research about how people have solved it before. Spending a few days researching the topic always completely changes how I am going to solve it.
https://archive.jlongster.com/How-I-Became-Better-Programmer
My workflow is:
* Learn the concept
* Implement it
* Research prior art
* Throw away my first implementation and rewrite it properly
(Edit: formatting)
- 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 :)