Software teams have a variety of tools, software patterns, architectural decisions, and process flows at their disposal. This can be daunting for a new engineer who wants to make an impact but doesn't know where to start. It can help to take a step back and look at the bigger picture. Building software isn’t just about writing code.

Where to Make an Impact

Impact is both organizational and technical. To discover where I can make an impact, I pay attention to the daily experience of myself and my team. I try to identify the areas that contain:

• Pain points
• Frustrations
• Inefficiencies
• Repetitive knowledge or process gaps
• Communication barriers or miscommunication
• Unclear direction for moving forward
• Lack of knowledge transfer

How to Make an Impact

Whenever I sense an issue, I start troubleshooting. The one question that has helped frame my mindset, is this:

How can this be made easier?

This one question opens the door of possibilities. It doesn’t require years of experience or a perfect understanding to get things started. All it does is identify ways that a situation can be made better or a gap that can be filled.

Solutions vary greatly. They can be based on what I’ve learned through books, through past experiences, and through reaching out to colleagues who can provide help and advice. Sometimes, one solution that works best in one instance may not apply in another.

What has worked best for me is iterative problem solving. I think of one or more solutions to a problem, try one out, assess the results, and iterate. If it works, great! If it works to a degree, I keep augmenting it until it resolves the issue in a sustainable fashion. If it doesn’t work at all, I try something else.

Making an Impact Through Documentation

When I first started working on a client project, I spent three days pairing with a client developer to get my computer set up with all the applications we needed to use to access stories, develop and build code, communicate with team members, etc. Some of the time, we discovered the tools we needed when the time came to use them, which may be why it took so long.

Then I thought...

How can this be made easier?

Well, it would have been much easier if I had a plan to follow, on what to install. So, I spent some time documenting all the applications that we installed on my machine or added to my browser bookmarks. The scribbled notes meant for my consumption alone were transformed into a simple checklist that could be useful for the next new hire. I uploaded this to the client's online documentation portal, and it ended up becoming an onboarding tool that was used across the entire software engineering department. I wrote zero lines of code but still added value. The client was happy, and so was I.

Making an Impact through Process Improvements

As time progressed, I joined other teams and worked on various applications and features. One team encountered pain points when merging features, especially larger features. We would encounter painful merge conflicts that would take a long time to sort out. This pain point was brought up during one of our retros.

So we thought...

How can this be made easier?

Well, we could create smaller PRs. Smaller feature branches would reduce merge conflicts. If someone was working on a larger story that required a lot of changes, it would be reasonable to create multiple PRs as the story progressed. This would make it easier for the person merging the PR because there was less to merge, as well as the people reviewing the PR because there was less to review. Our team agreed to try it for the next sprint. We were happy with the results.

We even used this concept when we made large-scale refactorings. We first mobbed on the changes to add clearly defined seams. Then, we divided up the rest of the work amongst different team members or pairs. The PRs were merged with fewer conflicts because there was less overlap. The client was happy with the new approach, and so was I.

Making an Impact through Teamwork

Sometimes the answer to the question hits a roadblock. A divide that you cannot overcome due to sheer “rules of the game.” Things that you seemingly have no influence over. When this happens, I try to think of another answer to the question that is worth trying out and is hopefully accomplishable.

One topic that came up several times in my team was the lack of clarity on how to approach larger stories. Many times, the sprints contained a few large stories that were expected to be completed by the entire team. However, there was no clarity on full scope, how to break up the work, or who does what.

So, I thought...

How could this be made easier?

Well, if we had smaller stories with clear scope, each of us could pick up a story to work on. These small stories would build up to the larger feature that the client wanted to have completed. This approach made sense in my mind, and fit with everything that I'd learned about agile and incremental feature building. However, this answer hit a roadblock. The stories couldn’t be made smaller.

So now what? The pain point still existed. Our team still needed to be productive within the confines of the rules we worked with.

So, the question again is...

How can this be made easier?

Well, we could break up the stories into subtasks, which are not negatively impactful from the business point of view, which are seemingly unlimited in terms of how many we can create, and which can accomplish the clarity that our team was seeking to obtain.

So we tried it. When our team was about to start a new large story, we mobbed on discussing the overall design, we added subtasks with helpful details, and we discussed who wanted to start on what. Once one subtask was completed, the next one was picked up, and so on, until all of the pieces of the pie were finished. We filled the gap, we added value, and our team was happy and productive.

In Conclusion

As a software engineer, we want to do what’s best for the client and make an impact. Since what’s best is relative and temporal, it helps to think of what we can do to make things easier now. Filling a gap adds value. Relieving a pain point adds value. As we iterate over making things easier, it leads to what’s best.