As a software developer I am constantly bombarded with information from design specs to “what would be really nice is…” and discussions from different people on HOW to do things. This continues to be a burden to sift and organize, but over the years I have learned that some things are helpful and contribute to the delivered product and other efforts waste time.
I do not believe in information overload. Too much information is not the problem. In fact, I want as much useful information I can get at the times I need it. Reducing the quantity of information is not something that is useful to me, because that means being dismissive of other people on the team or myself willingly being ignorant.
To remain smart and learn so I can be smarter in the future then I have to know how to generate the information I need and share it with others effectively. For example, too many meetings and group time is conjecture. It is everyone verbally throwing in their two cents. At the end of the meeting there are very few written words or diagrams or shared artifacts. The really good people take minutes and come out with action items beyond “get it done” or reference items. The other part that is often missed in building software products is shared information artifacts before coding takes place. For example, I was in one meeting today where a couple of people all talked about a workflow of a software application and at the end of the one hour there were no diagrams of the workflow they verbally produced or written instructions. Worse yet, these were middle managers who were not going to be doing the work themselves. The developers who were also in the meeting walked away with the verbal discussion in their head, but no reference material to go back to in the coming weeks as they code it. Most likely, there will be many verbal discussions between middle managers and their programmers in the coming weeks. This in itself isn’t bad. What is bad is what they will be talking about, which is verbally repeating what was said in the meeting or finally understanding the workflow and then coming up with smart suggestions for implementing it.
This brings up another good point. Different people need different kinds of media to truly understand the concept. Just because people agree verbally does not prove understanding or mean the right questions were asked and the right discussions had. A complex system can be described in a picture, a diagram, several bullet points of goals and a descriptive paragraph. This is more information of different kinds but lets people understand before they build it and lets managers understand before they force “solutions”.
So much waste in building software comes from building and rebuilding the wrong things. This is because the problem is not adequately defined. Before the solution can be defined, the problem and goals of the users need to be appropriately defined and shared. A software programmer is the least expensive part of the product when the right software is developed for the right problems and they fit user goals.
Cognitive friction is what happens when people burn brain power trying to understand any information that has so many modes, or is described out of context or in ambiguity. Worse yet, cognitive friction is what happens when people get burned out from arguing for an hour over misunderstood concepts and a week later in a different meeting go through the same process because everyone lost the context between the previous verbal discussion and the current verbal discussion.
To reduce cognitive friction, you have to create and share information artifacts that people can reference any time and that are in different media types so they are readily accessible. If I am in a high level meeting, then to be smart I should have a high level diagram of the workflow meeting. If I am collaborating on a feature with another programmer then I should have bullet points of the goals that this feature should let the user achieve and a paragraph describing the context.
This is how value is generated and learning takes place. Learning is compounded. Not learning does not even help you climb the project wall linearly. Non-learning makes you climb the wrong project walls fast or compromise on the very bottom layer of the right wall.