3 ms·

Many comments are focusing on kanban procedures, but the most important parts of solo development for me are social milestones. For example... * Who will I sho

by closed 7y ago

Many comments are focusing on kanban procedures, but the most important parts of solo development for me are social milestones. For example... * Who will I show X feature to? * When will I show it to them? * Can I show them a draft? To me, the biggest risk of solo development is not how I manage a todo list, but that I'll build the wrong thing, because I waited to get feedback. Some things that have helped me a lot... * set up a time to show someone your progress on feature X before you feel totally ready to. * ask someone to try and pick up and tweak some layer of your code (or pair with them) * if you are developing a library--record hour long screencasts where you use it in a realistic way. Prioritize issues where you say, "oh, I should fix that...". Repeat but with another person driving. I use github projects and a calendar (the calendar appointments feel more important!)

lliamander 7y ago
This is really good advice even if you are not a solo dev. A lot of devs that I have worked with (and this includes me at times) come with the expectation that they will be handed a task with a list of requirements, and all they have to do is check off the boxes and turn in the code. If QA found no bugs, then it's good. Even when things really are that clear cut, junior developers still often need a lot of feedback that they are on the right track. Part of maturing out of that initial stage comes from when you can autonomously take a well defined task, break it down into steps, and execute it. Maturing to the next stage requires that you be comfortable working in situations where the requirements are not clear or set in stone. At that point, your objective is not merely compliance with the spec (if there even is one) but that the code solves the problem as intended. Since developers are rarely in a situation to determine that for themselves, you have to become comfortable again with asking for feedback.
- closed 7y ago
  That makes a lot of sense! > Part of maturing out of that initial stage comes from when you can autonomously take a well defined task, break it down into steps, and execute it. It seems like this is the scariest part--since often whether a task is well defined feels more like an assumption. In a lot of ways, I think this is the value of social approaches--you have to answer, "how could I convince so-and-so that this is well defined?"
pezo1919 7y ago
On validation: totally! Its nice to have a set of people who use your app regularly or at least at times you ask a related question. Many times the last, finishing idea of a feature came from a "tester".
drums8787 7y ago
100%. I'm essentially solo in a larger group of "stakeholders" and shoot & share videos on a semi-daily basis to verify progress. More frequent dependent on the complexity & uncertainty. But I try not to overestimate my own certainty on a feature. People generally appreciate being kept in the loop, and that they can review on their own time. It also helps me to drive towards a level of completeness that I can show something in a 1-2 min video.

by closed 7y ago

lliamander 7y ago

This is really good advice even if you are not a solo dev. A lot of devs that I have worked with (and this includes me at times) come with the expectation that they will be handed a task with a list of requirements, and all they have to do is check off the boxes and turn in the code. If QA found no bugs, then it's good. Even when things really are that clear cut, junior developers still often need a lot of feedback that they are on the right track. Part of maturing out of that initial stage comes from when you can autonomously take a well defined task, break it down into steps, and execute it. Maturing to the next stage requires that you be comfortable working in situations where the requirements are not clear or set in stone. At that point, your objective is not merely compliance with the spec (if there even is one) but that the code solves the problem as intended. Since developers are rarely in a situation to determine that for themselves, you have to become comfortable again with asking for feedback.

closed 7y ago
That makes a lot of sense! > Part of maturing out of that initial stage comes from when you can autonomously take a well defined task, break it down into steps, and execute it. It seems like this is the scariest part--since often whether a task is well defined feels more like an assumption. In a lot of ways, I think this is the value of social approaches--you have to answer, "how could I convince so-and-so that this is well defined?"

pezo1919 7y ago

On validation: totally! Its nice to have a set of people who use your app regularly or at least at times you ask a related question. Many times the last, finishing idea of a feature came from a "tester".

drums8787 7y ago

100%. I'm essentially solo in a larger group of "stakeholders" and shoot & share videos on a semi-daily basis to verify progress. More frequent dependent on the complexity & uncertainty. But I try not to overestimate my own certainty on a feature. People generally appreciate being kept in the loop, and that they can review on their own time. It also helps me to drive towards a level of completeness that I can show something in a 1-2 min video.