Scheming Is Always Good: A Developer's Guide to Networking

Introduction

I gave a talk at DevNexus 2026 and opened it with a question: “Raise your hand if you’ve ever said ‘I’m bad at networking.’” Most hands went up. Including, if I’m being honest, mine — not too long ago. Here’s the thing though. The pandemic changed most or all of our behaviours. It rewired how we interact, pulled us out of hallways and happy hours and conference lobbies, and left a lot of us with professional relationships that were more brittle than we realized. Remote work was a gift in a lot of ways. But it quietly hollowed out some of the casual, compounding conversations that used to build careers without us even noticing.

We still need connections. That hasn’t changed. What changed is that we now have to be intentional about building them — and most developers have no framework for doing that. Which is interesting, because every developer already knows how relationships work. You define them in code every single day.

belongs_to. has_many. has_many :through. These aren’t just ORM patterns. They are, it turns out, a pretty complete map of how professional relationships actually function in a tech career. And once you see your network as a schema, you can start designing it like one. Scheming is always good. Let’s get into it.

---

Why Socialization Still Matters

Before we get into the schema, let’s establish why any of this matters. Because if your reaction to “you need to network more” is the eye roll — I get it. The “word” has baggage. It conjures images of awkward conversations, LinkedIn messages that feel like cold call scripts and the “Hi” that gets ignored.

But socialization in society and, by extension, tech — real, intentional socialization — unlocks things that no amount of solo grinding will:

• Relationships that make you better at your job and keep you sane while doing it
• Resources and opportunities that aren’t posted anywhere publicly, because they travel through trust networks first
• Belonging to a community that gives you context and perspective you can’t get from documentation
• Collaboration that makes your work better than what you’d ship alone
• Growth that compounds — because every person who knows what you can do is a potential amplifier

As they say, “links run the world”. I’ve seen this in my own career. This topic started with a conversation with my manager about how to present a “soft skill” as a technical topic. My ability to put myself into different tech spaces has yielded speaking, learning, and earning opportunities. People who have seen me speak, whom I’ve helped or connected to resources, remembered me and made calls that have grown my career. None of those things came from a cfp or resume submission into a void.

@LawrenceDCodes said something at a conference that I’ve been carrying around ever since:

“You are your own developer advocate.”

That’s the whole thing. The network you build is the marketing department you can’t afford to pay for. Every person who knows your name, your work, and what you stand for is doing advocacy for you when you’re not in the room. That’s not cliche, that’s infrastructure.

📣 Before you keep reading: Write down 3 people you’d want in your corner right now — a mentor, a peer, a community anchor. We’ll figure out what “type” they are by the end of this post.

---

The Core Idea: Your Network Is a Schema

Here’s the mental model that will make all of this click:

Every person in your network is a record. Every relationship has a type.

The type determines:

• Who holds the foreign key — i.e., who carries the responsibility for maintaining the relationship.
• What the cardinality is — one person on the other side, or many.
• Whether a join model is needed — did someone introduce you, or did you just end up in the same Discord server?

If you’ve worked with Rails, TypeORM, Sequelize, Prisma, JPA, or pretty much any ORM in any language, you already know these patterns. Here’s the mapping:

Association	Career Translation
belongs_to	One-to-one, intentional connections — you hold the FK
has_and_belongs_to_many	Community membership — mutual, lightweight, no join model needed
has_many :through	Warm introductions — you reach new people via existing relationships
has_many	Groups, audiences, communities — many FKs point to you
has_one	Mentorship — you are the anchor, they hold the FK

The language you work in doesn’t matter. Rails calls it belongs_to, TypeORM calls it @ManyToOne, Prisma uses @relation and JPA uses @ManyToOne. The concept is identical across every ecosystem: the type of relationship determines who does the work, how it scales, and what data it carries. Your career network works the same way. Once you know the type, you know the strategy.

📣 Map it before you build it: Before moving on, open your notes app and ask: which of these association types do I actually have in my career right now? Which ones are missing? A blank slot isn’t a failure — it’s a backlog item.

---

belongs_to — Your One-to-One Connections

What It Actually Means

In a belongs_to relationship, the foreign key lives on your table. You chose the association. You made the add. You carry the maintenance responsibility.

In career terms, this is your deep, intentional, one-on-one network:

• Coffee chats — you reached out, you hold the link.
• Intentional LinkedIn connections — not spray-and-pray, but people you specifically wanted to know.
• One-on-ones with a mentor, accountability partner, or manager — focused, recurring, directional.

The Pros and the Real Talk

The upside of this relationship type is focus. belongs_to connections are where real trust gets built. A 20-minute conversation where someone asks “what are you actually trying to do next?” and actually listens — that’s worth a hundred LinkedIn connections.

The honest challenge: it doesn’t scale; it’s not supposed to. You can only belongs_to so many people meaningfully. Every one of these relationships costs time and attention, and the foreign key is on your table — meaning you’re the one who lets it get stale if you stop showing up.

Most developers underinvest here because asking for a 1:1 feels awkward. It shouldn’t. The ask is almost always welcomed — people are flattered, not annoyed. The uncomfortable truth is that the awkwardness is in our “mostly” heads, not in the actual dynamics of the relationship.

How to Build It

• Send the message. Not “we should connect sometime” — send an actual ask with a specific day and a specific topic. Remember: you need one win.
• Come prepared. Research before you meet. Know what you want from the conversation and what you can offer in return.
• Follow up. The relationship doesn’t end when the call does. A quick “hey, I tried what you suggested and here’s what happened” goes further than most people realize.

📣 Your belongs_to action: Who is one person you’ve been meaning to reach out to for a 1:1? Stop meaning to. Send the message today — not “let’s connect sometime,” but an actual ask with a day and a time. One message. That’s it.

---

has_one — Your Mentorship Relationships

What It Actually Means

In a has_one relationship, the foreign key (FK) flips. They hold the reference back to you. You are the anchor — the more experienced person, the organizer, the one who created the seat.

This is the mentorship relationship, and it works in both directions:

• You seek a mentor — you become the record that holds a FK pointing to someone further along in their career.
• You become a mentor — you create a has_one slot and let someone else carry the FK back to you.

The Pros and the Real Talk

The upside: focused guidance, structured accountability, and — if you’re the mentor — the compounding benefit of teaching solidifying your own knowledge. Every explanation you give to a mentee sharpens your own understanding.

The honest challenge from the talk: finding a good match is hard. Not every has_one is the right one. Sometimes the chemistry isn’t there. Sometimes the timing is off. Sometimes the person you admired as a mentor turns out to be unavailable, or the mentee you took on wasn’t ready. That’s okay. The relationship is refactorable.

The thing that most people miss: good mentorship is structured. It isn’t just vibes and encouragement on a biweekly call. It has goals, check-ins, defined expectations, and honest feedback. If you want to go deeper on what that actually looks like from both sides, the How !To Be Mentored V2 post has the full breakdown.

How to Build It

• As a mentee: Go in with a clear articulation of what you want to learn and a realistic sense of what you’re bringing to the relationship. “I want to grow” is not enough. “I want to transition into senior-level work within 18 months and I need help with system design and navigating internal politics” — that’s a starting point.
• As a mentor: Recognize that your experience has value even if you don’t feel senior enough. You know more than a developer one step behind you. That’s enough.

📣 Your has_one action: Are you currently in a has_one relationship — as either the mentor or the mentee? If not, check out ADPList or MentorCruise, or reach out to someone in your company whose career trajectory you admire. One ask is all it takes to open that slot.

---

has_many — Groups, Stages, and Audiences

What It Actually Means

In a has_many, you are the hub. A lot of foreign keys on other tables all point back to you at once.

This is the multiplier move in career networking:

• Speaking at or organizing a meetup.
• Giving a conference talk.
• Leading or contributing to an open source project.
• Teaching a course or creating technical content.
• Running a workshop or community event.

One Atlanta freeCodeCamp meetup event: potentially 15-30 developers in your has_many. One DevNexus talk: a room full of engineers who now know your name, your perspective, and what you care about. One workshop given: students across multiple continents with a FK pointing back to your content.

The Pros and the Real Talk

The upside: broader reach, improved perspective, leadership skills that money can’t directly buy. The collection grows fast once you get going. The honest challenge: the collection only grows if you keep showing up. There are no passive has_many relationships. The meetup that runs once and disappears doesn’t build a network — it creates orphaned records. The talk you give but never follow up on is a missed join/connection. Consistency is the entire mechanism.

The other honest challenge: you have to earn the right to someone’s FK. People choose which speakers, organizers, and creators to follow. The quality of the thing you’re putting into the world determines the quality of the collection.

How to Build It

• You don’t need DevNexus to start a has_many. Show up consistently to one Discord server and answer questions. Comment on posts. Share resources. Five engaged community members is a better has_many than five hundred passive followers.
• Compound the effort. Every talk builds the next. Every post seeds the audience for the one after it.

📣 Your has_many action: Pick one venue this month — a meetup, a Discord server, a local conference, a Twitter/X thread — and show up. Not once. Three times in a row. Let the collection start. Progress over perfection.

---

has_many :through — The Warm Introduction (The Most Important Pattern)

What It Actually Means

This is the centerpiece. Give it some space in your brain.

In a has_many :through, you reach new people through an existing relationship. And the join model — the thing in the middle — carries the actual data: context, trust, shared history. That’s what makes it completely different from a cold connection.

Here’s the concrete difference: A cold LinkedIn request carries: nothing. No context, no trust, no shared history. Hit rate is somewhere around 2%. It feels transactional because it is transactional.

A warm introduction carries: “We both spoke/attended at Connect.Tech. I saw your Vue talk. You two should meet — you’re working on similar things.” That’s trust transferred. That’s context. That’s a completely different starting point for a relationship.

The join model is the handshake. And it has fields: how you met, what you have in common, who vouched for whom, and why the introduction makes sense. A cold connection has no join model. It’s just a raw has_and_belongs_to_many with no story.

Your Real :through Examples

From my own network:

• Volunteer role at Connect.Tech → new conference speakers and sponsors I would never have cold-messaged.
• Former colleagues at previous companies → referrals and job leads that came without a job board.
• Vue Mastery content → students and developers worldwide who reached out because they saw the work.
• A conference talk → hiring managers and senior peers who came up afterward and became real relationships.

In every one of these, there’s a through model — a shared experience, a mutual contact, a piece of content — that carried enough trust and context to make the new connection mean something immediately.

The Pros and the Real Talk

The upside: faster network growth with built-in trust. A relationship that starts with a warm or friendly introduction starts from a position of credibility. You don’t have to spend the first three conversations establishing that you’re worth talking to.

The honest challenge: this requires relationship maintenance on the front end. The join models don’t build themselves. You have to invest in the has_many and belongs_to relationships first — the ones that will eventually become your through models. Chaos, as the talk notes, if your relationship skills are static.

📣 Your :through action: List one person you want to meet. Now ask: who in your current network could introduce you? And ask yourself honestly — have you given them enough reason to do it? Invest in that middle relationship first. Then make the ask. That’s has_many :through.

---

has_and_belongs_to_many — Community Engagement

What It Actually Means

This is the community layer. Both sides are members of something together. Neither needs to track why or how — just that they’re in the same room, physical or digital.

habtm is what happens when:

• You’re an active, helpful presence in a developer Discord server.
• You contribute to or maintain open source projects.
• You’re a known face at recurring events — your local meetup, a conference you keep showing up to, an online community you participate in regularly.
• You’re on the Twitter/X/Bluesky dev community timeline actually engaging, not just broadcasting.

What makes this different from has_many: you don’t own the relationship. Both sides are equal members. Neither has the FK. It’s mutual. You’re not the hub — you’re a node in a larger mesh.

The Pros and the Real Talk

The upside: diverse perspectives, collaborative opportunities, and the kind of visibility that happens through genuine participation. The habtm layer is where you build your reputation at scale. It’s slow, but it compounds.

The honest challenge: you can’t be in 40 communities. The habtm pattern, applied carelessly, is how developers end up scattered across a dozen Slack workspaces and Discord servers, occasionally lurking, never actually present. That’s not community engagement — that’s social media hoarding.

Pick 3–5 communities and actually show up in them. The tech reality check from the talk: some communities thrive in person. Others are digital-only. Both are valid. What matters is consistency and genuine contribution — not passive membership.

📣 Your habtm action: What communities are you lurking in right now? Pick one. Go from lurker to participant this week. Answer a question, share a resource, comment on someone else’s post. That’s your habtm — go add a record.

---

Implementation: How to Actually Do This

Knowing the patterns is one thing. Putting them into practice is another. Here’s the implementation guide, distilled from what actually works.

Network Online and Offline

Don’t silo yourself. The developers who build the strongest networks move between both modes. Conferences/meetups are where you create the initial record — the shared experience that becomes the join model later. Online communities are where you maintain the collection between events.

The Developer Networking Tools: A Brief IRL Edition post goes deep on the unconventional offline tools — but the short version is that your conference shirts, your known presence at recurring events, and your genuine follow-through are doing more work than any LinkedIn profile optimization.

Use Your Tools

The database metaphor holds here too: don’t rely on your memory to maintain relationships. Log conversations. Keep a note when someone mentions a project they’re working on. Reference it next time you talk to them. The developers who follow up — who remember the thing you mentioned three months ago and circle back with something useful — are rare, and they are never forgotten.

Some options that work:

• Notion or Obsidian for a lightweight personal CRM.
• A brag document that also tracks meaningful connections and conversations (borrowed from the mentorship playbook).
• Calendar reminders/Coffee chats to check in with key belongs_to relationships on a regular cadence.

Build Incrementally

You don’t need to attend five conferences, join ten communities, and schedule twelve 1:1s this quarter. That’s not a networking strategy — that’s a burnout recipe.

Build in sprints. One new belongs_to connection per month. One new community per quarter. One talk per year. Those numbers compound over two to three years in a way that’s difficult to imagine when you’re standing at the start.

📣 Your implementation action: Pick one step from above — just one — and put it in your calendar for this week. Not “someday.” This week. Progress over perfection.

---

Measuring What Matters: Quality vs. Quantity

Most developers default to vanity metrics when they think about networking: follower counts, LinkedIn connection numbers, conferences listed on a bio. Those are output metrics. They tell you how many records are in the table, not whether the schema is working.

The real questions to ask yourself, borrowed from the talk’s quantification slide:

• Quality check: Are these relationships two-way? Do people reach out to you, or do you always initiate? A network of one-way FKs is a collection without joins — impressive in size, hollow in function.
• Be realistic: You cannot deeply maintain 500 relationships. The belongs_to and has_one associations need active tending. The has_many and habtm layers are more passive — but they still require showing up.
• Evaluate regularly: Set a quarterly review. Who haven’t you talked to in a while? Who has drifted naturally? Who should you intentionally reconnect with? Which communities have gone stale?

The ORM metaphor one last time: even good databases need maintenance. Orphaned records, stale joins, and broken foreign keys are as real in your career graph as in your schema. Clean them up. Refactor the relationships that aren’t serving you. Invest more deeply in the ones that are.

📣 Your measurement action: This week, audit your network. Pick 3 relationships you want to strengthen and 1 you’ve been neglecting. Reach out to all four. Relationships deprecate if you don’t maintain them.

---

Further Reading and Resources

• “Developer Networking Tools: A Brief IRL Edition” → developingdvlpr.com — the original unconventional tools post that seeded this talk.
• “So…This Is Your 1st Tech Conference: #AttendeeEdition” → developingdvlpr.com — practical guide to maximizing your has_many at conferences.
• “How !To Be Mentored V2” → developingdvlpr.com — the deep dive on has_one done right.
• “My Takeaways From Sit-Downs with Senior Devs” → developingdvlpr.com — what belongs_to relationships actually teach you.
• ADPList — free mentorship platform, great for finding your has_one.
• MentorCruise — paid mentorship from senior engineers and engineering managers.
• “Active Record Associations” → guides.rubyonrails.org — the docs that started the whole metaphor.
• “Atomic Habits” by James Clear — because consistent, incremental showing up is the entire mechanism.

---

Summary

Your network isn’t a list of contacts. It’s a schema — and like any good schema, it needs intentional design, regular maintenance, and the right associations for the right use cases.

belongs_to your people: the intentional, one-on-one relationships where you hold the FK and the responsibility. has_one and be had: find a mentor, create a mentorship seat, build the structured relationship that provides actual career direction. has_many consistently: show up, speak, organize, contribute — let the collection grow. Build your :through models and let trust do the heavy lifting: invest in the relationships that become warm introductions for others. And show up to enough communities that your has_and_belongs_to_many layer gives you breadth, diversity, and the kind of visibility that passive broadcasting never will.

And through all of it, remember what @LawrenceDCodes said:

“You are your own developer advocate.”

Build the network that advocates for you when you’re not in the room.

---

📣 Your turn. If this post gave you a new framework for thinking about your career network, I want to hear about it. What association type are you working on right now? What’s your biggest networking gap?

Find me @nerajno on Twitter/X, Bluesky, and LinkedIn — my DMs are open. The slides from the DevNexus 2026 talk are linked below if you want to dig into the ORM cross-reference (Rails, TypeORM, Sequelize, Prisma, JPA all mapped to the same networking metaphors).

And if you’re in Atlanta — come through to an Atlanta meetup. That’s my has_many right there, and there’s always room for one more record in the collection.