拿互联网行业来做主线吧。恩，以自我感觉为主。

1) 开发及调试环境
a) 对于Linux，要能够：安装、使用、网搜解决所有“遇到”的问题。
b) 对于依赖软件要能够：安装、使用、网搜解决所有“能解决”的问题。当然这主要是指开源软件；非开源的没必要费精力去深究，踏出那个门就用不上了。
c) 对于工具及“工具语言”，需要：安装、使用、网搜编写所有需要的使用场景。何为“工具语言”，能够解决简单需求，与项目主要语言不同的；比如：bash编写自动化脚本，Python编写导入导出工具，等等，孰能生巧。

2) 主要开发语言
首先明确的是“主要开发语言”是以“项目”走的负责主题逻辑的语言，开发语言的使用标准是“解决了问题”；类似“熟练、精通”这类词语并不合适作为标准。
以我现在所涉及子项目用到的主要开发语言，包括了：NodeJS、 Web(JS、CSS、HTML) 、Scala、Java、C++。有点多？没办法，使用场景是无法规避的，已经省略了工具语言的罗列。

3) “嘴遁”
说的好听点“沟通能力”，难听点“扯皮”。一个公司就是一个“社会”的缩影，总要面对“形形色色”特征的同事。
就职业性来讲，主要面对以下几个方面的进行“嘴遁”：
a) “这个功能为什么不能做”
一个新功能的加入，要考虑到对“原有架构”、“功能体系”的影响（统称“原有体系”）。如果与“原有体系”冲突太多，那么就很难为了“单一”功能做什么。“重起炉灶”再弄一套的方案，时常会“费力不讨好”。这一切的根源是“需求是不固定的、可变更的、可推翻的”；虽然能够用一些方案（可扩展性）来降低影响，但“这是有限度的”，突破“限度”的功能需求，仍是“不可做”的。
b) “这个功能为什么不能现在做”
一个“可实现”的功能要满足两个基本特征：一是有相应的技术（或基本功能）储备；二是具体实现有足够的时间；此外就是有“进度安排”。
c) “这个功能为什么要换个思路做”
许多“功能”如果直接实现对“原有体系”是有“冲击”的，但如果能够“换一个方案”实现则变得“可行”。这通常需要对“产品形态”的“些许”变更。
总之，整体上来讲在一个公司活着Team内的每个人的目标都是“一致”的；基本上没个成员都“希望”（或者奢望）“产品形态”能够向着“自己所构想”的那样逐步“实现”。但、但、但，“自我妥协”是不变的“方案”。