The four phases of the typical journey into coding

  1. The Hand Holding Honeymoon is the joy-filled romp through highly polished resources teaching you things that seem tricky but are totally do-able with their intensive support. You will primarily learn basic syntax but feel great about your accomplishments.
  2. The Cliff of Confusion is the painful realization that it’s a lot harder when the hand-holding ends and it feels like you can’t actually do anything on your own yet. Your primary challenges are constant debugging and not quite knowing how to ask the right questions as you fight your way towards any kind of momentum.
  3. The Desert of Despair is the long and lonely journey through a pathless landscape where every new direction seems correct but you’re frequently going in circles and you’re starving for the resources to get you through it. Beware the “Mirages of Mania”, like sirens of the desert, which will lead you astray.
  4. The Upswing of Awesome is when you’ve finally found a path through the desert and pulled together an understanding of how to build applications. But your code is still siloed and brittle like a house of cards. You gain confidence because your sites appear to run, you’ve mastered a few useful patterns, and your friends think your interfaces are cool but you’re terrified to look under the hood and you ultimately don’t know how to get to “production ready” code. How do you bridge the gap to a real job?

Which phase are you in?

  • Mikina
    link
    fedilink
    arrow-up
    10
    ·
    16 hours ago

    It took me a long time to realize the worth of having a CS degree. When I was leaving the school, I felt like it hasn’t tought me much. I was already a pretty ok programmer, since I was programming most of my highschool, and it felt like I’ve wasted a lot of time on languages I’ll never see in my entire life. Which is kind of true - I’m still pretty confident that I’ll never use Lisp, Prolog, Lambda Calcul, base assembly or Pharo ever again, but after a few years I’ve realized something important that I was missing - the school wasn’t trying to teach me how to be a “pharo/lisp/prolog programmer”, but to be “a programmer”.

    I noticed it on my pentesting colleagues who didn’t have formal programming education, how they mostly spoke about programming in relation to languages - “I know a little bit of python, but wouldn’t call myself a programmer. What programmer are you?”. That question felt wierd, and I eventualy realized that’s because the lines between languages eventually blured for me naturally, and I paid no mind to the language of choice - I was simply able to naturally pick up any language, and write anything I needed in it pretty quickly.

    Only then it occured to me that I have my education to thank for that. Sure, I might never use Lisp again, but I do vaguely remember the concepts and workflow the language has, so now I can more naturally pick up any lisp-like language. Same goes for the prolog-style of languages, or the more OOP-focused languages, like Pharo. Since I had to drag myself through hell to pass an exam in most of the flavours of languages, it made me a versatile programmer that can just naturally pick up anything I see, to the point where I don’t have to think about it - I just subconsciously detect what kind of basic workflow style is it going for, google the basic syntax and standard libraries, and I can write whatever I need in whatever language is available in a reasonable amount of time.

    I don’t see this “ascendance” mentioned in the post, and I think that it’s a really important point in learning to be a programmer. It’s also a piece of advice I try to give anyone unsure about whether his degree is worth it, because it feels like you’re learning useless stuff. I have no idea how to teach it, though. It kind of happened naturally for me, and I can’t identify the point when it happened or why, or how would I go in teaching it to someone else.

    It’s important to keep a wide field of view when learning programming, and not just lock yourself into one language. You can always google for syntax pretty quickly, but seeing the wide array of workflows and flavours different languages use to accomplish the same thing will go a long way in making you a better programmer.