Learning Through Books on Correctness and Pattern Recognition
Recently, a friend asked a question about the particular skills possessed by software engineers.
What are the unique skills that software engineers practice?
Drawing from my experience led me to an opinion. The idea I have come to realize over time is that I enjoy the meta of programming. The skill of learning the meta, or how to do what we do better, includes reading many well known books in context. I took specific examples of what I read over the years, applied it to my own observations practicing in the field and I answered in a way that I believed was most pragmatic.
Me: In my opinion, if we think universally, I would say it is the practice of correctness and pattern recognition*. These are some of the skills that are unique to software engineers.
Let’s exam these skills to add context.
Correctness is very much related to the how and why we build things the way we do. In organizations, it is most closely associated to the correctness of what the business must solve for its customers. Software that is written well follows this thinking.
Correctness is seen in engineering as how correct the how is so that the solution for business can continue to be solved with high reliability. It is and must be a balance of strategy (designing) and tactics (execution). The examination of the how’s how in a vacuum appears well in chapter four of Programming Pearls — Writing Correct Programs.
… keeping code simple is usually the key to correctness.
— Jon Bentley
Pattern recognition is strongly tied to the organization of that correctness by creating the necessary abstractions and component boundaries. Pattern recognition leads to concepts of reuse to modularize and isolate code. We monitor duplication, find areas that can be reused, and refactor complicated parts of code. It is what software engineers do well. Our attention to that detail is vigilant. We recognize knowledge as it is created over and over again. Then we simplify.
Pattern recognition is discussed at length in the community and there are many sources to read up on their techniques. The origins where I learned about this skill reside in chapter two of The Pragmatic Programmer — The Evils Of Duplication.
Make it easy to reuse. DRY — Don’t Repeat Yourself.
— Andrew Hunt & Dave Thomas
A Teachable Moment
Once I gave this response, my friend followed up with another question.
If correctness and pattern recognition are these skills, how do you teach them?
Of course, my answer was simple enough.
Me: Locate these books, set the environment, and work through by showing examples. Set the expectation of learning and practicing these meta skills while delivering value to business. Why? Complexity. This is the best investment of learning the skill of balancing complexity that I know of. It also results in engineers who become more confident over time.
My mentoring has been focused around these books and around these particular skills. But it made me realize there are few out there that invest heavily in the meta, apart from doing the work without realizing it. The vocabulary of the meta is something I’ve have interest in. My writings on problem decomposition (correctness), and organization (pattern recognition) in the real world were difficult to see when in the heat of delivery.
At about the same time I had thought about writing this brief on these skills, another book was mentioned because I’d been asking around. A professor at Stanford has been teaching a course on the meta and has resulted in a book of some of his course findings. I was shocked when I found out that he has the same gripe as me, I purchased the book and devoured it. From chapter thirteen, A Philosophy Of System Design.
Engineers tend to be very detailed oriented. We love details and are good at managing lots of them; this is essential for being a good engineer. But, great software designers can also step back from the details and think about a system at a higher level.
— John Ousterhout**
In my opinion, correctness and pattern recognition are skills*** that software engineers should strive to understand and do well at. The result is higher quality software. All other unique skills, if there are others to categorize, may very well be based off these. I invite others to share examples of meta skills they have practiced over time.
Fundamentally, correctness and pattern recognition have tie-ins to outcomes of complexity (also known as cognitive load). There needs to be a way to balance both intelligently so that the complexity is mitigated. In essence this is why these skills are, in my opinion, the distillation of what we do.