A poor programmer blames the language. – Programming Proverbs
I’ve been a polyglot developer (works in many languages) for a number of years now but a few years ago when I was first learning Ruby I use to hate it, not because there was anything worth hating but because it removed many of the misconceptions I had about programming languages in a way that forced me to forget what I had learned and relearn from scratch. Three to four years later I almost exclusively code in Ruby and don’t want to use anything else. When you hear someone complaining about a language, or a library or anything for that matter, step back and look at their situation. It’s not to say that there aren’t languages that suck, but we humans tend to focus our own inadequacies at what we don’t yet understand and you’ll see this a lot in software development.
Never optimize before measuring – Programming Proverbs
It’s a pretty common misconception that you have to have all of your ducks in a row architecture wise before you start a software project, in most cases though you don’t need to be using the largest servers with the best load balancing in the most expensive cloud service provider. In fact as long as you can point users to your app and let a hand full start using it, architecture can come later and it tends to bog down developers at the beginning instead of allowing them to focus on the business logic that they are trying to create. I’ve been guilty of doing this as well and have seen the good and ugly side of future proofing.
Mañana often has the most tickets. – Programming Proverbs
The programmer’s version of don’t put off for tomorrow what you can do today, in reality what this really comes down to is explaining that if you put off building your tests or answering tickets that you’ve already researched for tomorrow, it is likely that new issues will arise that will require your attention and you’ll end up in a perpetual loop of technical debt that you can’t get out of.
An early BETA launch will teach you more than a delayed promise. – Programming Proverbs
I’ve also heard this said a different way, “If a picture is worth a thousand words, than a working prototype is worth a thousand meetings” but in the truest sense having something that works (even if it doesn’t) is better than to continue to promise something that works but that no one can see for themselves. In development we tend to be perfectionists sometimes and that can bite us if we don’t have anything significant to show for it.
The code’s writin’ but ain’t nobody programming. – Programming Proverbs
Sometimes in Software Development we tend to be so focused on the minute details that we loose sight of the big picture, having a healthy perspective about the direction of not just a piece of code but of the entire application will be the difference between simply being a code monkey who hacks at stuff and a software engineer who really builds something.
What happens in Git stays in Git – Programming Proverbs
No this is not to say that if you make a bad git commit that you’re stuck with it, we all know we can revert git commits when necessary. This is to let us know though that little things can linger and stick around if you accidentally commit and push things that shouldn’t be pushed. A perfect example that I’ve been guilty of in the past is debug code, be careful what you git commit and or git push and remember that even reverts leave a historical footprint.
Simpler code has less bugs. – Programming Proverbs
It’s just basic math, the less lines of code you write, the less chance there is that any of those lines will produce a bug that you’ll need to catch. Keeping your code base small allows you to have less lines of code to read through and debug when a problem arises.
Lock up your dependency versions and other valuables. – Programming Proverbs
One of the most important things about programming is version control, that applies to more than just your code though. You need to handle your libraries and upgrades with caution and do them slowly and methodically to ensure that you first don’t break something that there is no test coverage for but second don’t end up releasing code into production that simply doesn’t work.
Figure out your data structures, and the code will follow. – Programming Proverbs
The most important thing you need to do before building out a new module or class is making sure that you’ve mapped what it’s going to do and how data is going to get stored before moving forward, when a refactor down the line requires you to change or move where or how data is stored in a hash for example, you risk messing up things at a production level if the application has already been deployed and other sources depend on that data.