How to do hard things

Put simply, one group put all of its energy into producing just one, and the other group just turned out pot after pot after pot.

At the end, so the story goes, the group that cranked out pots like crazy ended up producing pots of higher quality.

In my own life, I can often find out the thing that I'm afraid of learning because I've set it up like that first cohort: making the one perfect thing, instead of putting it out there and iterating on it or making another based on what I learned. Goes with learning languages (I'd do way better if I simply tried speaking every day, but I wait for perfect opportunities).

Breaking down problems is obvious and known advice, but very helpful, especially when you are lost in the weeds, can't see the forest for the trees, etc. Having it as "a system" helps self-management. Disagree about the importance of touch-typing.

Grammar snark (for an article about writing): "Sometimes it will be obvious what you need to improve, sometimes it won’t. When it doesn’t, ..."

when it doesn't obvious to you

No, you don't always have that choice.

What you do is you break it up, best you can, then try to build each part. If that doesn't work, you break it up differently.

Funny, I had this notion that experts are most of the time better at avoiding deadends. Subtlety and patience. Noobs are impatient and depth first and lose hope.

In high school, smart students can often get away with not studying. In university, your attitude and mindset towards failure and learning becomes much more important.

Professors were also good at teaching, which reduced the need to study at home even further.

It hurt me in the long run - i am really bad at putting in effort unless something catches my attention(thankfully programming can totally absorb me), and i quite frequently 'wait for the spark'(walking helps with that a lot).

* Ignore whole craze toward being cool, participating in random competitions, chasing opposite sex

* Keep detailed notes of your days, who did you meet, what did you learned?

* Don't worry too much about acquiring every possible new skills that you come across

* The most important part of the textbook is exercises and that's not because there would be tests. If you really want to learn something, you need to do exercises!

* Write down import concepts you learned, new insights you developed. The process of writing down to explain to someone or yourself improves learning by an order of magnitude.

* Avoid depth-first search. Not every chapter, every book, every subject must be learned in all its gory details.

* Most textbooks are written by people who have little passion for that subject and they just want to show off their expertise. If you think you are wasting time, dump that textbook sooner than later.

I think it's also important to remember it is rarely effortless to others. You just don't see the effort. I was fortunate enough to hang out with some people in college who were valedictorians at their high schools, and would generally be considered smart. They ended up graduating college with 4.0s. Since I hung out with them all the time, I got to see just how much they worked at it. They took amazing notes, and studied all the time. We didn't have a name for it then, but they essentially did the Pomodoro technique to pull all nighters studying for big exams.

Seeing them definitely helped me realize that getting through hard problems is work, and requires time. Thinking time, studying time, and practicing time. Do some things come easier to some people? Sure, but almost everyone has to put in the work at some point.

As an aside, not understanding how much work goes into something is common in sports. People see Michael Jordan hit the final shot or Tiger Woods hit an amazing shot out of a bunker, but do not realize they have probably practiced that shot hundreds if not thousands of times.

My favorite part of skate videos growing up was at the end when they showed all the wipeouts and crashes. They hurt to watch, so much, but they always drove home the fact that it took a lot of painful and frustrating failures before the guy landed that really smooth 35 stair grind.

The point it, things often seem effortless to others but that's just cause you're not really seeing the effort being put in.

I always return to this [0] diagram when thinking about learning. Am I taking shortcuts that'll actually stunt my ability to progress further in my development. The "Expert Beginner" is a dead-end development wise - it might be a perfectly reasonable place to end up, but not the right way to expertise.

[0] https://daedtech.com/pics/ExpertBeginner.jpg

The movie Goodwill Hunting has a scene that describes this [0].

[0] https://www.youtube.com/watch?v=RKu_QQVHJLA

I'm a third year university student; I did all the exercises set last year to do well in the exam and over the course of the whole year. And now, only one year later, I can't remember how to do some of the most fundamental problems. I can remember the derivative and integral of trig functions, but the method of doing even moderately challenging exercises with them I don't remember well and I'd need to look it up. I don't know what that signifies, but I have the impression that even just doing the exercises doesn't last long unless you use what you have learned semi-regularly at the least.

Is it because we are confident? Or because we lack sedulity? Or because our analysis was incomplete?

Is the surprise time consuming because we want/expect it to be easy? Or because we are focused on a different problem really. Or because our focus was interrupted.

It forces you to learn recursion since for most of the book it only uses pure functional programming with no mutation, so the only way to do loops is with recursion. Overall I would say it gave me a strong base to understand not just recursion but functional programming which has helped me pick up new languages more easily during my career.

Also I used Clojure instead of scheme to do the exercises. It's a wonderful modern lisp that works on JVM and can land you a job. The examples usually work with minor modifications and I would say it's worth it to learn.

I had two A-level maths teachers at school. One always started by getting the class to do a simple as possible example like the above before launching into more complicated stuff, the other started off explaining complex stuff. The first approach worked far better, with the second our minds just kind of glazed over.

There's something a little counter intuitive about it like your neurones have to wire up on the simple example before getting the more complex. Doing the simple stuff then sleeping on it and doing the complex the next day works better still I think.

If you imagine your code as a sequence of instructions, recursion is basically a `JMP` to the start of the stack again, normally with different values.

Once a condition is met, instead of jumping back to the start, it returns something. That condition then repeats itself inside all the repetitions eventually returning the value to the original caller.

  # imagine we're recursing to subtract to zero

  1. call function subtract with 10 (set x = 10)
  2. subtract x by 1
  3. if zero, return 0
  4. else return the result of calling the function with x-1 (jump to 2)

1) There is always an exit condition ( or it would run forever , we never want that)

2) There is always a value that changes and it is passed to the next execution, or otherwise it wouldn't make sense it would be always the same execution and the exit condition would never trigger.

3) Think like frames of a movie, in paper o whiteboard, write a table with a column for every variable and a row for every step, my first programming teacher taught me this, and 19 years later it save me in a white board interview, it helps to calm down and just go step by step seeing how values evolve.

So these 3 together, allow you to think in how the values change in every step, and how to get to the point that the exit condition is meet.

Hope it helps! good luck!

I didn’t realize that it was a threshold moment, and I didn’t even know if it was syntactically legal or allowed for a function to call itself (I had no formal CS training) but I remember struggling with the “how much should these child elements be indented” problem and eventually trying it and it worked; it was quite a rush for 14-year-old me.

Maybe try implementing something simple and straightforward that uses it, like a web front end that displays a directed graph of nested comments/message replies?

Notice there are 2 types of parts:

  - A leaf, which is the end (has no children)
  - A branch, which may have leaves or more branches (has children)... and because a branch can have more branches, this is recursion, so we abstract to a 3rd type of part:
  - A node, which could be a branch or a leaf...

  function int getNumLeaves(Node node):
    foreach childNode in node:
      if childNode.IsLeaf(): leafCount++
      else: return getNumLeaves(childNode) // NOT a leaf -> check this branch's children

  print getNumLeaves(tree.stem); // (start with the outermost 'node')

The 'reality' is the top level context.

You dive down to level 2 context by falling asleep; that would be the recursive function call.

In that dream, fall asleep and enter level 3 context. You are now recusrsively falling asleep.

In the movie, the characters wait for a signal to wake up and going one level up. This is the 'stopping condition' of a recursive call.

You can also see that as Matryoshka dolls.

Regarding the 'Inception' movie that's funny, because it popularized the '-ception' suffix to describe a recursive phenomenon [1]

[0] https://www.imdb.com/title/tt1375666/ [1] https://en.wikipedia.org/wiki/Inception#In_popular_culture

Also, if the algorithm is not tail recursive, you may be missing that there is an implicit call stack where intermediary results are pushed to.

In recursion, you have 3 main components: -A function that performs the same action a repeated number of times, except for when you meet a base case (end of the recursion) -A value that must be tracked and modified in order to perform the said action n times, and know when to stop doing it -A base case that stops the repeating action, and usually performs another 1 time action.

In our example, our components are: - Function <undress to take a shower> that performs the repeated action of taking a piece of cloth off. - Value tracked, which is the <number of pieces of cloth you have left to get naked>, and on each iteration or call of the function will be reduced by 1 (asuming you're taking 1 piece at a time). - Base case, which would be <when you have no pieces of cloth left to remove = you're naked> and you can perform the last 1 time executed action which is <take the bath>.}

Notice the importance of the base case, otherwise your program will keep iterating and the program will get stucked.

Hope that this helps.

To make sure your function will stop calling itself you need an exit-condition. So whenever you want to write a recursive function, simply start with a template like this:

  function myFunc(list) {
    // exit condition
    if (list.length == 0) {
      // What should the function do if the exit condition is true
      return
    } else {
      // before recursion
      console.log(list[0])
      
      // recursion
      myFunc(list.slice(1))
      
      // after recursion
    }
  }

Before I learned this pattern, my recursive functions were a mess. Now, they all adhere to that very template and I find it actually fun to write recursive functions as there are some problems which are a lot easier to solve with them.

  function RecFunc(n, max) {
    let result; // intialize the return variable
    if (n < max) {
      result = RecFunc(n + 1, max) // the recursion
    } else {
      result = n; // the exit condition
    }
    return result;
  }
  RecFunc(0, 3);

  | RecFunc
  v   n: 0, max: 3, result: undefined
  |   RecFunc
  v     n: 1, max: 3, result: undefined
  |     RecFunc
  v       n: 2, max: 3, result: undefined
  |       RecFunc
  v         n: 3, max: 3, result: 3

  ^ RecFunc
  |   n: 0, max: 3, result: 3
  ^   RecFunc
  |     n: 1, max: 3, result: 3
  ^     RecFunc
  |       n: 2, max: 3, result: 3
  ^       RecFunc
  |         n: 3, max: 3, result: 3

  var result = 0;
  for (var i=0; i++; i<=3) {
    result += 1;
  }

[0] https://github.com/reduxjs/redux/blob/master/src/compose.js

https://www.cs.princeton.edu/courses/archive/spr09/cos333/be...

So, each step needs to get you closer to the goal, working on a smaller problem, until you reach a base case, a really small problem that you don't solve in terms of recursion. You check for the base case, a really small problem you actually solve directly instead of handing it off to another recursive call, and you actually return your solution to the caller.

1. Write down the problem.

2. Think real hard.

3. Write down the solution.