I’ve been writing software professionally for a few years now, and I’ve been reflecting on the skills my co-workers told me would be useful when I first started working here. Writing quality software takes a lot of skills, and it can be overwhelming to decide which ones to focus on first.
Out of all of these skills, there are three that I find myself using every single day. I find that these skills shape how I think about writing software.
1. Identify Your Own Assumptions
During my first few days at Atomic Object, I paired with a developer who kept me engaged by asking me questions about the code while he typed. Typically, he would ask what I thought a particular piece of code did. That question was usually pretty easy and short. It was the follow-up question that always stumped me: Why did I think the code does that?
Usually, I tried to derive the behavior of the code from the names of the variables and functions found in it. My co-worker pointed out, almost obsessively, that I was making way too many assumptions about what the values of these variables could be, or what side effects particular functions might have.
Making these assumptions isn’t inherently bad, but forgetting the assumptions you make will lead to buggy software. For example, you can assume that a third-party API will return correct data and build your code around it. However, when you find that the code you wrote is buggy, you need to remember what assumptions you made and prove them along the way.
Because software is written by humans, it’s unfair to think that fellow developers will always write code that works perfectly. When interacting with software that’s written by someone else, you’ll need to make some assumptions about its behavior to continue forward progress and trust that it’s correct. But when bugs start to come up, you’ll want to prove that trust a little bit more.
2. Write Test Code Before Production Code
This skill is at the core of test-driven development, and I’m still working hard on refining it. My co-workers pushed this concept on the day I started, and they continue to emphasize it. While this approach feels unnatural and inefficient at first, writing test code before production code improves the quality of the software I write.
I’ve found that tests are the best way to prove out assumptions. Tests can provide documentation about the behavior of a piece of software. This is typically better documentation than the name of a function or a comment above the function (what I considered to be a best practice before). By writing the test first, I find myself naturally documenting all the edge cases that could happen for a particular function.
Learn Vim
One of the first skills my co-workers suggested was learning Vim. According to them, knowing how to use Vim keybindings would increase my productivity by allowing me to edit code much quicker. Initially, using Vim did the exact opposite. I was struggling to even move up and down lines of code without using the arrow keys. But after an initial steep learning curve, I’ve found using Vim to feel quite natural.
One co-worker claimed that Vim was not only the best way to edit code, but also the correct way. While that claim might be a bit bold, I do see a bit of truth in it. By minimizing the time it takes to navigate around the codebase, I can ensure that I spend most of my energy on my craft.
I also believe that using Vim puts me in the right mindset for productivity. It reminds me of a story a colleague told me. This colleague loved to hike in the mountains, and he was telling me about techniques that expert hikers would use to reduce the weight they carried. They went as far as cutting the handle off their toothbrushes, but even that wasn’t enough. They also hollowed out the head of the toothbrush with a drill. At this point, they may have been saving an unnoticeable amount of weight, but they were getting into the mindset that every ounce mattered no matter how small.
Learning Vim has a similar effect in my workflow. I want to make sure that I can write software as efficiently as possible. I need to optimize my toolset as much as I can. Vim is a key tool that I can use across many projects in my career. It challenges me to manipulate text as quickly as possible by learning more shortcuts each week. I’m glad I learned it early on in my career.
Conclusions
Early on in a software development career, there’s a lot to learn, but these three skills clearly benefit me every day. What do you see as key skills in your career? Leave a comment below!