是否立即投入疯狂的工作中，要编出一个新的POP3客户与现存的那些竞争呢？才不是哪！我仔细考察了手头上的POP工具，问自己“那一个最接近我的需要？”因为：
2.好程序员知道该写什么，伟大的程序员知道该重写（和重用）什么。
我并没有声称自己是一个伟大的程序员，可是我试着效仿他们。伟大程序员的一个重要特点是建设性的懒惰。他们知道你是因为成绩而不是努力得到奖赏，而且从一个好的实际的解决方案开始总是要比从头干起容易。
例如，Linux并不是从头开始写Linux的。相反的它从重用Minix（一个386机型上的类似Unix的微型操作系统）的代码和思想入手。最后所有的Minix代码都消失或被彻底的重写了，但是当它们在的时候它为最终成为Linux的雏形做了铺垫。
秉承同样的精神，我去寻找良好编码的现成的POP工具，用来作为基础。
Unix世界中的代码共享传统一直对代码重用很友好（这正是为什么GNU计划不管Unix本身有多么保守而选取它作为基础操作系统的原因）。Linux世界把这个传统推向技术极限：它有几个T字节的源代码可以用。所以在Linux世界中花时间寻找其他几乎足够好的东西，会比在别处带来更好的结果。
这也适合我。加上我先前发现的，第二次寻找找到了9个候选者——fetchPOP，PopTart，getmail，gwpop，pimp，popperl，popc，popmail和upop）。我首先选定的是“fetchpop”。我加入了头标重写功能，并且做了一些被作者加入他的1.9版中的改进。
但是几个星期之后，我偶然发现了CarlHarris写的“popclient”的代码，然后发现有个问题，虽然fetchpop有一些好的原始思想(比如它的守护进程模式)，它只能处理pop3，而且编码的水平相当业余(SeungHong是个很聪明但是经验不足的程序员)，Carl的代码更好一些，相当专业和稳固，但他的程序缺少几个重要的相当容易实现的fetchpop的特征(包括我自己写的那些)。
继续呢还是换一个?如果换一个的话，作为得到一个更好开发基础的代价，我就要扔掉我已经有的那些代码。
换一个的一个实际的动机是支持多协议，pop3是用的最广的邮局协议，但并非唯一一个，Fetchpop和其余几个没有实现POP2.RPOP，或者APOP，而且我还有一个为了兴趣加入IMAP(InternetMessageAccessProtocol，最近设计的最强大的邮局协议)的模糊想法。
但是我有一个更加理论化的原因认为换一下会是一个好主意，这是我在Linux很久以前学到的：
3.“计划好抛弃，无论如何，你会的”(FredBrooks,《神秘的人月》第11章)
或者换句话说，你常常在第一次实现一个解决方案之后才能理解问题所在，第二次你也许才足够清楚怎样做好它，因此如果你想做好，准备好推翻重来至少一次。
好吧(我告诉自己)，对fetchpop的尝试是我第一次的尝试，因此我换了一下。
当我在1996年6月25日把我第一套popclient的补丁程序寄给CarlHarris之后，我发现一段时间以前他已经对popclient基本上失去了兴趣，这些代码有些陈旧，有一些次要的错误，我有许多修改要做，我们很快达成一致，我来接手这个程序。不知不觉的，这个计划扩大了，再也不是我原先打算的在已有的pop客户上加几个次要的补丁而已了，我得维护整个的工程，而且我脑袋里涌动着一些念头要引起一个大的变化。
在一个鼓励代码共享的软件文化里，这是一个工程进化的自然道路，我要指出：
4.如果你有正确的态度，有趣的问题会找上你的，但是CarlHarris的态度甚至更加重要，他理解：
5.当你对一个程序失去兴趣时，你最后的责任就是把它传给一个能干的后继者。
甚至没有商量，Carl和我知道我们有一个共同目标就是找到最好的解决方案，对我们来说唯一的问题是我能否证明我有一双坚强的手，他优雅而快速的写出了程序，我希望轮到我时我也能做到。
三.拥有用户的重要性
于是我继承了popclient，同样重要的是，我继承了popclient的用户基础，用户是你所拥有的极好的东西，不仅仅是因为他们显示了你正在满足需要，你做了正确的事情，如果加以适当的培养，他们可以成为合作开发者。
Unix传统另一有力之处是许多用户都是黑客，因为源优码是公开的，他们可以成为高效的黑客，这一点在Linux世界中也被推向了令人高兴的极致，这对缩短调试时间是极端重要的，在一点