Working effectively in remote teams – Part 2

This post will be part 2 of the “Working effectively in remote teams” series I’m writing. Read part 1 here where I talk about the tools that I like to use in remote teams. In this part 2, I’ll go over the process that the remote teams I have worked on generally work with.

Again, before we begin, this post will pertain mostly to software development teams as I generally work in software development teams in my professional life. In this post, we’ll cover the workflow that I like to use when I work remotely.

The workflow will revolve around the tools that I suggested in Part 1 of this series, mainly Waffle, GitHub, CodeShip, CodeClimate, and AppSignal. I’ll just list out what each of the tools are for here for those who don’t want to read over Part 1.

  • Waffle – Trello like board that integrates tightly with GitHub Issues
  • GitHub – For code repository and ticket tracking
  • CodeShip – Continuous Integration
  • CodeClimate – For catching obvious red flags in code quality
  • AppSignal – Exception monitoring (feel free to replace this whichever service you prefer)

Overall Process

One thing I should mention is that I’ve never worked in an environment where we had continuous integration continuously developing new fresh code to production as long as the tests passed on CI. I’ve heard about these mystical work places where these systems were put in place, but I’ve never worked in one. So the process that I will be describing here will be specific to one week sprint formats.

  1. All of tickets that needs to be worked on are listed on GitHub Issues page on a daily basis. They are labeled as ready, feature, bugs, maintenance, sprint-name, project-name, and etc. All of these tickets are considered “backlog” and are automatically synced to the Waffle board.
  2. The tickets that need to be worked on that week’s sprint are marked as “ready” and moved to the “ready” column.
  3. Developers grab the tickets on the “ready” column of the Waffle board and move them to the “in progress” column of the Waffle board as we work on them. The priority of the tickets that the developers work on vary, but generally speaking, bugs that affect customers are always priority.
  4. Once the tickets are finished, we make a pull request, link the pull request on the ticket themselves, and move them onto the “code review” column
  5. In the “code review” column, an automatic script that runs on an hourly basis assigns the pull requests to a specific developer on the team (not the developer who created the pull request), and the assigned developer reviews the code. If the reviewer thinks that the code is satisfactory, he/she gives a “thumbs up” and merges the pull requests to the develop branch of our codebase. The reviewer then moves the ticket on the waffle board to “ready to test” column. Also, when the code is merged into the develop branch, the CI tool automatically deploys the code to our staging server. If the code review didn’t pass, the waffle ticket goes back to in progress until the code review passes.
  6. In the “ready to test” column, we have a QA person who manually tests the feature on the staging server. If the QA person decides that the code satisfies the requirements of the ticket, he/she gives a thumbs up, and then moves the ticket to the “ready to deploy” column.
  7. The day before deployment to production, which have always been Fridays for me, we stop all merging of code onto development branch and halt deploying to staging. This means that on Thursday, all active development halts and we focus on fixing bugs that may be on staging and focus on tickets that have not passed QA. Also, if everything looks good, we continue working but we stop merging code to develop branch altogether.
  8. On Fridays, we merge develop branch into master branch, and then deploy to production. If there are any tickets that have not been finished, we cherry pick those out to prevent it from being merged into master and deployed to production.

So that’s pretty much the process.

As you can see, the process is not too different from a normal weekly sprint that many other on-site software development teams may have. The only difference is that the members of the teams I work on are spread throughout the world and we communicate heavily via slack, email, video conferencing calls, and etc.

I’ll wrap up this post and the series here, but I think anyone who read this can conclude that as long as you hire competent and self-managing people, you definitely do not have to have your entire team in one physical location to run a software development team effectively.

If you have a team who works on-site and would give remote work a shot, I think the tools and the processes that I wrote about should help you start experimenting with remote work.

Working effectively in remote teams – Part 1

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:

  • Communication
  • 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 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.

Project Management

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 ( 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:

  • Ready
  • 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.

Exception Monitoring

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.


Performance Monitoring

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 (, 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

This one is obvious right? I like using CodeShip ( for this but you can use whatever you want like self hosted Jenkins.

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.

Udacity Android Developer Nanodegree Review

In 2016, I decided to dive into Android development, mostly because I try to pick up a new technology stack once a year. I utilized Udacity’s Android Developer Nanodegree program to get up to speed on Android development. and this post will be reviewing the program.

Timeline to Completion

Udacity recommends 12 months to complete the program, but this is highly dependent on many factors such as: your current level of programming skills, your experience level in software development, how much free time you have and/or willing to commit, and etc. Personally, I finished the program in a month, and this was while holding down a full time job and putting in around 2 – 3 hours per day after work on weekdays and full day of effort during the weekends. 12 months sounded too long to me to get warmed up in Android development, so I decided to zoom through the course. However, do note that this was only possible because I was already an experienced software engineer who had a few years of experience in an object oriented programming language and was already familiar with many common concepts in software development. Your mileage may vary.

Nanodegree vs Nanodegree Plus

Udacity offers two types of Nanodegree programs, the normal version and the plus version. At the time of this writing, the standard nanodegree program costs $199 per month while the plus version costs $299 per month. The Nanodegree program is essentially a professional certificate of some sorts handed out by Udacity, which is supposed to give you some credibility in the field (whether it does or not is a whole another debate). The way that the Nanodegree Plus program differs (and can justify the higher costs) is that Udacity will guarantee that you will land a job in the field (in this case getting a job as an Android developer) within 6 months of completing the program or they will refund you the tuition costs. For those of you interested in taking a Nanodegree program because you want to switch fields or you want to find a new job, the extra costs might be worth it. I went with the normal Nanodegree program because I was only looking to learn.

Course Quality

I’ve always been super skeptical of MOOCs (Massive Open Online Courses) in general due to the low completion rates of around 15%. A lot of these MOOCs are free and generally when you don’t pay for a class and there isn’t much of a consequence for not completing it, the motivation to do so is pretty low. But after completing the course, I do believe that MOOCs are awesome, given that you’re willing to put your best effort into it. With MOOCs, you really do get out what you put in.

The course’s syllabus is project based in that with each unit, you have to first go through a video course and then complete a project utilizing what you’ve learned in that unit. Applying what you’ve learned is the best way to learn anything so I really enjoyed the project based approach to learning. The course currently has 8 projects, with each project building upon the knowledge that was built upon in the previous project.

The course covered all of the fundamentals of Android development. Things like the difference between RecyclerView and the ListView, how to properly lay out XML views in a performant manner, how to bind views, android activity lifecycle, fragment lifecycles, android performance, debugging, responsive app design utilizing fragments, and etc. The course video content itself guides you through building a simple weather app, one that works on both on a mobile phone and also in responsive view in tablets. In the projects sections, you’ll be given specific projects to work on. In the final project, which is the Capstone project, you’ll be allowed to build whatever you want.

The course also does a good job of limiting the reliance on third party libraries to do the heavy lifting for you. For example, you’re forced to implement your own Content Providers from scratch, which is really painful to do from scratch, but it is the best way to learn how these things work.

Overall, the courses are excellent and you’ll learn a lot about Android development if you put in your best effort.

Course content vs The real world

The main thing I’ve noticed about the course, especially after working on a real world Android project, is that the way apps are built in the real world is very different than how the course teaches you to build apps. After all, the course was developed by Google, so I’m thinking that the way the course teaches you how to build Android apps is the way Google wants you to build apps.

One example is the heavy usage of Fragments in the course. Since I didn’t have any experience (aside from playing around with Android development in college), I thought that heavy usage of Fragments were a norm in the real world. Apparently this isn’t the case and that many developers despise Fragments due to their complex lifecycle and avoid using them at all costs.

Another thing is the heavy usage of third party libraries to speed up development. The course itself does a good job of not relying on third party libraries. For example, the course will write raw SQL queries to cache data into a SQLite database. In the real world however, many apps utilize third party ORMs to make caching easier.

I still think it’s important to know how things work under the hood so that you have a better understanding of how Android development works. But do know that the way apps are built in the course is not how Android development is done in real life.


I think if you’re an experienced software developer, or even a university student studying computer science and who has some programming experience, this Nanodegree program is a great way to learn Android development. The progression of course content is perfect, the projects are interesting and relevant, and if you enroll for the Nanodegree Plus program, you’re guaranteed a job or your money back.

If you do not have any prior programming experience however, I think you should learn to code first. The concepts explained in the course are not beginner-friendly concepts and will be difficult to wrap your head around if you do not have any previous programming experience. If you still want to learn Android development however and want to do some prep work prior to this course, Udacity does have a Android Basics program and even a Java Programming course. I haven’t taken these courses yet, but based on the quality of the courses in the Android Developer Nanodegree program, I’m pretty confident that the courses are high in quality.

How to Create a Blog Course – Simple Programmer

One of the inspirations for creating this blog was John Sonmez of

I’ve been randomly watching John Sonmez’s videos on YouTube every now and then and have always enjoyed his videos. When I was stopping by Maryland for a month or two, I realized I had his book Soft Skills in my bookshelf and due to sheer boredom one day, cracked it open and began reading it.

One section in the book that was intriguing was on how to market yourself as a software developer and how blogging was one of the best ways to do this. I’ve always thought that blogging was a waste of time and found that I had difficulty maintaining any sort of consistency with it. One of the things the he mentioned was that you have to take a long term view when it comes to blogging. It’s actually hard to find an unsuccessful blog that’s been consistently maintained for 4 – 5 years. I thought he had a valid point so…

I signed up for John Sonmez’s “How to Create a Blog” course mostly to give myself mandatory homework to do and keep myself accountable.  The course is emailed to your inbox with tasks to complete and is an easy way to keep track and be accountable throughout the blog creation process. It gives tips on what to write about, which blog platforms to choose (hint: WordPress), how to host your blog, what themes to choose, how to niche yourself, and etc. Well, this blog is the result of the course and I’ll be writing in it twice a week in 2017. The topics I’ll be focusing on are 1) Android development and 2) Remote/Nomadic software development.

If you’re interested, the link to the course is Off to filling this blog with at least 100 posts by the end of 2017!