This post is a bit of a general one, as its topic could be applied to really any endeavor, but I’m going to focus specifically on Software Engineering. In day to day development, we frequently have both software systems design and programming tasks. However, those are just the technical aspects of the workday. It doesn’t count all the meetings you sit through, or the time you spend catching up with teammates. So it’s easy to see how the hours can just slip away from you. Heck, even if you were to not talk to anyone and just focus on your own tasks (not likely, because nearly any task of sufficiently large scope will require at least some collaboration, but stick with me for this thought experiment anyway), you could spend a lot of time reading to learn how to do something or you could spend hours designing a system you need to build. The crucial component though is that you didn’t necessarily write any code. While that can be okay for brief stints focused around learning, it’s generally not a good idea because it inures your brain to view coding as a context switch.
The goal as you gain experience should be that coding simply becomes an extension of yourself, of your ability to manifest your ideas and designs into something tangible, and that it becomes effortless. “How do I make coding well become effortless?” you ask. Well, the simplest way is to always be producing.
Backstory
This was originally a lesson taught to me by my manager during an internship at Facebook (now Meta). After onboarding week, it was still overwhelming to learn about all the internal tooling at Facebook, to the point where I felt I had a bit of decision paralysis. I needed to just begin, but even after I was able to start on my project, I would frequently find myself getting stuck in documentation or tutorials, without really seeing how the pieces connect together. I had some code in local commits, but I hadn’t hit the good code velocity that I would need in order to finish my project.
After a couple days, my manager took me aside and asked if I was able to make any progress (because he couldn’t see any commits in version control). I showed him the local commits, but explained where I was stuck (with lots of “TODO” code comments).
Much to my surprise, he then enthusiastically said, “Good! That’s fantastic. Just don’t keep it solely local until it’s done. If you’re stuck, put that up on <Facebook’s Code Review and Submission Tool> and mention me in some comments where you’re stuck. We can work through them async over the review tool, or we can set up a meeting.”
I was amazed that he would even want some half-baked code up on the review tool, when it clearly wasn’t ready for review. But what I realized was that showing my progress, day to day, not only helped keep him in the loop (because he loved reading code), but also allowed him to help me whenever I was stuck.
Why Produce Every Day
In addition to keeping stakeholders in the loop and making it easier to get help, constantly trying to channel my thoughts into code throughout the day increased my code velocity. Even if I were completely stuck on next steps, I could write as many of my thoughts regarding the current design into code and then comment it out and preface it with “TODO: Not sure if this is right”.
Side note: A technique I have followed, whether I’m in my “coding zone”, or I’m stuck, is to start with a bottom-up deconstruction. Utility modules and helper methods, in service of the feature I’m trying to build, are always helpful, so I can start there. The problems helper modules solve are pretty well constrained, so they’re easier to tackle and they can be pretty good ways of initially getting some code out for review, which you can then iterate on.
Another very important reason for why you want to constantly be producing is that it holds you accountable for features and projects you want to take on. You can see day-to-day, and week-to-week, what progress you have made, and if you need to change your approach. That discipline will enhance your long-term thinking, as well as your software design skills. Every day, you are making progress, and surfacing that progress to stakeholders, even if it’s not fully thought out so that you can have constant dialogue with them. Over time what you’ll find is that there will be less of those “TODO” comments AND that you will pivot less day to day, and instead keep chipping away at incremental features toward a project vision.
There’s a concept in X (formerly Google[x]) called v.0.crap, which is intended to evoke some humor, but also simultaneously lessen the anxiety any team member has to share his/her “first draft” of work with other team members when asking for a review. It’s not that you are literally producing sub-par work, but rather that you don’t have to feel like it’s perfect in order to share it, to start a dialogue, or to get a review. When thinking about code, a commit with a lot of “TODO” comments, but some otherwise good starting methods/functions could be v.0.crap.
Over time, that first draft you put up, that v.0.crap with not fully-explained details, will get clearer and will approximate the code you admire from senior engineers. So keep at it!
Hope you enjoyed this post! If you have any thoughts on how to increase your code velocity, do drop me a comment 😃!