随想
这是最近的一些新的想法,记录下来。
技术为业务服务
以前一直认为,唯技术论。一直到18年的时候,某公司CTO跟我聊,他说,不要为了技术为技术,要为了业务而技术。
首先,我们要定义什么是技术,这是一个宽泛的概念,用前东家老大的话来说,做技术的人,就像一个手艺人, 手艺就是我们的技术,从浅的层次来说,技术可以是用熟某个工具,框架,但这只是最基本的要求,光有这一点 还不足以叫做技术。我认为的技术,应该是熟知工具及其原理,善用数据结构,对不同的场景能对症下药。
然后我们就有了接下来的问题,为什么不要为了技术而技术?对于国内的绝大部分公司来说,其实普遍情况是 先有业务,然后才有技术。增删改查这样的技术是为了业务而服务,纯粹的技术例如xxx中间件系统则是为了 做业务的程序员服务。如果没有业务,技术也就用不上了。
要做管理吗?
我想这是我以前思维的局限性,认为就该好好的做技术,单纯的做技术。晚些时候我意识到,在国内,单纯的 做技术,一直做技术是不切实际的,因为比加班,终究比不过年轻人,而技术的积淀其实并不是随着时间线性增长 的,而国内大部分公司其实并不需要什么技术含量的程序员。 用大白话来说,绝大部分公司,只要 “it just works” 就够了。而且他们的量级根本达不到,也不需要优化。数据库调优?缓存?分布式?熔断?降级? 不需要。而国内真正需要这些的,也就是那些一线互联网公司。技术专家的岗位少之又少。
那么是否意味着我们需要转管理岗位呢?随着工作经验的提升,我们的title也会跟着往上走,到了一定的程度,例如 高级,自然就会开始带人,再往上可能就是专职管理。但是管理有一个非常大的缺点,管理是一个软技能,难以量化, 而且是公司强相关的,每个公司有每个公司的管理风格。
某个操作系统为何能流行?其中一个重要的原因是,支持各类平台。如果你的技能依附于某个公司,那么你就是这个 公司的螺丝钉,一旦公司不行了,可能你就跟着公司一起不行了。
做技术难在哪里?
做技术的人,要保持随时可跳槽,这也是为什么绝大多数人做不好技术,为了保持可跳槽,我们需要不断的跟上新的
技术。RESTFul时代,你还在URL里写 /delete
用xml? 云时代你还在用物理机?
然而有一个矛盾的地方在于,要想跟上技术的变更,就要花时间去学习。单身的时候可能体会不到,非单身之后, 时间会少很多,有了家庭有了小孩以后,会更少。
出路
这是我最近想得比较多的一个点。毫无疑问,以下几点:
- 纯粹做技术是不行的
- 管理这个技能是需要点上的,但是不能只做管理
- 不能抛弃技术做管理,永远都不要把手艺丢了
- 要随时可以跳槽
- 学习除了技术以外的东西,例如设计一个产品,学习产品经理
- 尝试创造睡后收入,看能否摆脱 打工/出来卖(大家都是出来卖的) 的这种收入模型
至于更高深的结论,有了一些初步的想法,但是还没有付诸行动,暂且不表。
刚毕业的时候,凡事追求纯粹,即做A则不做其对立面。现在不这么认为,凡事无绝对,找到一个trade-off方是上策。
更多文章
- socks5 协议详解
- zerotier简明教程
- 搞定面试中的系统设计题
- 用peewee代替SQLAlchemy
- frp 源码阅读与分析(一):流程和概念
- Golang(Go语言)中实现典型的fork调用
- DNSCrypt简明教程
- 一个Gunicorn worker数量引发的血案
- Golang validator使用教程
- Docker组件介绍(一):runc和containerd
- Docker组件介绍(二):shim, docker-init和docker-proxy
- 使用Go语言实现一个异步任务框架
- 协程(coroutine)简介 - 什么是协程?
- SQLAlchemy简明教程
- Go Module 简明教程