Software Architecture - Triangle of Knowledge

I am currently watching the course Software Architecture Fundamentals Part 1 by Neal Ford, Mark Richards.

I do really love the triangle they used to represent the status of your knowledge.

The technical depth is the height of "stuff you know" while...

The technical breath is the height of the "stuff you know you don't know".

The key skill to become an effective software architect but I would say in general a knowledgeable T person is to move stuff from "stuff you don't know you don't know" to "stuff you know you don't know". In this way, you increase your awareness.

This is why constant learning, reading books, watching courses is so important. 

We all need to be long life learners!

Book: Resonate Present Visual Stories that Transform Audiences

Here are my learnings after reading the book Resonate Present Visual Stories that Transform Audiences.

The first important lesson is that being yourself during a presentation is critical. Removing all the human touch from a presentation is wrong and ineffective. People attend your presentation because they want to know your perspective on the subject, so you should give it to them. Sharing emotions is important because your goal is to "make your audience feel what you feel".

Your presentation should be a story, not a report. 

Reports inform, while stories entertain.

The key is to see the audience as the Hero of your story. You create a desire in the audience and then you show how your ideas fill that desire so that people adopt your perspective. You start with an incident that captures the audience's intrigue and interest and then you start a journey from their ordinary world into your special world, gaining new insights and skills from your special world. The audience makes a conscious decision to cross the threshold into your world; they are not forced. The audience will resist adopting your point of view and will point out obstacles and roadblocks. The audience needs to change on the inside before they'll change on the outside. In other words, they need to alter their perception internally before they change the way they act.

I found quite interesting that great presentations usually have some kind of conflict or imbalance perceived by the audience that your presentation resolves. You should clearly contrast who the audience is when they walk into the room (in their ordinary world) with whom they could be when they leave the room (crossing the threshold into a special world).

Presentations should have a clear beginning, middle, and end. Two clear turning points

The first is the call to adventure—this should show the audience a gap between what is and what could be—jolting the audience from complacency. When effectively constructed—an imbalance is created—the audience will want your presentation to resolve this imbalance.

The second turning point is the call to action, which identifies what the audience needs to do or how they need to change. This second turning point signifies that you're coming to the presentation's conclusion. 

It's important to follow up the call to action with a vivid picture of the potential reward. The ending should repeat the most important points and deliver inspirational remarks encompassing what the world will look like when your idea is adopted.

Presentations are meant to persuade, so there is also a subsequent action (or crossing the threshold) the audience is to do once they leave the presentation.

Your job as a communicator is to create and resolve tension through contrast. Though people are generally more comfortable with what's familiar to them, conveying the opposite creates internal tension. Oppositional content is stimulating; familiar content is comforting. Together, these two types of content produce forward movement.

You want to make each person feel like you're having a personal exchange with them. 

For this reason, it helps to split an audience into segments—but humans are more complex than that. In order to connect personally, you have to bond with what makes people human.

No matter what the tool is, the audience should leave each presentation knowing something they didn't know before and with the ability to apply that knowledge to help them succeed.

The key skills is to remove the inessential.

Striking a balance between withholding and communicating information is what separates the great presenters from the rest. The quality depends just as much on what you choose to remove as what you choose to include.

Finally Be honest.

Be honest with the audience and give them the authentic you. You're not perfect; they understand that. If you are honest with yourself and with them, your presentations will have more moments of vulnerability and sincerity.

How often do you deliberately read code?

I am currently reading the book 97 Things Every Programmer Should Know and I come across again to the most obvious but less followed advice ever.

You should read more code!

I like reading technical books and this is not the first time I see this advice.

Are you deliberately reading other people code?

I personally read snippets of code in books, in online videos and of course I read and review code written by my colleagues at work.

Is it enough?

I don't think so.

Code in books or online courses are just snippets so they can helps you to learn a specific technology or best practise but they do not help in teaching you how to read an entire code base or quickly jump into a new project.

Code at work is surely a source of learning but often you just read the code related to the task at hand instead of learning the overall project.

Programmers are writers. 

Great writers read books. 

Great programmers read code.

To make things harder, there are no books on the market teaching you how to read code, how to learn a code base from scratch and be productive quickly. This is a question I asked often and I rarely found an answer. 

Why some people are so good in jumping in on a new project?

They surely know the language and the technologies but more importantly they are used to read code, they can read and understand code quickly!

This is something you need to learn by doing.

There is no alternative.