Julia Evans

Release it, then build it

I did a cool fun exercise yesterday. I was writing a design document (which I am learning to like doing).

To start it out, I wrote a “goals” section. But! Instead of writing down a list of goals, instead I wrote a release email (“hi everyone! Today we’re announcing [cool new feature]. This is what we did! This is why we did it! This is how you use it!“)

I found this pretty fun to write (releasing things is fun!) and I think it was a reasonable way to explain the project’s goals at a high level in a clear way. For me I think this is kind of a weird brain hack – I sort of hate writing down lists of project goals, but I love writing emails and blog posts that explain cool new features to people.

some things that I think are better about this than just writing a set of goals

  • it’s fun (for me)
  • it forces you to write down a narrative around your end goals, consider your target audience, and explain why what you’re doing is important
  • it helps me feel more energetic about the project (“oh wow this is a good useful thing!”)
  • it’s (possibly) easier for people to read and understand than a list of abstract goals

Also I immediately got a bunch of helpful comments on the idea and some of the implementation challenges we’d need to tackle! That was great.

(This is not at all a novel idea, if you google “documentation driven development” you can read all kinds of people talking about similar things. But I like it!)

Why do UDP packets get dropped? How do you decide what to work on?