Ask HN: What's some “one sentence” wisdom you've learned or created?
59 comments
"Measure twice, cut once"
No matter how many times I cut, it is never long enough.
"I've cut it twice and it's still too short."
Good for carpentry and brists
"Easy choices, hard life. Hard choices, easy life."
Bad news does not age well.
My interpretation of your aphorism: bad news is not forever.
not aging well implies the thing gets worse the older it is. So, a more accurate interpretation would be "bad news gets worse the older it is" Although that seems unlikely to be what was intended.
I read it the same way, with the sentiment of "People will be more upset if you delay telling them bad news."
e.g.
"We got a letter for past-due rent yesterday, and I'm telling you now"
vs.
"We've been getting letters for past-due rent the last few months, and I'm telling you now."
e.g.
"We got a letter for past-due rent yesterday, and I'm telling you now"
vs.
"We've been getting letters for past-due rent the last few months, and I'm telling you now."
"not age well" in food means "expires quickly." Milk does not age well because it quickly expires. So "bad news does not age well" means that bad news quickly expires. :)
The most general problem cannot be solved.
"If you have no backup, you have no data. If you have one backup, you have no backup."
Backups you've never tested are not a backup
(backups encrypted with a key no one has access to are not a backup)
(backups encrypted with a key no one has access to are not a backup)
If only I could have convinced my previous department head of this.
VMware snapshots are not backups.
similar version that's been around for a while:
Two is one. One is none.
Two is one. One is none.
Parkinson's Law of Data: "Data expands to fill the space available for storage"
Most frequent use: Justifying quotas on NAS/SAN devices. People retain more stuff when they think a shared drive has 500GB free than they do when they see 2TB free.
Most frequent use: Justifying quotas on NAS/SAN devices. People retain more stuff when they think a shared drive has 500GB free than they do when they see 2TB free.
"Your code should reflect your ontology."
Meaning that you should strive to program so as to encode the structure, relationships, and qualities of the objects of your task/domain. If you do it faithfully, then your code will be logically consistent and bug-free. I think this is most directly possible in declarative programming.
Meaning that you should strive to program so as to encode the structure, relationships, and qualities of the objects of your task/domain. If you do it faithfully, then your code will be logically consistent and bug-free. I think this is most directly possible in declarative programming.
The higher, the fewer.
Treat people like children and they’ll behave like children.
Not tech related:
Don't complain about being bored. Bored/boring means that people around you (e.g. family) aren't dying.
Don't complain about being bored. Bored/boring means that people around you (e.g. family) aren't dying.
Seems like the same logic as "finish your food, there are starving kids in Africa"
Or maybe more simply, “the bored are boring”
"Don't do people favors if they don't ask for them."
Sometimes in the corporate life, you imagine that X would like to have Y, and you put in a lot of effort to make Y happen. And then X is not even aware that Y took effort, or worse, you misinterpreted, and X is annoyed that Y happened. Better make sure that X really wants Y and asks for it.
Sometimes in the corporate life, you imagine that X would like to have Y, and you put in a lot of effort to make Y happen. And then X is not even aware that Y took effort, or worse, you misinterpreted, and X is annoyed that Y happened. Better make sure that X really wants Y and asks for it.
Change is a process.
It has been my experience that to change anything with an organisation takes a while. First you present your proposed change or new process. No one understands or pay attention. Once you implement and showcase the new process, expect objections as it dawns on people they might have to change how they do things. Don't take offense at the objections (which should have been aired at first meeting but no one was paying attention). Just agree to note them and then a week later present same thing you presented. Now you will find most people have processed the change and might even have tried new process or read the documentation. Now the change begins. It's a process.
It has been my experience that to change anything with an organisation takes a while. First you present your proposed change or new process. No one understands or pay attention. Once you implement and showcase the new process, expect objections as it dawns on people they might have to change how they do things. Don't take offense at the objections (which should have been aired at first meeting but no one was paying attention). Just agree to note them and then a week later present same thing you presented. Now you will find most people have processed the change and might even have tried new process or read the documentation. Now the change begins. It's a process.
You train people how to treat you.
"If someone does something once, they will do it twice"
This is in some ways depressing, but its always been true for me. Individual actions that are outside the realm of someones common patterns are extremely rare. So if they act in a certain way, expect that going forwards. Be cynical.
This is in some ways depressing, but its always been true for me. Individual actions that are outside the realm of someones common patterns are extremely rare. So if they act in a certain way, expect that going forwards. Be cynical.
Maya Angelou said it like this: "When someone shows you who they are, believe them the first time."
I like these three:
Eating the menu isn't the same as eating the meal. (I believe from fritz pearls).
Thinking is hard that's why most people go straight to judgement. (C Jung)
There's nothing more disgusting that a person with tons of resources (money, time, imagination) but who has no taste. (Paraphrase of Goethe)
Eating the menu isn't the same as eating the meal. (I believe from fritz pearls).
Thinking is hard that's why most people go straight to judgement. (C Jung)
There's nothing more disgusting that a person with tons of resources (money, time, imagination) but who has no taste. (Paraphrase of Goethe)
_ « if you can not afford to buy it, you certainly can not afford to build it »_
To eager business leads saying that a software or service is too expensive and we should build it internally instead...
To eager business leads saying that a software or service is too expensive and we should build it internally instead...
That's been quite false in my experience - quite a few times it was much easier / simpler / cheaper to build than buy, because there wasn't an offering good enough, and the cost of adaptation was on the order of the cost of building.
Many SAP and Oracle-software (not the DB, the other stuff) implementations fail, and take years to do so, after costing as much as building in house would have (and likely succeeded).
For some things, it's true - but I wouldn't consider this "generally applicable wisom"
Many SAP and Oracle-software (not the DB, the other stuff) implementations fail, and take years to do so, after costing as much as building in house would have (and likely succeeded).
For some things, it's true - but I wouldn't consider this "generally applicable wisom"
Motion.
Everything changes when you're in motion.
Everything changes when you're in motion.
I've got a bunch more, but these are some of my favorites ( after reading that it was for a mentee relationship, I had to remove some)
- You impact your environment, regardless of your participation, and even your presence
- Perception is a weak approximation for reality
- Value the opportunity to be wrong, because eventually you'll lose the privilege of being told so
- The greatest barrier to getting things done, is not doing things
- You impact your environment, regardless of your participation, and even your presence
- Perception is a weak approximation for reality
- Value the opportunity to be wrong, because eventually you'll lose the privilege of being told so
- The greatest barrier to getting things done, is not doing things
[deleted]
The race is not to the swift or the battle to the strong, nor does food come to the wise or wealth to the brilliant or favor to the learned; but time and chance happen to them all. - Ecclesiastes
Life does not always make sense, sometimes best efforts and best preparation fail. That is okay
Life does not always make sense, sometimes best efforts and best preparation fail. That is okay
My favorite variant of this is the version from Jean-Luc Picard on Star Trek: The Next Generation:
"It is possible to commit no mistakes and still lose. That is not a weakness. That is life."
"It is possible to commit no mistakes and still lose. That is not a weakness. That is life."
"I'd rather be lucky than good." :)
„Getting better is just screwing up less“ - Adam Savage
Doubt your own infallibility
"It's lonely at the top in whatever you do"
if you don't test it then it doesn't work.
"It doesn't matter what they do. It matters what you do."
Commandments I refer to often:
1. Make it work, then make it work well
2. The user doesn’t give a shit how it’s made
3. If you can’t measure it you can’t improve it
4. The problem is more important than the solution
5. Write code that is easy to delete
6. Buy right buy once
1. Make it work, then make it work well
2. The user doesn’t give a shit how it’s made
3. If you can’t measure it you can’t improve it
4. The problem is more important than the solution
5. Write code that is easy to delete
6. Buy right buy once
Well, it's life wisdom, but it has applications in software development (though not necessarily in a commit message ...)
Overabstraction is generally much worse than underabstraction.
The right level of abstraction is worth it's 'wc -l' in gold.
Murphy was an optimist. Everything that can go wrong, will, but at the most inopportune time (while demoing for the biggest client ever, for example).
The new thing can save you 10% at best, but easily cost you 50% (in delays, unexpected costs, bugs, ...); Prefer boring and established.
Everything has a context. "readability" is not absolute, it depends on your target audience.
Your dev/test machine should be slightly weaker than your user's to guarantee a usable product.
Most people decide if something was brave or foolish only in retrospect.
The best time to plant a tree is 20 years ago, but the next best time is today. That's extremely true for refactoring/code changes/decision making in general.
Praised be those who have nothing to say, and nevertheless remain silent (supposedly a German saying). Keep your descriptions short and to the point, don't go on rambling.
Most people, most of the time, aren't rational, but rationalizing (part of the problem is that we really believe the stories we tell ourselves, even though they are mostly post-hoc rationalization). Is that really why you did that?
Most people like to complain and blame things they can't change, but fear acting on things that they can change.
The game is mostly rigged against you (unless you are the incumbent. Then, the game is rigged by and for you - but you already knew that ...).
History is written by the victors, so take anything you weren't there to witness with a grain of salt -- including science history. (e.g. Barbara McClintock and Danny Shechtman were pariahs until they weren't, but evidence is being whitewashed). Extremely true for office and dev politics. And there are always politics.
Those who cast the votes determine nothing. Those who count the votes determine everything (supposedly by J.G.Stalin). Are you really a decision maker, or just imagine yourself to be?
Overabstraction is generally much worse than underabstraction.
The right level of abstraction is worth it's 'wc -l' in gold.
Murphy was an optimist. Everything that can go wrong, will, but at the most inopportune time (while demoing for the biggest client ever, for example).
The new thing can save you 10% at best, but easily cost you 50% (in delays, unexpected costs, bugs, ...); Prefer boring and established.
Everything has a context. "readability" is not absolute, it depends on your target audience.
Your dev/test machine should be slightly weaker than your user's to guarantee a usable product.
Most people decide if something was brave or foolish only in retrospect.
The best time to plant a tree is 20 years ago, but the next best time is today. That's extremely true for refactoring/code changes/decision making in general.
Praised be those who have nothing to say, and nevertheless remain silent (supposedly a German saying). Keep your descriptions short and to the point, don't go on rambling.
Most people, most of the time, aren't rational, but rationalizing (part of the problem is that we really believe the stories we tell ourselves, even though they are mostly post-hoc rationalization). Is that really why you did that?
Most people like to complain and blame things they can't change, but fear acting on things that they can change.
The game is mostly rigged against you (unless you are the incumbent. Then, the game is rigged by and for you - but you already knew that ...).
History is written by the victors, so take anything you weren't there to witness with a grain of salt -- including science history. (e.g. Barbara McClintock and Danny Shechtman were pariahs until they weren't, but evidence is being whitewashed). Extremely true for office and dev politics. And there are always politics.
Those who cast the votes determine nothing. Those who count the votes determine everything (supposedly by J.G.Stalin). Are you really a decision maker, or just imagine yourself to be?
This might sound silly, but the following, cited in Getting Things Done, helped me a lot:
"The middle of every successful project looks like a disaster"
Whenever I have setbacks, delays, whatever, this sentence can help me put things into perspective and keep at work rather than panicking. (Although of course, sometimes, things look like a disaster because that's what they are...)
"The middle of every successful project looks like a disaster"
Whenever I have setbacks, delays, whatever, this sentence can help me put things into perspective and keep at work rather than panicking. (Although of course, sometimes, things look like a disaster because that's what they are...)
- If you think you should ask the question, then you probably Already know the answer (questions that start with “should”, “do you think”, etc.
- when in doubt, keep it out (tru for most things from cooking to sex to commentary)
- when in doubt, keep it out (tru for most things from cooking to sex to commentary)
Making work complex is easy; keeping things simple is hard.
Success has a thousand fathers; failure has none.
Success has a thousand fathers; failure has none.
If you can’t do something about it, don’t worry. If you can, then do, and don’t worry.
No single raindrop thinks it is to be blamed for the flood.
When in doubts, do the right thing.
“You can work from anywhere” is just a big lie!
Today I realized "there's a fine line between credit and blame" but that's a little too pessimistic to be real advice.