by Jake Worth on May 18, 2017

What is a typical day like for you at Hashrocket?

This is a question people ask. If you've never worked with a consultancy, what happens on the inside can be mysterious. We're consultants... does that mean we write code? We're developers... does that mean we only take projects in languages and frameworks we know very well? And perhaps most importantly: do we have a ping-pong table?

Today I aim to answer some of these questions the best way I can, by describing my typical day as a developer at Hashrocket in Chicago. I hope this gives insight into consulting, and how one person can find their place in the industry.

My typical day flows through team standup, client standups, development, lunch, development again, and individual contributions, not always in that order.

At Hashrocket, a vital part of our process is standing up together every day, something I explored in a previous post.

Our internal standup practice is one of my favorite things about Hashrocket. It helps us understand goals, coordinate effort on problem areas, share problems and improvements, and coalesce as a team. We have several remote team members, making this practice even more important.

On our client standups, communication is everything. We work to quickly help our clients develop their ideas, think about priorities, and explore hard technical decisions in the path to a viable product.

After standups, we get to code.

During this part of the day, it's me and often a pair (check out great blog posts on that subject here and here) working through technical challenges to deliver value to our clients. We put on some music (or not), sit or stand at our desks, and attack the fun and bedeviling work of programming.

In my time at Hashrocket, I've written Ruby, PHP, Go, Elixir, and a lot of JavaScript. One of the perks of consulting is that we see tons of languages, frameworks, databases, code styles, and design decisions. It's an endless walk through the many planes of web development.

How do I react when thrown into a project with a language or framework I'm still learning? We try to prevent that, something I attempted to explain in this Quora post. But of course, it happens often. That's one of the joys of developing at any job: how can I achieve expertise as fast as possible with this tool? What must I know? Are there any rites of passage that I can skip for the sake of expediency? When I'm lacking specific familiarity with a tool, I rely on general expertise in web development, problem-solving, and accessible coworkers.

I try to stay heads-down for as long as I can, breaking up work by talking to my coworkers about tools, design, client interactions, hiring, and current events.

Because we follow something resembling an Agile workflow, we have assigned stories that correspond to features or issues with a project. We approach these one by one, in an order prioritized by the client, requesting clarification, exploring edge cases, and finally, writing tests and implementation.

Most of us eat lunch as a team in our office, with groceries provided by Hashrocket. Conversations continue, mixed with board games, walks around the neighborhood, Halo, and reading. Visiting clients and hiring candidates can participate in the experience. At the end of the hour, we transition quickly back to work, since nobody has left the building.

After lunch, it's back to development. The afternoon block of work is longer than the morning block, and is where I feel the most productive. Because we follow an Agile workflow, we try to keep our commits small and atomic and deliver often to a staging server for client acceptance. The afternoon is a great time to kick off a round of deployments and feature delivery.

These blocks of time are free of mandatory meetings or distractions. Meetings and distractions do happen, but they are optional and always take a back seat to work.

When 5 PM comes, it's time to stop. This is not a marketing ploy, but an ingrained part of our culture. We try to keep people rested to prevent burnout and deliver the best possible work.

Hashrocket has a flat hierarchy; we are all peers and answer directly to the CEO. This means that if you're interested in taking on a responsibility to help the business, you just start doing it. There are a number of important internal projects that require extra work from everybody. Also, a consultancy's product is, in some way, the consultants, and we all try in our own ways to develop our personal and company standing in the community during downtime throughout the day.

Here are a few of the ways we make individual contributions:

• Writing blog posts
• Responding to job applicants
• Maintaining open source projects
• Maintaining our various web properties including https://hashrocket.com
• Building side projects
• Learning
• Organizing Meetups (Vim Chicago, Chicago Elixir, and React Native Jax, to name a few)
• Writing TILs
• Teaching
• Helping run the office and communicating with the rest of our team

Fridays at Hashrocket are special, because we spend the afternoon on 'Open Source Time'. This is a company-sponsored opportunity to dive more deeply into the individual contributions listed above, and show the rest of our team the things we've been working on. It's something we cherish, and I hope to cover it more deeply in a future post.

That's it! Eight hours talking, listening, thinking, and typing. It can definitely push your brain to the limit, but goes by quickly. I hope this gives some insight into Hashrocket, and what it's like to work with us.

^{Photo Credit: Jonathan Chen, https://unsplash.com/photos/0G8M3LVT5Ds. Accessed 12 May 2017.}