Progression as a coder

Starting off learning to code, an often common goal set out is to simply code to get it working. Simple and straightforward.

This is a perfectly fine goal when starting off because you are still learning and don’t know all the ins and outs of coding and how to think in terms of code yet. This is usually the standard of what early students are striving for, maybe even students in general depending on how loose the curriculum is.

The goals are simple and aren’t driven by possible edge cases that can find holes in the code yet. Refactoring code hasn’t yet been introduced and isn’t really needed, because you simply are trying to code it to work in the first place. Not to work in the best way possible.

Leveling up

As a coder starts to delve into harder projects that are more open ended and more likely have a range of different solutions, it is easy to fall into the trap of trying to hard to “big brain” the code and have it be over convoluted rather than go for a simpler and more often better approach.

It is often the case that during this part of one’s coding career that the code itself becomes difficult to read because of the combination of still being fresh from the mindset of getting things to simply just work with the now ideal of trying to code in creative ways in order to achieve the goal.

It’s not apparent when coding alone, and even with a partner if you’re both coding together rather than taking shifts, enforcing these bad habits upon each other. Overthinking on how to reach a goal while being tunnel visioned on said goal is destined to end up in hard to read code, that works! but at a cost.

Where we are now (at least for me)

As a coder progresses in their career/education, the value of planning out the code reaches new heights. Thinking ahead on how you want the code to be laid out, interreact with each other, what’s reasonable to achieve, what could be considered a bonus objective, is all now the most important phase of the coding.

Reaching this stage, figuring all of these questions out is the hard part, because you’ve already learned how to code and how the language works(at least for the most part), so now you can take the time to think past a one set goal. Taking the time to draw out how the code will work, requires thinking and strategizing. Writing the code, is simply like putting in the puzzle piece that you already know where it belongs.

Reaching this stage, thinking about adding code to the overall project isn’t an insert and go operation. It’s necessary to think about and be clear about what it does, how it works and making sure it doesn’t interfere with what is already working.

Summing it up

There’s obviously more to this in stages of a coder’s expertise, but these are what felt like clear and distinct parts of my coding growth. Being aware of how you’re growing and working on your weaknesses to have them become strengths is vital to improving as a coder.

Improvement is a never ending journey and being open to help and criticism will make the journey much easier and let you reach new heights that aren’t possible if you simply code alone.

The best part of being a coder is the community that’s with you. We’re all here to support each other and help each other become the best versions of ourselves that we can be. Being open will be your biggest asset as a coder and one that you won’t regret.