If heat rises, why is it colder at the top of mountains?

This blog will not answer the title question, but answer a much more relevant question: how and why should we hunt knowledge every day. It is inspired by my son, who asked the question and James S Bach’s “Secrets of a Buccaneer Scholar”.

First, about my son, then about James Bach. At six, my son loves science. Every time he asks questions like “why is the sky blue?” and “how long would it take to drive to the moon”, my wife and I dig into the answer with gusto. He loves math for much the same reason. We revel in his curiosity and encourage it. I have learned a lot teaching him.

Now, about James Bach. I found his book while looking for books about Software Testing. While James Bach also writes books about software testing, this book was about learning. It describes how, after dropping out of school with only an 8th grade diploma, he learned Assembly Language Programming, became a software tester, and now consults other software testers. It was his habit of self-education that gave him the edge over his college educated competition.

I’ll elaborate on just a few of his “great secrets”.

To learn something, it should be relevant. He calls these Authentic Problems. While I’ve studied several foreign languages in school, the 2-3 that I speak well I learned while living abroad, and are not the languages I learned in school. Likewise with software. The most useful software knowledge that I’ve gained has been because I needed the knowledge at work to solve a problem. I take the problem home and beat it into submission.

Cognitive Savvy. You have to understand how you learn. Everyone will learn differently. I learn well by processing things in multiples ways. For example, this blog entry will be my Toastmaster’s speech Tuesday. I know that I often fragment ideas as I restructure on the fly, so I videotaped myself reading it to ensure it flowed well.

Other minds. Woodrow Wilson said, “I not only use all the brains that I have, but all that I can borrow.” Bach refers to hunting knowledge in packs. I refuse to work alone because I want the ability to come up with crazy ideas. Some will be brilliant, some will be chaff. Other minds attacking my ideas allow me to be brilliant.

I will conclude by how I answered my son’s query: I dove in and made up a plausible answer on the spot. Diving in is always the first step across a river. Perhaps I could have solved it on my own, but I thought it would be more fun to hunt down the answer with my pack of friends and relatives. The most amusing answer was, “Because you’re further away from hell.” The most thorough and correct answer came from my brother, who has climbed all of the 14ers in Colorado. This was a very authentic problem for him. Now that I know the answer, I’m trying to understand it well enough to explain it to my six year old son. Finding the answer was a great hunt.

Respect, don't trust: A little philosophy on the emotional life of the software team.

I haven't heard much talk about the emotional world of the software engineer, so I'll offer some late night ruminations on the topic.

The deliberate conflict between the engineers making software and quality assurance fascinates me. Here's why: While software engineers passionately try to make things work, QA engineers diligently work to prove that the software is horrible. If you put this behavior in another context there would be pain and strife. One person persistently pointing out someone else's flaws. How rude!

In a healthy team, this is not discord, it is work and sometimes even fun. It's beautiful to watch. The graceful dialectic offers some life lessons and gives me hope in human nature. We can be honest and frank, we can seek truth and scorn "white lies". We can do this respectfully, with passion, and without hurt.

Here is how software teams make this work.

Respect, don't trust 

QA never trusts development. A QA who trusts the developer would believe -- without empirical proof -- that the software works. That would be silly. QA's role is to aggressively and skeptically to prove the developers' work flawed. QA seeks to prove. While mistrusting, the QA team respect the developers intelligence, creativity and passion. Respect does not require trust in this relationship - It a relationship where mistrust and skepticism are possible, emotionally, because of the teams' strong mutual respect. 

Trust and faith are good for your wife and your religion. Anyone or anything less than these gods deserves respectful skepticism. 

Be fearless of mistakes - mistakes and corrections make the world work. 

There are few situations in life where products must be right the first time. This is true in assembly line manufacture and live virtuoso performances. Most of life is about mistakes and corrections. In a conversation, if we don't understand each other, we dialog and correct. If I don't catch a fish on the first cast, I can try again. Bikes constantly wobble a little as we balance from side to side.  

Productive software engineers don't fear mistakes. Engineers who fear mistakes hoard their work for weeks, keeping it to themselves. Finally, pride satisfied, they throw an overwhelming amount of change of the wall to QA. QA needs weeks to validate - the cycles take many times longer than they should and the product is invariably late, rough in the places that need to be smooth, and polished in places where it doesn't matter.

Software works better when the developer fearlessly checks in small pieces of work continually. A little due diligence - send to to quality assurance. The right things are fixed and fast. Back to the physical world analogies: A bicycle with small wobbles moves fast. The only bike that does not wobble is probably smoothly falling over. 

Back to respect: The developer can fearlessly check in because of the respect offered from QA. QA respects the daring of the developer showing her raw work to the team.

( The final product is of course flawless. Mistakes the customer sees are bad. I'm talking about the early life of software. Typically, we make hundreds or thousands of bad builds before we make the final release build. So, the customer sees the one "right" build, but the life of software development is a story of continual mistakes and corrections. )

A defect in software is not a defect of the author.

Defect systems offer a powerful emotional tool - we don't talk about the systems this way very often. I rarely hear, in software, QA walk up to an engineer and say, "You stupid lout. You made the CSS wrong and the now the border of this table clips the text."

Instead, the developers does there best to make something pretty. QA digs into it, fines a tiny flaw, and files a bug report into a bug database. The bugs get prioritized, assigned out and fixed. The separation means that the flaw never gets personal. The author can handle a statement like "There is a flaw in the software" much better than "You broke the software."

All software teams think defect systems are essential for organization - I argue they are also essential to avoid getting distracted by the emotions of making mistakes.