On Leetcode (English)

You can read this original article in Grugspeak here.

I think leetcode is helpful. I believe it has helped me grow a ton as a programmer, will continue to aid my growth as a programmer, and this is true for all programmers. I also think that, if approached in certain ways, leetcode can be powerfully destructive. The first 12 minutes of this 18 minute video by Leetcode.IO really supported my experienceand helped me to process a lot of my thoughts about leetcode into a really simple premise; leetcode is mostly about practice.

A common critique of leetcode that it isn’t what coding at a job is like at all, and although I think this is true and a helpful point to make, I don’t totally agree that this disqualifies leetcode as a helpful method for becoming a better programmer.

Leetcode taught me that even in a language that I have been using for more than five years, Javascript, there are still many basic things I either don’t know, or have known briefly but failed to internalize, and the true cost of that ignorance.

In other words, leetcode has been a powerful tool for teaching me what I didn’t know I didn’t know.

It also provided me with the soft skill of working under pressure. The core unpleasantness of leetcode is that it represents an on-tap source of mindfuckery, which happens to be the exact resource I need to get better at coding under pressure. This can be accomplished in other ways, but it can be helpful to make it routine. It’s sort of amazing and ironic that the innovation of leetcode exists - it’s like a standardized, organized library representing the most outlying, eccentric scenarios of thought that exist in code.

Or at least, its organized when using the excellent and basically mandatory tools like Grind75 and the Neetcode roadmap. Leetcode alone has a horrifying absence of logical order. If Leetcode were a grocery store, the watermelons would be on the same shelf as canned beans and toothpase.

Here’s a list of some of the things I learned from leetcode:

• Write code too fast leads to mistakes that slow me down in the long run
• Code too slowly leads to losing valuable time needed to refine it
• Pseudocode can be really helpful
  • Wishful programming is even better than psuedocode
• If considering alternate approaches only takes 40 seconds, it might be worth stepping back and sacrificing a couple minutes from your thirty allotted minutes. But it’s probably not worth 4 minutes.
• Committing to a direction is usually better than “hmm, what’s a better way to do this”
• when to use for...in and when to use for...of
  • The traditional for is actually the most straightforward, despite being more verbose
• When to use Object.entries(), vs Object.keys()
• This fuzzy strategy of how, if you save information as you iterate, you have have information when you need it later, i.e. 3) Stock Profits
• How time complexity really works (50% of the way there at least if we’re being honest)
• That math notation exists (and can be used to neatly define time complexity, thanks Wolf)
• What space complexity is
• How trees can be helpful when doing various spatial lookups, like for a game
• How const really can help prevent you from shooting yourself in the foot sometimes - maybe a better way to say this is, in Jaseem’s words, is that avoiding mutation is a great way to avoid mistakes.
• How typing, when it comes to handling nulls, is one of the easiest ways to prevent unexpected errors

I think it’s cool how these lessons range from really technical, language-specific insights to much broader insights about weak-spots in my process.

I also happen to be someone who has built a lot of personal projects from the ground up, so I suppose I’m pretty experienced in just hacking things together and learning what makes sense in an ecosystem on my own. That’s probably why leetcode is so good for me - I’ve spent a lot of time just doing what works rather than really heads-down learning the best practices for syntax and algorithms, since I can usually borrow those from someone when shit really hits the fan.

What I didn’t realize was that the cost of sub-par code throughout my repos, in terms of the details, really slows me down - in bugs, in time complexity, and in general code complexity and readability. There are so many innovations that have been created that allow more to be done more efficiently with fewer lines of code, and I believe that it’s worth studying these in order to use them, as practice to be consistent and confident as a programmer, and as a mental exercise to work well under pressure.