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

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

rafalpienkowski profile image Rafal Pienkowski ・1 min read

I like quotes and funny rules. A good quote makes our presentation more interesting, draws attention to the presenter and makes the presentation unforgettable. Ridiculous or easy-to-remember rules help us keep in mind essential things.

Below one of my favorites:

  • Quote

    "A language that doesn't affect the way you think about programming is not worth knowing."
    Alan Perlis

  • Rule

    "A team shouldn't be larger than what two pizzas can feed."
    Jeff Bezos

Now it's your turn to share your quotes and rules related to IT ;)

Posted on by:

rafalpienkowski profile

Rafal Pienkowski


I'm focused on developing and expanding my knowledge and skills. Enjoying new challenges. I'm assuming that there are no stupid questions, there are only silly answers.


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


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


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.

This sentence reminds me Dr House's favorite saying:
Dr House


The first thing that came to my mind !


"Top Priority" and hasn't responded to the ticket in a year and a half.


Individuals and interactions over processes and tools

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


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.


I heard somewhere that multiplying a developers time estimate by PI is very accurate most of the time.


Talk is cheap. Show me the code. -Linus Torvalds


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


There's nothing more permanent than a temporary solution.

-- Howard Cauvel


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


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


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.


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


I've heard this many times from my sys admins.


Now I want to watch Roy and Moss again


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

Me :-)


Good patterns come from refactoring, not design.


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


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


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


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


"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 :-)


What are your views on this quote?


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


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

Rasmus Lerdorf - creator of php


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

  • Conway's Law

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


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.


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?


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.

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»


I wasn't aware of that. Good to know this.


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


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

Antoine de St Exupery


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.


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


All computers wait at the same speed.


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


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


"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


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


Nah, you just need to know about call stacks.


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


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


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


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


“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 know this one as: cheap, fast, good.