Beautiful Code and Beautiful Software

原文作者：violasong
译者：legendsland

 

Programming was fun because I could make cool stuff, but what actually got me obsessed about it was suddenly seeing something interesting in the semantics and syntactics of the very lines of code. Being sensitive to the difference between good and bad code was intensely motivating, and discovering ways to write efficient, self-documenting, and thoughtfully-organized code was something I knew could captivate me forever. This is what I loved (and still love) about my field—the art of programming, the wonderfully complex craft that could take a lifetime to master.

As I added to my Ruby knowledge Java and then Objective-C, I began appreciating software development at a lower level. I grew up in an environment (the Rails community) where there was a lot of hate for those big verbose languages, but upon actually experiencing them for the first time myself, I discovered that I enjoyed them. They were different, but still interesting in differing ways. And hey, there was something satisfying and clarifying about writing dumb code after being born in high-level land—my first for-loop in Java, for example, helped me better appreciate the cleaner, object-oriented practices I knew, but I also saw something appealing in the for-loop itself. It wasn't just elegant language that intrigued me, it was also the basic logic behind the syntax, and the fact of differing syntax. Computer language, and differences in computer languages, were fascinating in and of themselves.

I had the same satisfying feeling when I first learned Assembly in college this term. Assembly was tedious and sometimes quite painful, but the way it made me think about basic programatic functions in such new ways was completely worth the pain. Of course, I also got a geeky pleasure just from being aware of the low-levelness of the code I was writing.

It gets worse! I had a great moment of self-discovery when I read Wolf's Programmers Don't Like to Code early this year. I indeed love the problem solving, elegance-creating, coding-to-learn part of coding, but I realized that I actually like coding for coding's sake, too. At least, that's how I describe my enjoyment of CSS and XHTML. I have an extensive enough grasp of front-end programming that I don't often solve a new problem these days (in fact, problems that take me a while or bugs I haven't seen before can be downright thrilling). Yet, I still enjoy working with the stuff. There's something relaxing about dumping out good-looking code that I understand very well, sort of like how I enjoy doodling the same cartoon cat over and over in my class notes, or how I enjoy playing the same three tunes when I sit at a piano. Even just looking at good CSS—well ok, my CSS, with everything ordered, indented, and cascading correctly—feels good in the same way that I felt bad, almost physically ill, as I waded around in the stylesheets of a certain forum software and found inconsistent indentation, extra line breaks, commented-out junk styles, and styles disabled by deliberately misspelling the property name.

This is what happens when you're so easily inspired, interesting shadows on the walls motivate you to continue living. You have to come back in once in a while and reorganize your levels of sensitivity so that your appreciation for light and sound is appropriately proportional to your appreciation for Off-Off-Broadway.

That is to say, these days I've been thinking a lot about the software part of software development. Specifically, the design of user interfaces in software. At BARcamp this year, I liked how Aza Raskin asked all developers to raise their hands, then all designers, later saying that the hands that went up the first time should have stayed up. All developers should be designers. At least, that's true for all developers lucky enough to work jobs where they have a say in the design of their software.

I'm getting increasingly excited about the importance of design within development, especially as I come to terms with my different passions and reflect over some of my past gigs. In the web app contracting world, design and development are usually separate jobs. In some cases, the design job is minimized in comparison to the rest of the project because clients generally pay for features, not for beautifully thoughtful design. On a project where I played both design and development roles, I recall feeling uncomfortable because I was assigned only two days to complete the visual design. It needed a lot more than two days. It was a complicated application that deserved weeks of rigorous iteration and conversations with the client. Unfortunately, that's not what the client was paying us for. The client was perfectly fine with the version-one mockup that took me a couple hours, and well, we had an app to launch.

I had another wake up call while I was at C4 this year. It appears that many Mac developers, perhaps most of them, are solo indies producing their own products. As such, they really do have to be both designers and developers. Actually, design is often the most significant part, and there seems to be a lot more enthusiasm over user experience and just producing a great product than there is over the code itself. One night during C4, someone inadvertently helped me see this when he described to me the nature of his work: "Coding the basic functionality is the easy part. That just take a couple weeks. What's really hard and time consuming is figuring out the specifics of the UI."

Wow, I thought. Why does that seem so right? Why is that so cool to me?! Oh, right, I'm a designer to begin with. There are dramatic rifts between my enjoyment of development, design, and art because I appreciate each of them in very different ways. I constantly try to integrate development and art, but I really ought to figure out how to mix all three.

After all, my goodness! Do we want beautiful code, or beautiful software? Here's another peek into my life: A side effect of being extremely open minded and absorbent is that I find myself believing all kinds of contradictory ideas, sometimes even opposite ones. It doesn't bother me right now because I'm in exploratory mode, not know-what-I-believe mode, but to retain sanity it is, of course, a must to occasionally sort things through until they make some kind of sense.

Thus, for further consideration I've listed just a fraction of the many things people like about software development, loosely ordered from the most intrinsic rewards to the most extrinsic rewards. I've left out a lot of really wonderful stuff like community, open source values, and challenges because those are harder to fit into this order, but I think you'll get the point. This is an extremely interesting sort order to me because of how psychologists say that intrinsic motivations are stronger and more likely to keep you going. For example, the person who takes karate classes because she feels energized and excited by the sensation of punching and kicking will more likely end up with a black belt than the person who takes the same classes for the health benefits.

Is it the same for programming?

The sensation of writing code
The knowledge that one is writing code
Enjoying computer logic
Enjoying computer language
Elegant syntax
Elegant semantics
Learning about code
Problem solving
Learning about problems
Achieving usability
Finishing a product
Elegant software
Solving human problems
Solving business problems
Satisfying market needs
Making money
Having a stable career
Which is the most persistently motivating kind of reward? Most importantly, which kind of motivation produces the best software? I'd love to do some formal research on this topic sometime, but I'm already pretty sure that the answer is "a healthy balance of most of the items on this list," as we certainly want our software to be both usable and maintainable, and sellable, and everything else. I'm also pretty sure that the balance is different for every situation and person. At the moment, however, I envision a wide bell-shaped curve sitting upon a rectangle, and everything turned on its side—the motivations that result in the best software are the ones nearer to the middle of the curve; but really, I think all of the motivations are beneficial in some way, and insofar as the programmer has her priorities straight, the more the better.

The tragedy of our field is that most programmers don't ever get to appreciate the majority of these rewards, particularly the more profound ones. Then again, it works out great because the majority of programming jobs couldn't possibly satisfy someone who cared about all these things. Still, I wonder what the industry would be like if we were all intrinsically, thoroughly passionate about our craft, and nobody was signing up for Computer Science classes just for the "stable career." I wonder what it would do to the world.

I think I should revisit this train of thought every year or so as I become a better software developer. I get the feeling, though, that my fate is already somewhat set in the fact that the more I grow, the more I desire a working situation where I have enough freedom to create beautiful things. It's probably worth noting that both freedom and beauty are vague, subjective ideas, so that could mean anything. All I know is that the compromises to both beauty in code and beauty in software design as necessitated in most programming jobs give me an unwavering feeling of discontent. I wouldn't be surprised if I ended up settling down as a freewheeling solo developer using, you know, web design contracting to support my freewheeling solo lifestyle.

Eventually I'll retire my computers and spend the rest of my days plein air painting on some beautiful farm out in the country. That, or a sensuous city life of alternating between street art missions and serving time. It's fun to imagine where I'll go once I feel done with technology. Hopefully that never happens, because I want to be the cool guru grandma who's still around when her children are giving mandatory programming lessons to their children.

**********************************************************************

************************************************************************

 

编程很有意思是因为我可以做一些很酷的东西，但是实际上让我着迷的却是那一行行代码的语法和语义。保持对好代码和坏代码之间差异的敏感相当激励人，同时，去寻找编写高效、自文档化和经过深思熟虑良好组织的代码的方法将会永远吸引着我。这便是我对所在领域钟爱的原因编程的艺术，这种奇妙的复杂物将会让你花费一生的时间去成为大师。

续Ruby之后，我学习了Java和Objective-C，我开始享受到底层软件开发的乐趣。我是在一个讨厌繁缛语言开发的社区（Rails社区）成长起来的，但是当我第一次接触这类语言之后，发现我喜欢上了它们。它们（和Ruby比较起来）是不同的语言，但仍然具有它们特有的乐趣。以Java 里面的for循环为例，当以我的高级程序语言的背景，编写了一些这样的基础代码后，发现这种代码可以更好地帮助我理解面向对象的一些实践，但同时我也对 for循环本身也产生了兴趣。这不仅仅是优美的语言吸引了我，也是语法背后的逻辑和不同语法形式让我着迷。计算机语言，以及它们之间的差异，本身就极具魅力。

当这学期我在学校学汇编语言的时候，获得了相同的满足感。汇编很繁琐，有时相当痛苦，但是让我去思考使用这种新的方式去实现基本的程序功能，跟痛苦相比，是完全值得的。当然，意识到自己编写的代码如此底层，也让我享受到了奇客(Geek)的快感。

情况变得更糟了！在今年的早些时候，当我读到Wolf的程序员不喜欢编码时，我经历了一个很不错的自我发现过程。我确实是喜欢在编码过程中解决问题，进行优雅地创造，以及通过编码来学习，但实际上我意识到我也是喜欢编码而编码。至少，这就是我享受CSS和XHTML的方式。我拥有大量的Web前端开发经验，并且最近没怎么碰到新的问题（事实上，难搞的问题和我从没有见过的Bug会让我异常兴奋）。尽管如此，我仍然喜欢这些东西。比如，整理一下我完全理解的代码让它变得好看点，就像是在我的笔记本上重复地画一些卡通猫，或者是坐在钢琴前重复地弹三个相同的音调一样，这让我感到放松。甚至仅仅去阅读漂亮的CSS我自己写的CSS，上面每一样东西都整齐有序、缩进良好，并且进行了正确的层叠（CSS里面很重要的一种技术）而感到心情舒畅；相反，当我看到某些论坛的样式表里面混乱的缩进、多余的空行、被注掉的一些老代码，以及通过故意使用错误的属性名来屏蔽掉的样式的时候，我感到难受，就像是生病了一样。

当你可以如此轻易地被激起兴趣 ，就是上面这个结果。仅仅是墙上的影子就足够让你继续生活下去（看来，她对柏拉图很有兴趣）。你得不断地重新审视自己的敏感度，以便让你的声色品味与你口袋里的钞票相匹配。（你对代码或者软件的品味来自于你自己的能力水平）

这样来讲吧，这些天我一直在思考（整个）软件开发中的软件部分。特别是软件中的用户界面设计。今年在BARcamp，我喜欢Aza Raskin的一个实验，他让所有的开发人员举起手，然后是设计人员，接着他说那些第一次举手的人在第二次也应该举手。所有的开发人员必须是设计人员。至少，幸运的是，所有的开发人员在他们的工作中可以对软件设计发表自己的意见。

我越来越对软件开发中设计部分的重要性感到兴奋，尤其是当我反思我对过去所做的事情在不同方面的热情与心得的时候。在Web应用领域，开发和设计一般是分离的。有时候，设计部分的工作在项目中被最少化了，这是因为客户是为软件的特性买单，而不会为漂亮的设计付帐。在一个项目中，我同时扮演了开发和设计的角色，回想起来，我对只分配了两天时间来完成可视化的设计感到耿耿于怀。这决不是两天的事情。这是一个很复杂的应用软件，需要花上几周的时间与客户交流和迭代设计。不幸的是，客户并不会因此而买单。相反，客户对我花了几个小时的原型感到无比满意，就这样，我们有了这个产品的第一个版本。

在今年的C4上我有了另一次觉悟。好像很多Mac下的开发软件，可能他们中的大多数都在（私下）做自己的产品。这样，他们真的必须既是设计师又是开发人员。事实上，设计是最重要的部分，并且用户体验和制造了不起的产品看起来要比代码本身更具有热情。在C4的一个晚上，有人在向我描述他的工作的时候，无意中帮助我看到了这一点：编码这个基本要素是最容易的部分。那仅仅需要几周而已。真正困难和耗费时间的是搞定UI的规格。

哇噢，我在想，为什么这看起来如此正确？为什么对我而言是这么的酷？哦，是的，那是因为我是从设计人员开始的。我享受开发、设计和艺术的方式绝然不同，这就导致了这三种享受之间巨大的差别。我一直在尝试整合开发和艺术（这两个方面），但是我其实应该整合这三个方面。

毕竟，我的天啊！我们想要漂亮的代码或者是漂亮的软件吗？我生活中的另一个观点是：由于我的思想极具开放性和强吸收性，我发现我自己可以接受各种相互矛盾的观点，有时候甚至是相反的观点。这种问题目前不会困扰我，因为我正处在探索模式的阶段，而不是在只接受我所相信的阶段，但是，当然啦，为了保持我思想自身的一致性，当它们有点头绪的时候必须要好好的整理一下。

所以，为了后续的考虑，我按照软件开发给人们带来的由内之外的收获，简单地列出了这个清单。我没有选择其他一些极好的价值，比如社区、开源和挑战等等，是因为这些都很难按顺序列到里面去，不过我相信你可以领会到其中的要点。这个顺序对我而言是极度重要的，因为心理学家讲过，内因的力量更为强大，更能让你坚持。比如，一个为了想从击打和踢腿中感觉到力量和兴奋而参加空手道训练的人，肯定要比仅仅为了健康的人更容易达到黑段水平。

编程也是如此吗？

* 代码感（译者：还记得圣斗士里面的第六感吗？）
* 编码的知识
* 享受计算机逻辑
* 享受计算机语言
* 优雅的语法
* 优美的语义
* 学习代码
* 问题求解
* 了解问题
* 获得可用性
* 完成一个产品
* 优雅的软件
* 解决人的问题
* 解决商业的问题
* 满足市场需求
* 赚钱
* 有一个稳定的职业

哪个是最能持续激励人的收获？更重要的是，哪种动机可以制造出最好的软件？有时候我很想在这个话题上做一个很正式的研究，当我们希望软件既满足可用，又具备可维护性，同时还叫买，而且还要满足一些其他的目标的时候，我很确信这个答案就是清单上面各种条目之间健康的平衡。我同时还很确信这种平衡性是因情况和人而异的。现在，我已经勾画出了一条钟形曲线（正态分布），那些可以促成最佳的软件的动机位于曲线的中间部分；但是，我想实际上所有的动机在某些方面都是有益的，并且当程序员有她自己的优先级的时候，动机自然是越多越好。

我们领域的悲哀在于大多数程序员并不会欣赏上面大部分的收获，尤其是那些更为重要的。这个清单很有用，因为大多数编程的工作无法满足那些关心所有这些事情的人。同样地，我很好奇，如果我们每个人都从内心关心我们做的东西，并且不会有人为了稳定的工作而去选择计算机科学者个专业，那么这个（软件）领域将会成为什么样子呢？我好奇这样会对整个世界产生什么影响？

我想我每年都应该反思一下这种问题，以便成为一个更好的软件开发人员。尽管如此，我还是觉得我的信念已经固定下来了：越是成长，就越希望能够在一个足够自由的环境里面创造美妙的东西。值得注意的是，美妙和自由都是模糊和主观的概念，可以任意地去理解。我只知道，在大多数的编程工作中对代码之美和软件设计之美的妥协永远会让我感到不满。如果到最后，我选择成为一个自由开发者去做Web设计，以满足这种自我的生活风格，我不会对此感到意外。

最终我会从计算机上面退休，并且用我剩下的时间在国外美丽的农场里面画画。或者是，过上在街头涂涂抹抹和牢房之间互动的感性城市生活。想象一下，当我觉和技术玩完了的时候，接下来要去哪里将是很有趣的。但愿永远不要发生这种事情，因为我希望成为一个酷酷的guru奶奶，到时候给孩子们上一些编程的必修课呢！