I’m often torn between spending my time at work listening to senior engineers talk about complex subjects and just diving head down into a project that I can tackle with the skills I have right now.

When senior engineers have a postmortem on a serious issue, I know I learn about system design, communication, and failure assumptions. These are great lessons I can’t quite appreciate because I don’t make these kind design decisions on a daily basis, but I still cherish the knowledge for later use and I know it will make me a better engineer to just accumulate those high level lessons.

A programming state of mind

Most of these lessons aren’t things that are relevant while actually writing code. They are stories to guide my hand as I make smaller design decisions. If you think of coding as brick laying, it’s important to think that every small decision will eventually bubble up the highest level. Simple things like paying attention where your variables are being allocated, and if you are passing copies or references can end up having a performance impact that may change how the system operates as a whole.

Laying out your thoughts before you start coding is mostly a function of what you are keeping in mind. Do you need to be juggling all of the different states of your object? Do you need to be thinking about race conditions and thread interactions? It would be impossible to keep every lesson in mind for every piece of code, so having the optimal memory layout is extremely important before setting out to do anything.

Where is the line?

At what point have you thought enough about a problem to be ready to tackle it? The macro and micro scales have different thresholds. On the small end, having prototyping projects can be great when you don’t know where you are going. Your prototype should run into walls and roadblocks you weren’t aware existed, those become lessons to keep in mind when writing the project. On the macro scale, when are you ready to be in charge of your own project? If you only ever worked on enhancing and rebuilding things, does that help you when you start from scratch? There isn’t a prototyping stage for a job; most companies don’t let you leave for a month to try something else before deciding to come back or not. Deciding that you are ready to strike out on your own can be a much bigger commitment than spending a day trying a new technology stack.

I’m consistently between wanting to do more and wanting to learn more, and while learning-by-doing sounds like a good compromise it just hides the fact that you don’t know what you are trying to do. You are either building your skills up or you are putting them to use; programming isn’t a skill that just grows through repetition. To hone your craft, you have to take time away from focusing on getting the job done.