What Makes a Good Programmer Good?
I’ve worked with a lot of programmers over the years — some of them super amazing, and some distinctly lackluster. As I’ve had the pleasure of working with some very skilled individuals recently, I spent some time thinking about what I admire in them. What makes a good programmer so good, and a bad programmer so bad? Or, to mangle English a little bit, what makes a good programmer good?
Based on my experiences, being a great programmer has nothing to do with age, education, or how much money you make. It’s all in how you act and, more deeply, how you think. I’ve noticed a consistent set of habits in the programmers I admire. More than knowledge of their chosen language, deep understanding of data structures and algorithms, or even more than years of on-the-job experience — the way they communicate, the way they conduct themselves, and the way they approach programming speak volumes as to their amazing level of skill.
Certainly there’s more to being a good programmer than anyone can enumerate, and I wouldn’t judge any programmer solely based on the presence (or lack) of these practices. But I do know wisdom when I see it, and when I see a programmer expressing these traits, I think, “This person really knows what they’re doing.”
They do their research
Or “measure twice, cut once.” Or “Google it.”
Whatever you call it, most programming problems you’re likely to encounter have been solved in some form already — Ecclesiastes had it right in observing there was nothing new under the sun. In the form of libraries on GitHub, blog posts on the Internet, or just getting in touch with experienced individuals, good programmers know to do the research before they try to solve a problem.
I’ve seen even great programmers rush to solutions: but the worst programmers I’ve worked with never consult others, and as a result do huge amounts of duplicate work or tackle issues in precisely the wrong way. And unfortunately, they end up paying for their mistakes later.
They read error messages (and act on them)
This includes desymbolicating stack traces. Yes, it’s ugly and unfortunate — but if you’re not willing to do it how are you going to know what’s wrong? The most effective programmers I know aren’t afraid to dig deep into problems. The least effective see there was an error but don’t even bother reading the error message. (This sounds ridiculous but you’d be surprised how frequently I run into it.)
To take this a step further, great programmers see a problem and hunger to solve it. Reading error messages are for them just the beginning: they’re anxious to dive deep into the issue that it represents and figure out what’s going wrong. They’re not interested in passing responsibility, they’re interested in finding a solution. The buck really does stop with them.
They go to the source
Documentation, tests, people: these things lie. Not intentionally, but if you want to know exactly how something works, then you must view the source yourself.
Don’t be afraid if it’s not a language you’re super familiar with — if you’re primarily a Ruby programmer and you suspect there’s an error in one of Ruby’s C libraries, go crack it open and have a look. Yes, you might not get it. But who knows? You just might, and you stand a way better chance than if you didn’t try at all!
If you’re in a closed-source environment then this becomes a lot harder, unfortunately, but the principle still applies. Poor programmers have little interest in viewing source, and as a result problems flummox them much longer than those who are willing to do some research.
They just do it
Good programmers are driven to act. There’s a compulsion in them that can be difficult to control: they’re implementing a solution as soon as they identify a problem or see a new feature request, sometimes too early and sometimes too aggressively. But their instinctive response to a problem is to tackle it head-on.
This can be troublesome at times — but their enthusiasm is a crucial part of being good at what they do. While some might stonewall or wait for the problem to go away on its own, good programmers start solving.
To put it more simply (and, perhaps, too obviously): if you see someone excitedly grabbing problems and acting on them, chances are you have a good programmer on your hands.
They avoid crises
This is mostly a bad programmer trait: they tend to bounce from artificial crisis to artificial crisis, never really understanding one before they move to the next. They’ll assign blame to the wrong parts of their program and then spend hours debugging something that works perfectly well. They let their emotions get the better of them, trusting gut feelings rather than careful, explicit analysis.
If you hurry through a problem — or even view each problem as a world-shattering catastrophe — you’re more likely to make errors or not address the underlying issues. Great programmers take the time to understand what’s going wrong, even when there really is a catastrophe: but more than that, they treat regular problems as issues to be solved. Thus they solve more of them more accurately, and do so without raising the tension level of your organization.
They communicate well
Ultimately, programming is a form of communication. Being able to succinctly and eloquently express your thoughts is as crucial in writing code as it is in writing prose — and I’ve always found that those who can write a pithy email, elegant status report, or even just an effective memo will also be better programmers than those who cannot.
This applies to code in addition to English. It’s certainly possible to make a one-liner filled with parenthesis, brackets, and single-letter functions: but if no one understands it, what’s the point? Good programmers take the time to communicate their ideas properly in whatever medium they’re using.
They are passionate
I think this might be the most important aspect of a good programmer (and perhaps the part of this list most generally applicable to fields other than computer science).
If you truly care about what you’re doing — if it’s not just a job, but a hobby, an interest, even a fascination — then you have a major advantage over anyone else in your field. Great programmers are always programming. Their peers will clock out at eight hours a day: not out their job, but of their field in general. They don’t have programming side projects or much interest in contributing back to the community. They’re not constantly trying neat new methods and crazy programming languages just to see how they work.
When I see a programmer who’s doing their own hobby projects on the weekends, who’s involved in the creation of the tools that they use every day, who’s fascinated by the new and the interesting: that’s when I really know I’m looking at an amazing person. Ultimately great programmers view their profession not just as a means to make money, but as a means to make a difference. I think that’s what makes the best programmers who they are. Coding, to them, is a way of shaping the world. And that’s what I truly respect and admire.
Josh Symonds performs devops and server wrangling on cloud-scale infrastructures, deploys amazing web applications with Ruby on Rails, and creates awesome iOS apps with Objective-C and RubyMotion. He is founder and CTO of Symonds & Son, a development shop focused on quality and excellence.
What Makes a Good Programmer Good?的更多相关文章
- What technical details should a programmer of a web application consider before making the site public?
What things should a programmer implementing the technical details of a web application consider bef ...
- 程序员能力矩阵 Programmer Competency Matrix
[译文]程序员能力矩阵 Programmer Competency Matrix [译文]程序员能力矩阵 Programmer Competency Matrix 注意:每个层次的知识都是渐增的,位于 ...
- What every programmer should know about memory 笔记
What every programmer should know about memory, Part 1(笔记) 每个程序员都应该了解的内存知识[第一部分] 2.商用硬件现状 现在硬件的 ...
- [转] Finding the Best Programmer's Font
原文 Finding the Best Programmer's Font
- 10 Things Every Java Programmer Should Know about String
String in Java is very special class and most frequently used class as well. There are lot many thin ...
- POJ - 1245 Programmer, Rank Thyself
POJ - 1245 Programmer, Rank Thyself Time Limit: 1000MS Memory Limit: 10000KB 64bit IO Format: %I64d ...
- sof文件和NIOS II的软件(elf)合并为jic文件以使用Quartus Programmer烧写
将Altera FPGA的sof文件和NIOS II的elf固件合并为一个jic文件以使用Quartus Programmer烧写 我们在学习和调试NIOS II工程的时候,一般都是先使用Quar ...
- Articles Every Programmer Must Read
http://javarevisited.blogspot.sg/2014/05/10-articles-every-programmer-must-read.html Being a Java pr ...
- pic/at89c2051 programmer
http://dangerousprototypes.com/forum/viewtopic.php?t=170 It looks like the PICKIT2 uses a small boos ...
- POJ 2970 The lazy programmer(优先队列+贪心)
Language: Default The lazy programmer Time Limit: 5000MS Memory Limit: 65536K Total Submissions: 1 ...
随机推荐
- 将Excel另存为CSV格式文件
直接将Excel另存为CSV,速度很快: $CurrentPath = $MyInvocation.MyCommand.Path.substring(0,$MyInvocation.MyCommand ...
- Netsh配置端口
开启防火墙端口 netsh firewall set portopening all 3389 RDP_Rule enable (TCP/UDP) #配置RPC高位端口段Netsh int ipv4 ...
- STL源码学习----lower_bound和upper_bound算法[转]
STL中的每个算法都非常精妙,接下来的几天我想集中学习一下STL中的算法. ForwardIter lower_bound(ForwardIter first, ForwardIter last,co ...
- Android6.0动态权限申请步骤以及需要注意的一些坑
因为工作需要,简单研究了一下Android6.0权限申请,在Google提供的sample的基础上,写了一个简单的demo.算是自己的笔记吧,可能会比较混乱,主要是方便以后查看.后期有别的问题,随时更 ...
- 实现顶部轮播,下部listview经典布局的两种方式
开头: 在做android开发的时候,我们经常会遇到这样的布局,上面是一个图片轮播图,下面是一些列表的项目.很多新闻app,视频类app都采用这样的布局.起初的时候 由于没有很多参考,我自己想到了一种 ...
- iOS开发——数据持久化Swift篇&(二)沙盒文件
沙盒文件 //******************** 5.2 文件操作 func use_FileOperations() { //1.获取程序的Home目录 let homeDirectory = ...
- IIS配置相关
转:让Windows Server 2008 + IIS 7+ ASP.NET 支持10万并发请求 http://www.cnblogs.com/dudu/archive/2009/11/10/160 ...
- ext3文件系统基础
http://blog.csdn.net/haiross/article/category/1488205/2 block size: 是文件系统最小的单位,Ext2/Ext3/Ext4 的区块大 ...
- 用于迭代器的yield return
在我们写迭代器的时候往往继承自IEnumerable public class Tuple<T1, T2, T3> : Tuple<T1, T2>,IEnumerable { ...
- Ubuntu目录
1. java.io.FileNotFoundException: ***(Too many open files) 2. 在Ubuntu 12.04 桌面上设置启动器(快捷方式) 3. 解决Ubun ...