Programming psychology

A friend of mine was dreaming of writing the first book about programming psychology, and after a year of collecting anecdotal material he found out there is more than one book on the subject. This sounds strange and stupid, but smart people try to reinvent the wheel even more often than people who are not so smart. They think: if there is such I thing I would know it by now, which is usually not the case. In this post, we will address some classical aspects of programming psychology. For reference, you can read this, this and this publications.

Knowledge vs strategy

The key differentiator of an expert programmer vs a novice is a smart usage of effective strategies. The basic knowledge of the two types of programmers would be quite similar: the programming syntax is very simple, and one can master a new programming language in a week or so. The hard experience and effectiveness come from various strategies which are hard to acquire and require experience. For example:

• Planning. An expert programmer will spend some time planning the process, defining how different pieces of code should work together, selecting external libraries to do some heavy lifting, maybe drawing some diagrams of data flow or usage scenarios.
• Coding style. Balancing clear and readable code with concise naming strategy, reasonable file size, classes and functions hierarchies is a fine art. A novice would not understand even the issues facing the expert and would write a code that will be very hard to understand, debug and support.
• Work distribution. An expert has a feel of how much time each part of the project will take, and can balance the expectations of other people accordingly. A novice would probably overpromise and under-deliver, often work into the night making a lot of bugs, try to “cut some corners” to gain extra time.
• Debugging. It is not a secret that 80% of the programmer’s job is debugging. A novice makes significantly more bugs than an expert, an expert might be mentoring several new programmers and may need to clean up after them. The first thing an expert does when debugging is defining a clear process and test points for debugging, maybe write a testing application. An expert may use some complex automatic tools which a novice is not familiar with. The vast experience of the expert also helps, since many problems repeat themselves.
• Teamwork. An expert will likely understand his own shortcomings and use a wider community to overcome them. Experts often invite external consultants and post questions in professional forums. Experts use clear APIs and version control in a way that enables many people contributing to the project. Documentation is treated as a nuisance by novice programmers, experts understand that they will need to pass their code to other people.

A combination of hands-on practice, mentorship from an experienced programmer and extensive reading may make you an expert. Do not expect this to happen overnight. If you are very talented this will take you 6 month, most people never become expert programmers…

Comprehension and generation

Knowing how other people think and how different libraries work together, you may be able to write very little code. After all, most problems you are facing have been faced by others before you. A novice programmer will be intimidated by thousands of lines of unfamiliar code. An expert will look for patterns. The decision of using a piece of code or scrapping it for future use is a hard decision to make, with many risks in either case.

• There is a difference between write code and reading code, each skill needs to be practiced separately.
• Programming involves mapping between the problem being solved and the code being written. This mapping may be complex, and an expert will often use templates, such as design patterns. An expert will typically recognize design patterns used by others.
• When reading code we generate series of hypothesis, used as markers for our understanding. These hypotheses may be modified, but we seldom change the mapping between different hypotheses. Quite often our markers follow the logical structure of functions and classes in the code.
• Novice programmers will try to write either an oversimplified code that will not treat many situations or an overly generic code that will be very hard to debug and maintain. Some language structures are considered to be not friendly for the debugging process. Experts will think twice before using templates, void pointers, friend classes, explicit memory handling, hard-coded values etc.
• An expert will try to minimize the cognitive load, by dividing the process into a large number of smaller steps. Novice programmers work line by line, while experts manipulate with larger and more meaningful chunks of knowledge, which they can also document effectively.

If you work with meaningful chunks of code, you can generate hypothesis when reading and generate patterns when writing. Both can serve as nodes in your mindmap and you will be able to use meaningful constructs. Working line by line is a novice habit, and it will likely generate cognitive overload.

Programming as self-expression

While programming appears to be a pretty technical job, good programmers are very creative and have very good working memory skills.

• A generic solution will probably fail in each particular situation, you need to generate specific solutions in each case based on the parameters of the relevant situation.
• Maintaining a clear mapping between the problem being solved and code being written is a demanding task for your working memory.
• You need to be devil’s advocate and address all boundary conditions.
• The code needs to be organized in a way that will enable easy debugging and optimization. An expert will know where “the fat” is and will try to optimize it first.
• Unexpected problems will rise, and solving them will require all of your creativity.
• Proper teamwork with very strange people may require understanding and application of proper communication, brainstorming, and innovation management techniques.

Even an expert will likely generate an overly generic code, will use some tools too complex for a given job, will not address some integration issue, write the code longer than expected and do some other typical mistakes. We are consistent in our mistakes since they are a projection of ourselves.

Expert programmers think in meaningful chunks and not line by line. Experts use proper strategies for every scenario. To become an expert programmer, it helps to understand better not only how machines process our instructions, but also how people think and why they write the code the way they do. Knowing your own strengths and weaknesses we become more valuable team players, knowing strengths and weaknesses of other people we can manage them more effectively.