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

Discussion

pic
Editor guide
Collapse
evanoman profile image
Evan Oman

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

Collapse
ben profile image
Ben Halpern

Ha! That's great.

Collapse
k1pash profile image
Christopher Toman

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

Collapse
c33s profile image
Julian

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

Collapse
r3i profile image
R3i

love this!

Collapse
6ones profile image
Collapse
dhandspikerwade profile image
Devin Handspiker-Wade

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.
Collapse
rafalpienkowski profile image
Rafal Pienkowski Author

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

Collapse
sudiukil profile image
Quentin Sonrel

The first thing that came to my mind !

Collapse
buinauskas profile image
Evaldas

Status: critical.

Collapse
dhandspikerwade profile image
Devin Handspiker-Wade

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

Collapse
ben profile image
Ben Halpern

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.

Collapse
tmcsquared profile image
TMcSquared

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

Collapse
designpuddle profile image
Thread Thread
tmcsquared profile image
TMcSquared

3.141519265358979323.....

Collapse
quii profile image
Chris James

Individuals and interactions over processes and tools

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

Collapse
cadellsinghh_25 profile image
Cadell

"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

Collapse
leahein profile image
Leah Einhorn

Just read a similar one!

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

Collapse
rafalpienkowski profile image
Collapse
jaimezjacinto profile image
Jacinto Jaimez

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

Collapse
cathodion profile image
Dustin King

There's nothing more permanent than a temporary solution.

-- Howard Cauvel

Collapse
rpalo profile image
Ryan Palo

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

Collapse
momennano profile image
Nano.

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

Collapse
rafalpienkowski profile image
Rafal Pienkowski Author

This is very similar to

Think twice, code once.

which I've heard some time ago.

Collapse
ildoc profile image
Filippo

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

Collapse
sethusenthil profile image
Sethu Senthil

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

Collapse
cjbrooks12 profile image
Casey Brooks

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.

Collapse
sylardie profile image
Moner

I like this one!

Collapse
aleron75 profile image
Alessandro Ronchi

I love this quote from Mark Twain:

"continuous improvement is better than delayed perfection"

Collapse
tedhagos profile image
Ted Hagos

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

Collapse
brianemilius profile image
Brian Emilius

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

Collapse
andrekelvin profile image
AndreKelvin

First rule of IT 😂

Collapse
rafalpienkowski profile image
Rafal Pienkowski Author

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

Collapse
tedhagos profile image
Ted Hagos

Now I want to watch Roy and Moss again

Collapse
adnanrahic profile image
Adnan Rahić

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

Collapse
t4rzsan profile image
Jakob Christensen

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

Me :-)

Collapse
rafalpienkowski profile image
Collapse
suzuki11109 profile image
Suzuki Aki

Good patterns come from refactoring, not design.

Collapse
designpuddle profile image
Chris Bertrand

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

Collapse
jballanc profile image
Joshua Ballanco

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

Collapse
forstmeier profile image
John Forstmeier

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

Collapse
citizen428 profile image
Michael Kohl

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

Collapse
chiff profile image
Chiffre

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

Collapse
rafalpienkowski profile image
Rafal Pienkowski Author

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.

Collapse
tedhagos profile image
Ted Hagos

Law of diminishing returns or law marginal utility?

Collapse
tonyhicks20 profile image
Tony Hicks

"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

Collapse
einenlum profile image
Yann Rabiller

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.

Collapse
nielsbom profile image
Niels Bom

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

Collapse
ky1e_s profile image
Kyle Stephens

What are your views on this quote?

Collapse
einenlum profile image
Yann Rabiller

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

Collapse
ky1e_s profile image
Kyle Stephens

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

  • Conway's Law
Collapse
josipbartulovic profile image
JosipBartulovic

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

Rasmus Lerdorf - creator of php

Collapse
olubori profile image
John Olubori David

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

Collapse
gmartigny profile image
Guillaume Martigny

Not specific to dev, but highly relevant :

"Fail faster !"
Extra Credits

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

Collapse
c33s profile image
Julian

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?

Collapse
val_baca profile image
Valentin Baca

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.

Collapse
avalander profile image
Avalander
  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.
Collapse
ferricoxide profile image
Thomas H Jones II

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.

Collapse
maremarismaria profile image
María

"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

Collapse
belinde profile image
Franco Traversaro

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»

Collapse
rafalpienkowski profile image
Rafal Pienkowski Author

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

Collapse
nestedsoftware profile image
Nested Software

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

Antoine de St Exupery

Collapse
cgortaris profile image
Carlos Gortaris

"If it works, don't touch it"

Collapse
fpuffer profile image
Frank Puffer

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.

Collapse
gmartigny profile image
Guillaume Martigny

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.

Collapse
zasuh_ profile image
Žane Suhadolnik

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

Collapse
darkwiiplayer profile image
DarkWiiPlayer

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.

Collapse
tedhagos profile image
Ted Hagos

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

Collapse
theredspy15 profile image
Hunter Drum

"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

Collapse
across_the_grid profile image
Nicho

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

Collapse
pichardoj profile image
J. Pichardo

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

  • Larry Flon (1975)
Collapse
leahein profile image
Leah Einhorn

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

Collapse
hackingforlife profile image
Hackingforlife

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

Collapse
slavius profile image
Slavius

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

Collapse
nestedsoftware profile image
Nested Software

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

Collapse
cathodion profile image
Dustin King

Nah, you just need to know about call stacks.

Collapse
ikysil profile image
Illya Kysil

All computers wait at the same speed.

Collapse
slavius profile image
Slavius

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
Collapse
antonfrattaroli profile image
Anton Frattaroli

“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

Collapse
madinnella profile image
Mike Dinnella

Easy, good, cheap. Pick two.

Collapse
nielsbom profile image
Niels Bom

I know this one as: cheap, fast, good.

Collapse
plasteezy profile image
plasteezy

Garbage in garbage out

Collapse
vinayhegde1990 profile image
Vinay Hegde

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

Collapse
dmerand profile image
Donald Merand

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

Collapse
sreisner profile image
Shawn Reisner

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

Collapse
twmcd profile image
Tom McDonald

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