How to communicate effectively as a developer
karlsutt.com
How to communicate effectively as a developer
1–10 of 222 posts
Re: How to communicate effectively as a developer
#2Very good old thread on HN on similar lines (Ask HN: How to speak like a leader, not like an engineer?)
Re: How to communicate effectively as a developer
#3The difficult bit here is the tendency for developers to detest these parts of the job. In my experience, most developers would prefer nothing more than to write code in a cave, never to share a word with anyone. Reviewing a PR, writing documentation, and sharing knowledge are all things taking time away from their passion.
I think this is the origin for much of the friction we experience in collaboration and documentation. It’s easy to build something, ship it, and move on. That’s the dream we are sold as well: changing the world, one line of code at a time, from our basements.
I would love to see more focus on writing in our industry. Unfortunately, I haven’t experienced much improvement here in the last decade of working in the industry, across several organizations.
The writers among us are quite the minority.
Re: How to communicate effectively as a developer
#4The difficult bit here is the tendency for developers to detest these parts of the job. In my experience, most developers would prefer nothing more than to write code in a cave, never to share a word with anyone. Reviewing a PR, writing documentation, and sharing knowledge are all things taking time away from their passion. I think this is the origin for much of the friction we experience in collaboration and documen…
Seems like a pretty significant opportunity to level up for those willing?
Re: How to communicate effectively as a developer
#5The post begins with a preface about promotions for leadership from the Csuite.
But I argue most Csuite and leaders are horrible at this too; I can't tell you how many all hands or emails I've been at where leaders use the abbreviations ELT, LT, ET, Csuite to refer to themselves -- and then use abbreviations for their move-the-needle projects and expect everyone in the room to know what they mean.
Clear communication is great, especially in the remote world or when dealing with complex situations. But this isn't a trait that leaders have more than developers, and it's not a trait that particularly gets you outside the development track.
Frankly, Ruby on Rails - and Rspec provide an example that developers should be very verbose -- in their method names, their file names, the description, background, context, and specific examples..
Re: How to communicate effectively as a developer
#6The difficult bit here is the tendency for developers to detest these parts of the job. In my experience, most developers would prefer nothing more than to write code in a cave, never to share a word with anyone. Reviewing a PR, writing documentation, and sharing knowledge are all things taking time away from their passion. I think this is the origin for much of the friction we experience in collaboration and documen…
Seems like a pretty significant opportunity to level up for those willing?
Certainly. I’ve leaned into it, when given the chance.
As the author writes, it definitely makes you stand out, if you are willing.
Re: How to communicate effectively as a developer
#7This is one of the more critical issues of our industry, of our entire society actually.
Re: How to communicate effectively as a developer
#8The difficult bit here is the tendency for developers to detest these parts of the job. In my experience, most developers would prefer nothing more than to write code in a cave, never to share a word with anyone. Reviewing a PR, writing documentation, and sharing knowledge are all things taking time away from their passion. I think this is the origin for much of the friction we experience in collaboration and documen…
Personal opinion or anecdata:
Is it possible that communication is "detested" because it's not valued within the developer group? Many times, when someone speaks of a 10x software engineer, the gut feeling is of someone that provides the output (measurable in code) of 10 developers, not that he's able to have an impact in the organization through communication as 10 developers (breaking silo-s, syncing teams, etc), although this might be closer to the truth and what the duties of some staff and principal level developers includes.
In addition, rarely communication is valued within the companies where we work. Most aspects of documentation, whether vocal or written, are hard to measure and as such are ignored when an evaluation of the "worth" of an IC is done.
Personally, I think communication is relevant, but I also think that it's hard for developers to resist the sculpting that companies deliver to the employees on what is relevant in this field.
Re: How to communicate effectively as a developer
#9The difficult bit here is the tendency for developers to detest these parts of the job. In my experience, most developers would prefer nothing more than to write code in a cave, never to share a word with anyone. Reviewing a PR, writing documentation, and sharing knowledge are all things taking time away from their passion. I think this is the origin for much of the friction we experience in collaboration and documen…
> Reviewing a PR, writing documentation, and sharing knowledge are all things taking time away from their passion.
They have to write the code because that's what is demanded of them. If management would prioritize communication they would get more of it.
Re: How to communicate effectively as a developer
#10The post begins with a preface about promotions for leadership from the Csuite. But I argue most Csuite and leaders are horrible at this too; I can't tell you how many all hands or emails I've been at where leaders use the abbreviations ELT, LT, ET, Csuite to refer to themselves -- and then use abbreviations for their move-the-needle projects and expect everyone in the room to know what they mean. Clear communication…
> Frankly, Ruby on Rails - and Rspec provide an example that developers should be very verbose -- in their method names, their file names, the description, background, context, and specific examples..
Very interesting. Any practical example from said codebases?