Simple lessons learned about building things

⎈ Reinventing the wheel is sometimes a good idea

One of the stock critiques for any new project is that it’s been done before. You’re working on a new module, format, etc: what about this existing format?

1. Contributing to existing projects is often impossible if your vision is different from those of the maintainers, your changes are too large, or they’re absent.
2. Even if a problem is “solved” by an existing project, it can often be solved better, faster, in fewer lines of code, or with more documentation.
3. Sometimes writing the thing is the best way to learn about the solution. It’s best to develop the skill of reading code and understanding it, but usually the existing project is not written clearly.

✈︎ Few open source projects attain escape velocity

Most projects attract neither users nor contributors and are forgotten within a year of their development.

Some lucky projects acquire users.

Only the very luckiest projects get contributors, probably less than 1% of projects. These have more than one maintainer who really feels continuing ownership and has the time to contribute, and the open source dream can be achieved.

Most projects will cost you time. Your responsibilities to maintain them and their users will add up. The more things you create, the more time you spend helping users and doing their bidding, and less time you have to create new things.

☞ The ultimate skill is knowing what to do

Your ability to write code quickly or answer issues or anything else doesn’t matter if you don’t know what to do, and people don’t start out knowing what to do. The experienced builder knows what to prioritize when, and this is what make them effective.

Optimize for performance when you need to. Write minimal docs and expand them once the project is ready. Avoid implementing anything that isn’t necessary. If you expand the mission of a project, do so knowing that it’ll cost time and could sacrifice focus.

Most importantly, don’t build things that are impossible or that you’re sure will turn out bad just because that’s what the plan entails: change the plan and build possible, good things.

✎ Read more than you write

Learn to dig into codebases, read code, and understand other people’s styles, and you’ll save yourself thousands of annoying back-and-forth conversations.

Research is underrated. Computer Science history is short, but many problems have established, proven solutions. Knowing those solutions and the principles with which they were solved will give you the power of the ancients.