Software Engineering Quotes

“Truth can only be found in one place: the code.”
― Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship

“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

“The bearing of a child takes nine months, no matter how many women are assigned.”
― Frederick Brooks

“If it hurts, do it more frequently, and bring the pain forward.”
― Jez Humble, Continuous Delivery: Reliable Software Releases Through Build, Test, and Deployment Automation

“You must excuse my gruff conduct,” the watchdog said, after they’d been driving for some time, “but you see it’s traditional for watchdogs to be ferocious.”
― Norton Juster, The Phantom Tollbooth

“The conclusion is simple: if a 200-man project has 25 managers who are the most competent and experienced programmers,
fire the 175 troops and put the managers back to programming.”
― Frederick Brooks

“Heuristic is an algorithm in a clown suit. It’s less predictable, it’s more fun, and it comes without a 30-day, money-back guarantee.”
― Steve McConnell, Code Complete

“In the mid-1990s, a new employee of Sun Microsystems in California kept disappearing from their database. Every time his details were entered, the system seemed to eat him whole; he would disappear without a trace. No one in HR could work out why poor Steve Null was database kryptonite. The staff in HR were entering the surname as “Null,” but they were blissfully unaware that, in a database, NULL represents a lack of data, so Steve became a non-entry. To computers, his name was Steve Zero or Steve McDoesNotExist. Apparently, it took a while to work out what was going on, as HR would happily reenter his details each time the issue was raised, never stopping to consider why the database was routinely removing him.”
― Matt Parker, Humble Pi: A Comedy of Maths Errors

“If you see me make sure you say I Don't Do It, U Do It!!!”
― U Do It

“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.

The latter is useless - it’s petty and nearly impossible to act on. The former can (and should!) be helpful and give guidance on how to improve. And, most important, it’s imbued with respect: the person giving the constructive criticism genuinely cares about the other person and wants them to improve themselves or their work. Learn to respect your peers and give constructive criticism politely. If you truly respect someone, you’ll be motivated to choose tactful, helpful phrasing—a skill acquired with much practice.”
― Titus Winters, Software Engineering at Google: Lessons Learned from Programming Over Time

“Sometimes, the best thing you can do is just say, “I don’t know.”
― Titus Winters, Software Engineering at Google: Lessons Learned from Programming Over Time

“As an engineer, you might wield more power than you realize: the power to literally change society. It’s critical that on your journey to becoming an exceptional engineer, you understand the innate responsibility needed to exercise power without causing harm. The first step is to recognize the default state of your bias caused by many societal and educational factors. After you recognize this, you’ll be able to consider the often-forgotten use cases or users who can benefit or be harmed by the products you build.”
― Titus Winters, Software Engineering at Google: Lessons Learned from Programming Over Time

“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

“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

“Evolving a widely reused resource also requires coordination because changes must be compatible with all existing systems or users. Such coordination can slow down innovation... Some digital companies have even begun to explicitly favor duplication because their business environment rewards economies of speed.”
― Gregor Hohpe, The Software Architect Elevator: Redefining the Architect's Role in the Digital Enterprise

“Despite being roughly twice as many characters, it requires a fraction of the mental effort when you read it”
― Felienne Hermans, The Programmer's Brain

“Even if the ecosystem doesn’t change, what about the gradual erosion of architectural characteristics that occurs? Architects design architectures, but then expose them to the messy real world of implementing things atop the architecture. How can architects protect the important parts they have defined?”
― Neal Ford, Building Evolutionary Architectures: Support Constant Change

“By placing an external tool or framework at the heart of the architecture, developers severely restrict their ability to evolve in two key ways, both technically and from a business process standpoint. Developers are technically constrained by choices the vendor makes in terms of persistence, supported infrastructure, and a host of other constraints.”
― Neal Ford, Building Evolutionary Architectures: Support Constant Change

“Simplicity only makes sense in context. If I’m writing a parser with a team that understands parser generators, then using a parser generator is simple. If the team doesn’t know anything about parsing and the language is simple, a recursive descent parser is simpler.”
― Kent Beck, Extreme Programming Explained: Embrace Change

“SΦRT = Return Set Time In Order”
― Jonathan Roy Mckinney

“Time*SΦRT(Return cpyConstructor SΦRT{*Ifin.OrderedSet});”
― Jonathan Roy Mckinney

“What Is Bubble SΦRT? A method or controller that retrospects offsets in turn or reading/writing Hashed Object Based Storage Inna LIFO Stack. The halen in a controller that hard copies object storage van stack is basic MVC as it follows operating system principles to the core.”
― Jonathan Roy Mckinney Gero EagleO2

“Diablo Space Time Set Code Abstract : Sacred Globe Inna Whorl Turn Ring > BubbleSort = Off = BindMetaQuadSwitch = Bool BindSΦRT(SΦRT{FindHashSet({BindMetaQuadSwitch() = On;})});”
― Jonathan Roy Mckinney Gero EagleO2

“It doesn’t take a huge amount of knowledge and skill to get a program working.
Kids in high school do it all the time.
Getting it right is another matter entirely.
When software is done right, it requires a fraction of the human resources to
create and maintain.”
― Robert C. Martin, Clean Architecture

“The essence of authentication is being able to prove the assertion you are making.”
― Akshat Paul, Serverless Web Applications with AWS Amplify: Build Full-Stack Serverless Applications Using Amazon Web Services

“APIs are the conduits through which data flows, applications communicate and functionality is shared.”
― Akshat Paul, Serverless Web Applications with AWS Amplify: Build Full-Stack Serverless Applications Using Amazon Web Services

“Building a powerful frontend is an art, but it becomes a masterpiece when it is integrated seamlessly with APIs.”
― Akshat Paul, Serverless Web Applications with AWS Amplify: Build Full-Stack Serverless Applications Using Amazon Web Services

“Offline-first is not just a feature, it’s a mindset. It’s about building resilient systems that empower users, no matter their connection status.”
― Akshat Paul, Serverless Web Applications with AWS Amplify: Build Full-Stack Serverless Applications Using Amazon Web Services

“Analytics will not replace decision-makers, but decision-makers who use analytics will replace those who do not.”
― Akshat Paul, Serverless Web Applications with AWS Amplify: Build Full-Stack Serverless Applications Using Amazon Web Services

“Understanding the foundational principles of cloud computing is essential for designing and developing solutions in the cloud.”
― Jonah Andersson, Learning Microsoft Azure: Cloud Computing and Development Fundamentals