[jbc1]

Even if the final nod of agreement happens in real time the actual decision making process for critical product features should involve planning, thinking, research, etc. There should be a strong paper trail such that everyone knows what the decision is going to be prior to the "everyone gets together and declares this is how things are going to be" step.

If them missing some meetings means they're in the dark as to how those features were decided on then I can't see that as a defence of attending every meeting so much as a statement of BS meetings being so predominant in the company that all decisions are made through a BS process.

[MrJohz]

This might not be quite what the previous poster meant, but in my experience it's often not that the developer missed a meeting and now doesn't know some critical piece of information. Rather, it's often that the developer has some knowledge about the code that changes how something should be implemented. Because they weren't at the meeting, nobody else knew about this, and it's only later, when the developer sits down to write the code, that everyone finds out.

In this case, there's nothing to document from the meeting because the information wasn't shared in the first place. The information could only have been shared if the developer had been in the meeting.

(FWIW, I've rarely seen this from a developer not being in a meeting entirely, but I've seen it a few times where a developer has treated the meeting as a "read-only" event, i.e. expected that other people provide all the requirements and not used their own expertise or experience of the code to push back on decisions.)

[coliveira]

The point in the parent comment still stands. There should be a paper trail so that the developer would have to confront the need to add such a detail. If the decision was made in the meeting alone, then it was lost in time as not all developers can be expected to be in every meeting.

[scott_w]

How? Meeting notes can never contain all the detail of the meeting and, if they do, there would be so much content that you'd likely miss them when you read the documentation. That's to say nothing of the time investment of the person to catch up on every document produced.

In that case, you're essentially relying on the people in the meeting to know they should document that thing as important which, given the person who knows it's important isn't there, is pretty unlikely.

Even in an ideal world, we'll have developers not in the meetings they need to be in. My contention would be that we should try to get people in the right meetings and, over time, the number of issues where someone isn't in the right meeting will be lower than if we just don't have those meetings.

[MrJohz]

If decisions are being made about the code or implementation, then the person working on that code should be in that meeting, surely. Otherwise there's no point making that decision.

[pj_mukh]

I realize introverts don't work that way, I know, I am one. But I've had some of the most brilliant ideas come through purely on a discussion nay sometimes an emotionally charged argument.

Important decisions are almost never 2+2=4, if they were, they wouldn't be important and yes you wouldn't need a meeting (like I admitted, there's definitely a lot of unimportant meetings).

But important decisions are almost always an exercise in coaxing, cajoling and persuasion, which is just extremely low fidelity on paper.

Most engineers will look at their team leads and say "I don't believe in this strategy on paper", and all their team leads can say is "I was at the meeting. You had to be there"

[Propelloni]

I'm an introvert, too. I have no troubles participating in, or leading, or even fighting in group activities. Does it exhaust me? Yes, it does. I literally feel physical pain if I have to stay in company for more than maybe an hour. But value is created through interaction, not some process, paper stacks, or a lone wolf hiding in the closet, so I learned a long time ago how to communicate effectively, give and take feedback, organize tight meetings, and facilitate decision making.

I'm actually a bit tired of introverts hiding behind their disposition. You can do something about it, and it's more than complaining.

EDIT: Sorry, that was more rantish than I wanted. But I'll leave it here anyway.

[sneak]

Most people in meetings don’t type very fast, and find it easier to talk than to write.

This means that prior to AI transcription/summary bots, there wasn’t much written documentation about the decisions and conclusions from meetings. Now hopefully that will change.

[a_bonobo]

In my org we have rotating minutes takers - it effectively takes them out of the meeting, but they do pipe up if an issue affects them directly. Of course people's meeting taking skills vary widely but I still find the human-made minutes far superior and accurate to whatever Copilot cooks up.

[jbc1]

I wasn't so much saying that there should be plenty of documentation generated during a meeting as saying that there should be plenty of documentation prior to the meeting. That the meeting is based on.

[Cthulhu_]

I've also read a thing (dunno if it was opinion or fact) that posited that people's reading ability is directly correlated to a preference for video, I suspect it's the same with meetings. I read / write all day (including on here lmao), meetings are draining in comparison. But the people in those meetings don't read / write nearly as much as I do.

I did once think that if the meeting were to be transcribed, people are outputting paragraphs of text in a short amount of time, just verbally. But keeping up with that is pretty draining, as you have to listen and process it, whereas with reading you can skim and re-read things easily.

I sometimes think people's basic skills - reading and typing - are underdeveloped or not assessed, and they should be assessed when applying for a job that involves reading and typing. But I don't even think people consider reading/writing skills when looking for staff since the assumption is that everyone's is good enough.

[sneak]

I administer reading comprehension tests and typing speed tests to all candidates I consider hiring.

It’s overlooked.

Good ones who can’t type fast, I assign them typing lessons their first few paid days on the job, and a half hour twice a week thereafter for a while.

I’m an outlier and can type 120wpm without trying very hard, but I expect 40-50wpm (touch typing, not hunt and peck) at a minimum from staff that work with computers and aren’t disabled.

[absoluteunit1]

Hi

> Good ones who can’t type fast, I assign them typing lessons their first few paid days on the job, and a half hour twice a week thereafter for a while.

This is very interesting to me - I’ve actually been building https://www.typequicker.com recently and was curious about potentially adding features and marketing it towards businesses who then can use it to train their workers.

Typing quickly is extremely overlooked and since I learned touch typing, it completely improved my productivity and career trajectory. (Went from 40ish to about 100-120wpm depending on what I’m typing)

What are some tools that you use when you say you assign lessons?