Dedicated to all those producers around the world that still fight every day to make something extraordinary. The patriots who shape their own countries; the builders who sacrifice for their families. Learn what you can. Apply what you learn and shape your own future.
"This morning my universe blew up thanks to a simple display bug from a new experimental feature I added yesterday. So today I gathered the pieces, put them back together, adjusted the problem code segment and restarted time." -- Anthony J. Mountjoy
Learn how to write and compile computer programs quicker. For the serious student of the digital(soon to be quantum) arcana.
Basic differences in approach will significantly inform the outcome. Without adding this idea to the specific list below, let me just say that the first mistake almost everyone makes; not just programmers. Is in forgetting that programming like production generally is rooted in principles, it's governed by rules that produce, and this is key: Predictable Results.
Top Ten Obscure Mistakes That Kill Profit By Reducing Predictability
10. Compiling programs with source code you can't read and change. The essence of the problem that open source attempts to solve...with some success.
9. Chasing elegance instead of simplicity. Languages can seductively offer "short cuts" that are best avoided in all but the most specific circumstances.
8. Conflating the concept of a function with that of a procedure. Would you consider tactics the same as strategy? I hope not.
7. Relying on compiler specific optimizations to improve performance. This type of thing just encourages laziness and all that comes from it when applied to anything.
6. Outsourcing procedures to a third party library. The key word is 'outsource'. Writing your own libraries no matter how redundant that may seem is always encouraged, especially if those libraries are full of procedural strategies. To maintain control of a program's essence one must keep the functions closer to the seed.
5. Mistaking served content for database access. Latency matters and if you don't understand that then you don't understand real time applications.
4. Thinking techniques that work small scale can work just as well large scale. Learn what an engine is and why they are important...as a technique, not as a platform.
3. Abdicating responsibility for data usually through automatic memory management and/or virtual machines. Indicative of an insecurity in ones own understanding of information representation and likely algebra. If all you intend to do is package TV dinners, then don't call yourself a chef.
2. Abstracting program architecture with language based frameworks like Object Oriented Programming. The less detail one is aware of, the less influence one has with any observed phenomenon. What good is a helmet if it blinds? Avoiding an injury to instead suffer a fatal wound.
1. Depending on a debugger to find problems in the code. Use code logic and I/O to ensure that every aspect of a program is stable step by step. Your mind should be the only debugger you ever need. If one allows the language to influence the logic inappropriately, then one is inclined to allow a framework like OOP to do the same, and then a database like SQL and then an IDE like VS to settle the argument entirely.
How much code have you written? Spare me, how much of your mind is actually in the code. Without compromising, I've paid my bills with programming skills for 20 years and still going strong. Think you can do better? Prove it.