I learned to code in 30 days

I went from code-illiterate to launching my first web app in 90 days. Most days were spent agonizing over whether I could do it. The coding itself only took 30 days.

As with any journey paved with self-doubt, there were memorable lessons like:

• How I failed to code endlessly until I changed one thing
• Why many no-code tools will end up wasting your time
• Why flexible products tend to be the most unusable
• When learning to code makes sense, and how to do it without formal training 
  ‍

String of failures

I’ve tried and failed to code throughout my life: when computer science became trendy, when I thought it would help me be a PM, when I wanted to prove I could “be technical”.

Each time, I unknowingly committed the same mistake: I liked the idea of coding more than the actual practice. So whenever the course got boring or I got stuck, I gave up. Give up enough times, and part of you reasons: I’m just not cut out for this.  

Lesson #1: don’t count yourself out unless you’ve made real attempts. A real attempt in the context of coding is having a project you care about building. Everything changes when you’re motivated to bring it to life.  

Most coding in a (virtual) classroom is too low-stakes — I’m not bothered if my function breaks, but if filtering breaks on my site, I’m ashamed and will search every corner of the internet for a fix. Having a project raises the stakes of getting things right. 

Another big mistake I made was waiting around for a no-code tool to save me.
‍

Truth about no-code tools

With all the hype around no-code / low-code, you’d think that learning to code will soon be optional. Not so fast.  

If you’re building a blog or landing page, you’re in luck! There are many options on the menu: Typedream, Carrd, Webflow (harder to learn, but 100% customizable). They let you drag and drop your way to a beautiful product, creating the illusion that anything is possible these days.  

In reality, these tools are highly usable because they are rather inflexible: they’re focused on the narrow job of static websites. 

If you’re looking to make even a simple web app like retrieving information from a database based on user input, it’s nearly impossible without custom code. It took me building half a dozen crummy no-code prototypes to realize it was never going to work. I was foolishly trying to ignore the law of gravity of product development…
‍

Usability vs. flexibility

Behind every easy-to-use product is a mountain of invisible work. It starts with a vivid understanding of specific use cases, and a dedication to making the most common actions as easy as possible. This means reducing # of steps, or making them very obvious, usually both. 

The catch is that there’s a limit to how many things you can make easy to do. Real estate is a natural constraint. Just look at this navigation bar: 

Unbounded flexibility hurts usability. This same trade-off explains why no-code tools that tout “full functionality” and “total design freedom” end up massively underdelivering.

Bubble is the poster child for bright promise, underwhelming results. Despite raising $100M, it’s riddled with bugs and shoddy flows. Speaking of which, if you find bad bugs in a no-code builder’s onboarding, run far away and never look back. 
‍

Inheriting features… and bugs

Choosing a no-code tool is like hiring their product development team for a low fee. Great deal with two fat caveats:

1. You also inherit their bugs and responsiveness — if they’re a B-class team, your product will only rise to B-class quality 
2. You’re not only paying a fee, you’re also paying with the time it takes to learn the rules and quirks of their system

Flexibility is never free. The price is lower usability and higher chance of bugs, given more surface area for things to go wrong.  

Despite these hidden drawbacks, no-code tools can still save you time if:

1. You find a solution tailored to your use case (e.g., Softr = great frontend to visualize your Airtable, Retool = brilliant frontend for internal tools)
2. It’s fast to learn yet still supports enough functionality for your MVP

But if you want to have full control over a customer-facing web app, the shortcut is, surprisingly, doing the hard thing: learning to code. 
‍

When coding is the shortcut

I thought learning to code would take years, I would die of boredom and I still wouldn’t be any good. As it turns out, coding your own project is a completely different game. It’s fast-paced once you learn the rules, and you can do a lot with basic knowledge.  

Some highlights: 

• No room for sloppy work — it’s easy to think sloppy thoughts, hard to write sloppy thoughts, even harder to code sloppy thoughts
• Genuine empathy for the ups and downs of being an engineer
• Immense satisfaction from building something line by line
• Relief of leaving no-code constraints behind

Learning your way around a no-code tool is a cost of doing business, but learning how to code is an investment in the business of You. The ROI is massive if you have ideas you want to build, and plan on using the skill over and over. 

I still can’t believe it took more time searching for my no-code hero than learning how to save myself. If you want to have it all (flexibility and usability), do it yourself.  

P.S. for anyone interested in learning to code, I’ve included notes below. Also happy to answer any questions. 

And if you’re looking for a high-growth startup or benchmark your salary / equity, give my new product a try — welcome feedback!

Notes on learning to code: 

1. Pick a popular language that resembles English; I used Python Django because it’s intuitive and has a big online community — this matters because most problems you face will already have top-voted solutions
2. Writing code = mostly modifying other people’s better code. All of my code was inspired by solutions on Stack Overflow, JSFiddle and YouTube
3. If you have no idea how to modify someone’s code, take a short course to find your footing but don’t dwell too long on theory; concepts rarely stick until you’ve applied them to your own project
4. When following a YouTube tutorial, make sure to download the latest packages; some of the best videos are older and feature outdated packages; upgrading after you’ve written your code can break functionality 😢
5. 95% of your time will be consumed by 5% of the problems — that 5% will make you cry, but remind yourself it’s only 5%! They’re almost always niche scenarios that require you to get inventive
6. When in doubt, experiment! Try every variation; your hunches sharpen over time
7. Shoutout to these creators for demystifying Python Django! 🙌