Ways to contribute on a Software Engineering team other than coding
I have been onboarding onto a new project where the codebase is way out of my league. It is built not with one, or even two, but four frameworks that I have not worked in before. And they are complicated, fragile, and inconsistent to boot! Not necessarily the kind of team I can hop onto and immediately start coding up a storm.
While I work on understanding how to navigate the codebase and how things interact with one another, I still want to be able to actively contribute to the team. One of my mentors listed a few things that I can do without any knowledge of the configuration, languages or frameworks in place. It is helpful to be reminded that there are many ways so contribute to a software engineering team that do not involve coding at all!
1. Update the onboarding documentation
Odds are that some of the information on a given team’s onboarding documentation is out of date, incorrect, or defunct. During my onboarding I have noted many snags in the process like points of contact no longer working at the company, email distribution lists no longer used, permissions for certain softwares changed or removed, etc. It will save future devs time and frustration if I update the onboarding docs, and will help the team continue to move forward rather than stopping everyone in their tracks as they try to help troubleshoot why chromedriver refuses to open or why the ssh key configuration file isn’t reading correctly.
2. Update the local installation and set up documentation
This is similar to the first point, but deserves its own spot in the line up. Even when I finished the onboarding process to this new team, the local set up on my machine still took considerable time. As I hit more pain points setting up my local environment, getting access to the testing environments and repo, and configuring aliases that other team members forgot they created three years ago, I was taking notes in order to update the information in the app’s readme file or wiki. On the project I’m currently on, the readme is completely out of date and the wiki is nonexistent, so any contributions I add are better than what is currently there.
3. Learn the deployment and version release processes
Releasing a new version of the app and updating the testing environments with the latest version of the master branch are simple ways to help the development team that require no coding. On my team, on Thursdays I can create the next release number tag (such as 15.6, 15.7, etc), attach the notes for all changes involved, tag all of the corresponding JIRA tickets, and deploy the version in Jenkins. Watching the pipeline isn’t the most exciting thing in the world, but it’s good to know the process and be able to free up some time for other devs on the team.
4. Read tests and see which files are the most heavily tested
This is actually a tip I learned while interviewing a candidate for a role on my contract. Finding the longest testing files and can show what parts of the code are most heavily used. Reading through test code can help to understand what the code is trying to accomplish, what other code it depends on, etc. If there are files that are not as well covered or just not as expansive, a great way to start acclimating to the codebase is writing tests!
5. Ask questions as you discover things —fresh perspectives are valuable
Sometimes just asking questions is helpful for a dev team. You may see something that doesn’t make sense, or that you haven’t seen before, and it can expose valuable things to fix. Test suite blind spots, business logic failings, and documentation lacking details are all things I’ve found so far while onboarding, and then I’ve been able to help fix those issues.
I’m really glad I had that conversation with my mentor about not feeling like I could contribute on my new team. It helped me see that there is value in effort put into a project, whether it is code or otherwise. It can be easy to get tunnel vision and think that pumping out line after line in React is all that matters, but so many other things are necessary for a functional application. There is so much to learn, and I can‘t wait to see what comes next.
