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."
其实，这并非意味着要成为一个完美主义者。有时，修复破碎的窗户是可以推迟的。但是，通常情况下，对于允许窗户被打破和保持打破状态，没有人会觉得开心。我们程序员不开心，我们的客户不开心，我们的用户不开心，我们的项目经理也不开心。这是一种态度，是作为专业人士的核心内容。Benjamin Franklin怎么看呢？
“低价格的甜蜜被遗忘之后，低质量的苦涩将回味悠长。”
一切都是如此。“低价”是我们用一种草率的方式来实现某些东西而获得的快速胜利。
4软件应该是确定性的
这就是要瞄准的目标！
在理想化的世界中，软件中的一切都应该是“确定性的”。我们都应该是函数式程序员，编写没有副作用的纯粹的函数。如String.contains()。无论执行以下操作多少次：
结果总是相同的，都是预期的结果。哪怕宇宙爆炸对这一计算也没有影响。这是确定性的。
我们也可以在我们自己的程序中，而不仅仅是在标准库中做到这一目标。我们可以尝试尽可能多地编写无副作用的确定性模块。这真的与我们选择什么技术无关。确定性编程可以用任何语言完成——即使函数语言有更多工具也可以通过更复杂的类型系统来防止意外的副作用。
但是我所示的例子是一个Java示例。对象方向允许确定性。对的，像PL / SQL这样的程序语言允许确定性。如果要在索引中使用函数，那么需要请求确定性的函数：
这又是一个规则问题。有副作用的过程/方法/“函数”是为“破窗户”。有副作用也许会更容易维护，当然希望最终可以消灭副作用。但这通常是自己骗自己。当将来的某一天意外突现的时候，就是你付出昂贵代价的时候。别不相信，说曹操曹操就到。
5接受意料之外的事情
程序员始终应该遵守墨菲定律。一切都可能被打破。并且它即将被打破。作为软件工程师，我们应该谨记它是会破掉的。因为我们的世界是不确定的，所以我们正在实现的业务需求也是不确定的。我们只有在终于能够确定的时候，才能实现技巧#4（确定论）。
否则，我们将不可避免地进入不确定论的世界（也就是“现实世界”），即一个将会出错的世界。所以，要以此为基础。接受意料之外的事情。训练你内心的洪荒之力，从积极的角度预见各种麻烦。
当然，如何以简洁的方式写代码来预见各种麻烦就是另一个故事了。如何从那些可能会失败的东西（因此不需要处理）中辨别那些将会失败的东西（因此需要处理），还是需要通过一些实践滴。
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).