Embrace Chaos. Day 1 in Unfamiliar Code.

Note: This post was written before I was laid off by my employer but I still thought it was valuable to share. I plan on asking all of these questions when I begin my new job in the next few weeks/months. If you happen to know of anyone who is hiring Ruby developers, ideally in a SOA environment, please let me know. ;)

Now then, back to your regularly scheduled blog post.

Don’t worry, it’s a pretty straight forward codebase.

For quite some time, I have been pairing for an hour every Wednesday with fellow LivingSocialite Dave Woodall. He has recently changed careers from graphic design to software development. The speed of his transition has been very impressive. I look forward to our weekly pairing sessions. He has taught me a great deal about myself in the process.

At a recent pairing session, Dave asked me the question, “What do you do on day 1 of working in an unfamiliar codebase?”. This fairly simple question forced me to think about how I work with an unfamiliar codebase and what kinds of questions I should be asking.

Unbeknownst to me, Dave asked fellow coworker, Tom Copeland, the same question. I was very excited to see how our answers compared. Using both of our answers, I compiled a list of questions that we all could ask when diving into an unfamiliar codebase.

Many of these questions are geared towards developers entering a new workplace, but these can also be asked when moving to a new project. This list is by no means exhaustive and I am always happy to hear improvements and tweaks.

Codebase

• How do I setup my development environment? Can I do it in one step?
• Am I locked in to a particular IDE? If so then why?
• How do I run the tests? Can I do it in one step? How’s your test coverage?
• Are you using the most up-to-date versions of runtimes and libraries? If not then why?
• How do you ensure runtimes and libraries are kept up to date? Is this done regularly or only for bugfixes or security concerns.
• How confident are you in your application’s security? Mind if I put that confidence to the test? In production?
• How confident are you in your application’s ability to handle large traffic spikes? Can I put that to the test? In production?

Operational

• What is the average throughput of this application? Is it public facing? Is the business directly losing money in the event of downtime?
• Does this application have a defined SLA? Who is responsible for ensuring it is met? Are SLA violations treated the same as bugs?
• What is the expected turnaround time for a post-mortem in the event of an outage or other operational issues? How do we ensure that teams follow up on action-items?

Process

• Which bug tracker are you using? How are projects separated? Do I have to track time? Does your bug tracker have commit/diff integration?
• Is there a CONTRIBUTING.md (or similar) document somewhere that includes guidelines for submissions?
• Where does services, project, process documentation live? How is it organized? How is it kept up to date?
• Do I have to submit a Pull Request before deploying a change? Who handles code review? Is that when code review takes place or is that just basic QA?
• What is the average turnaround time for code reviews? If mine sits in the queue for too long who do I talk to about getting it prioritized?

Databases

• Which databases do you use? What version? Are they kept up to date?
• How do I make database changes?
• Is there a DBA who can help me with slow queries or schema changes?

Tooling and Infrastructure

• Do you use a tool like Code Climate? How’s your GPA?
• Where do I see the status of our build? How do I get notified of failing builds?
• Where can I view automatically generated documentation? Is this kept up to date?

Deployment

• How do I deploy? Can we do it in one step?
• Can I deploy right now? If not, why?
• If a deploy fails to whom do I escalate? Are they alerted?

Monitoring and Alerting

• How do I know if I pushed out a bad deploy? Where can I view application errors?
• How do I know if my deploy dramatically slowed something down?
• How can I view realtime stats about the application? How can I add tracking for custom stats?
• Where do I view aggregated logs? If the answer is “nowhere” then why?
• Is there an on-call rotation? What happens if something breaks at 3AM on Christmas Day?

After Dave & I discussed this list, I came to realize that its usefulness went beyond our pairing sessions, and thankfully I have finally put them into writing. Many of these questions were things I asked when entering new projects, but rarely wrote down. I hope inquiries like this would help organizations think critically about their software stack, processes, and tools.

We should regularly ask ourselves questions like these in order to improve and ensure our organization doesn’t become stagnant. Software processes are changing all the time and occasional reevaluation is a very health activity.

What questions would you ask on day 1? What questions would you ask after 30 days? What about 90 days?

Special thanks to Dave Woodall and Tom Copeland for inspiring this post. Also thanks to Tony Pitale, Matt Rogers, Jason Garber, and Colin Dean for reviewing + proof-reading.