软件工程师薪资来自三类预算之一

将三类预算映射到公司类型

• 评论者常把这三类预算对应为：
  • 咨询 / 出售工时 → 销售与市场预算。
  • 产品公司 → 研发预算。
  • “其他所有公司”内部使用软件 → 维护 / 运营预算。
• 许多人指出，公司可以混合这三条收入/支出来源（例如产品 + 咨询 + 内部工具），开发者也可能在它们之间轮换。

成本中心 vs 利润中心

• 一个反复出现的替代框架是：工程师被视为利润中心还是成本中心？
• 利润中心团队往往获得更高薪酬、更多投入，以及对风险更高的容忍度。
• 批评者认为“成本中心 vs 利润中心”在概念上有缺陷：每个部门最终都在支持利润，但领导层的信念和 KPI 会让这个模型在实践中成立。

职业策略：应该瞄准哪个桶？

• 有些人坚持认为，为了薪酬、影响力和杠杆，你“总是”应该瞄准产品 / 研发或利润中心。
• 也有人强烈不同意：
  • 咨询（#1）对于擅长沟通和快速交付的人来说，可以非常赚钱且令人满意。
  • 内部 / “第三类”岗位可以提供稳定性、深厚的领域专业知识，以及长久的职业生涯。
• 适配性取决于个性（更接近用户 vs 更追求规模、对政治的容忍度、对倦怠的承受度）。

维护、内部工具与 SRE

• 许多人说，维护和技术债工作长期资金不足，尤其是重构和内部工具。
• 也有人反映相反：SRE/运维以及合规要求很重的维护工作，可能获得充足资金，并且比炫目的研发更受保护。
• 有人担心，把维护当作低地位工作会造成组织衰退和反复重写。

咨询经济学与计费模式

• 按小时咨询往往会激励最大化可计费时间，而不是质量或复用。
• 固定费用合同存在争议：
  • 优点：更能对齐激励；可以减少与客户的对抗关系。
  • 缺点：估算风险可能毁掉利润率；需要强大的范围界定和谈判能力。

行业例子与模糊边界

• 很多人认为这三类并不清晰：
  • Amazon、Netflix、银行和国防承包商等大型公司，把三类都包含在同一屋檐下。
  • 在同一家公司里，有些软件是核心创收软件；另一些只是赋能 / 后台软件。
• 有人建议使用经验法则：看看没有你的系统业务会不会停摆；观察“明星”是谁（销售、工程师、内容等）。

工作安全、裁员与权力动态

• 多个轶事显示，裁员会横扫“核心”和“非核心”岗位；财务目标和投资者压力往往压倒本地价值。
• 向组织结构图更上层汇报可以提供保护，但这种保护只和那位领导自身的政治位置一样稳定。
• 直接关联明确收入，或拥有难以替代的技能，有时有帮助，但并不能保证安全。

薪酬趋势

• 有人指出，极高总包（约 $500k）在少数几个细分领域之外已变得罕见（例如某些 FAANG 岗位、交易公司、专门的 ML/分布式系统岗位）。
• 2024 年市场被认为比 2021–2022 年没那么火热，许多公司即使对资深岗位也把薪酬上限定在 $200–250k 左右。

会计：Capex vs Opex 与税务变化

• 讨论涉及 capex（前期、资本化投资）与 opex（持续运营成本）。
• 云订阅和“按月付费”模式通常因灵活性和更简单的决策而更受青睐，尽管税务细节不同。
• 美国新的规则（IRC §174）现在要求将许多软件开发成本资本化，这会影响财务报表中“研发”项目的呈现方式。

遗留系统与 COBOL

• 作为少数理解遗留 COBOL 系统的人是否会带来高价值，这一点存在争论：
  • 有人认为这应该带来高价值；也有人指出，薪酬通常并不高，工作也常被外包到海外或“内包”到更便宜的地区。
  • 组织把单人知识视为风险，并试图通过替换项目或团队建设来减少依赖。