As a developer at TaxJar, each day provides an interesting mix of new challenges and problems to solve. We’re a fast growing technology company processing millions of eCommerce transactions and calculations every month. Our team works across the United States from coast to coast in 4 different timezones.
In this post, I’ll share how we collaborate on a codebase to provide sales tax calculations, reporting, and filing for over 7,000 paying customers. Along the way, you’ll get a glimpse into life at TaxJar from a developer’s point of view.
A bit of background: I’ve been working remotely for over 5 years with a variety of distributed companies, including my own, and I haven’t seen projects executed better anywhere else than at TaxJar. We’re always evaluating internal processes and tools to get things done and ship faster. As the team grows, we’re figuring out what works and what doesn’t, especially for meetings and keeping everyone up to speed on changes. These kinds of things are important to get right as a distributed team, so we can spend more time writing code and less time collecting requirements.
Luckily, writing code is something we get to do every single day in a language we love: Ruby.
Ruby powers every aspect of TaxJar, from our sales tax reporting application on Rails to our SmartCalcs API built with Grape. It’s an elegant language that’s easy to learn, perfect for beginners and experts alike. The community is inclusive and diverse. It attracts developers who prefer writing simple, well-tested solutions to complex problems. For these reasons and more, we’re happy to invest in Ruby and its ecosystem. Last year we sponsored RubyConf and participated in Ruby Rampage. One of our newest developers actually helps co-organize Ruby Rampage (formerly Rails Rumble). We’re a proud customer of Heroku, Sidekiq, and many other Ruby-centric products and services. In the future we’re planning to release more gems covering some of our non-proprietary work, such as persisted_cache.
Now let’s jump into a typical day working as a developer at TaxJar.
First things first, we have a daily standup in the morning to discuss what was worked on yesterday and what we plan to work on today. Usually it lasts for about 15 minutes unless it’s a Monday. On Mondays, we plan for the week ahead with fortnightly sprints to make sure we’re staying on top of quarterly goals and priorities. Standups are performed over Zoom to share our Scrum board and quickly get answers for any blockers. It’s also great for face-to-face interaction with your coworkers when you work from home all day. Not only does it keep you personally accountable to share something new every day, it’s motivating to hear about everything else getting done.
For larger features and projects, we’ll often jump back on Zoom for quick 5-10 minute chats in smaller teams to discuss things in more detail and solidify requirements. I make sure they happen directly after standup or in the morning for a couple of reasons. Since we’re distributed throughout the entire country in various timezones, people are out and about for lunch throughout the day. Working from the West coast, there’s usually more availability in the morning. Secondly, it allows me to focus on other tasks later in the day without interruptions.
Typically these meetings are impromptu and mentioned during standup. Right now I’m part of a small team to work on our AutoFile experience. I also work independently on several platform integrations and manage our API clients. As a new developer you’d start off on smaller tasks, join a larger team project, and work toward managing your own projects.
Most communication is asynchronous at TaxJar. We use Flowdock for everything besides standups and the weekly team meeting on Fridays. During the day I’ll cruise around the flows to see what’s going on. Oftentimes I’ll get pinged for questions or ask some of my own in private one-on-one conversations. What I love most about Flowdock is being able to see all of our commits and pull requests next to the chat in a single flow/channel:
I can also see when tests are passing for a given branch, deploys made to our staging or production servers, and more. Flowdock stores all of our threaded conversations, questions, and links for quick review later. We’ve tried other chat applications, but Flowdock is still the best for seeing everything at a glance for each team in the company.
Everyone at TaxJar provides hands-on support. No exceptions. Working with customers, understanding their pain points, and getting their feedback firsthand is crucial to building a great business. As a developer, you’ll typically answer questions around the products and integrations you touch most often. Every other week you’ll be assigned a success hour to tackle support questions outside of your usual domains. This is the perfect time to use our customer success flow to ask the team questions about the various parts of TaxJar you’re not familiar with yet.
On a typical day, I’ll answer a variety of questions about SmartCalcs, Reports, and our Magento integrations. Customer feedback is recorded in Trello and issues are addressed with the team as they come up.
Working remotely gives you complete control over your working environment so you don’t have to worry about open offices, unexpected interruptions, and other nonsense. It’s much easier to get into the zone.
Of course, one prerequisite for getting in the zone is owning a great pair of headphones. We were all given noise-canceling headphones at our last Jarfest in Austin. It’s been a productivity boon for many people on the team, but unfortunately there’s been some downsides too:
In general, individual tasks should take one day of work or less. They’re divvied up among the people on your team at the beginning of a sprint.
Once a task from the Scrum board is started, it’s moved to an “In Progress” column and commits are pushed to a new branch off master. For version control we use Bitbucket to host our private repos and GitHub for our open source repos. RSpec and Capybara are used for writing specs, while Codeship provides continuous integration as you push your work up to Bitbucket.
After finishing a task with passing specs, you’ll move the task to a “QA” column and open a pull request with an outline of your work. Screenshots are recommended for visual changes. You’ll then assign your teammates to review it. For larger projects, you’ll want to deploy your code to staging for additional click-testing.
In the meantime, it’s a good idea to make a quick screencast using ScreenFlow or QuickTime explaining what you’ve accomplished. We recently started a demo flow to showcase weekly demos and get feedback from the team.
After a couple people on the team approve your pull request, it’s merged into master and the task is moved to the “Pending Release” column on the Scrum board. It’s then deployed to production on Heroku. Once deployed, the task is moved to the “Done” column to be archived after the next sprint is started.
As mentioned earlier, our sprints mainly focus on quarterly objectives around Reports, AutoFile, and SmartCalcs. However, there are a wide variety of other projects to help out with when time permits:
- OSS Initiatives
- Platform Integrations
- API Clients
- Developer Portal
- Marketing Sites & Tools
- Remote Tooling
We encourage everyone on the team to occasionally work on different projects to switch things up and try out new ideas. Working on a small team allows you to wear many different hats and make a huge impact. If you like writing, we have 3 different blogs with plenty of traffic. If you want to experiment with a new language, we probably need an API client for it. If you’re interested in learning more about AWS or scaling apps, we certainly need your help in the DevOps department. Near the end of the day, I’ll spend some time on one of my side projects like this blog post you’re reading right now.
That’s a high level overview of the processes and tools we use to get work done at TaxJar. If you enjoy writing Ruby and prefer getting things done with an experienced team, consider joining TaxJar!