Can you share your favorite quote or rule related to IT?

Rafal Pienkowski on June 08, 2018

I like quotes and funny rules. A good quote makes our presentation more interesting, draws attention to the presenter and makes the presentation ... [Read Full]
markdown guide
 

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

 
 

Sadly true, I always multiply by 4, but I think I got to do power of 4

 
 

Individuals and interactions over processes and tools

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

 

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.
 
 
 

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

 
 

Just read a similar one!

Debugging code is twice as hard as writing it, so always write code as if you're a halfwit.

 

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

 

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

 

This is very similar to

Think twice, code once.

which I've heard some time ago.

 

There's nothing more permanent than a temporary solution.

-- Howard Cauvel

 

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

 

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

 

Similar to a line I've found myself saying a lot lately:

What's the best way to get something production-ready? Use it in production.

 
 
 

I love this quote from Mark Twain:

"continuous improvement is better than delayed perfection"

 

And here I thought Robert McCall said it first "progress not perfection" :)

 

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

 
 

Simple is better than complex.
Complex is better than complicated.

Two lines that particularly resonate me from the Zen of Python.

"It depends."

My friend Mike's standard initial response to a tech question. ; )

 

Funny, since people make fun of me for this pretty much being my first answer to most questions. And my name's Michael too. :D

 

Good patterns come from refactoring, not design.

 

One of the reasons Agile can be so powerful if used correctly

 

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

 

I've heard something similar to this but I don't know the author. The statement said one of my managers:

Nine women aren't able to born one child in one month.

 

Law of diminishing returns or law marginal utility?

 

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?!?

 

"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

 

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.

 

I adhere to the following tactic around comments: comments should tell you why the code is doing what it’s doing, not how. The how should be obvious from the code, the why can be less than obvious :-)

 
 

Well, at first it sounded to me like a very hard and a bit dumb statement. But then, after discussing with this guy, I realized it was quite convincing. The question beneath this statement, is: "Why would you need to comment?". In general, if you can say something directly and clearly in the code, you don't need to comment it.
Let's take a very simple example:

// logs the user
const x = user => {
    // ...
}

In this example, I think we all agree that the comment is completely useless since we could just make the name of the function more explicit. Then the comment would disappear. So it seems like an implicit rule, that when you can say something in an explicit way in the code, you do it in the code, instead of adding a comment.
Which takes us back to the first statement. Every comment in the code is a confession of failure. The guy told me "Sometimes you need to comment. It happens that you don't have the choice. But then it's a confession of failure, because you couldn't make the code clear enough to be readable and understandable without comments".

I think it's debatable when you take in account the rule "Always comment why and not how", but it's still very relevant in most cases.

I almost never write comments in my code, because everytime I want to, I ask myself first "Is there a way to make my code understandable without comments?".

 

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

  • Conway's Law
 

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

Rasmus Lerdorf - creator of php

 
 

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

 

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.

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

And don't forget the revisited version:

  1. There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors.
 

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?

 

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.

 

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»

 
 

"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

 

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

 

To be honest, this has nothing to do with IT. It seems to be a general rule of life that one should never assume anyone will follow any rule or convention.

 
 

To be honest, I hate this saying. It might make sense from a very short sighted business point of view but in the Long run it prevents progress and builds up technical debt.

Most of the times you say this you are wrong and you probably know it.

 

That's the thing I'm starting to learn over the years. It is in direct conflict with "continuous refactoring" that I try to live by, but the reality of business catch you.

 

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

Antoine de St Exupery

 
 

Unless you upgraded from Intel Broadwell's architecture to Skylake and newer :D

Why Skylake CPUs Are Sometimes 50% Slower – How Intel Has Broken Existing Code

Hint:

CPU Type Pause Duration In ns
Xeon E5 1620v3 3.5GHz 4
Xeon(R) Gold 6126 CPU @ 2.60GHz 43
 

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

 

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

  • Larry Flon (1975)
 

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

 

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

 

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

 

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

 
 

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

 

"I have offended God and mankind because my work did not reach the quality it should have." - Leonardo Da Vinci

This is something that I have always remembered when doing anything. Whether it's learning something new, helping others, or writing code. I use it as sorta a kind of motivation to always do better.

Unfortunately, after constantly reminding myself of it for years now, my work always seems disappointing to me

 
 

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

 

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

 
 

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

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

 

“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

 

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

 

Quote:

reboot does you good

This rule comes from a known person who has rebooted the server or computer whenever he has fixed a bug.

 

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)

:-)

 
 

Simplicity is the ultimate sophistication - Leonardo da Vinci

 

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

 

Never trust the user.

It greatly helped me when designing and building APIs and websites.

 

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

 

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

 

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

 
 
 

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

 

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.

 
 

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.

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

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.

 
 

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

Dave Butenhof on comp.programming.threads

 

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!

 

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

 
code of conduct - report abuse