Institute That Change in Your Software Project!

As developers, we cannot be afraid to make change in the projects we work on. In some of my roles, I have sometimes neglected to do this because I felt it was not my place to institute new policies, libraries, or patterns, as I was not the team lead or even a senior dev. If you work at a company where new ideas receive backlash (as I have), then you know that suggesting or implementing new things can be difficult. Yet, every developer, no matter their rank, is capable of this, and sometimes the difference between great and average developers is implementing it instead of suggesting it.

Why instituting change is important

I will give you a real life example. At one of my previous jobs, I found a pull request (PR) template online and was using it in all of my new PRs, by pasting it into the PR body and editing the contents. This template had a brief summary of what changed, how the changes were tested, and then a checklist containing things that should be done for every new PR: reviewing my code, creating new tests, updating documentation, etc. When other developers would review my PRs, they would be able to see what I had done to make sure this PR was ready to go, before it was even reviewed by another person.

While this was happening, I knew that I could add a pull_request_template.md file to the project and enable other developers to use this template too. However, I didn’t do that: I felt it wasn’t up to me to change how other developers write PRs, even if it would be to the team’s benefit. I didn’t institute change. Lo and behold, a few months later, another developer implemented the PR template in the project, stealing my thunder and making me feel foolish for not doing it myself. Most of the team thought it was a great idea to implement, and all the praise went to the developer that implemented it.

Implement change, don’t just suggest it

Here’s another real example. At a previous job, I suggested we add Prettier to the React project our team was working on, as I had used it in other projects and it made the code much cleaner and easier to write. However, I only mentioned it in PR comments or in Teams, I didn’t implement the library. Another developer eventually did, and it made the project much better for everyone. This is why you should implement new things, not just suggest them.

How to institute change

I’ve always thought that PRs are a great way to suggest some new technology, because if people agree, then it gets implemented - it doesn’t just die as a “we should do this” comment somewhere. Of course, if it’s a big change, like moving a codebase from one framework to another, discuss that with the team first, or you risk wasting a lot of time doing something the team doesn’t agree with. You could always start with the ”we should do this” comment, and follow it up with some initiative: ”If there isn’t any disagreement, I’ll go ahead and create a new PR to implement [library name] in the project”.

Conclusion

Implement the change you wish to see in your projects. Don’t wait for someone else to do it, or feel that you are not qualified to move the project forward. If your job title doesn’t reflect a leadership role, don’t let that stop you. Everyone can be a leader in some way. Great teams are made of innovators and leaders that are ready to take that next step forward to improve the project, so be one of them. Just remember that communication with the team is key.