I have seen many similar posts what people have learned but not once have I seen:
"Don't assume anything".
So many times when shit hit the bricks because someone assumed something about some other thing they clearly don't know everything about. Which eventually lead to the system failing.
That's a useless advice IMO. How can you not assuming anything. I assume that my CPU works, for example. You can't write useful programs without many assumptions. Imagine program that does not assume that CPU works and reruns every algorithm few times with few different code versions to verify that outputs match. It might make sense for moon mission, but definitely not for another CRUD app.
I don't have 20 years of experience yet. But my PoV is as follows: assume as much as you can and ensure that if those assumptions are broken, you have fail-fast-and-log triggers (when it's possible). So when that trigger hits, you'll understand what assumption is broken. For example in Java I'll write Objects.requireNonNull(x, "x") and move on. If that assumption is broken, I'll have stack trace in my logs and I'll write additional logic. It won't take much time. But if that assumption will not be broken, I just saved few hours of time and few dozens of LoC from future maintenance.
Some people hate NullPointerExceptions and want to get rid of them. I love them. They're incredibly useful for me.
This is not a blind assumption that you make, but one based on lots of evidence (for example you are aware of the testing procedures and QA processes of the CPU manufacture, and you are aware that millions of people and companies use the same CPU model as you and if there were bugs they would have detected them).
If you were to buy some CPU that someone shady made themselves in their basement, them you would probably not make the assumption that the CPU works.
A lot of times programmers make assumptions without properly verifying that the assumption is true, and that is when problems happen. for example, when working with a library function, the programmer might test that it works with certain types of inputs and then just assume that it also works with other types, without actually checking the documentation or verifying
TBH, I got bitten by this assumption. Once, in the course of many decades. A single flipped bit - in a place where it never could happen in the program. After checking everything up and down the stack, this was our conclusion: "the issued command was invalid, thus caught and aborted; the higher-level operation was rolled back, retried, and succeeded; impact: some insignificant delay; root cause: probably cosmic rays; probability of repeating: infinitesimal. Result: no point in guarding against that." (Note that this was in normal athmospheric conditions, not in deep space, hence the probability.)
I completely agree with your second paragraph but the last sentence seems like you don't know what people mean when they say they hate NullPointerExceptions.
They don't mean that you just silently ignore the null value, they mean that they would prefer to use a language that has proper optional types.
People tend to not languages without null though. They have all those NullPointerExceptions in their mind and figure coding would be easier if those didn't exist, but when you give them that they don't like it. Null sits in a very nice spot between dynamic typing and static typing.
You are doing exactly that, assuming nothing. The number of times I've seem "meh, x can't be null here, just do nothing about it" (instead of some way of asserting that assumption, such as you provide) is staggering.
It would be impossible to do any work at all without making assumptions.
This attitude belies the fact that of the 1000s of assumptions you make every day 1 or 2 will end up being incorrect, but it's usually very, very hard or even impossible to know which in advance.
Yes the point would better rather be made as "continually question your assumptions" especially when troubleshooting (hence the value of having a rubber duck).
The original point is invalid, although one could say that being good at systematically validating and invalidating assumptions is the sign of a good engineer.
One who doesnt make assumptions at all just wouldnt do anything, though.
I assume that when I press a key on my keyboard, the corresponding character will show up in my code editor. If I couldn't assume that, I doubt I'd see the use of pressing any keys at all.
(For clarity's sake: Not disagreeing at all, just illustrating your point with a reductio ad absurdum example.)
It’s fine when you don’t do it deliberately. It’s just that about 100% of the time someone says “I just assumed…” that is the source of whatever problem you are having.
A principal I worked with for a couple years, actually has that quote up on the wall of his office. It is specially true with projects where you have multiple teams or distributed systems.
"Don't assume anything".
So many times when shit hit the bricks because someone assumed something about some other thing they clearly don't know everything about. Which eventually lead to the system failing.