I think the bigger problem is that when people work in large groups for implementing a business logic, things are assumed invariant in one component of a system, not tested for in another component that relies on that condition, and what used to work ceases to work when that condition changes.
If it literally isn't labeled "invariant" explicitly in some documentation, people learn to practice 'defensive programming', after enough frustration. Or they feel compelled to understand all the code in their code base, or migrate over to smaller companies, smaller projects where this is less of a headache (but not really, because we all depend on pieces of systems we can't always inspect in totality, therefore, can't always assume we know everything about the systems we are dependent on).
The real world has edge cases. If the instructions are wrong, it's because either the invariant isn't actually an invariant in the real world, or the domain is modeled incorrectly. The higher up you get in writing programs about programs, the less likely it seems like real world data works this way, because you literally don't even have the common sense or perspective to see that some things change without being able to specify an underlying order to them (implying some things change without there being an order to describe their changing).
“A post can’t be published if it hasn’t been reviewed.” (Precondition)
“After submitting a payment, an audit log entry must be created” (post condition)
This is what I've seen in interviews. The typical recent grad can understand an existing model. Some of them can't design a simple model from scratch and concretely specify functions to do operations on it.
if the program doesn't do what they want it to do, either the instructions are wrong, or there need to be more of them to handle the cases that aren't currently handled.
I've asked interviewees what they could do about them cycles in user-entered code, by giving them a 2-node example. Far too often, they reply with an if-clause to detect exactly a 2-node cycle. Then I ask what to do about 3 nodes, then far too many of them try to give me a 2nd if-clause!
With a 2-node example what do you mean? Like a race condition? A mutex or some kind of lock to prevent this?
When you say node cycle. Do you mean like in graph theory where you can have the "fast and slow traversal" find a cycle?
It's understandable when it's a physicist or electrical engineer trying to code something up to get something working. What really upsets me is when it's professional software developers who never evolve out of that mindset.
I feel like at the end of the day the trick is to think algebraically -- Your data types and structures are some domain and you define operations over the elements of that domain in such a way that certain properties hold.
I mean, this is a bit like saying, why doesn't every physicist do everything by just coming up with a random differential equation for their problem then use fixed points to deduce the long-form non-recursive version and isolate out the wanted variables into long form ? It's, after all, usually by far the simpler process, especially since everyone can come up with a few differentials for any situation. Coming up with the correct long form directly, however, is absurdly hard. So if you simply learn to work with differentials, that's the way to approach essentially any problem. With a tiny caveat ... "learn to work with them" is 6 months of study and intensive practice, and that's assuming you already know a lot of math that isn't exactly high school level either, including a significant list of "tricks" that you just need to know by hard. But what you can do with it is amazing.
But the level of knowledge and understanding required is just too high for anything resembling general application.
Don't look at other videos until you've internalized the first sentence. Think long and hard about what that sentence means : differential equations allow you to find any function that you can make enough "what happens when it moves" observations about. Enough usually means one.
For instance you can find Newton's equations from the statement that "falling things keep going linearly faster" (because they're the simplest function that satisfies that differential equation).
On the more complex side, Google's pagerank is also the solution to a differential equation. Very technically it sort-of kind-of qualifies as a first-order one, just not in the real number space.
There's a separate branch of "differential equations" (let's call it "the physics branch") that studies how to work it with discrete time intervals rather than continuous ones, which is also interesting and useful.
Because this is not what writing software is about. Ultimately it is about trying ideas out, where the notion of an invariant doesn't have a place. Why do you believe it should?
Are you saying that if the code doesn't solve the problem the wrong thing to do is add more to it? What about when you have multiple options, you can't just avoid adding more instructions necessarily?
Can you give a real example about what you are talking about?
Part of me is thinking that you are saying new grads are not readily able to come up with a clever solution and instead brute force. But you are not saying it in so little words, or in any intelligible way to me.