Consider this a primer on programming by a non-programmer. Why would you heed the advice of self-described non-programmer? Easy – I’m less enchanted with technology than most fanboys. So here are a few precursors you should consider before you jump in to programming.
Lesson 1: Languages are like underwear; lots of sizes and colors, one distinct purpose. No matter what the fanboys throw at you in terms of benchmarks, frameworks and syntax, it all comes down to preferences. But if you’re paying for courses, you might as well learn one that is being used widely to some degree. It makes finding an actual job somewhat easier.
Lesson 2: Sometimes these preferences are dictated by the person paying your paycheck. Other times you can go it alone and inject your own preferences into the project. Either way, if you accept Lesson #1, you should be able to program in any language with some success. If you can’t get your mind around a concept of a language you don’t “know”, it is probably because you don’t understand your preferred language either. The only exception, for example, is if you were using a procedural language and then jumped in to the object-oriented pool. Then you have new concepts to learn. But it shouldn’t be completely foreign territory.
Lesson 3: Frameworks are designed to make you more productive (or lazier) by doing some things that are often repetitive. A framework will not do you any favors if you skip Lesson #2 and don’t know the language.
Lesson 4: Computer science is often taught in the finite space of mathematics. But the real secret is that you should know an equal amount of statistics. The business world, where you will most likely derive a paycheck, is based in the world of probability. If you can’t wrap your head around the idea of uncertainty and variance, you’ll be JACP (just another commodity programmer) . Standard deviation must be understood.
Lesson 5: “Less is more” – Ludwig Mies van der Rohe: This doesn’t mean doing the least amount possible and getting away with it. Less is more so long as the end result provides more value than doing more and producing less. No one cares how big your app is or whether it has the words “enterprise” stamped on it. If it is a piece of shit, it only means you have a bigger pile of shit to clean up. Take a small app that is a piece of shit and you can easily turn it into something much better, much faster.
Lesson 6: A programmatic solution to a project you are developing is often *not* the solution to the project. Users often don’t care about a granular process or methodology or programming best-practices. Even if it makes sense to you, it probably doesn’t make sense to non-programmers.
Lesson 7: Don’t foist new technology on unsuspecting victims. You’ll end up regretting it when you have to integrate third-party tools, libraries and applications and they’ll hate you far less when you have to tell them the reality of the integration process.
Lesson 8: The user interface must meet the needs of your end user – not what you think they need. People are often wow’ed by the most devilishly simple, attractive interfaces. But slap on an ugly interface and have hundreds of thousands of options, features, tools and utilities and your end user will be lost. Take a hint and load an older copy of Microsoft Word and see what I mean.
Lesson 9: The only thing that makes you a better programmer is being better than most other programmers. Thus, if you wish to avoid having your job outsourced to another country, be better than most. Even if you do lose your job, your talents are easily applied elsewhere.
Lesson 10: You are not god. Don’t act like it. Or if you are just that good, don’t tell me you can’t do something or something is impossible. Like I’ve told a girlfriend or two when they start mouthing off: You can be replaced… especially if you are JACP.
