划分软件开发人员的两种尺度

引用说明：原文来自于http://www.iteye.com/news/21736   / 英文  http://rc3.org/2011/04/28/classifying-software-developers/，为了方便本人阅读，文本格式略有调整。

 

行业分析师 James Governor 试着创建一套开发人员的分类学。我认为他利用了开发人员与思维的关系。我开始思考我怎么将开发人员分类，最后归结为两种尺度来衡量他们。

　　第一种尺度是“职业 VS 爱好”，第二种是“专注内在 vs 专注外在”。

　　第一种尺度与动力有关。程序员编写程序，是因为这是他们的工作，还是因为他们他们享受软件开发本身？知道你的同事和潜在的雇员属于那一种是有帮助的。 因为在管理员工的时候，这极为重要。如果你不能切实地向那些为了工作而工作的开发人员，说明做这些事情会对他们的职业生涯有好处，要他们学习新东西或者变 得经验至上会很困难。其他则是为爱好而做编程工作。在选择解决方案时，他们很难决定是否已经给出了最好的解决方案或者最能激起他们兴趣的解决方案。

　　“专注内在 vs 专注外在”，这和开发人员更喜欢怎样去解决问题有关。当一个“专注外在”的开发人员遇到一个问题，他们会用Google搜索答案，会请教同事，会在 Stack Overflow 或者适当的论坛提交一个问题。当他们接到一项任务，他们会查找符合需求的开放源代码库，或者会查找过去解决了相同问题的人的博客。他们不排斥团队中有其它 的开发人员站在白板前与他们一起想出解决问题的办法。但这样做的缺点是，他们会创建一个用了jQuery 和MooTools 的网站，导致最后网站的每个网页页都会载入25个jQuery 插件。他们复制和粘贴在博文找到的代码，即使他们并不知道他是怎么运行的。

　　补充：关于如果利用搜索技巧，国外开发人员 Andriy Solovey 在他的博文《如何使用搜索技巧来成为一名高效的程序员》中的观点是：如果不借助搜索技术、网络及集体智慧，现代化高效编程是难以想象的。因此，搜索技巧对高效程序员变得愈发重要。现在，我们不需要了解和记住如何解决众多的编程问题，可以采用搜索技术。我们正变得更加高效、高生产力，并能够解决更多的问题。

　　“专注内在”的开发人员一般更喜欢尽可能依靠他们自己的脑力。他们常常为展示“这里还没有被发明”的典型体现选择时机，但只是个人层次的。当他们遇到 一个棘手的问题，他们常常会完全消失似的，直到他们已经解决了问题。他们解决简单问题的时间常常会更长，因为他们不会利用社区，他们不会留心社区中其他人 是怎么解决问题的。另一方面，你越偏向于这一端，你越有可能能够解决所有深层次的问题。当Google不能搜索出任何关于他们的问题的有意义结果时，他们 从来不会卡住在这里。他们也常常是团队中仅有的熟悉整个系统是怎么运作的开发人员。他们是那些实际发明东西的人。

　　两个尺度都各有千秋。一个好的团队会拥有各种各样的开发人员。如果团队太专注内在，就会常常不能将行业的进步带入他们自己的编码和实践中。如果团队太 专注外在，会很难在技术上获得有竞争力的优势，尽管他们常常可以快速交付产品。如果团队中有太多开发人员为自己的爱好而编程，他会因各种原因打击公司中其 余的员工。如果团队中有太多专注于职业的开发人员，就会缺少创造力，并通常不能成就非凡。

　　其他相关的尺度是“好 vs 不好”。成为前文提到的两种尺度的一方或另外一方，并不会促使你擅长或不擅长软件开发，但是优秀的和不及格的开发人员在分类上以不同的方式证明它们的重要性。区分好的和不好的开发人员是一门独立的学科，是一门我希望会更擅长的学科。

 

 

=======================================================================

 

Classifying software developers

In Commentary on 28 April 2011 tagged software development with 3 comments

Industry analyst James Governor takes a shot at creating a taxonomy of developers, with, I assume, people who work in developer relations in mind. I started thinking about how I classify developers, and boiled it down to positioning them on two scales.

The first is vocation versus avocation. The second is inward focus versus outward focus.

The first scale has to do with motivation. Does the programmer program because it’s their job, or because they enjoy developing software for its own sake? It’s helpful to know where your colleagues and potential hires lie on this scale, because it matters a great deal in terms of managing them. It can be difficult to motivate developers who are at the vocation end of the spectrum to learn new things or be experimental if you can’t show them in a tangible way how doing so will be better for their career. On the other hand, with developers who are at the avocation end of the spectrum to quit writing code and ship. When they pick an approach to solving problems, it’s often hard to determine whether they’ve chosen the best solution for the business or they’ve chosen the solution that intrigues them the most.

Inward focus versus outward focus has to do with how developers prefer to solve problems. When an outwardly focused developer runs into a problem, they’ll use Google, they’ll ask a coworker, they’ll post a question on Stack Overflow or on the appropriate forum. When they’re assigned a task, they’ll look for open source libraries that satisfy the requirement or they’ll look for blog posts from people who’ve attacked the same problem in the past. They’re not afraid to get other developers on the team to stand in front of the whiteboard and puzzle out the problem with them. On the downside, these are the developers who create Web sites that use jQuery and MooTools and wind up loading 25 jQuery plugins on every page of a site. They copy and paste code they find in blog posts even if they don’t actually know how it works.

Inwardly focused developers generally prefer to rely on their own brainpower as much as possible. They often times exhibit “not invented here” syndrome but on a personal level. When they are working on a tough problem they often seem to disappear completely until they’ve figured it out. It often takes them longer to solve simple problems because they don’t tap into the community to see how other people problems. On the other hand, the further you are toward this end of the scale, the more likely you are to be able to solve deep problems at all. These developers are never stuck when Google doesn’t return any interesting results related to their problem. They’re also often the only developers on the team who actually know how the entire system works. They’re the people who actually invent stuff.

Both of these scales are value neutral. A good team will have developers who fall all over the graph. Teams that are too inwardly focused often fail to incorporate industry progress into their own code and practices. Teams that are too outwardly focused have a hard time gaining a competitive advantage in terms of technology, although they can often deliver very quickly. Teams with too many developers who program for its own sake often frustrate the rest of the company for a variety of reasons. Teams with too many career-focused developers often lack creativity and usually fail to achieve excellence.

The other scale that matters is good versus bad. Falling to one side or another on either of the previously mentioned scales doesn’t make you good or bad at software development, but goodness and badness manifest themselves in different ways based on the type of developer. Identifying good and bad developers is a separate discipline, one I’d like to get better at.