Skip to main content

The Technical Bio and About-Me

What This Concept Is​

The technical bio is the 100-200 word paragraph that appears on your GitHub profile, personal site, and conference talk intros. It answers three questions:

  • What do you work on? (not "passionate about" -- actual subject matter)
  • What is the evidence? (one or two concrete things, linkable)
  • What are you trying to learn next? (direction without puffery)

A good bio reads like something an engineer would write about another engineer. A bad bio reads like a LinkedIn headline.

The bio is a surprisingly high-leverage artifact because it is tiny, read often, and copied verbatim by other people. Conference organizers, podcast hosts, and coworkers writing introductions will paste whatever is on your site without rewriting. One crisp paragraph, once written, shapes how you are introduced for months without your involvement.

That property -- high reach, zero reaudit cost per use -- is the same property that makes a well-written commit message or ADR pay out repeatedly; you pay once, the artifact is read many times. The bio is the most extreme example of that pattern in the portfolio.

The bio is also a forcing function for self-knowledge. You cannot write a sharp two-sentence bio while your own positioning is fuzzy. Trying and failing to write one is diagnostic -- it tells you the work you have not yet done thinking about what you work on.

Why It Matters Here (In the Capstone)​

Your bio is the first paragraph any reader sees across every channel. It runs at zero marginal cost -- once written, it pays out every time a reader lands on you. A weak bio still runs. It just keeps paying negative returns.

The bio is also a forcing function. If you cannot write two sentences about what you work on without using the words "passionate," "love," or a six-language laundry list, you probably have not decided yet. Writing the bio is partly how you decide.

At graduation the bio is the compressed version of the specialization decision (cluster 4). If you cannot name your chosen track in the bio without stretching, the specialization decision has not yet landed, and the rest of Module 5 is papering over it.

There is an additional, pragmatic reason the bio matters at graduation: it is the single paragraph a recruiter will copy-paste into a spreadsheet to triage whether the conversation is worth their time. A bio that names the domain, the evidence, and the direction survives triage. A bio that is adjectives and a laundry list does not.

Concrete Example: Good Bio​

"I build backend systems with an emphasis on reliability under retry and partial failure. My capstone is a multi-tenant inventory service with idempotent ingestion and an on-call runbook that has actually been used; the case study is at [example.com/inventory]. Currently digging into Raft and Rust for systems work."

What works: specific domain ("backend, reliability under retry"), concrete artifact (capstone + runbook + link), current direction (Raft + Rust) without claiming expertise in either. Every sentence either names a subject, names an artifact, or names a direction.

Concrete Example: Bad Bio​

"Passionate software engineer with 10+ years of experience building scalable, robust solutions for complex problems. I love learning new technologies and contributing to impactful projects. Skilled in Python, JavaScript, Go, Rust, Kubernetes, AWS, Docker, Terraform, Kafka, Redis, and more."

What fails: zero domain specificity, zero artifact, no direction, tool list as identity substitute. A reviewer learns nothing. Worse, they pattern-match to "generic developer bio," which is read as low signal regardless of whether the person is good.

Concrete Example: Three Lengths, Same Person​

A well-tuned bio has three canonical lengths that all say the same thing at different resolutions:

  • v1 (<= 50 words, crowded pages): "Backend engineer, focused on reliability under retry and partial failure. Capstone: multi-tenant inventory service with idempotent ingestion. Learning: Raft, Rust."
  • v2 (<= 200 words, personal site About): the full paragraph above plus one paragraph of what you have recently written or built, with two links.
  • v3 (<= 100 words, canonical): the v1 version expanded with one sentence of evidence and one sentence of direction; the default for GitHub and conference bios.

Keeping all three in sync is the maintenance cost. Keeping the same voice across all three is the signal.

Common Confusion / Misconceptions​

Treating the bio as self-promotion. It is not. It is orientation for the reader. The reader has limited attention; the bio tells them whether spending more of it on you is worth it. Orientation done honestly is the opposite of bragging -- it helps the reader self-select out if they are not a match.

Aspirational bios. "Distributed systems engineer" when you have never shipped one in production is read-through by anyone senior. Write the bio that matches what you can defend today; rewrite it after the next artifact, not before.

First-person vs third-person confusion. First person ("I build...") is right for personal pages. Third person ("Alex builds...") is for conference bios and team pages. Don't mix them in one paragraph.

The ever-lengthening bio. Bios accrete. Every new project tempts an extra sentence, which eventually produces a three-paragraph bio nobody reads. Re-cut the bio once a year; net length should stay roughly stable even as accomplishments grow.

The tool-list identity. "Python, Go, Rust, Kubernetes, Postgres, Kafka, AWS, GCP, Terraform..." is the single most common bio failure mode. The list signals "I know how to operate these" but leaves the reader with no idea what problem you are the person to call for. Identity is a problem you own, not a stack you are employed against.

The aspiration-by-label trick. Calling yourself a "staff engineer" before the title is earned, or a "distributed systems engineer" before shipping one, is the move a senior reader will flag and silently discount. Name the level that matches the evidence; trust the reader to see the trajectory.

How To Use It (In Your Capstone)​

Write the bio in this order:

  1. One sentence on subject matter -- domain nouns, not adjectives.
  2. One or two sentences of evidence -- what you made, with a link.
  3. One sentence of current direction -- what you are trying to learn next.
  4. Cut 20%.
  5. Read aloud. If any sentence would sound dishonest in a live conversation, replace it.
  6. Produce v1 / v2 / v3 from the same core.
  7. Commit all three to a canonical file (about.md in your site or profile repo) and reference-link them from every channel.

A final check: does the bio sound like the same person who wrote your capstone case study? If the voices diverge, one of them is fake.

Check Yourself​

  1. Is the first sentence about what you work on, or about traits you have?
  2. Is there a linkable artifact in the bio?
  3. Would the bio survive a five-minute live chat with the reader asking follow-ups?
  4. Do your v1, v2, and v3 bios say the same thing in the same voice?
  5. If a stranger copy-pasted the bio into a podcast intro, would you be happy with it?
  6. Has the bio been edited in the last 12 months, or is it pointing at the person you were at capstone start?

Mini Drill or Application (Capstone-scoped)​

Three drills:

  1. Three versions in one sitting. Write v1 (<= 50 words), v2 (<= 200 words), v3 (<= 100 words). Keep all three; the discipline is producing them consistently, not picking one.
  2. Honest-sentence scan. Read each bio aloud. For every sentence, ask "would I say this in a first-meeting conversation?" Replace anything that sounds like copywriting.
  3. Cross-channel sync. Paste v3 into your GitHub profile README, LinkedIn headline-and-summary, and personal site About section. The three must agree. If they do not, decide which is the canonical copy (usually about.md in your site repo) and make the others point at it.
  4. Five-year test. Write the bio you would want to read five years from now, then back off the claims to what you can defend today. The gap between the two becomes the skeleton of the 12-month plan.

File the three versions in your portfolio repo under library/raw/about/. Update once per year and when the capstone's status changes.

Transfer / How This Synthesizes Prior Semesters​

The bio is the smallest compression you will attempt in the degree, and everything that makes it work comes from prior semesters:

  • S7 M05 ADRs & reviews -- a bio is a personal ADR: decision (what you work on), context (evidence), consequence (direction); the same three-part shape.
  • S3 M05 applied design & code review -- the "remove what does not earn its line" review discipline is how you cut the bio to 100 words without losing its center.
  • S7 M04 API design & contract evolution -- the bio is a public contract; changing it silently breaks downstream consumers (podcast hosts, conference organizers) the same way a silent API change breaks service consumers.
  • S8 M05 technical leadership & strategy -- "communication is the craft"; the bio is the single line of communication that runs most often without your involvement.
  • S10 M05 c4 concept 12 -- the "currently learning" sentence has to match the 12-month plan; if the bio is ahead of the plan, the bio is marketing, not orientation.
  • S10 M01 domain analysis & architecture design -- the bio's center sentence is the most compressed possible version of your domain positioning; producing it is the same skill applied to yourself.

The bio's hardest transfer is the honesty move -- saying "backend engineer who has shipped one distributed system" rather than "distributed systems engineer" when the evidence has not yet matured. Senior readers respect the first; the second collapses on contact.

A second transfer worth naming: the bio rewards range. A person who can credibly say "backend with distributed-systems adjacency, learning compilers on the side" has a more distinctive bio than one who picks a single phrase and sands every edge off. The degree was deliberately broad; the bio should show the shape the breadth produced, not hide it.

See also (integrative)​

Source Backbone​

Portfolio assessment packages evidence from the whole curriculum. These books provide the technical and professional backbone for the narrative.