Some years ago, I was working with another on a small "hobby" project, and I realised that we had to re-assess things. We had written lots of code but it wasn't all good code.
We didn't really want to "throw away" all the work we had put in. But I realised something: what mattered most was the amount of work we would need to put in from now on.
We couldn't change the fact that we had already put so much work into the project, so the only way to minimise the total amount of work the project would need, would be to minimise the amount of work we hadn't done yet.
Since that day, I have stopped being attached to my code. If I'm confident that throwing it away and starting from scratch means less work than keeping it and adapting it to my needs, then I'll throw it away.
My high school art teacher used to encourage us to take what we considered to be our best drawings and tear them up; he called this "cleansing the soul". His reasoning was that, as artists, we were driven to create works of art, and any time we produced something that we liked and that gave us satisfaction, our motivation to continue creating would be lessened.
So I followed his advice and tore up my best stuff, and it worked. Instead of spending my time admiring my old work, I created new stuff and continually got better. I've tried to follow the same principle with my code, but it doesn't really work: my computer has a tough plastic shell that is nearly impossible to tear through.
I've often thought that sucking less every year is how humble programmers improve. You should be unhappy with code you wrote a year ago. If you aren't, that means either A) you haven't learned anything in a year, B) your code can't be improved, or C) you never revisit old code. All of these are the kiss of death for software developers.
We sure like to admire our nice code, but it's not always easy to know what to admire. Complicated and elaborate code is sometimes mistaken for admirable code, while elegance and simplicity should rather be what to strive for.
Two quotes come to mind:
"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.”
-- Brian Kernighan
and
"Make everything as simple as possible, but not simpler."
Jonathan Edwards wrote an impressively beautiful essay on this subject, prompted by the work on the O'Reilly book Beautiful Code. Here's the final paragraph, but the rest of the essay is also worth reading.
Another lesson I have learned is to distrust beauty. It seems that infatuation with a design inevitably leads to heartbreak, as overlooked ugly realities intrude. Love is blind, but computers aren’t. A long term relationship – maintaining a system for years – teaches one to appreciate more domestic virtues, such as straightforwardness and conventionality. Beauty is an idealistic fantasy: what really matters is the quality of the never ending conversation between programmer and code, as each learns from and adapts to the other. Beauty is not a sufficient basis for a happy marriage.
Other versions of this same wisdom exist in other fields. Samuel Johnson, about writing:
Read over your compositions, and wherever you meet with a passage which you think is particularly fine, strike it out.
William Faulkner's version of this was much more succinct: “Kill your darlings.”
My father-in-law works as a film editor, and he studiously avoids the set where the film is being shot. When he does have to visit, he shields his eyes as much as he can. This is because when he decides whether or not to include a scene in the final film, he doesn't want to be influenced by how much effort it took to shoot the scene. What matters is how well the scene works in the final film.
My essay, "My evolution as a programmer" (which I would link to if I weren't a new user), is largely about learning skepticism about the code I'd written: whether it works, whether it's useful, whether it's comprehensible (pair programming was a real wake-up call here). It's hard!
I never admire my code. I admire other peoples code that i "borrow" and try and emulate them or better them and i find that the more i know, especially about coding the more i find i don't to know. The only thing of value wold be for peer programmers to admire my code and borrow it.
I think he has a good point. It's frustrating to work with people that have too much of this, as it really hinders teamwork and getting to the best solution to the problem.
As I can be a bit delusional, I try to put practices in place that will keep me grounded in reality. For code,
unit tests: These keep me more focused on what the code is supposed to do, as opposed to any abstract "beauty".
shared code ownership: There are two camps here: give people more ownership of their code and hope pride takes over, or give them less and let peer pressure come into play. I believe that giving people more ownership can lead to this code admiration. We practice shared code ownership, so I am constantly forced to see someone rewrite my perfect code to make it better (in their mind). I quickly realized admiring it too much was a waste of time and emotionally difficult.
pair programming: working side-by-side with someone will keep you realistic.
other feedback: These are all feedback loops, but there are others. There's no better way to see if something works than by watching someone (try to) use it. Put your work in front of as many people as possible. Have code reviews. Read other people's code. Run static code analysis tools.
I'm with PurplePilot - I don't admire my own code, and as such I'm constantly searching for new, more efficient (hell, easier) ways of doing the same thing. I like the Effective c# book, picked up lots of useful code from there that I admire.
I would have no hesitation about throwing code away and starting again, but not necessarily from scratch, i.e. by writing some code for a specific scenario and then throwing it away, you'll probably have a better grasp of the scenario. In other words, it's a "wicked problem", or you've found another way that doesn't work a la Edison.
It begs a wider question: if code isn't thrown away, or at least revisited, is developing on libraries that are becoming stagnant a good thing?
There is nothing wrong with admiring your code ... this is part of the positive reinforcement process that will motivate you to write more and better code in the future.
However, misplaced or misused admiration can be a problem. If the code is really not good, or has bugs that haven't been exposed by unit or other testing, or needs refactoring/redesign/replacement then this misplaced admiratoin is a problem. And using admiration as an excuse to skip part of the process - such as code reviews, or not having a skeptical attitude towards code - is misuse of admiration.
Like anything else that is good, admiration of code can be misplaced or misused - it doesn't mean that it in itself is bad. That would be like saying "religion is a bad thing, because it causes conflicts and wars between people".
It's perhaps better to have a healthier perspective - we aren't rocket scientists, and we aren't curing cancer - it's just work.
(Yes, it's reasonable to be proud of an entire building you helped build if you're an architect, but do they really have a lot of their self-esteem wrapped up in an individual blueprint, or a closet on floor 3 they designed by themselves?).
发布评论
评论（11）
几年前，我与另一个人一起从事一个小型“爱好”项目，我意识到我们必须重新评估事情。我们编写了很多代码，但并不都是好代码。
我们并不是真的想“扔掉”我们投入的所有工作。但我意识到一些事情：最重要的是我们从现在开始需要投入的工作量。
我们无法改变这样一个事实：我们已经在项目中投入了如此多的工作，因此最大限度地减少项目所需工作量的唯一方法就是最大限度地减少工作量我们还没有完成。
从那天起，我就不再执着于我的代码了。如果我确信扔掉它并从头开始比保留它并根据我的需要进行调整意味着更少的工作，那么我就会扔掉它。
Some years ago, I was working with another on a small "hobby" project, and I realised that we had to re-assess things. We had written lots of code but it wasn't all good code.
We didn't really want to "throw away" all the work we had put in. But I realised something: what mattered most was the amount of work we would need to put in from now on.
We couldn't change the fact that we had already put so much work into the project, so the only way to minimise the total amount of work the project would need, would be to minimise the amount of work we hadn't done yet.
Since that day, I have stopped being attached to my code. If I'm confident that throwing it away and starting from scratch means less work than keeping it and adapting it to my needs, then I'll throw it away.
我的高中美术老师曾经鼓励我们把我们认为最好的画撕掉；然后把它们撕掉。他称之为“净化灵魂”。他的理由是，作为艺术家，我们被驱使去创作艺术作品，每当我们创作出一些我们喜欢的、让我们满意的东西时，我们继续创作的动力就会减弱。
所以我听从了他的建议，撕毁了我最好的东西，结果奏效了。我没有花时间欣赏我的旧作品，而是创造了新的东西并不断变得更好。我试图在我的代码中遵循相同的原则，但它并没有真正起作用：我的计算机有一个坚韧的塑料外壳，几乎不可能撕破。
My high school art teacher used to encourage us to take what we considered to be our best drawings and tear them up; he called this "cleansing the soul". His reasoning was that, as artists, we were driven to create works of art, and any time we produced something that we liked and that gave us satisfaction, our motivation to continue creating would be lessened.
So I followed his advice and tore up my best stuff, and it worked. Instead of spending my time admiring my old work, I created new stuff and continually got better. I've tried to follow the same principle with my code, but it doesn't really work: my computer has a tough plastic shell that is nearly impossible to tear through.
我发布了来自 Jeff Atwood 博客的片段，每年吸得更少，并且我100%同意。
I post a fragment from Jeff Atwood's blog, Sucking Less Every Year, and I agree 100%.
我们确实喜欢欣赏我们优秀的代码，但知道欣赏什么并不总是那么容易。复杂而精巧的代码有时会被误认为是令人钦佩的代码，而优雅和简单才是我们应该努力的目标。
我想到两句话：
和
We sure like to admire our nice code, but it's not always easy to know what to admire. Complicated and elaborate code is sometimes mistaken for admirable code, while elegance and simplicity should rather be what to strive for.
Two quotes come to mind:
and
Jonathan Edwards 写了一篇令人印象深刻的美丽文章关于这个主题，是由 O'Reilly 的《Beautiful Code》一书的工作推动的。这是最后一段，但文章的其余部分也值得一读。
同样智慧的其他版本也存在于其他领域。塞缪尔·约翰逊关于写作：
威廉·福克纳的版本则更为简洁：“杀掉你的宝贝。”
我的岳父是一名电影剪辑师，他刻意避开电影拍摄的场景。当他必须去拜访时，他会尽可能地遮住眼睛。这是因为，当他决定是否在最终电影中加入某个场景时，他不想受到拍摄该场景所花费的努力的影响。重要的是最终电影中的场景效果如何。
我的文章“我作为程序员的演变”（如果我不是新用户，我会链接到它），主要是关于学习对我编写的代码的怀疑：它是否有效，是否有用，是否可理解（结对编程是一个真正的警钟）。很难！
Jonathan Edwards wrote an impressively beautiful essay on this subject, prompted by the work on the O'Reilly book Beautiful Code. Here's the final paragraph, but the rest of the essay is also worth reading.
Other versions of this same wisdom exist in other fields. Samuel Johnson, about writing:
William Faulkner's version of this was much more succinct: “Kill your darlings.”
My father-in-law works as a film editor, and he studiously avoids the set where the film is being shot. When he does have to visit, he shields his eyes as much as he can. This is because when he decides whether or not to include a scene in the final film, he doesn't want to be influenced by how much effort it took to shoot the scene. What matters is how well the scene works in the final film.
My essay, "My evolution as a programmer" (which I would link to if I weren't a new user), is largely about learning skepticism about the code I'd written: whether it works, whether it's useful, whether it's comprehensible (pair programming was a real wake-up call here). It's hard!
我从不欣赏我的代码。我很欣赏我“借用”的其他人的代码，并尝试模仿它们或改进它们，我发现我知道的越多，尤其是关于编码，我发现我不知道的就越多。唯一有价值的是让同行程序员欣赏我的代码并借用它。
I never admire my code. I admire other peoples code that i "borrow" and try and emulate them or better them and i find that the more i know, especially about coding the more i find i don't to know. The only thing of value wold be for peer programmers to admire my code and borrow it.
我认为他说的有道理。与有太多这种情况的人一起工作是令人沮丧的，因为它确实阻碍了团队合作和找到问题的最佳解决方案。
因为我可能有点妄想，所以我尝试采取一些实践，让我立足于现实。对于代码，
单元测试：这让我更加关注代码应该做什么，而不是任何抽象的“美感”。
共享代码所有权：这里有两个阵营：给予人们更多的代码所有权并希望自豪感占据上风，或者给予他们更少的所有权并让同伴压力发挥作用。我相信给予人们更多的所有权可以导致对这些代码的钦佩。我们实行共享代码所有权，因此我经常被迫看到有人重写我的完美代码以使其变得更好（在他们看来）。我很快意识到，过多地钦佩它是浪费时间，而且在情感上也很困难。
结对编程：与某人并肩工作会让你保持现实。
其他反馈：这些都是反馈循环，但还有其他反馈循环。要了解某个东西是否有效，没有比观察某人（尝试）使用它更好的方法了。将您的作品展示给尽可能多的人。有代码审查。阅读其他人的代码。运行静态代码分析工具。
I think he has a good point. It's frustrating to work with people that have too much of this, as it really hinders teamwork and getting to the best solution to the problem.
As I can be a bit delusional, I try to put practices in place that will keep me grounded in reality. For code,
unit tests: These keep me more focused on what the code is supposed to do, as opposed to any abstract "beauty".
shared code ownership: There are two camps here: give people more ownership of their code and hope pride takes over, or give them less and let peer pressure come into play. I believe that giving people more ownership can lead to this code admiration. We practice shared code ownership, so I am constantly forced to see someone rewrite my perfect code to make it better (in their mind). I quickly realized admiring it too much was a waste of time and emotionally difficult.
pair programming: working side-by-side with someone will keep you realistic.
other feedback: These are all feedback loops, but there are others. There's no better way to see if something works than by watching someone (try to) use it. Put your work in front of as many people as possible. Have code reviews. Read other people's code. Run static code analysis tools.
我使用 PurplePilot - 我不欣赏自己的代码，因此我不断寻找新的、更高效（更简单）的方法来完成同样的事情。我喜欢《Effective c#》这本书，从那里学到了很多我欣赏的有用代码。
我会毫不犹豫地扔掉代码并重新开始，但不一定从头开始，即通过为特定场景编写一些代码然后扔掉它，您可能会更好地掌握该场景。换句话说，这是一个“邪恶的问题”，或者你找到了另一种无法像爱迪生那样工作的方法。
它引出了一个更广泛的问题：如果代码没有被丢弃，或者至少被重新审视，那么在变得停滞不前的库上进行开发是一件好事吗？
I'm with PurplePilot - I don't admire my own code, and as such I'm constantly searching for new, more efficient (hell, easier) ways of doing the same thing. I like the Effective c# book, picked up lots of useful code from there that I admire.
I would have no hesitation about throwing code away and starting again, but not necessarily from scratch, i.e. by writing some code for a specific scenario and then throwing it away, you'll probably have a better grasp of the scenario. In other words, it's a "wicked problem", or you've found another way that doesn't work a la Edison.
It begs a wider question: if code isn't thrown away, or at least revisited, is developing on libraries that are becoming stagnant a good thing?
欣赏你的代码并没有什么错……这是积极强化过程的一部分，它将激励你在未来编写更多更好的代码。
然而，错位或误用钦佩可能是一个问题。如果代码确实不好，或者有单元或其他测试没有暴露的错误，或者需要重构/重新设计/替换，那么这个错位的钦佩就是一个问题。使用钦佩作为跳过部分流程的借口 - 例如代码审查或对代码不持怀疑态度 - 是对钦佩的滥用。
就像任何其他好的东西一样，对代码的钦佩可能会被放错地方或被误用——这并不意味着它本身就是坏的。这就像说“宗教是一件坏事，因为它会引起人与人之间的冲突和战争”。
There is nothing wrong with admiring your code ... this is part of the positive reinforcement process that will motivate you to write more and better code in the future.
However, misplaced or misused admiration can be a problem. If the code is really not good, or has bugs that haven't been exposed by unit or other testing, or needs refactoring/redesign/replacement then this misplaced admiratoin is a problem. And using admiration as an excuse to skip part of the process - such as code reviews, or not having a skeptical attitude towards code - is misuse of admiration.
Like anything else that is good, admiration of code can be misplaced or misused - it doesn't mean that it in itself is bad. That would be like saying "religion is a bad thing, because it causes conflicts and wars between people".
两个词：代码审查。
聚集两个或更多的开发人员，并邀请他们对您的代码进行审查/批评/评论。 'twill 对你的代码提供了一些（诚然是严厉的）启发。
Two words: code review.
Gather two or more fellow developers and invite them to review/criticize/comment on your code. 'twill shed some (admittedly harsh) light on your code.
也许拥有更健康的视角会更好——我们不是火箭科学家，我们也不是在治愈癌症——这只是工作。
（是的，如果你是一名建筑师，为你帮助建造的整栋建筑感到自豪是合理的，但他们真的有很多自尊包裹在个人蓝图中，或者他们设计的三楼壁橱中吗？他们自己？）。
It's perhaps better to have a healthier perspective - we aren't rocket scientists, and we aren't curing cancer - it's just work.
(Yes, it's reasonable to be proud of an entire building you helped build if you're an architect, but do they really have a lot of their self-esteem wrapped up in an individual blueprint, or a closet on floor 3 they designed by themselves?).