lz可以慢慢把自己变成项目负责人 不光要会程序 还有和老员工怎么和客户打交道 怎么给老板汇报工作
“一个人开发的内容，另一个人必须审核并且充分理解。不然一个人离职了或者休假了出了问题很难解决。这是公司要求的。”我们也是这么要求的。我们是小公司，我来之前只有一个人编程。结果她在以前的程序里一行注释都没有写，我想撞墙
而且我编程的底子也不好，一想到前途就。。唉。。
学Info的真好，可以鄙视德国人。
adgjl 发表于 2014-8-8 09:30static/image/common/back.gif
问题在于LZ太急于和过于表现自己能力。不在其位，不谋其政，他写的代码，他自己对其负责，你没必要“帮他改错，重新整理代码”。如果你技术水平高到可以轻松加愉快地做到这些，那做了也无所谓，问题是你看的“想吐...
+1.绝对经验之谈。句句在理。
本帖最后由 mandriva 于 2014-8-9 01:21 编辑
纯C写的
但通过代码和交流，看的出来他没有太多和底层相关的经验，对很多关键的东西了解不够。逻辑不够清晰，代码比较混乱，算法和设计能力都不过关（至少以我的标准看来）。
举一个具体例子他写的 ANSI C 代码出来看看。
A自测完的东西，往往一堆漏洞，到了我这里经常还有一堆Bug。而且由于代码混乱不堪，难以理解，看的让人想吐血。。
我个人比较反对那种写一行注释一行的 入门菜。
一个出色的程序员必须是一个出色的程序调试员，编程的最高境界是 调试和implement 交融的境界，这种级别的是不用再多的人手来碍手碍脚，而是能自动修正错误，然后每天又能又能解决一些问题，从而每天把整个项目推进到一个新的进度。
//具体的做法linux GNU 有gdbwin 的最出色的调试工具是微软自家的，逐模块断点调试，然后模块内部逐函数断点调试，然后函数内部逐行逐句断点调试，最终分而治之为变量错误，推导出逻辑错误，或者不是像他想象的那样能算出来。
(比如 用MFC.NETWinAPI 处理GUI 事件 和 进程调度 基本方法一致，但那些细小的地方就是要人不断的刻苦努力去研究它， 掌握的语言越难，越少人能掌握，说明你的方法论越充分，要处理实际问题的Alternative越多，能力就越强(win的WinAPI 难于 MFCMFC 又难于.NETLinux的 Kernel API 难于 X11 API 但 Linux 天生的优点就是程序调试 因为它的内核类型叫做 Monolithic，而 Monolithic 内核 的本质含义 是说整个OS 就是 一个凌驾在硬件之上的调试器。 )。 那些光会个QT 的就像 人会用office而不知道为什么人能用office，因为框架简化了操作，从而隔离了能提升技能，和从操作系统角度来观看更接近本质层面的 的核心部分。 )
如果项目相当庞大，那也不是每个程序员应当操心的事情，每个程序员仍然是整个软件大厦的基石，他应当做的中流砥柱是保证每个模块，每个函数的正确的输入输出，也就是从IO的角度来肩负使命。
那怎么把各个程序员的 心血合起来？ 通过项目管理。
能够担当这个角色的 是那种老屌角色的 架构师， 硬搞它就搞的通透的， 它们不但年轻时身经百战这种最艰难的攻坚阶段，而且也是春秋战国时期的那种纵横家，善于游说于不同的程序员之间，也就是人能做最艰难的事情，那种刷嘴皮的事情更是驾轻就熟。
为了照顾他的面子，每次开例会时，我也只是简单的说，程序有些不稳定，已经修正了之类的套话。。
你可以直接告诉他哪里是错的，如果它不信，抽那段代码出来做一个简单程序给他看，错就是错，不过你如果理解错了，你最后应该道歉。
LZ只要晓得他的系统、模块、功能设计，以及程序sequence就行了，也就是有一个全局观，这些大部分在沟通的时候就了解了，公司也没要求你去查看人家code. 以后出错，排查也快。如果都要互看代码，那证明开发日程还是不紧
楼主给人的感觉是太过急于表现了，所以对直接领导的缺点有点放大来看了，觉得不给力，是因为你觉得他妨碍你的表现了。
如果直接领导有什么不足，挺他而不是嫌弃他，日后他才会提携你。如果你打算踩他上位，那么要看你跟大老板的关系如何。如果关系特别铁，越级上位才有希望。如果不是，楼上几位的建议都是高招。
职场上适者生存，而不是能者生存。放大别人的优点，缩小自己的优点，才能跟同事更愉快地相处。