<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Onboarding on rjrowland</title><link>https://rjrowland.com/tags/onboarding/</link><description>Recent content in Onboarding on rjrowland</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Wed, 29 Jul 2026 09:00:00 -0500</lastBuildDate><atom:link href="https://rjrowland.com/tags/onboarding/index.xml" rel="self" type="application/rss+xml"/><item><title>How to Learn a Codebase With No Docs</title><link>https://rjrowland.com/posts/engineering-practices-learning-a-codebase/</link><pubDate>Wed, 29 Jul 2026 09:00:00 -0500</pubDate><guid>https://rjrowland.com/posts/engineering-practices-learning-a-codebase/</guid><description>&lt;p&gt;The hardest case: no tests, no architecture decision records, no diagrams. The tactics shift from consuming documentation to producing it as a byproduct of exploring.&lt;/p&gt;
&lt;p&gt;Here&amp;rsquo;s what that actually looks like, walked through on one example: you&amp;rsquo;ve just joined a team maintaining &lt;strong&gt;Ledger&lt;/strong&gt;, an internal core-banking service written in Go. Nobody&amp;rsquo;s written a README beyond &lt;code&gt;make dev&lt;/code&gt;. You have a week before you&amp;rsquo;re expected to ship anything.&lt;/p&gt;
&lt;h2 id="start-outside-the-code"&gt;Start outside the code&lt;/h2&gt;
&lt;p&gt;Use the product as a user before you read a line of source. Check the error monitoring dashboards, Sentry, Datadog, early: they show where the system actually breaks, which tells you more than reading happy-path code ever will. The production error log is an honest account of what the system struggles with. The codebase only shows you what the engineers thought would happen.&lt;/p&gt;</description></item></channel></rss>