When I was in community college studying information technology, most of my classes were at the Woodbridge campus not too far from the National Museum of the Marine Corps where I worked. However, one of my classes was at the Manassas campus and it wasn’t even the main campus in Manassas but rather a satellite location off of University Blvd back in an office park. I honestly don’t remember why I decided to take Software Design there instead of at Woodbridge but I’m glad I did.
Professors can make or break a class. It’s true. I’ve learned this the hard way about bad professors but here in this class I learned that a professor can be a life changing force for good beyond what you expected from the curricular program of instruction. While other students I knew at the Woodbridge campus complained about their Software Design classes, I rejoiced that for me, Software Design class was the highlight of my week. I would get off from work and drive into the glowing sunset with eager anticipation of the class ahead.
Professor Brooks was a man of average height with a medium beard who dressed business casual because that’s how he dressed at his main job before he came to teach us. He was adjunct faculty at this community college but his primary job was at a think tank. He would put his left hand at the small of his back while he wrote on the dry erase board. For this class, he ordered a textbook that was not the university standard. I ordered a copy online and read it before the class started.
On the first night, we all showed up with different textbooks. Apparently, the college bookstore had not ordered the textbook that Professor Brooks had selected. So, for those students who went to the college bookstore, they came with the standard university text; a boring piece of material focused on diagram flow charts. For those of us who bought the book described in the syllabus, we had a gem of a find by an Australian author who explained the concepts of abstract problem solving in very approachable ways.
Professor Brooks announced that we would move forward with both books since the bookstore had made a mistake. He selected readings from each book so students could study regardless of which book they had. But the most important part of the class, was in the classroom. Those of us who had the Professor’s book fared better though because it was a superior text.
We used pseudocode to describe how to perform daily processes such as getting dressed or making a pot of coffee. Pseudocode, in our case, was just plain English word commands that were styled after computer programming languages but were somewhat simpler and not necessarily programming-language-specific. These explorations in pseudocode led to discussions about how we analyze processes. It was not easy figuring out how to break down making a pot of coffee into it’s smallest steps and learning how to verify that each step had been completed before moving onto the next step. As we wrote more pseudocode and broke down more processes into step-by-step procedures with verification, we began to discuss meta-cognitive topics. How does a computer know that it knows something? How do we know that we know something? How do we analyze processes? How do we verify that we have arrived at acceptable solution?
For many students, abstract thinking was not their thing. Some would surf the web on the class computers sitting at each desk. One guy read anime comics the entire class and left as soon as class was over. Two girls deliberately sat next to me every class no matter where I sat. One of them perused their social media pictures of themselves in various ceremonial Indian garb. The other was an artist and spent the class doodling pictures.
I believe that this Software Design class was used as a filtering class designed to remove those without the aptitude for it from pursuing IT any further. Within a few weeks, our class size had gone down considerably. I found out from my fellow students in other classes that this had happened in their Software Design classes as well. There were two reasons the class was hard for students. One, it required abstract thinking and problem solving which is not easy for everyone. Second, the traditional textbook and teaching method was dry, boring, and focused on minutia. Fortunately for those of us in Professor Brooks class, we only had to worry about the first reason. Students in other classes were not so lucky.
I remember how my classmates at the Woodbridge campus lamented the tedium of drawing endless process flow charts and getting dinged for formatting errors rather than getting taught how to understand how computers think and how to solve problems through code. Their professors spent so much effort on formatting that they seemingly neglected the weightier matter of learning how to design software. Our class benefited by the fact that our professor didn’t focus on irrelevant details (we never once drew one of the process workflow diagrams) but focused instead on teaching us how to think. The class was tough but for the right reasons. The drop rate was still high but I think that was unavoidable. For those of us who stayed, we couldn’t get enough of it.
The professor would start each class by reviewing student samples on the huge white board. Volunteers would go to the front of the class and show how we had solved this week’s assignments by writing out our pseudocode on the whiteboard. If ever we made a mistake, we would discuss it as a class and fix it together. No two people ever solved a problem the same way. Normally we only had three student examples up on the dry erase board and it was a real eye-opening experience to walk through each volunteer’s mindset and approach to solving the problem. We all made mistakes at some point or another. But that didn’t matter at all. We would talk through them and fix them. Professor Brooks cared about us understanding the material and mastering the concepts rather than just checking off boxes.
Three to six of us would stay after class ended at 9PM and we would talk with the professor for hours sometimes as late as 11PM. We would get kicked out of the building and continue talking in the parking lot. We would talk about how to break down problems into smaller pieces. He walked us through some of the types of problems he tackled at work; huge complex problems with no standard solution or method. He worked on open-ended questions that were largely undefined and how he would have to approach finding the definition. He would have to not only define the answer but also frame and define the question so that a path toward an answer could even be developed. We began to realize that there is a whole world out there of important questions that may seem unanswerable but can be answered if approached properly.
We also learned that you have to qualify your answers. You have to qualify your definitions. You have to explain what you know, what you don’t know, and allow for what you don’t know that you don’t know. You have to ask questions about the question you’re trying to answer. There is more than one way to define a problem and more than one way to answer a problem. You may need to define the problem several different ways and then find different answers for each. Very often, when approaching an unanswerable/open-ended/undefined problem, you need to ask more questions from those who gave you the problem. The correct response to a question, is often to respond with more questions.
This may seem simple enough but it was a novelty to me. Before this class, I tended to take the world as I perceived it to be and oversimplified my mental processes. I didn’t challenge what I thought I knew. I didn’t allow for the fact that life is very complicated with many variables and possibly more than one right answer to a given problem. I didn’t use to ask questions in response to questions; I just assumed I knew the bounds and limits of the question or I just felt too foolish to ask clarifying questions. I didn’t use to qualify my answers or openly admit the limits of my knowledge. I would pass on information that I had heard or reasoned out in my head as though it were fact.
After this class, I would be clear about what I did and didn’t know when asked a question. I would respond to unclear or open-ended questions with clarifying questions. I would spend time analyzing, understanding and describing a problem rather than just imagining that I understood a it. I would qualify my answers with the limitations of the information that I had. When asked a question that I realized I didn’t know the answer for certain, I would consult an authoritative source normally via the internet to verify the truth. People got used to me being very honest about what I didn’t know. They got used to me searching for and verifying the truth rather than parroting what I had come to believe.
How do I know that I know something? Have I verified my knowledge? Can I provide an answer based on limited or unverifiable information but qualify my answer properly so as to be accurate and not deceive people? Can I make sure that bad information stops with me and that I teach people to qualify and verify their information by my example? Maybe I could phrase answers like this: “I think this is the case but that is based on hearsay from people that I trust and could be inaccurate. I would verify or check this against such-and-such a source to be sure.”
I began to realize that there are at least two types of people in this world: those who don’t think about and question their own perceptions and those who do. It is important to be humble about what we know or think we know and to not be arrogant about our knowledge. We gain more credibility by saying “I don’t know” or “I think this to be true but my knowledge is based on <insert qualifications here> and I haven’t verified it” than by authoritatively passing on unverified information.
Professor Brooks took an entry-level software design class and turned it into a life-changing experience that taught me how examine how I perceive and frame my world. By studying how to tell computers how to think, I ended up learning how to think about how I think. One night, I talked with Professor Brooks about becoming a mathematician like he was. I guess I wanted to follow in his footsteps since he had made such an impact on me. He told me that the methods of problem solving and analysis we had learned in this class could be applied to any field and that it is needed in all fields of study. It wasn’t necessary for me to be a mathematician but rather for me to apply these methods in my own endeavors. Since then, I’ve used them in my career in IT, and in studying history, and in many other life pursuits.