The four phases of the typical journey into coding
- 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.
- 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.
- 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.
- 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?
Where is the “burnt out on corporate BS and not sure if I even like coding anymore, I just want to retire and sell shit on Etsy, too bad everything costs money” phase
I did not go through those phases.
I regularly cycle through them
Over a year in as a junior dev and I’m still in the second stage. I did 6 months backend and now I’m now entering my 6th month as frontend. I still know so little, but I know more than I did yesterday.
My biggest challenges:
- I don’t know what questions to ask when it’s about something I don’t know.
- Having a rough idea as to how I want to try and solve a problem, but not knowing how to code it
- Trying to retain so much new information on a daily basis and then remember everything from the days before
- (What I hope is) Imposter Syndrome on a weekly basis
I just keep on trying, try to understand what I can and ask for help when I feel I’m at a blocker.
If you don’t know, ask a stupid question to yourself. Then ask it again in a more intelligent manner to a rubber duck. Then a real person. One of these three will give you an answer
TDD is the answer to the second part. Seriously, just try it. Don’t do it for every task after, but do try it!
Notes, tickets, knowleadge bases, READMEs, well written code that is easy to understand, tests that are descriptive, ADRs. Nobody can remember it all, the hard part of programming is making it easy for the next change. Remember it’s likely to be you, be kind to your future self
And imposter syndrome never goes away. And this is a good thing - “don’t get cocky kid”. It does get lesser though, and then you get more responsibilities! But really, if you aren’t questioning why and what you are doing, how do you trust your past self? Embrace the imposter, realise we are all imposters to a lot of extents
What’s TDD?
Test Driven Development. The route to programming nirvana includes a stop at this station
Test driven development. It’s a technique where you know what behaviour or result the code should produce, but you haven’t written any producing code yet. So you break down the problem into small steps which each produce a testable result or behaviour that brings you closer to what you need. And before writing any implementation for each of these small steps, you write a unit test which checks whether an implementation would execute this step correctly. Once you have each test set up, you can start writing the implementation, keeping it as simple as possible, and running the test until it passes for your implementation. This keeps going in a cycle.
Once all your tests pass, provided you’ve written good and correct tests for every step, there are several benefits of this approach:
- you can be quite confident that your code works as expected
- making changes to existing code is much less scary, because you can change the thing you need to change, adjust or add tests accordingly, and rerun all the other tests to make sure everything else still works as expected
- there is a big psychological benefit when you force yourself to define exactly what you expect the code to do before you actually write it
- it can help others understand what the intent behind the code is by looking at its expected behaviour
The downside is that it takes more time to write tests for everything. But for complex applications, it will save you a lot of time in the long run if the code will be changed very often in the future or is complicated, because many bugs will be caught by your test landscape.
Sometimes ill do TDD, sometimes ill do the opposite. When I know what something looks like or should function. Im not sure what the technical term of itis, but ive heard someone call it Scaffold testing. Its making sure all the parts work as expected (Unit and integration/e2e) for your future sanity.
TDD lets you experiment and makes multiple potential solutions to a general problem. IE starting with the end first. Scaffolding lets you create a scaffold around what you already built so its more rigid. Both have their place.
Thanks for this, almost every day can be a challenge but that’s what I signed up for when I switched to software development! I’ll keep what you’ve said in mind and try to put it to practice 🙂
I didn’t go through these phases I just pray to the Omnissiah and sacrifice an HP printer when it doesn’t work
At least you’re not using abominable intelligence that’s commonplace these days.
AI is a pretty good tool for this sort of thing though. If you don’t know what to ask, or need an example, etc.
Yeah, but they literally used the term as used in Warhammer lore: A.I.
In Warhammer AI is forbidden on the grounds of past wars with humanity
Neat. Kinda like Dune
depends…
- html: 1? idk i only use it to make a site that i dont even wanna make too fancy. it works and i like iy that way
- css: 2, i can do basic layout but man doing anything else than just font and colors is so hard…but again, i might not do more and just keep it simple
- basic: 4, i can make text games fluently, but its pure spaghetti
- js: i can only make a hello world :(
- batch: see basic
- bash: see js (i cant code crap in it all i can do is navigating the filesystem)
- gray snail: idfk man i only know it for the lolz of “yeah i know esolangs” i never really did crsp in it
- everything else: see js
I started with the desert, reached the cliff only to turn back to the desert, through a community school parking lot, and now I am just hiding under a rock in a hole for now.
deleted by creator
I started programing at such a young age that I don’t even remember how it went. Makes it difficult to teach as I find it hard to relate to newbies. I’m quite used to just learning my self and sometimes hitting roads that lead to nowhere. In the past that I actually remember, I’ve only been learning new paradigms, deepening my understanding of low level stuff and mastering my art. Hardly stuff I can give along to a newbie.
I think it s easier. Get a problem you want to solve > press buttons as best a syou can > get something working > congrats.
Then by doing you will learn how to get better.
Very accurate. Working for a small dev shop with sympathetic senior team members brought me through 2 and into the start of 3. But a job change (into something I only barely qualified for) meant I had to trek phase 3 alone. It’s a loong slog, and the myriad of technologies in the intro without ever feeling like you know anything is spot on (I would frequently be reading web pages for help only to pull my hair out at how often they mentioned things I should know but didn’t). Fortunately I had gone to work for an IT team embedded in a larger company, not a software company itself, and they had far lower standards. I don’t think that’s a good thing in general, but it did allow me to get semi hacky things done during the desert of despair and I felt like I was delivering just as often as I was floundering. The upswing of awesome is real though. I hit it about 5 or 6 years in. I found my niche, everything id been reading and studying suddenly started to reinforce one another rather than sow deeper confusion and confidence and productivity started to multiply. About 7 years in I was technical lead in a couple of business critical areas. After 8 years I started my own consultancy in those technologies and have never looked back. I take care now to give junior staff projects that stretch them, and they need to work at, but which aren’t soul crushing.
Im not sure if this helps anyone but I used to tell my jr devs the same thing:
- You got the job.
- You are now a developer.
The article somewhat goes over this but: Learning to code is a life long thing. You just keep getting better each day with practice. Im not sure about the phases though. Definitely the “job ready” portion of the article. It seems short sighted to say you need all those things and going through each of the “phases” in order to be successful. Just solve a problem. With software. Congrats!
I remind my team every year that even seniors struggle at times.
I’m now 15 years in and at least twice a month, I’m coding with 40 tabs open trying to piece together the best solution, often just throwing spaghetti at the wall.
Heh yeah. I feel that. Close to 20 now and Im starting to feel the churn. But its still a good feeling to give direction and see people grow. I used to be a team lead in addition to a senior dev…now im just a dev (being an individual contributor is fun again) and the 40 tabs bit resonates with me. I find that AI is good a surface level assignments like build basic CRUD/models…but it Fd up so hard sometimes its hard to come back from. Definition of spaghetti sometimes haha. I just go back to the old stuff that I know works.
This is all predicated on the assumption that people already have a familiarity with organizing their thoughts and intentions in a way that even have a prayer of being understood by a machine.
There are a lot of ways people innately organize their thoughts. Some of them translate much more easily than others to code.
For some people, even step 1 is a hurdle that there are insufficient resources to clear.
Definitely 4 but stage 2 always comes back, it’s just not as emotional anymore
Phase 0).
Started to learn last year, 2626143747722 articles later about “No company will hire JR devs anymore” and “AI will replace all of you.” and I decided to stop :(
it can be still useful to know how to code, for when you want to put together a tool, or something that does things automatically
That’s what the junior devs want you to think!!
I never found it that hard… But I also never expected to just know everything. Coding is life-long learning. People who see it as “a thing to learn once” struggle a lot more I think. They also start to fall behind at some point.
100%. I also never found it that hard but I’ve been doing this 20 years now and I’m still learning. I look back at what I did a year ago and I probably wouldn’t write it the same today. I’ve worked with people who don’t seem to have learned anything in 10 years and it baffles me.
