Give Developers Autonomy
2015-08-13 09:12
141 查看

MoST ARCHiTECTS BEgin THEiR CAREERS AS dEvElopERS. An architect has new responsibilities and greater authority in determining how a system is built. You may find it difficult to let go of what you did as a developer in your new role as an architect. Worse, you may feel it’s important for you to exercise a lot of control over how developers do their work to implement the design. It will be very important to your success and your team’s success to give all of your teammates enough autonomy to exercise their own creativity and abilities.
As a developer you rarely get the time to sit back and really look at how the whole system fits together. As an architect, this is your main focus. While developers are furiously building classes, methods, tests, user interfaces, and databases, you should be making sure that all those pieces work well together. Listen for points of pain and try to improve them. Are people having trouble writing tests? Improve the interfaces and limit dependencies. Do you under- stand where you actually need abstraction and where you don’t? Work for domain clarity. Do you know what order to build things in? Build your project plan. Are developers consistently making common mistakes using an API you designed? Make the design more obvious. Do people really understand the design? Communicate and make it clear. Do you really understand where you need to scale and where you don’t? Work with your customers and learn their business model.

If you’re doing a great job of being an architect, you really shouldn’t have enough time to interfere with developers. You do need to watch closely enough to see that the design is being implemented as intended. You do not need to be standing over people’s shoulders to accomplish that goal. It’s reasonable to make suggestions when you see people struggling, but it’s even better if you create the environment where they come and ask you for suggestions. If you are good, you will deftly walk the fine line between guaranteeing a successful architecture and limiting the creative and intellectual life of your developers and teammates.
Philip Nelson is a technology generalist whose career began in hardware; moved to networks, systems, and administration; and finally changed to software develop- ment and architecture, where he found the most interesting things were going on. He has worked on software problems in transportation, finance, manufacturing, marketing, and many infrastructure-related areas.
Give Developers Autonomy
Philip NelsonMoST ARCHiTECTS BEgin THEiR CAREERS AS dEvElopERS. An architect has new responsibilities and greater authority in determining how a system is built. You may find it difficult to let go of what you did as a developer in your new role as an architect. Worse, you may feel it’s important for you to exercise a lot of control over how developers do their work to implement the design. It will be very important to your success and your team’s success to give all of your teammates enough autonomy to exercise their own creativity and abilities.
As a developer you rarely get the time to sit back and really look at how the whole system fits together. As an architect, this is your main focus. While developers are furiously building classes, methods, tests, user interfaces, and databases, you should be making sure that all those pieces work well together. Listen for points of pain and try to improve them. Are people having trouble writing tests? Improve the interfaces and limit dependencies. Do you under- stand where you actually need abstraction and where you don’t? Work for domain clarity. Do you know what order to build things in? Build your project plan. Are developers consistently making common mistakes using an API you designed? Make the design more obvious. Do people really understand the design? Communicate and make it clear. Do you really understand where you need to scale and where you don’t? Work with your customers and learn their business model.

If you’re doing a great job of being an architect, you really shouldn’t have enough time to interfere with developers. You do need to watch closely enough to see that the design is being implemented as intended. You do not need to be standing over people’s shoulders to accomplish that goal. It’s reasonable to make suggestions when you see people struggling, but it’s even better if you create the environment where they come and ask you for suggestions. If you are good, you will deftly walk the fine line between guaranteeing a successful architecture and limiting the creative and intellectual life of your developers and teammates.
Philip Nelson is a technology generalist whose career began in hardware; moved to networks, systems, and administration; and finally changed to software develop- ment and architecture, where he found the most interesting things were going on. He has worked on software problems in transportation, finance, manufacturing, marketing, and many infrastructure-related areas.
相关文章推荐
- 架构师速成8.4-分库分表的关键点
- hadoop常见操作命令
- 让Shell终端下的svn diff支持颜色高亮
- linux 下tomcat 的catalina.sh的JAVA_OPTS的配置
- 【大型网站技术实践】初级篇:借助LVS+Keepalived实现负载均衡
- Ubuntu 14.04 为 root 帐号开启 SSH 登录
- Ubus移植到openwrt
- FMS2015:Memblaze现场演示单机310万IOPS高性能解决方案
- CopyOnWrite
- Apache+Tomcat构建Tomcat负载均衡集群
- 详解Hadoop核心架构
- spark加载hadoop本地库的时候出现不能加载的情况要怎么解决呢?
- AngularJS权威教程(www.Linuxidc.com整理)2
- AngularJS权威教程(www.Linuxidc.com整理)1
- (总结)Nginx与Apache、Tomcat、Resin动静分离核心配置
- Linux6 虚拟机克隆网卡问题及解决
- 记一次网站服务器迁移(my)
- shell中for循环总结
- Linux find命令示例
- 运维自动化 Cobbler 安装