Programming and development often teaches one wisdom that cannot be attained elsewhere. Coding and programming, as some have said, is a way of life, not just job. When you are a coder, that is a big part of who you are at work and outside of work. So, let's come together, and put down our wisdom for future generations to see and learn from.
The Rules
Given that I've been getting a great number of pull requests and submissions, I wanted to write down a quick FAQ and rulebook.
Are programming wisdoms allowed? No, not really. These are supposed to be wisdoms and proverbs about life taken from programming. While a "proverb" like Use semantic class names that are easy to read and understand sounds great for a programmer, it misses the point of the repo. It can be rewritten as such Write classnames so others can understand the wisdom of your code which makes sense outside of coding as well: work and communicate in such a way so that others can understand what you mean and the wisdom behind your work.
Can I submit someone else's quotes? No. Please submit your own ideas. You're welcome to look up regular (non-programming) proverbs and translate them as I did with A deployed MVP is worth two prototyped. Use your own ideas please!
Should I include my name in the quote? You're welcome to do a - by Me tag after the quote. That will ensure that even after I restructure the readme file, you'll still get credit!
Is my quote always going to be here? Probably not but I will build out a legacy.README.md where I will store any discarded quotes.
API
For those that feel like they want to hit up an API and get a list of proverbs (or a single proverb), I crafted this neat little API. Here's how it works:
Please tweet <@antjanus> if you do use it so I can see it in action!
Proverbs
Dance like nobody is watching, code like everybody is.
A deployed MVP is worth two prototyped.
When you reach wizened engineer-level, there are at least a hundred wizened engineers above you.
A/B Test twice, deploy changes once.
Don't commit on master when drunk.
Sleep on a force push.
A git pull a day, keeps the doctor away.
Sometimes you have to cut legacy support to allow the new product to bloom.
More hours worked, more commits made. Mostly reverts and bug-causing features.
Even a wizened engineer will drop production DB.
Scope creep makes a mountain.
A hundred programmers won't make a two-year project in a week.
Facebook wasn't built in a day.
"Just ship" is no substitute for design.
Today's fashion is tomorrow's legacy.
Learning obscure and strange languages, yields better understanding and broader horizons.
The better job you do, the easier others discount the level of difficulty.
Testing is easier than debugging.
Finish a product in a day, and people will expect a new product every day. Teach people about proper development cycles, and your company will flourish.
Customers are the best testers.
Absence is beauty, in error logs.
Eternal sunshine of the stateless mind.
Laziness is your best friend. Never do twice what you can automate once.
Good test coverage + automated workflows = quiet cell phones and better sleep.
The best code is no code at all.
The best request is the one you don't make.
If a system works perfectly, no one will care what is inside it. Once it breaks, systems design and architecture decides your fate.
Leave architecture for applications that require long-term support.
Architecture and design are preparations for problems and changes, not a key to runtime.
Without a prototype, don't build a final product.
Without boilerplate, there's no speedy development.
Code frustration is a bad advisor for a refactor.
The more technology you learn, the more you realize how little you know.
An early BETA launch will teach you more than a delayed promise.
All applications are pretty when your screen is off.
Do not pick a framework for its demo page, instead pick it for its code.
You cannot set a web standard alone.
A poor programmer blames the language.
The code's writin' but ain't nobody programming.
Mañana often has the most tickets.
Never optimize before measuring
Think about your dance moves when drunk, next time you try to code with some beers on your count.
What happens in Git stays in Git
Simpler code has less bugs.
Lock up your dependency versions and other valuables.
Quantity of attempts often yields quality at the end. Commitment to refactoring legacy code yields better quality yet.
Accept that some days you're the QA and some days you're the one fixing bugs.
Give a programmer the correct code and he can do his work for a day. Teach a programmer to debug and he can do his work for a lifetime - by Chirag Gude
Debugging becomes significantly easier if you first admit that you are the problem.
Figure out your data structures, and the code will follow.
One thing should never do more than one thing.
Success from a final version is a lie, there is only iteration. Through iteration, we gain better products. Through better products, we gain traction. Through traction, we gain success. Through success, misguided tech specs are broken. The development cycle shall free us.
An open source developer does not act for personal fame.
Public code review forces one to better oneself. It forces better practices, smarter solutions, growth as a developer... or being broken.
Testing covers not testing.
The most attractive pull requests are the ones wearing a lot of red.
Coding styleguides without peer code reviews are like running a country on voluntary taxes
Deploying an unmonitored app is like going on a roadtrip without a gas gauge.
Learn a programming language, become a new developer.
Some old code never refactors, and breaks at the slightest change.
A developer will spot a peer from far away
A developer that codes until burnout, lives without a mind.
A marketer is not a QA, a developer does not advertise.
A soft spoken developer will see his warnings of technical debt unheeded, and will suffer the blame.
A well spoken developer can be hired hastily but at the last minute fail an easy test.
One can self-learn the art of code but do not assume other crafts suffer of such low bar of entry.
Find ease in your code: Code difficult to read and understand is code destined to be in troubled legacy.
Collaborating on open source projects can bring about friendship and community just as it can create factions and flame wars.
Refactor or rewrite, there is no patching unmaintainable legacy code
If you stop learning now and take the easy path, you will find yourself stuck in legacy software forever.
A beautiful product which is pleasing to non-paying users is good only for frightening investors when it runs out of funding.
A foreach loop avoided is a CPU cycle earned.
You cannot prevent managers from asking too much of you, but you can prevent them from getting used to it.
Your code might be perfect but you aren't
Any sufficiently complex app architecture is indistinguishable from spaghetti code.
Writing requirements based code and walking on water are both relatively easy to do when frozen.
It takes twice as much intelligence to debug than to program, therefore you peer review because you can never truly be smart enough to debug your own code.
Hofstadter's Law will tell you to always add more time than you think you need to a project because it will take longer, even when you take into account Hofstadter's Law.
Long lasting code is written only when you pretend that it will be peer reviewed or maintained by a violent psycopath who knows where you live.
Small bug becomes a huge problem.
Commiting is the only command I know, Commiting on you.
No one who codes before dawn 360 days a year fails to make his startup profitable
There is no test without first a failure
A line of testing is worth more than a module of code
Don't put all your logic in one method basket
As you code so shall you also deploy
Diff before you Push
When the only tool you have is Rails, everything looks like Ruby
Careful that Ignoring a PR doesn't get construed as Approval
An interview at the right price is worth two at Google
With commit and deploy access comes great responsibility
When aruging with a foolish and conceded programmer, first make sure that the other person isn't doing the exact same thing
Don't enter an architecture argument without knowing design patterns first
Anger and stubborness make bad allies in code review
Not all those that prototype and test ideas are lost.