软件公司加班，这应该是个很寻常的事情；其实加班不应该是一个感到不舒服的事情，任何公司或单位都会加班，只是程度不同而已，程度才决定了算不算舒服。
加班不一定是坏事，看是什么情形。
为什么会加班呢
加班一般是没做完事情的直接结果。
但是可能有两种可能，一种是应该完成的事情没有完成导致的；
另一种即是一些特殊情况，这种情况就没什么说的，做就做吧。
第一种情况下可能又被分成两种情况，一种是因为时间顺序被其它必须完成的任务推迟导致的，这种情况下就提醒下做之前工作的人们，然后接着做了；
另一种是自身不能在规定的时间里完成要求质量的事情。
这话情况又被分成两种情况，一种是因为先前提供的没有真正达到规定的要求，导致后来做了很多补漏的工作；这种情况下，先做一件事情，将里面的问题提出来。
另一种就完全是自身的原因了，前提很ok，自身没有完成该做好的东西。这种情况要小心了，因为这其实意味着自身的技术还有差距，不能按质量要求完成工作。
加班的原因不只因为自己
根据上面的分析，加班的原因不单单是因为自己，可能是前提不太好，先做了很多补漏工作，当然更不爽的可能是，补漏工作花费了，最后得到结论，补漏还不如从新弄；这才是世上最让人痛苦的，不亚于失恋，如果时间很紧，有可能真想有赶紧到世界末日的期望，一切都结束吧...呵呵，开个玩笑，还是要继续弄呀...不过，有一点还是很重要的，不能老是出现这种情况，这些问题是需要慎重对待，不是说空话，出现问题总需要当事者或者相关人员做总结，尽可能避免设计一个让后来者不得不重新做设计并编写代码的东西；如果一定这样，那设计的意义在哪里？开发和代码工人有什么区别？
如果是自身原因导致的，那么深入分析一下，一般都会得到结论，那就是对于技术上的某些问题理解不够清晰导致的。一直以来，我一直在思考什么叫对技术问题理解很清晰？想了一遍又一遍，却一直不能完全来诠释这个概念，如果对于任何一个技术问题，能从设计者的角度来解释，那么他基本是很清晰的了吗？但是很多并不需要这样，因为技术有很多，一个人也不可能理解所有的东西。那么，怎么才能证明对一个技术问题理解了呢？研究了很多关于操作系统和编译器的东西，慢慢地这个问题的答案开始浮出水面了，那就是当能从底层来解释或剖析一个上层问题的原理或者过程，那这才叫对于问题很理解了。
但是，很可惜，在中国的这个软件环境里，一大部分弄上层，底层的东西似乎并不是很受重视，似乎只有那些搞研究的、搞嵌入式系统、驱动和架构的等这些需要能力很高的人物真正了解这些。我只能说，这犯了一个大错，因为不了解底层的使用上层，永远都可能出错，因为，上层出错可能有很多，定位这个问题也许不难，但是理解这个问题也许不是简单的问题，如果重视它，那么之后犯错的几率就降低，否则，bug只会一堆又一堆，终究快没了，也加班地差不多了。
其实，底层不难，只是没那么多人费心去学习和理解，也许只需要一个人的点拔，一个难的问题就ok了；差就差在，公司存在这样的人才吗？他们在影响着整个团队吗？团队是不是还在低效地改着上层的bug，真没看到底层在偷笑么？
更多信息请查看 java进阶网 http://www.javady.com