Why I Love Doximity Engineering

May 23, 2022 | Edward Anderson

I joined Doximity's Engineering team more than 4 years ago and am continually super happy and proud to be a Doxer. I’ve been working on our news products as a Senior and then Staff level engineer, mostly in our web stack built around Ruby on Rails. Today I want to share a few things that have really made Doximity shine for me.

Leadership gets how to run a tech company well and actually pulls it off

There’s a magical combination of knowing the right things to do, having adequate resources, and successfully executing on the vision. In practice, it’s difficult and uncommon to pull off.

Our leaders have built a culture of…

Putting people and teams on things that matter

The larger an engineering team grows, the more disruptive its shared problems become. Having clear ownership is crucial. Otherwise, these problems persist due to them being everyone’s problem and no one’s responsibility. For example:

  • Flaky tests causing intermittent build failures in the main branch of our largest codebase are tracked and disabled by our test automation team, who then delegates the fix to whichever team owns the code. I have massive appreciation for them being on point for us, so these things don’t block everyone from shipping. They’ve also made massive progress in making our largest Rails app’s test suite fast, bringing build time in CI from an hour down to 15 minutes. 💛
  • Another team has done an amazing transformation of our development environment, enabling us to continue editing and browsing locally but moving our growing set of Docker containers for development into the cloud, freeing up resources on our laptops and making support and consistency stronger.
  • Finally, we have a team dedicated to providing our infrastructure as a platform, like Heroku, so we can spin up new services when that’s the right choice, rather than lump a service into an existing app just because of the effort required to set up new infrastructure.

Seamless deployments

At Doximity, we often deploy code to production more than 70 times per day. Thanks to the platform team, a smooth deployment to production is as easy as doxbot ship <app> after merging the GitHub pull request. We have automated and manual quality checks in place to prevent problems, but ultimately, there’s very little that gets in the way of Getting Stuff Done and shipping value to our users.

Ruby code that is nice to work in

I've had exposure to a great number of Ruby projects, and perhaps like you, I’ve seen a lot of terrible Ruby code. This can arise from lack of technical wisdom, business necessity, or just a constant push to pump out new features without allowing time for needed maintenance.

How do we keep up code quality? Doximity works on a quarterly cadence, where every quarter each team sets and works toward measurable goals. We dedicate 70% of our time each quarter pushing toward these stretch goals. The other 30% is reserved for:

  • addressing technical debt,
  • larger engineering-driven projects,
  • fixing bugs,
  • speed improvements,
  • documentation,
  • education, and
  • other work that isn't goal-impacting.

With this structure, we're able to both focus on business impact and maintain our code so that we can keep shipping at a good pace and stay happy as engineers.

Tech proposals

Coordinating and building consensus around significant architectural changes and new features can be challenging, especially on a distributed team. To accomplish this, after we vet and solidify our initial ideas with peers, we write up a proposal in a Google Doc to share and get feedback from a wider audience. Writing it down really helps you think it out and come up with a fully-baked solution that people can take time to think about asynchronously. There are a lot of smart people here, and it's super helpful getting their feedback. If there are still disagreements after discussion, to keep us from getting stuck, the team that owns the proposal makes the call since they have the most context and ultimately have to live with the decision.

Using technical proposal documents allows us to work asynchronously and have a better culture where you don't need to follow the Slack (group chat) conversations all day or risk being left out of an important decision.

Huge learning and growth opportunities and support

Doximity values and encourages our growth and professional development as engineers. This includes attending conferences, participating in training, and providing any other resources to help further your career.

My teammate who joined last year was floored when his manager told him, “My job is to help you grow and be prepared for your next job.” I hope his “next job” will be a promotion within Doximity, but I absolutely love the attitude our leaders have toward helping us be the best we can be.

When I approached my manager during my regular 1 on 1 to let him know I felt ready for a promotion from Senior to Staff Engineer, he replied, “Great! These are the larger problems we're dealing with that need to be addressed… Which of these would you be most interested to help with?” We reviewed the expectations for the Staff Software Engineer role (which are superbly documented for each role) and created a plan for me to bridge the gap. He provided me with excellent resources and mentorship through the entire process that helped me truly grow into and be ready to succeed in the role.

Bad Joke Thursday

Okay, lame puns may not be your thing (though they are definitely mine). Bad Joke Thursday (intentionally setting the bar low) is a thing I started where now over 80 of us gather each week to read and share our favorite jokes.

This isn't (just) about jokes though. It's about everyone's ability to have a real impact on our culture and be the real you—one of our core values. This is simply one example of many things that have come from grassroots efforts to make Doximity a place that we love to work.

Remote culture & offsites

A great remote work experience isn't easy to pull off, but Doximity does it well. Some highlights not mentioned above include:

  • an organized, smooth, and supportive onboarding experience,
  • virtual team social hours throughout the quarter,
  • remote-first mentality when collaborating with people at HQ,
  • healthy Slack etiquette, including use of threads to minimize disruption and encouragement to be productive by snoozing notifications,
  • and most importantly, trust: we're expected to communicate well and deliver results, and beyond that, you have the flexibility to work in a way that's best for you.

This is huge: Every quarter, we get the teams together in person at some destination for an offsite. These events are a great blend of work—recognizing how we were successful and planning for the next quarter—and play! As a fully remote engineering team, spending this quality time together with co-workers and getting to know each other does wonders for feeling connected with the team and building great relationships. It's hard to beat the flexibility in working from home, but nothing virtual can truly replace the value that comes from getting together, especially the ideas and solutions that come from mixing among people you don't typically work with.

This goes hand in hand with why…

Our people are great to work with

It’s easy to say people are great, but our low attrition rate speaks for us, with over 25% of Doxers having a tenure of 4+ years, even having grown our staff roughly 33% each of those years.

A huge part of what makes Doximity enjoyable is the people—friendly, welcoming, helpful, and kind. It's not okay to be a jerk here. Doxers value Straight Talk—we say what we think (in a kind way), and every voice is heard and respected. This has been foundational in keeping out drama and office politics.


If these are things that speak to you too, please come join us!

Learn more at workat.doximity.com or reach out to me if you have questions!


Be sure to follow @doximity_tech if you'd like to be notified about new blog posts.