I was recently asked for my insights on being a great programmer. This is an interesting question, I think we can all be great programmers, no matter our talents, if we follow some rules - I believe - it should be common sense. In fact, these rules apply not only to the field of programming, but also to any profession.
Of course, not everything in these 10 points is completely serious, some things are just my opinion and your situation may be different, so don't take it to heart if there is a contradiction.
These points are:
1learn how to ask questions
There are basically these types of programmers asking questions:
Perfectionists: Especially when asking questions about some open source tools, they may have debugged through the code and found the real cause of the problem.
But even if no real cause is found, a perfectionist will explain the problem, reproduce steps, suggest possible workarounds, or even suggest possible fixes. In fact, perfectionists have no problem. There are only answers.
Chatterbox: The person didn't actually ask the question. They state their minds, sometimes placing pompous question marks all over the place. For questions, they give their thought process, and if you wait for the answer, they either find the answer themselves, or they ask the real question after multiple emails.
Oh right, I found this requirement to be completely wrong, I solved it with some other techniques. Actually, I completely changed the library. "Hehe. Just hope they don't ask questions anymore.
Idiot: The code is here. I don't know where is wrong? please help me.
Manager: For this type of person, time is money. Questions must be short, and the quicker the answer, the better. Ironically, by keeping the question short (meaning: incomplete, not concise), most of the time, a lot of important details are lost, and then the programmer can only ask for more details in order to answer the question.
So the manager (who is naturally disappointed because he got not an answer but a new question) sends a short message again and asks for an answer more urgently. cycle back and forth. In the end it may take 1-2 weeks to answer.
Complainer: This type of person doesn't ask questions. They kept complaining until the problem went away. If things don't get better, there's even more reason to complain.
It should be clear by now that a well-prepared question (brief, simple, short, but with enough detail) will yield a better answer. If you know exactly what you need to learn about the subject, you're more likely to get what you want.
2Learn how not to ask questions
In fact, it's best to avoid asking questions as much as possible. Maybe you can figure it out yourself? Of course this is not always the case. There are many things you simply don't know, and asking domain experts can help you find the quickest and most efficient path to success. However, there are many benefits to frequently trying to solve problems yourself:
What we learn this hard way is better kept in memory - we will remember what we learned. It's more valuable to find the answers yourself.
You don't make "noise". Remember the "chat box" I mentioned earlier? Unless the person you're asking is responsible for answering the question (thus delaying their work), they may try to answer every incomplete "question" without understanding your thought process. This doesn't help anyone.
By deferring asking questions (at least for a while), you can gather more relevant information, which you can then provide to someone who might be able to answer the question. Think of "perfectionists" who spend more time looking for details first and then answering the questions themselves.
With training you can become better at asking questions. It takes time.
3Don't leave broken windows
There was a very interesting article recently about not leaving broken windows. The essence of the article is to never compromise on quality. Never be a deserter. Never leave behind...broken windows. The following quote is from this article:
"Reflecting our careless code when we take some shortcuts to deliver something in the shortest amount of time can lead developers after us (from the same team, future teams, even ourselves!) to draw an important Conclusion: It's not important to pay enough attention to the code we produce. It will be an unstoppable process that the application gradually starts to deteriorate."
Actually, this does not mean to be a perfectionist. Sometimes, repairing broken windows can be put off. Usually, however, no one is happy about allowing windows to be broken and to remain broken. We programmers are not happy, our customers are not happy, our users are not happy, and our project managers are not happy. It is an attitude that is at the heart of being a professional. What does Benjamin Franklin think?
"After the sweetness of the low price is forgotten, the bitterness of the low quality will linger long."
Everything is so. "Low price" is our quick win for implementing something in a sloppy way.
4Software should be deterministic
That's what to aim for!
In an idealized world, everything in software should be "deterministic". We should all be functional programmers, writing pure functions with no side effects. Such as String.contains(). No matter how many times you do the following:
The result is always the same, all expected. Even a cosmic explosion would have no effect on this calculation. This is deterministic.
We can also do this in our own programs, not just in the standard library. We can try to write as many deterministic modules as possible without side effects. It really doesn't matter what technology we choose. Deterministic programming can be done in any language - even functional languages have more tools to prevent unintended side effects through a more sophisticated type system.
But the example I show is a Java example. Object orientation allows for determinism. Yes, programming languages like PL/SQL allow determinism. If you want to use a function in an index, you need to request a deterministic function:
This is again a question of rules. Procedures/methods/"functions" with side effects are "broken windows". Having side effects might be easier to maintain, and of course hopefully eliminating side effects eventually. But it's usually a lie to yourself. When one day in the future unexpectedly pops up, that's when you pay dearly. Don't believe it, say Cao Cao and Cao Cao will arrive.
5accept the unexpected
Programmers should always obey Murphy's Law. Everything can be broken. And it's about to be broken. As software engineers, we should remember that it breaks. Because our world is uncertain, so are the business needs we are implementing. We can only implement technique #4 (determinism) when we can finally be sure.
否则，我们将不可避免地进入不确定论的世界（也就是“现实世界”），即一个将会出错的世界。所以，要以此为基础。接受意料之外的事情。训练你内心的洪荒之力，从积极的角度预见各种麻烦。
当然，如何以简洁的方式写代码来预见各种麻烦就是另一个故事了。如何从那些可能会失败的东西（因此不需要处理）中辨别那些将会失败的东西（因此需要处理），还是需要通过一些实践滴。
6不要货物崇拜
不要教条主义。始终具体情况具体对待。
所有教给你的内容都存在潜在的错误。即使是那些流行语。引用一句很不错的话：
“我的职业生涯至少有50％是为了帮助或解脱由教条主义引发的一个个灾难。
我们的职业充满了虚假。我们喜欢把自己当作数学家，坚持最纯粹的思想，认为它们一定是正确的。
那是一条歧路。我们的职业构建在数学的基础之上，但除非你进入范畴论或关系代数的时髦世界（即便你真的进入，我也怀疑一切是否是“正确的”），否则你就得面对现实世界务实的业务需求。好吧，坦率地说，这离完美还有十万八千里。让我们来看看一些最流行的编程语言：
C
Java
SQL
你真的觉得这些语言一点都不像数学吗？行，不如我们先来讨论段错误，Java泛型和SQL三值逻辑。这些语言是由实用主义者建立的平台。所有这些都有一些非常酷的理论背景，但最终，还是有了这些工具。
对于建立在语言之上的所有东西也是如此：库，框架，设计模式，甚至架构。没有什么是对的或是错的。一切都是为某些上下文设计的工具。想想在其上下文中的工具。永远不要把这个工具当成一个独立的理由。我们不是“为艺术而艺术”。
所以对这些质疑说不：
XML
JSON
功能编程
面向对象编程
设计模式
微服务
三层架构
DDD
TDD
实际上：*DD
不胜枚举
所有这些都是某些给定上下文的好工具，但并不总是如此，要学会具体情况具体对待。保持好奇心，开发创造力，知道何时才需要使用这些工具，将有助于你成为一个更优秀的程序员。
7就是干
这是真理。话说，总有一些牛人出类拔萃，能够傲视群雄，让人鞭长莫及。
但大多数程序员只达到“好”的级别，或是有潜力达到“好”的程度。那么怎么才能成为一名好的程序员呢？正如罗马不是一天建成的，伟大的软件也不是一天可以写成的，受欢迎的人并非我们这个时代唯一的英雄。我遇到过许多默默无闻但伟大的程序员，他们孜孜不倦地攻克软件难题，解决了许多小公司隐蔽的问题。
伟大的程序员都有一个共同点：遇到问题就是干。练习，实践。每天都致力于工作与学习，然后变得越来越优秀。
想要更擅长SQL？那就干吧！每天都尝试用一些新功能编写一个SQL语句。使用window functions。分组。递归。分区的外连接。MODEL和/或MATCH_RECOGNIZE子句。不需要每次都交付生产，就是为了实践。这些都是有价值的。
8专注一个主题（从长远的角度）
可能只有很少一部分“优秀的”全栈开发人员独领风骚。事实上，大多数全栈开发人员都将位于中间水平。当然，一个小团队可能只需要几个全栈开发人员，就可以涵盖很多业务逻辑，快速推出一个新的软件。
但是，软件将非常笨拙，“马马虎虎能工作”。也许这对于只要可行即可的产品阶段来说就已足够，但从长远来看，会导致全栈开发人员将没有时间来正确分析（或预见！）更复杂的问题。
主要专注一个主题，并真正擅长这个方面。真金不怕火来炼，只要你有本事，那么走到哪里都需要。所以，致力于你的职业生涯，做一些真正好的东西，而不是“差不多就行”。
9涉猎广泛
虽然你应该主要关注一个主题，但不应该完全遗忘其他方面。你永远不能马上真正擅长SQL、扩大、扩展、低级性能、CSS、面向对象、需求工程、架构等等的所有内容（见技巧#8）。这是不可能的。
但你至少应该明白它们每一个的本质。你需要明白何时SQL是正确选择（以及何时不是）。何时低级别性能的调整很重要（何时不是）。CSS原则上如何工作。面向对象、FP优点。等等。
你应该花一些时间涉猎这些（以及更多）概念和技术，以便更好地了解它们的重要性。知道何时应用它们，然后再找专业人士来实际执行工作。
Ditching new paradigms and technologies helps you think in a completely different way, and you may unconsciously use them in some way or another in your day-to-day work.
10keep it simple, for dummies
Einstein once said:
"Everything should be made as simple as possible, but no simpler."
("Everything should be made as simple as possible, but no simpler.")
No one can handle enormous complexity. Not in software, not in any other aspect of life. Complexity is the killer of good software, so simplicity is the enabler. Easy to understand. difficult to achieve. You need a lot of time and practice to identify and produce simplicity. Of course, there are many rules you can follow to achieve simplicity.
One of the simplest rules is to use methods/functions with only a few parameters. Let's take a look. The String.contains() method mentioned earlier does just that. We can write "abcde".contains("bcd") and without reading any documentation, everyone immediately understands what this does and why. The method does one thing, and only this one. No complicated context/settings/other parameters passed to the method. There are no "special cases" and no warnings.
Also, it's much simpler to simplify in the library than in the business logic. So can we make it happen? Maybe. through practice. by refactoring. But like great software, simplicity doesn't happen in a day.
(Advanced tip: Apply Conway's Law. It's completely impossible to write good and simple software in an environment where a business is super complex. Either you choose complexity and ugliness, or you better get rid of that business).