Practice, practice, practice
Software engineering is an incredibly complex subject. This is not like history, where one can simply memorize and recall. This is not like chemistry or physics, where one follows a set pattern of steps to solve problems with known variables. Software engineering is like learning what a hammer is on day one, learning what a saw is on day two, being shown how to use a hammer and a saw on day three, and on the forth day you are given some wood and a prompt that reads: “Build a House, Time Limit: 45 minutes”.
One is not only learning to recall. Software engineering is learning from start to finish: what is this tool, how can it be used, how should it be used, and then figuring out the skill of recalling that tool at the exact time that one should use it to help one solve a problem efficiently.
How is it possible to get from here (where you know nothing) to there (where you can build a house)? One common trait among all people who have done so is practice.
There is no easy way around it. There are no short cuts. “Practice, practice, practice” is the advise given to every young person learning to program. Everyday one must practice writing code, practice using the tools in their tool chest, and acquire new tools to practice with.
Only by these hours upon hours of beating on the craft will one be able to see a protruding nail and skip the mental step of thinking about what a hammer does and how to use it, and instead simply reach behind them to fetch the hammer and swing while instead mostly thinking about how this piece fits into the structure of the house.
Making that leap for any new tool in one’s programming tool chest is what anyone learning software engineering is after, and practice is the only way to get there. Therefore, to practice as often and purposefully as possible should be the goal.
The stress and enduring nature of that may be a negative side effect, but the alternative may be that one is never able to fully acquire a new programming skill or never be able to use it effectively and efficiently.
Software engineering in general has made leaps and bounds towards making it easier to learn and understand.
The advent of new programming languages or updates to previous languages continuously add new features that make programming code easier to read and write as a human. After all, we came all the way from literal 1s and 0s to languages like Python. Although in some instances, specificity and self-explanation in the code may be lacking, once a better understanding is in place, the language itself is easier to read.
I think Javascript is a great example of this. Prior to exposure to Javascript, I had primarily programmed only in Java. Whereas the language used in Java reads a lot more like computer code and requires compilation, Javascript is arguably more straightforward in the human brain.
Software engineers now and in the future would likely have more success writing code in languages that favor English and the way we are taught to read and write, rather than computer code. I believe this simply because this allows for real people to spend less time translating in their brains and instead spend that mental capacity on actually solving the logic behind a problem.
Continuing from my previous analogy, instead of spending so much time and energy using a handsaw, we can invent new tools like a circular saw that frees our mind to consider the bigger picture more often and completely.