⛩️Titus Winters - Collected Quotes

"A boat without a captain is nothing more than a floating waiting room: unless someone grabs the rudder and starts the engine, it’s just going to drift along aimlessly with the current. A piece of software is just like that boat: if no one pilots it, you’re left with a group of engineers burning up valuable time, just sitting around waiting for something to happen (or worse, still writing code that you don’t need)." (Titus Winters, "Software Engineering at Google: Lessons Learned from Programming Over Time", 2020)

"Code coverage can provide some insight into untested code, but it is not a substitute for thinking critically about how well your system is tested." (Titus Winters, "Software Engineering at Google: Lessons Learned from Programming Over Time", 2020)

"Fixing a bug is much like adding a new feature: the presence of the bug suggests that a case was missing from the initial test suite, and the bug fix should include that missing test case." (Titus Winters, "Software Engineering at Google: Lessons Learned from Programming Over Time", 2020)

"[...] do not underestimate the power of playing the social game. It’s not about tricking or manipulating people; it’s about creating relationships to get things done. Relationships always outlast projects. When you’ve got richer relationships with your coworkers, they’ll be more willing to go the extra mile when you need them." (Titus Winters, "Software Engineering at Google: Lessons Learned from Programming Over Time", 2020)

"Given enough time and enough users, even the most innocuous change will break something; your analysis of the value of that change must incorporate the difficulty in investigating, identifying, and resolving those breakages." (Titus Winters, "Software Engineering at Google: Lessons Learned from Programming Over Time", 2020)

"In a professional software engineering environment, criticism is almost never personal - it’s usually just part of the process of making a better project. The trick is to make sure you (and those around you) understand the difference between a constructive criticism of someone’s creative output and a flat-out assault against someone’s character." (Titus Winters, "Software Engineering at Google: Lessons Learned from Programming Over Time", 2020)

"In addition to developing the proper culture, invest in your testing infrastructure by developing linters, documentation, or other assistance that makes it more difficult to write bad tests." (Titus Winters, "Software Engineering at Google: Lessons Learned from Programming Over Time", 2020)

"In short, performance ratings are indicative only of how a person is performing in their given role at the time they are being evaluated. Ratings, although an important way to measure performance during a specific period, are not predictive of future performance and should not be used to gauge readiness for a future role or qualify an internal candidate for a different team. (They can, however, be used to evaluate whether an employee is properly or improperly slotted on their current team; therefore, they can provide an opportunity to evaluate how to better support an internal candidate moving forward.)" (Titus Winters, "Software Engineering at Google: Lessons Learned from Programming Over Time", 2020)

"Knowledge is in some ways the most important (though intangible) capital of a software engineering organization, and sharing of that knowledge is crucial for making an organization resilient and redundant in the face of change. A culture that promotes open and honest knowledge sharing distributes that knowledge efficiently across the organization and allows that organization to scale over time. In most cases, investments into easier knowledge sharing reap manyfold dividends over the life of a company." (Titus Winters, "Software Engineering at Google: Lessons Learned from Programming Over Time", 2020)

"Making good engineering decisions is all about weighing all of the available inputs and making informed decisions about the trade-offs. Sometimes, those decisions are based on instinct or accepted best practice, but only after we have exhausted approaches that try to measure or estimate the true underlying costs." (Titus Winters, "Software Engineering at Google: Lessons Learned from Programming Over Time", 2020)

"One of the broad truths we’ve seen to be true is the idea that finding problems earlier in the developer workflow usually reduces costs." (Titus Winters, "Software Engineering at Google: Lessons Learned from Programming Over Time", 2020)

"People are inherently imperfect - we like to say that humans are mostly a collection of intermittent bugs. But before you can understand the bugs in your coworkers, you need to understand the bugs in yourself. We’re going to ask you to think about your own reactions, behaviors, and attitudes - and in return, we hope you gain some real insight into how to become a more efficient and successful software engineer who spends less energy dealing with people-related problems and more time writing great code." (Titus Winters, "Software Engineering at Google: Lessons Learned from Programming Over Time", 2020)

"Programming is the immediate act of producing code. Software engineering is the set of policies, practices, and tools that are necessary to make that code useful for as long as it needs to be used and allowing collaboration across a team." (Titus Winters, "Software Engineering at Google: Lessons Learned from Programming Over Time", 2020)

"This is what good management is about: 95% observation and listening, and 5% making critical adjustments in just the right place." (Titus Winters, "Software Engineering at Google: Lessons Learned from Programming Over Time", 2020)

"When an engineer refactors the internals of a system without modifying its interface, whether for performance, clarity, or any other reason, the system’s tests shouldn’t need to change. The role of tests in this case is to ensure that the refactoring didn’t change the system’s behavior. Tests that need to be changed during a refactoring indicate that either the change is affecting the system’s behavior and isn’t a pure refactoring, or that the tests were not written at an appropriate level of abstraction." (Titus Winters, "Software Engineering at Google: Lessons Learned from Programming Over Time", 2020)

⛩️Mark W Maier - Collected Quotes

"A systems approach is one that focuses on the system as a whole, specifically linking value judgments (what is desired) and design decisions (what is feasible). A true systems approach means that the design process includes the 'problem' as well as the solution. The architect seeks a joint problem–solution pair and understands that the problem statement is not fixed when the architectural process starts. At the most fundamental level, systems are collections of different things that together produce results unachievable by the elements alone."  (Mark W Maier, "The Art Systems of Architecting" 3rd Ed., 2009)

"Architecting is both an art and a science - both synthesis and analysis, induction and deduction, and conceptualization and certification - using guidelines from its art and methods from its science. As a process, it is distinguished from systems engineering in its greater use of heuristic reasoning, lesser use of analytics, closer ties to the client, and particular concern with certification of readiness for use."  (Mark W Maier, "The Art Systems of Architecting" 3rd Ed., 2009)

"Architecting is creating and building structures - that is, 'structuring'. Systems architecting is creating and building systems. It strives for fit, balance, and compromise among the tensions of client needs and resources, technology, and multiple stakeholder interests."  (Mark W Maier, "The Art Systems of Architecting" 3rd Ed., 2009)

"Insight, or the ability to structure a complex situation in a way that greatly increases understanding of it, is strongly guided by lessons learned from one’s own or others’ experiences and observations. Given enough lessons, their meaning can be codified into succinct expressions called 'heuristics', a Greek term for guide. Heuristics are an essential complement to analytics, particularly in situations where analysis alone cannot provide either insights or guidelines."  (Mark W Maier, "The Art Systems of Architecting" 3rd Ed., 2009)

"It is generally agreed that increasing complexity is at the heart of the most difficult problems facing today’s systems architecting and engineering. When architects and builders are asked to explain cost overruns and schedule delays, by far the most common, and quite valid, explanation is that the system is much more complex than originally thought. The greater is the complexity, the greater the difficulty. It is important, therefore, to understand what is meant by system complexity if architectural progress is to be made in dealing with it."  (Mark W Maier, "The Art Systems of Architecting" 3rd Ed., 2009)

"Less apparent is that qualitatively different problem-solving techniques are required at high levels of complexity than at low ones. Purely analytical techniques, powerful for the lower levels, can be overwhelmed at the higher ones. At higher levels, architecting methods, experience-based heuristics, abstraction, and integrated modeling must be called into play."  (Mark W Maier, "The Art Systems of Architecting" 3rd Ed., 2009)

"Modeling is the creation of abstractions or representations of the system to predict and analyze performance, costs, schedules, and risks and to provide guidelines for systems research, development, design, manufacture, and management. Modeling is the centerpiece of systems architecting - a mechanism of communication to clients and builders, of design management with engineers and designers, of maintaining system integrity with project management, and of learning for the architect, personally."  (Mark W Maier, "The Art Systems of Architecting" 3rd Ed., 2009)

"Modeling is the fabric of architecting because architecting is at a considerable distance of abstraction from actual construction. The architect does not manipulate the actual elements of construction. The architect builds models that are passed into more detailed design processes. Those processes lead, eventually, to construction drawings or the equivalent and actual system fabrication or coding."  (Mark W Maier, "The Art Systems of Architecting" 3rd Ed., 2009)

"Taking a systems approach means paying close attention to results, the reasons we build a system. Architecture must be grounded in the client’s/user’s/customer’s purpose. Architecture is not just about the structure of components. One of the essential distinguishing features of architectural design versus other sorts of engineering design is the degree to which architectural design embraces results from the perspective of the client/user/customer. The architect does not assume some particular problem formulation, as “requirements” is fixed. The architect engages in joint exploration, ideally directly with the client/user/customer, of what system attributes will yield results worth paying for."  (Mark W Maier, "The Art Systems of Architecting" 3rd Ed., 2009)

"The basic idea behind all of these techniques is to simplify problem solving by concentrating on its essentials. Consolidate and simplify the objectives. Focus on the things with the highest impact, things that determine other things. Put to one side minor issues likely to be resolved by the resolution of major ones. Discard the nonessentials. Model (abstract) the system at as high a level as possible, then progressively reduce the level of abstraction. In short: Simplify!"  (Mark W Maier, "The Art Systems of Architecting" 3rd Ed., 2009)

"This primacy of complexity in system design helps explain why a single 'optimum' seldom if ever exists for such systems. There are just too many variables. There are too many stakeholders and too many conflicting interests. No practical way may exist for obtaining information critical in making a 'best' choice among quite different alternatives."  (Mark W Maier, "The Art Systems of Architecting" 3rd Ed., 2009)

⛩️Eric Evans - Collected Quotes

"A domain model is not a particular diagram; it is the idea that the diagram is intended to convey. It is not just the knowledge in a domain expert’s head; it is a rigorously organized and selective abstraction of that knowledge." (Eric Evans, "Domain-Driven Design: Tackling complexity in the heart of software", 2003)

"Always remember that the model is not the diagram. The diagram’s purpose is to help communicate and explain the model. The code can serve as a repository of the details of the design." (Eric Evans, "Domain-Driven Design: Tackling complexity in the heart of software", 2003)

"But code as a design document does have its limits. It can overwhelm the reader with detail. Although its behavior is unambiguous, that doesn’t mean it is obvious. And the meaning behind a behavior can be hard to convey. […] A document shouldn’t try to do what the code already does well. The code already supplies the detail. It is an exact specification of program behavior. Other documents need to illuminate meaning, to give insight into large-scale structures, and to focus attention on core elements. Documents can clarify design intent when the programming language does not support a straightforward implementation of a concept. Written documents should complement the code and the talking." (Eric Evans, "Domain-Driven Design: Tackling complexity in the heart of software", 2003)

"Diagrams are a means of communication and explanation, and they facilitate brainstorming. They serve these ends best if they are minimal. Comprehensive diagrams of the entire object model fail to communicate or explain; they overwhelm the reader with detail and they lack meaning." (Eric Evans, "Domain-Driven Design: Tackling complexity in the heart of software", 2003)

"Domain-driven design is both a way of thinking and a set of priorities, aimed at accelerating software projects that have to deal with complicated domains." (Eric Evans, "Domain-Driven Design: Tackling complexity in the heart of software", 2003)

"Domain experts are usually not aware of how complex their mental processes are as, in the course of their work, they navigate all these rules, reconcile contradictions, and fill in gaps with common sense. Software can’t do this. It is through knowledge crunching in close collaboration with software experts that the rules are clarified, fleshed out, reconciled, or placed out of scope." (Eric Evans, "Domain-Driven Design: Tackling complexity in the heart of software", 2003)

"Effective domain modelers are knowledge crunchers. They take a torrent of information and probe for the relevant trickle. They try one organizing idea after another, searching for the simple view that makes sense of the mass. Many models are tried and rejected or transformed. Success comes in an emerging set of abstract concepts that makes sense of all the detail. This distillation is a rigorous expression of the particular knowledge that has been found most relevant." (Eric Evans, "Domain-Driven Design: Tackling complexity in the heart of software", 2003)

"Extreme Programming recognizes the importance of design decisions, but it strongly resists upfront design. Instead, it puts an admirable effort into communication and improving the project’s ability to change course rapidly. With that ability to react, developers can use the “simplest thing that could work” at any stage of a project and then continuously refactor, making many small design improvements, ultimately arriving at a design that fits the customer’s true needs." (Eric Evans, "Domain-Driven Design: Tackling complexity in the heart of software", 2003)

"Continuous refactoring is a series of small redesigns; developers without solid design principles will produce a code base that is hard to understand or change—the opposite of agility. And although fear of unanticipated requirements often leads to overengineering, the attempt to avoid overengineering can develop into another fear: a fear of doing any deep design thinking at all." (Eric Evans, "Domain-Driven Design: Tackling complexity in the heart of software", 2003)

"If the architecture isolates the domain-related code in a way that allows a cohesive domain design loosely coupled to the rest of the system, then that architecture can probably support domain-driven DESIGN." (Eric Evans, "Domain-Driven Design: Tackling complexity in the heart of software", 2003)

"If the design, or some central part of it, does not map to the domain model, that model is of little value, and the correctness of the software is suspect. At the same time, complex mappings between models and design functions are difficult to understand and, in practice, impossible to maintain as the design changes. A deadly divide opens between analysis and design so that insight gained in each of those activities does not feed into the other." (Eric Evans, "Domain-Driven Design: Tackling complexity in the heart of software", 2003)

"In fact, XP works best for developers with a sharp design sense. The XP process assumes that you can improve a design by refactoring, and that you will do this often and rapidly. But past design choices make refactoring itself either easier or harder. The XP process attempts to increase team communication, but model and design choices clarify or confuse communication." (Eric Evans, "Domain-Driven Design: Tackling complexity in the heart of software", 2003)

"Knowledge crunching is an exploration, and you can’t know where you will end up." (Eric Evans, "Domain-Driven Design: Tackling complexity in the heart of software", 2003)

"Many objects are not fundamentally defined by their attributes, but rather by a thread of continuity and identity." (Eric Evans, "Domain-Driven Design: Tackling complexity in the heart of software", 2003)

"Many things can put a project off course: bureaucracy, unclear objectives, and lack of resources, to name a few. But it is the approach to design that largely determines how complex software can become. When complexity gets out of hand, developers can no longer understand the software well enough to change or extend it easily and safely. On the other hand, a good design can create opportunities to exploit those complex features." (Eric Evans, "Domain-Driven Design: Tackling complexity in the heart of software", 2003)

"Maps are models, and every model represents some aspect of reality or an idea that is of interest. A model is a simplification. It is an interpretation of reality that abstracts the aspects relevant to solving the problem at hand and ignores extraneous detail." (Eric Evans, "Domain-Driven Design: Tackling complexity in the heart of software", 2003)

"Models come in many varieties and serve many roles, even those restricted to the context of a software development project. Domain-driven design calls for a model that doesn’t just aid early analysis but is the very foundation of the design […]  Tightly relating the code to an underlying model gives the code meaning and makes the model relevant." (Eric Evans, "Domain-Driven Design: Tackling complexity in the heart of software", 2003)

"Software design is a constant battle with complexity." (Eric Evans, "Domain-Driven Design: Tackling complexity in the heart of software", 2003)

"The effectiveness of an overall design is very sensitive to the quality and consistency of fine-grained design and implementation decisions. With a MODEL-DRIVEN DESIGN, a portion of the code is an expression of the model; changing that code changes the model. Programmers are modelers, whether anyone likes it or not. So it is better to set up the project so that the programmers do good modeling work." (Eric Evans, "Domain-Driven Design: Tackling complexity in the heart of software", 2003)

"The technical model that drives the software development process must be strictly pared down to the necessary minimum to fulfill its functions. An explanatory model can include aspects of the domain that provide context that clarifies the more narrowly scoped model. Explanatory models offer the freedom to create much more communicative styles tailored to a particular topic. Visual metaphors used by the domain experts in a field often present clearer explanations, educating developers and harmonizing experts. Explanatory models also present the domain in a way that is simply different, and multiple, diverse explanations help people learn." (Eric Evans, "Domain-Driven Design: Tackling complexity in the heart of software", 2003)

"To create software that is valuably involved in users' activities, a development team must bring to bear a body of knowledge related to those activities. The breadth of knowledge required can be daunting. The volume and complexity of information can be overwhelming. Models are tools for grappling with this overload. A model is a selectively simplified and consciously structured form of knowledge. An appropriate model makes sense of information and focuses it on a problem." (Eric Evans, "Domain-Driven Design: Tackling complexity in the heart of software", 2003)

"Useful models seldom lie on the surface. As we come to understand the domain and the needs of the application, we usually discard superficial model elements that seemed important in the beginning, or we shift their perspective. Subtle abstractions emerge that would not have occurred to us at the outset but that pierce to the heart of the matter." (Eric Evans, "Domain-Driven Design: Tackling complexity in the heart of software", 2003)

"Well-written code can be very communicative, but the message it communicates is not guaranteed to be accurate. Oh, the reality of the behavior caused by a section of code is inescapable. But a method name can be ambiguous, misleading, or out of date compared to the internals of the method. The assertions in a test are rigorous, but the story told by variable names and the organization of the code is not. Good programming style keeps this connection as direct as possible, but it is still an exercise in self-discipline. It takes fastidiousness to write code that doesn’t just do the right thing but also says the right thing." (Eric Evans, "Domain-Driven Design: Tackling complexity in the heart of software", 2003)

"When a design is based on a model that reflects the basic concerns of the users and domain experts, the bones of the design can BE revealed to the user to a greater extent than with other design approaches. Revealing the model gives the user more access to the potential of the software and yields consistent, predictable behavior." (Eric Evans, "Domain-Driven Design: Tackling complexity in the heart of software", 2003)

"When we set out to write software, we never know enough. Knowledge on the project is fragmented, scattered among many people and documents, and it’s mixed with other information so that we don’t even know which bits of knowledge we really need. Domains that seem less technically daunting can be deceiving: we don’t realize how much we don’t know. This ignorance leads us to make false assumptions." (Eric Evans, "Domain-Driven Design: Tackling complexity in the heart of software", 2003)

⛩️Michael M Hammer - Collected Quotes

"At the heart of reengineering is the notion of discontinuous thinking—of recognizing and breaking away from the outdated rules and fundamental assumptions that underlie operations. Unless we change these rules, we are merely rearranging the deck chairs on the Titanic. We cannot achieve breakthroughs in performance by cutting fat or automating existing processes. Rather, we must challenge old assumptions and shed the old rules that made the business underperform in the first place." (Michael M Hammer, "Reengineering Work: Don't Automate, Obliterate", Magazine, 1990) [source]

"Conventional process structures are fragmented and piecemeal, and they lack the integration necessary to maintain quality and service. They are breeding grounds for tunnel vision, as people tend to substitute the narrow goals of their particular department for the larger goals of the process as a whole. When work is handed off from person to person and unit to unit, delays and errors are inevitable. Accountability blurs, and critical issues fall between the cracks." (Michael M Hammer, "Reengineering Work: Don't Automate, Obliterate", Magazine, 1990) [source]

"In reengineering, managers break loose from outmoded business processes and the design principles underlying them and create new ones. [...] Reengineering requires looking at the fundamental processes of the business from a cross-functional perspective. [...] The reengineering team must keep asking Why? and What if? Why do we need to get a manager’s signature on a requisition? Is it a control mechanism or a decision point?" (Michael M Hammer, "Reengineering Work: Don't Automate, Obliterate", Magazine, 1990) [source]

"In short, a reengineering effort strives for dramatic levels of improvement. It must break away from conventional wisdom and the constraints of organizational boundaries and should be broad and cross-functional in scope. It should use information technology not to automate an existing process but to enable a new one." (Michael M Hammer, "Reengineering Work: Don't Automate, Obliterate", Magazine, 1990) [source]

"Information technology can capture and process data, and expert systems can to some extent supply knowledge, enabling people to make their own decisions. As the doers become self-managing and self-controlling, hierarchy - and the slowness and bureaucracy associated with it - disappears." (Michael M Hammer, "Reengineering Work: Don't Automate, Obliterate", Magazine, 1990) [source]

"Reengineering cannot be planned meticulously and accomplished in small and cautious steps. It's an all-or-nothing proposition with an uncertain result. Still, most companies have no choice but to muster the courage to do it. For many, reengineering is the only hope for breaking away from the antiquated processes that threaten to drag them down." (Michael M Hammer, "Reengineering Work: Don't Automate, Obliterate", Magazine, 1990) [source]

"Reengineering triggers changes of many kinds, not just of the business process itself. Job designs, organizational structures, management systems - anything associated with the process - must be refashioned in an integrated way. In other words, reengineering is a tremendous effort that mandates change in many areas of the organization." (Michael M Hammer, "Reengineering Work: Don't Automate, Obliterate", Magazine, 1990) [source]

"A business process is a collection of activities that takes one or more kinds of input and creates an output that is of value to the customer. A business process has a goal and is affected by events occurring in the external world or in other processes." (James A Champy & Michael M Hammer, "Reengineering the Corporation", 1993)

"A process perspective sees not individual tasks in isolation, but the entire collection of tasks that contribute to a desired outcome. Narrow points of view are useless in a process context. It just won't do for each person to be concerned exclusively with his or her own limited responsibility, no matter how well these responsibilities are met. When that occurs, the inevitable result is working at cross–purpose, misunderstanding, and the optimization of the part at the expense of the whole. Process work requires that everyone involved be directed toward a common goal; otherwise, conflicting objectives and parochial agendas impair the effort."  (James A Champy & Michael M Hammer, "Reengineering the Corporation", 1993)

"'Automating a mess yields an automated mess.' Unless an organization reconceptualized its operations, overlaying new technology on these operations accomplished little." (James A Champy & Michael M Hammer, "Reengineering the Corporation", 1993)

"Business reengineering isn't about fixing anything. Business reengineering means starting all over, starting from scratch. Business reengineering means putting aside much of the received wisdom of two hundred years of industrial management [...] How people and companies did things yesterday doesn't matter to the business reengineer." (James A Champy & Michael M Hammer, "Reengineering the Corporation", 1993)

"Reengineering is the fundamental rethinking and radical redesign of business processes to achieve dramatic improvements in critical contemporary measures of performance such as cost, quality, service and speed." (James A Champy & Michael M Hammer, "Reengineering the Corporation", 1993)

"Reengineering posits a radical new principle: that the design of work must be based not on hierarchical management and the specialization of labor but on end-to-end processes and the creation of value for the customer." (James A Champy & Michael M Hammer, "Reengineering the Corporation", 1993)

"To succeed at reengineering, you have to be a missionary, a motivator, and a leg breaker." (Michael M Hammer, Fortune, August 1993)

⛩️Robert C Martin - Collected Quotes

"A system that is comprehensively tested and passes all of its tests all of the time is a testable system. That’s an obvious statement, but an important one. Systems that aren’t testable aren’t verifiable. Arguably, a system that cannot be verified should never be deployed." (Robert C Martin, "Clean Code: A Handbook of Agile Software Craftsmanship", 2008)

"Any comment that forces you to look in another module for the meaning of that comment has failed to communicate to you and is not worth the bits it consumes." (Robert C Martin, "Clean Code: A Handbook of Agile Software Craftsmanship", 2008) 

"Clean code is focused. Each function, each class, each module exposes a single-minded attitude that remains entirely undistracted, and unpolluted, by the surrounding details."  (Robert C Martin, "Clean Code: A Handbook of Agile Software Craftsmanship", 2008)

"Clean code is not written by following a set of rules. You don’t become a software craftsman by learning a list of heuristics. Professionalism and craftsmanship come from values that drive disciplines." (Robert C Martin, "Clean Code: A Handbook of Agile Software Craftsmanship", 2008)

"Code formatting is important. It is too important to ignore and it is too important to treat religiously. Code formatting is about communication, and communication is the professional developer’s first order of business."  (Robert C Martin, "Clean Code: A Handbook of Agile Software Craftsmanship", 2008)

"Duplication is the primary enemy of a well-designed system. It represents additional work, additional risk, and additional unnecessary complexity."  (Robert C Martin, "Clean Code: A Handbook of Agile Software Craftsmanship", 2008)

"Every system is built from a domain-specific language designed by the programmers to describe that system. Functions are the verbs of that language, and classes are the nouns."  (Robert C Martin, "Clean Code: A Handbook of Agile Software Craftsmanship", 2008)

"Good software designs accommodate change without huge investments and rework. When we use code that is out of our control, special care must be taken to protect our investment and make sure future change is not too costly."  (Robert C Martin, "Clean Code: A Handbook of Agile Software Craftsmanship", 2008)

"If the discipline of requirements specification has taught us anything, it is that well-specified requirements are as formal as code and can act as executable tests of that code!"  (Robert C Martin, "Clean Code: A Handbook of Agile Software Craftsmanship", 2008)

"In an ideal system, we incorporate new features by extending the system, not by making modifications to existing code." (Robert C Martin, "Clean Code: A Handbook of Agile Software Craftsmanship", 2008)

"Indeed, the ratio of time spent reading versus writing is well over 10 to 1. We are constantly reading old code as part of the effort to write new code. [… Therefore,] making it easy to read makes it easier to write." (Robert C Martin, "Clean Code: A Handbook of Agile Software Craftsmanship", 2008) 

"It is a myth that we can get systems 'right the first time'. Instead, we should implement only today’s stories, then refactor and expand the system to implement new stories tomorrow. This is the essence of iterative and incremental agility. Test-driven development, refactoring, and the clean code they produce make this work at the code level." (Robert C Martin, "Clean Code: A Handbook of Agile Software Craftsmanship", 2008)

"It is not enough for code to work. Code that works is often badly broken. Programmers who satisfy themselves with merely working code are behaving unprofessionally. They may fear that they don’t have time to improve the structure and design of their code, but I disagree. Nothing has a more profound and long-term degrading effect upon a development project than bad code." (Robert C Martin, "Clean Code: A Handbook of Agile Software Craftsmanship", 2008)

"It is unit tests that keep our code flexible, maintainable, and reusable. The reason is simple. If you have tests, you do not fear making changes to the code! Without tests every change is a possible bug."  (Robert C Martin, "Clean Code: A Handbook of Agile Software Craftsmanship", 2008)

"Nothing has a more profound and long-term degrading effect upon a development project than bad code. Bad schedules can be redone, bad requirements can be redefined. Bad team dynamics can be repaired. But bad code rots and ferments, becoming an inexorable weight that drags the team down." (Robert C Martin, "Clean Code: A Handbook of Agile Software Craftsmanship", 2008)

"One difference between a smart programmer and a professional programmer is that the professional understands that clarity is king. Professionals use their powers for good and write code that others can understand." (Robert C Martin, "Clean Code: A Handbook of Agile Software Craftsmanship", 2008) 

"One of the best ways to ruin a program is to make massive changes to its structure in the name of improvement. Some programs never recover from such “improvements.” The problem is that it’s very hard to get the program working the same way it worked before the 'improvement'." (Robert C Martin, "Clean Code: A Handbook of Agile Software Craftsmanship", 2008)

"Refactoring is a lot like solving a Rubik’s cube. There are lots of little steps required to achieve a large goal. Each step enables the next." (Robert C Martin, "Clean Code: A Handbook of Agile Software Craftsmanship", 2008)

"Standards make it easier to reuse ideas and components, recruit people with relevant experience, encapsulate good ideas, and wire components together. However, the process of creating standards can sometimes take too long for industry to wait, and some standards lose touch with the real needs of the adopters they are intended to serve." (Robert C Martin, "Clean Code: A Handbook of Agile Software Craftsmanship", 2008)

"The majority of the cost of a software project is in long-term maintenance. In order to minimize the potential for defects as we introduce change, it’s critical for us to be able to understand what a system does. As systems become more complex, they take more and more time for a developer to understand, and there is an ever greater opportunity for a misunderstanding. Therefore, code should clearly express the intent of its author. The clearer the author can make the code, the less time others will have to spend understanding it. This will reduce defects and shrink the cost of maintenance." (Robert C Martin, "Clean Code: A Handbook of Agile Software Craftsmanship", 2008)

"The problem isn’t the simplicity of the code but the implicity of the code (to coin a phrase): the degree to which the context is not explicit in the code itself." (Robert C Martin, "Clean Code: A Handbook of Agile Software Craftsmanship", 2008)

"There are two parts to learning craftsmanship: knowledge and work. You must gain the knowledge of principles, patterns, practices, and heuristics that a craftsman knows, and you must also grind that knowledge into your fingers, eyes, and gut by working hard and practicing." (Robert C Martin, "Clean Code: A Handbook of Agile Software Craftsmanship", 2008)

"We do not want to expose the details of our data. Rather we want to express our data in abstract terms. This is not merely accomplished by using interfaces and/or getters and setters. Serious thought needs to be put into the best way to represent the data that an object contains. The worst option is to blithely add getters and setters." (Robert C Martin, "Clean Code: A Handbook of Agile Software Craftsmanship", 2008)

"When people look under the hood, we want them to be impressed with the neatness, consistency, and attention to detail that they perceive. We want them to be struck by the orderliness. We want their eyebrows to rise as they scroll through the modules. We want them to perceive that professionals have been at work. If instead they see a scrambled mass of code that looks like it was written by a bevy of drunken sailors, then they are likely to conclude that the same inattention to detail pervades every other aspect of the project." (Robert C Martin, "Clean Code: A Handbook of Agile Software Craftsmanship", 2008)

"Whether you are designing systems or individual modules, never forget to use the simplest thing that can possibly work." (Robert C Martin, "Clean Code: A Handbook of Agile Software Craftsmanship", 2008)

"Yet attentiveness to detail is an even more critical foundation of professionalism than is any grand vision. First, it is through practice in the small that professionals gain proficiency and trust for practice in the large. Second, the smallest bit of sloppy construction, of the door that does not close tightly or the slightly crooked tile on the floor, or even the messy desk, completely dispels the charm of the larger whole. That is what clean code is about." (Robert C Martin, "Clean Code: A Handbook of Agile Software Craftsmanship", 2008)

"You should choose a set of simple rules that govern the format of your code, and then you should consistently apply those rules. If you are working on a team, then the team should agree to a single set of formatting rules and all members should comply." (Robert C Martin, "Clean Code: A Handbook of Agile Software Craftsmanship", 2008)

"Acceptance tests are not unit tests. Unit tests are written by programmers for programmers. They are formal design documents that describe the lowest level structure and behavior of the code. The audience is programmers, not business. Acceptance tests are written by the business for the business (even when you, the developer, end up writing them). They are formal requirements documents that specify how the system should behave from the business’ point of view. The audience is the business and the programmers." (Robert C Martin, "Clean Code: A Handbook of Agile Software Craftsmanship", 2008)

"Coding is an intellectually challenging and exhausting activity. It requires a level of concentration and focus that few other disciplines require. The reason for this is that coding requires you to juggle many competing factors at once." (Robert C Martin,"The Clean Coder: A code of conduct for professional programmers", 2011)

"Following the principle of 'late precision', acceptance tests should be written as late as possible, typically a few days before the feature is implemented. In Agile projects, the tests are written after the features have been selected for the next Iteration or Sprint." (Robert C Martin,"The Clean Coder: A code of conduct for professional programmers", 2011)

"For some reason software developers don’t think of debugging time as coding time. They think of debugging time as a call of nature, something that just has to be done. But debugging time is just as expensive to the business as coding time is, and therefore anything we can do to avoid or diminish it is good." (Robert C Martin,"The Clean Coder: A code of conduct for professional programmers", 2011)

"One of the most common communication issues between programmers and business is the requirements. The business people state what they believe they need, and then the programmers build what they believe the business described. At least that’s how it’s supposed to work. In reality, the communication of requirements is extremely difficult, and the process is fraught with error." (Robert C Martin,"The Clean Coder: A code of conduct for professional programmers", 2011)

"One of the worst symptoms of a dysfunctional team is when each programmer builds a wall around his code and refuses to let other programmers touch it." (Robert C Martin,"The Clean Coder: A code of conduct for professional programmers", 2011)

"Programming is an act of creation. When we write code we are creating something out of nothing. We are boldly imposing order upon chaos. We are confidently commanding, in precise detail, the behaviors of a machine that could otherwise do incalculable damage. And so, programming is an act of supreme arrogance." (Robert C Martin,"The Clean Coder: A code of conduct for professional programmers", 2011)

"Software development is a marathon, not a sprint. You can’t win the race by trying to run as fast as you can from the outset. You win by conserving your resources and pacing yourself. A marathon runner takes care of her body both before and during the race. Professional programmers conserve their energy and creativity with the same care." (Robert C Martin,"The Clean Coder: A code of conduct for professional programmers", 2011)

"The cost of automating acceptance tests is so small in comparison to the cost of executing manual test plans that it makes no economic sense to write scripts for humans to execute. Professional developers take responsibility for their part in ensuring that acceptance tests are automated." (Robert C Martin,"The Clean Coder: A code of conduct for professional programmers", 2011)

"The fact that bugs will certainly occur in your code does not mean you aren’t responsible for them. The fact that the task to write perfect software is virtually impossible does not mean you aren’t responsible for the imperfection." (Robert C Martin,"The Clean Coder: A code of conduct for professional programmers", 2011)

"The fundamental assumption underlying all software projects is that software is easy to change. If you violate this assumption by creating inflexible structures, then you undercut the economic model that the entire industry is based on." (Robert C Martin,"The Clean Coder: A code of conduct for professional programmers", 2011)

"The purpose of acceptance tests is communication, clarity, and precision. By agreeing to them, the developers, stakeholders, and testers all understand what the plan for the system behavior is. Achieving this kind of clarity is the responsibility of all parties. Professional developers make it their responsibility to work with stakeholders and testers to ensure that all parties know what is about to be built." (Robert C Martin,"The Clean Coder: A code of conduct for professional programmers", 2011)

"The second best way to learn is to collaborate with other people. Professional software developers make a special effort to program together, practice together, design and plan together. By doing so they learn a lot from each other, and they get more done faster with fewer errors." (Robert C Martin,"The Clean Coder: A code of conduct for professional programmers", 2011)

"The true professional knows that delivering function at the expense of structure is a fool’s errand. It is the structure of your code that allows it to be flexible. If you compromise the structure, you compromise the future." (Robert C Martin,"The Clean Coder: A code of conduct for professional programmers", 2011)

"True professionals work hard to keep their skills sharp and ready. It is not enough to simply do your daily job and call that practice. Doing your daily job is performance, not practice. Practice is when you specifically exercise your skills outside of the performance of your job for the sole purpose of refining and enhancing those skills." (Robert C Martin,"The Clean Coder: A code of conduct for professional programmers", 2011)

"Unfortunately, all too many projects become mired in a tar pit of poor structure. Tasks that used to take days begin to take weeks, and then months. Management, desperate to recapture lost momentum, hires more developers to speed things up. But these developers simply add to the morass, deepening the structural damage and raising the impediment." (Robert C Martin,"The Clean Coder: A code of conduct for professional programmers", 2011) 

"When you cannot concentrate and focus sufficiently, the code you write will be wrong. It will have bugs. It will have the wrong structure. It will be opaque and convoluted. It will not solve the customers’ real problems. In short, it will have to be reworked or redone. Working while distracted creates waste." (Robert C Martin,"The Clean Coder: A code of conduct for professional programmers", 2011)

"[…] you should not agree to work overtime unless (1) you can personally afford it, (2) it is short term, two weeks or less, and (3) your boss has a fall-back plan in case the overtime effort fails." (Robert C Martin,"The Clean Coder: A code of conduct for professional programmers", 2011)

"Function or architecture? Which of these two provides the greater value? Is it more important for the software system to work, or is it more important for the software system to be easy to change?" (Robert C Martin, "Clean Architecture: A Craftsman's Guide to Software Structure and Design", 2017)

"Getting software right is hard. It takes knowledge and skills that most young programmers haven’t yet acquired. It requires thought and insight that most programmers don’t take the time to develop. It requires a level of discipline and dedication that most programmers never dreamed they’d need. Mostly, it takes a passion for the craft and the desire to be a professional." (Robert C Martin, "Clean Architecture: A Craftsman's Guide to Software Structure and Design", 2017)

"Software architects are, by virtue of their job description, more focused on the structure of the system than on its features and functions. Architects create an architecture that allows those features and functions to be easily developed, easily modified, and easily extended." (Robert C Martin, "Clean Architecture: A Craftsman's Guide to Software Structure and Design", 2017)

"The bigger lie that developers buy into is the notion that writing messy code makes them go fast in the short term, and just slows them down in the long term. Developers who accept this lie exhibit the hare’s overconfidence in their ability to switch modes from making messes to cleaning up messes sometime in the future, but they also make a simple error of fact. The fact is that making messes is always slower than staying clean, no matter which time scale you are using." (Robert C Martin, "Clean Architecture: A Craftsman's Guide to Software Structure and Design", 2017)

"The goal of software architecture is to minimize the human resources required to build and maintain the required system." (Robert C Martin, "Clean Architecture: A Craftsman's Guide to Software Structure and Design", 2017)

"What is OO? There are many opinions and many answers to this question. To the software architect, however, the answer is clear: OO is the ability, through the use of polymorphism, to gain absolute control over every source code dependency in the system. It allows the architect to create a plugin architecture, in which modules that contain high-level policies are independent of modules that contain low-level details. The low-level details are relegated to plugin modules that can be deployed and developed independently from the modules that contain high-level policies." (Robert C Martin, "Clean Architecture: A Craftsman's Guide to Software Structure and Design", 2017)

"When software is done right, it requires a fraction of the human resources to create and maintain. Changes are simple and rapid. Defects are few and far between. Effort is minimized, and functionality and flexibility are maximized." (Robert C Martin, "Clean Architecture: A Craftsman's Guide to Software Structure and Design", 2017)

"When we talk about software architecture, software is recursive and fractal in nature, etched and sketched in code. Everything is details. Interlocking levels of detail also contribute to a building’s architecture, but it doesn’t make sense to talk about physical scale in software. Software has structure - many structures and many kinds of structures-but its variety eclipses the range of physical structure found in buildings. You can even argue quite convincingly that there is more design activity and focus in software than in building architecture - in this sense, it’s not unreasonable to consider software architecture more architectural than building architecture!" (Robert C Martin, "Clean Architecture: A Craftsman's Guide to Software Structure and Design", 2017)

⛩️Edmond Lau - Collected Quotes

"A work environment that iterates quickly provides a faster feedback cycle and enables you to learn at a faster rate. Lengthy release cycles, formalized product approvals, and indecisive leadership slow down iteration speed; automation tools, lightweight approval processes, and a willingness to experiment accelerate progress." (Edmond Lau, "The Effective Engineer: How to Leverage Your Efforts In Software Engineering to Make a Disproportionate and Meaningful Impact", 2015)

"Adopting a mindset of instrumentation means ensuring we have a set of dashboards that surface key health metrics and that enable us to drill down to the relevant data. However, many of the questions we want to answer tend to be exploratory, since we often don’t know everything that we want to measure ahead of time. Therefore, we need to build flexible tools and abstractions that make it easy to track additional metrics." (Edmond Lau, "The Effective Engineer: How to Leverage Your Efforts In Software Engineering to Make a Disproportionate and Meaningful Impact", 2015)

"At fast-growing teams and companies, the number of problems to solve exceeds available resources, providing ample opportunities to make a big impact and to increase your responsibilities. The growth also makes it easier to attract strong talent and build a strong team, which feeds back to generate even more growth. A lack of growth, on the other hand, leads to stagnation and politics. Employees might squabble over limited opportunities, and it becomes harder to find and retain talent." (Edmond Lau, "The Effective Engineer: How to Leverage Your Efforts In Software Engineering to Make a Disproportionate and Meaningful Impact", 2015)

"Because we spend so much of our time at work, one of the most powerful leverage points for increasing our learning rate is our choice of work environment." (Edmond Lau, "The Effective Engineer: How to Leverage Your Efforts In Software Engineering to Make a Disproportionate and Meaningful Impact", 2015)

"But like many other aspects of code quality, building an abstraction for a problem comes with tradeoffs. Building a generalized solution takes more time than building one specific to a given problem. To break even, the time saved by the abstraction for future engineers needs to outweigh the time invested." (Edmond Lau, "The Effective Engineer: How to Leverage Your Efforts In Software Engineering to Make a Disproportionate and Meaningful Impact", 2015)

"Continuous deployment is but one of many powerful tools at your disposal for increasing iteration speed. Other options include investing in time-saving tools, improving your debugging loops, mastering your programming workflows, and, more generally, removing any bottlenecks that you identify." (Edmond Lau, "The Effective Engineer: How to Leverage Your Efforts In Software Engineering to Make a Disproportionate and Meaningful Impact", 2015)

"Developing the skills to automate takes time, whether they be using shell scripts, browser extensions, or something else. But the cost of mastering these skills gets smaller the more often you do it and the better you get at it." (Edmond Lau, "The Effective Engineer: How to Leverage Your Efforts In Software Engineering to Make a Disproportionate and Meaningful Impact", 2015)

"Fine-tuning the efficiency of simple actions and saving a second here or there may not seem worth it at first glance. It requires an upfront investment, and you’ll very likely be slower the first few times you try out a new and unfamiliar workflow. But consider that you’ll repeat those actions at least tens of thousands of times during your career: minor improvements easily compound over time." (Edmond Lau, "The Effective Engineer: How to Leverage Your Efforts In Software Engineering to Make a Disproportionate and Meaningful Impact", 2015)

"Good metrics accomplish a number of goals. First, they help you focus on the right things. […] Second, when visualized over time, good metrics help guard against future regressions. […] Third, good metrics can drive forward progress. […] Fourth, a good metric lets you measure your effectiveness over time and compare the leverage of what you’re doing against other activities you could be doing instead." (Edmond Lau, "The Effective Engineer: How to Leverage Your Efforts In Software Engineering to Make a Disproportionate and Meaningful Impact", 2015)

"How can we reduce integration risk? One effective strategy is to build end-to-end scaffolding and do system testing earlier. Stub out incomplete functions and modules, and assemble an end-to-end system as soon as possible, even if it’s only partly functional. Front-loading the integration work provides a number of benefits. First, it forces you to think more about the necessary glue between different pieces and how they interact, which can help refine the integration estimates and reduce project risk. Second, if something breaks the end-to-end system during development, you can identify and fix it along the way, while dealing with much less code complexity, rather than scrambling to tackle it at the end. Third, it amortizes the cost of integration throughout the development process, which helps build a stronger awareness of how much integration work is actually left." (Edmond Lau, "The Effective Engineer: How to Leverage Your Efforts In Software Engineering to Make a Disproportionate and Meaningful Impact", 2015)

"In any engineering discipline (and in life), there will always be more tasks to do than you have time for. Working on one task means not working on another. Therefore, regular prioritization is a high-leverage activity, because it determines the leverage of the rest of your time." (Edmond Lau, "The Effective Engineer: How to Leverage Your Efforts In Software Engineering to Make a Disproportionate and Meaningful Impact", 2015)

"It’s wishful thinking to believe that all the code we write will be bug-free and work the first time. In actuality, much of our engineering time is spent either debugging issues or validating that what we’re building behaves as expected. The sooner we internalize this reality, the sooner we will start to consciously invest in our iteration speed in debugging and validation loops." (Edmond Lau, "The Effective Engineer: How to Leverage Your Efforts In Software Engineering to Make a Disproportionate and Meaningful Impact", 2015)

"Many of us are familiar with the concept of a minimal, reproducible test case. This refers to the simplest possible test case that exercises a bug or demonstrates a problem. A minimal, reproducible test case removes all unnecessary distractions so that more time and energy can be spent on the core issue, and it creates a tight feedback loop so that we can iterate quickly." (Edmond Lau, "The Effective Engineer: How to Leverage Your Efforts In Software Engineering to Make a Disproportionate and Meaningful Impact", 2015)

"Project estimation and project planning are extremely difficult to get right, and many engineers (myself included) have learned this the hard way. The only way to get better is by practicing these concepts, especially on smaller projects where the cost of poor estimations is lower. The larger the project, the higher the risks, and the more leverage that good project planning and estimation skills will have on your success." (Edmond Lau, "The Effective Engineer: How to Leverage Your Efforts In Software Engineering to Make a Disproportionate and Meaningful Impact", 2015)

"Project estimation is one of the hardest skills that an effective engineer needs to learn. But it’s crucial to master: businesses need accurate estimates to make long-term plans for their products. They need to know when resources might free up to work on upcoming features or when they can promise feature requests to customers. And even when we don’t have pressure to ship against a deadline, how long we think a project will take affects our decisions of what to work on." (Edmond Lau, "The Effective Engineer: How to Leverage Your Efforts In Software Engineering to Make a Disproportionate and Meaningful Impact", 2015)

"Projects fail from under-communicating, not over-communicating. Even if resource constraints preclude the dependency that you want from being delivered any sooner, clarifying priorities and expectations enables you to plan ahead and work through alternatives." (Edmond Lau, "The Effective Engineer: How to Leverage Your Efforts In Software Engineering to Make a Disproportionate and Meaningful Impact", 2015)

"Sometimes, we build things in a way that makes sense in the short-term but that can be costly in the long-term. We work around design guidelines because it’s faster and easier than following them. We punt on writing test cases for a new feature because there’s too much work to finish before the deadline. We copy, paste, and tweak small chunks of existing code instead of refactoring it to support our use cases. Each of these tradeoffs, whether they’re made from laziness or out of a conscious decision to ship sooner, can increase the amount of technical debt in our codebase." (Edmond Lau, "The Effective Engineer: How to Leverage Your Efforts In Software Engineering to Make a Disproportionate and Meaningful Impact", 2015)

"To be effective engineers, we need to be able to identify which activities produce more impact with smaller time investments. Not all work is created equal. Not all efforts, however well-intentioned, translate into impact." (Edmond Lau, "The Effective Engineer: How to Leverage Your Efforts In Software Engineering to Make a Disproportionate and Meaningful Impact", 2015)

"The best strategy for optimizing your iteration speed is the same as for optimizing the performance of any system: identify the biggest bottlenecks, and figure out how to eliminate them. What makes this difficult is that while tools, debugging workflows, and programming environments might be the areas most directly under your control as an engineer, sometimes they’re not the only bottlenecks slowing you down." (Edmond Lau, "The Effective Engineer: How to Leverage Your Efforts In Software Engineering to Make a Disproportionate and Meaningful Impact", 2015)

"The faster that you can iterate, the more that you can learn about what works and what doesn’t work. You can build more things and try out more ideas. Not every change will produce positive value and growth, of course." (Edmond Lau, "The Effective Engineer: How to Leverage Your Efforts In Software Engineering to Make a Disproportionate and Meaningful Impact", 2015)

"[…] the first heuristic for prioritizing high-leverage activities is to focus on what directly produces value. At the end of the day (or when it comes time for performance reviews), what matters is how much value you’ve created. […] the first heuristic for prioritizing high-leverage activities is to focus on what directly produces value. At the end of the day (or when it comes time for performance reviews), what matters is how much value you’ve created." (Edmond Lau, "The Effective Engineer: How to Leverage Your Efforts In Software Engineering to Make a Disproportionate and Meaningful Impact", 2015)

"The freedom to choose what to work on and how to do it drives our ability to learn—as long as we have the support that we need to use that freedom effectively. At established companies, employees tend to work on specialized projects, but they also have access to more coaching and structure. At smaller companies, you’ll end up wielding significantly more autonomy over the total surface area of product features and responsibilities, but you’ll also need to take more ownership of your own learning and growth." (Edmond Lau, "The Effective Engineer: How to Leverage Your Efforts In Software Engineering to Make a Disproportionate and Meaningful Impact", 2015)

"The next time you find yourself repeatedly going through the same motions when you’re fixing a bug or iterating on a feature, pause. Take a moment to think through whether you might be able to tighten that testing loop. It could save you time in the long run." (Edmond Lau, "The Effective Engineer: How to Leverage Your Efforts In Software Engineering to Make a Disproportionate and Meaningful Impact", 2015)

"To invest in your own growth, you should carve out your own 20% time. It’s more effective to take it in one- or two-hour chunks each day rather than in one full day each week, because you can then make a daily habit out of improving your skills. Your productivity may decrease at first (or it might not change much if you’re taking time away from web surfing or other distractions), but the goal is to make investments that will make you more effective in the long run." (Edmond Lau, "The Effective Engineer: How to Leverage Your Efforts In Software Engineering to Make a Disproportionate and Meaningful Impact", 2015)

"Ultimately, software quality boils down to a matter of tradeoffs, and there’s no one universal rule for how to do things. […] Rigidly adhering to a notion of building something 'the right way' can paralyze discussions about tradeoffs and other viable options. Pragmatism - thinking in terms of what does and doesn’t work for achieving our goals - is a more effective lens through which to reason about quality." (Edmond Lau, "The Effective Engineer: How to Leverage Your Efforts In Software Engineering to Make a Disproportionate and Meaningful Impact", 2015)

"When establishing our goals, it’s important to choose carefully what core metrics to measure (or not measure) and optimize. When it comes to day-to-day operations, however, you should be less discriminatory: measure and instrument as much as possible. Although these two principles may seem contradictory, they actually complement each other. The first describes a high-level, big-picture activity, whereas the second is about gaining insight into what’s going on with systems that we’ve built." (Edmond Lau, "The Effective Engineer: How to Leverage Your Efforts In Software Engineering to Make a Disproportionate and Meaningful Impact", 2015)

"When you write to teach other people, you gain a deeper understanding of ideas you’re already familiar with and pinpoint the details that you didn’t fully understand." (Edmond Lau, "The Effective Engineer: How to Leverage Your Efforts In Software Engineering to Make a Disproportionate and Meaningful Impact", 2015) 

"Why is continuous deployment such a powerful tool? Fundamentally, it allows engineers to make and deploy small, incremental changes rather than the larger, batched changes typical at other companies. That shift in approach eliminates a significant amount of overhead associated with traditional release processes, making it easier to reason about changes and enabling engineers to iterate much more quickly." (Edmond Lau, "The Effective Engineer: How to Leverage Your Efforts In Software Engineering to Make a Disproportionate and Meaningful Impact", 2015)

⛩️David Farley - Collected Quotes

"Acceptance testing relies on the ability to execute automated tests in a productionlike environment. However, a vital property of such a test environment is that it is able to successfully support automated testing. Automated acceptance testing is not the same as user acceptance testing. One of the differences is that automated acceptance tests should not run in an environment that includes integration to all external systems. Instead, your acceptance testing should be focused on providing a controllable environment in which the system under test can be run. 'Controllable' in this context means that you are able to create the correct initial state for our tests. Integrating with real external systems removes our ability to do this." (David Farley & Jez Humble, "Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation", 2010)

"Asking experts to do boring and repetitive, and yet technically demanding tasks is the most certain way of ensuring human error that we can think of, short of sleep deprivation, or inebriation." (David Farley & Jez Humble, "Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation", 2010)

"At an abstract level, a deployment pipeline is an automated manifestation of your process for getting software from version control into the hands of your users." (David Farley & Jez Humble, "Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation", 2010)

"If it hurts, do it more frequently, and bring the pain forward." (David Farley & Jez Humble, "Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation", 2010)

"In software, when something is painful, the way to reduce the pain is to do it more frequently, not less." (David Farley & Jez Humble, "Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation", 2010)

"Indeed, there is a school of thought that any work on a branch is, in the lean sense, waste - inventory that is not being pulled into the finished product." (David Farley & Jez Humble, "Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation", 2010)

"It is worth emphasizing that branching by feature is really the antithesis of continuous integration, and all of our advice on how to make it work is only about ensuring that the pain isn’t too horrible come merge time." (David Farley & Jez Humble, "Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation", 2010)

"Our proposal is not a technical solution but a practice: Always commit to trunk, and do it at least once a day. If this seems incompatible with making far-reaching changes to your code, then we humbly submit that perhaps you haven’t tried hard enough." (David Farley & Jez Humble, "Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation", 2010)

"Releasing software is too often an art; it should be an engineering discipline." (David Farley & Jez Humble, "Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation", 2010)

"Releasing software should be easy. It should be easy because you have tested every single part of the release process hundreds of times before. It should be as simple as pressing a button. The repeatability and reliability derive from two principles: automate almost everything, and keep everything you need to build, deploy, test, and release your application in version control." (David Farley & Jez Humble, "Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation", 2010)

"So, when should you think about automating a process? The simplest answer is, 'When you have to do it a second time.' The third time you do something, it should be done using an automated process. This fine-grained incremental approach rapidly creates a system for automating the repeated parts of your development, build, test, and deployment process." (David Farley & Jez Humble, "Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation", 2010)

"The deployment pipeline has its foundations in the process of continuous integration and is in essence the principle of continuous integration taken to its logical conclusion. The aim of the deployment pipeline is threefold. First, it makes every part of the process of building, deploying, testing, and releasing software visible to everybody involved, aiding collaboration. Second, it improves feedback so that problems are identified, and so resolved, as early in the process as possible. Finally, it enables teams to deploy and release any version of their software to any environment at will through a fully automated process." (David Farley & Jez Humble, "Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation", 2010)

"The earlier you catch defects, the cheaper they are to fix." (David Farley & Jez Humble, "Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation", 2010)

"The most important practice for continuous integration to work properly is frequent check-ins to trunk or mainline. You should be checking in your code at least a couple of times a day." (David Farley & Jez Humble, "Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation", 2010)

"There should be two tasks for a human being to perform to deploy software into a development, test, or production environment: to pick the version and environment and to press the 'deploy' button." (David Farley & Jez Humble, "Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation", 2010)

⛩️Peter Coad - Collected Quotes

"More effective analysis requires the use of problem domain constructs, both for present reuse and for future reuse." (Peter Coad & Edward Yourdon, "Object-Oriented Analysis" 2nd Ed., 1991)

"One of the biggest problems faced by analysts is studying the problem domain and making discoveries about it. [...] OOA is the challenge of understanding the problem domain, and then the system's responsibilities in that light." (Peter Coad & Edward Yourdon, "Object-Oriented Analysis" 2nd Ed., 1991)

"One of the critical success factors for any method and its application is its ability to facilitate communication, avoiding information  overload. So for larger models, the question is how to guide the reader into different parts of the model." (Peter Coad & Edward Yourdon, "Object-Oriented Analysis" 2nd Ed., 1991)

"The transition from analysis to design has been a constant source of frustration. [...] no matter how many cute cartoons are drawn to depict the transition, the radical change in underlying representation causes a major chasm between analysis and design models." (Peter Coad & Edward Yourdon, "Object-Oriented Analysis" 2nd Ed., 1991)

"A pattern is a fully realized form original, or model accepted or proposed for imitation. With patterns, small piecework is standardized into a larger chunk or unit. Patterns become the building blocks for design and construction. Finding and applying patterns indicates progress in a field of human endeavor." (Peter Coad, "Object-oriented patterns", 1992)

"Object-oriented methods tend to focus on the lowest-level building block: the class and its objects." (Peter Coad, "Object-oriented patterns", 1992)

"With each pattern, small piecework is standardized into a larger chunk or unit. Patterns become the building blocks for design and construction. Finding and applying patterns indicates progress in a field of human endeavor." (Peter Coad, "Object-oriented patterns", 1992)

"We think most process initiatives are silly. Well-intentioned managers and teams get so wrapped up in executing processes that they forget that they are being paid for results, not process execution. (Peter Coad et al, "Java Modeling in Color with UML", 1999)

⛩️George E Forsythe - Collected Quotes

"The use of practically any computing technique itself raises a number of mathematical problems. There is thus a very considerable impact of computation on mathematics itself, and this may be expected to influence mathematical research to an increasing degree." (George E Forsythe, 1958) 

"I consider computer science to be the art and science of exploiting automatic digital computers, and of creating the technology necessary to understand their use. It deals with such related problems as the design of better machines using known components:, the design and implementation of adequate software systems for communication between man and machine, and the design and analysis of methods of representing information by abstract symbols and of processes for manipulating these symbols." (George E Forsythe, "Stanford University's Program in Computer Science", 1965)

"To a modern mathematician, design seems to be a second-rate intellectual activity." (George E Forsythe, 1966)

"Computer science is at once abstract and pragmatic. The focus on actual computers introduces the pragmatic component: our central questions are economic ones like the relations among speed, accuracy, and cost of a proposed computation, and the hardware and software organization required. The (often) better understood questions of existence and theoretical computability - however fundamental - remain in the background. On the other hand, the medium of computer science - information - is an abstract one. The meaning of symbols and numbers may change from application to application, either in mathematics or in computer science. Like mathematics, one goal of computer science is to create a basic structure in terms of inherently defined concepts that is independent of any particular application." (George E Forsythe, "What to do till the computer scientist comes", 1968)

"The most valuable acquisitions in a scientific or technical education are the general-purpose mental tools which remain serviceable for a lifetime. I rate natural language and mathematics as the most important of these tools, and computer science as a third." (George E Forsythe, "What to do till the computer scientist comes", 1968)

"Most of known computer science must be considered as design technique, not theory." (George E Forsythe, "What to do till the computer scientist comes", 1968)

"The most valuable acquisitions in a scientific or technical education are the general-purpose mental tools which remain serviceable for a life-time." (George E Forsythe, "What to do till the computer scientist comes", 1968)

"People have said you don’t understand something until you’ve taught it in a class. The truth is you don’t understand something until you’ve taught it to a computer, until you’ve been able to program it." (George E Forsythe)

⛩️Maurice V Wilkes - Collected Quotes

"As soon as we started programming, we found out to our surprise that it wasn't as easy to get programs right as we had thought. Debugging had to be discovered. I can remember the exact instant when I realized that a large part of my life from then on was going to be spent in finding mistakes in my own programs." (Maurice Wilkes, 1949)

"A source of strength in the early days was that groups in various parts of the world were prepared to construct experimental computers without necessarily intending them to be the prototype for serial production. As a result, there became available a body of knowledge about what would work and what would not work." (Maurice V Wilkes, "Computers Then and Now", 1968)

"Acceptance of the idea that a processor does one thing at a time - at any rate as the programmer sees it - made programming conceptually very simple, and paved the way for the layer upon layer of sophistication that we have seen develop. [...] Revolutionary advances, if they come, must come by the exploitation of the high degree of parallelism that the use of integrated circuits will make possible. The problem is to secure a satisfactorily high factor of hardware utilization, since, without this, parallelism will not give us greater power." (Maurice V Wilkes, "Computers Then and Now", 1968)

"At the present time, choosing a programming language is equivalent to choosing a data structure, and if that data structure does not fit the data you want to manipulate then it is too bad. It would, in a sense, be more logical first to choose a data structure appropriate to the problem and then look around for, or construct with a kit of tools provided, a language suitable for manipulating that data structure." (Maurice V Wilkes, "Computers Then and Now", 1968)

"In the judgment of design engineers, the ordinary means of communicating with a computer are entirely inadequate. […] Graphical communication in some form or other is of vital importance in engineering as that subject is now conducted; we must either provide the capability in our computer systems, or take on the impossible task of training up a future race of engineers conditioned to think in a different way." (Maurice V Wilkes, "Computers Then and Now", 1968)

"Surveying the shifts of interest among computer scientists and the ever-expanding family of those who depend on computers for their work, one cannot help being struck by the power of the computer to bind together, in a genuine community of interest, people whose motivations differ widely." (Maurice V Wilkes, "Computers Then and Now", 1968)

"The artificial intelligence approach may not be altogether the right one to make to the problem of designing automatic assembly devices. Animals and machines are constructed from entirely different materials and on quite different principles. When engineers have tried to draw inspiration from a study of the way animals work they have usually been misled; the history of early attempts to construct flying machines with flapping wings illustrates this very clearly." (Maurice V Wilkes, "Computers Then and Now", 1968)

"The realization came over me with full force that a good part of the remainder of my life was going to be spent in finding errors in my own programs." (Maurice Wilkes, "Memoirs of a Computer Pioneer", 1985)

⛩️Richard W Hamming - Collected Quotes

"The purpose of computing is insight, not numbers […] sometimes […] the purpose of computing numbers is not yet in sight." (Richard Hamming, “Numerical Methods for Scientists and Engineers”, 1962)

"Computer based simulation is now in wide spread use to analyse system models and evaluate theoretical solutions to observed problems. Since important decisions must rely on simulation, it is essential that its validity be tested, and that its advocates be able to describe the level of authentic representation which they achieved." (Richard Hamming, 1975)

"Probability is the mathematics of uncertainty. Not only do we constantly face situations in which there is neither adequate data nor an adequate theory, but many modem theories have uncertainty built into their foundations. Thus learning to think in terms of probability is essential. Statistics is the reverse of probability (glibly speaking). In probability you go from the model of the situation to what you expect to see; in statistics you have the observations and you wish to estimate features of the underlying model." (Richard W Hamming, "Methods of Mathematics Applied to Calculus, Probability, and Statistics", 1985)

"Probability plays a central role in many fields, from quantum mechanics to information theory, and even older fields use probability now that the presence of 'noise' is officially admitted. The newer aspects of many fields start with the admission of uncertainty." (Richard W Hamming, "Methods of Mathematics Applied to Calculus, Probability, and Statistics", 1985)

"There is a universality about mathematics; what was created to explain one phenomenon is very often later found to be useful in explaining other, apparently unrelated, phenomena. Theories that were developed to explain some poorly measured effects are often found to fit later, much more accurate measurements. Furthermore, from measurements over a limited range the theory is often found to fit a far wider range. Finally, and perhaps most unreasonably, quite regularly from the mathematics alone new phenomena, previously unknown and unsuspected, are successfully predicted. This universality of mathematics could, of course, be a reflection of the way the human mind works and not of the external world, but most people believe it reflects reality." (Richard W Hamming, "Methods of Mathematics Applied to Calculus, Probability, and Statistics", 1985) 

"There is always a gap between the mathematics and reality. Most of us believe that the world is made out of molecules, and when you try to make very, very accurate measurements, the random movement of the molecules will defeat your attempts at ultimate precision. In the modem theory of quantum mechanics, it is widely believed that you cannot, even in principle, precisely measure both the position and momentum (velocity times mass) of a particle at the same time; thus in this interpretation of quantum mechanics it is impossible, even theoretically, to get arbitrarily accurate measurements at the same time on certain properties of a particle. In practice, from the physical world we abstract a mathematical idealization of what is going on, and then we operate on the mathematical model. Finally, we try to interpret the mathematical results back into physical reality. Surprisingly often we get useful results, but now and then we get nonsense. You need to develop your intuition about the reality of the mathematical models you see." (Richard W Hamming, "Methods of Mathematics Applied to Calculus, Probability, and Statistics", 1985)

"A model can not be proved to be correct; at best it can only be found to be reasonably consistant and not to contradict some of our beliefs of what reality is." (Richard W Hamming, "The Art of Probability for Scientists and Engineers", 1991)

"A model is often judged by how well it "explains" some observations. There need not be a unique model for a particular situation, nor need a model cover every possible special case. A model is not reality, it merely helps to explain some of our impressions of reality. [...] Different models may thus seem to contradict each other, yet we may use both in their appropriate places." (Richard W Hamming, "The Art of Probability for Scientists and Engineers", 1991)

"All of engineering involves some creativity to cover the parts not known, and almost all of science includes some practical engineering to translate the abstractions into practice." (Richard W Hamming, "The Art of Probability for Scientists and Engineers", 1991)

"It is generally recognized that it is dangerous to apply any part of science without understanding what is behind the theory. This is especially true in the field of probability since in practice there is not a single agreed upon model of probability, but rather there are many widely different models of varying degrees of relevance and reliability. Thus the philosophy behind probability should not be neglected by presenting a nice set of postulates and then going forward; even the simplest applications of probability can involve the underlying philosophy." (Richard W Hamming, "The Art of Probability for Scientists and Engineers", 1991)

"Mathematics is not just a collection of results, often called theorems; it is a style of thinking. Computing is also basically a style of thinking. Similarly, probability is a style of thinking." (Richard W Hamming, "The Art of Probability for Scientists and Engineers", 1991)

"A neural net, in case you are unfamiliar with them, can learn to get results when you give it a series of inputs and acceptable outputs, without ever saying how to produce the results. They can classify objects into classes which are reasonable, again without being told what classes are to be used or found. They learn with simple feedback which uses the information that the result computed from an input is not acceptable. In a way they represent a solution to 'the programming problem' - once they are built they are really not programmed at all, but still they can solve a wide variety of problems satisfactorily. They are a coming field [...], but they will probably play a large part in the future of computers. In a sense they are a 'hard wired' computer (it may be merely a program) to solve a wide class of problems when a few parameters are chosen and a lot of data is supplied." (Richard Hamming, "The Art of Doing Science and Engineering: Learning to Learn", 1997)

"[...] a systems engineering job is never done. One reason is the presence of the solution changes the environment and produces new problems to be met. [...] A second reason the systems engineers design is never completed is the solution offered to the original problem usually produces both deeper insight and dissatisfactions in the engineers themselves. Furthermore, while the design phase continually goes from proposed solution to evaluation and back again and again, there comes a time when this process of redefinement must stop and the real problem coped with - thus giving what they realize is, in the long run, a suboptimal solution." (Richard Hamming, "The Art of Doing Science and Engineering: Learning to Learn", 1997)

"Accuracy of measurement tends to get confused with relevance of measurement, much more than most people believe. That a measurement is accurate, reproducible, and easy to make does not mean it should be done, instead a much poorer one which is more closely related to your goals may be much preferable." (Richard Hamming, "The Art of Doing Science and Engineering: Learning to Learn", 1997)

"All things which are proved to be impossible must obviously rest on some assumptions, and when one or more of these assumptions are not true then the impossibility proof fails - but the expert seldom remembers to carefully inspect the assumptions before making their 'impossible' statements." (Richard Hamming, "The Art of Doing Science and Engineering: Learning to Learn", 1997)

"Another curious phenomenon you may meet is in fitting data to a model there are errors in both the data and the model. For example, a normal distribution may be assumed, but the tails may in fact be larger or smaller than the model predicts, and possibly no negative values can occur although the normal distribution allows them. Thus there are two sources of error. As your ability to make more accurate measurements increases the error due to the model becomes an increasing part of the error." (Richard Hamming, "The Art of Doing Science and Engineering: Learning to Learn", 1997)

"Good design protects you from the need for too many highly accurate components in the system. But such design principles are still, to this date, ill-understood and need to be researched extensively. Not that good designers do not understand this intuitively, merely it is not easily incorporated into the design methods you were taught in school. Good minds are still needed in spite of all the computing tools we have developed." (Richard Hamming, "The Art of Doing Science and Engineering: Learning to Learn", 1997)

"If the data is usually bad, and you find that you have to gather some data, what can you do to do a better job? First, recognize what I have repeatedly said to you, the human animal was not designed to be reliable; it cannot count accurately, it can do little or nothing repetitive with great accuracy. [...] Second, you cannot gather a really large amount of data accurately. It is a known fact which is constantly ignored. It is always a matter of limited resources and limited time. [...] Third, much social data is obtained via questionnaires. But it a well documented fact the way the questions are phrased, the way they are ordered in sequence, the people who ask them or come along and wait for them to be filled out, all have serious effects on the answers."  (Richard Hamming, "The Art of Doing Science and Engineering: Learning to Learn", 1997)

"If you want to be certain then you are apt to be obsolete." (Richard Hamming, "The Art of Doing Science and Engineering: Learning to Learn", 1997)

"In an argument between a specialist and a generalist the expert usually wins by simply: (1) using unintelligible jargon, and (2) citing their specialist results which are often completely irrelevant to the discussion. The expert is, therefore, a potent factor to be reckoned with in our society. Since experts are both necessary, and also at times do great harm in blocking significant progress, they need to be examined closely. All too often the expert misunderstands the problem at hand, but the generalist cannot carry though their side to completion. The person who thinks they understand the problem and does not is usually more of a curse (blockage) than the person who knows they do not understand the problem." (Richard Hamming, "The Art of Doing Science and Engineering: Learning to Learn", 1997)

"It has been my experience, as well as many others who have looked, data is generally much less accurate than it is advertised to be. This is not a trivial point - we depend on initial data for many decisions, as well as for the input data for simulations which result in decisions." (Richard Hamming, "The Art of Doing Science and Engineering: Learning to Learn", 1997)

"Machines do not produce logical novelty when working properly, but they certainly produce psychological novelty - programmers are constantly being surprised by what the program they wrote actually does! But can you as a human produce logical novelty? A careful examination of people's reports on their great discoveries often shows they were led by past experiences to finding the result they did. Circumstances led them to success; psychological but not logical novelty. Are you not prepared by past experiences to do what you do, to make the discoveries you do? Is logical novelty actually possible?" (Richard Hamming, "The Art of Doing Science and Engineering: Learning to Learn", 1997)

"One trouble with much of programming is simply that often there is not a well defined job to be done, rather the programming process itself will gradually discover what the problem is! The desire that you be given a well defined problem before you start programming often does not match reality, and hence a lot of the current proposals to 'solve the programming problem' will fall to the ground if adopted rigorously." (Richard Hamming, "The Art of Doing Science and Engineering: Learning to Learn", 1997)

"Probably the most important tool in creativity is the use of an analogy. Something seems like something else which we knew in the past. Wide acquaintance with various fields of knowledge is thus a help - provided you have the knowledge filed away so it is available when needed, rather than to be found only when led directly to it. This flexible access to pieces of knowledge seems to come from looking at knowledge while you are acquiring it from many different angles, turning over any new idea to see its many sides before filing it away." (Richard Hamming, "The Art of Doing Science and Engineering: Learning to Learn", 1997)

"Sometimes the mathematician can accurately estimate the frequency content of the signal (possibly from the answer being computed), but usually you have to go to the designers and get their best estimates. A competent designer should be able to deliver such estimates, and if they cannot then you need to do a lot of exploring of the solutions to estimate this critical number, the sampling rate of the digital solution. The step by step solution of a problem is actually sampling the function, and you can use adaptive methods of step by step solution if you wish." (Richard Hamming, "The Art of Doing Science and Engineering: Learning to Learn", 1997)

"Systems engineering is the attempt to keep at all times the larger goals in mind and to translate local actions into global results. But there is no single larger picture. [...] Systems engineering is a hard trade to follow; it is so easy to get lost in the details! Easy to say; hard to do." (Richard Hamming, "The Art of Doing Science and Engineering: Learning to Learn", 1997)

"The computers make it possible for robots to do many things, including much of the present manufacturing. Evidently computers will play a dominant role in robot operation, though one must be careful not to claim the standard von Neumann type of computer will be the sole control mechanism, rather probably the current neural net computers, fuzzy set logic, and variations will do much of the control." (Richard Hamming, "The Art of Doing Science and Engineering: Learning to Learn", 1997)

"The desire for excellence is an essential feature for doing great work. Without such a goal you will tend to wander like a drunken sailor. The sailor takes one step in one direction and the next in some independent direction. As a result the steps tend to cancel each other, and the expected distance from the starting point is proportional to the square root of the number of steps taken. With a vision of excellence, and with the goal of doing significant work, there is tendency for the steps to go in the same direction and thus go a distance proportional to the number of steps taken, which in a lifetime is a large number indeed." (Richard Hamming, "The Art of Doing Science and Engineering: Learning to Learn", 1997)

"[...] the human brain has many, many components in the form of nerves interconnected with each other. We want to have the definition of 'thinking' to be something the human brain can do. With past failures to program a machine to think, the excuse is often given that the machine was not big enough, fast enough, etc. Some people conclude from this if we build a big enough machine then automatically it will be able to think! Remember, it seems to be more the problem of writing the program than it is building a machine, unless you believe, as with friction, enough small parts - will produce a new effect - thinking from non-thinking parts. Perhaps that is all thinking really is! Perhaps it is not a separate thing, it is just an artifact of largeness. One cannot flatly deny this as we have to admit we do not know what thinking really is." (Richard Hamming, "The Art of Doing Science and Engineering: Learning to Learn", 1997)

"The Turing test is a popular approach, but it flies in the face of the standard scientific method which starts with the easier problems before facing the harder ones. Thus I soon raised the question with myself, 'What is the smallest or close to the smallest program I would believe could think?' Clearly if the program were divided into two parts then neither piece could think. I tried thinking about it each night as I put my head on the pillow to sleep, and after a year of considering the problem and getting nowhere I decided it was the wrong question! Perhaps 'thinking' is not a yes-no thing, but maybe it is a matter of degree." (Richard Hamming, "The Art of Doing Science and Engineering: Learning to Learn", 1997)

"Things change so fast part of the system design problem is the system will be constantly upgraded in ways you do not now know in any detail! Flexibility must be part of modern design of things and processes. Flexibility built into the design means not only you will be better able to handle the changes which will come after installation, but it also contributes to your own work as the small changes which inevitably arise both in the later stages of design and in the field installation of the system." (Richard Hamming, "The Art of Doing Science and Engineering: Learning to Learn", 1997)

"Until we understand languages of communication involving humans as they are then it is unlikely many of our software problems will vanish." (Richard Hamming, "The Art of Doing Science and Engineering: Learning to Learn", 1997)

"We are beginning to find not only is intelligence not adequately defined so arguments can be settled scientifically, but a lot of other associated words like, computer, learning, information, ideas, decisions (hardly a mere branching of a program, though branch points are often called decision points to make the programmers feel more important), expert behavior - all are a bit fuzzy in our minds when we get down to the level of testing them via a program in a computer. Science has traditionally appealed to experimental evidence and not idle words, and so far science seem to have been more effective than philosophy in improving our way of life. The future can, of course, be different." (Richard Hamming, "The Art of Doing Science and Engineering: Learning to Learn", 1997)

"You must struggle with your own beliefs if you are to make any progress in understanding the possibilities and limitations of computers in the intellectual area." (Richard Hamming, "The Art of Doing Science and Engineering: Learning to Learn", 1997)