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.
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.
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.
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.
> 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!
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”?
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.
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
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!
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.
> [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!
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.