Today I realized "there's a fine line between credit and blame" but that's a little too pessimistic to be real advice.
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.
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.
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.
Life does not always make sense, sometimes best efforts and best preparation fail. That is okay
"It is possible to commit no mistakes and still lose. That is not a weakness. That is life."
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.
(backups encrypted with a key no one has access to are not a backup)
Two is one. One is none.
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
Stupidity is more likely than bad actors. Usually.
- 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
"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...)
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)
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.
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."
Don't complain about being bored. Bored/boring means that people around you (e.g. family) aren't dying.
- when in doubt, keep it out (tru for most things from cooking to sex to commentary)
To eager business leads saying that a software or service is too expensive and we should build it internally instead...
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"
Success has a thousand fathers; failure has none.
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?
Everything changes when you're in motion.