At CodeGuard, we’ve been able to push a high quality product to market quickly and scale it reliably. Today, we would like to share what happens on a daily basis to make this type of rapid production possible.
Everyone in the office has different schedules and different priorities. While each team member’s daily routine is different and changes from day to day, here’s what a typical day at CodeGuard for one of our employees might look like.
8:00 Wake up, eat, and get ready for work
9:00 Arrive at work, respond to emails, and plan for the day
9:30 Begin testing new selective restore features
10:00 Gather with the rest of the team for our daily scrum meeting
10:15 Modify the selective restore pipeline to address an unhandled case
10:45 Write an article for our weekly blog post
12:00 Review and implement suggestions made by another team member
12:30 Eat lunch
1:00 More testing for the new selective restore features
1:30 Monthly meeting with supervisor
2:00 Final round of testing for the new selective restore features
3:00 Deploy new selective restore features
3:15 Final testing for the new internal performance metrics dashboard
4:00 Deploy new internal dashboard
4:15 Celebrate two successful deploys by ringing our ceremonial CodeGuard gong
4:30 Leave early and enjoy the holiday weekend
Now that you’ve seen what a typical day at CodeGuard looks like, let’s talk about our development process.
Our day begins with our daily morning scrum meeting. For those unfamiliar with Agile development practices a scrum meeting is a way for members of a team to share updates regarding ongoing projects. In our scrum meetings we form a circle and have each member share a high level overview of the tasks they completed yesterday, the tasks they plan to complete today and the tasks that need help with in order to move forward. These meetings generally last 10-15 minutes. The rest of the day involves completing the tasks covered during our morning scrum. Typical tasks include planning for new projects, developing current projects, or testing completed projects.
Planning begins at our conference table with each project participant expressing their own thoughts and concerns about project execution. Because our team is small, there is no designated project leader. Instead, one team member is asked to research the project before hand and help guide the discussion. Team members are encouraged to contribute, and sitting idly is not an option. One of the great things about working for a small company is that we have the freedom to try new things. For example, although our main application is written in Ruby, a few of our most recent projects have been written in Go. This level of flexibility would be hard to find at a larger company.
Once we have a plan, we break the project apart into manageable tasks and begin development. We are lucky enough to have access to top of the line tools for writing software. Each employee has their own workstation consisting of an adjustable height desk, 27 inch retina display, and the latest Macbook Pro. Although each team member is free to choose their own development environment, most of gravitate towards command line tools like vim and tmux. We use GitHub issues to keep track of what is being worked on and by whom.
After a task is completed, it must be submitted for review. Depending on the importance of the task, one or several other team members will test and review changes in our staging environment before submitting the final changes to our production servers. In addition to automated testing, the review process often involves analyzing code for uncaught syntactic and logical errors.
Although we spend most of our time working hard to improve our service, being a CodeGuardian isn’t all work and no play. To keep things lighthearted and fun, we have Happy Hour every Friday afternoon, and we routinely plan outings to nearby events. Our most recent adventure involved participating as extras in a big movie production being filmed in downtown Atlanta.