对 IT 技术岗位的一点思考 Thoughts on IT posts

在一个提供软件产品或互联网服务的公司，通过在技术部门对不同工作设置相应岗位，尝试让技术团队发挥出最大效能（出工）的同时创造出最大价值（出活）。
In a company which provides software products or Internet services, we set different IT positions according to various jobs in the technical department, try to build an efficient and effective team and ultimately output the most valuable things.

本人在 IT 行业工作数年，发现不少公司，不少人甚至高管对技术岗位的认识有偏差或错误，故写作本文，尝试更准确地描述不同的技术岗位，或许可以帮到一些人。
I have been working in IT companies for a few years, unfortunately, I found many people, including company executives, misunderstand the duties of IT posts. This essay tries to describe various technical positions more accurately and hopefully, it could help someone.

程序员，软件工程师 Programmer, Software Engineer

《我仍然是一名初级开发员吗？》 对初级和中级程序员所应当具备的技术能力给与了分析和描述，摘录如下：
The article "Am I still a Junior Developer?" analyzed and described technical abilities that a junior and middle-level developer should comprehend and master, excerpts are below.

初级 Junior

• 理解基本编程概念 Understands basic programming concepts
• 开发代码时不太考虑性能和可维护性 Will produce code without keeping performance or maintainability in mind sometimes
• 会使用类库和框架，但并不总是理解相关工具实际做了什么以及它们是怎么做的 Can use libraries & frameworks but will not always understand what the tools are actually doing for them and/or how’s it doing them.
• 即便不理解，也会从网上（比如 stackoverflow.com）拷贝代码来使用，只要这些代码能工作 Might copy & paste code from the web (such as Stack Overflow) without understanding it, if it just works
• 偶尔会需要导师予以帮助 Will need occasional mentorship
• 工作受阻时，有时会担心别人认为自己不够好而不愿向他人寻求帮助（你是很不错的，寻求帮助很正常） Sometimes won’t ask for help when stuck because of fear thinking you’re not good enough (You are good! It’s ok to ask for help 😊)

中级 Mid-Level

• 深入地理解一门或更多编程语言 Understands one or more languages more deeply
• 编码时总会考虑性能和可维护性 Will produce code with thinking about performance & maintainability
• 使用工具时，理解它们做了什么，经常会考察工具源码来理解其工作方式，也会寻找缺少文档的工具的其他用法 Understands what the tools are doing for them, digs into the source code often to understand how it works & also finds undocumented usage of tools.
• 在考虑从网上拷贝代码之前，会先去理解它们 Will understand code found on the Web before even thinking about copying & pasting the code.
• 当工作受阻时总会去寻求他人的帮助 Will ask for help when they know they’re stuck (because asking for help is ok!)

高级 Senior

说起高级程序员，有时我也会像 Florian Rohrer 的一篇文字那样发出类似的疑问：《你什么时候可以说已经懂得一门语言？》 对于高级程序员而言，相比于初中级，“高”在哪里？他是否一定要在各方面胜出？答案很明显是否定的，那么应当以怎样的标准进行衡量呢？
Speaking of a senior programmer, sometimes I would raise questions like Florian Rohrer asked in "When Can You Say You Know a Language?" Relative to junior & mid-level programmers, where can we find how "high" they are? Do they have to be head and shoulders above others in every aspect? Obviously, the answer is negative, but how could we measure it by what standards?

• 从技术的角度对初中高划分，其思路应当是横向+纵向的。比如对编程语言的语法，API 的认识，不仅要考察程序员对其准确性、相关性、优雅度这样的横向认知，也要考察其对语言、API 的发展历史的纵向认知。之所以作纵向考察，是因为这样能衡量出其对技术的关注度，是否会对发展逻辑作深入思考，从而对技术的走向有一定的前瞻性。纵向知识同时也表现出一个人知识范围的广度，不仅仅是本学科领域的知识，也包括其他领域。 From the perspective of technology, we need to consider it horizontal & vertical when facing the three levels. For example, for grammar/syntax of programming language, understanding of APIs, not only do we inspect a programmer how he looks at both of the aspects of accuracy, relevance, gracefulness horizontally, but vertically inspect depths and the history of them. The reason why we inspect the vertical side is, we could measure how much he concentrates on them, whether he would think of the logic of development deeply, subsequently, make trends of technology with extraordinary foresight. In many cases "vertical knowledge" demonstrates how wide a technical personnel's knowledge he has, including various knowledge in other realms.
• 从非技术的角度看，一个有着广泛知识的程序员（比如艺术音乐体育等），往往能借鉴其他领域学科的模式、解决方法来审视当前遇到的问题，从一个新的视角“更有创意地”解决问题。 From the perspective of non-technology, a programmer who masters wide knowledge, (art, music, sport, etc,.), he would probably learn patterns and solutions from other fields so that he could offer a solution more creatively with a new sight when dealing with problems.

《关于滨野纯的访谈》中谈到明星程序员的三种品质：
Three virtues/characters a star programmer should have when interviewing with 滨野纯:
1，最重要的第一点是，能够持之以恒地做某件事；First and foremost, be persistent when you start something.
2，拥有良好的直觉和品位。良好的直觉，这里是指面对一个新问题时，即使没有完整的解决问题也能够凭直觉提出正确的解决思路和方向。Processing good instincts and tastes. Good intuition means that when we are facing a new problem, we could raise correct solution ideas and directions even could not solve the problem utterly.
3，沟通能力。这个沟通能力不是说只要说明 “我想做什么” 就可以了，而是能够解释 “我的目标是什么” 以及我得出这一目标的整个思维过程，并且更重要的，是能够让其他人信服，简而言之就是能够将自己的目标明确传达给他人的人。Communication ability. This does not mean that it is sufficient if we tell others "what I want to do", but illustrate clearly "what is my goal" and the whole process how I formed the goal, and more importantly, make others convinced. In short words, it is an ability that we could articulate our purposes to other people.

技术经理 Technical Manager

技术经理的一个明显能力体现在对疑难杂症的解决上，他能根据前端页面展现形式，问题出现的模式（出现时间，频率，位置等），服务器日志，造成的错误等逐步缩小错误范围并最终定位错误所在，如果直觉足够好，甚至能精准地一次性定位问题。他的另一个能力在于知道在哪里使用最恰当的技术，这将给项目管理带来益处。作为一名技术经理，他不可避免地需要对下属的技术能力有准确的了解，从而适当地安排工作并设立测试、审核环节，以防止产出糟糕的代码。
A remarkable ability a technical manager should have is how he/she troubleshoots an application. Based on the information from front-end page, the pattern a problem occurs(timing, frequency, position, etc.) Another ability could be he/she knows where to apply a technique in the most appropriate way, this would bring many benefits to project management. As a manager, he/she inevitably has to be well acquainted with each subordinate, subsequently could arrange tasks more precisely, set test or review operations, prevent from outputting unqualified codes.

项目经理 Project Manager

在中国大陆，很多软件开发公司或部门的技术经理和项目经理是同一个人，这里当然有成本的考量，但更多时候是想当然而为之。诚然，优秀的人才当然可以身兼数职，但对于相当复杂（频繁的需求变更，高人员流失率，开发人员的技术水平参差不齐，复杂的业务逻辑）的系统而言，将两者分开很可能是更好的选择。项目经理可以专注于项目的跟踪和推进，与其他部门的连接，等等。
In mainland China, the technical manager and project manager are de facto the same person in many software companies or departments. Of course, the cost could be a major concern, but under many circumstances, it is due to a misunderstanding of software development. Admittedly, a talented personnel can have multiple job duties, but as for a considerably complex system, such as continuous requirements change, high staff turnover, different levels of developers' ability or complicated business logic, it would be better to separate into two distinct roles. As such, a project manager can focus on tracing and pushing a project, connecting with other departments, etc.

架构师 Architect

谁可以成为一名架构师？他必须具备怎样的技能？《一名软件架构师的角色，技能和职责》 中对架构师这个岗位进行了详细的描述。
Who is eligible for an architect? Which skills should he/she grasp? The article "The role, skills, and duties of a software architect" elaborated on this subject.

在我看来，架构除了应用到技术上，还可以应用到个人、业务及各种关系上。对于个人而言，其技术的掌握程度，经验的丰富程度，对新技术的热情，知识面的广度与深度，及最重要的，对待“学习”的认知都成为其“架构”的一部分；就业务而言，包括业务功能是否设计的足够清晰（避免歧义）与合理，业务的激励机制的合理性，有没有把人安排到他最适合（擅长）的位置，这些都是“架构”的用武之地。
In my opinion, not only can architecture apply to technology, but to an individual employee, business logic, etc. For an employee, the comprehension of his techniques, his relative experience, enthusiasm for new technology, breadth and depth of knowledge, and the most important part, the cognition to "learning" make up the whole notion of "architecture"; as for business logic, including whether business functions are clear enough(to avoid ambiguity) and reasonable, the rationality of incentive mechanism, is it proper to assign a task to an employee, in all these fields we could apply "architecture".

以下重点讲技术架构。I would like to share more about technology architecture.

技术架构的目标 The purpose of technology architecture

• 从技术的角度看，要达到某个目标，其衡量标准可以从 3 abilities 进行； From the perspective of technology, we could measure an architecture with such 3 abilities to see if it could reach a goal;
• 进而，可以通过所使用的技术（框架）对 abilities 的支持程度判断其优劣与适用性； Furthermore, we could determine a technology(framework)'s pros and cons or applicability by how it supports the 3 abilities;
• 再进而，工程师对具体技术的掌握程度来安排岗位。Lastly, assign the most appropriate post to a software engineer according to his/her specific skills.

以上只是一个思路，而衡量一个系统的架构的优劣还有其他方面，比如这个图：
The above are only a few thoughts, there are many other aspects to consider when we are measuring a system's good and bad parts in terms of the architecture, like this mindmap:

所以，要评估一个技术的架构是否良好，只要这 7 个方面表现良好了，架构就是良好的。
Therefore, to estimate if the architecture of a system is good or not, I believe that as long as such 7 aspects are good, it is good.

技术与业务的冲突 Conflicts between technology and business

(to be added)

CTO

刻意忽略了一些工作，比如市场，技术前瞻性，与其他公司的关联，等等。
Some duties are ignored deliberately, relating to market, tech vista, connection with other companies, etc.

Title: 工作职责(duties)
人(employees)->事(tasks): 优于(prior to)
Note over 人(employees): 招人，裁人(recruit, lay off)；\n鼓励人，安抚人(build teams)
Note over 人(employees): 结构上可替换\n(make replaceable)
事(tasks)->技术(tech): 优于(prior to)
Note left of 人(employees): 工作职责分对内和对外两部分，在对外事务中，\n“事”-“技术”-“金钱”的优先级别需要调整\n(priority adjustment on tasks,\ntech and money when \ndealing with outside events)
Note over 事(tasks): 设置产品或项目的优先级\n(set priorities for products, projects)
技术(tech)->金钱(money): 优于(prior to)
Note over 金钱(money): 合理花费(reasonable expense) > \n节约或过度花费(save or squander)
Note over 技术(tech): 做产品而非做项目；\n文档一致性；开源贡献\n(do projects like a product;\ndoc sync; Open Source Contribution)
Note over 人(employees),金钱(money): 部门协调，项目\n(depts coordination, \nprojects accomplishment)