Thanks, great read! I definitely agree that communication is often a weak spot among developers, especially written forms of communication, and remote work just made it painfully obvious. I believe standardization or adoption of some common ground principles could help resolve this situation to a certain degree. Like, understanding that we work in teams and should work out common code patterns and styles and stick to it. I've had issues with this in the past in several companies. It is great to work alone in this regard, but having a few more heads to think about a problem certainly helps in more ways than one. It also creates issues like the one we're talking about - effective (sometimes written) communication.
Thanks. Your article gave me a few things to chew on in free time!
Software consultant. Bestselling Author. Loves rum, alt culture, games & metal.
Formerly Head of engineering, chief technical architect, head principal engineer, lead dev, etc.
Location
London, UK
Work
Independent Software Consultant at Electric Head Software
I feel like some of the idioms from successful open source projects can be taken through into a template of communication. Though heaven forbid not the entitlement ;)
Strong conventions over readmes, discoverability of ADRs and diagrams, and actually a lot of the "communication about code" works well. The more meta project / program management stuff I feel is the realm of product management - so should be captured in things like living product canvases.
Certainly my personal take :)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Thanks, great read! I definitely agree that communication is often a weak spot among developers, especially written forms of communication, and remote work just made it painfully obvious. I believe standardization or adoption of some common ground principles could help resolve this situation to a certain degree. Like, understanding that we work in teams and should work out common code patterns and styles and stick to it. I've had issues with this in the past in several companies. It is great to work alone in this regard, but having a few more heads to think about a problem certainly helps in more ways than one. It also creates issues like the one we're talking about - effective (sometimes written) communication.
Thanks. Your article gave me a few things to chew on in free time!
[EDIT: IDIOMS not idiots ;) ]
I feel like some of the idioms from successful open source projects can be taken through into a template of communication. Though heaven forbid not the entitlement ;)
Strong conventions over readmes, discoverability of ADRs and diagrams, and actually a lot of the "communication about code" works well. The more meta project / program management stuff I feel is the realm of product management - so should be captured in things like living product canvases.
Certainly my personal take :)