CI/CD (continuous integration/continuous deployment) is one of the fundamental steps in software development today. They run our tests, they build our code, and they deploy that software to any necessary consumers.
But since they handle so many tasks, CI/CD pipelines can get bloated and take a long time to run. CI/CDs can take over an hour to run if there are many serial steps involved. As a developer, this often means waiting around to see if my build has passed before I can progress on a task.
Although some developers are able to keep many work tasks running at once, I have a hard time staying on top of many different streams. As a result, I like to focus on and finish one task before moving on to the next. This means that when I’m waiting for CI to finish, I take on work that I can forget about when the build is complete.
As opposed to watching the build to see when it finishes, here are some ways I found to use that time more wisely without context switching into another piece of work.
As a guide, the ⏰ emoji denotes how much time each item can take (which can of course vary).
⏰ = 0-20 minutes
⏰⏰ = 20-60 minutes
⏰⏰⏰ = 1+ hour
Code Review ⏰⏰
Reviewing a coworker’s code is one of the best ways to level up as a developer. It forces you to consider alternate architectures and think of ways to improve an existing codebase. It also helps you gain familiarity with other parts of the codebase.
Since developers at many organizations rely on code review before they can ship their code, reviewing it can help expedite an otherwise long wait. I have often found that the best engineers on my team were the ones who actively taught using code reviews.
For junior developers, one of the best ways to start code reviewing is to ask questions. You may not be able to offer insightful solutions, but you can learn the thought process behind a lot of decisions and code patterns.
Update Documentation ⏰
Good documentation helps your users understand how to use a product effectively and efficiently. It provides clear instructions, explanations, and examples, making it easier for users to get started.
I don’t believe in the idea that good code documents itself. Often it’s a way to push off writing good docs for the sake of getting a product deployed. But thoughtful documentation can speed up a user’s onboarding of your product. And since those minutes and hours multiply by the number of users, it generally saves more time than the actual documentation writing.
If you are making a change to a feature or writing a new one, spend some time updating the documentation to account for it while your CI/CD is running. It will help users find your changes and understand how to use that feature.
Triage Contributor Pull Requests ⏰
I am a strong advocate that any action that gets you closer to your users is worth doing. If your organization has any open source/core repositories, take a look to see what other developers are doing to improve your codebase.
Aside from dependencies and typo fixes, external collaborators offer a ton of expertise to your code. They offer ideas for feature implementation as well as bug fixes for edge cases. Some PRs help to clean up the styling or add in tests. Some companies may hire developers based on their activity on open source repositories.
Taking the time to look at what changes contributors are making helps you to understand what holes might be missing from your engineering team’s knowledge base. Someone who is personally interested in the work can teach you what to look for when you are writing your own code.
Write Tests ⏰⏰
This wouldn’t be a Codecov blog post if I didn’t mention something about writing tests. One of the best ways to learn about a codebase is through the tests. As a developer, you can learn a lot about the models and APIs through unit testing, but also the expected code flows through integration and end-to-end tests.
Taking the time to write good tests for your code helps you and other developers understand those changes in the future. And of course, tests help to ensure that those code paths will behave the way that you expect.
If you are looking for ways to add tests, you can use code coverage to identify holes in your test suite. It tells you what lines of code haven’t been tested, so that you can quickly figure out where to invest your time. Increasing your code coverage can help reduce the number of errors found in production.
Rewatch Customer Calls ⏰⏰
As an engineer, we often aren’t closely involved with the end user of our products. But knowing how your customers use a product can provide valuable insights. By being honest with their feedback, users can enable changes in product roadmaps and feature development.
Many revenue teams record calls with customers in order to discuss their needs with the team and to aggregate data to inform the product. These are great sources of information for an engineer to get context on the features they are developing.
Review the Product Pipeline ⏰
Product roadmaps are a great resource to understand the business side of a company. A significant amount of research is done to ensure that the highest priority features and fixes are delivered to the most number of customers. As a result, the product roadmap gives great insight into what a company is focusing its efforts on based on the market and its users.
Unfortunately, the product roadmap is not always top of mind for a developer. Most engineering teams will discuss the timeline of individual items once a quarter in order to estimate time requirements. The high-level goals can get lost among your other priorities and tasks.
By reviewing the product pipeline, you can refresh and strengthen your understanding of the company and its products. It will help to inform you of why certain features are being prioritized, or how your work fits into the overall scheme.
Try a New Technology ⏰⏰⏰
One of the best ways to level up your coding toolbox is to try using new technologies. Some of the best engineers I’ve worked with always seem to be playing with some new framework or library they were told about. As a result, they were often the people who would be making big improvements to the infrastructure of a codebase.
Learning a new technology is not just about using something new. It also helps you compare and contrast the tools that you are already using. Why would you want to use React versus Angular? Is Python really the best choice for your backend? Taking the time to learn new technology will help round your abilities and may even open up job opportunities in the future.
Read a Language or Framework API Documentation ⏰
When I was a younger developer, one of the senior engineers on my team gave me great feedback on my pull requests. Often, they pointed out better functions or libraries to use that I had never heard of. Many of these were just built-in functions for a language (Python) or a framework (Django).
From that experience, I learned to take the effort and time to read the API documentation for the major technologies I was using. I wasn’t always guaranteed to remember everything, but I knew that if I needed a function, there might be something already written for me.
Open and read the documentation that goes into the base languages and frameworks you use daily. They often have invaluable insights into their own concepts and usage. Having this information in your back pocket can save you a ton of time developing a feature or optimizing a function down the road.
Write a Blog Post About Your Work ⏰⏰⏰
One of the scariest things to do is to publicize your work. Writing and sharing about what you’ve accomplished opens you up to scrutiny and criticism. It may even make you feel like the work you do is insignificant.
But this is very rarely the case. The vast majority of feedback received is positive or is constructive criticism. As a developer advocate, I’ve learned the importance of writing about your work. Some of the best articles I’ve read were a result of engineers finding interesting ways to solve their own problems.
Writing a blog post about your work is a great way to ensure that your efforts have higher visibility. As an example, we had a customer write a blog highlighting work they had done to help other developers using xcresultparser and Codecov. Even if you keep the post internal, other stakeholders can see the value of your work and why it matters to the overall product. Other engineers on your team can learn from your experiences and improve on the codebase.
Dive into the Data ⏰⏰
As an engineer, we have outsized access to data about how our customers use our products. But often, that data is just sitting around without an individual taking charge. Learning how to take advantage of that information can help you figure out what to focus on.
I’ve found the best way to learn about your data is just to try to ask a question about it. How many customers do you have using a certain version of your product? How long does it take to set up and onboard? Are you seeing a particular segment of users growing quickly? Finding answers to all of these questions will help your product and business grow.
[BONUS] Improve the CI/CD Pipeline ⏰⏰⏰
Instead of working through any of the above actions on the list, you could help improve the entire engineering organization’s time by finding and optimizing the CI/CD pipeline.
Codecov’s new Automated Test Selection feature (beta) helps to identify what tests are necessary to run which can greatly decrease the amount of time it takes to run CI/CD. We have seen over 75% time savings for every CI run using Automated Test Selection in our repositories.
As of this writing, Automated Test Selection is only available for Python projects. If you are interested in trying it out, take a look at the documentation or open up an issue on our feedback repository.
