We're surrounded by people telling us that software design comes from
requirements, and that code comes from design. However in the real world,
particularly in hobby coding, it's very common for software to grow
"organically" from the particular itches one or two people choose to scratch.

The result of this is that software, particularly at the surface, is almost
entirely there to satisfy its contributors. Fortunately for the majority of us
that means that early users of the software get to shape it which might mean
that it meets our needs too. The better software is written by people who
actually spend time working out what their users need and writing for that,
rather than for themselves.

This issue can go beneath the surface too. It's very common to find that
internal APIs in software projects exist only to satisfy the author and thus
the code being written. It's rare to find a more complete API than the author
themselves needs, unless the author is designing an API for others to use (and
frankly even then it can be patchy). This is so common that even when you're
aware that it happens you can fall into the trap yourself.

For this week, I'd like you to go back to some of your software which you have
released (or if you haven't released any, some software you might one day want
to release) and look at its functionality. Consider if there might be gaps
which users would like to be filled, and look at making the codebase coherent
inside and out. Then file some bugs, make some kanban cards, or whatever you
need to let yourself know what you need to do. If you're feeling energetic
then make the changes too.