\ ['I think a lot of new programmers like to use advanced data structures and advanced language features as a way of demonstrating their ability. I call it the lion-tamer syndrome. Such demonstrations are impressive, but unless they actually translate into real wins for the project, avoid them.','','- Glyn Williams'],
\ ['I would rather die of passion than of boredom.','','- Vincent Van Gogh'],
\ ['If a system is to serve the creative spirit, it must be entirely comprehensible to a single individual.'],
\ ["Progress in a fixed context is almost always a form of optimization. Creative acts generally don't stay in the context that they are in.",'','- Alan Kay'],
\ ['The essence of XML is this: the problem it solves is not hard, and it does not solve the problem well.','','- Phil Wadler'],
\ ['A good programmer is someone who always looks both ways before crossing a one-way street.','','- Doug Linder'],
\ ['Patterns mean "I have run out of language."','','- Rich Hickey'],
\ ['Always code as if the person who ends up maintaining your code is a violent psychopath who knows where you live.','','- John Woods'],
\ ['Unix was not designed to stop its users from doing stupid things, as that would also stop them from doing clever things.'],
\ ['Contrary to popular belief, Unix is user friendly. It just happens to be very selective about who it decides to make friends with.'],
\ ['There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies.','','- C.A.R. Hoare'],
\ ["If you don't make mistakes, you're not working on hard enough problems.",'','- Frank Wilczek'],
\ ["If you don't start with a spec, every piece of code you write is a patch.",'','- Leslie Lamport'],
\ ['Caches are bugs waiting to happen.','','- Rob Pike'],
\ ['Abstraction is not about vagueness, it is about being precise at a new semantic level.','','- Dijkstra'],
\ ["dd is horrible on purpose. It's a joke about OS/360 JCL. But today it's an internationally standardized joke. I guess that says it all.",'','- Rob Pike'],
\ ['All loops are infinite ones for faulty RAM modules.'],
\ ['All idioms must be learned. Good idioms only need to be learned once.','','- Alan Cooper'],
\ ['For a successful technology, reality must take precedence over public relations, for Nature cannot be fooled.','','- Richard Feynman'],
\ ['If programmers were electricians, parallel programmers would be bomb disposal experts. Both cut wires.','','- Bartosz Milewski'],
\ ['Computers are harder to maintain at high altitude. Thinner air means less cushion between disk heads and platters. Also more radiation.'],
\ ['Almost every programming language is overrated by its practitioners.','','- Larry Wall'],
\ ['Fancy algorithms are slow when n is small, and n is usually small.','','- Rob Pike'],
\ ['If C++ and Java are about type hierarchies and the taxonomy of types, Go is about composition.','','- Rob Pike'],
\ ['Methods are just functions with a special first argument.','','- Andrew Gerrand'],
\
\ ['Care about your craft.','','Why spend your life developing software unless you care about doing it well?'],
\ ['Provide options, don`t make lame excuses.','','Instead of excuses, provide options. Don`t say it can`t be done; explain what can be done.'],
\ ['Be a catalyst for change.','','You can`t force change on people. Instead, show them how the future might be and help them participate in creating it.'],
\ ['Make quality a requirements issue.','','Involve your users in determining the project`s real quality requirements.'],
\ ['Critically analyze what you read and hear.','','Don`t be swayed by vendors, media hype, or dogma. Analyze information in terms of you and your project.'],
\ ['DRY - Don`t Repeat Yourself.','','Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.'],
\ ['Eliminate effects between unrelated things.','','Design components that are self-contained, independent, and have a single, well-defined purpose.'],
\ ['Use tracer bullets to find the target.','','Tracer bullets let you home in on your target by trying things and seeing how close they land.'],
\ ['Configure, don`t integrate.','','Implement technology choices for an application as configuration options, not through integration or engineering.'],
\ ['Analyze workflow to improve concurrency.','','Exploit concurrency in your user`s workflow.'],
\ ['Always design for concurrency.','','Allow for concurrency, and you`ll design cleaner interfaces with fewer assumptions.'],
\ ['Use blackboards to coordinate workflow.','','Use blackboards to coordinate disparate facts and agents, while maintaining independence and isolation among participants.'],
\ ['Estimate the order of your algorithms.','','Get a feel for how long things are likely to take before you write code.'],
\ ['Refactor early, refactor often.','','Just as you might weed and rearrange a garden, rewrite, rework, and re-architect code when it needs it. Fix the root of the problem.'],
\ ['Test your software, or your users will.','','Test ruthlessly. Don`t make your users find bugs for you.'],
\ ['Don`t gather requirements - dig for them.','','Requirements rarely lie on the surface. They`re buried deep beneath layers of assumptions, misconceptions, and politics.'],
\ ['Abstractions live longer than details.','','Invest in the abstraction, not the implementation. Abstractions can survive the barrage of changes from different implementations and new technologies.'],
\ ['Don`t think outside the box - find the box.','','When faced with an impossible problem, identify the real constraints. Ask yourself: "Does it have to be done this way? Does it have to be done at all?"'],
\ ['Some things are better done than described.','','Don`t fall into the specification spiral - at some point you need to start coding.'],
\ ['Costly tools don`t produce better designs.','','Beware of vendor hype, industry dogma, and the aura of the price tag. Judge tools on their merits.'],
\ ['Don`t use manual procedures.','','A shell script or batch file will execute the same instructions, in the same order, time after time.'],
\ ["Coding ain't done 'til all the Tests run.",'',"'Nuff said."],
\ ['Test state coverage, not code coverage.','','Identify and test significant program states. Just testing lines of code isn`t enough.'],
\ ['English is just a programming language.','','Write documents as you would write code: honor the DRY principle, use metadata, MVC, automatic generation, and so on.'],
\ ['There are no final decisions.','','No decision is cast in stone. Instead, consider each as being written in the sand at the beach, and plan for change.'],
\ ['Prototype to learn.','','Prototyping is a learning experience. Its value lies not in the code you produce, but in the lessons you learn.'],
\ ['Use a single editor well.','','The editor should be an extension of your hand; make sure your editor is configurable, extensible, and programmable.'],
\ ['Fix the problem, not the blame.','','It doesn`t really matter whether the bug is your fault or someone else`s - it is still your problem, and it still needs to be fixed.'],
\ ['"select" isn`t broken.','','It is rare to find a bug in the OS or the compiler, or even a third-party product or library. The bug is most likely in the application.'],
\ ['Crash early.','','A dead program normally does a lot less damage than a crippled one.'],
\ ['Use exceptions for exceptional problems.','','Exceptions can suffer from all the readability and maintainability problems of classic spaghetti code. Reserve exceptions for exceptional things.'],
\ ['Don`t program by coincidence.','','Rely only on reliable things. Beware of accidental complexity, and don`t confuse a happy coincidence with a purposeful plan.'],
\ ['Test your estimates.','','Mathematical analysis of algorithms doesn`t tell you everything. Try timing your code in its target environment.'],
\ ['Don`t use wizard code you don`t understand.','','Wizards can generate reams of code. Make sure you understand all of it before you incorporate it into your project.'],
\ ['Work with a user to think like a user.','','It`s the best way to gain insight into how the system will really be used.'],
\ ['Start when you`re ready.','','You`ve been building experience all your life. Don`t ignore niggling doubts.'],
\ ['Don`t be a slave to formal methods.','','Don`t blindly adopt any technique without putting it into the context of your development practices and capabilities.'],
\ ['Organize teams around functionality.','','Don`t separate designers from coders, testers from data modelers. Build teams the way you build code.'],
\ ['Test early. Test often. Test automatically.','','Tests that run with every build are much more effective than test plans that sit on a shelf.'],
\ ['Use saboteurs to test your testing.','','Introduce bugs on purpose in a separate copy of the source to verify that testing will catch them.'],
\ ['Find bugs once.','','Once a human tester finds a bug, it should be the last time a human tester finds that bug. Automatic tests should check for it from then on.'],
\ ['Sign your work.','','Craftsmen of an earlier age were proud to sign their work. You should be, too.']