As a developer at an agency focusing on Ruby on Rails projects, no two work days are exactly the same. Iām working with a few different applications at any given time, and depending on the day, I might spend parts of my day meeting face-to-face with clients or writing up something for our blog...like this article. But if youāre curious what itās really like to work as a Rails developer at an agency, read on for an overview of my typical day.
One of the great things about working at Planet Argon is that my typical workday is very flexible. As with many other dog owners, much of my routine revolves around my furry little friend, Chelsea, and working at Planet Argon makes taking care of her super convenient.
8-9 AM
Most days consist of Chelsea and I walking the mile or so to the office. Every day for me starts with coffee, so if I'm the first one in the studio then I'll start brewing a carafe, otherwise I'll grab a mug and head to my desk.
First order of business is to check my email and Slack to see if any pressing items need immediate attention. If not, I take a look at our ForecastApp, which is our tool to plan out how many hours should be spent on what clients or projects. From there, I switch to JIRA and look at my dashboard and Kanban boards to figure out what tickets should be worked on. I'll typically take this time to do some JIRA grooming as well: check for tickets that have been 'In Review' for a while, find tickets that need estimates or updates, that sort of thing.
One of the biggest challenges here is trying to minimize context switching. As an agency developer, I have to maintain knowledge of several different client projects, typically working on anywhere between 1-3 different codebases per week and 4-6 codebases per month. Timeboxing my calendar and prioritizing tickets where I can work on a singular project for an extended period before switching to another is vital to being efficient.
9:30 AM, Monday
If it's a Monday, once I have a good idea of what tickets I have in my queue, I'll begin prepping for Meet the Week. Meet the Week is like a longer, more detailed stand-up. Everyone in the company attends and we start by having everybody talk about four things:
Personal Highlight from the past week. This can be a nice meal, a fun outing with friends, a hike, whatever you remember most from your personal life that week!
Professional Highlight from the past week. I often use a handy little tool called git-standup to look back on what commits I made the previous week.
Lessons Learned which can be professional or personal. This is also referred to as 'Risks Taken', as it's not a critique session but more a way to share with others something risky or difficult we attempted, didn't quite hit the mark, and what we learned from it. It was difficult to get used to at first but I really enjoy it now since it's a great way to learn from one another.
Kudos is the last part. This is our chance to shine a spotlight on co-workers for helping out or doing something really well.
Meet the Week then goes into more nitty-gritty details, like sales updates, marketing updates, project launches for the week, and out of office and event reminders.
9:30 AM, Tuesday-Friday
On non-Monday mornings, we have a quick developer stand-up. We'll start a Slack call if people are working remotely, and we briefly discuss what we worked on the previous day and what we plan to work on during the coming day. We'll also bring up any blockers and solicit help if need be. These typically last between 5-10 minutes, shorter if people are out of the office, and longer if weāre in the midst of a large project or have a deadline coming up.
9:45 AM - 11:30 AM
After the Meet the Week or stand-up, my regular workday begins.
So on a typical day, coding starts after I settle in back at my desk. Typically my work can be broken down into two general categories: bug fixes and production improvements. Bug fixes tend to involve lots of debugging, looking over logs, running tests, and writing specs. They can also involve quite a bit of client interaction, especially in situations that are hard to replicate, so calls with clients are not unusual.
Production improvements typically involve a client (or co-worker) requesting features to be added or modified on a project. This type of work tends to involve more time spent whiteboarding and researching solutions than actual coding. The old adage āMeasure twice, cut onceā is as relevant for software development as it is for carpentry.
For most significant production improvements or bug fixes, I create pull requests to merge them into the production or master branch. These pull requests typically take up a small amount of a regular workday but are essential to making sure only quality code is deployed to clientsā servers. Communication with clients via JIRA tickets is similar in that it typically takes up a relatively small amount of my regular day but is incredibly important in making sure what Iām doing is actually reflective of the clientās wants and needs. And of course, the actual process of deploying changes does take (hopefully) a minimal amount of time but does factor into how my day progresses.
Our studio has an open concept with soft music that one of us selects playing in the background. We also have two conference rooms for meetings, calls, or if you need a change of scenery or more silence than headphones can provide. I tend to stay at my desk most of the time but will occasionally move to one of our standing desks if I'm feeling stiff or am having trouble concentrating.
Lunchtime
I normally take lunch between 11-12, where I can use our kitchen to heat up whatever I brought or head to one of the nearby restaurants. Most of the time Iāll eat at one of our communal tables, where I'll either chat with whoever else is eating, browse my phone, or read a book. I try to avoid eating at my desk unless I'm really swamped. I've found that taking real breaks and stepping away entirely from coding and my desk ends in better results than trying to push my way through problems while eating.
12:30-4
I'll typically have a mini self-check-in, which is basically an expedited version of my typical morning. Iāll see how far I've gotten on tickets I lined up in the morning, compare that to how many hours my ForecastApp says I have on that project, and re-prioritize my tickets as need be. Then it's back to coding!
4-5:30 PM
Chelsea and I typically leave the studio between 4-5:30, depending on when I got in and how long of a lunch I took. It's very rare to stay later than 6 and is actively discouraged. We're really fortunate that we have a team that genuinely values a healthy work/life balance and believes well-rested programmers are more effective than burned out programmers with lots of hours under their belt.
Flexible work schedule
Occasionally, when my schedule is clear of meetings, Iāll take extended breaks during the day and finish up my work later at night. I've come to notice that some days I work better later at night. Having the flexibility to work at slightly varied hours is a huge win in my book as it lets me bill time only when I know I'm working at my fullest capacity.
Sometimes a change of scenery can spur exactly the kind of mental boost needed to solve a particularly difficult problem and leaving the studio early and heading home (or starting at home and coming in later in the day) can do exactly that. Having the option to work from home also can help relieve stress when things are occurring at home that might be distracting otherwise: repairmen and deliveries being perfect examples.
Weekends
Weekends are definitely meant for personal time. If work is required on a Saturday or Sunday, it's likely something serious and urgent like a client's site completely crashing. I originally would look at tickets and do some planning work on Sundays when I first started but I've come to agree with the idea that an adamant work/life balance really does make me a better, more efficient worker.
Meetings, team building, and outings
We have a bi-weekly developer's meeting called a D10, where for an hour the developers all gather to discuss issues that have arisen. We all are able to contribute to the agenda anytime between meetings. Topics vary greatly, sometimes being very technical or coding specific, or more esoteric with things like āDo you feel like we are being true to our values?ā We make to-do items and assign them to specific people when an issue warrants action.
We also typically have quarterly outings on the calendar, where the company goes and does something fun together, like curling or rolling skating! We also tend to have fun meals (like Taco Tuesday) and social gatherings (like a pumpkin carving) at least once a month, which is often a morale booster and a great way to socialize with coworkers.
In Summary
Overall, in a typical work week, I would estimate spending 80% of my time coding, 5% in meetings, and 15% on administrative tasks, like JIRA, email, and Slack. I think this split in time working is a major strength for the developers at Planet Argon. Rarely does my coding feel stifled by meetings or administrative functions, but I also feel like there are plenty of avenues for me to raise issues when need be. I think the typical day at Planet Argon shows it's a place that conducive to personal and professional growth.