Individuals and interactions over processes and tools

The first line of the Agile Manifesto is the one that gets ignored the most.

There's the "law of conservation of complexity". Which is to say, just because a technology-user no longer sees the complexity, doesn't mean it isn't still there. First really encountered it when trying to Network Apple systems in the first half of the 90s. While setting up ad hoc networks of all-Apple systems was fairly trivial, integrating them with non-apple products was paaaaaaaaaaaaaainful for administrators. Users never really saw the "behind the scenes" pain, though. They just knew that, one week, suddenly they were able to see the rest of the corporation's IT assets. But, damn, the sustainment of the setup was fragile.

A bug is like an iceberg - it always goes ten times deeper than you can see.

Me :-)

Users lie. They may not be lying about an issue, how they ran into the issue, or how the bug is affecting them but assume there's at least one lie in every bug report. It may be something completely unimportant. They have no reason to lie, but they will.

• A past manager of mine.

"There's never enough time to do things properly but always time to come back and fix it later" - No idea who said that but it's been the common theme with most businesses I've seen

Not restricted to IT, but anyone who has tried estimating work can relate to this:

Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law

Hofstadter's Law

Not specific to dev, but highly relevant :

"Fail faster !"
Extra Credits

store.dftba.com/products/fail-fast...

If you don't succeed in your first attempt, call it version 1.0

The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time.

-Tom Cargill

There’s even a Wikipedia page about the 90-90 rule.

"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, be definition, not smart enough to debug it." - Brian Kernighan

Always code as if the guy who ends up maintaining your code will be a
violent psychopath who knows where you live.

John F. Woods

In Italy two pizzas means two people, so it's a pretty small team! 😁
Back in topic:
«the three virtues of a great programmer: impatience, lazynes, and hybris»

Creativity is allowing yourself make mistakes, design is knowing which ones to keep.

Make it work, make it right, make it fast.
-- Kent Beck

My other favorite is this:

if you ever code something that "feels like a hack but it works," just remember that a CPU is literally a rock that we tricked into thinking
[...]
not to oversimplify: first you have to flatten the rock and put lightning inside it
-- @daisyowl

There is no programming language, no matter how structured, that will prevent programmers from making bad programs."

• Larry Flon (1975)

Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?

The Elements of Programming Style, 2nd edition, chapter 2

"I don't know how to write php. Php is made in c, not in php."

Rasmus Lerdorf - creator of php

"Ask Google", works nearly every time.
If it doesn't: "Sleep on it"

"If it works, don't touch it"

Good patterns come from refactoring, not design.

I've always liked the classic, "Always write your code as if the person who'll maintain it is a violent psychopath who knows where you live."

organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations

• Conway's Law

"Weeks of coding can save you hours of planning." - Unknown

Confusion is your friend. If you feel confused, remember that's when you're learning.

• Mattias P. Johansson, Funfunfunction

"Have you tried turning it off and on again?"

Not exactly related to IT but I'm sure everyone here who's maintained any aspect of a production environment will resonate with this:

Whatever can go wrong, will go wrong - Murphy's Law

Write code like a blind man is going to read it

I like the classics:

1. Premature optimization is the root of all evil.

Shaving 1ns off code executed once or even 100 times probably isn't going to matter. Plus, your intuitions of where to optimize are bad.

1. There are only two hard things in Computer Science: cache invalidation and naming things.

A recent one I got from Working Effectively with Legacy Code:

1. Programming is the art of doing one thing at a time.

This applies to your code and to the act of writing code. Methods should do one thing well. At a single time, you should be doing one thing well. Do tests, refactoring, and new features individually and you'll benefit.

A few others that are more life-quotes, but I think apply:

1. Be regular and orderly in your life so that you may be violent and original in your work

2. Small things, if not corrected, become big things, always.

3. If you get tired, learn to rest, not to quit.

In order to understand recursion, you must first understand recursion.

Culture eats strategy for breakfast

Peter Drucker

"In God we trust, all others must bring data." - W. Edwards Deming

Coders are special. "We are expected to know how to do things we've never done before and estimate how long they will take."

Perfection is attained, not when there is nothing more to add, but when there is nothing more to take away.

Antoine de St Exupery

In one of my first IT job interviews, the boss asked me my views about this quote:

Every comment in the code is a confession of failure.

It's quite a harsh statement, but I keep it in my mind, every time I code.

Simplicity is the ultimate sophistication - Leonardo da Vinci

There's nothing more permanent than a temporary solution.

-- Howard Cauvel

"As IT professionals, we need to look both ways before crossing a one way street."

No idea who said it, but it couldn't be more true for this field.

Garbage in garbage out

It's a "best before" date, not a "don't eat after" date.

...Because we all need rules to guide us through the minefield known as the staff fridge!

"To me code has more in common with for example poetry or some kinds of writing. The beauty of it is in the structure, [...] So a good piece of code you can read without comments and it's immediately obvious why it's been written, how it's elegant."

Alan Cox

The string is a stark data structure and everywhere it is passed there is much duplication of process. It is a perfect vehicle for hiding information.

-- Alan J. Perlis

All computers wait at the same speed.

... instead of picking up Djikstra's cute acronym we should have called the basic synchronization object "the bottleneck".

Dave Butenhof on comp.programming.threads

I love this quote from Mark Twain:

"continuous improvement is better than delayed perfection"

"What one programmer can do in one month, two programmers can do in two months." - Fred Brooks

The Six Stages of Debugging (from here):

1. That can't happen.

2. That doesn't happen on my machine.

3. That shouldn't happen.

4. Why does that happen?

5. Oh, I see...

6. How did that ever work?!?

This one is rather interesting ;"First do it,then do it right then do it better "~Addy Osmani

• If you find yourself writing the same thing over and over, you are doing something wrong

“User experience is everything. It always has been, but it’s still undervalued and under-invested in. If you don’t know user-centered design, study it. Hire people who know it. Obsess over it. Live and breathe it. Get your whole company on board.” – Evan Williams

My mind is like a browser. 27 tabs are open, 9 aren't responding, lots of pop-ups... and where is that annoying music coming from?

"Walking on water and developing software from a specification are easy if both are frozen."
-- Edward V Berard

My favourite will always be

“There are only two kinds of languages: the ones people complain about and the ones nobody uses.”

― Bjarne Stroustrup, The C++ Programming Language

"With enough time and money we can code anything!"

This is an actual statement of one of our CEOs actively steering application development:

No standard(s) dare to stand in a way of a "good solution".

It still brings mixed emotions to me after all those years (I wanted to cry and laugh hysterically at the same time when someone repeated that...)

Easy, good, cheap. Pick two.

RTFM

"We can solve any problem by introducing an extra level of indirection"

"Programming isn't meant to be easy, and if it is, Then you're doing it wrong."

"It's not magic, it's only math."

• A website I used to make conversion from decimal to binary and hex as I was starting to code, about 10 years ago. I can't remember the name.

“Everything that is syntactically legal that the compiler will accept will eventually end up in your codebase" - John Carmack (creator of Doom and Wolfenstein 3D)

"I never commit to memory anything that can easily be looked up in a book" - Albert Einstein

For anyone who wants to start something but still feels difficult and feels like giving up.

I’m Not Smart, I Just Sat Here for Longer Than You.

Your First Attempt says more about you

Improve code by removing it

— Pete Goodliffe

The moment I read that quote in "97 things every programmer should know", I thought that it perfectly encapsulates my position towards code.

very nice post. I noted down lots of quotes from the comments as well.

and now I drop this one:

the quotes are simple, the execution is hard. (garyvee)

:-)

You will always write any code and configure anything you administer at least twice. So always consider automation and refactoring as part of your workflow.

Favorite Quote: "When you have ruled out everything possible, it must be what is left" Sherlock Holmes, circa 1867