By Liz Denhup, software engineer at Ontra
For me, one of the most difficult—but rewarding—parts of onboarding into a new tech company is familiarizing myself with the codebase. It’s both exciting and daunting to view the concrete intellectual achievements of my new teammates while learning about a new business domain.
Here’s a fun fact: before I was a programmer, I was a sociology student. Though I defected from the social sciences to pursue a career in technology, I think many of the intellectual habits that prove helpful for sociological inquiry also apply to large-scale collective human endeavors like software development projects. Over the past few years, learning a new codebase as a remote developer is a problem I have approached from both technical and sociological perspectives. In my experience, combining technical and sociological investigation to understand my company’s codebase and business domain has helped me contribute code to projects more quickly and with greater confidence. Here, I’d love to share some strategies I’ve used successfully for onboarding remotely to new Rails projects, especially here at Ontra.
Technical strategies for successful onboarding while working remotely
At Ontra, we have an onboarding curriculum that aims to familiarize every developer with the business domain (legal technology + contract automation). In addition to going through the onboarding curriculum and asking questions, I like to use the following technical strategies to help me onboard effectively:
Pair programming for remote work
At our company, we’re trialing out Tuple for pair programming. I have used Tuple at past jobs and loved it. Pair programming is one of the few activities that work better when both parties are remote, especially with a tool like Tuple. Both parties can stay engaged and see clearly while pairing, and it’s a great way for teammates to bond and share knowledge with new hires.
Create entity-relationship diagrams (ERD) by hand or with a Rails gem-like rails-erd
This particular technique works best for monolithic Rails projects. However, in the past, when I have worked on microservices, I have seen similar (but different) diagramming techniques used to great effect. An entity-relationship diagram allows me to quickly see how various models and classes connect without tabbing through many files. When using a tool like rails-erd, generating diagrams is easy. If you’re set up with a Rails project, you can follow the directions in the rails-erd README here to generate hierarchical diagrams of your backend models in seconds.
Code spelunking for code execution and context
Code spelunking, broadly speaking, is a set of strategies that one can apply to understand a new codebase. The developer can use debugger statements, logging, grep statements, and other low-level methods for understanding code execution and context. The linked article gives an overview of the topic and describes strategies for drawing meaning from a codebase.
I like to take a fairly unstructured approach to code spelunking when onboarding to a new job. On a day when I have time to fill that is not long enough to finish a project (e.g., thirty minutes before the workday ends or the 15 minutes in between meetings), I choose some topic related to the backend that I want to understand better. I go to the Rails model, then I look at the associations between that model and the other models, and then allow myself to go down the wormhole (for lack of a better word) of reading the codebase carefully. Over time, these small sojourns can add up to a clear and ever-growing view of the codebase.
How thinking sociologically can help developers onboard remotely
I like to use some of the skills I learned from studying the social sciences to ramp up quickly and meet my quarterly software engineer goals. These techniques are of general interest and do not require a sociology background.
First, a “what is sociology” primer for STEM readers. Sociology is the study of collective human behavior. Sociologists study things like how people organize themselves or interaction patterns between individuals and entities. You might be asking yourself, why would sociological thinking help me better understand my company’s codebase?
I think sociological thinking can help remote developers in a few ways:
Good software models the domain it seeks to describe
My first software engineering mentor told me that good software closely models the domain it seeks to describe. Sometimes this concept is called “domain-driven design” (DDD). The relationships in our codebase describe real relationships between entities in the real world. Understanding the business domain in which we work can help us make sure the features we build make sense for our users. In past tech roles, I worked in industries or domains that I was more familiar with; at Ontra, I am learning about an industry that I know very little about. When I started looking at this codebase, I had to first understand why Ontra exists and the ecosystem within which it operates.
As a new hire without a background in legal technology, I did not understand why companies might need to manage thousands of non-disclosure agreements at a time or why contract automation might be desirable. Taking the time to understand more about the private equity landscape and learn some basic theory about contracts means I can better understand the business problems I need to automate as a developer here at Ontra.
Participant observation for greater understanding
In certain subfields of sociology, it is expected and encouraged that you might be a full participant in whatever you’re studying. I think applying this attitude to coding can be really helpful. When a colleague and I needed to digitize client matter IDs in our database for LEDES files, we had many questions. Right at the top of the list were “What is a client matter ID?” and “What is a LEDES file?” (A client matter ID is an identifier that law firms use internally to track projects for invoicing purposes; a LEDES file is a legal billing file that conforms to an industry-standard format).
To help get this project rolling, I asked to observe my colleague on the Finance team as she generated invoices for that month. She was very gracious in answering our questions, and the time spent on participant observation helped us understand the functional requirements and the time-money value of our work.
Understanding and rectifying WFH communication foibles
For me, the biggest challenge in coding has often been understanding functional requirements as they are communicated to me by a product manager or stakeholder. One thing I enjoyed studying as a sociology student that helps me in this domain is conversation analysis. Conversations (in any culture) have a lot of implicit rules and take on certain patterns. In a remote-first context, the cost of communication is higher than for in-person work. The feedback loop between asking a question and getting an answer can be longer when posing questions by Slack, and onboarding developers (rightfully) have lots of questions!
Being mindful of how asynchronous communication can create feedback loops or communication bottlenecks is especially important to developers since software projects resemble the topologies of the teams who work on them. This theory is called Conway’s Law.
A few final thoughts on effective onboarding
Though by no means an exhaustive list, I hope this blog post has provided you with some strategies for engaging with remote work more effectively, from both a technological and sociological perspective. I am confident that as hybrid workplaces become more common, we will all develop effective ways across society of working together irrespective of our physical location.
Here at Ontra, we leverage our technological skills while looking towards other disciplines like sociology for lessons on how to structure information and communication channels to support onboarding new remote developers and communication in a rapidly-scaling environment.
