我在it这个行业有10年左右的经验了，但我一直是个程序员。曾经一个程序员的管理人员，我的上级给我说过，程序员的管理是比较难的。 我想他这样说,一个原因是，程序员的工作成果是用代码说话的。但在编程的过程中，可能要和产品人员，设计人员，上游人员，下游人员，上级，同事沟通交流。 我简洁的把程序员的能力分为编程能力和沟通能力。
刚才在网上搜索情商，得到这样一句话 "在生活和职场中，很多时候不是输在能力不行，而是输在说话 做人情商低"。 下面我用分隔线来讲一个项目上的问题。
-------------------------------------------------------------------------------------------------------------------------------------------
我曾经做过一个大数据的项目。我的上级把我叫过去，说做一个用spark处理数据的项目。我和相应的产品人员沟通，我得到了前期的需求，我的其它同事把数仓处理的结果数据放在一些表中，我就是用spark把这些结果数据进行二次处理，前期的需求我觉得很简单，用spark和flink都是可以。当时由于自己的私心，学习的私心说用flink做，也得到了我的上级同意。
我做完一个版本的需求后，接着又提新的需求。我在实现需求的时候感觉到，或者我推测到，再这样提需求下去，这个代码将变得越来越难写，越来越难维护，但我觉得这不是我技术能力造成的，是这个项目需求不合适造成的。 有时候我也给领导反映过困难，我也给领导说再加一个大数据开发人员，我们分模块写，我试图用这样的方式告诉领导，不是我的原因造成的，是这个项目本身它就有问题造成的。 但一直没有新的大数据开发人员加入。
我有个特点，或者缺点就是我总体来说是不擅长和人交流的。 当时有个做java后端的，叫王路，我和他交流沟通，觉得他人不错，我没看过他写的代码，但我做这行多年了。我个人有个自大的想法，我也不知道对不对，我和一个人接触，就可以判断出这个人是否适合编程。 虽然王路没有做过大数据开发，但我觉得他适合编程，我当时就找王路让他转做大数据开发，由于种种原因他没有转，后面他去别的地方做Java后端开发了。 我当时这样做，主要是看好王路这个人，而不是好像是从一个角度想，我自己搞不定，拉一个做java后端的人背锅。 当时也有其它Java后端开发人员，我怎么不找其它的人呢。在我的眼里，许多编程的工作，技术就是那么回事，有许多的它就是个体力活，熟练工种而已。（如我的简历上的3个项目，虽然是3个项目经验，但其实从技术角度讲，完全都是一样的，绝大多数的都是重复的体力劳动而已）只要有人教，被教的人适合做编程的工作，并且有编程经验，我认为这个是很快可以上手的。 就王路这个例子，在我的职位生涯多年前，我也干过类似的事。
我也知道这个项目后面还会提需求，我又控制不了需求，越做这个项目，我就越觉得这个项目交付的风险很大，这个项目它本身有问题。真这样做下去我要干到猴年马月，还不知道能不能交付。项目组也有别人觉得我这样做不合适，提出来用别的方式做，当时也被领导给否了。 当时一直没有新的大数据开发人员加入。综合，我开始投简历，跳槽。
跳槽成功后，那个项目有新在大数据开发人员加入，我也给支持过，讲过代码。 这个项目在我的心里一直是个事，我是觉得就按照当时的需求提下去，很难交付。
过了一两年后，我和当时我的上级叫刘进升沟通过，就问那个项目交付的事。 我记得他当时说的比较含糊。 前几天我又和刘进升沟通过，想确定的问下那个项目交付的事。他说什么交付了吧，从他的语气让我觉得，他也不确定是否交付。
如果那个项目真的交付了，并且是用flink或者spark做的。 我不看代码，就有信心从上游，通过某些手段，让它出问题。 或者就算交付了，我来提需求，提一些刁钻的需求，会让程序员实现很难受。 因为这个项目，如果用spark或者flink做，就是把它们想的太智能了，我是觉得这个项目它本身就有问题。
如果没有交付，我也认为是合理的，因为这个项目它本身就有问题。 如果让我拍板，这个项目倒底能不能做。从逻辑上讲，可以做，但必须把需求定死，不能变，并且数据量也要确定。我在这个行业多年了，在没有开发前，就把需求完全定死，一点都不能变，这个要求太高太高了，也不太现实。我是觉得这个项目本身的逻辑有问题，把spark或者flink想的太智能了。
这个项目最优的解法，是在项目开发前，就找有过flink项目经验的人，再找到产品人员，双方就目前的需求和以后的需求进行讨论，来看这个项目是否能做。
-------------------------------------------------------------------------------------------------------------------------------------------
上面划虚线中的部分，是我讲一个项目的事。听过郭德纲的相声，有一句话"在大海中航行大船，快要沉了，对船上的人来说是灾难，但对厨房中的活鱼活虾那就是生命的奇迹"。下面我就从程序员的管理方面，从不同角度来讲这个事。
一，上级不懂flink。
（1）从一个角度讲，如果这个上级没有做过开发的工作，不懂flink。我当时的做法，叫一个做java后端的人来和我一起做大数据开发，从一个角度来讲，我是不是让他来背锅。从上级的角度讲，我应该技术很差，这个项目不能交付就应该怪我。
（2）从一个角度讲，我虚线中那段话，最后那两段话，我还敢对我之前做的项目推测，还敢对交付方面推测。如果我推测的准确，那么我是不是就很牛逼。 这和上述（1）真是两个极端。
（3）从一个角度讲，如果那个上级不懂flink，但这个项目组还有别的flink的开发人员。那么很有可能，这个上级就会问别的flink的开发人员，我的水平怎么样。这种情况我的flink的水平怎么样，就很有可能取决于，我和别的flink开发人员的人际关系。
(4)从一个角度讲，如果那个上级不懂flink。我做的flink项目上线了，但是出问题了。 其原因是我和上游同事闹矛盾，上游同事记恨我，在上游生产数据上动了手脚，这个是很有可能让我的flink程序出问题的。 甚至再卑鄙些，这个上游同事和一个懂flink的人员配合，通过看我的flink代码，这种是更容易造成我的flink程序出问题的。
(5)从一个角度讲，如果那个上级不懂flink。我如果使个坏心眼，本来一天可以做完的内容。我上班期间摸鱼，干别的事，这样就可能花两三天才能做完，来骗公司的钱。反正上级不懂flink，我只要和别的flink开发人员搞好关系就好。
(6)从一个角度讲，如果那个上级不懂flink。公司有监测机制，如可以监测到我每天写代码的情况，写代码快慢的情况，写代码行数的情况。 就拿数据排序这个例子来说吧，我如果用冒泡排序，这种代码写起来简单，写起来要快，代码行业少，从编程的技术角度讲，应该是能力低。 我如果用归并或者快排，这种代码写起来慢，代码行数多，从编程的技术角度讲，应该是能力高。我前面说的能力高低，是指编程方面的执行效率，实际开发中，有的项目需要快速完成，不用管执行效率，我会归并或者快排，但为了快速完成，用冒泡排序就是最优解。 我再补充一下，例子我就不举了，绝对不能以代码行数来定这个程序是否开发的好。
二，上级懂flink
(1)从一个角度讲，如果那个上级懂flink。这就看这个上级人怎么样了，是否能公正的评价我。
(2)如我个人交流沟通方面有问题。 做事比较个性，如见到某些人，或者领导应该主动打招呼。 但我不喜欢说话，没有打招呼导致某些人记恨我，或者其它方面做的不好得罪了别人，而对我进行报复的做了些事。 如从管理方面，我之前经历过，发现有人有时候对我特别的好，好的特别的异常，我觉得不应该那样对我好，好的让我得意忘形，同时也有别人，通过做一些事诱导我犯错，导致我做过一些出格的事，而害了我自己。后来我看了些书，才明白，那种手段叫捧杀。
--------------------------------------------------------------------------------------------------------------------------------------
综上所述，事情从不同的角度想，甚至我有的写的是是从卑鄙的角度来想，会有不同的结果。从避免矛盾，减少冲突的角度想。如一个管理人员，管一些做flink开发的，这个管理人员最好也做过flink开发，不然就容易出各种各样的问题。
)
