Skipping corners, not verifying correctness is necessary for productivity. There are multiple levels of correctness. Rubbish > Does Something > Reasonable > Justified > Correct > Omniscient optimal. The level of correctness needs to be observable.
Most of the time you programme more specific results than you actually need. Don't do this
Writing correct code the first time is economically unviable.
Firstly, Human brains are not good at logic. Trying to programme as logical discipline. Rather, we must turn programming into a empirical discipline. The work of programmers is to make the behaviour of code observable/verifiable. We verify the properties of code, not reason about them.
Secondly, you are likely never working in a closed logical system, but rather calling APIs. The API contracts are never complete enough (or correct) to logical write a program. The only way to proceed is empirically.
It's a waste of time to even try to write some first time. Always write something incorrect then debug it. It's a waste of time to reason about code. Figure out a way to write code that is debugable. Writing debugable code is the core skill of the professional programmer.
Programming is not intrinsically rewarding, unlike say running with the runners high. The only way to stay programming is by making it a habit.
You cant program because you take too long to debug you code. But the thing is debugging should be done by programming not reasoning. So the real reason why you cant debug fast and stress free, is that you cant really program in the first place.
It doesn't require much skill to write a program. But that program always has bugs. It requires significant amount skill to be able to debug programatically consistently and reliably. It is this level you actually need to be a professional programmer.
You create information out of nothing by merely using words.
But also it is like a magic trick. One way get a magic trick to fool people is by spending more time, money and practice than they think is possible.
The key skill of programming is enduring tedium.
https://www.reddit.com/r/programming/comments/mnqck2/embrace_the_grind/
https://softwareengineering.stackexchange.com/a/443857/366664
I'd say the whole development process relies on invariants.
You write some code, that produces observable behaviour.
You then modify the code, with the goal that most of the observable behaviour remains invariant. When the invariant fails, you then git diff to figure out what change caused it to break.
Unit tests are used when the required invariant behaviours become too much to check in the development loop.
Learning to code is mostly about figuring out how to do this; i.e. decomposing the desired behaviour into a set of invariant behaviours which you are able to evolve into complex behaviours.
A good example is the movement code for the game Celeste - 4k+ lines just to make it feel good.
Less structure is better. When I was new to programming, I would enforce more structure than was necessary on my code. As I have come more experienced I have learn to write code with the least structure possible. The code must be flexible. Ideally you should beable to change the function with as few lines as possible. This is what makes good APIs, good data structures.
If the surface area is small, it doesn't matter how complex the code is. It doesn't matter if a single pure function is infinetly complex because it is not interacting with other code. However, lots of time is required simplifing/rewriting code unites many moving parts.
You are writing a language with the spellings of you variables/functions https://www.youtube.com/watch?v=Bf7vDBBOBUA
The programmer must structure their data to simplify the operations/transformations. How can I structure this data, so the transformations will be as simple as possible. But this requires knowing the simplist transformations of data. You really need a good understanding of transformations (i.e. thinking from a fp perspective).
unstructured data -> what transformations are needed -> structuring of data
This is why primeagen says it takes one or two rewrites to make something. In your first attempt you guess the structure of your data, and you try to work out the transformations in the editor. Once you figure out the needed transfomations, you can figure out how to simplify them, and then determine right structure of your data.
Software engineering is about knowing the footguns. Then engineering the code to be defensive about these footguns. So you can either:
- learn about the footguns the hard way
- copy patterns from other people who have already learnt the hard way