From Code to Community with Daniel Afonso

🎧 New Señors @ Scale Episode

This week, I spoke with Daniel Afonso, a developer advocate, educator, and community builder who has been involved in just about every corner of the JavaScript and front-end ecosystem. He's a Senior Developer Advocate at PagerDuty, a member of the SolidJS DX team, an egghead instructor, and one of the organizers behind JNation — the developer conference in Coimbra, Portugal, where his career in DevRel effectively began. He also competed nationally in C++ programming before he knew what he wanted to do with software, used experimental React hooks in a job interview before the interviewer had ever seen them, and has Batman and Spider-Man tattooed on his arm and leg.

In this episode, we get into the origin story of a developer who learned to navigate the web by drawing symbols from the screen, how writing about every hard problem he faced became the habit that built his career, and why the first thing you should do when joining a new codebase is look at the tests.

⚙️ Main Takeaways

1. He taught himself to use the internet before he could read

At age four, Daniel figured out how to navigate websites without knowing a single word — by drawing the symbols he saw on screen and mapping them to keyboard keys.

• The setup: Cartoon Network was on the screen. He wanted to interact with it. Reading wasn't an option yet. So he built his own system.
• The result: His grandparents and parents still tell the story. The instinct to figure things out independently, without instructions, was there from the beginning.
• Why it matters: That same pattern — observe, map, experiment, repeat — shows up across everything he's built since.

2. Learning in public: write about every hard problem

Every week, whatever took Daniel a meaningful amount of time to figure out at work became a blog post. Not for an audience — just to practice writing and lock in the learning.

• The habit: Medium first, then dev.to. No strategy, no target readership. Just documenting friction.
• The compounding effect: Over time, those posts built a portfolio of writing and thinking that made the jump into developer relations credible.
• The quote: "Every time I had a challenge in my job, something that would take me a bit to figure out, I would write a blog post on it."

3. Read the tests first when joining a new codebase

This is the most practical tip in the episode, and the one most developers overlook entirely.

• Why it works: Tests tell you the business logic, the maturity of the team, what's been prioritized, and what's been ignored. They're a compressed map of the codebase.
• The secondary signal: The quality of the tests tells you what kind of team you've joined — what they care about, how rigorous they are, and what to expect.
• If there are no tests: That is your first task. Don't wait for someone to assign it.
• The quote: "If you're joining a new company and you want to learn the thing you're going to be maintaining, look at its tests."

4. Breaking into DevRel: two years of building the skills before landing the role

Daniel didn't stumble into developer relations. He saw it at JNation, understood immediately what it was, and then spent two years methodically building the skills it required.

• The moment: Attending JNation in Coimbra, watching developer advocates on stage, and having a coworker explain what the job actually was. He connected it instantly to his natural tendency to talk and teach.
• The work: Writing consistently, starting to speak publicly, building a presence in the community. Two years before the first DevRel role.
• The insight: DevRel isn't something you fall into — it's something you build toward, and the portfolio you need is made of writing and speaking reps, not job applications.

5. Remote conferences during COVID were an accelerant, not a setback

When the pandemic moved everything online, Daniel used it to speak at conferences he never would have accessed from Portugal.

• The example: React Philadelphia — a conference he spoke at while still based in Portugal. Pre-pandemic, that wouldn't have happened.
• The effect: Remote speaking gave him reps at international scale before he had the profile or travel budget to match. Those reps compounded.
• The lesson: Constraints that look like limitations sometimes remove the barriers that were actually holding you back.

6. Using experimental React hooks in a job interview — before the interviewer had seen them

During his TalkDesk interview, Daniel asked whether the interviewer wanted class components or hooks. The interviewer had never seen hooks used in an interview before. He got the job.

• The context: This was before hooks were stable. Most engineers were playing it safe with what they knew.
• The signal: Staying current with the frontier of the ecosystem — not just the mainstream — showed up as a differentiator at exactly the right moment.
• The quote: "From one Sunday to the other, my life changed completely."

7. "Thriving on Overload" — the book he's read three times

This is Daniel's most re-read book, and in the context of DevRel and staying current across a fast-moving ecosystem, it makes complete sense.

• What it's about: Managing information overload strategically — how to stay genuinely on top of a wide surface area without burning out.
• Why it matters for DevRel: Developer advocates live in the middle of enormous information flow. The skill isn't consumption — it's curation and synthesis.
• The principle: Three reads isn't accident. The ideas are operationally useful and apply differently at different career stages.

8. DevRel = making developers successful, not selling the product

The line between developer advocacy and marketing is thin. Recalibrating that line constantly is a core part of the job.

• The definition: DevRel is the bridge between a company and its developer community. The core skill is making developers successful with the technology.
• The tension: The moment it tips toward selling rather than enabling, the community notices — and the trust that makes DevRel valuable evaporates.
• The reality: Holding that line requires constant judgment and, often, difficult internal conversations.

9. "The Phoenix Project" didn't land until he was living it

Daniel read The Phoenix Project before joining PagerDuty. It only truly clicked once he was inside the world of DevOps and observability.

• The before: He read it, understood it conceptually, thought it was fine.
• The after: Working at PagerDuty, inside the incident and reliability world, every story in the book suddenly had a direct parallel. The characters became real.
• The principle: Some books require the lived experience to unlock. Reading them early isn't wasted — but the second read, in context, is where the value is.

10. National programming competitions built rigor before he cared about rigor

Before Daniel knew he wanted a career in software, he was competing nationally in C++ programming in Portugal. He qualified twice.

• The effect: The competition circuit forced a level of precision, problem-solving under pressure, and structured thinking that most developers only develop years into their careers.
• The timing: It happened before he had professional goals or a framework for why it mattered. The rigor came first; the career came later.
• The pattern: Early, high-pressure environments that push you past your current ceiling often define how you think for decades.

🧠 What I Learned

• Learning in public doesn't require an audience — it requires a habit. Write about what takes you time. The audience is a side effect.
• The first thing to do when joining a new codebase is read the tests. They contain the business logic, team maturity, and your first roadmap. No tests means that's your first task.
• Breaking into DevRel is a two-year project of reps, not a single application. Build writing and speaking before you apply.
• Remote conferences during COVID removed geographic barriers and gave people international speaking reps they wouldn't have gotten otherwise.
• Staying current with the frontier of your ecosystem — not just the stable mainstream — creates differentiating moments at exactly the right times.
• DevRel is about making developers successful. The moment it becomes about selling, the trust that makes it work dissolves.
• Some books only unlock when you're living the context they describe. A second read after experience is often worth more than the first.
• Early high-pressure environments — competitions, demanding first jobs — install rigor before you know why you need it.
• Curiosity without instructions, mapping unfamiliar territory, figuring things out before anyone explains them — that pattern shows up early and compounds.

💬 Favorite Quotes

"Every time I had a challenge in my job, something that would take me a bit to figure out, I would write a blog post on it."

"If you're joining a new company and you want to learn the thing you're going to be maintaining, look at its tests."

"From one Sunday to the other, my life changed completely."

"If there's a good story, I'll enjoy it. It doesn't matter if you're from one family or the other."

🎯 Also in this Episode

• Growing up in Portugal: Cartoon Network at age four, mapping URLs with hand-drawn symbols
• The national C++ programming competition circuit in Portugal — qualified twice
• The Farfetch years: joining a senior team at 21 and building in React before hooks were stable
• Getting hired at TalkDesk by using experimental React hooks in the interview
• How he became a JNation organizer — started as an attendee, ended up building the event
• Faris and "the penicillin dish of incidents" — the colleague who has experienced every type of production incident and what you can learn from them
• The tricky line between internal developer enablement and external developer advocacy
• The Batman and Spider-Man comic collection — tattooed on his arm and leg
• "Death in the Family" as the comic that started everything (Jason Todd / Red Hood)
• DC vs Marvel, and why the story is what actually matters

Resources

More from Daniel:

• Daniel on Twitter/X
• egghead courses by Daniel Afonso
• JNation Conference

Book Recommendations:

• Thriving on Overload by Ross Dawson — Managing information overload strategically
• The Phoenix Project by Gene Kim — DevOps, incidents, and organizational dysfunction (read it again after you're living it)
• How to Win Friends and Influence People by Dale Carnegie

🎧 Listen Now

🎧 Spotify
📺 YouTube
🍏 Apple Podcasts

Episode Length: 58 minutes on learning in public, breaking into DevRel, reading tests first, and building a career from genuine curiosity.

If you're thinking about developer relations, wondering how to build a presence in the community, or just looking for one concrete tip to use on Monday morning — read the tests first.

Happy building,
Dan