
Write a rapid prototype first (2007) - throwaway3157
https://terrytao.wordpress.com/advice-on-writing-papers/write-a-rapid-prototype-first/
======
CptFribble
To echo other comments, I've found this works for creative/fiction writing as
well.

I forget where, but I once heard that writer's block is what happens when you
try to create a final draft on the first try.

~~~
hyperpallium
If Michelangelo did drafts and studies, why can't I?

------
olegious
This is great advice for almost any problem, not only math. I've used the same
approach when programming, thinking through product problems, even thinking
through issues that come up in life- describe the problem and the outlines of
potential solutions. I find this brings clarity that's not always present if I
just think through problems in my head.

------
hcarvalhoalves
The 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.

[1]
[https://en.m.wikipedia.org/wiki/Cynefin_framework](https://en.m.wikipedia.org/wiki/Cynefin_framework)

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

------
codr7
I do this with code, which is my main creative medium these days.

First I solve the problem, without giving a damn about anything else.

Then I gradually improve my solution until I understand the problem well
enough to drastically improve the architecture, at which point I either
refactor or start over from scratch depending on which takes less effort.

------
fooker
I 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.

------
phsource
> In particular, it is often difficult to make the (important) decisions about
> the organisation of the argument, and selection of good notation, until a
> large part of the paper is already written

This is very true. When writing a blog post in China during the earlier parts
of coronavirus [1], I had drafted an initial version where I just went through
my experiences in chronological order. Only after writing it all down did
themes emerge in how I finally structured the article.

This really speaks to the power of interdisciplinary concepts though. Writing
an essay by writing an outline first and then filling in the details probably
predates rapid prototyping by eons. It's cool that it all circles back to
writing academic papers only through this leap!

[1] [https://wanderlog.com/blog/2020/01/29/coronavirus-
observatio...](https://wanderlog.com/blog/2020/01/29/coronavirus-observations-
on-the-ground-in-shenzhen-china/)

------
bigiain
I wonder how often “proof of concept” or “rapid prototype” scientific papers
get “pushed into production” before they’re finished by managers?

I wonder if papers written this way suffer from “second system syndrome”,
where the rewrite stage totally changes the underlying arguments and
conclusions “in response to feedback from stakeholders”?

<grin>

------
saeranv
I 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.

~~~
Ar-Curunir
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

------
hyperpallium
He 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!

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

------
hyperpallium
> [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!

------
underdeserver
Title missing a (2008).

~~~
gus_massa
The oldest version in the WaybackMachine is from July 2007
[https://web.archive.org/web/20070703081456/https://terrytao....](https://web.archive.org/web/20070703081456/https://terrytao.wordpress.com/advice-
on-writing-papers/write-a-rapid-prototype-first/)

and here say May 2007
[https://terrytao.wordpress.com/?s=Discovering+a+solution](https://terrytao.wordpress.com/?s=Discovering+a+solution)

