As a software developer, I spend almost every week at Code for Boston. There are a large number of attendees consisting of optimistic boot camp graduates thirsty to get some experience coding on real open source projects. Having worked with over fifty boot camp graduates over the past year and a half and seeing their challenges, I have developed an understanding of the challenges boot camp graduates face as they transition to coding in the real world. While you can join me at Code for Boston to learn these things, I am going to share some of my wisdom below.
Git Skills
In order to effectively code in a team, you should have mastery of git and work with some kind of project management tool. For most of our open source projects, we use GitHub at MAPC and Code for Boston. We use GitHub Issues to manage our project tasks. GitHub Issues are close to the code base, open to the world, and can be easily referenced and closed from commits.
There are lots of philosophies around how to structure git commits. Writing good commits will come to you with practice and experience. As a boot camp graduate, you have likely not yet had to dig into someone else’s code base and pray that certain information about a commit was there so that you can figure out what is going on. It is important to write a great commit message. If you are intentional about writing that great commit message and keeping your bug fix or feature down to a few great commits, it will be easier for others to understand the purpose of your code. Often the question you need to know the answer to is: “is it safe to change this code and if so, how?” Commit messages are a big part of how you find the answer to that question. You can also get a sense of commit message quality by looking at a class with git blame.
Inevitably you will at some point in your life commit a secret to a public GitHub repository. Do yourself a favor and setup and practice using BFG Repo-Cleaner today. When you actually need it, it will feel like a scary emergency and you will feel better having practiced this skill.
Pull Requests and Code Review
An important part of building your coding skill is to receive constructive criticism of your current work and style. You will likely do this by submitting a bug fix or feature as a pull request to an existing project. To improve your skills it is also helpful to review other people’s code. This is a chance to think and be intentional about what makes good code. While some new coders get anxious about making comments, the best thing to do is to treat code review as a discussion and not expect every thought of yours to be blindly implemented by the pull request author. Thoughtbot’s Guide has great advice on reviewing pull requests.
My process for reviewing a pull request is to first review the code on GitHub for any errors, opportunities for improvement, or obvious bugs. I make sure to understand what the pull request is attempting to do as a unit and also what each commit accomplishes towards this goal. If I do not understand I ask the requester questions to create this understanding. Once I fully understand the pull request I clone it to my local machine. There I run and check to see if the test suite passes. Then I actually run the app to try out the feature or go through the steps to reproduce to the fixed bug to prove it has been fixed. Once this has occurred I approve the pull request and let the requester merge it into the develop branch. Then the update is deployed to a staging instance to be tested one last time by a developer and any relevant outside parties before being promoted to production.
Fixing Bugs
Fixing bugs on your own or other software can be challenging. With the right toolset, you can surmount these challenges and successfully get your software working. Your first step is to reproduce the bug. Hopefully, the user has submitted enough information so you can see and experience the bug for yourself. If not, you need to open the lines of communication with your user so that you can effectively reproduce it. If they are getting the bug and you are not, you need to figure out what is different between their setup and yours that might be causing the bug. If you cannot reproduce a bug, you do not understand it and most certainly will not be able to fix it.
Once you can reproduce the bug you need enough information to figure out what is going wrong in your code to cause it. There is a large menu of options of what can cause incorrect software behavior, your job is to eliminate options from that menu by trying the most likely things and working your way to the least likely things. If you are lucky you get a warning message somewhere that surfaces an obvious solution. Googling reveals a typo or need to coerce an object to another type. If you are unlucky you enter the frontier of the unknown. You uncover a bug in the web framework or programming language you use. An external API behaves differently than its documentation suggests. All sorts of crazy things can happen and go wrong in software, so when it comes to things you believe to be true: trust, but verify.
How to Build These Skills
Many of these skills involve coding in teams and working with users. While you are now one step ahead of your peers by reading about them above, you will only master them through practice and experience. The best way to get this practice and experience is to work on real projects with other developers. Try your hand at an issue for an open source project. Submit a pull request. As long as the project is maintained, you will likely get the feedback you need to improve your code.