Title missing a (2008).
The oldest version in the WaybackMachine is from July 2007 https://web.archive.org/web/20070703081456/https://terrytao....
and here say May 2007 https://terrytao.wordpress.com/?s=Discovering+a+solution
Write a rapid prototype first (2007)
11–20 of 20 posts
Re: Write a rapid prototype first (2007)
#12[deleted]
Re: Write a rapid prototype first (2007)
#13The tips on how to prototype are very good. Let me give another perspective though:
You shouldn’t always prototype first, before mapping what kind of problem you have, at the risk of reinventing the (square) wheel.
Rapid prototyping is the holy grail software is known for. But prototypes are not always cheap, and almost always go to prod and turn into technical debt. In other disciplines the instinct to just try something first would sound ridiculous (e.g. let’s always figure out open heart surgery from scratch, it’s just a quick experiment, if the patient dies we figure out later).
I’m a fan of the Cynefin framework [1] as a higher level tool to figure out if I should prototype at all - even if not very precise, because at least it forces me to think about it.
Re: Write a rapid prototype first (2007)
#14I find it very surprising that he suggests writing the introduction at the end of the paper. He doesn't explicitly mention the abstract, so I'm assuming the introduction includes the abstract of the paper. If that's true, I find it impossible to write any paper without first working out a fairly fleshed out abstract. It usually takes about 50% of my time to just write my abstract.
The way I structure my prototypes, I have to have a sense of the existing state of the art, which I then leverage to propose my hypothesis. I do a version of this for programming as well, I try and identify state of the art methods in the field, and use that to guide my implementation.
Re: Write a rapid prototype first (2007)
#15I find it very surprising that he suggests writing the introduction at the end of the paper. He doesn't explicitly mention the abstract, so I'm assuming the introduction includes the abstract of the paper. If that's true, I find it impossible to write any paper without first working out a fairly fleshed out abstract. It usually takes about 50% of my time to just write my abstract. The way I structure my prototypes, I…
It’s much easier to write an abstract and intro once the rest of the paper is concrete and correct; it tells you what the strengths and important points of your paper are. You don’t necessarily know these until you’ve done the hard work in the rest of the paper
Re: Write a rapid prototype first (2007)
#16> [paraphrasing] get some good idea along the way devote a minute to write down a “stub” for that (just enough to jog your memory when you return), so as not to break your concentration or momentum
This "stub" or aide-mémoire doesn't define the idea, just evokes it. So you better come back while that memory is still fresh, or you will not be able to work out what it was!
Re: Write a rapid prototype first (2007)
#17He talks about how to begin a daunting task: linear order, easiest/most straightforward first, or a top-down "skeleton" first.
If it's daunting enough to be discouraging, consider doing tasks that quickly give you some sense of progress towards what like about it. To sustain your interest - your most precious resource.
This mightn't be most efficient, or give the best structure, but if it motivates you to do it, it will be far more efficient and better strucured than nothing!
Re: Write a rapid prototype first (2007)
#18The tips on how to prototype are very good. Let me give another perspective though: You shouldn’t always prototype first, before mapping what kind of problem you have, at the risk of reinventing the (square) wheel. Rapid prototyping is the holy grail software is known for. But prototypes are not always cheap, and almost always go to prod and turn into technical debt. In other disciplines the instinct to just try some…
One necessity for a successful prototype is that you have a pretty clear idea of why you’re making it and what you hope to learn. You also want to consider if the cost of making the prototype will be justified by those learnings. With experience you do this instinctively, as part of the process. You know what answers you need and how to get them cheap enough.
In the case of surgery, where someone’s life is on the line, it’s not going to be worth the cost.
Re: Write a rapid prototype first (2007)
#19He talks about how to begin a daunting task: linear order, easiest/most straightforward first, or a top-down "skeleton" first. If it's daunting enough to be discouraging, consider doing tasks that quickly give you some sense of progress towards what like about it. To sustain your interest - your most precious resource. This mightn't be most efficient, or give the best structure, but if it motivates you to do it, it w…
This is like an MVP, where you quickly find out if people actually want it; if they do, you get motivation. A step earlier is an actual prototype, where am inventor sees whether the idea works or not; if so, it's motivating.
Not sure how this applies to proof, which has to be perfect to work at all. Pehaps Tao's skeleton, then filling in the most crucial parts first, is exactly this.
Re: Write a rapid prototype first (2007)
#20I am a big fan of this approach. I have seen that if I stop and think about the problem too much in the beginning, it takes a whole lot longer to arrive at a good solution. Prototype -> Think -> Engineer. If you are lucky, you get to reuse some code from the prototype, if not that was hopefully a good lesson for the future.
[deleted]