 index

Making Software

I’m best known for being a founding employee and Principal Engineer at Slack, which I left in 2023 after eleven great years.

I helped grow the product from 0 to 10s of millions of users, and the company from 8 to over 4,000 people, committing about 1 million lines of code along the way.

I’m an investor in The Browser Company and am open to new seed investment opportunities.

Erich Dieckmann – Design development of a metal tube chair

Right now I’m writing Building Slack with my friend Ali Rayl. Stories of building Slack — the company, the product, the business, and the culture — told by two employees who were around for the entire journey.




I’m also building Math Magic, an iPad app for kids to practice math.




Some posts I’ve written as an engineer & product designer:
How big technical changes happen at Slack A framework for making technical investments on a large engineering team. With Keith Adams.

When a rewrite isn’t: rebuilding Slack on the desktop The Ship of Theseus as software migration metaphor. With Mark Christian.
The story of Slack Clips A case study of our iterative, prototype-oriented design process. With Anna Niess and Pedro Carmo.

A faster, smarter Quick SwitcherMaking Slack’s best navigation method smarter and quicker. With Dio Brito, Patrick Kane, and Kyle Stetz.
Some popular Twitter threads I’ve posted about Slack:
Slack’s secret menu (tips and tricks)
Slack’s notification workflow diagram
Introducing “Later”
7 year anniversary thread

And a short story about pivoting from a failed game to a unicorn startup: The death of Glitch, the birth of Slack.



A program, we must remember, is both a programmer’s series of instructions to the computer, and the resulting program’s series of instructions to its users.  The instructions to the computer are defined by syntax, while the instructions to the users are defined by user interfaces.

In well-designed software, the instructions to the user tell a clear story of the world the programmer is trying to achieve, though the best ones tend to maintain some ambiguity.  They tell a user to communicate publicly in 140 characters, or to edit an encyclopedia entry, but they don’t specify which characters or which entry. The magic happens when a well-told story meets an imaginative set of users.

And so, the art of software becomes the art of coming up with a beautiful story of a world that could exist, and then telling that story in code (half of the story anyway) to the right set of users.

To such people there is tremendous power, for programs are more direct than poetry.  They act on the world.  They give a framework not just for human thought, but for human behavior. The stories that these programmers tell, if they tell them well, are likely to become realities.

Sep Kamvar