- 浏览: 224299 次
- 性别:
- 来自: 深圳
文章分类
- 全部博客 (212)
- 架构师-01-文档目录 (3)
- 架构师-02-组织 (7)
- 架构师-03-实施 (35)
- 架构师-04-监督 (14)
- 架构师-05-工具 (29)
- 架构师-09-引用文集 (63)
- 专题-01-微博应用 (5)
- 专题-02-GoogleEarth (1)
- 专题-03-运行维护 (9)
- 专题-04-经纪人营平 (3)
- 专题-05-RCP&RAP (5)
- 专题-06-框架PK (3)
- 专题-07-Android (13)
- 专题-08-UI (3)
- 专题-liferay6 (6)
- 专题-extjs4 (3)
- 专题-CXF (3)
- 专题-封闭网络的社会化 (0)
- 扯谈 (4)
- 外包 (9)
- 专题-C++ (4)
- 专题-09-BI (2)
- jquery&easyui (2)
- 专题-搜索引擎 (1)
最新评论
-
brighter:
oMapper.configure(Deserializati ...
jackson 抛出 bean 中没有定义字段的错误,只好用 gson -
PassFeed_free:
public Bitmap decode(ImageDecod ...
android universalimageloader 几点改进 -
PassFeed_free:
楼主你好, 请问这个库, 在大屏显示高清图片 ,listvie ...
android universalimageloader 几点改进 -
yonghong:
楼主只是揣测
JIRA4.1 升级到 JIRA5.1 -
abdxj:
"Could NOT parse license t ...
JIRA4.1 升级到 JIRA5.1
引用说明:原文来自于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 不好”。成为前文提到的两种尺度的一方或另外一方,并不会促使你擅长或不擅长软件开发,但是优秀的和不及格的开发人员在分类上以不同的方式证明它们的重要性。区分好的和不好的开发人员是一门独立的学科,是一门我希望会更擅长的学科。
=======================================================================
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.Classifying software developers
发表评论
-
深入理解Java:SimpleDateFormat安全的时间格式化
2014-06-26 01:45 447原文引用自:http://www.cnblogs.com/p ... -
注册MS CRM 2011 online
2014-04-24 00:38 494http://www.cnblogs.com/StoneGa ... -
微信架构推测
2013-08-06 09:45 1330原文:http://wenku.baidu.com/vie ... -
arc-04-10-手机应用的性能测试
2013-01-05 15:01 668手机性能测试的工具一大堆,但专门针对开发手机应用的性能测试工 ... -
GraphicsMagick 介绍及安装
2012-12-26 16:56 1225引用说明:原文来自 http://paris8.org/a/b ... -
在windows系统中生成数字证书-V3
2012-12-10 16:43 1040引用说明:原文来自 http://zhouyongqiang. ... -
如何从最大用户并发数推算出系统最大用户数
2012-11-19 14:52 1410引用说明:原来来自 ht ... -
使用JIRA搭建企业问题跟踪系统
2012-07-20 09:33 0原文来自:http://www.blogjava.net/zh ... -
Eclipse rcp/rap 开发经验总结
2012-01-11 23:48 1226有牛人将 Eclipse RCP & RAP 开发经验 ... -
VMware Server 在 CentOS 下的安装与配置
2012-01-08 09:46 1084引用说明:原文来 ... -
rdesktop:Linux 下的远程桌面客户端
2012-01-07 11:37 931引用说明:原文来自于 http://blog. ... -
解决 Oracle 11g存在密码过期问题
2012-01-04 09:52 786引用说明:原文来自 ... -
角色权限,RBAC
2011-12-27 23:00 855引用说明:原文来 ... -
Spring Security 2 配置精讲
2011-12-12 20:10 768引用说明:原文来 ... -
Linux下Mongodb的分布式分片群集(sharding cluster)配置
2011-12-12 09:45 814引用说明:原文来自于http://www.linux ... -
使用 JReble 实现 tomcat 热布署
2011-11-24 09:42 2081甚至有人为了实现热部署,放弃各种框架(struts, spri ... -
基于MongoDB的好友消息动态的实现思路
2011-10-18 13:45 1537引用说明:原文来自 ... -
Linkedin网站技术架构简介
2011-10-11 14:41 1205引用说明:原文来 ... -
微薄后台架构浅析
2011-10-11 14:00 773引用说明:原文来自于http://blog.sina.c ... -
通过 Flick 看数据库集群
2011-09-19 14:14 782原文参见 http://www.cchere.com/arti ...
相关推荐
3. **软件集成测试**:集成测试主要有渐增式和非渐增式两种方法。渐增式测试逐步合并模块,而非渐增式测试则一次性集成所有模块进行测试。 4. **可行性研究**:可行性研究的目的是在最短时间内以最小代价判断软件...
在显微镜镜头缺陷检测领域,Gabor滤波器和图像分割法是两种常用的技术,它们在检测机械部件,特别是玻璃等透明材料的缺陷时,展现出显著的效果。本主题将深入探讨这两种方法及其在实际应用中的重要性。 Gabor滤波器...
项目中的两种方法可能分别采用了原始的暗通道先验算法和改进版本,如快速暗通道先验,以提高计算效率。 4. 其他可能的去雾方法:除了上述两种方法外,项目可能还包含了其他基于暗通道先验或者新型去雾技术的实现。...
在本设计中,软件开发分为ARM端嵌入式Linux软件开发和FPGA软件开发两部分。ARM端软件实现WAV格式的节目源标准样品读取、解析MXML文件、汉字UTF8和GB2312转换、按键和导航旋钮的管理、TFT液晶屏显示和网络通信等功能...
debug 版本是软件开发过程中的测试版本,用于检测软件的错误和bug。release 版本是软件的正式版本,用于用户使用。 9. C 和 C++的差异: C 和 C++ 是两种不同的编程语言。C 是一种过程式编程语言,而 C++ 是一种...
通过合理划分仿真域,混合仿真可以实现不同时间尺度事件的同步处理,避免传统单一仿真方法可能出现的时间步长选择难题。 在“行业分类-电子政务-一种用于电力系统混合仿真的混合仿真系统.pdf”文档中,可能会详细...
标题中的“hog的代码matlab-DSST:DSST的实现(用于鲁棒视觉跟踪的精确尺度估计)”指的是在MATLAB环境中实现的一种名为“Histogram of Oriented Gradients”(HOG)特征提取方法,结合了“Directional Scale Space ...
开发人员可能会使用编程语言(如Python、Java或C#)编写自定义脚本来处理坐标转换,而GIS工具(如ArcGIS、QGIS或GDAL/OGR)提供了图形用户界面和API,使得非开发人员也能方便地进行坐标操作。例如,ArcGIS中的...
这个“msGC.zip_dugweg_granger_msgctxt_因果关系分析_国嵌 msg.c”文件和其包含的“MSGC-toolbox”可能是一个专门用于执行Granger因果关系分析和多尺度因果关系分析的软件工具或代码库,可能是由“dugweg”开发,并...
数据标记是使用YOLOv8的第一步,这通常包括两种方式:一是利用开放数据集,如Open Images,直接下载已经标记好的数据;二是使用CVAT工具进行自定义数据集的标记。CVAT允许用户上传个人图片并进行细致的标注,支持...
图像量化基础涉及两种基本运算:点运算和邻域运算。点运算仅考虑单个像素,而邻域运算则考虑像素的邻近区域。常见的邻域运算包括模板运算(卷积运算)、滑动窗口运算和块运算。模板运算通过设计特定的模板(卷积核)...
传统的SVM是通过找到一个最优超平面来分隔两类样本,但在多分类问题中,我们需要构建多个超平面以将数据划分到不同的类别。一种常见的方法是“一对一”(one-vs-one)策略,即对每一对类别建立一个SVM分类器,最后...
SIFT(Scale-Invariant Feature Transform,尺度不变特征转换)是一种用于检测和描述图像局部特征的算法,特别适用于特征匹配。SIFT的主要优点在于其尺度不变性和旋转不变性,使得在不同的视角、光照、距离和噪声...
本文将深入探讨如何使用MATLAB这一强大的数学计算软件来进行支持向量机的开发,并将其应用于语言诊断,特别是针对舌病的诊断。 支持向量机(Support Vector Machine,SVM)是一种二类分类模型,它的基本模型是定义...
在MATLAB中开发Bayesian Linear Classifier(贝叶斯线性分类器)是一种常见的机器学习实践,它基于概率框架,能够处理不确定性并进行有效的预测。在这个项目中,我们重点关注的是线性模型在二元分类问题中的应用。...
标题中的"matlab开发-classificationkmeans"表明我们即将探讨的是使用MATLAB进行分类的一种算法——K均值聚类(K-Means Classification)。K-Means是一种无监督学习方法,常用于数据挖掘和机器学习领域,目的是通过...
它提供了一系列内置函数和工具箱,方便科研人员和工程师进行算法开发。对于K-D Tree的实现,MATLAB源码可以帮助我们更好地理解和定制算法,以适应特定的应用需求。 K维树算法的基本思想是将高维空间分割成一系列的...
在MATLAB中,k-means算法是一种广泛应用的无监督学习方法,主要用于数据的聚类分析。这个"matlab开发-kmeansdkdistance"项目显然聚焦于该算法的一个特定方面,即计算样本之间的距离,可能是在一个高维空间中的欧氏...