The Psychology of Computer Programming

Editor's Notes

• #2: Hello, my name is Dan Stewart. My Web address is Stew Shack dot com.
• #3: There’s a fantastic book titled, The Psychology of Computer Programming by Gerald M Weinberg. I read the silver anniversary edition which has comments by the author.This book was on several people’s “must read” list and now I know why. Not only does it cover the human side of programming, it also has timeless concepts that we can use today. Is this book relevant? Definitely!
• #4: Let’s start with the human side. Reading about egoless programming gave me a lot of confidence. The best programming is done by teams and not by a single genius. The team’s strengths make up for individual’s weaknesses. When a programmer’s ego is wrapped up in the program, they “own” it. What happens when the team finds a bug in it? The “owning” programmer feels embarrassed. Maybe the team picks on them, because they buy into this “owner” fallacy. We are not our code! If we refuse to own a program, we welcome the team into the process. Once the team realizes that they own it too, bugs are no big deal. We find them, we crush them, together! If a programmer’s individual intelligence is not important, then their temperament or personality is. They have to work well with the team. This means admitting weakness. Admitting that you do need help, that you don’t know everything, and that can be a humbling experience.
• #5: The cycles and iterations that were mentioned in the book are the typical Waterfall sections. These include design, code, test, and release.I think we can agree that the Waterfall approach only works with software that has a set criteria. I’ve heard it said, “Walking on water and designing software to spec is easy if both are frozen.”Even in the 1970’s the business was constantly changing. New discoveries are made, turning in requirements to a project manager was pointless. The Agile approach embraces change by working in short iterations. The team designs, codes, tests, and releases sometimes in as little as two week cycles. Realize that change is inevitable and work towards showing your customer something that they can change as quickly as possible.
• #6: What traits does a successful programmer possess? First, the ability to tolerate stressful situations. The author is not just talking about the bug that has your manager breathing down your neck to fix. He’s talking about long-term stress. Multiple days, weeks, and even months of grinding out a project. As programmers we have to be able to handle stress through diet, exercise, meditation, and even the occasional vacation.The code you write is like sand of a Buddhist Mandala. Each little colored grain is carefully placed to create a beautiful design. Then, when it is done and admired, the monk will sweep it all up into a jar. Nothing lasts forever. We have to relax and realize that change will come only after we are done placing the last grain of sand.Neatness, a clean desk is the sign of a clean mind, or is it a crazy mind? What is the structure of your program? Are things put where they belong? Are you using a patterns like MVC with clear places for models, controllers, and views?Humility with our own ability has shown to reduce bugs. If we humble ourselves and realize we probably made a mistake, we will look for it. If we humble ourselves to allow the team to review our code, they will find it. We should be happy the bug was found before it made it’s way into production. Without humbleness we would have false confidence in the code.Assertiveness sounds like the opposite of humbleness. It is, and we should not be humble about our ideas. We should not be humble about our morals. Don’t get stuck in analysis paralysis. Just do it! You know it will change later, so why worry about it?
• #7: Doctors, lawyers, and programmers have to constantly learn. They have to study to provide the best service to their clients. Each person has their own unique way of learning. The way might even be depend on what they are trying to learn. The author gave an example on learning a programming language. Maybe to learn it, the programmer has to do it. Contrast that with learning a high level concept like Object Oriented Programming. Learning OOP might be best done in a classroom, or watching a video.The first step is to get motivated to learn. Ask yourself why? If you don’t get a good answer, then find a reward for learning. I will treat myself to a dinner if I finish this book on the Psychology of Computer Programming. Learn about the concept before you get bogged down in the details. A great example of that is Test Driven Development. You can’t learn TDD by writing unit tests. You have to start with how TDD helps, what makes up a good test, what should be tested, and end with writing a test.Try explaining how a computer mouse works to someone who has never used one. It’s pointless, because it is irrelevant to them. Now sit them down at a computer and ask them to click on an icon using the mouse. Now they have a reason to learn and the training to start.It’s ok to make mistakes. Learning can’t begin until you are willing to fail and fail often.Try to tackle a subject using different approaches. Read books, or blogs, download a podcast on the subject, watch a video, even attend a conference. What worked for you? You can tailor your learning to suit the way you learn.
• #8: I would like to thank Ugly House Photos dot com for the wonderful 70’s home photos. After reading this book, I gained a lot of confidence in my abilities. I discovered my strengths and some areas that I’m working on. I realized that programming isn’t just about 1’s and 0’s, it about people and personalities.