Programming quotes

From Motley Bytes Wiki
Jump to: navigation, search

Contents

F_Terry_Baker

Code Library

“The most important of these is a development support library which encourages the visibility and manageability of the product, as well as reduces clerical effort on the part of the programmers. The library is typically maintained and operated by a programming librarian who serves to control the programming assets and to provide the necessary services for both programmers and management. As a result of its use, the entire project is maintained in a centralized, up-to-date, visible form which makes its status immediately apparent to code-competent software managers and makes it possible for programmers to answer their questions directly without relying on others.”
  • Source: Baker, F. T. (1975). Software Management Through Improved Programming Technology. ACM ’75: Proceedings of the 1975 Annual Conference, 286–287. https://doi.org/10.1145/800181.810346

Program Ownership

“A program or program system is a group product and should be produced in a way which allows and encourages maximum knowledge of it by each person involved. Furthermore, the management responsible for its development should be able to determine its status directly and not depend on the programmer's description of his progress on an 'invisible product'.”
  • Source: Baker, F. T. (1975). Software Management Through Improved Programming Technology. ACM ’75: Proceedings of the 1975 Annual Conference, 286–287. https://doi.org/10.1145/800181.810346

Programmer Clerks

“...programmers typically get less programming done than they could because they do a great deal of clerical work directly.”
  • Source: Baker, F. T. (1975). Software Management Through Improved Programming Technology. ACM ’75: Proceedings of the 1975 Annual Conference, 286–287. https://doi.org/10.1145/800181.810346

Programmer Management

“With each programmer doing his own work in his own way, managers are so busy just trying to find out what's going on and why things don't fit together, that they don't have any opportunity to improve quality and reliability.”
  • Source: Baker, F. T. (1975). Software Management Through Improved Programming Technology. ACM ’75: Proceedings of the 1975 Annual Conference, 286–287. https://doi.org/10.1145/800181.810346

Software Management Support

“While the components of the methodology are relatively easy to learn and apply, they are most successful when the management of the organization understands and encourages the process.”
  • Source: Baker, F. T. (1975). Software Management Through Improved Programming Technology. ACM ’75: Proceedings of the 1975 Annual Conference, 286–287. https://doi.org/10.1145/800181.810346

Thinking Versus Coding Errors

“In short, it is the thinking errors, more than the coding errors, which limit programming productivity.”

Friedrich_Ludwig_Bauer

Tinkering versus Engineering

“The time has arrived to switch from home-made software to manufactured software, from tinkering to engineering.”
  • Source: Quoted in the book entitled Mechanizing Proof: Computing, Risk, and Trust by Donald Mackenzie. Published in 2001 by Massachusetts Institute of Technology. ISBN: 0262133938.

Software Engineering Too Difficult

“Software engineering is the part of computer science which is too difficult for the computer scientist.”
  • Source: [Bauer; 1972]. A paper entitled Software Engineering. Written by Friedrich Ludwig Bauer. Published 1972 in Information Processing 71: Proceedings of Ifip Congress 1971, volume 1. ISBN: 9780720420630.

Joe_Biden

Coal and Programming

“Give me a break! Anybody who can throw coal into a furnace can learn how to program, for God's sake.”
  • Note: The comment was met with silence from the audience.

Robert_N_Britcher

Software People Rare

“But the number of people who know how software is written is small. Most of us are not talking, or we are saying 'Trust us'.”
  • Source: Britcher, Robert N. (1999). The Limits of Software: People, Projects, and Perspectives. Reading, MA: Addison Wesley. ISBN 0-201-43323-0. Page 17.

Programming Not Science

“Programming is not a science, and there is no theory of programming. If there were, everyone would approach programming the same way.”
  • Source: Britcher, Robert N. (1999). The Limits of Software: People, Projects, and Perspectives. Reading, MA: Addison Wesley. ISBN 0-201-43323-0. Page 17.

Theory Informs Programming

“...theory has informed Programming largely through programming languages.”
  • Source: Britcher, Robert N. (1999). The Limits of Software: People, Projects, and Perspectives. Reading, MA: Addison Wesley. ISBN 0-201-43323-0. Page 18.

Programming Demands Little Formal Training

“Programming demands very little formal education or training.”
  • Source: Britcher, Robert N. (1999). The Limits of Software: People, Projects, and Perspectives. Reading, MA: Addison Wesley. ISBN 0-201-43323-0. Page 18.

Theory and Programming

“...when it comes to programming, theory and practice may never be on speaking terms.”
  • Source: Britcher, Robert N. (1999). The Limits of Software: People, Projects, and Perspectives. Reading, MA: Addison Wesley. ISBN 0-201-43323-0. Page 18.

Keywords: Programming_quotes Theory_quotes Practice_quotes Speak_quotes Term_quotes

Programming is Hard

“But programming is hard.”
  • Source: Britcher, Robert N. (1999). The Limits of Software: People, Projects, and Perspectives. Reading, MA: Addison Wesley. ISBN 0-201-43323-0. Page 24.

Keywords: Programming_quotes Hard_quotes

Human Element

“The real scoop on programming and software is the human element. I didn't know Alan Turing or John von Neuman or the other inventors, but I've known plenty of programmers. We are just like everyone, part this, part that. Except we have to deal with enormous complexity, which springs upon us only after we are too far into what started out to be kind of fun - coding an algorithm and watching it run on a machine. Then it's too late and it all becomes work, very stressful work.”
  • Source: Britcher, Robert N. (1999). The Limits of Software: People, Projects, and Perspectives. Reading, MA: Addison Wesley. ISBN 0-201-43323-0. Page 28.

Lines of Code

“...programmers abhor the line of code. When managers speak of it, programmers quicken their step. Most of them know that the line of code is as central to the meaning of a program as the period is to the meaning of Tolstoy's Anna Karenina.”
  • Source: Britcher, Robert N. (1999). The Limits of Software: People, Projects, and Perspectives. Reading, MA: Addison Wesley. ISBN 0-201-43323-0. Page 50.

Limits of Testing

“The limits of software are never more obvious than in its testing. Software systems are beyond discrete and statistical analysis. A single incorrect state - out of two to the trillionth states - can down a rocket: To find such a fault in a software system would require a hundred generations of programmers - but after the first failure is found and fixed, all bets are off; they wouldn't be testing the same system anymore. We can design and build fail-safe systems, but can we know we did?”
  • Source: Britcher, Robert N. (1999). The Limits of Software: People, Projects, and Perspectives. Reading, MA: Addison Wesley. ISBN 0-201-43323-0. Page 56.

Programming_Straining

“If programming symbols were made of steel, we would surely notice men and women straining to hoist thousand-pound beams with a single hand. But alas, their weight is intellectual...”
  • Source: Britcher, Robert N. (1999). The Limits of Software: People, Projects, and Perspectives. Reading, MA: Addison Wesley. ISBN 0-201-43323-0. Page 111.

Verification Percent

“Over 70 percent of the technical budget was spent on verification activities such as inspections and testing; only 30 percent was spent designing and writing code.”
  • Source: Britcher, Robert N. (1999). The Limits of Software: People, Projects, and Perspectives. Reading, MA: Addison Wesley. ISBN 0-201-43323-0. Page 117.

Programming Miracle

“Computer programming is a bit of a miracle.”
  • Source: Britcher, Robert N. (1999). The Limits of Software: People, Projects, and Perspectives. Reading, MA: Addison Wesley. ISBN 0-201-43323-0. Page 128.

Keywords: Computer_quotes Programming_quotes Miracle_quotes Difficulty_quotes

Difficult Programming Shortcuts

“So developing software correctly is difficult. Developing vaccines and medications without side effects is difficult. But neither enterprise will benefit from shortcuts.”
  • Source: Britcher, Robert N. (1999). The Limits of Software: People, Projects, and Perspectives. Reading, MA: Addison Wesley. ISBN 0-201-43323-0. Page 128.

Mixed Abstractions

“... computer systems and programming attract brainy people because symbol systems mix abstractions. One thing appears to be something else depending on how you look at it.”
  • Source: Britcher, Robert N. (1999). The Limits of Software: People, Projects, and Perspectives. Reading, MA: Addison Wesley. ISBN 0-201-43323-0. Page 129.

Reuse Sharing and Copying

“Sharing is one side of re-using; copying is another.”
  • Source: Britcher, Robert N. (1999). The Limits of Software: People, Projects, and Perspectives. Reading, MA: Addison Wesley. ISBN 0-201-43323-0. Page 129.

Keywords: Sharing_quotes Reuse_quotes Copying_quotes Programming_quotes Side_quotes

Programmer Errors

“Programmers will always make errors.”
  • Source: Britcher, Robert N. (1999). The Limits of Software: People, Projects, and Perspectives. Reading, MA: Addison Wesley. ISBN 0-201-43323-0. Page 132.

Keywords: Programmer_quotes Programming_quotes Error_quotes Make_quotes

Fault Layers

"Layer upon layer of programs will build on faults as they build on features.”
  • Source: Britcher, Robert N. (1999). The Limits of Software: People, Projects, and Perspectives. Reading, MA: Addison Wesley. ISBN 0-201-43323-0. Page 134.

Important Development Things

“The single, most important thing is that the individual programmer needs to be given total responsibility and control of the programming, including its function... eliminate project design and review as an exhaustive and rigorous process. Most of the design and review should occur as the program is written. ... Monitor progress on the project by talking to the individual programmers as [code] is being written. ... You must trust developers on the project to create a good product. ... Sometimes there are failures. ... The important thing is to fail quickly so you have time to find another approach. ... Developers must also feel free to say what they think to their supervisor. ... Managers should be the best programmers; ...There should be no overtime pay. ... Use profit-sharing and bonuses to get awesome products. ... Developers should each get their own office. ... Eliminate the dress code. Avoid meetings at all costs. ... Writing software is a lot like writing a book. Almost anyone can write garbage; very few can write a best-seller.”
  • Source: Britcher, Robert N. (1999). The Limits of Software: People, Projects, and Perspectives. Reading, MA: Addison Wesley. ISBN 0-201-43323-0. Page 155-156.

Programming and Engineering

“Some aspects of programming will remain forever beyond the grasp of classical engineering. Programming is too much like writing, too personal and private, too much under the spell of hyperbole, marketing, and self-aggrandizement.”
  • Source: Britcher, Robert N. (1999). The Limits of Software: People, Projects, and Perspectives. Reading, MA: Addison Wesley. ISBN 0-201-43323-0. Page 208.

Fred_Brooks

Programmer Poetry

“The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds his castles in the air, from air, creating by exertion of the imagination. Few media of creation are so flexible, so easy to polish and rework, so readily capable of realizing grand conceptual structures.”
  • Source: Brooks Jr., F. P. (1995). The Mythical Man-Month - Essays on Software Engineering (Anniversary Edition) | 1975/1995 (Anniv.). Boston. MA: Addison-Wesley. ISBN: 0201835959. Chapter 1, page 7.

Child Bearing Task Law

“The bearing of a child takes nine months, no matter how many women are assigned. Many software tasks have this characteristic because of the sequential nature of debugging.”
  • Source: Brooks Jr., F. P. (1995). The Mythical Man-Month - Essays on Software Engineering (Anniversary Edition) | 1975/1995 (Anniv.). Boston. MA: Addison-Wesley. ISBN: 0201835959. Chapter 2, page 17.

Tables versus Flowcharts

“Show me your flowcharts and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won't usually need your flowcharts; they'll be obvious.”
  • Source: Brooks Jr., F. P. (1995). The Mythical Man-Month - Essays on Software Engineering (Anniversary Edition) | 1975/1995 (Anniv.). Boston. MA: Addison-Wesley. ISBN: 0201835959. Chapter 9, page 102.

Rudolf_Carnap

System of Statements

"Science is a system of statements based on direct experience, and controlled by experimental verification. Verification in science is not, however, of single statements but of the entire system or a sub-system of such statements."
  • Source: Rudolf Carnap, The Unity of Science (1934), trans. Max Black, 42.

Alexander d'Agapeyeff

Programming too much Art

“Programming is still too much of an artistic endeavour.”

Edsger_Wybe_Dijkstra

Humble Programmers

"We shall do a much better programming job, provided that we approach the task with a full appreciation of its tremendous difficulty, provided that we stick to modest and elegant programming languages, provided that we respect the intrinsic limitations of the human mind and approach the task as Very Humble Programmers."
  • Source: Edsger Wybe Dijkstra in an article entitled The Humble Programmer. Written by Edsger W. Dijkstra. Published 1972 in Communications of the ACM, volume 15, number 10. DOI: 10.1145/355604.361591.

Competent Programmer

“The competent programmer is fully aware of the strictly limited size of his own skull; therefore he approaches the programming task in full humility, and among other things he avoids clever tricks like the plague.”

Competent Programming

“Don't blame me for the fact that competent programming, as I view it as an intellectual possibility, will be too difficult for 'the average programmer' — you must not fall into the trap of rejecting a surgical technique because it is beyond the capabilities of the barber in his shop around the corner.”

Programming Dogmatism

"Please don't fall into the trap of believing that I am terribly dogmatic about [the go to statement]. I have the uncomfortable feeling that others are making a religion out of it, as if the conceptual problems of programming could be solved by a simple trick, by a simple form of coding discipline!"
  • Source: Dijkstra (1973) in personal communication to Donald Knuth, quoted in Knuth's “Structured Programming with go to Statements”, online at https://pic.plover.com/knuth-GOTO.pdf retrieved 2022.

Powers of Abstraction

“The effective exploitation of his powers of abstraction must be regarded as one of the most vital activities of a competent programmer.”
  • Source: The Humble Programmer (1972), 1972 Turing Award Lecture[1], Communications of the ACM 15 (10), October 1972: pp. 859–866.

Lines of Code

“My point today is that, if we wish to count lines of code, we should not regard them as 'lines produced' but as 'lines spent': the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger.”

Effective Reasoning

“The required techniques of effective reasoning are pretty formal, but as long as programming is done by people that don't master them, the software crisis will remain with us and will be considered an incurable disease. And you know what incurable diseases do: they invite the quacks and charlatans in, who in this case take the form of Software Engineering gurus.”

Edward_Emil_David

Explore_First

“Begin with skeletal coding: Rather than aiming at finished code, the first coding steps should be aimed at exploring.”

David_Deutsch

Program It Understand It

"If you can’t program it, you haven’t understood it."
  • Source: David Deutsch, The Beginning of Infinity: Explanations That Transform the World (2011).

Keywords: Programming_quotes Requirements_quotes Understanding_quotes

Edsger_Wybe_Dijkstra

Big Machines Big Problems

“As long as there were no machines, programming was no problem at all; when we had a few weak computers, programming became a mild problem, and now we have gigantic computers, programming has become an equally gigantic problem.”
  • Source: Edsger Wybe Dijkstra in an article entitled The Humble Programmer. Written by Edsger W. Dijkstra. Published 1972 in Communications of the ACM, volume 15, number 10. DOI: 10.1145/355604.361591.

Art of Programming

“The art of programming is the art of organizing complexity, of mastering multitude and avoiding its bastard chaos as effectively as possible.”

Programming is Difficult

“Programming is one of the most difficult branches of applied mathematics; the poorer mathematicians had better remain pure mathematicians.”

Programming Styles

“There are very different programming styles. I tend to see them as Mozart versus Beethoven. When Mozart started to write, the composition was finished. He wrote the manuscript and it was 'aus einem Guss' (from one cast). In beautiful handwriting, too. Beethoven was a doubter and a struggler who started writing before he finished the composition and then glued corrections onto the page. In one place he did this nine times. When they peeled them, the last version proved identical to the first one.”
  • Source: Dijkstra (2001) Source: Denken als discipline, a program from Dutch public TV broadcaster VPRO from April 10th, 2001 about Dijkstra.

Alexander_G_Fraser

Program Construction Sum

“One thing seems to be clear just now. It is that program construction is not always a simple progression in which each act of assembly represents a distinct forward step and that the final product can be described simply as the sum of many sub-assemblies.”

Top Down Bottom Up

“In the designs I have been involved in, and which have not involved too many people, I have not been able to identify whether these have been ‘top-down’ or ‘bottom-up’. They seem to me to be more like frame stressing,”

J_A_Haar

Software Documentation

“A standard for program documentation when programs are written in symbolic machine language should be set and each program should include this standard documentation in the ‘remarks field’ of the symbolic program.”

Hans_Hüttel

Chatbots and Programmers

“Even if chatbots should become a useful tool for programmers, their existence cannot mean the end of programming. It may well be the case that this combination of a built-in repository of code examples and the ability to easily retrieve code examples based on it can be used for generating ideas and for forms of ‘pair programming’.”
  • Source: Written by Hans Hüttel in the journal article entitled “On Program Synthesis and Large Language Models”, in Communications of the ACM, volume 68, number 1, 2025-01. DOI:10.1145/3680410.

Brian_Kernighan

Debugging Harder

“Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?”
  • Source: Book entitled: The Elements of Programming Style; Edition: 2nd. Chapter: 2. Written by Brian Kernighan and Phillip James (Bill) Plauger. Also known as Kernighan's law.

Donald_Knuth

Premature Optimization

“Premature optimization is the root of all evil (or at least most of it) in programming.”

Software is Hard

“My main conclusion after spending ten years of my life working on the TEX project is that software is hard. It’s harder than anything else I’ve ever had to do.”
  • Source: Donald E. Knuth in the paper entitled All Questions Answered. Published in Notices of the AMS, volume 49, number 3 (March 2002).

Kenneth_W_Kolence

Software Engineer

“There are people who call themselves software engineers, and who build software systems that other people trust their lives to that software. So a great deal of progress has really been made since 1962 (when I first began considering myself as a software engineer) and in that respect toward what may be considered as a valid engineering capability. ... Using the term [Software Engineering] ... actually did, for the first time, provide programmers with a more professional description of what they were trying to do. In my opinion, that was a very good thing.”

Robert_M_McClure

Time and Motion Code

“I know of one organisation that attempts to apply time and motion standards to the output of programmers. They judge a programmer by the amount of code he produces. This is guaranteed to produce insipid code”

Malcolm_McIlroy

Programs and Bridges

“There is a difference between writing programs and designing bridges.”

Negative Code

“The real hero of programming is the one who writes negative code.”
  • Source: Malcolm McIlroy, spoken during a talk 2009-12-03 at the Dartmouth-Lake Sunapee Linux User Group (DLSLUB).

Harlan_D_Mills

Thinking Versus Coding Errors

“In short, it is the thinking errors, more than the coding errors, which limit programming productivity.”

Alan_Perlis

Program Parts Recurse

“Every program is a part of some other program...”


Keywords: Program_quotes Programming_quotes Part_quotes Recursion_quotes

Understanding Code

“It is easier to write an incorrect program than understand a correct one.”

Understanding Programs

“To understand a program you must become both the machine and the program.”

Reading Programs

“Perhaps if we wrote programs from childhood on, as adults we'd be able to read them.”

Program Sameness

“If two people write exactly the same program, each should be put in microcode and then they certainly won't be the same.”


Program Purpose

“Every program has (at least) two purposes: the one for which it was written and another for which it wasn't.”

Programming Language

“A language that doesn't affect the way you think about programming, is not worth knowing.”

Programming Special Cases

“In programming, everything we do is a special case of something more general - and often we know it too quickly.”

Programming the Excluded Muddle

“Structured Programming supports the law of the excluded muddle.”

Error-Free Programs

“There are two ways to write error-free programs; only the third one works.”

Programming Language Wish

“When someone says ‘I want a programming language in which I need only say what I wish done,’ give him a lollipop.”

Programming Impossible for Most

Most people find the concept of programming obvious, but the doing impossible.”

Learning Knowledge and Programming

“You think you know when you learn, are more sure when you can write, even more when you can teach, but certain when you can program.”

Programming Education

“It goes against the grain of modern education to teach children to program. What fun is there in making plans, acquiring discipline in organizing thoughts, devoting attention to detail and learning to be self-critical?”

Programming Unnatural

“Programming is an unnatural act.”

Keywords: Programming_quotes Unnatural_quotes Action_quotes

Herbert_Schildt

C and C++

“C gives the programmer what the programmer wants; few restrictions, few complaints... C++ maintains the original spirit of C, that the programmer not the language is in charge.”
  • Source: Herbert Schildt. In the book entitled C++: The Complete Reference. Written by Herbert Schildt. Fourth edition. Published by McGraw-Hill in 2003. ISBN 978-0072226805. Page 8.

Mark_Seemann

Pair Programming

“...not everyone likes pair programming. As a typical introvert, I personally find the activity exhausting. It also leaves little room for contemplation, and it requires synchronization of schedules... it’s hardly practical or desirable to do it all the time.”
  • Source: Mark Seemann, “Code That Fits in Your Head: Heuristics for Software Engineering”. Published in 2021 by Pearson Education, Kindle Edition, ISBN: 978-0-13-746440-1. Page 190.

Herbert_Simon

Computer Programming as Data Structures

“When we write a computer program in any language except machine language, we are really not writing down processes but data structures. These data structures are then interpreted or compiled into processes, that is, into machine-language instructions that the computer can understand and execute. Nevertheless, for most purposes, it is convenient for us simply to ignore the translation step and to treat the computer programs in higher-level languages as representing processes.”

John_Tukey

First Use of the Term Software

“Today the ‘software’ comprising the carefully planned interpretive routines, compilers, and other aspects of automative programming are at least as important to the modern electronic calculator as its ‘hardware’ of tubes, transistors, wires, tapes and the like.”
  • Source: John Wilder Tukey. A paper entitled "The Teaching of Concrete Mathematics". The American Mathematical Monthly, volume 65, 1958. DOI: 10.2307/2310294.

Gerald_Weinberg

Desire To Eliminate Programmers

“Over the years, executives have backed their desire to eliminate programmers with staggering funds.”
  • Source: Book Entitled: The Psychology of Computer Programming (Silver anniversary edition). Edition: Silver anniversary. Written By: Gerald Weinberg. Published originally: 1971. Republished: 2011.

Small Teams More Efficient

“In any case, the basic rule for size and composition of programming teams would seem to be this — for the best programming at the least cost, give the best possible programmers you can find sufficient time so you need the smallest number of them. When you have to work faster, or with less experienced people, costs and uncertainties will rise. In any case, the worst way to do a programming project is to hire a horde of trainees and put them to work under pressure and without supervision — although this is the most common practice today.”
  • Source: Chapter 5. Weinberg, G. M. (2011). The Psychology of Computer Programming (Silver anniversary edition) | 1971. Weinberg & Weinberg.

Faster Programming Demands Better Programmers

“If we have to have the program faster, we shall have to hire a better man for the job.”
  • Source: Chapter 5. Weinberg, G. M. (2011). The Psychology of Computer Programming (Silver anniversary edition) | 1971. Weinberg & Weinberg.

A Good Program

“Most programmers feel that there is such a thing as good programming. Although this feeling may be valid, it does not follow that there is such a thing as a good program. Not, at least, in the sense that we can study the program out of the context in which it was developed and in which it will be used and declare it to have a goodness of 83.72 percent.”
  • Source: Chapter 2. Weinberg, G. M. (2011). The Psychology of Computer Programming (Silver anniversary edition) | 1971. Weinberg & Weinberg.

Fisher's Fundamental Theorem

“Fisher's Fundamental Theorem states — in terms appropriate to the present context — that the better adapted a system is to a particular environment, the less adaptable it is to new environments. By stretching our imagination a bit, we can see how this might apply to computer programs as well.”
  • Source: Chapter 2. Weinberg, G. M. (2011). The Psychology of Computer Programming (Silver anniversary edition) | 1971. Weinberg & Weinberg.

Programming Not Individual

“But there is much evidence, as we shall see presently, to argue that the proper study of programming is done at the level of the programming social unit. Not that the individual level is unimportant, but we might start by asking why, if the average programmer spends two-thirds of his time working with other people rather than working alone (yes, it's true!), that 99 percent of the studies have been on individual programmers.”
  • Source: Chapter 3. Weinberg, G. M. (2011). The Psychology of Computer Programming (Silver anniversary edition) | 1971. Weinberg & Weinberg.

No Right Programming Solution

“In programming, however, there is no right ‘solution’.”
  • Source: Chapter 3. Weinberg, G. M. (2011). The Psychology of Computer Programming (Silver anniversary edition) | 1971. Weinberg & Weinberg.

Vending Machines

“When the vending machines had been in the common room, a large crowd always hovered around them — but not particularly for fol-de-rol, as the manager had so quickly assumed... Informal mechanisms always exist and it is dangerous to change things without understanding them.”
  • Source: Chapter 4. Weinberg, G. M. (2011). The Psychology of Computer Programming (Silver anniversary edition) | 1971. Weinberg & Weinberg.

Furniture Partitions

“Someone should definitely study the depressing effect that the all-too-common half partitions have on programmer productivity. They manage to cut off all useful communication while permitting all disturbing sound and movement to penetrate.”
  • Source: Chapter 4. Weinberg, G. M. (2011). The Psychology of Computer Programming (Silver anniversary edition) | 1971. Weinberg & Weinberg.

Programming Not an Individual Task

“The ideas expressed in the preceding paragraph (of programmer individuality) are possibly the most formidable barrier to improved programming that we shall encounter. First of all, if this is indeed the image generally held of the programming profession, then people will be attracted to, or repelled from, entering the profession according to their preference for working alone or working with others.”
  • Source: Chapter 4. Weinberg, G. M. (2011). The Psychology of Computer Programming (Silver anniversary edition) | 1971. Weinberg & Weinberg.

Egoless Programming and Cognitive Dissonance

“Now, what cognitive dissonance has to do with our programming conflict should be vividly clear. A programmer who truly sees his program as an extension of his own ego is not going to be trying to find all the errors in that program. On the contrary, he is going to be trying to prove that the program is correct — even if this means the oversight of errors which are monstrous to another eye.”
  • Source: Chapter 4. Weinberg, G. M. (2011). The Psychology of Computer Programming (Silver anniversary edition) | 1971. Weinberg & Weinberg.

Egoless Programming and John von Neumann

“Programming groups who have conquered the ego problem do exist and have existed from the earliest days of computing. John von Neumann himself was perhaps the first programmer to recognize his inadequacies with respect to examination of his own work. Those who knew him have said that he was constantly asserting what a lousy programmer he was, and that he incessantly pushed his programs on other people to read for errors and clumsiness. Yet the common image today of von Neumann is of the unparalleled computing genius — flawless in his every action. And indeed, there can be no doubt of von Neumann's genius. His very ability to realize his human limitations put him head and shoulders above the average programmer today. Average people can be trained to accept their humanity — their inability to function like a machine — and to value it and work with others so as to keep it under the kind of control needed if programming is to be successful.”
  • Source: Chapter 4. Weinberg, G. M. (2011). The Psychology of Computer Programming (Silver anniversary edition) | 1971. Weinberg & Weinberg.

True Consensus on Group Goals

“To achieve true consensus on group goals, there is no better method than having the group set the goals itself... To be sure, not every programming team can be permitted to set whatever goals it happens to fancy at any moment. A team is usually constituted to accomplish some task which has probably been set down before the team was even assembled. But programming tasks are not usually specified too precisely until much later than team formation, so that unless the upper management is very overbearing, much meaningful and interesting goal setting can be done by the team members in concert. The greatest danger is the manager who has come up through the programming ranks and wants to define every bit and byte before the team even sees the problem. Nothing is more sure to dampen the team enthusiasm and make them feel that they are 'mere coders... Of course, it is best if each team can have a single clearly defined goal, but the world is seldom so simple... When a team is not fully apprised of the emphasis to be placed on each factor, the members of that team may very well be working at cross purposes.”
  • Source: Chapter 5. Weinberg, G. M. (2011). The Psychology of Computer Programming (Silver anniversary edition) | 1971. Weinberg & Weinberg.

Technical Leaders

“Leadership, in the sense that social scientists use it, means the ability to influence people. Programmers, being people who tend to value creative work and professional competence, tend to put their stock in people whom they perceive to be good at the things they do. Thus, it is easier to exert leadership over — to influence — programmers by being a soft-spoken programming wizard than by being the world's fastest-talking salesman. When nonprogramming leaders are brought in to be in charge of programming teams, trouble usually brews unless the appointed leader explicitly and implicitly recognizes his incapacity on technical matters. The very worst he can do — and this goes also for a former programmer who has lost touch with the field — is to try to match programming wits with the other members of the team. Although a team might come to respect a leader who openly admitted his programming inexperience, they could only come to ridicule one whose pretense at knowledge was revealed to be a sham.”
  • Source: Chapter 5. Weinberg, G. M. (2011). The Psychology of Computer Programming (Silver anniversary edition) | 1971. Weinberg & Weinberg.

Too Smart for Programming

“It is possible to be too smart for programming — if the person is not smart enough to use his intelligence to modify his social behavior and methods of communication.”
  • Source: Chapter 5. Weinberg, G. M. (2011). The Psychology of Computer Programming (Silver anniversary edition) | 1971. Weinberg & Weinberg.

Management Deskilling

“Even though the nth-level manager may have originally been a programmer, which is rare enough, he has almost certainly lost any programming ability by the time he reaches these heights. Given the rapid change of programming techniques and hardware, the higher-level manager becomes obsolete even if he retains the skills he originally had and keeps them sharply honed, for those languages and those machines are no longer in use. In a small survey of working programmers, only 15 percent of the first-line managers were thought to be as skillful as the programmers themselves, and none of the higher-level managers.”
  • Source: Chapter 6. Weinberg, G. M. (2011). The Psychology of Computer Programming (Silver anniversary edition) | 1971. Weinberg & Weinberg.

Amateur and Professional Programmers

“The amateur... is looking for a way to get the job done. If he runs into difficulty, all he wants is to surmount it — the manner of doing so is of little consequence. Not so, however, for the professional. She may well be aware of numerous ways of circumnavigating the problem at hand. She may even employ one of them for the immediate purpose of getting the job done. But her work does not stop there; it begins there. It begins because she must understand why she did not understand, in order that she may prepare herself for the programs she may someday write which will require that understanding. The amateur, then, is learning about his problem... The professional, conversely, is learning about her profession — programming — and the problem being programmed is only one incidental step in her process of development.”
  • Source: Chapter 7. Weinberg, G. M. (2011). The Psychology of Computer Programming (Silver anniversary edition) | 1971. Weinberg & Weinberg.

Edward_Yourdon

Better Programming Languages

“Better coding techniques may do nothing more than help you arrive at a disaster sooner than before. Better programming languages, used without anything else, may be just what your programmers need to develop a brilliant solution to the wrong problem.”
  • Source: Edward Yourdon in the book “Decline and Fall of the American Programmer”. Published in 1992 by Prentice Hall. ISBN: 0-13-203670-3. Chapter 2, section 2.1, page 27.

Design Analysis Strategy

“There is more to be gained from attention to design, analysis, and business strategy issues than from attention to programming-level issues.”
  • Source: Edward Yourdon in the book “Decline and Fall of the American Programmer”. Published in 1992 by Prentice Hall. ISBN: 0-13-203670-3. Chapter 2, section 2.1, page 27.

Shoshana_Zuboff

Information Produced

“Thus, information technology, even when it is applied to automatically reproduce a finite activity, is not mute. It not only imposes information (in the form of programmed instructions) but also produces information.”
  • Source: Zuboff, S. (1988). In The Age Of The Smart Machine: The Future Of Work And Power. New York, NY: Basic Books, p. 9. ISBN:0465032125.