如果你是一个开发人员，你应该会写代码

去年我做了很多面试，在我的面试部分，我应该测试人们的思维方式，以及他们如何在白板上实现简单到中等的算法。我一开始的问题是:

假设可以使用函数4 *(1 - 1/3 + 1/5 - 1/7 +…)来估计圆周率，使用更多的项来获得更高的精度，编写一个计算圆周率的函数，其精度为小数点后5位。

这是一个应该让你思考的问题，但对于一个经验丰富的开发人员来说不应该是遥不可及的(它可以用大约10行c#来回答)。然而，我们的许多候选人(应该是中介机构预先筛选的)甚至无法开始回答这个问题，甚至无法解释他们将如何回答这个问题。所以过了一段时间，我开始问一些更简单的问题，比如:

给定圆的面积是π乘以半径的平方，写一个函数来计算圆的面积。

令人惊讶的是，超过一半的候选人不能用任何语言编写这个函数(我可以阅读大多数流行的语言，所以我让他们使用他们选择的任何语言，包括伪代码)。我们有“c#开发人员”，他们不能用c#编写这个函数。

我对此感到很惊讶。我一直认为开发人员应该会写代码。现在看来，这似乎是一个有争议的观点。当然是在面试中!

编辑:

在评论中有很多关于第一个问题是好是坏的讨论，以及你是否应该在面试中问这么复杂的问题。我不打算在这里深入研究这个问题(这是一个全新的问题)，除了说你在很大程度上错过了文章的重点。

是的，我说过人们在这个问题上无法取得任何进展，但第二个问题很琐碎，许多人在这个问题上也无法取得任何进展!任何自称为开发人员的人都应该能够不假思索地在几秒钟内写出第二个问题的答案。很多人做不到。

PHP太烂了;-)

见分晓。

编程挣钱通常是对男人时间最糟糕的利用之一。

首先，你是在和埃尔博尼亚人竞争，他们每天只挣25美分。你需要说服你的雇主，你能提供埃尔博尼亚人永远无法提供的东西，而且你的东西值得一份体面的薪水。随着埃尔博尼亚人获得越来越多的海外业务，真正的优势逐渐消失，管理层也明白这一点。

另一方面，你是在花时间解决别人的问题。这些时间你可以用来发展自己的兴趣，或者解决你真正感兴趣的问题。如果你认为解决别人的问题就能拯救世界，那你为什么不让埃尔博尼亚人为你解决问题呢?

最后，软件领域的伟大创新(visicalc、Napster、Pascal等)不是由小隔间农场创造的。它们是由一两个没有预支工资的人创建的。你不能强行重建它。当一个有能力的程序员有一个非常好的想法时，这就是奇迹。

有足够的软件。有足够多的软件开发人员。你不需要被雇佣。节省你的才华，你的时间，你的头发，你的婚姻。让别人把灵魂出卖给键盘吧。如果你想编程，没问题。但不是为了钱。

那些不在业余时间编写代码取乐的程序员永远不会像那些在业余时间编写代码的程序员一样优秀。

我认为即使是最聪明和最有才华的人也永远不会成为真正优秀的程序员，除非他们不只是把编程当成一份工作。这意味着他们在业余时间做一些小项目，或者只是在业余时间摆弄各种不同的语言和想法。

(注意:我并不是说优秀的程序员除了编程什么都不做，而是说他们比朝九晚五的编程做得更多)

代码布局很重要

也许双括号位置的细节应该保持纯粹的宗教争论-但这并不意味着所有的布局风格都是平等的，或者根本没有客观因素!

问题在于布局的超级规则，即:“保持一致”，尽管听起来不错，但被许多人用作拐杖，从不尝试看看他们的默认风格是否可以改进——而且，这甚至无关紧要。

几年前，我正在学习快速阅读技术，我学到的一些东西是关于眼睛如何在“固定”中获取信息，如何最优地扫描页面，以及潜意识中拾取上下文的作用，这让我思考如何将其应用到代码中——尤其是在编写代码时牢记它。

它使我形成了一种本质上倾向于柱状的样式，在可能的情况下对标识符进行逻辑分组和对齐(特别是我严格要求每个方法参数都在自己的行上)。然而，与一成不变的长柱结构相比，以块为单位改变结构实际上是有益的，这样你最终会得到眼睛可以在一个固定装置中接受的矩形岛屿——即使你没有有意识地阅读每个字符。

最终的结果是，一旦你习惯了它(通常需要1-3天)，它就会变得赏心悦目，更容易理解，对眼睛和大脑的负担也更少，因为它的布局方式更容易接受。

几乎无一例外，我邀请的每个尝试这种风格的人(包括我自己)一开始都说，“啊，我讨厌它!”，但过了一两天就说，“我喜欢它——我发现很难不回头用这种方式重写我所有的旧东西!”

我一直希望有时间做更多的对照实验，以收集足够的证据来写一篇论文，但一直忙于其他事情。然而，这似乎是一个向那些对有争议的技术感兴趣的人提及它的好机会:-)

(编辑)

我终于抽出时间把这件事写在博客上(在“意义”阶段停留了很多年之后):第一部分，第二部分，第三部分。

Requirements analysis, specification, design, and documentation will almost never fit into a "template." You are 100% of the time better off by starting with a blank document and beginning to type with a view of "I will explain this in such a way that if I were dead and someone else read this document, they would know everything that I know and see and understand now" and then organizing from there, letting section headings and such develop naturally and fit the task you are specifying, rather than being constrained to some business or school's idea of what your document should look like. If you have to do a diagram, rather than using somebody's formal and incomprehensible system, you're often better off just drawing a diagram that makes sense, with a clear legend, which actually specifies the system you are trying to specify and communicates the information that the developer on the other end (often you, after a few years) needs to receive.

[如果有必要，一旦您编写了真正的文档，您通常可以把它塞进组织强加给您的任何模板中。不过，你可能会发现自己不得不添加章节标题和重复的材料。

The only time templates for these kinds of documents make sense is when you have a large number of tasks which are very similar in nature, differing only in details. "Write a program to allow single-use remote login access through this modem bank, driving the terminal connection nexus with C-Kermit," "Produce a historical trend and forecast report for capacity usage," "Use this library to give all reports the ability to be faxed," "Fix this code for the year 2000 problem," and "Add database triggers to this table to populate a software product provided for us by a third-party vendor" can not all be described by the same template, no matter what people may think. And for the record, the requirements and design diagramming techniques that my college classes attempted to teach me and my classmates could not be used to specify a simple calculator program (and everyone knew it).