Source: cirosantilli/backward-design

= Backward design
{tag=You aren't gonna need it}
{wiki}

This is one of <Ciro Santilli>'s most important principles.

<Steve Jobs>[Steve Jobs] has a great quote about this. He's totally right on this one!
> You've got to start with the customer experience and work backwards to the technology. You can't start with the technology and try to figure out where you're going to sell it.

\Video[http://youtube.com/watch?v=FF-tKLISfPE]
{title=<Steve Jobs> Insult Response excerpt from the https://en.wikipedia.org/wiki/Apple_Worldwide_Developers_Conference[1997 WWDC]}
{description=TODO understand the context of the question a bit better. It is something to do with an https://en.wikipedia.org/wiki/OpenDoc[OpenDoc] thing and <Java>.}

Decide your goal first, and then do whatever is needed to how to reach it.

Don't start randomly learning tech, because that means you <how to teach/help students achieve their goal>[will waste a lot of time learning useless stuff].

There is of course some level chicken-and-egg paradox in this, as <image dilbert nuclear power user requirements>[highlighted by Dilbert], since choosing an achievable goal in the first place requires some level of technical understanding.

\Image[https://web.archive.org/web/20200331090146im_/https://assets.amuniversal.com/1af002106d5c01301d80001dd8b71c47]
{title=<Dilbert> cartoon about designing a nuclear power plant from user requirements (2002)}
{description=
This cartoon illustrates well how when doing <deep tech> and fighting against the <laws of physics>, you can't just start from user requirements, but you also have to also think "what can we actually get done at all with this new technique".

The best research engineers are able to identify what is just on the cusp of the "possible", but which has the greatest value. This is the endless dance between the tech push, and the market/need pull.
}
{height=300}
{id=image-dilbert-nuclear-power-user-requirements}
{source=https://dilbert.com/strip/2002-02-20}

However, it is much more common that people will get way too involved in learning useless stuff and lose sight of the <art>[useful end goals].

Rather, take an iterative approach:
* start with an ambitious end goal
* learn a bit of tech to try and reach it
* realize that you can't reach your end goal and <pivot (strategy)> a bit to a related end goal that seems more realistic: <the side effects of ambitious goals are often the most valuable thing achieved>
* loop

There is some truth to the counter argument that "but if you don't spend a lot of time learning the basics, you can never find solutions".

However, these people underestimate your <brain>. The brain is beautiful, and human intuition is capable of generating interest towards the things that are actually useful to reach your goal. When you feel like learning something related to your goal, by all means, give yourself the time to do so. But this still be <ourbigbook com/motivation>[much more efficient than just learning random things that other people tell you to learn].

Bibliography:
* <Ciro Santilli> and many many others believe that backward design is a fundamental principle that should be considered by the <educational system> rather than wasting 90% of everyone's time with the 90% of mandatory curricula they don't care about:
  * notably that school should be <self-directed learning>[personalized] and project driven:
    * <students must have a flexible choice of what to learn>
    * <how to teach/help students achieve their goal>
  * https://www.cartalk.com/content/rant-and-rave-36 "The New Theory of Learning" by Thomas L. Magliozzi section "Premise III: THE BACKWARDS LEARNING THEORY" says the exact same thing. Ciro actually found this when writing <Cool data embedded in the Bitcoin blockchain>.
  * several well known <teaching methods>:
    * <Montessori education>
* a Coding Horror <software engineer>[software specific] take on this issue: https://blog.codinghorror.com/please-dont-learn-to-code/
* https://x.com/7etsuo/status/1784787045157900697[]: <#George Hotz>
  > Everyone I've met who can program well learned it the same way: they had an idea, and then they built it.