High-Documentation is so out of fashion, for all the wrong reasons. If you are designing anything that is intended to last longer than 6 months, documentation is a critical part of the system.
Meetings are great for communicating with people here and now, but only writing can communicate with people from the future. When you meet with your current colleagues, spare a thought for your future colleagues who haven’t yet joined, and do them a favor by writing things down.
Ability to use written communication is a major differentiator between junior and senior engineer.
This reminds me of when leadership announces a policy over email. Sure, all the people who got the email can follow it, but what about people who join the team in the future? Either they find out about the policy when they violate it and get reprimanded, or they hear about it via word of mouth.
For sure! Why can't it be "we have updated/created X policy, please find it here: <link to document in policy repository>" ? Is that so much harder?
Most document management systems have a notification system built-in so that you can automatically email your all-staff mailing list when there is an update. It's very much a solved problem.
Writing is definitely a critical skill for software development. At my last "staff+" job, I spent most of the time writing documents that seemingly nobody ever actually read. I also reviewed a bunch of them.
My current workplace culture (at least in the HW dept) is much more towards zero-documentation than anything I have experienced before and it has been a nightmare as a relatively new employee.
I waste so much time in reviews because I have done something non-standard despite having checked the standards docs but it turns out the standards have changed and no one bothered to update the docs. We don't even write specifications for products before we start work on them; if I make some architectural changes during the design, there is nowhere to record it. Drives me insane.
IMO there are two things that should be documented about any project:
1. The product itself: at least its interfaces, features and general architecture
2. The process of design: what changes were made vs the original spec, why, and when
If you want to know anything contained in that set of information here, you have to know who worked on the project so you can ask them about it, and then they have to be able to remember. It's not uncommon that changes are suggested and discussed multiple times within a project, or that changes are made but the reasons why are forgotten before the project is even complete.
I often joke that projects here are more "observed" than managed.
Exactly as you say - emails/meetings are ideal tools for discussion and decision making but for lasting records, you need documentation.
Agile taught us working software over comprehensive documentation, but it also made huge generation of people thinking that all documentation was bad, and not just "comprehensive" (or "overblown").
Documentation (words) is how many complex concepts are communicated.
I've built a requirements management system to handle this (https://userdoc.fyi), and it's made many projects I've worked on 200% easier for developers, project managers, and all stockholders.
I think high-Documentation is out of fashion as a reaction to agile, but things are swinging back the other way.
Meetings are great for communicating with people here and now, but only writing can communicate with people from the future. When you meet with your current colleagues, spare a thought for your future colleagues who haven’t yet joined, and do them a favor by writing things down.
Ability to use written communication is a major differentiator between junior and senior engineer.