[HN Gopher] No, we won't have a video call for that
___________________________________________________________________
No, we won't have a video call for that
Author : anotherevan
Score : 332 points
Date : 2021-09-23 22:47 UTC (2 days ago)
(HTM) web link (xahteiwi.eu)
(TXT) w3m dump (xahteiwi.eu)
| Aeolun wrote:
| This really struck a chord wit me. But my biggest takeaway is
| that Slack DM's are not private any more.
| lordlic wrote:
| I just scanned this, but some of it seems _ludicrously_ wrong.
| Like rating chat a neutral face for "find" when honestly one of
| the biggest advantages to chat in my mind is being able to search
| for key terms long in the future and be able to turn up the exact
| transcript of the discussion you're thinking of. Or like this
| quote:
|
| > Using interactive chat is a good idea for the kind of
| communication that requires immediate, interactive mutual
| feedback from two or more participants. If that is not the case,
| chat is not a good idea.
|
| No. Just... no. This is so wrong it's absurd. The point of text
| chat instead of in-person chat is that it's asynchronous and it
| _doesn 't_ require immediate, interactive feedback. I'm honestly
| just baffled at how someone could actually use chat and come to
| this kind of conclusion.
| duckmysick wrote:
| I think neutral is a good rating for chat searchability. It's
| better than video or face to face chat. It's good for recalling
| the conversations you were part of. It's bad for discovering
| information you don't know about and you weren't part of.
| nzmsv wrote:
| The chat that doesn't require immediate feedback is called
| "email".
|
| Otherwise you are stuck with "hey, can you help?" with zero
| details for when you actually get to take a look. Then you have
| to say "yeah, what's wrong?" and wait another hour. A properly
| written email would have solved the issue in a tenth of the
| time.
| lordlic wrote:
| No, I'd argue that there's basically no use case for email
| beyond stuff that you want the other person to be able to
| ignore.
|
| If you're expecting a response, but don't care when it comes,
| that's ideal for chat.
| chrisweekly wrote:
| See also PG's classic "Maker's Schedule, Manager's Schedule"
|
| http://paulgraham.com/makersschedule.html
| pyrale wrote:
| In my experience, both asynchronous teams and teams of people
| doing highly synchronized work, some spending most of their time
| together in voice chats or calls have worked great.
|
| I appreciate the experience feedback from that article, but I
| wish some of the feedback was contextualized rather than
| presented as universal. The antithesis laid at the end of the
| talk helps a bit, but it is a bit reductive about the
| effectiveness being limited to ops.
| picodguyo wrote:
| Hard disagree here. In practice, corporate wikis are always
| graveyards of outdated and incomplete information. The process
| usually looks like this:
|
| 1. Someone is excited about a new project and creates a wiki page
| with a lot of aspirational introductory content and a sketch of
| the rest of the page with TBD everywhere
|
| 2. Author gets busy on other things, leaves the company, or the
| project quickly diverges from the original vision
|
| 3. The original page stays in the wiki, adding negative value
| Dudeman112 wrote:
| Documenting is like exercising or eating healthy: doing it an
| average of once per month isn't worth crap.
|
| It's not a problem with documenting stuff, it's a problem with
| corporations. Somehow very few companies have technical writers
| whose main job is keeping their docs healthy.
| Aeolun wrote:
| I think this strongly depends on how much time everyone spends
| on the wiki and how much love it is given in the first place.
|
| I've had companies where it is exactly as you say. Which is
| especially frustrating because a search for the term you need
| yields 19 graveyard pages and 1 actual result.
|
| But also companies where the wiki was a bastion of well kept
| and up to date information.
|
| What I think it mostly comes down to is structuring. If you
| have little wiki fiefdoms, where every project gets it's own
| page, and nobody gets to edit other projects, then you quickly
| end up with huge heaps of garbage.
|
| If there is one space that the entire company has access to,
| which is well organized, it's much easier to get rid of (or
| restore) information.
| natmaka wrote:
| Albeit I agree with the author on nearly every point, some
| challenges seem neglected.
|
| "Write. Things. Down." may let a a competitor obtain some
| company's efficient ways/tools, especially such information is
| shared among departments ("view permissions") and with the high
| employee turnover rate. Even if it is not a real risk (in most
| cases it IMHO isn't) some (especially among senior managers) will
| think it is, and fight against this convention.
|
| If you like the approach described in this article AND are able
| to hire you will probably describe your ways during job
| interviews, and in many ways attract candidates similar to
| yourself. Leading an old existing team not build by yourself
| towards this approach is a totally different matter because
| pertinent habits are among the most difficult to change.
|
| Most pertinent tools (wiki and bugtrackers alike) publish each
| piece of information's history (who wrote what/when). It
| sometimes becomes a metric: people committing numerous or very
| useful information obtain consideration. Many organizations,
| especially large ones, have people unable to produce such input
| BUT nonetheless useful as 'crossroads': they usually have all
| most recent important info and are also able to say who may
| answer to a question. Other ancillary challenges include shyness
| (some are able to talk or write a mail to a direct colleague but
| won't commit any potentially widely-read wiki article) and
| 'weird' syntax/orthograph.
| peakaboo wrote:
| What's up with this guy repeating what he says is not science so
| it could be wrong? Is he unaware that science is wrong all the
| time too?
|
| Science is not a religion! It bothers me how people think
| "science" is something not to be questioned when it's actually
| the opposite - always question science. Because not only are
| scientists funded by corporations with motives, they also like to
| get rich as much as politicians.
| theduder99 wrote:
| yep, global warming, no wait its global cooling, no wait back
| to warming now lets just rebrand as climate change so nobody
| can disagree with whichever direction we choose to go with this
| thing.
| alephu5 wrote:
| Everyone I know uses YouTube as a de facto reference. They don't
| read blogs, Wikipedia, news articles or company documentation,
| rather they look for explainer videos or tutorials.
|
| I mention that because I think it overflows into work
| interactions. I've had to deal with many complex problems,
| technically complex but also with business complexity needing
| collaboration to manage the objectives and risk. In these
| circumstances it really warrants a document or detailed email to
| tell others everything they need to know and consider, and yes
| it's going to require effort to absorb it. In recent years I've
| noticed that people almost never read these and ask for a video
| call. They want you to present it as if it were a YouTube video
| and you lose an hour trying to explain everything and losing much
| of it, because it's too much to absorb in real-time.
|
| Maybe I'm a bad writer but I think few would dispute that it's
| the best way to transfer a block of information. As a rule of
| thumb calls only make sense for Q & A or discussions.
| yarcob wrote:
| > Everyone I know uses YouTube as a de facto reference. They
| don't read blogs, Wikipedia, news articles or company
| documentation, rather they look for explainer videos or
| tutorials.
|
| This comes as a complete surprise to me because I don't know
| anybody who uses Youtube for technical information. Everyone I
| work with primarily uses Google or DuckDuckGo to find answers
| on blogs or on stack overflow. If that doesn't work they check
| the official docs.
| lotsofpulp wrote:
| Same for me. YouTube is for projects like car repair or home
| improvements.
| duped wrote:
| I've noticed this too but I don't think it's because of
| YouTube. I think some people just communicate differently.
|
| There are a few people on my team that won't engage with
| written communication. Similarly, I have difficulty with video
| communication. It's just something you need to look out for
| when hiring and building teams.
| 3np wrote:
| One thing I personally hard disagree with is the author's view on
| chat/DMs; that they are by default and expected to be synchronous
| and immediate.
|
| Unless urgency is indicated somehow, I see chat as asynchronous -
| an incoming question doesn't carry an expectation of immediate
| feedback. This is in contrast with, say, a phone call.
|
| Some of the negatives of chat-heavy comms disappear under that
| mode. Like, why does encrypted e-mail need to have benefits over
| chat (apart from the interoperability, maybe).
|
| Chat is new to society and we don't (yet) have strong cultural
| norms and expectations around how it should work. I think things
| like this are important to talk about when forming a team or
| starting to work on a project or in a new context.
| PeterisP wrote:
| I have an objection to the author's blanket disregard for "pings"
| in chat - while the request could/should be worded a bit more
| clearly than just "ping", IMHO they're a valid way of requesting
| if an opportunity for synchronous communication is available in
| the (not that rare!) cases where asynchronous communication would
| be worthless.
|
| If someone's blocking on some unclear thing which requires
| external input for progress, making an asynchronous request (i.e.
| writing the question directly) is not helpful since in such a
| case an answer is valuable if and only if it's synchronous.
| Writing a chat question that gets answered the next day has
| _negative_ value, since it has the extra cost of the answerer
| reading the question and preparing the (now useless) answer.
|
| If the other person is available for synchronous communication,
| that's great, there's an opportunity for a useful communication.
|
| If the other person is not available for synchronous
| communication right now, that's fine as well, but then the
| replacement is _not_ asynchronous communication with that person
| but instead something else that can actually be done right now -
| contacting someone else who is available, or doing some redundant
| experimentation /research, or just proceeding with an assumption
| that may later be falsified, etc, all of which aren't optimal but
| still clearly preferable to blocking until an asynchronous
| response arrives.
|
| Sure, things _can_ be done 100% asynchronously eventually, but
| that 's not an optimal flow, going 100% async requires giving up
| many opportunities for helpful communication. Especially in
| international organizations I've far too often seen things
| delayed by days or even weeks where literal ten minutes of a
| synchronous comms (no matter if it's a phone call or chat or
| video) was completely sufficient.
|
| Perhaps I'm looking at 100% async as an optimization on
| allocating time for communication that has some benefit of
| throughput - having more efficient schedules for people working -
| at a horrific sacrifice of latency - having much less effective
| schedules for resolving individual tasks.
|
| Pings would be useless (and I'd concede that even harmful) in a
| world where status indicators in a chat app reasonably match
| actual availability for synchronous communication right now, but
| I don't live in such a world, people are routinely marked as
| "active" while they're working in meetings or deep work and don't
| want to be disturbed, and the opposite way around; so there needs
| to be _some_ protocol of requesting synchronous communication -
| are there any ways that are substantially better than "pings"?
| Macha wrote:
| Even in the case where the explanation of the question is quite
| long, I think the onus is still on the asker to give
| information for the reciever to prioritise it. Because
| sometimes my availability for the discussion depends on how
| important that is versus my current task.
|
| Need help debugging your CI build while I'm just churning out
| unit tests for my run of the mill work? Sure, I'll take up that
| discussion.
|
| But hey, what if I'm working on a gethering data for a
| presentation to stakeholders tomorrow? Then your CI build has
| to wait.
|
| But wait, what if you're debugging production being down? Well
| then you know what, my feature can wait.
|
| So "I need help with <X> so that I can <Y>, are you around for
| a chat?" is ok. I can make a judgement call here and give you
| an answer.
|
| "Ping"/"yt"/"Can we talk?" is not. You give me no information
| to prioritise your request.
| PeterisP wrote:
| Okay, that's a good point, a "ping" with sufficient context
| about the priority is a clear improvement.
|
| I saw the original article's recommendation to add "no
| urgency" when appropriate, but the type of requests I was
| thinking about are those that actually are urgent but not
| that important, where it's no big deal if you can't answer
| right now, but then we'll proceed without your input at all
| instead of waiting for it.
| bananamerica wrote:
| One of the reasons for having a meeting is knowing that most
| people won't read or watch anything you send them, and even if
| they read they won't recall much. That is why in film school my
| teachers screened films in class instead of just assigning them.
| jasode wrote:
| The author wants to educate people on the benefits of (more) text
| communication, but I don't believe it will change minds.
|
| Reading the sibling comment from papaf[1] and also a previous
| reply to me by jakubp[2] about talking things out instead of
| email, it seems like the higher meta-analysis is that some people
| have a _predisposition_ to prefer synchronous (videoconference,
| phone call, cubicle visit) over asynchronous communication
| (email, chat).
|
| One group really prioritizes synchro comm for "emotional nuance"
| etc. The other group prioritizes written text's dense information
| content and searchability.
|
| So if the company has folks like papaf and jakubp, it doesn't
| matter if you have a blog article recommending structured emails
| over video calls. Some employees prefer not to communicate that
| way. In fact, the blog article just makes them express their
| disagreement with it. E.g. papaf saying we're not "efficient
| robots" and jakubp advising me that I should accommodate his
| communication style of in-person cubicle visits.
|
| To prevent clashing, I guess the higher-level advice is to hire a
| team where everybody likes to communicate the same way.
|
| [1] https://news.ycombinator.com/item?id=28651678
|
| [2] https://news.ycombinator.com/item?id=20583427
| tailspin2019 wrote:
| > The other group prioritizes written text's dense information
| content and searchability.
|
| I would add that the other group also likely prioritises focus,
| flow, blocks of uninterrupted time for deep work and minimising
| context switching. For me personally the text-based content and
| searchability is way down the list compared to keeping the
| focus on my core tasks.
|
| I think there is quite a lot more the author could touch on
| regarding the huge overhead and performance hit of context
| switching and the absolute importance of protecting your time
| against non-urgent interruptions if you're doing any kind of
| deep work. Makers vs managers schedule stuff. And yes, even
| managers should be doing deep work occasionally (I would argue
| often).
| madeofpalk wrote:
| "focus, flow, blocks of uninterrupted time for deep work" is
| always going to be relative and a function of the
| company/work itself, rather than communication method.
|
| I like a video call because I can block out that time and get
| the communication over, rather than struggling to discuss
| something over a longer period of time over async text chat.
|
| Of course this just goes back to the grandparent's point -
| its all subjective and depends on how the individuals and
| teams work. There is no One True Solution with how to
| communicate as a team.
| tailspin2019 wrote:
| > I like a video call because I can block out that time and
| get the communication over, rather than struggling to
| discuss something over a longer period of time over async
| text chat.
|
| Yep that's a fair point. I guess it depends on whether the
| nature of the communication is operations based or project
| based. For day-to-day operations where you may get lots of
| small queries and messages throughout the day, I vastly
| prefer text chat for this as opposed to someone calling me
| every 5 minutes, or sending a tonne of separate emails.
|
| For more structured meetings, project planning/reviews etc.
| then I totally agree that blocking at the time and having a
| call can be a better way to do it.
| birthday wrote:
| People get very confused when it comes async communication. In
| fact I have opted to stop calling it asynchronous communication
| and instead just talk about individual aspects of it and the
| benefits of those aspects in an applied manner at my company
| Over time you can slowly build people up to your level of
| understanding.
|
| If you are not a team lead or similar you are fighting an
| exhausting and losing battle. If you are in a lead position
| then you have the power to show others by focusing on your own
| team and getting your team on that level via coaching them
| multiple times per week. That said, without commitment from
| your manager or peer teams it will be extra hard even as a team
| lead.
|
| PS I'm in the coaching part right now with my team and have
| stopped calling it "asynchronous" communication.
| foxtacles wrote:
| I agree, this is my experience as well. At the extreme ends,
| some people absolutely require synchronous communication /
| social interaction to be productive, while others' performance
| (and sometimes happiness) depends on the absence thereof (often
| perceived as inefficient or even a waste of time). They are
| inherently at odds with each other.
|
| Personally I fall into the latter category and I do believe
| it's a better fit for a software engineering role in terms of
| getting things done, but I've also come to the realiziation
| that in our world, you'll eventually have to meet the others
| half-way. Hiring a team that shares the same communication
| style is often just too difficult (exacerbated by the fact many
| candidates aren't even self-aware enough to know which
| preferences they really have, or don't want to admit them).
| tarsinge wrote:
| I think we should nuance that a bit. Personally I'm an
| introvert, and naturally fall into the latter category like
| you. But at work, especially for management and direction, I
| find synchronous and social interactions way more efficient,
| allowing higher level discussions and vision and necessary to
| really move things between teams company wide. Written
| asynchronous communication seems more fit for intra team
| work, i.e. solidifying processes when the direction is clear.
| JJzD wrote:
| This is a great summary and would also explain the tendency
| to want to meet in response to a thought out document. The
| author has wrestled with the topic long enough to write out
| a specific document. The receiver of the document has not
| yet spent this time, and needs to understand broad
| outlines. Besides this, if there is a meeting of equals,
| they might bring something to the table, the author hasn't
| thought about, or did but dismissed it for undocumented
| reasons. Let alone the buy in factor of a shared product vs
| 'you go build this, off you go'
|
| I hate meetings for looking busy, but a 20 minute
| conversation can bring a week of work to actually implement
| the decision.
| fxtentacle wrote:
| You're absolutely right. That's why many companies will have
| weekly team calls and then someone will write down a transcript
| and email it to everyone. It's the best of both worlds, because
| you can react to emotional nuances, yet you still have an email
| that you can search for and re-read as a reference later.
| marcinzm wrote:
| >and searchability.
|
| This can be achieved with meeting notes. These can even be
| posted "publicly", potentially in a cleaned up form, in a wiki
| so future employees see them unlike an email chain.
| hutzlibu wrote:
| I like both and I guess many people, too. But it depends on the
| people involved.
|
| I think the big advantage of text is accountability.
|
| Lots of people say lots of things (the other person wants to
| hear) ... and remember only some of it. I wasted so much time
| relying and then discussing forgotten promises, where I wished
| have had that exchange via text. And I actually believe, this
| is a big (unconscious) reason for many avoid written
| communication. Talk is cheap.
| blowski wrote:
| You're totally right here. People want accountability because
| they want to increase honesty, which is obviously a worthy
| goal. But sometimes it backfires.
|
| If I'm going to be held to account for everything I say in a
| meeting, I will be more careful about what I say and how I
| say it. That sounds like a good thing. But I think out loud.
| I voice opinions that I don't necessarily hold to encourage
| others to voice theirs in a free-thinking conversation.
| People's immediate feedback allows me to rapidly change my
| thoughts - asking for short bits of feedback is normal
| verbally, but laborious in writing. Also, when writing, I
| self-censor ideas because they sound wrong - but someone
| might have taken inspiration from one of those wrong ideas
| and corrected it.
|
| The best medium in which to have a conversation thus depends
| on the participants, context and intent of that conversation.
| Closi wrote:
| Agree with this - and the other thing is subtle but it's
| about trust.
|
| If I am documenting things on emails just to create a paper
| trail for accountability, something about the culture in
| the company has probably gone awry and it means there is a
| lack of trust between people.
|
| Documentation shouldn't be a substitute for honest feedback
| and ensuring everyone does what they promise. (I'm not
| saying that tracking actions isn't a good thing to do - but
| my primary purpose is to help people remember what they
| said rather than to hold them to account).
| hutzlibu wrote:
| "People's immediate feedback allows me to rapidly change my
| thoughts - asking for short bits of feedback is normal
| verbally, but laborious in writing. "
|
| But that change of thought would be included. Important is,
| what everyone agrees to in the end.
|
| Also, keeping track of the back and forth is useful for
| credit assignment later.
| blowski wrote:
| Why do you need "credit assignment"?
| hutzlibu wrote:
| In those cases, someone claimed a idea as his work, when
| initially he opposed it.
| blowski wrote:
| If the culture you work involves people competing for
| credit, you've got bigger problems.
| GravitasFailure wrote:
| >One group really prioritizes synchro comm for "emotional
| nuance" etc. The other group prioritizes written text's dense
| information content and searchability.
|
| Don't forget the usefulness of email when you need the ability
| to reference past conversations. For some people, a faulty
| memory is a finely honed art.
| wirrbel wrote:
| that's why I send around meeting notes regularly. THEY hate
| it.
| Aeolun wrote:
| I like it. I can't be in all meetings all the time, but I
| _can_ read all the meeting notes and follow up if I have
| to.
|
| Unfortunately, nobody sents any meeting notes, and they
| decide things that later get cited as 'it was decided', and
| I have to track back through history (and a lot of
| unwilling people) to figure out that 'it' was decided by
| two PM's having a meeting at 12am with nobody relevant
| present.
|
| Who then tell me to be in meetings if I want to have any
| influence on their decisions.
| gtirloni wrote:
| I stopped doing that because people take it the wrong way.
| Initially, I was just trying to be helpful with the notes
| (so people wouldn't forget what was discussed, people who
| could participate could catch up, etc). But I started
| noticing some people were looking at the meeting notes as
| if I was holding a gun at their heads for what they said
| during the meetings.
| [deleted]
| commandlinefan wrote:
| > some people were looking at the meeting notes as if I
| was holding a gun at their heads
|
| Ok, so... I'm usually super cynical, but how do you know
| you're not projecting here? I know people that do this
| and as far as I can tell, they're always appreciated.
| More commonly I see people ignoring those summaries than
| being threatened by them.
| raverbashing wrote:
| It doesn't have to be "in your face" but it has to have
| the main points and especially the future action items
| people are taking
| nobody9999 wrote:
| >But I started noticing some people were looking at the
| meeting notes as if I was holding a gun at their heads
| for what they said during the meetings.
|
| My experience (as technical resource/lead and project
| manager) has been to make sure that meeting notes include
| all agenda items and the action items associated with
| them.
|
| _However_ , I always make explicit that this is _my_
| understanding and request feedback from _all_
| participants as to the accuracy, schedule and scope of
| action items.
|
| I suppose that comes from long experience where you're
| given _responsibility_ for ensuring the success of an
| effort /project but not given the concomitant _authority_
| to compel action.
|
| That requires consensus building and buy in from all
| stakeholders.
|
| Often, that's not an issue when the entire organization
| is focused on a singular product/service. But in large
| organizations, building consensus among the stakeholders
| is absolutely necessary for success.
|
| In smaller organizations this is less of an issue, as
| someone with authority over all aspects of cross-
| functional efforts is likely directly involved.
|
| As such, the metaphorical "this is going to be done. Do
| it now." coming from a person who can directly affect
| your compensation and continued employment is extremely
| effective.
|
| That's not so in large organizations where authority is
| more broadly distributed.
|
| It occurs to me that differences in the size and
| structure of an organization can have significant impact
| on how such processes evolve and either thrive or die.
| lbriner wrote:
| Meeting notes can easily become noise. One of the big
| dangers of meetings is spending lots of time talking and
| not making specific actions to make something happen.
| Instead of minutes, it would be better in my opinion to put
| any relevant points into the relevant tool: Trello, Jira,
| Teams Tasks or whatever gets used.
|
| It's then easy to continue working with, if you are a bit
| wrong, you don't need another email with corrections,
| someone can just edit the task details or add more to it.
| flohofwoe wrote:
| I bet this is exactly why some people prefer direct
| communication that doesn't leave a trace ;)
| gtirloni wrote:
| I agree. Every time something important starts getting
| discussed, people want to jump in a video call so every
| history is erased afterwards.
| lbriner wrote:
| That is a cynical assumption. I think in most cases,
| people don't want eternal back-and-forth that can happen
| with emails when it can make sense to have a single
| conversation where the objections can quickly be
| noted/considered and the subtlety can be understood.
|
| Of course, in some cases, this has disadvantages but like
| most things, we should avoid making such absolute
| statements and allow intelligent people to work out
| whether written or spoken is a better idea for each
| topic.
| prepend wrote:
| > Some employees prefer not to communicate that way.
|
| I think it depends on the purpose of the team as to whether
| people should change.
|
| I'm technology, if the purpose is to build things well then the
| people who like to emotionally nuance things in synchronous
| communication should do more async because that works better
| for building.
|
| It really frustrates me when I analyze a problem, thoughtfully
| write up a solution and send it out. And then someone (or
| several) wants to meet to talk about it.
|
| Then the meeting has nothing persistent than a feeling and the
| details get lost and a week later people forget the resolution.
| And want to meet again.
|
| I guess if there's no accretive development it doesn't matter,
| like sales or restaurants or whatever. But there seems to be a
| better way to design and execute complex things.
| jensensbutton wrote:
| > the people who like to emotionally nuance things in
| synchronous communication should do more async because that
| works better for building.
|
| Citation needed. Pretty much everything of any complexity
| that has been built to date, in human history (including
| software), was built with synchronous communication (not to
| say things aren't written, but things are ALWAYS discussed).
| prepend wrote:
| Let me clarify, I'm not saying that we should never
| synchronously communicate, but that it is not the sole or
| primary communication.
|
| My comment was about the tendency to avoid writing over
| speaking. I think we need lots of writing and some
| speaking.
|
| Software in particular is easier to "say it in code" than
| to just talk and talk and talk.
|
| I'd say my preference is write-up, then talk, then follow
| up with write-up.
|
| My complaint is the constant redirection to only talk and
| never write up.
| wpietri wrote:
| I agree with your point, but I also think more nuance is
| possible in structure.
|
| For me, sync and async are good for different kinds of things.
| So I think a good distributed team needs to get at least decent
| at both and uses them when they fit. We all know the horror of
| a meeting that could have been a memo. But we also know the
| horror of the interminable email thread that should have been a
| quick discussion.
| serial_dev wrote:
| > it doesn't matter if you have a blog article recommending
| structured emails over video calls
|
| Exactly! Funny thing is that if you send these people an
| article explaining the benefits of written docs (design docs,
| RFCs, proposals, any text document documenting a decision),
| they will just simply not read it.
|
| I'm on a team where I believe we started gigantic refactoring
| and redesigning projects without being clear on the goals, non-
| goals, and tradeoffs we take. I proposed that before we start
| working on something huge, we should write a short document
| where we explain what, how and why we want to do.
|
| I recommended them some articles, for example "Design Docs at
| Google" [1], and "Scaling Engineering Teams via RFCs: Writing
| Things Down" by Gergely Orosz [2], but I couldn't even convince
| them to read those articles...
|
| I didn't even send them my favorite posts about the Amazon
| 6-page memo, because I knew they'd dismiss the whole idea in a
| second (no matter if I told them that we could do "OurCompany
| 1-page memo").
|
| This lead me to the sad realization, that our team will never
| start "writing things down". In my opinion, it would force us
| to think things through, but it seems like they disagree, or
| they just don't care.
|
| My coworkers will not even read a 3-paragraph ticket, but
| they'd love to talk about the same ticket for an hour in a
| video call. Then in 3 weeks, nobody remembers anything anyway,
| and they discuss it again.
|
| [1] https://www.industrialempathy.com/posts/design-docs-at-
| googl...
|
| [2] https://blog.pragmaticengineer.com/scaling-engineering-
| teams...
| sul_tasto wrote:
| If you have time could you reference your favorite posts on
| the Amazon 6 page memo?
| sulZ wrote:
| I found this article on it:
| https://writingcooperative.com/the-anatomy-of-an-
| amazon-6-pa...
| jbverschoor wrote:
| Because most documents are not written to be read. The are
| written to have something published. Ego, status, whatever.
| Similar to over architecting.
|
| Spend more time making things more concise, and people will
| read.
|
| Evidence: tiktok and other shorts
| Aeolun wrote:
| Oh! We work in the same place! Or at least close enough that
| it doesn't matter what the actual name is.
| ChrisMarshallNY wrote:
| I wrote an article (since it's written, I don't expect it to
| be actually _read_ )[0] , about the importance of _not
| writing too much stuff down_ (Ironic, I know).
|
| 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-...
| ctvo wrote:
| > _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._
|
| 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.
| ChrisMarshallNY wrote:
| _> you 're selfish_
|
| Thanks for the insult. I appreciate the feedback.
|
| I'll do me. You do you.
|
| Have a nice day.
| upofadown wrote:
| Everyone that works in development is literate but not
| everyone that works in development has good reading
| comprehension or is good at generating meaningful prose at a
| keyboard. Many people who work in development just don't like
| to read and consider it a chore.
|
| 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.
| ctvo wrote:
| In my experience a key characteristic of a good software
| engineer is their ability to handle dense, technical texts.
| We do it all the time, from academic papers (less often) to
| documentation (every other hour). Not liking to read (?!),
| and thinking it's a chore, because we're only humans, will
| mean you won't do it unless forced and will either lack a
| deep understanding of a subject or reach for someone else
| to do it for you (RTFM).
|
| 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...
| darkerside wrote:
| You want to convince them, but you won't meet them on their
| terms to do so? Maybe you should try having a conversation
| with them about it instead. Actually, a series of
| conversations. And be patient because influencing other
| people's base assumptions takes time.
|
| 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?
| blowski wrote:
| This, I think, is at the root of the good and bad of
| written conversation.
|
| 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.
| otabdeveloper4 wrote:
| > they want you to understand the benefits of in person
| communication
|
| 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.
| serial_dev wrote:
| Thank you for your note, I'll keep it mind in case I try to
| get them to document things and / or read things.
|
| 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.
| darkerside wrote:
| Fair point, I'm sure there's a lot you are doing that
| didn't fit in the little white text box. Good luck!
| commandlinefan wrote:
| > I recommended them some articles
|
| 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.
| Aeolun wrote:
| You can log it under 'working on project xxx'? Literally
| all my time regardless of what I do goes under there.
|
| 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.
| atom_arranger wrote:
| This seems about right.
|
| Personally I dislike getting on calls for stuff. I think the
| clarity of text is much better, and the fact that it's
| asynchronous means I can look things up while responding,
| meaning my responses are more high quality.
|
| It's super frustrating being like this and then interacting
| with people who don't want to write things out clearly or don't
| want to read my responses, and then ask me to "hop on a call".
| blitzar wrote:
| 'Can you talk me through this document you sent me'.
|
| I might have limited my career progression briefly when I
| asked if they had read the document, then called them out on
| the lie - 'was the 2 paragraph summary at the start not
| clear'.
|
| I now put the summary in the email body as well, apparently
| it is easy to miss the heading _Summary_.
| hutzlibu wrote:
| "apparently it is easy to miss the heading Summary."
|
| It is, when you are not paying attention, because you are
| busy with lots of other stuff. So putting the summary in
| the email seems lile a working pragmatic approach.
| WesolyKubeczek wrote:
| It's almost like your busyness is paramount and the other
| person may never be busy in case you need to quick-
| question them at your whim.
| Aeolun wrote:
| If you have time to 'hop on a call' and discuss things
| you are clearly not busy.
| laserlight wrote:
| In that case they will be so busy that they are not even
| able to read the summary in the email. Busyness is an
| excuse.
| blitzar wrote:
| Allegedly they read the document, but somehow they didnt
| see the section at the start titled summary.
|
| It was a lie - they didnt read the document, I was busy
| is the dog ate my homework level of excuses. If you are
| taking home 7 figures you should probably brush up on
| your excuses.
| FeepingCreature wrote:
| This is so weird for me.
|
| Where I work (backend software development), we do video calls
| and meetings _all the time_. Probably an hour every day or more
| is spent in direct contact. I see this as absolutely essential to
| get people on the same page - but _none_ of the reasons that
| people have listed in this thread for why people prefer personal
| meetings apply to me. For instance, I am extremely grateful if
| someone writes up meeting notes, I read text documents all the
| time, and I often require continuous uninterrupted time and
| respect it in others, and I _still_ prefer voiced meetings.
|
| I think the primary reason is if I am trying to clarify an idea
| for a design or an approach, I will go to the people who have
| also touched that field of difficulty, and try to explain what I
| am trying to do to them in advance. The spoken medium in that
| case gives room for interruptions, immediate elaborations and
| feedback. A write-up either convinces or it doesn't; it can be
| edited but it has feedback cycles on the order of tens of minutes
| to hours. Spoken communication has feedback cycles of seconds, so
| even if I was going to write something up, I'd talk it through
| verbally first, anyways.
| andrei_says_ wrote:
| I do one on one 5-15-min zoom meetings when I need to clarify
| things that need clarification after 1-2 text exchanges. Super
| useful to look at the thing together and align mental models in
| real time.
|
| Other useful formats - look at work together with stakeholders
| and get instant feedback + clarification questions.
|
| For almost anything else, meetings can be a time waste. Some
| communications do not require full bandwidth exchange but where
| tone is important, an efficient meeting can be a timesaver.
| skohan wrote:
| Same. So many things can be solved in a 5 minute meeting which
| take hours of back and fourth using textual communication.
| Dudeman112 wrote:
| Also, so many things can be solved in a 5 minute text message
| which take hours of back and fourth when using meetings.
| [deleted]
| NikolaNovak wrote:
| I agree with everything you said; but coming from a place where
| 20 +++ hrs a week is spent in video meetings (and that's after
| rejecting just as many invites), having only an hr a day means
| somebody somewhere, whether explicitly or culturally, already
| set up system and expectation when productive time is
| respective and meetings are minimized. In other words you are
| already in a place many of us only dream of :-)
| Joeri wrote:
| You're both right, some of the time.
|
| There are two types of approaches to working out a problem. One
| is to get everyone in a meeting and talk it over until a
| solution is reached. The other is for a single person to
| carefully think through the problem and possible solutions,
| write down a solution, and pass it around for (usually
| asynchronous) comments.
|
| People who think meetings are really useful thrive in the first
| approach. The more meetings they have the faster they can get
| things done. People who prefer the solitary focused approach
| tend to see meetings as obstructions to progress, because they
| prevent them from actually solving problems by pretending to
| solve the problem while not making headway.
|
| Which approach is right is highly contextual, and you can't
| really argue it either way without falling back on personal
| preferences.
| oceanghost wrote:
| My last corporate gig-- I spent 6 to 8 hours in meetings. All
| of my development was done as overtime.
| pc86 wrote:
| I'm not sure your definition of "all the time" matches anyone
| else in the industry, quite frankly. At the architect/staff
| level I'm lucky if I can only spend half my time on the phone
| or in some sort of meeting (includes the ad hoc group chat
| where we're discussing something via our internal equivalent of
| Slack). I get maybe 5-10 hours a week of coding, and it's
| usually either something extremely challenging that someone
| else has already spent weeks hacking on, or a super basic bug I
| grab to keep myself sane and in touch with the nitty gritty
| code stuff.
|
| An hour a day is junior dev level meeting load at almost every
| place I've ever worked. Seniors are 2-3, arch/staff/principal
| 4-6 and managers all day long (all averaged over a couple weeks
| or so it obviously ebbs and flows).
| urthor wrote:
| Going out on a limb.
|
| 95% of all substantial corporate meetings would be vastly,
| vastly improved if someone wrote up some dot point notes of
| said meeting, and circulated the document as a courtesy.
|
| In my time in the workplace I've seen this done in maybe 5% of
| meetings. The entirety of that 5% involved team leaders having
| a regularly scheduled catch-up with our divisional overlord,
| and I sat in or saw the memo.
|
| Why don't these very basic things that would _vastly_ improve
| productivity take place?
|
| Garden variety laziness.
|
| Unless you get over that very basic hurdle of couldn't give a
| damn, what's the point of all these other solutions?
| amozoss wrote:
| Our meetings always felt like one construction worker digging
| a hole (doing work) while everyone else watched. Easily could
| have been solved with an agenda or someone telling to do the
| work post and not drag everyone else through the process of
| making a Jira ticket.
|
| We eventually decided to have a meeting chairman, their job
| was to make sure there is an agenda and to keep it on topic.
| They also make notes of tickets that need writing and make
| sure it's done post. We decided to rotate the responsibility
| weekly since it's kinda a hassle, but it really helps having
| someone assigned to keep meetings moving.
|
| We used a spreadsheet to rotate at first, but then found an
| slack app called tellspin that's been working really well for
| us. It reminds me a lot like pagerduty has a schedule,
| overrides, etc. Allows people to move shifts and stuff so the
| meeting leader role is always filled.
| ransom1538 wrote:
| "In my time in the workplace I've seen this [notes] done in
| maybe 5% of meetings"
|
| I go a step further. If it isn't on the agenda, we don't
| cover it. Just "spit-balling" or talking about things that
| are clearly not researched is a WASTE of everyone's time. If
| you want to talk about something, we want to take 10 minutes
| and research it too. Put it on the agenda and be prepared. We
| don't want to be ambushed into stupid decisions. "Let's use
| mongo!" out of no where is pointless and stupid. So that 95%
| can keep their unresearched ideas to themselves. Thanks.
| Personally I live by this quote: "Every stupid meeting starts
| with no agenda." NO agenda? Even better, meeting canceled.
| wpietri wrote:
| Laziness situates the problem in individuals and as a deep
| characteristic, and I think neither is true.
|
| Normally when I see ineffective meetings and missing
| communications, it's an organizational culture issue. The
| number one cause I see is what the Lean people call
| "overburden". I know somebody who was a big fan of
| circulating notes and tried to bring that practice to a new
| job. But they ended up giving up because a) bosses put too
| much on their plate to have the time for that, and b)
| everybody else was overloaded enough that they wouldn't read
| the notes anyhow.
|
| That of course means everybody has even more work now, the
| work called "failure demand". Extra meetings. Doing the wrong
| work because of confusion. Dealing with delays trying to get
| information not communicated to them. Etc, etc. So good
| meeting notes become more needed and more difficult to adopt.
|
| In my view, all of this is driven by not getting another Lean
| concept: push systems vs pull systems. [1] Work is not driven
| by actual demand and capacity limits, which is how pull
| systems work. Instead managers jam requests into the hopper
| with little regard for capacity, causing all sorts of
| downstream pathologies.
|
| So if we want to actually fix this, we need systemic change,
| not individual blame.
|
| [1] https://www.allaboutlean.com/push-pull/
| urthor wrote:
| That's a really good insight.
| FeepingCreature wrote:
| Right, and we do do that for decisions that affect more than
| the people involved in the debate. However, we also have a
| wiki, and so anyone can look at it and see how a habit of
| writing things down decays - because people may write it, and
| read it, but nobody _maintains_ it or cleans it up.
|
| The only worthwhile document is a document with a clear owner
| that is routinely updated. This does not scale beyond a few
| pages per user.
|
| When you talk to someone, you get their view at this point in
| time. You don't accidentally get their view five years ago
| which they've since revised; you are guaranteed to get, if
| not the _accurate_ version, then at least the _current_ one.
| When you talk to multiple people, you even have a chance to
| get the _correct_ one. Notes cannot defend their argument and
| so must be taken on faith - or else to confirm your
| understanding, you end up talking to someone anyways!
|
| In code, the best documentation is the test, because it
| _must_ be correct. The second best documentation is a
| comment, because it 's right there and hence hard to miss.
| Third is an external specification referenced in the README,
| because they generally change much more slowly than the code.
| Distant fourth is a self-written document in the same
| repository, because after all, how do you notice that
| something _didn 't_ change during review?
| urthor wrote:
| Ah but you see, in coding, before you write the test, you
| need a software developer and/or a team lead who gives a
| shit about writing tests.
|
| So it all comes back to the good ole "give a shit" factor.
| ethbr0 wrote:
| And I think this is somewhat the original talk's point:
| if the superiority of a given method is predicated on
| things happening (which rarely do) or things not
| happening (which often do), then it might not be
| superior.
|
| If TDD is superior if leads write tests, but leads rarely
| write tests, then is it superior?
|
| If meetings are superior if everyone shows up on time,
| prepared and generates documentation of the meeting, but
| nobody ever does those things, then are meetings
| superior?
|
| Tl;dr - Be honest about your team's reality, and choose
| the optimal option for that reality.
| tibiahurried wrote:
| TL;DR: - Meeting -> Outcome -> Create tickets
| -> Assign - Developers: write scripts; value
| automation over documentation
|
| In my experience, people don't read documents.
|
| When they need something they will ask.
|
| A meeting should always have an outcome in the form of
| actionable work;just create tickets and assign them to
| people.
|
| The ticket should capture all the necessary information to
| work on it. If a document is needed, it should be linked to
| the ticket.
|
| As for developers, scripts, tools, automation works better
| than a boring, soon to be outdated document.
| ethbr0 wrote:
| You're probably getting downvotes because you said
| "ticket."
|
| Which speaks to another problem with most large company
| cultures: ticket shoveling. In a healthy company, every
| ticket should receive one of three outcomes.
|
| (1) I can fix this, I work the ticket to completion, then
| request verification it's resolved.
|
| (2) I cannot fix this, but I know someone who can. I add
| context if needed, forward it to the appropriate person,
| and stay appraised of it and available until it's
| completed.
|
| (3) I cannot fix this, and nobody I know of can. I list out
| reasons why this cannot be fixed, and give any information
| I might have about alternative contacts who might(!) be
| able to help, and close the ticket.
|
| In most companies, and I think this has been exacerbated by
| outsourced IT and contractual resolution SLAs, until
| everyone's internalized it as the way they and everyone
| else _should_ act, you get something like this.
|
| (1) Is work. This is to be avoided at all cost.
|
| (2) I blindly forward a ticket on to anyone else who looks
| remotely responsible, to get it out of my queue, and then
| wash my hands of the entire matter and forget it ever
| existed. I certainly don't follow up or add context.
|
| (3) I close the ticket without providing any reason why, or
| information I have about someone who might know something I
| don't, who could help.
|
| A reliable metric I've come up with for measuring corporate
| and/or team disfunction is to count how many circuits a
| worst-case ticket can receive (where a circuit is:
| originator -> some number of teams -> originator/loop). My
| record is 3, before someone noticed.
| jodrellblank wrote:
| > " _In my experience, people don 't read documents._"
|
| I think this is worth calling out for its own discussion.
| Along with the traditional use of "RTFM" meaning "go away
| and stop bothering me", any amount of dysfunction in a
| sytem or company can be tolerated as long as someone has
| written about it in a document somewhere.
|
| Poor design? Buggy implementation? Complex configuration?
| Poor defaults? Missing features with inconvenient
| workarounds? Arduous processes? All fine as long as it's
| been documented. And any comments about voluminous
| documentation and "I couldn't find it" become point-scoring
| "I know where the needle is in the documentation haystack
| so I win".
|
| And as a user or customer, the last thing I want when
| facing your system being complex and unintuitive is a
| mountain of documentation to go with it. That adds insult
| to injury - you couldn't make a good system _and_ you 've
| made more work for me on top. How often have any of you
| read some good documentation about the internal workings of
| a system and left feeling intrigued and surprised and
| impressed? Occasionally, right? And how often have you
| trawled through documentation saying things like "to change
| the username field, simply log into our admin website,
| click accounts, click usernames, click customize, then
| download the XML customization file from the available
| template files, make the necessary changes, and simply
| raise a support ticket for us to install the new file" ? A
| poorly designed feature with an awkward process, with parts
| where detail matters (content of the file) left for
| guesswork, but at least it's all documented.
|
| I want my intuition (experience) to carry me almost
| seamlessly through your system, and if it has a short
| amount of clear documentation which helps me then I'm OK
| with that. If you want me to commit to trawling through
| books worth of content to learn things which are your own
| proprietary lock-in buzzwords around Rube Goldberg kludge
| designs, I'm not as OK with that.
| nickjj wrote:
| > In my experience, people don't read documents.
|
| I think this is true too, but I don't blame folks.
|
| I recently started a position which is the first time I
| ever worked as a non-freelancer. Previously I always wrote
| documentation for myself and my clients in self contained
| Markdown files.
|
| But at this new place they use a combination of Confluence
| and Google Docs for any type of docs that don't necessarily
| belong in a repo's readme file (like ancillary topics,
| general knowledge and guides). It's not easy to find stuff
| unless you already know where to look. Confluence's full
| text search is also pretty lackluster.
|
| Turns out keeping documentation and knowledge up to date
| when you're dealing with a handful of folks isn't easy.
| Especially if you factor in everyone contributing their own
| docs with their own writing style and patterns. It makes
| for a pretty inconsistent feel.
| wpietri wrote:
| There's a conflict in what you say. If people don't read
| documents and will ask when they need something, why invest
| in creating heavy tickets filled with the text they don't
| want?
|
| My team (and many XP teams) gets by just fine organizing
| things with cards that have a modest number of words on
| them (5-10, normally). When we need something, we ask. It
| works fine for us. We're a distributed team that has never
| met in person. But it also works fine for in-person teams:
| https://williampietri.com/writing/2015/the-big-board/
| tibiahurried wrote:
| I called it ticket, you can call it card. I did not say
| it to be heavy. But should also contain enough info to
| get started or at least point to the right person.
| wpietri wrote:
| What you are describing is definitely heavier than what
| I'm describing.
|
| And I disagree it should contain those things. In the XP
| tradition story cards (which are conceptually different
| than tickets, but I'm fine with either term) are tokens
| for conversations. The more documentation you add, the
| more it drives people away from conversation. As you say,
| when people need something, they'll ask. And I think
| that's a strength, not a weakness.
| thrower123 wrote:
| 90% of the meetings that are landed on my calendar don't even
| have so much as a unique subject or a one-line description of
| what the meeting is about. Most usually, the scheduling party
| reuses an old invitation, so any information in the invite
| body isn't accurate anyway.
|
| They're usually sent to me sometime after midnight, EST, for
| a meeting at 9 AM. When I did go to the office it wouldn't be
| uncommon to hit some traffic and arrive to find out you've
| already missed a meeting you didn't know about. If you did
| make it in, you were immediately ambushed with an angry
| customer who doesn't understand timezones or business hours.
| ofrzeta wrote:
| Today many meetings have the form of a brainstorming, like
| totally agile you know. I think for meetings to make sense
| you should have a clear agenda and notes about the outcome,
| possible action etc. For the modern workplace that's probably
| too old-fashioned.
| jodrellblank wrote:
| > " _Garden variety laziness._ "
|
| This is the kind of lazy non-explanation I was complaining
| about in the recent HN thread on "laziness doesn't exist".
| There are people who have perosnal incentives and counter-
| incentives, they work in groups which bring their own
| incentives. Things like:
|
| - Socially, writing up notes and sending them out is often
| seen as secretarial work, women's work, low status work.
| People think their personal interests are better served by
| taking high status tasks, not low status tasks.
|
| - As well as being a low status task, it could be seen as
| trying to usurp your manager's authority, if you want to be
| the one sending out "here is what we decided and who is going
| to be taking followup actions".
|
| - Socially it could be "goody-two-shoes" behaviour if you
| weren't asked to do it, and lose the respect of some people.
|
| - Socially, if a coworker got lumbered with a task nobody
| wanted, they might resent you sending an all-hands email
| "gloating" and making sure everyone knows about it, or you
| fear they might.
|
| - Writing memo notes invites you to open-ended future
| scrutiny if anyone thinks the notes unfairly represented what
| they said or their participation. Coworker who thinks
| management is getting an unfair view of their contribution
| because of your biased notes, for example.
|
| - There are power imbalances and adversarial relationships
| among people in meetings; writing memo notes may be seen as
| "I'm going to write down what you say so I can take it out of
| context and use it against you" or in an "I'm going to hold
| my seniors to account" way. Maybe some things in the meeting
| are spoken, deliberately so they are "off the record".
|
| - If you think the notes will not be read, writing them feels
| like pointless make-work.
|
| - It misunderstands the purpose of meetings as "productivity"
| when they are often for avoiding blame, feeling important, or
| pushing something back and forth because the people in the
| meeting don't have the authority to make the decision(s)
| which need to be made.
|
| - If the company sees meeting records as important, it should
| be explicitly someone's job. If it's not someone's job, the
| company doesn't value it, so why should you? In the YosefK
| "Employees can read their manager's mind"[1] sense, employees
| are not there to make the company productive, they are there
| to make their managers happy.
|
| - If meeting memos aren't regularly taken, and you want to
| start, you face all the possible problems of trying to push a
| change into an existing system and people's reluctance to
| change no matter what the change is.
|
| - If tasks are assigned in the meeting, they should go into
| wherever the teams track work, not into generic forgettable
| group emails. If decisions are made, they should be logged in
| whatever documentation logs decisions, not generic email. If
| those are done the memo is redundant.
|
| There are only a couple of quick ways through this, the first
| is an enthusiastic junior who wants to be seen to be helping
| and has little to lose because the worst case is a manager
| asking them to stop. The other is a high-status employee
| (socially, e.g. wealthy white male, contractor, friend of the
| boss) or organizationally (e.g. senior title, manager,
| leader) secure in their skills and life who have respect and
| can damn the consequences - although they would be more
| likely to use their power to skip the junk meeting or have
| the memo taking task assigned to someone less busy. For
| everyone else, all changes have risks, especially ones which
| include increasing your visibility while making the implied
| statement "you weren't doing things properly and I have a
| better way".
|
| These things which really exist and do bother people casually
| dismissed as "garden variety laziness" is, I repeat, a lazy
| non-explanation.
|
| [1] https://yosefk.com/blog/people-can-read-their-managers-
| mind....
| Foobar8568 wrote:
| I have been writing minutes, action lists, sharing documents
| meetings, 95% of people don't care and will come back to you
| a week later with a different opinions than what you agreed
| during the meeting, better, they'll pretend what ever despite
| written evidence.
|
| Corporate world is a shit hole where the only thing that
| matter is the opinion of a decision level breaker (escalation
| point) .
| blowski wrote:
| Exactly. If you a toxic culture, written notes won't help
| you. If you have a healthy culture, it's not a problem in
| the first place.
| ethbr0 wrote:
| I'd argue written notes / minutes do help in a toxic
| culture.
|
| I've had the obligatory interactions with a few
| backstabbing and/or passively aggressive teams, and when
| things eventually explode and work their way up the
| leadership chain (hopefully to someone with more sense),
| it's a quick knife through "you said / they said" to
| produce a written document from a meeting 3 months ago,
| where the assumptions you've been operating under were
| agreed to by the other team.
|
| Obligatory: producing said doc in this context makes you
| an asshole, and is a nuclear escalation. But some (rare)
| times call for that.
|
| (If it's a habit, you should probably reflect on yourself
| and/or find a healthier place to work)
| atatatat wrote:
| Sounds like you need to consider making a change, too.
| Foobar8568 wrote:
| At the end of the day, you need to change as often as you
| have a reorg in a company.
| nuclearnice1 wrote:
| What are the kinds of things people reverse their
| agreement s on?
|
| They change technical designs or timelines slip?
| ethbr0 wrote:
| In my (thankfully limited) experience it was around
| responsibility and methods of escalation.
|
| My read was that a team didn't want to be bothered with
| something, but I was working on a corporate priority, so
| we set a meeting, hashed out, and agreed on how issues
| should be brought to them.
|
| When something happened down the road, the agreed process
| was followed, and they (surprisingly stubbornly) claimed
| they weren't responsible and shouldn't be contacted for
| this issue.
| lornajane wrote:
| Do you have some tips on doing good writings? It's
| something I'd like to improve on but I haven't seen it done
| really well so far. If you have any recommended resources
| for learning more, I would be interested to dig in.
| jodrellblank wrote:
| > " _95% of all substantial corporate meetings would be
| vastly, vastly improved if someone wrote up some dot point
| notes of said meeting, and circulated the document as a
| courtesy._ "
|
| Has anyone tried putting at the top of the summary something
| like:
|
| Meeting cost: 4 work hrs (8 people x 30 mins)
|
| to draw attention to the fact that meetings aren't free, and
| put the decisions in context of how much it cost to get to
| them?
| saiya-jin wrote:
| > we do video calls and meetings all the time. Probably an hour
| every day or more is spent in direct contact.
|
| That's not _all the time_ my friend. My usual day is 3-5 hours
| on conf calls, you gain 'popularity' as your time / seniority
| at the company rises. I get 50% of my actual work done during
| those meetings, while others talk in matters
| unrelated/distantly related to my work.
|
| Video all the time? No, thank you. Our top 10 bank in the world
| is managing just fine without a single video call since
| forever. You get used to it very quickly, and the freedom it
| gives you is magical.
| closeparen wrote:
| Only an hour a day is most radically anti-meeting culture I've
| ever heard of.
|
| It's an extraordinary week when I get as many as 40% of my
| working hours for focus time.
|
| * Weekly cross functional syncs for the products I'm involved
| in, 2 hours.
|
| * Weekly design and SLA/postmortem reviews for the org, 2
| hours.
|
| * Three interviews and associated debriefs, 4.5 hours.
|
| * Standup, planning, and retro, 2.5 hours.
|
| * Tech talks, knowledge sharing sessions, org and company all
| hands, 2 hours.
|
| That's before anything as-needed to work on a specific issue.
| eutropia wrote:
| My personal calendar as a software engineer at a company of
| over 700 people includes about 1 hour of meetings per week.
| icedchai wrote:
| An hour a day would be paradise. I work for a company with
| tons of meetings and it's awful
| ethbr0 wrote:
| I see your awful and raise you a company where the default
| culture is to send blank meeting invites.
|
| At best, you might get a subject line.
| icedchai wrote:
| What happens if you don't show up? Do you get a nasty
| email, or a talking to through zoom?
| amarant wrote:
| Where I currently work, we're only doing standups every other
| day. It's usually around 45 minutes, and most weeks, that's
| the only scheduled meetings we have! Then of course if I or a
| colleague need help or want to discuss something, we'll have
| an impromptu call for it as needed.
|
| And this ain't no startup either: EA DICE can probably safely
| be described as a rather large company these days..
|
| Of course, it might well be different in other teams, being a
| backend web developer I'm part of a somewhat unusual team in
| the context of a gaming studio.
| SkyPuncher wrote:
| We typically accomplish everything we need in less than 5
| hours of meetings per week. Most of our engineers get to
| spend nearly all day actually writing code.
|
| An average week is 2.5 hours of "core" meetings
|
| * 1.5 hours - 30 minute "standup" 3 days per week. Skip the
| BS status updates. Planning, team discussions, etc all happen
| in this timeframe.
|
| * 30 minutes of retro (1 hour biweekly)
|
| * 30 minutes of 1:1
|
| We generally keep planning meetings pretty light. A _really_
| heavy week will be 10 hours of planning. A light week will be
| 1 or 2 hours talking about an upcoming feature.
|
| Everything else happens by individuals, asynchronously.
| caturopath wrote:
| I made it through most of my career thus far, including
| pretty senior positions, where probably most of my days
| didn't have a formal meeting. It's been so strange to move to
| a big tech company where I could spend 30 hours per week in
| meetings if I was not pushing back.
|
| Any they're all 30 minutes. What the heck do you expect to
| accomplish in 30 minutes? You spend 20% of the time waiting
| for someone to show up.
| wpietri wrote:
| You don't have to spend 20% of your time waiting for
| somebody to show up! That's an organization culture issue.
|
| For the daily team coordination meeting I run, we had a
| problem with that. So after one especially egregious delay,
| I asked how people felt about that. They didn't like it, of
| course. I then said I wanted a consistent start time, but
| was open as to when it was. At the hour? 1 minute after? 5
| minutes after?
|
| To my surprise, they picked 1 minute after. And everybody
| has stuck to it. A couple months in we'll occasionally have
| somebody turn up late, but the meeting starts without them,
| so they know not to do it again. It's great!
|
| We also build an agenda on the fly, keeping the pace brisk.
| Usually we finish a few minutes early, and sometimes the
| meeting will be a zippy 10-15 minutes. It's possible to
| have good, useful meetings!
| ljm wrote:
| Funnily enough, my zippy meetings are the ones where an
| agenda, or at least a boundary, is set out in advance.
| Oftentimes we allocate more time than is needed to
| discuss, so we call it off the moment we're done instead
| of filling the time.
|
| Part of this is because I'm also fine with interrupting
| and telling people to take something async if a group
| meeting is becoming a hyper-specific 1:1.
|
| Soon enough, meetings remain direct and rabbit-hole free.
| Unless the entire purpose of the meeting was to
| collectively burrow into it.
|
| All it takes is a little discipline, and clear
| expectations.
| rjzzleep wrote:
| Being able to call out people to take their stuff out of
| the meeting is extremely important.
|
| Needless to say when I just recently did that with the
| two program managers in a fortune 500 I got punished.
|
| It leaves you wondering why these big corps have program
| and project managers when they:
|
| - consistently don't have an agenda
|
| - completely ignore scope
|
| - don't even try to define scope
|
| - keep talking about being productive
|
| - keep getting promoted for creating powerbi dashboards
| of other people's work
| ljm wrote:
| I double checked my post and I never said 'called out'.
|
| I don't know how you went about it in this case but, I've
| never called out.
|
| All I've ever said is, hey...do we need to do this now?
| PKop wrote:
| Doubt OP meant anything different than: "interrupting and
| telling people to take something async"
| wpietri wrote:
| I'd suggest you read about managerialism, our reigning
| business paradigm. Spender and Locke's "Confronting
| Managerialism" really opened my eyes. If you think of
| management's purpose as making the business better,
| there's a lot that doesn't make sense. But it gets
| clearer if you think of it as caste dedicated to both
| individual and class power and enrichment, who also try
| to keep the business on the rails enough that there's
| something to have power over and extract money from.
|
| Not that all managers are bad or anything; plenty of them
| are people just trying to get things done. It's a
| structural problem.
| bobthepanda wrote:
| Video calls have also made this a lot easier.
|
| Before everyone kind of expected ~3 minutes of lateness
| to be the norm, dependent on elevator and stairway
| congestion. And god forbid one person is traveling from
| another meeting in another building a bit of a walk away.
| wpietri wrote:
| I think we agree. For me, the daily team coordination
| meeting has a clear initial agenda: go through each work-
| in-process item and quickly discuss it.
|
| But that tends to spin off longer discussions, and there
| are often short things people want to raise with the
| team. So after we've gone through our kanban board, we'll
| have an optional period called "post". Long items go into
| Zoom chat as "Post: thing to discuss" and we give a few
| minutes to each.
|
| I totally agree with blocking rabbit holes. Things that
| interrupt the fast run-through of the board get booted to
| post. Items there that are longer than a few minutes get
| booted to async or a topic-specific meeting, generally a
| smaller group than the team meeting.
|
| One other trick I recommend: rotate leadership of the
| meeting once people have the hang of it. I ran mine
| myself for the first couple months. Then I ran it every
| other week, with somebody new swapping in. The weeks when
| people are responsible for keeping the meeting on track
| make them much better participants when they're not in
| charge.
| ghaff wrote:
| Tons of meetings are just fine with being 30 minutes. And
| even if we schedule something longer we should expect to
| give people time back if we don't need the whole thing.
|
| Way too many 39 minute things get scheduled for 60. While
| there logistics issues at physical events with multiple
| tracks I feel most conference talks should be 30 minutes
| too.
| manigandham wrote:
| Why do you need more than 30 mins? The major problem with
| meetings is that they're mostly useless. Just talking for
| the sake of talking.
|
| Write up everything first for education and background,
| distribute that, then have a _short_ meeting when there's
| something actionable to do.
| gambiting wrote:
| I'm a team lead and most days I'll have 1 maybe 2 meetings
| at most, but having 0 isn't unusual. Is that weird? I do
| talk to people on teams _all the time_ though. I know what
| everyone is doing and how they are doing, just without
| having a voice /video call. We just text most of the time -
| I can be in 10+ ongoing conversations at the same time.
| Spooky23 wrote:
| It's culture thing. Personally, I prefer in-person or
| video meetings because it's an event and people are
| usually focused on task. One on one calls are great too.
|
| Text is good or bad. It's an attention thief, and you
| never know what you are getting. Also, I find that
| platforms like Teams are great for the present, but awful
| for history and context.
| Consultant32452 wrote:
| In my experience 90% of meetings with more than 3 people
| are irrelevant to my work. Here's a couple examples:
|
| "Standups" that are really PM status calls that
| constantly go down rabbit holes. My update is 30s or
| less, but the meetings are always 30 minutes long and
| usually run over.
|
| "Code reviews" that are really run/monopolized by one
| person. The entire team is required to attend even if you
| have no code, but in practice no one other than the
| runner is allowed to provide feedback.
| pc86 wrote:
| How are your standups taking that long? We have over a
| dozen people on our daily standup and it's 5-6 minutes
| long.
| adamnew123456 wrote:
| I've noticed a similar pattern at $JOB - we started doing
| a daily "WFH status call" in early April last year. There
| was nothing like it previously, just a weekly report on
| important bugs, support items, etc. that we worked on.
| And the occasional (less than weekly) meeting which would
| include the PM and dev team.
|
| The calls started out shorter but over time they've
| become a hybrid of:
|
| - "Here's the outlay for today." The shortest are just
| this which only happens when things are going smoothly
| and everyone's tackling things of moderate difficulty.
|
| - "Here's something that's been giving me trouble" which
| prompts a few minutes discussion. Usually someone has a
| idea to pitch in which gets the person unstuck, but it
| can bleed into...
|
| - "I wanted to bring up this thing I noticed" which pulls
| us into a bigger half-hour discussion with some possible
| followups scheduled with the more senior members.
|
| So at the extremes, any given instance of this meeting
| could last from 10 minutes to 45 minutes.
|
| We usually refer to this as a "stand-up" but I could see
| how someone from a more regimented team would understand
| it to be something with a more tightly defined purpose.
| pc86 wrote:
| Seconding the other comment on not waiting for people. As
| soon as the clock changes to the start time we are
| beginning the meeting, and we're not catching anyone up if
| they're late. They can figure it out.
|
| Obviously this gets a little slack if you're a super senior
| position (nobody's telling the company President they're
| not circling back on something already discussed) but for
| the most part meetings are much more efficient if you're
| absolutely ruthless with the clock. It's literally the only
| thing that nobody can control.
|
| On the flipside you have to be equally ruthless about not
| going over time. At 5 min before the scheduled meeting end
| time we start cutting off discussions that have become
| circular and start determining if we need to have a follow-
| up or clarification meeting for something. My biggest rule
| for this is that it can't be the exact same group, you'll
| just end up having the same meeting again. These follow-up
| meetings are most effective if it's a subset of the
| original group trying to clarify some specific point.
|
| 30 minute meetings can be useful if you stick to these
| rules.
| FeepingCreature wrote:
| I haven't timed it, an hour may be off. Call it two for
| safety. We generally orientate meetings vaguely around mid-
| day. Having a flextime schedule helps, because some people
| only show up an hour before lunch so you can't plan meetings
| for the morning anyways.
|
| That explains a lot of things though. It sounds like most of
| your meetings are terrible. Actually, if most of people's
| meetings in this thread are terrible experiences, that seems
| like it would explain their sentiments. In other words,
| meetings are mostly time loss, which you're of course trying
| to minimize.
|
| (It really helps that we have a culture of "I don't think I
| can contribute to this meeting, I'm gonna head out.")
|
| Almost all of my in-person meetings are technical debates -
| or group debugging sessions, where progress depends on
| randomly noticing something. In both cases, they scale well
| with number of members up to a point of four or so, where
| adding another participant generates more ideas than it costs
| time.
| BlargMcLarg wrote:
| >they scale well with number of members up to a point of
| four or so, where adding another participant generates more
| ideas than it costs time.
|
| That's the main thing I come across. Most meetings are well
| over four people. And personally, I already don't deal well
| with more than 3 people as most people work on a vastly
| different wavelength than myself.
|
| Now consider all the "Agile" meetings are already 5+ people
| and often contain management types and people who are both
| higher on the chain of command and have no technical
| background either hogging the attention. Suddenly, most
| meetings I see become either a hybrid announcement + roll
| call, a "meeting" with ulterior motives (e.g. managers
| trying to measure "participation" as a way to grade
| employees) or a very rushed design-by-committee approach to
| solving something.
| rtkaratekid wrote:
| I dislike when management decides to join a technical
| meeting randomly and then spends the whole time being
| confused and trying to get folks to explain something to
| them. It's happened at every place I've worked so far.
| For the record I'm not saying they're unintelligent, it's
| just that explaining something like how a kernel module
| actually works to someone who doesn't know what a kernel
| is tends to put a damper on the meeting if it takes 30+
| minutes.
| dvtrn wrote:
| A previous boss was like this. Couldn't avail himself for
| any of the status updates when I tried to-dutifully-keep
| him informed on project status, but would then show up to
| my team planning meetings, be confused, or get upset when
| he found out we were either not where he expect us to be
| in terms of progress, or that a minor decision was made
| among the group that he wasn't roped in on (but doesn't
| require senior management approval or consent)
|
| Meanwhile in my "Sent" (aka "CYA") folder...you can guess
| where this is going.
| ethbr0 wrote:
| Meeting sizing is a good point. It feels like adding
| additional people is often done aggressively but
| thoughtlessly, so maybe the solution is to have a
| company-wide rule to counter-balance that tendency.
|
| If voice/video meetings could have no more than 4
| participants unless (insert somewhat burdensome exception
| process), all participants would presumably consider more
| carefully who should be added.
| _0ffh wrote:
| A more flexible rule that also might help a little would
| be to require a separate justification for the use of
| time to be filed for every single invitee.
|
| It's just like of the signup process on your landing
| page. Make things you want to happen as effortless as
| possible -> make things you want to happen less more
| effortful.
| _0ffh wrote:
| In an evil afterthought: If people still keep inviting to
| many others to meetings, make the filing of the
| justifications only possible using a special intranet
| page, and make your least capable intern code that page.
| That should sort it out. }:->
| FeepingCreature wrote:
| Yeah we very rarely have that sort of management meeting,
| which is good cause they're useless.
| wpietri wrote:
| For sure. This bald assertion in the post blew me away:
| "Working in a distributed team means working asynchronously."
|
| This is just false. You and I live other approaches every day.
| I believe his way of working is fine for him, and he's welcome
| to it. But that doesn't justify sweeping dismissal of everybody
| else's experience.
| burnished wrote:
| Did you actually read TAF? They make it quite clear that this
| is their approach and in no way dismiss other view points.
| Your post reads like you are just trying to dunk on this
| article, and its weird.
| wpietri wrote:
| Bald assertions like that _do_ dismiss other viewpoints.
|
| Yes, he has a header saying, "It's solely based on my
| personal experience, and the experience of others I have
| talked to, watched, or read. Everything I say here is
| subject to debate and rebuttal, or you can simply have a
| different opinion."
|
| But he's then stating things dramatically as universals in
| a way that excludes the experience of others. Not only is
| it an unpleasant experience for those, like me, who have
| different experiences, but it also means I can't really
| trust him to tell the difference between what happens to
| work for him and what might work for others.
| burnished wrote:
| >but it also means I can't really trust him to tell the
| difference between what happens to work for him and what
| might work for others.
|
| No one can.
|
| > unpleasant experience for those, like me, who have
| different experiences
|
| Is it unpleasant being shown experiences that differ from
| yours? Can you elaborate on this with an example from the
| text and your own experience? I think it would help me
| understand where you are coming from if I could relate to
| it.
|
| The way I see this - you are asking the author to write
| in a 'universal' style, that respects and acknowledges
| all view points without preferring one over another. I
| have two problems with that. 1) it defeats the purpose of
| sharing your experience and the preferences you have
| learned. 2) it is difficult ranging to impossible.
|
| I'm not trying to put words in your mouth there, merely
| give you an opportunity to correct me and my impression.
| oblak wrote:
| I am with you. I spent about 50% of my working days talking
| to the people I work with. So, so much better than breathing
| each other's air. And as a bonus, no one is reaching for my
| mouse and keyboard.
|
| That said, I am not into this guy's shoes. His arguments make
| sense. I get it but my situation is different, plus I enjoy
| talking to the people I work with. Well, most of them anyway.
| onion2k wrote:
| I find people don't like calls if they don't have an opportunity
| to prepare for them well. A call that has a clear agenda, a clear
| purpose, a set of well defined outcomes, and (ideally) a document
| sent ahead of time for people to read and think about makes calls
| significantly more effective. Otherwise everyone just says
| they'll think about stuff and then you need a second call to get
| people's reactions.
|
| Sometimes setting everything out in a document and an agenda can
| even make the actual call redundant, if people respond with their
| input early enough.
| MattGaiser wrote:
| Indeed. A call often is an ambush to drag you into things you
| barely understand.
| mkl95 wrote:
| One of my clients employees struggles massively with asynchronous
| communication. He constantly spams one-liner after one-liner and
| demands immediate answers. Anything that involves working
| together on a sheet or a document becomes a pain in the butt.
|
| Having to work with someone like this has caused our current
| project to take longer and become more expensive. I really wish
| corporations gave these people some basic training and tips on
| async communication. Some people just don't get it.
| mmarq wrote:
| In my experience, many people prefer meetings over asynchronous
| communication because they can't write. I'm not referring to
| grammar or to spelling, but to being able to communicate
| effectively without a continuous feedback from the recipient of
| the message. When these people are asked to write documentation,
| the result is usually very sparse text with too many bullet
| points, table and images. Good asynchronous communication
| requires a high degree of introspection, clarity of mind and
| empathy, that not everybody has. A meeting allows you to pass
| your message through successive approximations, as in adjusting
| what you are saying based on the reactions of the listeners and
| being pushed in the right direction by their questions.
| Unfortunately it is also much more time consuming, because
| everybody has to stop whatever they are doing and listen for 1-2
| hours, while reading 2 pages of text would taken them 30 minutes
| and they could have scheduled it at their convenience.
|
| I don't see much of a difference between older vs younger
| generations nor between native and non-native English speakers.
|
| I'm open to accept that it's just my own experience and that it
| doesn't generalize.
| koonsolo wrote:
| I don't fully agree. I'm an ok writer, and don't mind writing
| documentation. But it takes time for me to write a good email.
| Like you say, you need clarity in your head. So basically you
| have to clear things out on your own before you can finish the
| document.
|
| Compare this to a meeting: you just say what you are thinking
| at the moment. Others might join in and raise points you
| haven't thought of. So you start from there and readon further.
| Basically a meeting is clearing things out in a group, which
| sometimes is more efficient.
| mobjack wrote:
| I prefer documentation with sparse text and lots of diagrams
| and images. It provides the high level context and I can fill
| in any gaps with a short follow up conversation.
|
| For most people, the high level information is all they really
| need. The few who need to dig in more can hash out the details
| in a smaller more effective meeting without wasting everyone
| else's time.
| mmarq wrote:
| Do you find it easier to learn something new from pictures
| and bullet points or from a long-form document?
|
| That kind of documentation is not necessarily bad, but it
| depends heavily on context, which is not always shared across
| readers. So when the author and those they talked to are not
| available anymore, it quickly becomes useless.
|
| Don't get me wrong, I don't think people should write War and
| Peace. Usually a good 2-3 paragraph introduction improves the
| quality of a document/email significantly. There you can
| provide the context that is necessary to fully understand the
| pictures and lists and diagrams you add after.
| ilaksh wrote:
| I feel like Discord can work OK for a small team. People can
| answer things asynchronously in the chat, organize in different
| channels or threads. And usually it is possible to sync up every
| now and then, and that can be useful.
|
| I think its easier for people to start putting things in an issue
| tracker and then forget about them, and the other person doesn't
| even know about it, or dismisses part of it, writes a comment,
| the first person doesn't see the comment, etc. So people often
| need to discuss things directly and tools like an issue tracker
| can make it too easy to avoid resolving issues or talk past each
| other.
|
| It depends though. I am talking about really small teams.
| commandlinefan wrote:
| It's gracious of the author to assume that the purpose of video
| calls is usually to convey information and solicit feedback, but
| the true purpose of most video calls is to exert some control
| over somebody who (the organizer thinks) needs a reminder of
| who's in charge.
| scrollaway wrote:
| You might need to quit your workplace If this is the way you
| feel people take video calls ...
| keskival wrote:
| People keep saying reading body language and expressions is
| important and so in-person or video meetings are crucial. However
| in my experience in the software industry experienced people
| don't show their emotions from behind their poker-face. If people
| show emotions, they are mostly fake smiles and fake enthusiasm.
| If you don't get honest feedback from your team in text, you're
| not going to get it from body language either.
| monocasa wrote:
| There's levels to body language, and engineers aren't typically
| great at hiding it. It's a soft thing, yeah, but definitely
| there.
| satisfice wrote:
| You know what, I am smart and experienced, too.
|
| I do a lot of meetings on Zoom. The idea that I should instead
| carefully craft documentation for much of the work I do is an
| incredibly bad one. The ideas I develop are easy to
| misunderstand, and constantly in flux. Meanwhile, my teammates
| have other things to do than keep up with my confluence pages.
|
| Usually such intensive documenting ideas are promoted by people
| with no respect for good documentation. But also, people with
| little understanding of how working relationships are formed and
| maintained.
| randomdata wrote:
| Whereas I'm stupid. I do a lot of meetings on Zoom too, and by
| the time you're finished explaining yourself I've forgotten
| what you said.
|
| It's not just about you. Write it down so that everyone can
| benefit.
| jimmytucson wrote:
| Calling remote work "distributed" is a buzzword. The work is
| distributed to different people, whether they're in the same
| building or not. The physical distance decreases the
| communication bandwidth between them.
| maxk42 wrote:
| "Distributed" teams are teams where everyone works remotely
| whereas "remote" roles may include those where some workers are
| in an office together. It's an important distinction.
| MattGaiser wrote:
| I always took it to mean that the people are spread out rather
| than co-located.
| papaf wrote:
| I disagree with a lot of this article because it assumes that we
| are efficient robots that just need things to be searchable and
| written down. Tools are also a bit lacking -- in theory writing
| stuff in a wiki is useful but then try finding the information
| with, say, Confluence search.
|
| The article also assumes every one is a native speaker who can
| write quickly and clearly in a chat -- in a lot of international
| projects this is not the case.
|
| I find that there is less chance for misunderstanding and
| aggression if you disagree over a video call. Also, human contact
| and informal communication make life and working more enjoyable.
| Aeolun wrote:
| > I find that there is less chance for misunderstanding and
| aggression if you disagree over a video call.
|
| If you put me in a video call with someone not more or less
| capable of communicating in our chosen common language I can
| practically guarantee that I'm going to want to murder them.
|
| There's nothing worse than sitting on a long call waiting for
| someone to finally understand what button you want them to
| click. Even better if you have 500ms delay too.
| marcodave wrote:
| 500ms ? you have it lucky , try 2000ms next time for real
| frustration. Bonus points if you can hear yourself back
| unless the recipient is muting him/herself
| f6v wrote:
| The assumption that text is always superior to a sync
| conversation is too strong. Often you get the crucial bits by
| interrupting someone mid discussion and asking for specifics.
| baash05 wrote:
| But you can do that in text too. I mean if it's wall of text
| dump, no; but if people keep their chat blocks short, then
| it's a two way convo. (or more)
| throwaway98797 wrote:
| Text suffers from being precise but accurate.
|
| Voice is accurate but not precise.
|
| Different problems are resolved better by one than the other.
|
| Brain storming better in voice. Technical details of an app
| that needs to be coded, writting is better.
| smallerfish wrote:
| > in theory writing stuff in a wiki is useful but then try
| finding the information with, say, Confluence search.
|
| If the company/team wiki isn't organized to optimize for
| browsing to relevant documentation, then you might as well use
| google docs (which excels at search and is terrible for
| browsability).
|
| A reasonable percentage of effort documenting something in a
| wiki should be devoted to making sure that people actually can
| find it, otherwise you're in cleaning-closet-in-disused-
| bathroom territory.
| the_gipsy wrote:
| The article assumes that we are NOT efficient robots that can
| store any and all information that we get in our heads.
| masklinn wrote:
| > I disagree with a lot of this article because it assumes that
| we are efficient robots that just need things to be searchable
| and written down.
|
| It assumes no such thing. If anything it assumes the opposite
| of your assertion, that we are _not_ perfectly efficient robots
| able to instantaneously and fully recall the content of
| transient discussions. Written content is perennial and
| searchable, so it can be retrieved in the future if necessary
| without being limited by human foibles and memory.
|
| Even if the search is bad and the system is not especially
| designed for it, I regularly manage to find information I dimly
| recall through search in discord and friends, something which
| would be entirely impossible using video calls. IME that is in
| fact a regular issue, people asserting that things were told
| during discussions and there's no way to confirm it, have
| context, ... because the discussion was a voice / video call.
|
| > The article also assumes every one is a native speaker who
| can write quickly and clearly in a chat -- in a lot of
| international projects this is not the case.
|
| Have you been in that scenario, ever? Video calls are
| infinitely worse than typed text between non-native speakers.
| And if the call is not going to be in english... why would the
| written communication be so?
|
| > I find that there is less chance for misunderstanding and
| aggression if you disagree over a video call.
|
| I find that there are regular shouting matches over video
| calls, and collisions between speakers makes the experience
| miserable. It's also impossible to dive in and out and recover
| the information, if you arrive on a group discussion midway you
| can read the history, if you dive out for a bit you can read
| what you missed. On a video call, it's gone.
|
| > Also, human contact and informal communication make life and
| working more enjoyable.
|
| _To you_.
| foldr wrote:
| While there may be some people who don't enjoy human contact,
| I think it's a little unfair to suggest that this is some
| kind of idiosyncratic preference of the original poster. It's
| a basic human need. Most people who work full time will want
| to have some kind of social contact within working hours.
| masklinn wrote:
| > While there may be some people who don't enjoy human
| contact
|
| We're not discussing human contact, we're discussing video
| calls.
|
| > I think it's a little unfair to suggest that this is some
| kind of idiosyncratic preference of the original poster.
|
| So pointing out that people differ is "a little unfair" but
| asserting liking video calls is a universal human
| requirement and enjoyment is fine?
|
| > It's a basic human need.
|
| History is full of people who happily did without.
| foldr wrote:
| It was not clear from your post that you were referring
| to video calls rather than human contact in general. Here
| is the part I was responding to:
|
| >> Also, human contact and informal communication make
| life and working more enjoyable.
|
| >To you.
|
| I think the vast majority of people would prefer having
| social contact via video calls to the alternative of
| having no social contact or having it only via text chat
| - yes. But I was not talking specifically about video
| calls.
| tluyben2 wrote:
| > I think the vast majority of people would prefer having
| social contact via video calls to the alternative of
| having no social contact
|
| I believe that too, but for me at least, video chat is
| for chitchat and banter and text chat for everything,
| including substance. This is the same for in person; I
| enjoy going with clients and colleagues to coffeeshops
| and bars, but we don't get much done in either (in bar,
| if with techies, actually more than you would think) but
| it is nice for the human contact.
|
| (Talking work context here if that was not clear)
| baash05 wrote:
| Personally, I like having chat's with my mates, over
| vids. I can chat with them async too. I don't need to see
| them to hear their voice in text.
| TheGigaChad wrote:
| Die Autist.
| papaf wrote:
| _Have you been in that scenario, ever? Video calls are
| infinitely worse than typed text between non-native speakers.
| And if the call is not going to be in english... why would
| the written communication be so?_
|
| I am in this scenario every work day as a non-native speaker.
| I much prefer talking to people than trying to get the text
| correct.
| subw00f wrote:
| I'm also in that scenario everyday with other 3 non native
| speakers from different countries, text is preferred
| unanimously. Tbh, that's the first time I encounter a non
| native speaker software engineer who prefers video calls.
| acatnamedjoe wrote:
| If there are "regular shouting matches" going on in any form
| of meeting then I would suggest the organisation in question
| has cultural problems way beyond the communication tool being
| used.
| thaumasiotes wrote:
| > The article also assumes every one is a native speaker who
| can write quickly and clearly in a chat -- in a lot of
| international projects this is not the case.
|
| You think non-native speakers have an easier time communicating
| in real time in a video call than through text? A video call is
| _the worst case_ for a non-native speaker.
|
| (Well, OK, a phone call is even worse. But being synchronous
| and relying on their ability to understand the spoken language
| are both terrible ideas if you're concerned about what makes
| things easy for non-native speakers.)
| zhte415 wrote:
| Phone calls are better, as no one can see the group on the
| other end looking at each other in bemusement (if in a
| meeting room) or in a group IM chat (if not all in the same
| place) asking each other what the hell the speaker is talking
| about (was talking about, as the speaker's often moved on).
| That's assuming anyone not interested has not taken a
| bathroom break.
|
| Sarcasm I hope detected.
|
| Speaking in an international environment is a skill. It's not
| just about (I think the term is) paralinquistics (speed,
| accent, volume, etc), it's about _thinking about who else is
| in the conversation_.
| nottorp wrote:
| > You think non-native speakers have an easier time
| communicating in real time in a video call than through text?
| A video call is the worst case for a non-native speaker.
|
| Oh yea, I forgot about this because I don't do video/audio
| calls.
|
| A non native speaker is NOT exposed to spoken english daily.
| In some countries they even dub Hollywood movies so not even
| their entertainment is in english. And where movies are
| subtitled you tend to read the subtitles so you don't bother
| understanding accents, speech over explosions and stuff like
| that.
|
| Written english is another thing, if you do programming.
| There's no point of looking for docs in your native language;
| the originals are in english and always more up to date.
|
| So maybe the non native speakers have trouble because the OP
| speaks too fast / has an unfamiliar accent?
| astonex wrote:
| I work as a non-native speaker in Korea. Speaking and
| listening is just insanely harder than reading and writing.
| I can be productive as long as I'm exchanging messages on
| Github/Messenger, but meetings are horrendous.
| jdshaffer wrote:
| I have the opposite problem here in Japan. I can listen
| and speak pretty well, even in meetings, but written
| stuff kills me because of all the kanji...
| nottorp wrote:
| And both of you should blame distributed work for this?
| For opposite reasons? You simply know spoken Japanese
| (much) better than written, while the poster above you
| knows written Korean (much) better than spoken.
| vasco wrote:
| A non native speaker wasn't born in an English speaking
| country, the rest are your assumptions. I'm non native and
| I'm exposed to and speak english every single day, and
| don't even live in an English speaking country.
| nottorp wrote:
| Local customs may vary? I'm not a native speaker either
| and I do mix English and my native language even when
| speaking. I'd still say my spoken English is
| significantly worse than the written one.
| Al-Khwarizmi wrote:
| Apart from what you say about exposure (which is true), I'd
| say that written English is much easier than spoken English
| for most (if not all) native speakers, for several reasons:
|
| - If you don't understand a sentence the first time, you
| can read it twice (or as many times as you want), and this
| very often helps as a non-native speaker - sometimes you
| misinterpret a word and this throws you off, but reading
| the sentence again clears the misunderstanding. It also can
| help deducing the meaning of an unknown word from context,
| etc. Of course in a video call you could ask the speaker to
| repeat, but this isn't functional if you do it often, and
| can make the non-native speaker feel ashamed of slowing the
| conversation too much, especially in work environments.
|
| - This one only applies to related languages, but it's much
| easier to deduce the meaning of written words from other
| languages. Take the word "subtitles" in your text. Any
| Spanish speaker could infer that it is equivalent to
| "subtitulos" in Spanish, because it's spelled very
| similarly (Levenshtein distance = 2). But the pronunciation
| (/'s^btaIt@ls/ vs. /sub'titulos/) is very different
| (Levenshtein distance = 5).
|
| - If you _still_ don 't understand a word, you can look it
| up. Or even hit Google Translate. Good luck with that in a
| video call.
|
| - Written language is reasonably standard. While there can
| be some regional variation (color/colour, lift/elevator and
| so on); you get rid of all the diversity of accents which
| can be a huge deal for a non-native speaker.
|
| Seriously, speaking as a non-native English speaker (at a
| quite good level now that allows me to speak quite
| comfortably, but obviously I went through all the stages of
| learning...) the difference between texting and phone/video
| calling when you're a non-native is enormous. The latter is
| like an order of magnitude more difficult.
| thaumasiotes wrote:
| > But the pronunciation (/'s^btaIt@ls/ vs. /sub'titulos/)
| is very different (Levenshtein distance = 5).
|
| Levenshtein distance between conventionalized IPA
| orthographic representation is not a useful metric for
| the perceptual difference between two spoken sound
| sequences.
|
| > Written language is reasonably standard. While there
| can be some regional variation (color/colour,
| lift/elevator and so on); you get rid of all the
| diversity of accents which can be a huge deal for a non-
| native speaker.
|
| This problem actually comes up in writing too; I knew
| some Chinese students who were _really_ offended by
| English typos. They had a point - lacking the pre-
| existing knowledge of English that lets me know what a
| typo was meant to say, they just had no way of finding
| out what a misspelled word was supposed to mean. You can
| 't look up words that don't exist.
| Al-Khwarizmi wrote:
| > Levenshtein distance between conventionalized IPA
| orthographic representation is not a useful metric for
| the perceptual difference between two spoken sound
| sequences.
|
| I know. Just wanted to provide some metric for the
| quantitatively-minded, and because the example is hard to
| follow if you don't speak Spanish or read IPA, and I
| don't know any least bad quantitative metric. But
| qualitatively speaking, I can tell you that inferring the
| meaning of that English word from the written form is
| obvious even to a Spanish person with zero English
| knowledge, while inferring it from the pronunciation it's
| very difficult. And it's just an example, but it happens
| with many words.
|
| > This problem actually comes up in writing too; I knew
| some Chinese students who were really offended by English
| typos. They had a point - lacking the pre-existing
| knowledge of English that lets me know what a typo was
| meant to say, they just had no way of finding out what a
| misspelled word was supposed to mean. You can't look up
| words that don't exist.
|
| It can come up, but still, the normal frequency of typos
| is much, much smaller than the frequency of accent-
| specific pronunciation variants, which typically change
| several words per sentence. And with Google you _can_
| look up many light typos and it will come up with the
| correct form (although not things like using "of"
| instead of "have", of course).
| hutzlibu wrote:
| "You can't look up words that don't exist."
|
| Erm, just google them and take the recommended result?
|
| In general I think searching with missspelled words is a
| quite solved problem.
| BlargMcLarg wrote:
| >because the OP speaks too fast / has an unfamiliar accent
|
| Here's an unpopular opinion by a hard-hearing person with
| native English skills: the far majority of people are
| really bad at verbal communication as a way to transfer
| knowledge. Doubly so in complex areas. To top it off, I see
| barely any difference between people in roles that require
| speaking often and those who don't, except for frequent
| public speakers.
|
| The reasons? Bad articulation. Speaking too fast. Speaking
| before you know what you want to say. Complicated
| explanations. Muttering "uh", "ah" and more. Diversions.
| The list goes on.
|
| And it's not like the information on how to be a better
| speaker isn't out there. I can assuredly say the average
| person in a leadership position doesn't even take 5 minutes
| of their work day to do vocal exercises. That alone already
| helps a lot.
|
| Meanwhile, people making informative videos and talks out
| of their own accord are much easier to hear and understand.
| The difference is night and day.
| perl4ever wrote:
| I'm attending a series of lectures on project management,
| and the first one was _great_. I mean, it didn 't contain
| any earth shattering information, but it was paced
| perfectly.
|
| The second one was surprising by comparison, because
| while it wasn't that bad, it illuminated all the things
| that were spot on in the first one. For instance, it was
| just a little too fast for me to easily type everything
| on the slides as notes, which I think is approximately
| the pace at which I absorb information. At the same time,
| there was too much redundancy and filler so I tended to
| get lost figuring out where information should go in my
| outline.
|
| If someone is otherwise a good and prepared speaker, a
| heavy accent can be adjusted to.
|
| Go a little slower and prune the verbiage a little more
| seem to me like principles to come back to.
| DiggyJohnson wrote:
| I am not a great communicator. I talk too fast, don't
| articulate my thoughts, start talking before the other
| person is finished (though I have a pet theory I picked
| up this habit from my first high-paced tech job working
| across 9 timezones with Indians =p ).
|
| I am constantly trying to work on this part of myself-for
| both myself and others' benefit-but have to be careful to
| not get too anxious about trying to fix my communication.
|
| I really appreciate this comment because I've found that
| when I talk to (close) friends about this challenge they
| do not consider communication something that can be much
| improved; communication style is mostly rigid. This
| baffles me because it seems like it would doom most bad
| communicators to a lifetime of bad communicating. This
| might be exactly how life works, I admit, but its an
| interesting way of getting to this obvious point.
|
| Where do you recommend someone like me go to learn more
| about those vocal exercises you mentioned. That does seem
| like a great starting place.
| mgbmtl wrote:
| Yeah, accents can be difficult. Personality too.
|
| I grew up in a bilingual en/fr environment. I mostly read
| in English and watch TV in English. Half of my ex partners
| are Anglo.
|
| And yet, on calls where I'm the only non-native speakers,
| and others are American or AU/NZ, I just don't understand
| half the cultural references and can't say anything because
| they talk too fast and interrupt all the time. At best,
| someone might notice that I am frowning or bored.
|
| Regardless whether text or video, some people are not there
| to listen to others. No easy way out of that one :)
| nottorp wrote:
| It's also implying that you do need to train a bit to work
| efficiently in a distributed team.
|
| > The article also assumes every one is a native speaker who
| can write quickly and clearly in a chat -- in a lot of
| international projects this is not the case.
|
| These are two different things. Native speaker is one, having
| the skill of writing quicky and clearly is another. They're
| unrelated. Both are trainable. Not to mention that in my
| experience it's the native speakers (of English i guess?) have
| the worst spelling :)
|
| > Also, human contact and informal communication make life and
| working more enjoyable.
|
| And... informal communication _has_ to be in a video call? It
| can 't be in writing?
|
| As for the human contact, I do recommend having a social life
| outside work. Distributed or not distributed work.
|
| Source of statements: been working in distributed teams for 20
| years, not since this pandemic.
| papaf wrote:
| _And... informal communication has to be in a video call? It
| can 't be in writing?_
|
| On video calls and in meatspace, you get to see peoples
| facial expressions, their smiles, they can move their hands
| and make gestures. I much prefer that to text.
|
| _As for the human contact, I do recommend having a social
| life outside work. Distributed or not distributed work._
|
| You are correct but, personally, I think spending 8 hours a
| day without seeing faces is too much.
| tluyben2 wrote:
| We work with people from all over the world, most not native
| speaking. For technical stuff, in our experience, voice or
| video calls are the most inefficient thing possible. Because
| spoken bad English is far worse than written, a lot of people
| have less than optimal internet bandwidth and latency and,
| worst, after the call the details are kind of lost. So first
| writing the main points in chat, if then some people (usually
| this is 1 person) want a call, we do a call and then flesh the
| details out over chat and in docs/wiki.
|
| Informal comms is also via chat; far more so then in video as,
| because of the overchatter and bad connections, jokes and quips
| get lost far easier.
|
| Ymmv of course but we avoid vid/voice like the plague, so far
| it hurt us with large amounts of miscommunication and time
| loss.
|
| By the way, been doing this and like this for 25 years now.
| nottorp wrote:
| > By the way, been doing this and like this for 25 years now.
|
| Yeah, he must be new to distributed work :)
| TheGigaChad wrote:
| Autist idiot.
| notRobot wrote:
| I prefer written communication because I like to think while
| absorbing information. As a result, when it's on a call, often
| I'll space out for a bit if I suddenly get a thought -- and then
| I'll have to ask the speaker to repeat themselves, which isn't
| very fun for anyone involved. Plus, I don't have the best memory
| when it comes to conversations.
|
| Just the fact that written communication can be referenced (and
| searched!) at any point in the future makes it magnitudes better
| _for me_.
|
| Even if a call is recorded (which it never is at my workplace),
| it takes a lot more time to go through a recording to find the
| bit you need, as compared to a quick and simple ctrl+F.
|
| But people all work differently, so... :shrug:
| bob229 wrote:
| It doesn't necessitate asynchronous working at all if you all
| work the same hours in the same time zone as many people will be
| nonameiguess wrote:
| One thing I never see considered in these discussions is the
| terrible state of high-speed residential broadband in the United
| States. Whether or not my team wants to do constant video calls,
| I can't. One of the things I did when I first started working
| from home is set up my router with OPNSense in preference to the
| ISP-provided router, which gives me some visibility into fine-
| grained details of traffic.
|
| Early on, the defense program I'm working on was big into pair
| programming. With a distributed team, this meant screen-sharing
| through Teams for hours per day. I could see turning on HD screen
| sharing and video feeds causes Teams to eat up 90%+ of my
| bandwidth, and additionally by tracking the data rates I'm
| getting through the WAN at different times of day and different
| times of the week, I can see very clearly that my ISP is
| throttling me when I'm using that much bandwidth. I may be paying
| for 400 mbps, but if I actually try to use that, I won't get it
| for more than a few minutes a day, or I'll get it for Netflix and
| Amazon Video, which are clearly paying for preferential treatment
| now that net neutrality is still not a thing (it will be
| interesting to see if they'll just started getting throttled as
| well if the FCC chooses to reinstitute net neutrality).
|
| Unless and until my employer or whatever acquisition office for
| the contract we're working on is going to run a dedicated leased
| line to my house that guarantees me consistent high-speed access,
| or they're willing to pay the ISPs for preferential treatment
| like streaming services do, nonstop HD audio and video is simply
| not going to happen.
|
| An hour a day is fine. I don't want to say never have any
| primarily voice-based meetings. Talking to people is important
| for many reasons. But at some point, when you've made a design
| decision, write it down. When you've begun implementing
| something, write down why you did it the way you did, how it
| works. It's easy enough to say documentation grows stale, so why
| bother? Then keep it up to date. Block out time in your work
| planning to do that. You wouldn't learn how to use the
| programming language you're learning, the operating system you're
| using, how TCP/IP and HTTP works, how a browser renders html, by
| asking the original creators of those tools. They wrote down how
| those things worked, and committed to a public interface, and you
| learn by reading as you're doing. I've been bit far too often by
| organizations that want to deliver fast and scrimp on
| documentation, and all the knowledge of why a particular design
| decision was made rest entirely in one person's head, and that
| person leaves, and the rest of us are left to reverse engineer
| whatever it is they did. You gain speed up front for your very
| first delivery, but then permanently cripple yourselves forever
| after.
|
| Maybe the vast majority of developers are just making
| screwdrivers and it doesn't really matter. The plan is to deliver
| anything quickly, generate some hype, and get acquired, and they
| don't care about product longevity because they won't be around
| for it anyway. But at least some people are making jet turbine
| engines, or something worthy of being included in that rebuild
| civilization from scratch archive that documents how to create
| all of the lasting and essential technologies that enable modern
| life. That has to outlive you. It's already not scalable or
| workable to try to contribute to the Linux kernel by asking Linus
| Torvalds personally how it works. Thankfully, it has great
| documentation. But imagine if you were at Google trying to work
| on Android and wanted to ask Robert Love why it is doing a
| particular thing. He's not even there any more! Thankfully, he
| not only contributed to the wonderful kernel documentation
| project. He also wrote books about it! And they won't grow
| instantly stale because the design decisions were well thought
| out and the APIs are fairly stable because of it. Writing out the
| rationale behind your design decisions is one way to force
| yourself to make sure they are actually well thought out.
| ivraatiems wrote:
| This is a well-written, cogent, and carefully considered article
| whose conclusions I disagree with almost completely.
|
| Many of the specifics have already been discussed, but a major
| benefit of video calls has been missed: Screen sharing. Computer
| interaction is largely a visual medium in modern times. It is so
| much easier to look interactively, together, at something than to
| try to type out what's going on. This applies to both
| instructions on using or doing something, and especially to code
| review or discussion.
|
| That doesn't mean you screenshare or call for most problems - you
| don't. But for some things it just ends up taking infinitely less
| time, especially when you are having trouble getting one side to
| understand via text.
|
| I work for a fully remote engineering team that has been remote
| for more than a decade - COVID changed very little of my
| organization's culture, as far as I know (I joined after the
| pandemic started). One of our core rules is "if a conversation is
| not going well, or people don't understand what's being said,
| take it to video," and that has served us well.
| xzlzx wrote:
| We optimize to get things done. If a video call is warranted, we
| all hop on and get to the answer much faster than text. If the
| convo is inherently asynchronous, we use Slack. I don't see the
| benefit in drawing lines in the sand. Each situation is
| different. We use impromptu meetings in most cases, not scheduled
| ones. It works like a charm. Being rigid about process is a
| classic productivity killer.
| MattGaiser wrote:
| > is warranted
|
| Significant disagreements likely arise about what this means.
|
| The problem isn't so much that video calls can be warranted,
| but that different people can have wildly different
| understandings of what that means.
| formerly_proven wrote:
| I've done like three or four video calls at work since corona
| (=full remote). I don't get the US obsession with video calls.
| Voice is perfectly cromulent for almost everything (see: those
| 3-4 exceptions).
|
| In distributed teams involving people from multiple countries you
| probably want to avoid both video and voice calls because on
| average everyone is much better at writing and reading English
| compared to speaking and listening.
| Hamuko wrote:
| Most of the meetings that I attend as a full-time remote
| employee are ones where someone is sharing a screen anyways.
| There's little screen real estate for anyone's webcam and I
| wouldn't really be interested in staring at them since I'm
| primarily looking at the shared screen.
| Scoundreller wrote:
| That's where voice comes in handy. I'd hate to have to type
| while demonstrating the issue or solutions in the
| screenshare.
|
| Then the difficulty on the other side of having to read since
| the host's typing shows up in a side box instead of like a TV
| subtitle.
|
| Sometimes we'll have stakeholders call in on their iPad or
| whatever, but they're passive so it's best to avoid text if
| they do need to jump in.
| bgatl wrote:
| The obsession is clear at least: Video calls are the
| narcissist's prime weapon of choice to fake useful involvement
| in a project. Many managers grade people on presence and
| eloquence in meetings.
|
| What is not clear is why the actually productive people don't
| push back.
| nottorp wrote:
| > What is not clear is why the actually productive people
| don't push back.
|
| Easier to change jobs until the culture fits. Especialy with
| remote jobs.
| vaylian wrote:
| A lot of people had very little video/voicechat experience
| before the pandemic. It doesn't occur to them, that the
| "downgrade" to audio-only is actually better than video+audio.
|
| Text trumps audio in terms of communicating hard facts. But
| many people outside of the tech industry can't properly touch-
| type. Just consider how many people still make phone calls
| instead of writing an e-mail.
| lbriner wrote:
| Many people in the tech industry can't touch-type!
|
| Certainly in the UK, and probably Europe, where you are much
| less likely to have a comp-sci degree, it is very hard to
| create consistent requirements for devs like "touch type 60
| words per minute" or "understands patterns and principles".
|
| It would be great to have something, even an industry
| standard like exists for law, medicine and even some building
| trades to at least have a base-level of consistency. I think
| this would help communication a lot - the domain language
| like "this wouldn't work as a Singleton because we need to
| subclass it" is nice and terse but only if you know the
| words.
| kgwgk wrote:
| > much less likely to have a comp-sci degree
|
| > consistent requirements for devs like "touch type 60
| words per minute"
|
| How are those two things related?
|
| Is typing part of the computer science curriculum?
| Aeolun wrote:
| It was part of my elementary school curriculum :/ and
| that was 22 years ago.
|
| (In the Netherlands, and of course we used typewriters,
| since we didn't have that many computers yet)
|
| Edit: modified for clarity based on comment
| kgwgk wrote:
| I'm pretty sure computers were not so rare in the
| Netherlands in 1999!
| Aeolun wrote:
| Fair point.
|
| I meant, we had computers, but not a whole class full of
| them. Teaching kids one by one on the one computer per
| class would have been very inefficient.
|
| Modified the original comment.
| perl4ever wrote:
| I don't think so; the causation would be in the opposite
| direction.
|
| A lot of experience typing (code) would tend to make
| someone more likely to pursue and complete a CS degree.
| anyfactor wrote:
| I do freelancing and I hate calls in general.
|
| There are people out there who would not even give a single
| sentence description of what they want rather it is "when can
| you jump on a call with me".
|
| They assume the task is difficult to explain in text but to me
| it often sounds like they don't even have an idea of what they
| want really.
|
| They want me to hold their hands and lead them through a
| journey of self discovery while on the ride we discover joy and
| surprise and at the end of the tunnel only to discover the
| project is radically abstract and the client is not happy to
| pay on a per hour basis.
| lbriner wrote:
| I think there is space for more disruptive approach to meetings.
| Remember Elon Musk saying if he didn't find meetings productive,
| he would walk out? Stuff like that.
|
| How about saying to people that if they don't see the value of a
| meeting, they shouldn't turn up. You start to see problems arise
| and people should then start to see why some of those "boring"
| meetings are actually important or perhaps how the same problems
| can be solved in another more productive way.
|
| The difficult part is sometimes teaching devs that they do not
| exist in a vacuum and the business is more important than the
| tech. Sometimes they need to be in meetings to help others
| understand and sometimes they need to hear some non-tech truths,
| neither of which they would necessarily appreciate by default.
| BlargMcLarg wrote:
| >I think there is space for more disruptive approach to
| meetings. Remember Elon Musk saying if he didn't find meetings
| productive, he would walk out? Stuff like that.
|
| The last time I even suggested doing this, I was swiftly met
| with a "then I'll report it to HR" by the manager. Even though
| this was in video, with a clear tongue-in-cheeks approach. The
| majority of my colleagues had nowhere near the audacity to make
| such a suggestion, let alone actually do this. Reality is most
| developers aren't working together enough to make it a serious
| risk for managers not to listen, as the average dev is still
| replaceable enough.
|
| >The difficult part is sometimes teaching devs that they do not
| exist in a vacuum and the business is more important than the
| tech.
|
| You don't really need meetings for this though. Unless you're
| trying to convince a stubborn dev by showing him just how much
| more stubborn stakeholder X, who controls the money, truly is.
|
| >Sometimes they need to be in meetings to help others
| understand
|
| I fail to see how pulling the majority of the dev team to the
| meeting, while at the same time giving them zero time to
| prepare and zero development in their presentation skills,
| helps others understand much more if it wasn't something that
| was so trivial, you could've explained it in a short message.
| I'm all for helping the client, the higher-ups or any other
| non-dev who wants to know more and meet the business ends.
| However, the kneejerk reaction seems to be "let us meet". In
| reality, they want me to bridge the gaps between their
| perceived needs, their actual needs, my/our jargon and a way of
| communication they understand. New-age meetings with barely any
| preparation or research beforehand, being mostly a back-and-
| forth, no-holds-barred discussion, have barely ever been a
| suitable medium for that.
___________________________________________________________________
(page generated 2021-09-25 23:01 UTC)