Want to be a good programmer?

Well, it’s time to put aside 24 hours to learn XXX, and ten years of coding tells you that good programmers should make a habit of asking themselves these eight questions every day.

Is there a pattern in your code?

Looking for what works and what doesn’t in a pattern will reveal seemingly unrelated ideas or fundamental principles. To gain a deep understanding of your work, you must develop the habit of asking yourself, “Is there a pattern?” The habit of.

It doesn’t just apply to your code. Is there a model to adapt to various types of business change? Is there a model for technological development? Do you see the same type of mistakes springing up?

How can I make the code simpler?

Developers often want complex and extensible solutions. Making something so complicated that you feel like you’re the master of your own universe. The problem is that you never know how products and businesses will change in the future.

“Architecture” and code are more like gardening than architecture. You must be able to adapt to changing circumstances. The more complex the solution, the harder it is to make.

Do you know why the program works the way it does?

Knowing that something works that way and knowing why it works that way are two very different things. If you know why things are the way they are, you’ll be able to make better decisions.

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

The same principle applies to problem fixing.

“Restart the service.”

“Have you tried rebooting?”

We often think of these words when a problem arises. Every time you say that, you miss a golden opportunity to learn.

Understanding why such errors occur will correct the root causes and avoid the symptoms. At the very least, don’t make the same mistake again.

Has anyone written code like this before?

Whenever you find yourself inventing a complex algorithm, you’re probably on the wrong track. Unless you search for a PhD thesis that someone else has just solved.

Need to write an algorithm that adds labels to items next to the user’s mouse? Look at the Voronoi

Want to find the shortest route to a truck delivery? Take a look at Dijkstra. Want to find the closest tag for user input? It should be the Levenschtein distance to find it.

These are just a few simple examples, and believe me, they’re everywhere.

Do you know where this technology comes from?

Do you think you know REST?

Have you read Roy Fielding’s original paper describing REST? Do you really understand its original purpose? A blog written by a guy who uses 5 minutes more of the REST API generation wizard in the IDE V7 tool than you do doesn’t count.

Do yourself a favor and try to read the original documentation of the concept or rationale, and then stay up to date with industry leaders by any means. If you don’t know where they started, follow their lead. (Follow them wherever they come from, if you don’t know where they come from.)

Do I like what I’m doing?

Face it, programming is hard.

In addition to being hard, programming is moving fast. The Art framework has evolved from “clunky dinosaur” two years ago to today’s standard. To stay at the top of your game, you must establish a commitment to lifelong learning and research.

If you don’t like what you do, you have no chance of keeping up with the other guys. So find the type of programming that burns your passion! Don’t decide to become a security specialist because there’s a gap in the market, or because you make a lot of money. Don’t decide to become a UX specialist because an article says UX is the hottest job.

Again, do what you love.

Do what you like, and the resources will follow — Peter McWilliams

Can this code be used elsewhere?

One of the greatest limitations of a programmer is his own failed imagination.

If we learn something that works in a particular context, or see a technique that solves a particular problem, we think that’s the only place it works. This is completely wrong. Whenever you learn something new, ask yourself, “Can I use it elsewhere?”

When a great new way of locating nodes on a graph is discovered, can it be applied to locating data of interest in a two-dimensional data set?

When you discover a new way to send data from client to server over WebSockets, how does it apply to extensible backend services? Sometimes it’s wrong, but sometimes it’s right.

Which brings us to our next question…

Is there really no way?

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

Assume that whatever you do is possible, and then push back in the backward direction. You may find that what you want to do is impractical for the time being, but it is enough to change the world and may become a reality sooner than you thought.

The process of recruitment, tens of millions of programmers to find a new choice! This article was written by De Cheng.