Build something useful

When I look at a project, the first thing I want to know is how it holds up when I actually use it. Can I get it running? Does the setup break somewhere stupid? When something blows up, can I figure out what happened? Without those answers, a long feature list in the README doesn't mean much.

Yusuf İpek writes about going a little beyond what people expect from your work ^[1]. Thinking it through. Getting better at it. When I apply that idea to software, finishing the part left hanging comes to mind before adding another feature.

When you say it works #

Say you write a tool. It runs on your machine, but someone else installs it and it crashes because a setting is missing. Then you have to explain which setting they need. The code might technically work. But part of the solution is still sitting in your head.

An error message that names the missing setting, a setup guide you've actually tried, or a sensible default can be more useful than another feature. The user might never have asked for any of that. They shouldn't have to predict where they'll get stuck. I built the thing; I can do some of the thinking here too.

That's what I take providing extra value to mean: accounting for the part of the job that happens on the other person's end. A script that removes a repetitive manual task can do more for someone than ten settings screens. An explanation that saves them from asking the same question again does something useful too.

Putting in hours is easy #

Sinking hours into something doesn't make it good. You can keep repeating the same mistake and call that practice.

A meta-analysis of deliberate practice and performance found that the relationship varies across fields ^[2]. I wouldn't read that as a promise that whoever puts in more work wins. The amount of effort alone doesn't explain the outcome.

If I spend all my time reading a tool's documentation, I still don't know whether I can do anything with it. I'd rather build something small, see where I get stuck, look into that part, and try again. That gives what I'm reading some context. I don't want learning to become an endless preparation phase either.

The same goes for feedback. If someone gets stuck during setup, saying “works on my machine” gets us nowhere. I need to see where they got stuck. Sometimes the thing that needs fixing isn't even code. It's a bad assumption or two unclear sentences.

Who's going to pay you back? #

I'm less comfortable with the source article's suggestion that the value you provide will eventually come back to you ^[1]. Good work can go unnoticed. You can build something very well that nobody needs. Someone can benefit from what you made and give you nothing in return. There's no automatic fairness mechanism running in the background.

So I want to know why I'm doing the work. Am I solving my own problem, learning something, or trying to make money? Each calls for a different calculation. If I keep expanding the scope just to get noticed, I can end up never finishing the thing. My time has to count too.

Still, I don't like doing a half-assed job. If I choose to build something, I want to take it far enough that someone else can actually use it. I don't need to add every idea or solve every possible case. It can be small. It should do its job properly and be clear about its limits.