3 ms·
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
by 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 agoThat 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?"