软件工程师的职责是开发软件系统和实现新需求等。可是实际工作中一个软件工程师有大量的时间在修复软件bug。
修复软件bug就像给病人做手术，要对症下药，不能乱改，即使发现了bug的原因，也要进行仔细的推敲，保证改了代码能修复bug并且不引入新的bug。
自己写的软件bug，只能说明自己学艺不精，有待提高。一般比较容易修复，如果是近期写的代码就更容易了，代码比较熟悉，省去了再次阅读代码并理解的时间。修复一个自己写的bug的时间大概在1小时以内，这只是个人经验值，当然也会有一些bug要花很长的时间定位并想办法解决。对一些抛异常的bug，在调试模式下可直接定位到代码行，解决起来很顺畅；解决业务逻辑的bug花时间相对多一些。
对别人写的软件bug敬而远之。解决别人写的软件bug需要花很多的时间，这个时间很难预期和把控。最好是谁写的代码谁来改bug.
修复别人写的软件bug不可避免的。可能这个写bug的人花了很长时间没能修复bug，这个时候需要技术更好的软件工程师来协助修复bug，因为一个软件工程师在一个bug上花费太多的时间，成本上是不划算的。商人的思考方式，不划算的事情不做。也可能写的软件bug的人外出、离职等，总归是有各种各样原因不可避免地修复别人写的软件bug。
以我最近修复的三个别人写的软件bug进行说明。软件系统很庞大、年代很久远，新接触一个持续迭代开发了十几年的ERP系统，不是很熟悉。前两个bug大概每两个小时一个就解决了，第三个bug花费了十几个小时，远远超过了我对这个bug的预期时间。
如果发现代码中有很多类似的问题，进行了大范围的修复，可能没时间进行完整的测试，这样就违反了代码变更之后必须进行测试的原则，需要谨慎处理，提醒测试人员协助加强测试，保证修改/重构后原有功能正常。代码中有单元测试更好，单元测试正常基本保证软件功能正常，但是我还未遇见过软件中有完备单元测试的源代码。
定位bug的一个技巧是字符串搜索，代码是以文本格式存储的，非常容易搜索到相关的内容，加快定位bug速度。有些软件内容生成的是加密文本，字符串搜索就不适用了。
代码的质量影响代码变更的时间。C#语言编写的软件竟然有10000多行的单个.cs类文件，还和其他几个大文件中的类相互调用方法，其中300多行的方法，方法中分step1、step2、step3、step4...，单行代码近300个字符，备注和代码的实际功能不符，各种奇葩的变量命名，这些都违背了优秀代码的原则。代码读起来十分费劲，我看了好几遍才看懂。作为一个有经验的软件工程师感到十分惭愧。软件工程师何苦为难软件工程师！
软件工程师技术差是根本原因。整天写业务逻辑，仿照现有代码依葫芦画片，不知道提升自己的变成水平。不敢深入理解框架，感觉那不是自己的事情，应该是高级软件工程师的事情，这种思维局限了个人的发展空间。所有的头衔都是虚的，工作任务不是井水不犯河水那么明确的区分，而是像代码之间的耦合一样，很多时候任务是相交的，当你选择可做可不做的事情不做的时候，别人被你坑了几次之后，也会把更多的任务留个你，工作就会陷入被动，别人也会远离你。为了技术变现，不限制自己的工作范围，积极承担任务，量力而行，避免996.icu。
懒。工作稳定之后就没有主动学习技术的冲动了，不像找工作的时候，时时想着提高自己以便拿到好的offer，早日实现财务自由。工作中用到什么学什么，慢条斯理地学习，浅尝辄止，很少人能熟读框架的官方技术文档，看成本的技术书籍更不容易坚持了。
工作时间短。编程入门不是很难，很多刚毕业或者培训机构短暂培训之后就参加工作了，甚至有些是校企联合没毕业就去公司实习，期间写的代码好不到哪里去。熟练写代码基本需要三年时间持续学习，五年可以达到80%的技术使用都没有问题。当然这说的是所使用技术的方向，技术的广度远远超过人的学习能范围，谁也不可能成为精通所有技术的全栈工程师。同时技术也在持续的发展，总有学不动的知识。
技术选型差。选择的技术在一定程度上决定了软件的质量。比如有那么多的ORM你不用，认为原生SQL执行更快，为了那一点效率让软件工程师天天拼SQL语句，最终只能导致软件Bug多，软件工程师的技能提升小，代码变更的难度大。尽量选择强类型的语言，编写出来的软件，能更早地发现软件bug，不用等到软件运行时功能异常才发现软件bug。
多个类、结构体、枚举放到同一个文件中。有人说把多个类型放在同一个文件内可以减少文件的数量，避免出现很多的文件只包含很少的内容。我只能笑笑:P，欲言又止。可能每个人的认知习惯有差异，对我来讲，我确信每一个对象的定义放一个文件是最好的做法。文件的名称应该和其中的对象定义的名称一致，不要是一头戴着羊头套的狗。