面对后者，你可以选择拒绝接受任务，但那会让人觉得你工作态度不好，以后好的差事可能就轮流不到你了;你可以选择走人，换个地方去做，但那也只能祷告，祈求上帝保佑你在别的地方遇到好任务。

其实这都不是好的做法，相反我们应该接受并搞掂它，应该想法转换它们，完成任务但又不必自虐，从中还能学到东西。下面是我的一些经验：

1、让电脑去做重复的工作

Unix文化有一个原则：宁愿花机器一分，不花程序员一秒。单调重复的工作多数都是有规律可循的，有规律可循就可以让电脑来做。

实例一：在早些年代，那时还没有听说autobuild这个概念，发布版本是一件痛苦事情。你要从CVS上取出源代码，编译各个版本((英文版, 日文版) x(大企业版, 小企业版, 试用版))，再制定各个版本的安装包，最后上传到FTP服务器上。

如果整个过程顺利，四个小时差不多了，但事实是从来没有顺利过，结果通常要花费两三天才能完成。编译出错，手工拷贝文件出错，上传时放错目录如此等等。那位负责做版本的大姐还算有耐心，坚持做了大半年时间，后来这事没费多大劲就推到我头上了(呵，大家都认为我好欺负)。

我接手后，第一件事是花了两天用bash写了个脚本，把整个过程自动化了，在接下来一个版本中进行了验证，并修正几个脚本里的问题，后来发布版本时几乎不用人干预了。

实例二：如果有人问我写得最多的程序是什么。我一定会回答是代码产生器，前前后后、大大小小至少写过十几个代码产生器，小的可能是用bash+awk来做的，也就上百行代码，大的用C/C++来写，动则数千行代码，最大的竟达8000多行C++代码。

大部分代码产生器都为我节省了不少时间，或者至少把单调重复的事情变得有趣一点了，而且得到的代码也更稳定可靠。

2、换种思路，看有没有捷径

有些事情单调重复，本来也是可以让电脑去做的，但是开发相应的工具要费更多的时间，得不偿失，这时不换一种思路，或许别有洞天。

实例一：曾接到一个任务，要求找出一个公共函数库里的所有全局变量。那个库是个大杂烩，里面什么东西都有，凌乱而庞大。时间期限是一周，时间比较充足，即使一个文件一个文件的去找，时间也来得及，但那太痛苦了。

更麻烦的是这个库是变化的，可能刚刚完成任务，又有人加了一个全局变量，这样就很难拿到一个最新的结果。怎么呢，我想，编译器肯定是知道哪些是全局变量的，所以第一反应是拿一个开源的编译器修改一下，让编译器告诉我结果。

修改编译器可能也要一周时间，但利用它随时可以得到最新结果。有没有更简便的办法呢？猜想VC输出的map文件或许有些帮助，打开map文件一看，果然如此。让VC编译该库并输出map文件，取出全局变量列表，搞掂了。从接受任务到完成任务前后不到一个小时。

实例二：前几天，同事拿一个第三方库，编译时发现那个库是用带硬件浮点数的toolchain编译，而我们的toolchain用的是软浮点数。尽管反汇编出来，没有发现浮点指令，但编译器就是不让链接该库。我们的方案是，反汇编它再重新编译它。

但反汇编出来的格式与as的输入格式有些差异，要花不少时间去修改，修改之后发现还是编译不过去。最后，这个任务又落到我头上了。

我想既然没有用浮点指令，编译器不让编译可能是因为一个标志引起的，于是花了点时间去研究ELF(linux下的可执行文件格式)文件格式。果然是文件头中一个标志引起的，写了个小程序为该库加上这个标志位，编译就通过了。

3、换种心情，坦然接受

如果面对一项任务，你别无选择时，那就坦然接受它吧。然后想法说服自己，让自己有个好的心情，这样的任务总是要有人做才行。还可以告诉自己，一定要从中学到点东西，即使从中学不到技术，也要从中学会忍耐。

当我从QA组进入RD组时，我任务是把Win32程序移植到linux下。这个任务比较重要，但绝不是什么好任务，工作本身单调不说，别人还瞧不起。他们认为这都是很简单的，不用动脑子的体力活。

同组的同事很多都走了，新来的同事也呆不了多久。但我坚持下去了，移植的同时去研究那些代码，去研究Win32和linux在编程上的差异, 一年之后我成了少数几个了解整个系统架构的人，编程能力大有提高，对软件的可移植性也有了较深的理解。

原文链接：https://mp.weixin.qq.com/s/N24lI05POiShOqkbDXqJ2w