For a software engineer, a personal brand is simply what people think of when your name comes up: “she writes about Android performance,” “he maintains that payments library,” “they’re the one who explains Kubernetes clearly.” You build it by doing useful work in public, around a few topics, consistently. You don’t need to become an influencer, post every day, or have a big following.
This guide covers the building blocks (a portfolio site, writing, open source, talks, and social media), a 90-day plan to start small, how to keep going, and the mistakes that hurt more than they help.
Why it’s worth the effort, and when it isn’t
A visible body of work makes several things easier:
- Job searches. Hiring managers can see how you think before the first interview. That matters even more when you’re applying for remote roles in another country, where nobody knows your previous employers.
- Inbound opportunities. Recruiters, founders, and clients find you through what you’ve published.
- Learning. Explaining something in writing exposes the parts you don’t fully understand yet.
- Freelance credibility. Clients trust someone they can look up. If that’s your direction, Freelancing 101 covers the rest of the setup.
It isn’t mandatory, though. Plenty of excellent engineers have no public presence and build strong careers through good work and good relationships. If writing in public makes you miserable, a solid resume and a healthy network will still carry you. And it should never come at the expense of your actual job, which is where most of your best material comes from.
Pick a narrow topic
“Software engineer” is too broad to be memorable. A useful formula is technology or domain + audience + angle. For example:
- Flutter apps for small businesses that can’t afford two native teams
- Kotlin Multiplatform for teams moving off separate Android and iOS codebases
- Practical AI automations for small online shops
- Go backend performance for engineers who have never profiled anything
Choose something you already do at work or in side projects, so your material comes from real problems instead of research. You can change topics later, and most people do. A narrow topic just makes it easier to start and easier for people to remember you.
The building blocks
A portfolio site as your home base
Social platforms change their rules and their reach. A site you control doesn’t. It doesn’t need to be fancy, but it needs four things:
- About: one paragraph on what you work on and who you help.
- Projects: three to five, each with the problem, your role, the result, and a link.
- Writing: your posts, or links to where they’re published.
- Contact: an email address or another simple way to reach you.
GitHub Pages is an easy place to start. It hosts static sites straight from a repository, gives you an address at your-username.github.io, and supports a custom domain when you’re ready for one. For what to put in the projects section, see how to build a software engineer portfolio that gets interviews.
Writing
Writing gives the best return on your time. Posts are searchable and shareable, and they keep working for years. Formats that suit engineers:
- Debugging stories: the bug, the investigation, and the fix, with confidential details removed.
- Today-I-learned notes: short posts about one thing you figured out.
- Comparisons: two libraries or approaches you actually tried, with the trade-offs.
- Explanations: a concept you recently learned, written for the person you were a month ago.
Two essays are worth reading before you start. Julia Evans’ Some blogging myths takes apart the beliefs that stop most people, such as needing to be an expert or needing a topic nobody has covered. swyx’s Learn In Public makes the case for sharing what you learn while you learn it, and for creating the resource you wish you’d had.
Publish on your own site first. Cross-posting to developer community platforms can bring more readers; when a platform allows it, point back to the original on your site.
Open source
Contribute to tools you already use, where you understand the problems. Small, solid contributions such as a documentation fix, a bug fix with a test, or a clear bug report build a reputation with maintainers. If you’ve built something reusable in a side project, publishing it as a small library with a good README is worth more than a dozen half-finished repositories.
Add a profile README to your GitHub account as well. GitHub displays it on your profile when you create a public repository named after your username with a README in it (setup steps here). Use it to link to your site and your best writing.
It can be this short:
# [Your name]
Android and Flutter engineer. I build apps for small businesses
and write about making them fast and reliable.
- Writing: https://[your-site]/blog
- Currently working on: [project or topic]
- Contact: [email address]
Don’t chase a solid green contribution graph. Few people read it closely, and padded commits look worse than gaps to those who do.
Talks
In a local community, talks tend to build recognition faster than writing, because people put a face to the name. Start small:
- An internal tech talk at work, or a five-minute lightning talk at a local meetup.
- A talk based on a post that already got a good response, so you know the topic lands.
- A longer meetup talk, then conference talks if you enjoy it.
Record your talks when you can, or publish the slides with speaker notes, so they keep working after the event.
Social media
Choose one platform where your audience already spends time, such as LinkedIn, X, Bluesky, or Mastodon, and ignore the rest at first. Share what you’re building, link to your posts, and reply thoughtfully to people in your niche. Conversations build more relationships than broadcasting. This overlaps heavily with networking: a brand is partly just a network that knows what you do.
What a useful first post looks like
Most first posts fail because they’re too general. A post that solves one specific problem for one specific reader is easier to write and far more likely to be found and shared. This structure works for most technical posts:
- A title that says what the reader gets. “Fixing slow cold starts in a Flutter app” beats “Some thoughts on performance.”
- The problem in two sentences. What went wrong, and who is likely to run into it.
- Context. Versions, platform, and setup, so readers can tell quickly whether it applies to them.
- What you tried, including what didn’t work. Dead ends are often the most useful part for someone stuck in the same place.
- The fix, with the smallest code snippet that shows it.
- The result and how you measured it. Before and after, using your own numbers.
- Limits. When this approach doesn’t apply, or what you’d do differently next time.
Seven short sections like these often add up to 600 to 1,000 words, which is plenty.
A 90-day plan to start small
| Weeks | Focus | Done when |
|---|---|---|
| 1–2 | Foundations | A simple site is live, your GitHub profile README is up, and your LinkedIn headline matches your topic |
| 3–6 | First writing | Two posts published, both based on real work from the last few months |
| 7–10 | Community | One open source contribution, plus one useful answer a week in a community you use |
| 11–13 | First talk or bigger piece | A lightning talk or one longer write-up, and a review of which pieces got real responses |
At the end of the 90 days, look at what produced conversations, questions, or opportunities. Do more of that and drop the rest.
Staying consistent
Consistency matters more than volume. One solid post a month for a year is worth far more than ten posts in a burst followed by silence.
- Keep an idea log. Every time you solve a tricky problem or answer a teammate’s question, add one line to a notes file. That list becomes your backlog of topics.
- Use a fixed slot. A recurring hour on your calendar is more reliable than waiting for inspiration.
- Reuse your work. One investigation can become a post, a short social thread, and later a talk.
- Measure the right thing. Page views say little. Messages from readers, questions from colleagues, and opportunities that mention your work are the signals that count.
- Ship imperfect pieces. A clear post with a rough edge beats a perfect draft that never gets published.
What to avoid
- Sharing confidential work. Check your employer’s policies, strip out internal names and data, and ask when you’re unsure. A post that leaks internal details can cost you more than any brand is worth.
- Hot takes for engagement. Dunking on other people’s work gets attention but builds the wrong reputation.
- Inflating your experience. Claimed expertise falls apart in the first real technical conversation.
- AI-generated filler. Generic posts that could have been written by anyone about anything damage your credibility. Use AI tools to edit if you like, but the substance has to come from your own work.
- Spreading too thin. Six half-maintained profiles look worse than one active one.
- Neglecting the day job. Your best material comes from doing good work. A brand without that work behind it is empty.
Your next step
Today, open a notes file and list five problems you solved in the last three months. Pick the one you would most have wanted to read about before you solved it, and write it up in under 800 words this week. Publish it on a simple site or on GitHub, and share it in one community where it would genuinely help someone.