Programmer’s Career is open to submissions from engineers who have shipped and maintained real systems and hold an opinion they can defend. If that is you, we would like to read your work.
Get Jacklyn Parrish’s stories in your inbox
Join Medium for free to get updates from this writer.
We favor a sharp, practitioner point of view over neutral explainers — a piece that argues something and backs it up, not a summary of what everyone already agrees on. The best writing here reads like a smart colleague telling you something they learned the hard way.
1. What we publish
Three lanes:
Go, backend, and systems — real engineering and hard-won judgment, not tutorials rephrased from the docs.
The developer’s career — the parts nobody writes into the job description: on-call, code review, debugging, technical judgment, and working with (and around) AI tools.
AI for engineers — building with LLMs and agents from the point of view of someone who has to operate what they ship.
2. What makes a piece a fit
A defensible claim. Lead with a thesis or a contrast, not a label. “Go Is Memory-Safe. Your Code Isn’t.” beats “Understanding Memory Safety in Go.”
A first-person, practitioner voice. Show what it cost you to learn the thing — a real risk, a specific mistake, a decision you would make differently now.
Real specifics. A named tool, a dated incident, a concrete number, code you actually ran. Smooth, generic examples (“a fintech startup I worked with…”) read as filler.
A takeaway the reader keeps — a rule, a mental model, a decision framework — not a generic “in conclusion.”
3. Format
Title and subtitle are a pair (claim + detail, or question + answer) and must not restate each other. Title case, tight (aim under ~70 characters), no clickbait or shock words.
Open with a hook — a problem, a question, a surprising fact. Never “In this article we will…”.
Use section headings for the body. Break long paragraphs; white space is what keeps readers past the first screen.
Code is welcome when it earns its place — short, runnable, briefly explained. Long code belongs in a GitHub gist.
Cite your primary sources honestly — official docs, RFCs, specs, the original research or announcement. Link the real source, not a secondary blog that summarized it.
Length: quality over count. ~1,500+ words is typical, but a tight 900-word argument beats a padded 2,500.
One clear cover image, chosen in the editor.
4. What we do not accept
Pure news recaps, or “polished summaries” of someone else’s post with no added lens of your own.
Thin listicles (“10 VS Code Extensions You Must Try”) with no argument and no concrete artifact.
Clickbait, rage-bait, or sensational titles — they also hurt distribution and Boost eligibility.
AI-generated slop: over-symmetric, hedged, “time will tell” prose with no author stake. The test we use: if this could have been written by a model from the same source without your real experience, it is not for us.
Undisclosed AI-written pieces passed off as your own. Use the tools; own the result; write like a specific human.
5. How to submit
Request to become a writer, then submit your draft through the submission queue — unpublished (please don’t publish it elsewhere first).
Expect a response within about a week.
We edit lightly for the above — voice, structure, a stronger title — and will flag anything that needs a fix from you before it runs.
We read everything. A sharp, honest, well-argued piece from an engineer who has actually done the work is exactly what we are looking for. Send it over.
