Nobody Told Me My Developer Profile Was My Resume Until It Was Too Late
What "personal brand" actually means for developers Here's my working definition: your personal brand is the answer someone gives when they describe you to a recruiter, a hiring manager, or a potential collaborator who hasn't met you yet. It's not your job title. It's the specific thing you're known for. "Oh, Jonathan Sanchez ? He's the one who rearchitected the notification pipeline at his last company and wrote that post about async messaging with Kafka that keeps coming up in our Slack." That's a brand. Built from real work, communicated clearly, in places where people can actually find it. The AI angle here is genuinely interesting to me, because we're at a weird moment where "developer who understands AI" is simultaneously overused as a phrase and underrepresented as a demonstrated skill. Everyone is claiming it on their LinkedIn headline. Very few people are actually showing it. That gap is an opportunity, and I don't think it stays open forever. Start with what you actually know, not what sounds impressive The biggest mistake I see junior and mid-level engineers make is trying to brand themselves around something aspirational instead of something real. They put "AI/ML Engineer" in their bio when they've done one Kaggle competition. Hiring managers see through this instantly. And worse, it makes everything else you say feel less trustworthy. My honest advice: pick one thing you genuinely know better than most people at your level. Not better than everyone, just better than most people at your experience level. For me, when I started taking this seriously, it was backend service design on the JVM. Spring Boot, async processing, connection management. Not distributed systems at Google scale. Just Java services and why they fall apart under load in production. Eight years ago wrote some notes in Confluence Page about a specific bug we'd chased for three days on our notification service, where we were exhausting the HikariCP connection pool because every inbound event was spinning up its own JdbcTemplate with a fresh DataSource . The fix sounds obvious in retrospect: // The broken pattern -- simplified recreation of what we had // Called on every incoming event. Each call creates its own DataSource. Terrible. public class NotificationHandler { public void handle(NotificationEvent event) { DataSource ds = DataSourceBuilder.create() .url("jdbc:postgresql://db:5432/notifications") .username("app") .password("secret") .build(); JdbcTemplate jdbc = new JdbcTemplate(ds); jdbc.update( "INSERT INTO notifications (user_id, message) VALUES (?, ?)", event.getUserId(), event.getMessage() ); } } // What we actually needed -- inject a shared, pooled DataSource via Spring @Component public class NotificationHandler { private final JdbcTemplate jdbc; public NotificationHandler(DataSource dataSource) { this.jdbc = new JdbcTemplate(dataSource); } public void handle(NotificationEvent event) { jdbc.update( "INSERT INTO notifications (user_id, message) VALUES (?, ?)", event.getUserId(), event.getMessage() ); } } The HikariCP pool config that finally stabilized things looked like this in application.yml : spring: datasource: hikari: maximum-pool-size: 20 minimum-idle: 5 connection-timeout: 30000 idle-timeout: 600000 Not groundbreaking. But it was real, it was specific, and four people reached out within a week saying they'd hit exactly the same thing. That's the whole point. Specific beats impressive every time. Your personal site is your professional home base A personal developer profile does something no LinkedIn page or GitHub account can do on its own: it puts everything in one place, on your terms, with your framing. Not a platform's template. Not an algorithm deciding what to show first. Your work, your way. I built my-tech-profile.dev with that in mind. The structure I landed on after a few iterations: A clear, specific bio. Not "passionate software engineer who loves solving problems" (everyone says this, it means nothing). Mine says what I actually build, what stack I work in day-to-day, and what kind of problems I find genuinely interesting. Two short paragraphs. That's it. Project write-ups, not just project links. This is the part most developers skip. Linking to a repo tells someone nothing unless they go read the code. A 300-word write-up that explains the problem, what you built, what broke, and what you'd do differently, that tells them a lot. I have eight of these on my profile right now and they consistently get mentioned in interviews. A writing section that surfaces the good stuff. Not every post I've ever published, just the three or four that actually represent how I think. Curated beats exhaustive. Contact that actually works. Sounds obvious, but I've seen developer profiles with no working email or contact form. If someone interesting finds your site and can't reach you, that's just a missed connection. The AI stuff specifically is worth being intentional about on your profile. A section that says "I'm exploring AI" is filler. A section that describes a specific thing you built with LangChain4j or Spring AI, what it does, what you learned about token limits and context window management, that's interesting. That's the kind of thing that makes a recruiter forward your profile to an engineering manager with a note. Writing: the part most engineers skip I avoided writing publicly for a long time because I thought I needed to have something novel to say. Something nobody had written before. That's completely the wrong frame. You don't need to be first. You need to be clear and specific about your own experience. The post I've gotten the most mileage out of wasn't some deep technical insight. It was a post-mortem style writeup of a migration I led where we moved a Spring monolith's auth layer to a separate Spring Boot microservice. We used JWT tokens for the handoff, ran both services in parallel for about six weeks behind a Spring Cloud Gateway routing rule. That post got shared in three different Slack communities I'm aware of not because it was brilliant. Because it was real, and people recognized the exact flavor of pain I was describing. If you're not sure where to write, start with LinkedIn articles, then link everything back to your personal profile. The writing is what matters. The platform stuff is honestly a distraction when you're just getting started. The AI dimension: being specific here is everything Everyone is an "AI enthusiast" right now. It means nothing. If you want AI to be part of your brand, you need to be specific about what you actually do with it. There's a real difference between these three positions: "I'm interested in AI and LLMs" "I've built RAG pipelines using Spring AI with a pgvector backend, and I have opinions about chunking strategies and re-ranking" "I'm figuring out how to make AI-generated code review suggestions actually useful in a Java team that has strong Checkstyle and ArchUnit rules already" Positions 2 and 3 are real stances. You can have a conversation about them. You can write a post about them. Someone can find you because of them. Position 1 is just noise at this point. I spent a few months last year building a small internal tool, basically a REST endpoint backed by a fine-tuned classification model that triaged incoming bug reports to the right team. The training side was Python, but the serving side was Java. I wrapped inference calls in a Spring Boot controller: @RestController @RequestMapping("/triage") public class BugTriageController { private final RestTemplate restTemplate; public BugTriageController(RestTemplateBuilder builder) { this.restTemplate = builder.build(); } @PostMapping public List<TriageResult> triage(@RequestBod...