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?
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 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
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 🙂
What’s TDD?
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:
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.
Test Driven Development. The route to programming nirvana includes a stop at this station