30 pieces of advice from senior designers

Don't be too sure when it looks like true. Dig into the domain.
When something looks real, don't trust it for sure. Make great efforts to mine it.

Experience is your treasure. And it is also your burden. (The design shocould
Be based on the problem domain, not what you have done in the past .)
Experience is your wealth and burden. (The design should be conducted according to the problem domain, rather than based on what you did in the past)

It's hard to say "I was wrong", but if you don't say it, you have to pay
It.
It is very difficult to admit "I am wrong", but if I do not admit it, I will pay the price for it.

It's not your job to show how to do coding. You can do it, but you can't
Te to it.
Your job is not a demonstration of how to program. You can demonstrate it, but do not devote yourself to it.

Bugs fixing is also your responsibility, don't leave them to maintenance
Team alone.
It is also your responsibility to handle bugs. Don't leave them to the maintenance team.

You are not a problem solver. Try to eliminate problems before they surface.
(Good design can eliminate problems; you're not a firefighter)
You are not dedicated to solving the problem. Try to kill the problem before it occurs. (Good design can avoid problems; you are not a fireman)

Design is a technical thing, avoid politics in your demo-. but if it is
Stronger than you, negotiate with it to make things still work.
Design is a technical activity. Do not involve politics. If the political power is more powerful than you, compromise to make things work.

If your demo-is based on some limitations, always remember
Limitations along with your demo.
If your decision is based on some restrictions, remember these restrictions while making your decision.

If you can summarize principles from your work, write it down. Then
Sometimes you're able to know you were wrong, or you can use it as
Reminder.
If you can summarize the principles in your work, write them down. In this way, you will be able to know what you have made before, or you can use it as a memorandum.

If your programmers were waiting for your design, you're definitely dead
Man. (Human Resource driven is the sin)
If many programmers are waiting for your design (to start), you will die. (Human resource-driven is the original sin)

Don't use lame metaphors; software is neither art nor brick building.
Do not use a poor metaphor; software is neither an art nor a brick wall.

Tell users what you can provide; don't ask them what they really want.
Tell the user what you can provide; don't ask them "what you really want ".

Quality is your responsibility, don't hand it over to QA. (Design in
Robust way)
Quality is also your responsibility; do not give them to QA. (Robust design)

Don't get smart. Write it down when you feel like a genius, and attack your
Idea as dangerous enemy.
Don't be clever. When you feel like a genius makes a design, then you take your inspiration as the most dangerous enemy to attack.

Reuse is not your purpose, it's neither necessary nor sufficient to success.
"Reuse" is not your purpose. It is not a sufficient condition for "success.

A language addicit will always be a slave. Try to become a Sensai.
The language Guru will always be a slave; try to become a master.

Solutions/tools with high price guarantee nothing on productiinstances.
High-priced solutions/tools never guarantee any productivity.

Don't use "Microsoft did the same thing" to support yourself. It proves
Nothing. (Google/Facebook/Twitter/etc .)
Do not use "Microsoft has done this too" to support yourself. It does not prove anything (Google, Facebook, or Twitter)

Don't try to collect all information/requirements you need and decide later;
Welcome to the moving planet.
Don't try to collect all the information and needs you need before making a decision. Welcome to the planet of motion!

There's no universal solution; a language sometimes can be the one; and we
Need lots of ages, right?
There is no omnipotent solution; a language is sometimes a (universal solution); we need many languages, right?

Age and experience are not the right way to defend yourself in an argument.
In the debate, age and experience are not the correct way to prove yourself.

Yesterday's workaround is tomorrow's limitation.
The alternative to yesterday is tomorrow's limitation.

Good design evolves; bad design patches.
Good designs are constantly evolving, while bad designs are being patched.

Design what you're able to implement. If it's too hard to you, don't count
On others.
You can design it in a way you can. If it is difficult for you to write it, don't count on others.

Zenus didn't control everything; neither shoshould you.
Zeus does not control everything, and you are the same.

Inspect your design in each level.
Carefully examine your design at different levels

Understand the hardware; your system doesn't run in air. (hardware will
Never be perfect)
You must understand the hardware. Your system is not running out of thin air (hardware will never be perfect)

Make you design naturally and comfortable. Don't fight with programmers, and
Don't let them fight with your design.
It makes your design quite natural and comfortable. Don't fight with programmers, or let them fight against your design.

It's too late when you realize to improve performance; Design for it;
It is too late to improve performance when you realize that it is necessary to improve performance. performance is considered during design.