I like quotes and funny rules. A good quote makes our presentation more interesting, draws attention to the presenter and makes the presentation un...
For further actions, you may consider blocking this person and/or reporting abuse
Not restricted to IT, but anyone who has tried estimating work can relate to this:
Hofstadter's Law
Ha! That's great.
Sadly true, I always multiply by 4, but I think I got to do power of 4
love this!
❤
This sentence reminds me Dr House's favorite saying:
The first thing that came to my mind !
Status: critical.
"Top Priority" and hasn't responded to the ticket in a year and a half.
"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!
It's so real.
-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.
What's PI?
3.141519265358979323.....
The first line of the Agile Manifesto is the one that gets ignored the most.
This is very similar to
which I've heard some time ago.
My other favorite is this:
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:
I like this one!
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" :)
"Have you tried turning it off and on again?"
First rule of IT 😂
I've heard this many times from my sys admins.
Now I want to watch Roy and Moss again
Me :-)
Nice :)
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):
That can't happen.
That doesn't happen on my machine.
That shouldn't happen.
Why does that happen?
Oh, I see...
How did that ever work?!?
"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:
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:
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:
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
"I don't know how to write php. Php is made in c, not in php."
Rasmus Lerdorf - creator of php
Not specific to dev, but highly relevant :
store.dftba.com/products/fail-fast...
My favourite will always be
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.
I like the classics:
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.
A recent one I got from Working Effectively with Legacy Code:
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:
And don't forget the revisited version:
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
Perfection is attained, not when there is nothing more to add, but when there is nothing more to take away.
Antoine de St Exupery
"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.
"If it works, don't touch it"
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.
"In God we trust, all others must bring data." - W. Edwards Deming
This is an actual statement of one of our CEOs actively steering application development:
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"
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
Hint:
443In order to understand recursion, you must first understand recursion.
Nah, you just need to know about call stacks.
This one is rather interesting ;"First do it,then do it right then do it better "~Addy Osmani
“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
Easy, good, cheap. Pick two.
I know this one as: cheap, fast, good.
Garbage in garbage out
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
The Elements of Programming Style, 2nd edition, chapter 2
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."
"With enough time and money we can code anything!"
"It's not magic, it's only math."
"Ask Google", works nearly every time.
If it doesn't: "Sleep on it"
Peter Drucker
"I never commit to memory anything that can easily be looked up in a book" - Albert Einstein
Nice.I like it.
I believe that Da Vinci was in fact a figure of a higher scale than everyone else in general. They are born maybe once in 1000 years, or even more. Now there are no people of such a scale of thinking and in general of creativity. Millions of stories, poems, articles and essays have been written about him. I myself wrote an essay in college about him, by the way, if you need to learn a lot of possible even new information for you should be on studydriver.com and it is there to get acquainted with them. It is very detailed and detailed just about him, there are many different essays and other materials about Da Vinci and his creations, which he gave to this world.
For anyone who wants to start something but still feels difficult and feels like giving up.
Haha, this is the best.
RTFM
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
“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)
— 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:
:-)
"Programming isn't meant to be easy, and if it is, Then you're doing it wrong."
... instead of picking up Djikstra's cute acronym we should have called the basic synchronization object "the bottleneck".
Dave Butenhof on comp.programming.threads
...Because we all need rules to guide us through the minefield known as the staff fridge!
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.
Write code like a blind man is going to read it
Favorite Quote: "When you have ruled out everything possible, it must be what is left" Sherlock Holmes, circa 1867