Video summary

It took me 10+ years to realize what i’ll tell you in 10 minutes

Main summary

Key takeaways

Educational

Main ideas / lessons (10 things the speaker wishes they knew earlier)

  1. You don’t need to memorize everything

    • Coding isn’t about perfect recall; it’s about recognizing patterns, understanding how things typically behave, and knowing where to look when you forget details.
    • Even experienced developers still look things up (e.g., “center a div”).
    • What matters is the ability to reason through problems, find answers, and stay calm when things don’t work.

  2. Tutorials can feel like learning—but building is what teaches

    • Watching tutorials can make you feel competent without actually gaining the skill.
    • The real learning happens when you stop watching and rebuild from memory—including making mistakes, getting stuck, searching, breaking things, and backtracking.

Method / rule (step-by-step):

  - Watch **one** tutorial/video.
  - **Close** it.
  - **Rebuild** the thing yourself from memory.
  - If you get stuck:
      - Search for answers
      - Break things
      - Debug/reason why it fails
  - **Do not start a new tutorial** until you’ve rebuilt something from the previous one on your own.

  1. Stop trying to “write perfect” code the first time

    • Chasing elegance and correctness immediately slows you down and creates fear of being “not one of them.”
    • Nobody writes flawless code.
    • Senior developers also ship broken things—they’re just better at detecting and fixing them quickly.
    • Finish things instead of polishing them prematurely:
      • Ship an “ugly” version that works.
      • Once it works, improve it afterward.

  2. Confidence doesn’t come first—action comes first

    • Waiting to feel ready can turn into waiting forever.
    • Even when shipping your first real product, it won’t feel complete or safe.
    • You become “ready” by starting anyway, even while scared.

  3. The real skill is solving problems, not just writing code

    • Memorizing syntax (like for-loops) isn’t the main value.
    • What makes you valuable:
      • Breaking vague requests into small, buildable pieces
      • Debugging by asking the right questions
      • Narrowing down causes methodically when something is broken
    • Analogy: tracing electrical wiring when lights cut out—rule things out until you find the loose connection.

  4. Debugging is core work, not an interruption

    • Early on, the speaker spiraled when things broke (“I must be bad”).
    • Later they learned: debugging—despite feeling like it slows you down—is actually the work.
    • Great developers don’t panic; they keep investigating until they understand.

  5. Users care about outcomes, not your code elegance

    • Users don’t care how clever or clean the implementation is.
    • They care whether:
      • Buttons work
      • Pages load quickly
      • The product functions
    • Clever internal systems can be invisible—and that’s okay.

  6. Clean code matters—but mainly for other developers

    • The main reason developers care about your code is that it’s simple enough to understand and change without breaking everything.
    • Instruction:
      • Write code that works for users.
      • Keep it simple and maintainable for the next developer.

  7. Burnout is real; boundaries protect you

    • Motivation fades; exhaustion and doubt can set in.
    • There’s “no finish line,” so pushing endlessly makes you slower and more fearful.
    • Boundaries help:
      • Go outside
      • Take breaks before you think you “earned” them
      • The work will still be there—and you’ll be better for it.

  8. You’ll spend more time reading code than writing it

    • You will frequently read:
      • Old code you wrote
      • Code written by others
      • Code from past projects/people who left
    • Big codebases can initially feel overwhelming.
    • The skill is learnable:
      • Trace a feature from UI (button) back to data sources
      • Read a function to understand its intent before judging implementation
      • Follow one thread until the system makes sense
    • Reading strong code is like having a mentor embedded in each file.

  9. Senior vs junior isn’t only technical depth—it’s communication

    • A senior dev can explain technical trade-offs to non-technical people.
    • They can write pull request descriptions that reviewers understand.
    • Value includes teamwork:
      • A brilliant solution nobody can use/defend/hand off is worth less than a decent shared solution.
    • “Quieter” promotion factors:
      • Staying calm in incidents
      • Giving feedback kindly
      • Helping new hires feel safe
    • Communication and collaboration help you get promoted and referred.

  10. Networking is not slimy; it’s relationship-building through good work

    • Jobs often come through people recommending you—not just applying to vacancies blindly.
    • Real networking = doing good work and being remembered positively:
      • Helping teammates
      • Being decent in community
      • Staying loosely in touch
    • The idea: the junior dev you’re kind to becomes a senior later and remembers you.

Speakers / sources featured

  • R.J. (speaker; web developer and instructor)

Original video