Go homepage(回首页) Upload pictures (上传图片) Write articles (发文字帖)
The author:(作者)左published in(发表于) 2013/11/12 11:57:07 Where does a good programmer
Where does a good programmer-programmer-IT information Where does a good programmer
I worked with many programmers over the years – some of them great, some obvious common. Because I recently and some skilled programmers work is a pleasure, I spent some time thinking about what I envy them. What makes a good programmer as well, as bad as bad programmers? Or, as short as possible, what makes a good programmer is good?
According to my experience, become a good programmer with age, education, or how much you make, it's OK. Your performance is the key, sharper said, is how you think. I noticed that I envy programmers have the same habit. Compared to their chosen language knowledge, deep understanding of data structures and algorithms, or several years of work experience--is more the way they communicate, manage their own way, and according to their superb skills can know them programming methods are meaningful.
Of course, become a good programmer requires more than anybody can cite, I would not based on the existence of these practices (or lack of) and judged separately for any programmer. But when I saw I really know exactly, when a programmer that has these character gets, I would think, "this person really knows what they are doing. ”
They do research
Or referred to as "leap", or known as "Google".
No matter what you call it, most programming problems that you may encounter in some form has been almost solved. Ecclesiastes would have on record is nothing new under the Sun. On GitHub library file list, in a blog on the Internet, or communicating with a personal experience, a good programmer doing research before you know you want to solve a problem.
I have seen great programmers eager to give a solution, but I've been working with the worst programmers never consulted others, leading to a lot of repetitive work, or just using the wrong way to solve the problem. Unfortunately, they end up paying for their mistakes.
Read the error message (and)
This includes stack trace symbol resolution. Yes, nasty and unfortunately-but if you're not willing to do so, how do you know where I went wrong? I know the most efficient programmers are not afraid to dig deeper into the problem. Least efficient programmers see errors or are reluctant to read error messages. (This sounds ridiculous, but I encountered frequency will surprise you. ）
Furthermore, a great programmer see the problem, urgent to solve it. For them, read the error message is only the first step; they long for in-depth questions and find the source of the error. They blame a lack of interest, they are interested in finding solutions. Problems did they stop here.
They're going to look at the source code
Document, test and people: these are likely to be lying. May not be deliberately lying, but if you want to know exactly how the code works, you would have to look at the source code.
Even if it is not that you are familiar with the language and do not be afraid – for example, if you are a Ruby programmer and you suspect that Ruby c There are mistakes in the language pack, then to extract it later. Yes, you will end up with nothing. But who knows, you might find the problem, compared with nothing to do, you select at least one more chance way.
If you work in a non-open source environments, it's not so good, it's unfortunate, but the truth is the same. Bad programmers to view source is usually not much interested in, with the result that, compared with people who are willing to look at source code, they will usually be more of these problems.
They say do it
Good programmers tend to take action. They seem to have an uncontrollable compulsion: once they identified a problem or to see a new feature requests, you will proceed immediately to solve and sometimes even premature or too brave. Gut reaction is positive they encounter a problem to solve it.
Sometimes this leads to trouble, but their enthusiasm was key factor in they can do very well. When some people are holding off to avoid problem will go away on its own, or fantasy, good programmers have begun to rise.
Simpler (and perhaps, too obvious): If you see an exciting finding and dealing with the problem, chances are, you've got a good programmer.
They prevent
This may be a bad programmer features: they are entangled in a series of human errors, has always been understood the previous turn to next. They are always complaining about their error section in the program, they take many hours to debug code that runs perfect. They let emotions take the initiative, trust your instincts and not carefully clear analysis.
If you run into a problem--or every problem looks like the end of the world, you most likely are making a mistake, not to resolve potential problems. Great programmer will take some time to get a feel for what went wrong, even if it is really is a disaster, in addition to these, they will often appear as assigning tasks to deal with the problem. Because they can solve most of the problem more precisely, so as not to increase the intensity of your team.
They are good at communication
After all, programming is also a means of communication. To succinctly express your point of view is to write code as it is to write poems as important – a long time, I found those to be able to write simple e-mail memorandum of reports or just efficient, elegant people typically are better programmers.
The discovery of written procedures and use English. Of course, only one letter is riddled with brackets and named functions on one line is also possible, but if no one can understand the code you wrote and what does all this mean? Regardless of the medium, good programmers will spend time on how to express their point of view better above.
They are passionate
I think it is best able to embody a good Bob's place (and not just in the computer industry, which is applicable to any industry).
If you really care about what you do--don't just think of it as a work area to meet, but an interest in something, you have great charm, in this sector, compared to other people, you will have a huge advantage. Well Bob will remain subjects to write code, they spend time not less than 8 hours in the industry: including work and free time. In between writing project and with regret the relatively, they are not in favour of any party. They won't just to get to the bottom of something works all day fascinated by new technology or programming language.
When I study observed a Sunday is doing its own interest in the project, creating one of your own tools, fascinated by the new, interesting things when programmers: I realized that I was watching a person who will show everybody not help heart tribute. Finally, a great programmer and they will not be professional as a money-making tool, but a tool that changed the world. I think the real reason this is already a great programmer. Programming for them also means creating the world. Only such people, deserves our sincere respect and admiration.
一个优秀的程序员好在哪里 - 程序员 - IT资讯一个优秀的程序员好在哪里
我这些年和许多程序员工作过——他们有些人超级棒，有些明显比较平常。因为我近来和一些熟练的程序员工作的很愉快，我花了一些时间考虑我羡慕他们什么。是什么让一个好的程序员那么好，差的程序员那么差？或者，简短一些，是什么让一个好的程序员那么好呢？
根据我的经验，成为一个优秀的程序员与年龄、教育或者你挣钱的多少没有关系。关键在于你的表现，更深刻的说，是你如何思考。我注意到我羡慕的程序员有一致的习惯。比起他们所选语言的知识、对数据结构和算法的深入理解、或者几年的工作经验——更多的是他们交流的方式，管理自己的方式，和根据他们精湛的技巧可以知道他们接触编程的方法很有意义。
当然，成为一个好的程序员需要的比任何人可以列举的都还要多，我不会基于这些实践的存在（或者缺失）而单独评判任何程序员。但当我看到时我确实能明确的知道，当我看到一个具有这些性格的程序员时，我会想，“这个人真的知道他们在做什么。”
他们做研究
或者称作“三思而后行”，或者称作“谷歌一下”。
无论你怎么称呼它，你可能遇到的大多数编程问题几乎在一定形式上都已经被解决了。传道书早就记录在案，阳光底下无新事。在GitHub上的库文件列表中，在因特网上的博客中，或者恰好与某个人经验交流中，好的程序员知道要在解决一个问题之前先做研究。
我曾经见过伟大的程序员急于给出解决方案，但是我曾经一起工作过的最糟糕的程序员，从来不咨询他人，从而导致做了大量的重复性工作或者恰好使用了错误方式来解决问题。于是很不幸的，他们最终为他们的错误付出代价。
读错误信息（并以之行事）
这包括对堆栈追踪的符号解析。是的，令人厌恶而且不幸——但如果你不愿意这么做，怎么知道哪里出错了？我知道的最高效的程序员不害怕深入挖掘问题。最低效的程序员看到错误甚至都不愿读错误信息。（这听起来挺可笑的，但我遇到的频率会让你吃惊。）
更进一步说，伟大的程序员看到问题，会急迫的去解决它。对于他们来说，读错误信息仅仅是第一步；他们渴望深入问题并找出错误的根源。他们对推卸责任没有兴趣，他们对找到解决方案有兴趣。问题确实在他们这里止步。
他们会去看源代码
文档，测试和人：这些都可能会说谎。未必是故意撒谎，但是如果你想确切的知道代码是怎么工作的，你就必须亲自察看源代码。
即使这不是你非常熟悉的语言也不要害怕–比如，如果你主要是一个Ruby程序员并且你怀疑Ruby的C语言包里有错误，那就去解压它看看再说。不错，你可能会一无所获。但是谁知道呢，你也可能会找到问题所在，比起什么都不做，你至少选择了一条更有机会的路。
如果你工作在一个非开源的环境中，就不太好办了，这很不幸，不过道理是不变的。糟糕的程序员对查看源码通常没有太多兴趣，结果就是，跟那些愿意去研究一下源码的人相比，他们通常会被这些问题困扰的更久。
他们说做就做
好的程序员总是趋向于采取行动。他们似乎有种控制不住的强迫性:一旦他们确认了一个问题或者看到了一个新的特性需求，就会立即着手解决，有时甚至过早或者过于勇往直前。他们遇到问题的直觉反应就是正面解决它。
有时这会带来麻烦–但是他们的热情正是他们能够做的很好的关键因素。当某些人还在拖延回避或者幻想问题能自己消失的时候，好的程序员已经开始动手了。
更简单的来说(也许，太过直白):如果你看到一个人兴奋的发现并处理问题，很有可能你得到了一名好程序员。
他们防患未然
这可能是一个坏的程序员的特征：他们总是纠缠于一个又一个的人为失误，从来都是没有明白上一个就转向下一个。他们总是在抱怨他们程序中的错误部分，却耗费数小时对完美运行的代码来debug。他们让情绪占据主动，相信直觉而不是仔细明确的分析。
如果你突然遇到一个问题——或者每一个问题看起来都像是世界末日一般，你极有可能是在犯错误而不是在解决潜在的问题。伟大的程序员会花费一些时间来了解是什么出了错，哪怕是真的是一场灾难，除了这些，他们还会把常出现的问题当成分配任务来处理掉。由于他们能更精确的解决大部分问题，从而不会提高你的团队的紧张程度。
他们善于交流
说到底，编程也是一种交流的方式。能够简洁明了地表达出你的观点之于写代码就如其之于写诗一样重要——长久以来，我发现那些能够写出精炼的电子邮件、优雅的报告或者仅仅是高效的备忘录的人通常也会是更优秀的程序员。
这个发现对写程序和对英语一样使用。当然，把充斥着括号和只用一个字母命名的函数写在一行里面也是可以的，但是如果没有人能够理解你写的代码，又有什么意义呢？无论使用什么媒介，优秀的程序员会把时间花在如何将他们的观点更好地表达出来上面。
他们激情四射
我想这是最能够体现一个好的程序猿的地方（并且，不仅在计算机行业，这点适用于任何行业）。
如果你真正关心你做的东西——不只是把它当做一个工作区应付，而是一个兴趣、一件对你有着莫大魅力的事情，那么在这个行业里，相较于其他人而言，你就拥有了一项巨大的优势。好的程序猿会一直保持者写代码的状态，他们每天花在这个行业里的时间都不低于8个小时：包括工作和空余时间。在编写项目和授业解惑两者之间，他们不会偏向任何一方。他们不会只是为了搞清楚某个东西的工作原理而整天痴迷于新技术或新的编程语言。
当我自习观察一个周日正在做自己感兴趣的项目、在创造自己需要的工具、被新的、有趣的事物吸引的程序员的时候：我意识到我正在观察一个会领所有人都不由自主心生敬意的人。最后，伟大的程序员不会将他们的专业看做赚钱的工具，而是一种改变世界的手段。我想这就是早就一个伟大程序员的真正原因吧。编程，对于他们来说也就意味着创造世界。也只有这样的人，才值得我们由衷地敬佩和景仰。
赞