Insightful article but surprised at the recommendations. Teamwork is important, yes... but smaller task sizes should have been mentioned too.
>Finally, after several weeks, the engineer shares an update, and one (or many) of the following bad things transpire:
Several weeks? If you are giving developers open-ended tasks that take weeks or more to complete, imo it's asking for things to go off the rails.
The most effective way I've found to avoid this situation is to ensure that worked assigned is broken down into tasks that are as small as possible.
When assigned work is limited to small deliverables you get smaller PRs, limited business logic changes to get lost in, fewer integration changes, etc.
I'm currently realizing that laying out a moderately complex PCB can take more than a week, but there's not much to be gained from breaking it up into smaller pieces. You kind of just have to do it.
Some problems are impossible to subdivide in a practical way. Having a team that can respond dynamically is really the only general solution I've ever seen.
>Finally, after several weeks, the engineer shares an update, and one (or many) of the following bad things transpire:
Several weeks? If you are giving developers open-ended tasks that take weeks or more to complete, imo it's asking for things to go off the rails.
The most effective way I've found to avoid this situation is to ensure that worked assigned is broken down into tasks that are as small as possible.
When assigned work is limited to small deliverables you get smaller PRs, limited business logic changes to get lost in, fewer integration changes, etc.