10 questions programmers should ask themselves repeatedly when writing code

[[121299]]

Do you want to be a good programmer?

Well, now is the time to put down the super cheat book "Learn xxx Language v8.3 in 24 Hours" and instead, you should develop the habit of asking yourself the following 10 questions every day.

1. Is there a pattern in your code?

Looking for patterns of what works and what doesn't will reveal seemingly unrelated ideas or underlying principles. To gain a deep understanding of your work, you must develop the habit of asking yourself, "Is there a pattern?"

It doesn't just apply to your code. Is there a pattern for adapting to different types of business changes? Is there a pattern for technology evolution? Are you seeing the same types of bugs popping up?

To understand is to understand patterns - Isaiah Berlin

2. How to make the code simpler?

Developers often want complex and scalable solutions. Build something extremely complex and feel like you are the master of your own universe. The problem is that you can never predict how your product and business will change in the future.

"Architecture" and code are more like gardening than architecture. You have to be able to adapt to changing circumstances. The more complex the solution, the harder it is to do.

Simplicity is the ultimate sophistication - Leonardo da Vinci

3. Do you know why the program runs this way?

Knowing that something works the way it does and knowing why it works the way it does are two completely different things. If you know why things work the way they do, you can make better decisions.

The difference between a great programmer and someone who knows a programming language is the depth of understanding of why.

The same principle applies to problem fixing. "Restart the service." "Have you tried restarting?" We often think of these words when a problem occurs. Every time you say this, you lose a golden opportunity to learn.

Understanding why such an error occurred will help you correct the root cause and avoid treating the symptoms instead of the root cause. At the very least, you won't make the same mistake again in the future.

4. Has anyone written code like this before?

Whenever you find yourself inventing a complex algorithm, you are probably on the wrong track. Unless you search for a PhD thesis where someone else solved the problem.

Need to write an algorithm that adds a label to the item next to the user's mouse? Look at VoronoiTesselations. Want to find the shortest path for a truck to deliver a package? Look at Dijkstra. Want to find the closest label to something the user inputs? Find its Levenschtein distance.

These are just a few simple examples, trust me, they are everywhere.

I can see further because I stand on the shoulders of giants - Isaac Newton

5.Do you know where this technology comes from?

Do you think you know REST?

Have you read the original paper by Roy Fielding describing REST? Do you really understand its original purpose? A blog written by someone who spent 5 minutes longer than you using the REST API generation wizard in IDE v7 does not count.

Do yourself a favor and try to read the original documents of the concept or principle, and then learn the latest developments in the industry through various means. If you don't know where they started, just follow their pace? (If you don't know where they came from, follow them to where they are going!)

6. Do I like what I am doing now?

Face it, programming is hard.

Besides being difficult, programming is also developing very fast. Art framework has developed from a "clunky dinosaur" 2 years ago to today's standard. In order to stand at the top of your "game", you must establish a belief in lifelong learning and research.

If you don't love what you do, then you have no chance of keeping up with the other guys (who love what they do). So find the type of programming that makes you passionate! Don't decide to become a security expert because there is a gap in the market or the salary is good, and don't decide to become a UX expert because an article said UX is the hottest career.

Again, do what you like.

Do what you love and the resources will come — Peter McWilliams

7. Can these codes be used in other places?

One of the biggest limitations I see in programmers is their own failed imagination.

If we learn something that works in a specific context, or see a technique that solves a specific problem, we assume that's the only place it applies. This is completely wrong. Whenever you learn something new, ask yourself, "Can I use it elsewhere?"

When you discover a great new way to locate nodes on a graph, can you apply it to locating interesting data in a 2D dataset? When you discover a new way to send data from a client to a server via websockets, how can you apply it to a scalable backend service? Sometimes it’s wrong, but sometimes it’s right.

Which brings us to our next question…

Logic can only take you from A to Z, imagination can take you everywhere - Albert Einstein

8.Did you do anything wrong today?

The easiest way to increase revenue generation is to reduce losses from errors.

Game developer Valve and a few other companies believe this. The same applies to your progress as a web developer. If you are afraid of failure, you won't have big breakthroughs.

Be brave, try, fail, learn and try again.

Don't be afraid of mistakes; they allow you to learn from your failures and start over. - Benjamin Franklin

9.Is there really no way?

We live in a very small part of the world where that is not possible (with a few exceptions).

Assume that whatever you are doing is possible, and then work backwards. You may find that what you want to do is impractical at the moment, but it is enough to change the world and may become a reality faster than you think.

Nothing seems possible until you achieve it - Nelson Mandela

10.Who can I learn from?

Never work in a place where you are the smartest person among a group of people.

Choose jobs and companies with colleagues who inspire you and motivate you to do more. Don't get involved with programming, there is a whole world outside of text editors and command lines. Learn from other fields and try to apply them to your work.

Never be satisfied with just being able to do the job you have!

Link to this article: http://www.cocoachina.com/programmer/20141019/9963.html