A Follow-Up: The Resume PDF Links Needed the Same Fix

I recently made external links open in a new tab instead of navigating away from the site, but I only caught the links inside blog posts and on the Projects page. I missed the two "Download PDF" buttons on the home page and the resume page. Both link to /resume/Peter_Connolly_Resume.pdf. Technically, it's hosted on my own domain, but functionally it's a different destination. Clicking it either opens a PDF viewer or starts a download, not a page on my site.

The fix

Same pattern as before, applied to both instances:

<a
  href="/resume/Peter_Connolly_Resume.pdf"
  target="_blank"
  rel="noopener noreferrer"
  className="..."
>
  Download PDF
</a>

Why this is actually more user-friendly

It's worth explaining the reasoning, not just the code, since "open everything in a new tab" is not a rule I'd apply everywhere:

• It preserves context. Someone reading my resume or a project case study who clicks the PDF doesn't lose their scroll position. They can close the tab and land right back where they were, instead of hitting the browser's back button and reloading the page.
• It supports exploration instead of exit. This site exists for people evaluating me. Recruiters and hiring managers often want to check several things in one visit: the PDF, GitHub, LinkedIn. If every click replaces the page they're on, each one becomes a dead end they have to backtrack from. New tabs let them open several in parallel and come back to where they started.
• It matches the mental model of "leaving." A PDF download or an external site is conceptually a different destination, not another page of mine. Treating it as a separate tab matches what a visitor already expects.

The honest caveat: opening every link in a new tab is a real anti-pattern, not a universal best practice. It clutters the visitor's tabs, and WCAG accessibility guidance recommends warning users when a link will open a new window, since an unexpected context switch is disorienting, especially for screen-reader or keyboard users. That's why this fix is scoped narrowly: only genuine external destinations and file downloads get target="_blank". Navigation between my own pages, like Home, Resume, Projects, and Blog, stays as normal same-tab links, because there's no "leaving" happening. It's just the site.

The PM angle

This is the second time a "make links open in a new tab" request has needed more than one pass. The first pass covered the two link-rendering code paths I could see immediately: markdown output and the Projects page. The PDF buttons were a third path, easy to miss because they don't look like links. They look like buttons in a call-to-action row. The lesson isn't "I missed something." It's that verifying a fix means walking every place the pattern could apply, not just the places you remembered when you scoped the task. That's the same discipline as a QA pass on a requirements checklist at work. The gap is rarely in the code you wrote. It's in the inventory of places you didn't think to check.