- KISS - Keep it simple and straightforward
- DRY - Don't repeat yourself
- WET - Write Everything Twice
- RTFM - Read the friendly manual
- FUBAR - Fouled up beyond all repair
- NMP - Not My Problem
- LGTM - Looks Good To Me
- DGAF - Doesn't Give A Farthing
- Everything should be made as simple as possible, but no simpler.
- Cursing is the only language all programmers speak fluently.
- If you make something idiot-proof, someone will just make a better idiot.
- Slow is smooth, smooth is fast
- 90% of success comes from being in the right place, at the right time, in the right uniform.
- Weeks of programming can save you hours of planning.
"Premature optimization is the root of all evil in Programming."
-- Donald Knuth
"If you need more than 3 levels of indentation, you're screwed anyway, and should fix your program."
-- Linus Torvalds, Linux kernel coding style guide, Section 1, Paragraph 3
"Don't put multiple statements on a single line unless you have something to hide"
-- Linus Torvalds, Linux kernal coding style guide, Section 1, Paragraph 6
“Experience is the name everyone gives to their mistakes.”
-– Oscar Wilde
“Any fool can write code that a computer can understand. Good programmers write code that humans can understand.”
-– Martin Fowler
"Good designers never start by trying to solve the problem given to them: they start by trying to understand what the real issues are. As a result, rather than converge upon a solution, they diverge, studying people and what they are trying to accomplish, generating idea after idea after idea."
-- Don Norman, The Design of Everyday Things, 2013 edition, pg. 218
"There are 2 hard problems in computer science: cache invalidation, naming things, and off-by-1 errors."
-- Leon Bambrick paraphrasing Phil Karlton
"Young man, in mathematics you don't understand things. You just get used to them."
-- John Von Neumann to Felix Smith
"[It]'s almost a law of the universe that solutions which are the first thing you think of, look sensible, and are easy to implement are often terrible, ineffective solutions that once implemented, will drag on civilization forever."
-- CGP Grey
"You become a better programmer by being a bad programmer."
-- Theo Browne
"Computers are good at following instructions, but not at reading your mind."
-- Donald Knuth
"What one programmer can do in one month, two programmers can do in two months."
-- Frederick Brooks
"It is the struggle itself that is most important. We must strive to be more than we are. It does not matter that we will never reach our ultimate goal. The effort yields its own rewards."
-- Lt. Cmdr. Data, Star Trek TNG, Written by René Echevarria.
"They did not realize that because of the quasi-reciprocal and circular nature of all improbability calculations, anything that was infinitely improbable was actually very likely to happen almost immediately."
-- Douglas Adams, "Life, The Universe, and Everything"
"Well, what happened? Did you not see it? Were you fucking with it? How did [some] snake get so mad, that it almost killed you?"
-- Bill Burr, "You people are all the same"
- Parkinson's Law - Work expands to fill the time available.
- Peter's Principle - In a hierarchy, every employee tends to rise to his level of incompetence.
- Ruckert's Law - There is nothing so small that it can't be blown out of proportion.
- Murphy's Law - Anything that can go wrong will go wrong.
- Brook's Law - Adding manpower to a late software project makes it later.
- Conway's Law - Any piece of software reflects the organizational structure that produced it.
- Pareto Principle - For many phenomena, 80% of consequences stem from 20% of the causes.
- Moore's Law - The number of transistors on an integrated circuit will double in about 18 months.
- Knuth's Optimization Principle -> Premature optimization is the root of all evil.
- Hanlon's Razor - Never attribute to malice that which is adequately explained by stupidity.
- Barker's proof - Some flaws will not be discovered until after publication, regardless of proofreading.
- Bike-Shedding - The time spent on any item of the agenda will be in inverse proportion to the sum (of money) involved.
-
Understand and accept that you will make mistakes.
- The point is to find them early, before they make it into production. Fortunately, except for the few of us developing rocket guidance software at JPL, mistakes are rarely fatal in our industry, so we can, and should, learn, laugh, and move on.
-
You are not your code.
- Remember that the entire point of a review is to find problems, and problems will be found. Don't take it personally when one is uncovered.
-
No matter how much "karate" you know, someone else will always know more.
- Such an individual can teach you some new moves if you ask. Seek and accept input from others, especially when you think it's not needed.
-
Don't rewrite code without consultation.
- There's a fine line between "fixing code" and "rewriting code." Know the difference, and pursue stylistic changes within the framework of a code review, not as a lone enforcer.
-
Treat people who know less than you with respect, deference, and patience.
- Nontechnical people who deal with developers on a regular basis almost universally hold the opinion that we are prima donnas at best and crybabies at worst. Don't reinforce this stereotype with anger and impatience.
-
The only constant in the world is change.
- Be open to it and accept it with a smile. Look at each change to your requirements, platform, or tool as a new challenge, not as some serious inconvenience to be fought.
-
The only true authority stems from knowledge, not from position.
- Knowledge engenders authority, and authority engenders respect – so if you want respect in an egoless environment, cultivate knowledge.
-
Fight for what you believe, but gracefully accept defeat.
- Understand that sometimes your ideas will be overruled. Even if you do turn out to be right, don't take revenge or say, "I told you so" more than a few times at most, and don't make your dearly departed idea a martyr or rallying cry.
-
Don't be "the guy in the room."
- Don't be the guy coding in the dark office emerging only to buy cola. The guy in the room is out of touch, out of sight, and out of control and has no place in an open, collaborative environment.
-
Critique code instead of people
- In short, be kind to the coder, not to the code. As much as possible, make all of your comments positive and oriented to improving the code. Relate comments to local standards, program specs, increased performance, etc.
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
-
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
-
Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
-
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
-
Business people and developers must work together daily throughout the project.
-
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
-
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
-
Working software is the primary measure of progress.
-
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
-
Continuous attention to technical excellence and good design enhances agility.
-
Simplicity--the art of maximizing the amount of work not done--is essential.
-
The best architectures, requirements, and designs emerge from self-organizing teams.
-
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
-
Work always flows in one direction: downstream.
- Work should only flow in one direction. No known defect should be passed downstream. Always seek to increase the flow.
-
Create, shorten and amplify feedback loops.
- Establish an upstream feedback loop. Shorten the feedback loop. Amplify the feedback loop.
-
Continued experimentation, in order to learn from mistakes, and achieve mastery.
- Promote experimentation. Learn from success and failure. Constant improvement. Seek to achieve mastery through practice.
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent