By Gerald M. Weinberg



Programming is not reduced to just a skill set, but by its social aspects is also a complex psychological activity, including a certain mindset, particular social arrangements, and a bizarre relation with human created tools (machine / programming language).

Big ideas

  • Programs have intrinsic values that can be measured through both objective (being on schedule, respecting specifications) and subjective and scales (adaptability, efficiency, +language criterias)
  • Programmers are getting satisfaction through material rewards, challenge and interest, general conditions of work and leadership. The three first criteria tending to be corporately fixed and industrially homogenized, the fourth (leadership) tend to be the biggest differentiatior.
  • Programmers value creative work and professional competence. Therefore it is easier to exert leadership and influence over developers by being a soft-spoken programming wizard than the world’s fastest talking salesman.
  • Only the leader who is ready to step down has a real chance of success
  • When a supervisor is responsible for work he does not understand, he starts rewarding workers not for work but for appearance of work.
  • Evaluating intelligence and a good job for problem solving because it is hard evaluating how much problem we are not having as a consequence of that problem solving. If I spend 3 weeks working 14h x 7 days a week to resolve something, it is seen as great involvement. But better is the guy who resolves something in 5 days x 8 hours. Although it won’t be seen as wonderful.
  • The 2 major influence to exert on a programmer’s performance are motivation (desire for working and training(what he knows that is needed for the job)

Ideas worth noting


  • Programs have been written under a certain context, with psychological reasons for why it is the way it is (limitations, constraints, skills, etc.)
  • Learning and studying programming might invoque common pitfalls such as:
    • using introspection without validation
    • generalization of a too narrow base
    • observing the wrong variables
    • interfering by observing
    • generating data instead of information
    • unjustified precision,
    • etc.
  • A programming team has both formal and informal social mechanisms, the latter must be understood before changing things around to prevent problems coming from psychological phenomenons
  • Programs, as behaving following the programmer’s transcripted mind, can be seen somehow as an extension of him/herself. Therefore one shall be cautious before criticizing a developer’s code, because this is also criticizing the developer.
  • Psychological state of a given developer influences the quality of their code directly on both subjective and indirectly on objective levels. (on bad days, bad code)
  • Principles for language design / what makes code beautiful: uniformity (doesn’t contradict itself), compactness, locality and linearity (you don’t need to browse all the time to understand a local declaration, you can read from top to bottom), tradition and innovation (is re-using the folklore, goes in a “good direction”).
  • Documentation is an extent of programs that is part of programming itself, but turned to humans.

Personal activity

  • Parkinson’s law: work expands to fill the time allotted.
  • To achieve consensus on goals in a group, no better method than having the group fixing the goals.
  • Resolving conflicting ideas on team goals is paradoxically more critical when differences are almost indistinguishable. Persistence of this kind of behaviour can be interpreted as an underlying bigger conflict.
  • Programming implies learning new things all the time → this implies that people get less content with limited responsibilities all the time. To make a project successful over time, a manager must treat the team as a developer plant: fresh juniors as input, experienced leaders as output, flow of people bumping up in the middle.
  • Status is an important part of reward for developers, that is amusing: additional tokens, toys, special advantage, title, etc.
  • Developers take assumptions when there is unknown. This can lead to misalignments.
  • Different minds call to different skills and fields of application - patching requires being synthetic, where testing requires being analytical. A team that gives work depending on mind should do a better job.
  • It is hard for a developer who mastered a technology (dead-end) to switch to something he doesn’t master cause it requires giving up on satisfaction temporarily.

Social activity

  • Programmers tend to be aware of their opportunities and involved in decisions. This leads to programming teams being democratic. In democratic teams the leadership flows through the team. Although it is never spread equally amidst the members. The important factor is not equality, but that leadership is spread given the reality of life and not imposed from outside.
  • The leader is a carrier of information with the external world of the team.

  • Fitting with the team on a personal level is as important as skills - the sociological games makes that both the work and personality are judged.
  • Persons who are not fit personally or on a skill level can be distressful for the entire team and lowering the general function rather than just their job. Better rid of them.

  • Problems of behaviour or personal implications usually have a deeper source, resolving them requires finding the source and correcting it. Sometimes (when it’s personal) it cannot be done.


  • Jean Sammet: Programming Languages: History and Fundamentals