4 New Year’s resolutions for developers in 2019

There’s no time like the beginning of the year to reassess what’s working and what isn’t in your day-to-day workflow

Amid product deadlines and competing priorities that clamor for our attention during the year, it can be easy to neglect some of the healthy habits that should be part of our ongoing software engineering processes. However, the first quarter of the year signifies a time to reflect and refocus. It’s a time to bring those best practices back out from under the rug and incorporate them into updated plans and new goals. Similar to the resolutions many set for their personal lives, I offer developers four resolutions to keep in mind as they kick off the new year.

1. Invest in documentation

When pressed for time, it can be easy to cut corners when it comes to creating robust documentation for your code or project. After all, it's not an essential component needed to deploy. But in reality, investing time in documentation at the outset will pay dividends down the road. Writing good documentation is crucial for a seamless handoff of a project among team members. This is especially true in infrastructure engineering, where other developers must quickly understand the rationale of each design choice, adopt the change, and be productive. To think about it another way, documentation, if done properly, can save countless hours spent answering questions later on, allowing you to focus on new development instead of support.

Earlier in my career, I created a library to enable A/B testing without much thought towards building a comprehensive user guide to go with it. Adoption suddenly ramped up due to product experimentation demand, and I spent two months answering questions over email and chat, in addition to sitting down with developers to teach and help troubleshoot. It felt heroic and exciting in the moment, but in hindsight, was my time really well spent? I was helping developers one-on-one, but if I had created a good user guide with answers to the FAQs, my time could have gone much farther, as I could have helped many people simultaneously. Good documentation enables you to scale yourself.

2. Test smarter

As engineers, we often have a propensity for quantifiable measurements, which means that we sometimes look at line coverage as a way to evaluate the quality of our testing. However, not all lines of code are created equal; sometimes, a particular code path will have a much greater impact on the end user’s experience than others. For this reason, it’s important to be smarter in your testing: understand the most common use cases, and prioritize tests against these scenarios. If you aren’t sure how your code is going to be used, don’t be afraid to ask your key stakeholders questions—the better you understand the end goal for your code, the better your testing will be.

As an example, imagine the code behind a messaging application. You have code for many different functions, including receiving messages, composing replies, deleting old messages, and organizing the messages into folders. When you think about the end user, which of these functions will be most important? In a perfect scenario, you would test for all features, but when time is of the essence, what would you prioritize? The answer is likely the ability to receive and reply to messages. Being able to delete and organize messages is important, but not as critical or frequently used. In this instance, it makes sense to devote extra attention towards testing for these more important functions, while still covering the other areas of code with tests as well.

3. Focus on quality, not quantity in code reviews

The process of code reviews can be anxiety-inducing for both reviewer and reviewee, but it can be incredibly valuable to have another set of eyes review code before it’s deployed. Not only does the process of peer reviews foster consistency and collective code ownership, but it also acts as a form of knowledge-sharing. Good code reviews require the reviewer to take the time to understand the problem the code is trying to solve and to compare the end product against this goal. While it can be easy to fall into a habit of giving a more cursory code review that focuses on things like style and syntax, developers should strive instead to provide reviews that truly address the substance of a given code base. Even if this means you can complete fewer code reviews in a given time frame, it’s worth shifting to a focus on quality in reviews. Not only will the engineer whose code you’re reviewing benefit, but you may also learn more about different approaches to coding and problem solving by studying someone else’s work.

4. Never stop learning

In an industry where the only constant seems to be the fast pace of change, trends in programming tools come and go. Between the newest language or hottest machine learning framework, there’s always a plethora of skills to add to your toolkit. While it’s unnecessary to know how to utilize every new framework out there, it is important to stay informed and up-to-date with the industry and developer community.

Adopting a mindset of continuous learning helps expand your horizons and perspective when tackling future problems. It can be easy to settle into a framework or language that you’re most comfortable with, and neglect to think about whether that’s the right tool for the specific problem at hand. To put it another way, if your favorite language is Python, you may have a tendency to solve every problem in Python, even if JavaScript might be more well-suited to the situation.

As much as possible, developers should be attending conferences, networking with peers, and reading blogs to stay engaged with the industry beyond their direct scope of work. Whether you’re just starting your career or are a senior manager, there’s much to gain from tuning in to the constant innovations in our space.

Use the start of the year to reset

Similar to the personal resolutions many of us make at the start of each year, it’s important to apply this same thinking at work. There’s no time like the beginning of the year to reassess what’s working and what isn’t in your day-to-day workflow. Think about where you want to go in the year ahead and how these changes in your normal processes can help you become a better developer.

This article is published as part of the IDG Contributor Network. Want to Join?