We’re putting together written content to supplement our usual software training for 2020. Throughout, there will be some interspersed inspirational quotes and ideas to inform, guide, enlighten, and entertain the budding software developers.
What’s your favorite pearl of wisdom related to writing software?
There are only two hard problems in computer science: cache invalidation, naming things, and off-by-one errors.
I also highly recommend Akin’s Laws of Spacecraft Design. They’re aerospace-oriented, but many of them are extremely relevant to software development.
Programs must be written for people to read, and only incidentally for machines to execute.
Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.
Walking on water and developing software from a specification are easy if both are frozen.
Computers make very fast, very accurate, mistakes.
The computer programmer is a creator of universes for which he alone is the lawgiver. No playwright, no stage director, no emperor, however powerful, has ever exercised such absolute authority to arrange a stage or field of battle and to command such unswervingly dutiful actors or troops.
It’s a curious thing about our industry: not only do we not learn from our mistakes, but we also don’t learn from our successes.
Good design adds value faster than it adds cost.
Programming is the art of breaking down a process to the point that a lightning infused rock can perform it.
There is nothing quite so permanent as a quick fix.
To me programming is more than an important practical art. It is also a gigantic undertaking in the foundations of knowledge.
One accurate measurement is worth a thousand expert opinions.
You manage things, you lead people. We went overboard on management and forgot about leadership.
A good programmer looks both ways before crossing a one-way street.
First, solve the problem. Then, write the code.
Experience is the name everyone gives to their mistakes.
Every piece of software written today is likely going to infringe on someone else’s patent.
Computers do not solve problems, they execute solutions.
I love deadlines. I like the whooshing sound they make as they fly by.
The future is here. It is just not evenly distributed yet.
Adding manpower to a late software project makes it later!
Only half of programming is coding. The other 90% is debugging.
The nice thing about standards is that there are so many to choose from.
A computer will do exactly as it is told, nothing more, and nothing less.
Insanity: doing the same thing over and over again and expecting different results.
If you can´t explain it simply, you don´t understand it well enough.
In design, complexity is toxic.
You’re bound to be unhappy if you optimize everything.
Simplicity is prerequisite for reliability.
Code never lies, comments sometimes do.
I’ll also be sure to offer the opportunity to my co-workers. Though, knowing my Team Lead, I’ll surely have to filter any responses for “appropriateness”.
You can pretty much find one of these every other page in The Mythical Man-Month - Wikipedia .
IMHO it’s one of the best programing resources I was exposed to in College.
When you have a bug in your code that you see the first time you try to run it, you will be able to fix it in no time at all, because all the code is still fresh in your mind.
If you find a bug in some code that you wrote a few days ago, it will take you a while to hunt it down, but when you reread the code you wrote, you’ll remember everything and you’ll be able to fix the bug in a reasonable amount of time.
But if you find a bug in code that you wrote a few months ago, you’ll probably have forgotten a lot of things about that code, and it’s much harder to fix. By that time you may be fixing somebody else’s code, and they may be in Aruba on vacation, in which case, fixing the bug is like science: you have to be slow, methodical, and meticulous, and you can’t be sure how long it will take to discover the cure.
-Joel Spolsky
Top notch development teams don’t torture their programmers. Even minor frustrations caused by using underpowered tools add up, making programmers grumpy and unhappy. And a grumpy programmer is an unproductive programmer.
To add to all this… programmers are easily bribed by giving them the coolest, latest stuff. This is a far cheaper way to get them to work for you than actually paying competitive salaries!
-Joel Spolsky
“640K is more memory than anyone will ever need on a computer” - Bill Gates
Less of a quote and more of a saying:
Read the entire error message before doing anything.
I’d give a spin through one of my favorite Twitter accounts:
I disagree. Reading the story in it’s entirety leaves no room for adventure.
D
If you try to make it idiot-proof, someone will come up with a better class of idiot.
Ha, all extremely excellent so far!
I’ll share the two that hang at my desk:
“Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.”
“Programs are meant to be read by humans and only incidentally for computers to execute.”
This applies to a lot more disciplines than software:
I think a lot of the Go Proverbs can be applied to programming in general.
Along similar lines, The Zen of Python is pretty good too.
When I write code, I tend to use longer, more verbose variable names that describe exactly what is going on
I also like to use tons of comments for anything thats less than obvious
I also comment the flow of the program/class
I need to follow my own advice more for our FRC code
FRC-specific first line of defense debugging:
“Did you save it?”
“Did you compile it?”
“Did you deploy it?”
So many “errors” that were actually just the robot not having the new code >.<
Advice I give to FRC teams a lot is:
“Keep simple things simple; don’t make complex things unnecessarily complex.” - Bjarne Stroustrup, https://www.youtube.com/watch?v=nesCaocNjtQ
I paraphrase it as “don’t overcomplicate it”. The vast majority of teams can get a moving robot with feedback control in like 20 lines of code. FRC teams like to write over-abstracted fluff when it’s really unnecessary.
Also, don’t reinvent the wheel. Chances are there’s a library component that does what you need, and it’s better written and tested than what you’d write yourself. Forgoing it for learning is fine, but don’t sacrifice a successful robot for that reason.