62. Building a Public Technical Identity
62.1GitHub
Your GitHub is your CV's load-bearing wall — quantum hiring reads it first. Standards that matter: pinned repos that run (one-command reproduce, Ch. 54.9's checklist — a repo that doesn't run is a negative signal), READMEs that state claims and results (not just installation), tests that pass in CI, and honest commit history showing how you work. Content strategy: three flagship artifacts beat thirty repos — the Ch. 17 simulator, the Ch. 46 compiler, the Ch. 37 decoder or Ch. 53 reproductions; make each a maintained project with issues, releases, and a write-up, not a homework dump. Housekeeping that reads as professionalism: profile README orienting visitors to the flagships, descriptive repo names, and LICENSE files (MIT/Apache) — unlicensed code can't be safely reused, so it can't be safely evaluated.
62.2Technical Writing
The most underinvested skill in engineering hiring, and quantum's scarcest: the field runs on papers, roadmaps, and design docs, and engineers who write clearly are disproportionately trusted. The training path: write publicly on a cadence (biweekly beats brilliant-monthly), on topics one notch above your comfort (teaching consolidates — Part II's mental model is your notes, perfected), with the Ch. 52 reading method feeding the input. Forms, in ascending effort: explainer posts (a concept you just learned, tested by whether a peer understands it), experiment reports (Ch. 54's format, published — negative results included), reproduction write-ups (Ch. 53.8), and design documents (your Ch. 17/46 projects' architecture — the document that most resembles paid work). Style: the honest engineering tone of this book — numbers, error bars, caveats — which in this field is a brand.
62.3Research Notes
Publish your lab notebook — the working document, lightly edited: what you tried, what failed, what surprised you (Ch. 54's surprises file, 58.6's anomalies). Formats: a notes/ directory in each project repo (timestamped markdown), or a public log (the "research log" genre — several notable quantum careers were launched this way). Why it works: notes demonstrate the process credentials can't — experimental judgment in action (Ch. 58.4), honest treatment of negative results, and the daily texture of scientific work; a hiring manager reading three months of your notes knows more about you than any interview. Discipline: dated, honest (never edited to look prescient), and specific (numbers, seeds, error messages). The notes are also your memory — Ch. 55.3's friction journal and 62.8's blog posts are both mined from them.
62.4Reproducible Notebooks
The hybrid artifact: Jupyter notebooks that tell a story and run — the field's working medium for tutorials, reproductions, and demos. Professional standards: run top-to-bottom on a clean kernel before publishing ("Restart & Run All" as a release gate), pin dependencies (a notebook that breaks in six months was never reproducible), narrative-first structure (each section: question → method → result → interpretation — Ch. 54's skeleton), and honestly-labeled compute requirements. Where to host: repo (canonical), with rendered copies on nbviewer/Colab/Binder for zero-friction reading — the friction you remove is readers you gain. Content: your Ch. 53 reproductions as notebooks are double credit — a reproduction and a demonstration of reproducibility craft; textbook derivations instantiated at small n (Ch. 52.5's method, published) fill gaps the field leaves.
62.5Open-Source Contributions
The apprenticeship the field actually offers. The ladder, honestly: (1) docs and examples — genuinely valued (every quantum SDK is docs-hungry), zero-barrier, and teaches you the codebase; (2) good-first-issues — real but competitive; the effective move is picking a component you use (your Ch. 17 simulator found an Aer edge case? that's an issue and the fix), (3) sustained component ownership — answer issues in your component, review PRs, become the name the maintainers know; (4) committership — which in quantum's OSS ecosystem (Qiskit, Cirq, PennyLane, stim, PyZX) is a professional credential recognized worldwide, affiliation-free. Etiquette that matters: small PRs, tests included, patient with review cycles, and issues that are bug reports (minimal reproducer, version, expectation) not complaints. Three merged PRs in a quantum SDK outrank a certificate by an order of magnitude.
62.6Conference Participation
The field's gatherings: research conferences (QIP — theory; IEEE Quantum Week, TQC — broader; APS March Meeting — physics), industry events (Q2B), and workshops co-located with everything. How to participate from outside: many record talks (YouTube archives are a free education), posters have student-and-independent-friendly tracks, and IEEE Quantum Week explicitly includes industry/practitioner programming. The realistic ladder: watch archives (year 1) → submit a poster on your reproduction/project work (year 2 — Ch. 53.8's write-ups are poster-ready) → workshop papers → talks. The visa problem for Iran-based readers (Ch. 63.9): some venues are more attainable than others (location and sponsorship vary year to year — check early, and remote-attendance options have normalized post-2020). When you attend: the hallway track is the point — go with three specific questions for three specific people whose work you know.
62.7Research Correspondence
Email the authors. This is the field's open secret: quantum researchers answer thoughtful email from anyone, because good questions are rare and appreciated. What works: specific engagement with their paper (the Ch. 52 three-pass, done — "in Section 4, did you consider the correlated-error case? My reproduction at small scale suggests..."), attached evidence (your repo/notebook), a narrow ask (one question, not "mentor me"), and brevity. What doesn't: flattery-then-favor, requests for basic education (the textbook exists), or unverified claims (Ch. 59.5's protocol is your credibility). The compounding effect: three good exchanges and you have a correspondent; ten and you have a network; a network plus artifacts (62.1–62.5) and you have what affiliations purchase — introductions, feedback, collaboration — built by mail. Many of the field's notable careers from non-traditional backgrounds began exactly here.
62.8Technical Blogging
Your publication venue between notebooks and papers: the blog is where you become findable. Mechanics: static site or platform (Hugo/Astro on GitHub Pages — you built one for this book's site; the skills transfer — or a Substack-style newsletter for subscription mechanics), a cadence you sustain (biweekly, 45 minutes each, beats monthly brilliance), and posts that are durable (the explainer of a concept with a 2026-honest treatment keeps accumulating readers for years). Topics that work for your position: "I reproduced X, here's what the paper didn't say" (reproduction genre — uniquely available to you, valuable to everyone), stack explanations (Part XII's material, written well, is genuinely scarce), and honest negative results (Ch. 54's discipline, published). SEO of one: when someone googles your name before a call — and they will — the blog is what they find; curate it accordingly.
62.9Building Credibility Without Institutional Affiliation
The synthesis: affiliation substitutes for verification — "trust her, MIT does" — and your strategy is to supply verification directly. The verified-artifact stack: code that runs and is tested (62.1), reproductions that match published numbers within stated bounds (62.4), benchmarks run to Ch. 46.8's standard with error bars (62.2), open review in public (your OSS record, 62.5), and correspondence with named researchers who will vouch (62.7). Time discipline: credibility compounds on roughly an 18–36 month horizon — unglamorous, unavoidable, and front-loadable from anywhere, which is why this chapter precedes the relocation one. What breaks it: any single public overclaim (Ch. 58.7's decision standard applies publicly — the field's memory for hype is long) — and what accelerates it: consistent, boring, verifiable output. You are not asking to be believed; you are making belief checkable.