I get asked often how I work without ever meeting my coworkers in person. Won’t your co-workers worry that you’re watching Netflix instead of actually working? How will they know that you’re actually working when they can’t actually see you working? This is the part 1 of the series where I will cover the tools that I use in remote software development teams.
How do you work effectively in a team when you’re not all in the same physical location? This was a mystery for me too before I started working remotely. In this post, I’ll go over how the remote teams I have worked in functioned. Just understand that this post will be more specific to software development teams, although we did have team members in other departments collaborating remotely.
Using the right tools for collaboration is very important in a team environment where you are not physically within each others’ presence.
The tools we used are divided into five categories:
- Project Management
- Code repository service
- Exception monitoring
- Performance monitoring
- Code quality measurement
- Continuous Integration Service
Slack, email, video chat, and phone calls (only for emergencies). Yep, that’s it. Slack was the communication tool we used 90% of the time. Everyone on the team was on slack during work hours and this is how we communicated. In fact, in the various remote teams that I still work in, this is still how we communicate 90% of the time.
One note about slack, or any other chat services that remote teams may use, is that you shouldn’t expect responses immediately. The thing that’s vastly different when working in a full remote team vs on-site teams is that work tends to happen asynchronously. For example, in an office environment, if you have a question, you could just walk over to someone, tap on their shoulder, ask him/her a question, and get an answer right away. When communicating via Slack, things don’t work quite as synchronously. You may have a question so you send a question to a colleague on slack and he may respond to you 3 hours later. Do you wait for his answer and do nothing for 3 hours? Absolutely not! Once you ask him your question, just continue working. If you have a blocker that will be resolved by the answer that your colleague will give you, just pause that specific work and start working on something else.
Remote work tends to be more asynchronous than in-person work. I had a bit of trouble with this in the beginning but I got used to it pretty quick after a month. Actually, I found that it made me more productive since my days weren’t interrupted by constant interruptions and innocent “taps on the shoulders” for quick questions from colleagues. I could answer questions at my convenience when I wasn’t in deep focus working.
Email was also used, but generally for questions that didn’t need immediate responses. Also, emails are more or less used for communicating with people outside of our team, for example with clients. Within our team, we generally communicated via Slack.
Video conferencing apps like Google Hangouts and Appear.in are used only when we needed to talk face to face and pair program. Also, when I had a full time job in a remote company, we had a weekly video call meeting where the team would talk face to face. This time was used to catch up with other team members (since we almost never saw each other in person) and as a general weekly stand up.
Finally, phone calls are used for absolute emergencies. And when I say emergencies, I mean emergencies like the application in production is crashing.
When it comes to project management tools, I prefer simple tools. I absolutely abhor mega-tools like JIRA or Redmine. Too many features bloat the product with useless features that we never end up using.
My favorite tool for Project Management has been Github Issue Tracker combined with Waffle (https://waffle.io). I have also used Trello with the Github Addon, and I have found that to be useful as well if your team members include non-developers.
Waffle is a tool that integrates tightly with Github Issue tracker and provides a Trello-like board that you can configure with labels in Github. So let’s say that you have labels in Github like:
- In Progress
- Code Review
In GitHub, this will look like:
You see the “ready” and “code review” labels?
In Waffle, this will look like
What I like to do is create a bunch of tickets on GitHub without labels, which will be populated under the Backlog section of the Waffle board. When the tickets are ready to be worked on, I simply move the tickets out of the Backlog section in the Waffle board into the Ready section. When you do that in Waffle, this will sync with GitHub and add the “ready” label in the GitHub Issue Tracker.
Each team members are assigned to different tickets and they individually move the tickets that they’re working on into the “In Progress” field, which will also be synced with GitHub. Once they’re done, they make a pull request and move the ticket on waffle into the “Code Review” section. Once the pull request is merged, the ticket is moved to “Closed” in Waffle, which will close the ticket in GitHub.
The Waffle board sections are completely customizable and syncs beautifully with GitHub. I found this combination to be the best in software development teams due to its simplicity and effectiveness. In Part 2, I’ll talk about the processes I like to follow in remote software development teams, but in Part 1, I’ll just stop right here since I want to only cover the tools I like to use in remote teams.
Code Repository Service
I just use GitHub. It works, it’s universal, it’s the “go-to” service for open source projects, and it also works well with Waffle. New services have been popping up recently like GitLab and there’s always BitBucket, but for me, I just go with GitHub.
We all know this is important to catch bugs in production and staging. I don’t think it really matters which one you use. Also, the ones you’ll use will depend heavily on what type of development you do.
For Ruby on Rails development, I’ve used Airbrake, Honeybadger, and AppSignal. My favorite so far has been AppSignal due to it being a great balance between both an exception monitoring tool and a performance monitoring tool.
For Android development, I’ve used Firebase Crash Reporting so far and it does do the job.
I don’t have too much to say on this subject, so I’ll just end this section with a referral code for my AppSignal service 🙂
If you sign up with my referral code, we both get $100 in credits. It’s a win-win 🙂 If you go with their lowest priced plan, which is 250k requests for $19 per month, $100 should last you 5 months, which is a long time. So if you’re looking for an exception monitoring service for Ruby on Rails applications (and they also support Elixir applications now like Phoenix applications), sign up with my referral code below.
The team I was previously on used New Relic for its Ruby on Rails application. For my clients, at least for the ones that are using Ruby on Rails, I just tell them to sign up for AppSignal because it gives them both exception monitoring and basic performance monitoring. But if you’re running a bigger application with lots of traffic, you may need a more heavy duty tool like New Relic.
Code Quality Measurement
Code quality measurement tools aren’t perfect, but they do a good job at several basic things.
First, they’re excellent at catching obvious “oopsies” like code duplication.
Second, they enforce certain code style for your development team. For example, with tools like CodeClimate (https://codeclimate.com), you can sync your account with your GitHub account and set a certain set of standards for your code styles so that when someone on your team makes a pull request with a code style that goes against the conventions that your team has set, it’ll give a warning. Having this warning helps you to standardize a strict code style across your codebase. Some people don’t care about this, but I really like having strict rules on code styles as it makes the codebase look more uniform and easier to read.
Continuous Integration Service
What I like about having a Continuous Integration Service is that when someone makes a pull request, the CI tool will automatically run a test on that branch, and notify you whether the build passed or not.
On large codebases, I sometimes get lazy on running the entire test suite before pushing up a branch and making a pull request. I like having CI tools to help double check that my code that I’m requesting to be merged has its test suite passing.
In Part 2…
This is it for the tools section. In Part 2, I will describe the workflow I like to use in remote teams. It’s a similar flow that we used in the first remote company I’ve worked at, when I hired a freelance developer to work with me, and what I like to use with my clients now.