Those who can, do; those who can’t, teach.”
George Bernard Shaw
As you can imagine, in a family heavy in educators, this phrase lands anywhere from irksome to derogatory. As I have worked to define my own expectations in my new role, it occurs to me that Shaw got this wrong, and we have to go back a few thousand years to correct it.
Do we hate teaching?
As you may have noticed via my LinkedIn, I have stepped into a new role as Chief Architect. The role has been vacant here for some time, which means I have some flexibility to refine the position and how it will assist the broader engineering staff moving forward.
My current team is comprised strictly of highly experienced software architects who have, combined, spent at least fifty years working on software. As a leader, how can I best utilize this group to move our company forward? As I pondered this question, the Shaw quote stuck in my head: why such a disdain for teaching, and does that attitude prevent us from becoming better?
Teaching makes us better
Our current group of software architects spends a lot of time understanding the business problems and technical limitations of our current platforms and then working out solutions that allow us to deliver customer value quickly. In this cycle, however, we leave ourselves little time to fully understand some of the work that we are doing in order to educate others.
I can say, with no known exceptions, that I my level of understanding of a topic is directly related to how many times I have had to educate someone on said topic. If I have never had to teach someone how my algorithm works, chances are I am not fully aware of what it is doing. I simply got it to work.
For topics that I have presented to others, written blog posts about, or even just had to document in an outside medium, my level of understanding increases significantly.
Teaching is a skill
Strontium sums up The ‘Those who Can’t Do, Teach’ Fallacy very well. The ability to teach someone else a particular task or skill requires so more than simple knowledge of the task. Teachers must have an understanding of the task at hand. They must be able to answer challenging questions from students with more than “that’s just how it is.” And, perhaps most importantly, a teacher must learn to educate without indoctrinating.
As technical leaders in software engineering, architects must be not only be able to know and put into practice patterns and practices that make the software better, but they must be able to educate others on the use of those patterns and practices. Additionally, they must have the understanding and ability to answer challenging questions.
What is our return?
In a professional environment, we often look at teaching as a sunk cost. When high level engineers and architects spend the additional time to understand and teach complex topics, they are not producing code that leads to better sales numbers and a healthier bottom line. At least not directly.
Meanwhile, there is always mandatory training on HR compliance, security, and privacy. Why? If there is a breach in one of those areas, the company could be liable for millions in damages.
How much would it cost the company if a well-designed system suffered from poor implementation due to lack of education on the design?
Teach it!
Part of the reason I wanted to restart my blog was to give me an outlet to document and explain some of the work that I have been doing. This blog gives me an outlet to have to explain what I have done, not just “make it work.”
As you progress through your professional journey, in software or not, I encourage you to find a way to teach what you know. In the end, you will learn much more than you might think, and you will be better for it.
As I mentioned above, I prefer Aristotle’s views on this matter over Shaw’s:
Those who know do, those that understand teach.”
Aristotle
Leave a Reply