If a PR has solid tests, good observability, and the logic holds, do you need to read every line? Jess says no, and she makes a solid case for it.
In Episode 8 of Making Software, I talked to Jess Temporal, a Senior Developer Advocate with a background in biomedical informatics and data science. She's been helping people understand complex things since before she knew that was a job title.
Her "nontraditional" path was DevRel training the whole time. Biomedical informatics sat between hard Computer Science and healthcare, which meant explaining things to two completely different audiences and she didn't realize that was advocacy until years later.
She won't teach what she hasn't built. Her creative process works backwards from understanding: build it, connect the pieces, then shape it into a story worth telling.
"Is my data safe?" is a valid security question. A journalist friend building with AI didn't know the technical words for her concerns. Jess's take: describe the concern to your agent and let it surface the vocabulary.
The My Yarn Stash app that taught her more than any tutorial. Her side project is a yarn tracker, a real problem she actually had. It was down for three days, AI wrote the postmortem, and now she has uptime monitoring. She understands observability better now because she needed to.
Things that stuck with me
Jess said, mid-episode, that she doesn't know what a harness is. She works in AI full-time. She's been hearing the term constantly. She just hasn't looked it up yet, and on camera she admitted she was too scared to do it right then. She's doing great work in the AI space without knowing every piece of its vocabulary.
Her actual position on reading code: tests matter more than the code itself. If the tests make sense, if you have observability, if you can ask an AI to audit for security vulnerabilities, reading line-by-line is a lower priority than most engineers assume.
The postmortem detail is the one that I thought the most about. She had AI fix a bug that took her site down for three days, then asked the same session to write a postmortem and add prevention guidelines to its own rules.
The constraint is the method. Find one real problem. Pick one tool. Learn it well enough to have an opinion on the next one.
What's a side project that taught you something a job never could? Let me know in the comments!
Listen to the full episode
Available on YouTube, Apple Podcasts, and Spotify.
Thanks for reading! 👋
Top comments (0)