9 b% |5 n" L' z& A初期应该如何融入团队?) Z: Q2 y, S7 v2 O! Q6 t, v ^8 P( L
幸运的是程序员毕竟男多女少,因为我想举的例子和足球有关.我很爱看球,我们往往关注的都是那些场上闪耀的球星,然而任何一个年轻的小球员在初入球队时都是从替补席冷板凳坐起的, 哪怕你是罗纳尔多这样的超级巨星(球迷们不要怪我,只是我觉得拿大罗来举例相对争议小一些).7 X7 H# `4 k' }7 S0 q0 ~
8 |. T* N2 c W- c' z3 i! q
; ]& x6 i) y; G, Q m/ Q$ ]! y# f
初入职场的你,就如同一个刚进入球队坐在替补席上的小球员一样,最初很可能连90分钟末补时的那几分钟上场机会对你来说都是无比珍贵. % }. w- c5 F2 O8 _ / g2 J9 E0 r- @# \) t" f9 l , ~. f) T& o' m' D在这种情况下,要学会捡别人不要的活儿干,而不是坐在工位上打开qq和同学抱怨自己在部门里不受重视. 1 J: o3 m& R$ O+ o6 Q6 h% i7 n# p/ F( J* L. G: O, x, a
# g* g# K r9 t1 z: ~" a( O
举个例子:如果说部门里缺前端,你作为服务端也该自己学会写后台管理页面,这些东西leader看在眼里,他会明白你的努力.0 f; C8 e' C& s- N% r
' {2 I- x; |" W" K @5 q 9 h" V7 F0 k2 S: A7 E另外千万不要放过任何和同事们沟通的机会,哪怕是午餐时的闲谈.这恰恰是发现一些”可捡的活儿”的一个途径. # F) G3 @0 P6 r& e" b# k# j% n5 Q( x" [& D4 A5 X2 H2 d
- D6 g. _2 e) u+ y% J
遇到技术上的问题该怎么解决? - O( c) V, |9 D& h对于这个问题的看法有很多版本,我个人偏向于尽量靠自己解决问题. / A# ~4 Z! L6 L" w ! }+ `7 t+ Y' t D9 E$ S" Y( a6 b% w F1 F7 P) O
原因有二:第一个原因是作为一名初入岗位的工程师,不是看不起你,很多时候你对自己遇到的问题究竟该不该问别人,该问的话该问谁你都是不知道的.在这样的情况下, 你很可能把一个google五分钟就能解决的程序语法报错拿过去问了你的同事,问问题存在沟通成本和理解成本,你的描述不清以及对方缺乏上下文了解这些都可能增加以上两个成本, 这样一来不仅耽误双方的时间,长此以往还会让对方觉得你记得技术基本功不扎实,独立处理问题能力差.第二个原因是,即使这个问题真的是一个较为冷门的编程语言运行环境层面的bug, 你在不经过任何思考的前提下把它抛给了你的导师或是你的leader,他很可能是遇到过这个问题的,于是直接把问题的答案告诉了你,这样你就完美地错过了一次在你所使用的语言环境下亲自踩坑然后填坑的机会.# u/ @ h6 F* F2 V0 K0 e. H
& M! b b8 x) u; h6 ? - y+ h1 B9 V7 h我认为对于程序员来说,总有一天你要独立面对这些编译环境、运行环境的偏门bug,因为你不可能一辈子只写一门语言或是只从事一种开发岗位,你现在可以问你的导师问你的leader, 那么你自己当上leader之后又该问谁呢?总不能告诉自己的老板,这问题太难了,我解决不了.6 k& q7 ^0 S. `
* h. `* T' p" F) j, J, X
; y$ o+ L1 y& [我记不清好像是之前百度的首席工程师说过的一句话:衡量一个程序员价值的标准并不是他掌握了多少知识,而是他掌握的知识与学会这些所花的时间之比.8 q8 n3 Y" a$ n& T4 K
b: y2 t& V# `& f
P! g0 ^% i8 P( z) A% e/ F对于初入开发岗位的你来说,每一次踩到一个坑然后独立填坑的经历都将会加速你对更多技术领域内的知识和问题的学习速度,也将会提高你作为一个工程师的价值. ' k) E# ?1 N7 d K! L1 y 4 _( ~: c8 m. y/ w- n) }- q! L5 \0 v6 w. N6 M6 I' g
如何与产品沟通?/ w$ ^6 J, O) g+ m2 [$ D
在技术圈里这是老生常谈的话题,我认为与产品沟通的过程中是最能体现出一个程序员情商的时候.无论对方提出的需求是怎样的,你考虑问题的逻辑应该是:当前提的这一条需求做完以后对产品有什么收益?对技术这边又有什么收益?更重要的是leader们是否会在乎这一点?, H- [6 I2 k# w/ R
2 N9 `6 E3 A) Q/ k+ b
, {& z0 D' F8 S4 A然而这一切都应该发生在你的内心中,权衡利弊之后如果有什么没考虑到的你可以提出来,如果并不是十分确认自己的想法,你可以等会后私下里和你的leader提出自己的看法,这既是对leader的尊重也是节省开会时间.# O/ X4 ~* O( l% ]. i7 q X
5 J* @5 s5 g' P$ V* D% k; q3 y
$ i4 w- v3 F, f. N5 r
幸运的是,在互联网这个行业里,需求沟通的过程中,技术人员的话语权通常还是较大的,然而绝不要滥用你的话语权.7 O, m8 H9 A5 \" _! I
: H2 J; L2 H; n, o8 }$ k $ Z) E* C* m& A( U5 a( O我可以扪心自问的说,在我正式入职以后沟通过的每一位产品,没有和任何一位发生过争吵,相反的是产品们都愿意与我对需求.; [& r* }$ \4 R0 a) k1 U, |' M
2 q) ~/ w; Z5 L D. i9 B, u5 L