🧵 View Thread
🧵 Thread (9 tweets)
# on technical accessibility One interesting observation I think back to often: - when I first published the micrograd repo, it got some traction on GitHub but then somewhat stagnated and it didn't seem that people cared much. - then I made the video building it from scratch, and the repo immediately went through hockey stick growth and became a verty often cited reference for people learning backpropagation. This was interesting because the micrograd code itself didn't change at all and it was up on GitHub for many months before, stagnating. The code made sense to me (because I wrote it), it was only ~200 lines of code, it was extensively commented in the .py files and in the Readme, so I thought surely it was clear and/or self-explanatory. I was very happy with myself about how minimal the code was for explaining backprop - it strips away a ton of complexity and just gets to the very heart of an autograd engine on one page of code. But others didn't seem to think so, so I just kind of brushed it off and moved on. Except it turned out that what stood in its way was "just" a matter of accessibility. When I made the video that built it and walked through it, it suddenly almost 100X'd the overall interest and engagement with that exact same piece of code. Not only from beginners in the field who needed the full intro and explanation, but even from more technical/expert friends, who I think could have understood it if they looked at it long enough, but were deterred by a barrier to entry. I think as technical people we have a strong bias to put up code or papers or the final thing and feel like things are mostly self-explanatory. It's there, and also it's commented, there is a Readme, so all is well, and if people don't engage then it's just because the thing is not good enough. But the reality is that there is still a large barrier to engage with your thing (even for other experts who might not feel like spending time/effort!), and you might be leaving somewhere 10-100X of the potential of that exact same piece of work on the table just because you haven't made it sufficiently accessible. TLDR: Step 1 build the thing. Step 2 build the ramp. 📈 Some voice in your head will tell you that this is not necessary, but it is wrong.
@karpathy Same energy for the other 2 AKs on X If you wrote a paper/published code but there's no one in the woods, did it really matter? https://t.co/4hzMYs0MVG
Crazy AF. Paper studies @_akhaliq and @arankomatsuzaki paper tweets and finds those papers get 2-3x higher citation counts than control. They are now influencers 😄 Whether you like it or not, the TikTokification of academia is here! https://t.co/gXCvUBrMMY https://t.co/zbDH2xEgAI
@karpathy those are code comments btw https://t.co/hrETRnUdJF
@karpathy I have also seen this before. I think it's the psychology of material coming all at once that can be overwhelming for newcomers. If one builds up things bit-by-bit there not this overwhelming feeling of "this is too much; I am not good enough to learn this".
@Tim_Dettmers Yeah exactly. The trap is that the original creator has actually built it piece by piece and over time molded it, which creates an unintuitively large disparity between how easy they perceive it, and how easy fresh eyes perceive it, even when controlling for technical level.
This is a fantastic insight. People (including me) often just want a guiding hand learning something new. Sometimes as a teacher I forget how hard it was to learn a new program or something originally because now it’s so “easy” for me. It’s good to carefully walk over the steps again to be sure both I and they understand it as well as possible. Also there’s the oldie but goodie: if you want to really understand it, teach it. You’ll be surprised what you don’t know about a subject when you have to pass that information on to students.