Managers all wish their developers were more productive. Most engineers enjoy the feeling of being productive as well. We like to create, and we like to look back on what we’ve built with pride.
However, sometimes we’re not as productive as we’d like to be, and it’s not for lack of motivation. Instead, there may be behavioral and environmental factors that contribute to a slower development cycle.
Let’s consider six of these barriers to fast-paced software development and how we can overcome them.
Barrier #1: Not Understanding the Languages or Technology Used
As a software engineer, it’s essential to become familiar with your company’s tech stack. If you’re frequently using a programming language in which you’re not yet proficient, take time for deliberate learning.
Dedicate time specifically to learning the language or tool rather than just struggling with it during development tasks. It may feel like you’re wasting time to begin with, or you may feel guilty that you’re not working on your specific task, but you should brush those feelings away! It’s much more effective to spend a little extra time up front to develop a skill than it is to muddle through things.
This is at the heart of Stephen R. Covey’s seventh habit: sharpen the saw. Abraham Lincoln once said, “If I only had an hour to chop down a tree, I would spend the first 45 minutes sharpening my axe.” The metaphor is that it’s more effective to sharpen your skills first than it is to keep chopping away at your proverbial tree with a dull tool.
Platforms like LinkedIn Learning, Pluralsight, or Udemy have incredibly useful video courses for learning new skills. Or maybe you learn best through building small example apps. Maybe you enjoy digging into the docs or blog posts. Whatever your learning style, it’s important to understand how you learn best.
A little upfront cost in learning will pay massive dividends for your productivity in the long run.
Barrier #2: Not Understanding the Architecture of the Codebase
It’s not enough to master the tools you’re using – you also must master your codebase. This may not be much of a challenge for smaller repos, but this can be a daunting task for legacy codebases that have existed for more than a decade.
When you don’t understand the architecture of a codebase, you may not be sure where to make a change. Or, you may not understand how a given change will affect the surrounding pieces in the app. You may end up duplicating existing efforts because you weren’t aware of a helpful component or utility method that was already there. You may even end up making a change in the wrong place, leading to rewrites down the road.
When onboarding at a new company or team, it’s important to get an architectural overview from another developer. This overview should include the app architecture itself and also the codebase and directory structure.
CodeSee Codebase Maps are here to help! With CodeSee Codebase Maps you can visually explore your codebase, create your custom maps and annotations, and easily onboard new developers to your team.
Barrier #3: Slow or Flaky CI Pipelines
Now that we’ve addressed some personal action items, let’s turn our attention to some technical and organizational problems.
Continuous integration is important for keeping the master branch of your codebase in a good state at all times. Your continuous integration pipeline can run whatever checks you want, but at the very least you should run your code formatters, code linters, and tests in your pipeline. These tests might be unit tests, integration tests, or end-to-end tests.
Once your CI pipeline is in place, it’s important that you don’t let your test suites become too slow. Imagine waiting an hour for your tests to finish running before being able to merge any pull request! What a productivity killer.
Even worse, imagine that some of your tests are flaky, meaning that sometimes they pass and sometimes they fail, without any apparent rhyme or reason. Flaky tests destroy your confidence in your tests, as it’s often hard to tell if something is truly wrong in the app or if the test is just flaky. Developers spend extra time retrying flaky tests and re-triggering pipelines, leading to a loss in productivity.
If you have a slow CI pipeline, explore ways to make it faster:
- Are there jobs that can be run in parallel?
- Are there steps that can be removed altogether?
- Are there long-running end-to-end tests that could be stripped out and replaced with faster unit tests at a lower level?
If you have flaky tests in your CI pipeline, investigate them as soon as you can. Temporarily remove them, if needed. Ideally you’ll be able to identify the source of the flakiness and update your tests so that they pass consistently.
Barrier #4: Slow Code Review Process
Code reviews are often a bottleneck in most software companies. Developers are frustrated that their pull requests sit around unmerged for too long and that they spend too much time bouncing back and forth between new work and old work.
We won’t go into all the ways that you can improve your code review process, but here are some high-level ideas:
- Keep pull requests small.
- Use pull request templates to provide all the context a reviewer would need.
- Implement response time SLAs.
- Train junior and mid-level engineers on the key things to look for during a code review.
- Set up CI pipelines to run linters, formatters, and unit tests.
- Use pull request review apps so you can easily inspect UI changes.
- Generate diagrams to visualize your code changes using a tool like CodeSee Review Maps.
CodeSee Review Maps take the same ideas behind CodeSee Codebase Maps, integrating nicely into your pull requests by posting comments with maps of what’s changed.
For further reading on ways to improve the code review process, check out this blog post!
Barrier #5: Too Many Meetings
Most developers complain that they’re overloaded with meetings. Between standups, planning meetings, status reports, demos, all-hands meetings, and sprint reviews, it’s hard to find any peace and quiet to actually get any work done!
In response to missed deadlines and low productivity, ironically, the approach many companies take is to have more meetings to figure out why they aren’t getting any work done!
If you find your day filled with more meetings than you’d like, consider dividing your day into a maker’s schedule and a manager’s schedule. Group your meetings toward the beginning or end of your day so that you have extended periods of time in between to focus. You can even book time on your calendar as “focus time” to get into your flow state and do some deep work. If you’re often invited to meetings that really aren’t relevant to you, consider politely declining those meetings.
Barrier #6: Inattention to Quality
Writing sloppy code quickly has short-term benefits in terms of getting code out the door, but the cost of maintaining that code will bite you in the long run. Code that is merged as a “temporary fix” often becomes much more permanent than you’d think.
When developers or organizations don’t pay attention to quality, they may find that they’ve sped up in the short term, but they’ll spend that saved time fixing all the bugs later. In fact, the amount of time spent fixing production bugs usually ends up being much more than the amount of time you would have spent fixing those errors before merging your code.
If you’re noticing that you spend a large amount of your time fixing bugs, you’d do well to pause for a moment and ask why:
- Are developers not performing thorough code reviews?
- Is the organization pushing to release features faster than developers can reasonably build them?
- Is the test coverage lacking in critical areas of the codebase?
Whatever the root cause, your priority should be to stop the flow of bugs. Slow down, do quality work, write tests, and you’ll see your overall development speed improve.
Conclusion: Six Barriers to Fast-Paced Development
To recap, here are six barriers to fast-paced development. With a mix of personal, technical, and organizational concerns, opportunities for improvement are everywhere!
- Not understanding the languages/technology used
- Not understanding the architecture of the codebase
- Slow or flaky CI pipelines
- Slow code review process
- Too many meetings
- Inattention to quality
