工作中有一半时间都不在写代码,这是合理的吗?

新手上路,请多包涵

开会、接需求、讲需求、搜索资料、扯皮等等,好像每天写代码的时间没那么多,这是正常的吗?大家怎么看?

回复
阅读 3k
28 个回答

看你的公司处在什么状态,有时候是合理的,或者说没办法。因为开会、聊需求、确定需求,才能避免日后扯皮、返工,才能保证我们写出的代码能够真正促进业务的发展。

已参与 「极客观点」 ,欢迎正在阅读的你也加入。
新手上路,请多包涵

我感觉是合理的,因为业务代码确实不多,有的公司已经成体系了,确实没有太多的代码要写,完美的完成产品的需求其实就挺不错了
已参与 「极客观点」 ,欢迎正在阅读的你也加入。

如果你能慢慢把这种新鲜变成家常便饭,那么恭喜你成熟了。实际的情况的确都是这样。

已参与 「极客观点」 ,欢迎正在阅读的你也加入。

好像大家对程序员的误解都是埋头写代码的状态,我感觉这是大多数人对程序员这个职业及其工作职责上所存在的最大的误区。我之前也很不理解,一有开会需要参加我就心烦,会上也不会认真听。后来随着会越来越多,当然也是因为个人的成长吧我觉得,我也就理解了这种现象。

首先,程序员一般都是指某某软件开发工程师。开发一个软件,就要了解其产品定位、行业痛点、用户需求等一系列的信息(大概也可以统统理解为我们经常所说的业务吧)。我们虽然不需要向产品同学那样深度了解定位,也不需要像运营同学那样直面用户需求,但是我们需要把一切的定位、需求,转化成代码逻辑的呀。那试想一下,都不了解这些需求逻辑,怎么实现这些代码逻辑呢?

其次,一个软件开发出来,是需要包括研发在内的多个岗位通体合作的。既然是团队合作,就是需要沟通的。但凡涉及到多个独立的人,每个人作为独立的思想个体,肯定就会有思维碰撞和冲突,不可避免的就会有“扯皮”现象。只不过,如果是为了产品变得更好的扯皮,我会觉得这是一个氛围很好地团队。如果是为了甩锅而互相指责、逃避的扯皮,那我会尽早的离开这种地方。

再者,现在的资本家也好、领导也好,都更追求 T 型人才。对研发技术能力的要求是一方面,对其软素质的要求则是另一方面。所以你就会看到很多招聘信息,都会列出来“团队合作、沟通能力、价值观”等方面的要求,其与技术能力是并列重要的。

最后我想说,至于你想更多的提升自己的技术能力,还是更注重软素质的提升,主要看你对自己的职业规划。如果想一辈子都从事技术,那可以两耳不闻窗外事,一心只钻研技术,向技术专家的塔尖冲去,不疯魔、不成活。但是更多的人,会随着多方面能力的发展,逐渐朝着管理岗迈去,这条路上,可写的代码也越来越少,但更多的是需要协同能力、沟通能力、管理能力等等和写代码无关的能力,而这些能力,都需要这些各种会议、扯皮来提升,哈哈哈O(∩_∩)O~。

所以,正式它,换个视角,换个心态,你就不会煎熬。没准还会发现自己在另一方天地更有天赋呢。

已参与 「极客观点」 ,欢迎正在阅读的你也加入。

从某种程度上来讲,程序员是最贴近用户的一层,尤其是前端工程师。有效的沟通可以避免很多无用功,甚至解决很多燃眉之急。更重要的是沟通协作也是职场很重要的一种能力

已参与 「极客观点」 ,欢迎正在阅读的你也加入。

太正常了,在大型公司里,甚至更加普遍,可能在你看来是一个很简单的需求,都需要开会讨论的。

已参与 「极客观点」 ,欢迎正在阅读的你也加入。

写代码只是程序员的输出而已。只有大量的输入,才有输出。
而这大量的输入,需要做大量的工作,各种权衡,妥协之后,才可能输出代码。
而这背后的工作绝对是水面下的冰山。

已参与 「极客观点」 ,欢迎正在阅读的你也加入。

作为技术, 基本不需要开会, 开会的都是运营和产品, 技术都是做他们需求的
他们开完会后把产品图一画, 技术只管做就行, 如果技术都经常开会, 我觉得难以理解

已参与 「极客观点」 ,欢迎正在阅读的你也加入。

好多情况类的问题都不太好回答, 其实都得根据自身的情况来讲.

简单的来说,你得感觉到自己的成长, 如果不在代码上的成长, 在需求的梳理和沟通上有成长也可以. 你得从多维度去评价现在的状态.

不过作为程序员,还是得有牢靠的编码基础的, 如果说自己写代码的时间太少的话, 可以尝试可以刻意联系,利用碎片时间学习,或者减少不必要的会议, 和拒绝不必要的扯皮.


已参与 「极客观点」 ,欢迎正在阅读的你也加入。

如果把软件开发的过程分为需求分析、设计、编写代码、测试四个大的阶段,其中编写代码的占比应该是在 20% 以下。但是,这 4 个阶段中,维有编写代码是必不可少的,没有代码就出不了货,所以在实际的很多项目中,编写代码这部分占比高达 80% 以上。然而,由于对分析、设计和测试的弱化,这样编写出来的东西往往很难满足客户需求,也很难达到验收标准。

对于一个多人协作的软件项目来说,同步需求——也就是让团队对需求达成共识,是最重要的事情,其次就是同步设计。这些都是需要在编写代码前达成高度共识的事情。而在同步知识的过程中,由于大家的理解不一样,讨论、分析、扯皮是再正常不过的事情了。如果不能达成共识,编写出来的东西就可能会各按各的理解,最终写出来的东西存在很大的风险不是最初的目标。

说实在的,我很羡慕你们能有那么多的时间来做这些事情。很多时间为了赶时间,某些团队这些事情都是能省则省,虽然结果往往很不如意,但毕竟要先按期完成交付第一版 —— 只不过后面就是不断的跟客户扯皮了……


已参与 「极客观点」 ,欢迎正在阅读的你也加入。

关于开会的问题,需求会和进度会这个是肯定不能少的,不然就靠安排的任务去写代码很容易会出现不连贯的问题,比如说缺失了某一部分的关联业务,最后在上线前测试的时候才发现,就寄了。

平时开发中遇到的疑问也可以在进度会或者立会的时候提出来节省彼此的时间,不然一有没理解的点就去问,一有就去问其实浪费的时间就更多了。


其实你的实际Coding时间是没有给你安排的工期那么多的,很多的时间都是在整理业务逻辑和搜索资料上,或者是摸鱼上面。
如果按照每天8小时的工作,你全部都在Coding的话,脑力负担是很大的。等你回到家之后就只想京瘫了。一般大家都会多报1.5~2.5倍左右的时间,不然一直被DeadLine追着会让你疲惫的。

我给自己计划的Coding时间是20个小时每周,用WakaTime来统计,平时不忙的时候每天其实只有4小时在写代码,都不能够达到自己设置的20小时到。
忙起来的时候一般是40~50个小时/周,就这样才可能才满足你预想满工时的情况。

一般情况就是每天有1~2个小时花费在开会上,4个小时左右在Coding,剩下的时间都是碎片化的摸鱼或者扯皮。或者突然夹进来一个突发任务需要去解决。

已参与 「极客观点」 ,欢迎正在阅读的你也加入。

不太清楚国外的工作模式,但光拿国内来说,基本上算是合理的。

因为你自己独自一人写代码和在一个团队中写代码是不同的。公司要求的是为业务服务、为需求服务、为用户和最终产生的价值服务。那这个过程中程序员就仅仅是其中的一个环节而已,你可以理解为工厂流水线,程序员只是其中的一道工序,前期的原材料和后期的包装都不能缺少。那既然只是其中的一个环节而已,必然在开始生产全新的产品前,要统筹考虑这条生产线能否完成任务,所以就需要每个环节的人都来开会讨论,制定方案,虽然花的时间很多,但是在一定程度上保证了新产品出的错会越少,大家的目标也会更加一致。

已参与 「极客观点」 ,欢迎正在阅读的你也加入。
新手上路,请多包涵

如果对于工作流程有什么建议,可以大胆的提出自己的想法,至于采纳不采纳,就另说了。

已参与 「极客观点」 ,欢迎正在阅读的你也加入。

非常合理,大部分时间都在整理思路;思路清晰了,写代码很快

已参与 「极客观点」 ,欢迎正在阅读的你也加入。

开会:需求评审、计划会、回顾、功能演示.....

再加上一些临时的事情,开发时间会更少了


已参与 「极客观点」 ,欢迎正在阅读的你也加入。

根据达摩科技市场统计结果表明,程序员工作中有效集中的高效开发时间大概在2小时,所以请不要认为不合理,这个至少是目前市面上普遍存在的现状。

已参与 「极客观点」 ,欢迎正在阅读的你也加入。

很合理。

因为开发人员的工作不单单是写代码。一个项目要落地,从前期的参加需求评审,自己做业界调研,写技术方案,然后才是开发,开发后还得总结实践过程,然后去参加测试用例,最后还要写各种上线保障稳定的方案。所以这么看,写代码只是工作中众多流程的一环,你能花一半的时间在上面已经很不错了

已参与 「极客观点」 ,欢迎正在阅读的你也加入。
新手上路,请多包涵

甲方和乙方的区别吧,甲方可能讨论多,流程长,coding时间就少了,

乙方的开发相对简单点,项目需求沟通好,就不停的coding,直到项目交付。


已参与 「极客观点」 ,欢迎正在阅读的你也加入。

对比一下,你还是在合理范围内的。我目前每天有三分之一的时间来写代码就不错了,工作流程越完善,

节点会议就更加频繁。各种琐事接踵而来,还要控制被时刻打断的负面情绪。

感觉大部分人,都会经理这个时间段,习惯了,也就没那么纠结了。

已参与 「极客观点」 ,欢迎正在阅读的你也加入。

很正常, 软件开发基本 80% 的时候是在设计,想方案, 真正用在编码上的时间很少, 即使这样, 编码与调试的时间还是 3:7 分的, 即编码的时间只占整个时间的 20% * 30%

已参与 「极客观点」 ,欢迎正在阅读的你也加入。

很正常的操作,一般稍微大一点的公司或者正规一点的公司,开会讨论的时间占整个项目的三分之二,剩下的三分之一才是开发和测试的时间。
已参与 「极客观点」 ,欢迎正在阅读的你也加入。

我觉得非常合理,程序员不太可能一天八小时都是在写代码,肯定也得有需求讨论的时间。如果不讨论清楚,不达成一致,做出来不是公司想要的,这不还得浪费时间返工。


已参与 「极客观点」 ,欢迎正在阅读的你也加入。

感觉跟你所处的位置也有关系。在公司职级越高越不用写业务代码,每天的工作好像就是不断的开会开会。如果只是负责自己的那一部分需求,除了需求评审、技术评审、进度沟通等会议外,其余大部分时间还是可以自己掌控的。

已参与 「极客观点」 ,欢迎正在阅读的你也加入。

新手上路,请多包涵

作为程序员,应该都知道那个经典的软件需求流通链条:客户仅仅需要在树上面挂个轮胎啥的,结果是挂个沙发,大相径庭,什么样的都有。作为21世纪的程序员,光 闭门造车不行的,即使是创业,你也要出去调研客户需求和市场状态的

已参与 「极客观点」 ,欢迎正在阅读的你也加入。

合理又不合理,有时候需求多,争议多就需要拉会去拉齐。
我反感开会是因为:交付时间紧,会有多,还要写代码。
要是交付时间不紧张,工作量又不大,开会?那就开呗。到点下班就行

已参与 「极客观点」 ,欢迎正在阅读的你也加入。

也挺合理,不管它任何因素,45%左右时间写代码也不错了,这其中不包括排查疑难问题、开需求会、测试分析会等等,毕竟写技术评审等文档需要时间,代码设计、工程化设计等也需要时间。
如果 80%+ 时间一直写代码,反而不正常。(短期当然可以这样)

已参与 「极客观点」 ,欢迎正在阅读的你也加入。

其实代码只是整个项目生命周期中很小的一部分,虽然他不可缺少。而代码之外,这些暂且称之为编程软技能。跟产品、业务之间的博弈,本身也是一种技术。
如果你能站在很高的高度去审查这个项目,熟悉他的整个生命周期及数据流转。
编码速度自然就上去了。

已参与 「极客观点」 ,欢迎正在阅读的你也加入。

看公司业务情况吧! 业务不忙时,多学习就可以了,没必要焦虑。

已参与 「极客观点」 ,欢迎正在阅读的你也加入。

推荐问题
logo
极客观点
子站问答
访问
宣传栏