Put yourself in their shoes, they want you to understand the benefits of in person communication, so they schedule meeting after meeting with you to talk about it. You are immediately fed up because you actually do already understand the benefits, and all these meetings are a waste of time.

Wouldn't you rather they demonstrate that they understand your point of view by writing up a document, or sharing an article, describing the benefits of in person communication that you could consider on your own time?

I'll also say, one of the big benefits of in person communication is getting real time feedback on body language and tone which tell you how the other person feels about what you are saying. If that's not something you care to do in this instance, when it's so important for you to gauge their opinions on it, is it any surprise that they think even more written communication will only put the team even more out of sync?

The goal of my comment wasn't to document every attempt I made in the last months to convince them that writing some things down would be beneficial for the team. I do speak with them, we have video calls and we also talked about this topic multiple times.

I wanted to point out that it's a funny experience when you send a document to someone with the purpose of providing them a great overview, highlighting the benefits of these design docs... And nobody reads them.

I already understand the benefits of in person communication, I don't want to eradicate video calls, I'd just prefer to write our decisions down so that other people who were not part of a decision can read these docs and join later.

In the end, I understand that I'm trying to change the status quo and change the team culture, I know it's a hard thing to do, and I get it that it will take a while.

I doubt that. Mostly they just want to punt responsibility. (I've been in these shoes many times.)

A written record trail means the buck eventually stops somewhere. Talking it through without writing it down means you have plausible deniability.

At its best, it allows the author to articulate their thoughts and share it widely for readers to consume and archive efficiently.

At its worst, the author writes an unreadable polemic without any thought of the audience. To the writer, their point is clear, obvious, and unarguable. To the reader, it’s a muddled, angry rant. The readers then type their own polemics in response, disingenuously cherry-picking and taking phrases out of context. And on it goes.

Not all written conversations look like this, but a lot do.

I call it "concrete galoshes." The structure can become more important than the project.

That said, not having a structure can be absolutely deadly. It's not for the faint of heart.

I seldom write down a detailed project plan (I write about that here[1]. Feel free to not read it, as well). Instead, my projects start with what I call a "napkin sketch," and evolve, as they progress. The results can be amazing, but I also end up backtracking a lot, and tossing out a lot of code.

I feel that you can't work the way I work, unless you are highly experienced (I've been at it over 30 years). I make big decisions, on the fly, and I need to have a really clear idea of the ramifications of these decisions. Often, the devil is in the details. It's quite possible to decide to do something one way, and get there, and then realize that a corner case makes the design unusable, and/or downright dangerous.

I'm not a fan of "design by buzzword." Modern techniques are often marvelous, but they can be unsuitable for some applications. Having a toolbox available, that includes a wide range of options, is invaluable.

I am a fan of early, high-quality usable product. One of my techniques, is to leverage Apple’s TestFlight beta service, as early as possible. This allows non-tech stakeholders to have meaningful say in the project. Screenshots and interaction diagrams are fairly useless. They take a lot of time (and expense) to create, and no one reads them. They also tend to add unproductive rigidity to the project.

[0] https://littlegreenviper.com/miscellany/concrete-galoshes/

[1] https://littlegreenviper.com/miscellany/evolutionary-design-...

This is fine for a sketch, a prototype, or an exploration. If you do this to produce production, critical path code, on a professional team with others you're selfish:

- The team, not only you, maintains this work that they have no agency over.

- You skipped feedback loops, and ignored the expertise of others.

- You've removed information sharing and visibility as you go into your cave and come back out with a solution.

> I feel that you can't work the way I work, unless you are highly experienced (I've been at it over 30 years). I make big decisions, on the fly, and I need to have a really clear idea of the ramifications of these decisions. Often, the devil is in the details.

Yes, the devil is in the details. Get some feedback from other people and stop designing by mistakes I happened to notice and catch. The ones you didn't notice? They're bugs your teammates fix.

Thanks for the insult. I appreciate the feedback.

I'll do me. You do you.

Have a nice day.

I think an interesting interview question would involve reading. "What were the last 3 things you have read to learn something?" "Do you read for enjoyment?" Based on the results you could group people in terms of how they relate to text.

Not a fan of the often repeated, flawed [1], "we have different modes of learning" mantra that sometimes comes with these discussions too. That myth is so hard to debunk likely because of this very issue!

1 - https://www.theatlantic.com/science/archive/2018/04/the-myth...

I have a slightly cynical take on why most programmers don’t read much: you can’t log “reading” into a time tracking system that has to add up to (at least) 40 hours a week.

I guess it makes a difference for consultants, but they can log it under unbillable ‘administrative actions’ if the very necessary ‘continuous education’ does not exist.

Spend more time making things more concise, and people will read.

Evidence: tiktok and other shorts