Writing code is a lot like writing an essay. You start off with an outline. Probably some bullet points or pseudo code. Maybe it’s all in your head or maybe it’s jotted down in a notebook — it doesn’t matter.

You move on to the first draft. It’s the shortest, simplest thing that works. It might not be pretty, but it gets the point across. You’re probably aware of its shortcomings and, more importantly, why they’re there. You just wanted to get something working. It can be refined later.

And that’s exactly what comes next: the finished product. It’s been polished, reviewed, edited, and debugged. It handles edge cases, provides sources, matches the house style, and is formatted properly. It’s the type of thing you’d use as an example of a good essay or chunk of code.

So essays and code are similar. They’re developed in similar fashions. Why does that matter to you, a software developer? Because you can use the same strategies writers use to improve your code.

Peer review is the de facto standard for reviewing written work, but I feel it’s underused for code. All too often programmers focus only on the output of their program. A good way to counteract this is is to publish the code itself in addition to showcasing the project. GitHub is helping make this a more common occurrence.

But becoming a better coder is even easier than that. All it takes it reading more code. Good writers read. A lot. Good coders should, too. The code you read doesn’t have to be useful, it just has to be interesting. It might come in handy later.

Fortunately, these two tips play nicely with each other. By publishing your code, you’re giving other developers more code to read. Their code will get better, and hopefully they’ll publish it too. Then you can learn from it.