All self-help content that has ever been published is either trying to run towards or away from one universal truth: you need to do things to get better at them. More to the point, you need to work in a focused way to try to get better at things. There are two ways you can deal with this immutable truth. First, you can get really good at pretending. This is what a lot of self-help is about, and for the most part represents the 10-minute-abs phenomenon. Second, you can cram a ton of effort into a short time. This is what "fast improvers" do.

A lot of people get the second part of this wrong. There's a great deal of people who have a misconception that improving at things is a function of how much time you spend at the thing. This is, at the surface level, true. How could it not be true? You start not knowing and then over time you know. But it raises a funny question: why do people improve at different rates? Is it because of innate talent? Is it because of "shortcuts" and hidden wisdom in the learning process?

The real revelation here is that time is just a container for effort, and that a lot of time is a very large container which can hold a lot of effort. There are some things where, to become good at them, you need to cram a monstrous amount of effort into that entire container, to fill it to the brim with a lifetime of excruciatingly high effort. Most things are not like that. Most things are things you can get pretty good at¹ with passive, moderate effort over a long period of time. You can learn these things very quickly if you're willing to be uncomfortable.

To be uncomfortable as much as possible, you need to fill your time with stuff that you struggle with, and remove stuff which is not that bad. For algorithms and data structures, leetcode offers a beautiful platform for most people who want to spend time finding stuff they suck at. Thousands of exercises, a gentle difficulty curve, community solutions for nearly every problem, labels for different types of problems, even detailed sets of problems commonly used for interviews. The path to go from complete beginner to someone with a strong handle on these things is contained entirely within this website, with virtually zero gatekeeping from knowledge or resource access. I know this because I have watched my wife, a biochemist with minimal programming background, grind problems on this platform until she could get through mediums with no assistance.

The ultimate way to become strong at anything is to fill your time with exercises, ideally optimizing for as difficult and as many as possible. What counts as an exercise for the thing you want to learn is left to the reader, as an exercise.

Large Language Models are really amazing at generating code now. Like many other things, they have largely sped up the process of writing simple functions just by writing them in plain text². Even if you can write the solution yourself³, it's often simply faster to write what you want in english just because it's quicker to type it.

I find copilot-like tools to have improved my ability to produce code quickly. However, using these tools to write code does not really seem to help me become much better at it⁴. So I resolved to pay back some of the saved time deliberately grinding these sorts of simple problems, to make sure that I continue to improve at actually writing code without help⁵.

I was learning Rust yesterday so I disabled it briefly to complete some coding exercises and I felt a sense of dread realizing it was just the cursor and I, alone in the text editor 😬

— Andrej Karpathy (@karpathy) December 30, 2022

Given that code generation capabilities will only continue to improve, one might ask why we should bother to stay sharp anyways. To me, this question has three very simple answers: machine management, thinking in code, and trust.

Not all problems are created equal. Most of the problems on leetcode are pretty straightforward, even if they are sometimes very hard: identify what algorithms and data structures to use, transmute the problem to a problem you already know how to solve, and then solve it. Every once in a while, though, you encounter what I consider a beautiful problem.

One such problem is 279. Perfect Squares, which can be solved in 4 different ways: one using Dynamic Programming, Static DP, Breadth-First Search, or using math. When I tackled this problem, I wrote up a greedy solution, realized it would not always give me the correct answer, and relatively quickly wrote up a dynamic programming solution. I'd say I spent roughly ten minutes on it, in total: it was not too hard. As always, I thumbed through some solutions afterwards, and quickly realized that there were simply multiple ways to solve the problem in addition to what I did. I spent the next 30 minutes in a hyperfixated rabbit hole on wikipedia, reading about Lagrange's four-square theorem, far longer than I spent solving the original problem. This, to me, is the marker of a beautiful problem.

I never really had this sort of math background growing up, so encountering these sorts of weird theorems always comes as a wonderful little surprise to me whenver I happen upon them. I get the sense that these sorts of problems are more common in contest math, where solving them is less about applying a known formula⁸ and more about creatively arriving at some solution. While I understand the need to strengthen the ability to apply formulas (it's what pays the bills after all), this sort of thing is what makes me feel like the leetcode habit is worth it (as someone not currently looking to pass coding interviews).