3 ms·

I was hoping this would discuss how he chooses which features to build. Unfortunately, that is not what this is. It is a description of a pretty rigorous devel

• Forge36 5y ago
  An example of a well documented "here's roughly how I do it" post with some rational on how they documented and why they have a preference. Having something like this is useful for a team as it helps communicate where you are, what you're working on, and avoids butting heads over process differences being surprises. It can also help with onboarding as the steps are written out and can reduce back-and-forth and help focus on the issue (whether it's an enhancement or a problem).
• simonw 5y ago
  I wish I had a good answer for that question! I use my projects a lot, so most of my feature ideas come from scratching my own itches. A few come in as feature requests from other users. Then I file everything as issues, and keep an eye out for things where I can think I can get a lot of value for the smallest possible amount of work. I mostly work on things where I think I can get to a working version in less than a few hours. This keeps me engaged and churns our a lot of useful stuff, but it can get in the way of the longer projects that would add more value if could dedicate the time to them! So I'm still very much trying to figure this out. The hardest problem in tech is picking the right thing to work on next.