Email signature generator › Developer

What a developer should put in an email signature

Most professions ask the reader to take a claim on trust. A developer can point at work that can be read and run, which makes one line in the signature worth more than everything else in it.

The one link that matters

A code profile or a portfolio of shipped work is the only credential in this field that a reader can verify in thirty seconds. If you have public work, that link is the most valuable line in the signature and it should be the only link you include.

If your work is not public — which is true of most employed developers — then linking an empty profile is worse than linking nothing. An abandoned profile with three forks from four years ago actively works against you. In that case link nothing, or link a personal site if it says something.

The stack list problem

Signatures listing seven technologies are common and they do not work. React · Node · Kubernetes · Terraform · Go · PostgreSQL · AWS reads as a keyword list rather than as expertise, and it dates: the technologies you named two years ago now describe someone else.

If you want to signal a specialism, one phrase does it better than seven nouns. Backend, mostly Go says more than a list, because it admits a shape.

Contractors and the availability line

For a freelance developer, a line stating current availability — Available from March — is worth more than any technology list. It answers the question a prospective client has before they write, and it is the one piece of information that changes often enough to be genuinely useful.

The obligation is to keep it current. An availability line that is six months stale is a signal about how you handle detail.

Plain text and mailing lists

Developers correspond on mailing lists more than most professions, and many lists are plain text by convention or by rule. An HTML signature sent to a plain-text list is converted by stripping tags, which turns a table into a run-on line of words and marks you as someone who did not check.

Keep a plain-text signature — three lines, name, role, one URL — and use it for list traffic. Most clients let you set a different signature per account or per identity, which is enough if list mail comes through a separate address.

The delimiter convention

In plain-text mail there is a long-standing convention that a signature is introduced by two hyphens and a space on a line of their own. Clients that understand it will hide or grey the signature when quoting, which keeps threads clean. It costs one line and it is invisible to anyone who does not know it.

What to leave out

A GPG fingerprint, unless you actually receive encrypted mail. It is 40 characters of noise for a capability nearly nobody will use, and if someone does want your key they will fetch it from a keyserver. An ASCII art logo. A terminal prompt as decoration. All three are in-group signals that read as costume to anyone outside.

The plain-text version, written out

Three lines under a -- delimiter: name, role, one URL. Under 120 bytes, renders identically in every mail client and every list archive, and cannot be mangled because there is nothing to mangle.

Set it on the identity or account you use for list traffic. Thunderbird, Apple Mail and most desktop clients support a different signature per identity, which is enough to keep list mail plain and everything else formatted.

Why the HTML version still matters

Most of a developer's correspondence is not with mailing lists — it is with recruiters, clients, vendors and people outside engineering, who read mail in Outlook and Gmail. A single plain-text signature everywhere is a reasonable choice, and it forgoes the one link that does the work being visibly a link. Two signatures cost five minutes to set up.

The size, for once, is trivially small

Name, role and one link as text is under 200 bytes. There is no logo, no headshot and nothing to block, which makes a developer's signature the lightest in this whole set — and means the only decision left is which link goes in it.

Frequently asked questions