Seek First to Understand

Habit number 5, from Stephen Covey's The Seven Habits of Highly Effective People was to "Seek first to understand. Then to be understood." It actually just struck me how this relates to a change in my learning style and a z/VM development core.

Coming out of college, I was still some what stuck in that mode of learning:

• Memorize facts or procedures, so you can...
• Regurgitate those facts, so you can...
• Pass and move on to the next class

I was fortunate in my impressionable years with IBM to have good mentors. None of them were formal mentors. You know, the ones that mentor because it is in their nature, not just because they need the check mark for appraisal time of having mentored someone. I'll talk more in a future post about some of these individuals because that's how important they were to me and my career.

But the point here is they changed my learning process. They forced me to know why we did things when I wanted to just focus on the procedure. They took me from being able to type in a list of commands to knowing what those commands were and what they did. In ways, it was as if I was learning a new language. Just because I can count to ten and name the days of the week in Spanish, doesn't mean I can speak Spanish. So it was that my mentors forced me past memorization of VM commands and into an understanding of virtualization and the underlying architecture.

I see this with my current peers. For example, when they train new people on z/VM memory management. They don't give them a list of subroutines to memorize; they tell them to go read and understand Chapter 3 of the z/Architecture Principle of Operations. Probably just what their mentors told them. I smile thinking about the generations of people involved in z/VM and the approach of understanding the system first in order to developed on it to the fullest. There's a sense of craftsmanship in all of this.

This craftsmanship has another dimension, that of understanding how things are used. The better moments in VM history are where VM Development collaborated and accepted direction from customers and vendors to influence the design and implementation of new functions. This all takes time, but I would argue that it is worth it.

Combining the two dimensions is magical. What's better than a developer who first knows the potential of hardware and architecture and combines it with knowledge of the customer's needs and business to produce something that brings true value? Nothing is better. Well, nothing except 40 years of developers doing that.