万圣节 数据

Warning: the following article will strike fear into the hearts of programmers everywhere. It may be Halloween, but it’s terrifying to realize these issues can crop up at any time of year. Turn back before it’s too late …

警告：下一篇文章会使世界各地程序员的内心恐惧。 也许是在万圣节那天，但是意识到这些问题可能在一年中的任何时候出现都令人恐惧。 在为时已晚之前回头……

1.估计厌恶 (1. Estimation Aversion)

Time estimation is hard. Even if you adequately divide a project into tiny constituent parts, it’s difficult to accurately predict how long a task will take if you’ve never done it before. Even if you’re confident, you’ll probably forget the impact of non-programming issues such as progress meetings, vacations, sick leave, documentation, etc.

时间估计很难。 即使您将项目充分地划分为多个小组成部分，也很难准确地预测如果您从未做过，那么任务将花费多长时间。 即使您有信心，也可能会忘记非编程问题的影响，例如进度会议，假期，病假，文件等。

Estimation is made worse by naive project managers who tie you down to those figures. Remind them that estimates are called “estimates” for a reason.

天真的项目经理将您限制在这些数字上，从而使估计变得更糟。 提醒他们，估计被称为“估计”是有原因的。

2.可疑的时间表 (2. Suspicious Schedules)

Projects must have clearly defined goals and time-lines or they can drift forever. Nothing can be ever considered “complete” but goals should be achievable and dates should be realistic. Even then, be prepared for slippage because things go wrong and it’s impossible to foresee all problems.

项目必须有明确定义的目标和时间表，否则它们可能会永远漂移。 没有什么可以被认为是“完整的”，但是目标应该是可以实现的，日期应该是现实的。 即使那样，也要为滑倒做好准备，因为事情出了问题，不可能预见所有问题。

Programmers are often blamed for release delays. It’s not necessarily your fault: bad management and a failure to plan is the cause.

经常因延迟发布而责怪程序员。 不一定是您的错：管理不善和计划失败是原因。

3.范围蠕变 (3. Scope Creeps)

Those who overcome estimation and scheduling woes can be faced with the scope creep; a dastardly character who insists on new features or total overhauls every few days. Nothing is ever good enough and the project veers uncontrollably from one rewrite to another. Good project management will help. Or simply ask the creep for a fully-documented specification — they’ll go mysteriously quiet.

那些克服估计和调度难题的人可能会遇到范围蔓延的问题； 每隔几天就要坚持要求新功能或全面检修的呆呆角色。 没有什么比这更好的了，该项目从一个重写到另一个变得不可控制。 良好的项目管理将有所帮助。 或只是索取蠕变以获得完整记录的规格-他们会神秘地安静下来。

4.工具震动 (4. Tool Tremors)

There’s one thing worse than not having the right tools for the job: being forced to use tool you hate. Perhaps you’re a PHP developer being moved into Java. Or a Gulp expert compelled to use Grunt. Or an Atom user obliged to use Eclipse.

比没有合适的工具来完成工作还糟糕的一件事是：被迫使用您讨厌的工具。 也许您是一名被Java迁移PHP开发人员。 或Gulp专家强迫使用Grunt。 或Atom用户必须使用Eclipse。

Be pragmatic and adopt the procedures and processes used by others in your team (unless you can convince them that migrating elsewhere is cost-effective). But having to use random tool or editor because “that’s what we use here” is soul-destroying. The solution? Don’t whine and use whatever you need. It’s easier to beg forgiveness than ask permission — and few will complain if you get the job done.

要务实，并采用团队中其他人所使用的程序和流程(除非您可以说服他们相信迁移到其他地方是具有成本效益的)。 但是必须使用随机工具或编辑器，因为“这就是我们在这里使用的”，真是万劫不复。 解决方案？ 不要抱怨并使用任何您需要的东西。 乞求宽容比征求许可要容易得多，而且如果您完成工作，很少有人会抱怨。

5.非技术同事的担忧 (5. Non-Technical Colleague Concerns)

Do you dread certain people coming to the office? They may be perfectly pleasant individuals but it becomes tiring having to explain the same technical issues every time they visit. They’ll want to know why IE8 isn’t showing rounded corners, why the application looks different on their ancient Blackberry, why their laptop is running slowly, why email wasn’t working at 10:52pm, why their browsing history is visible and how someone accessed their Facebook account.

你怕某些人来办公室吗？ 他们可能是非常愉快的个人，但每次访问时都必须解释相同的技术问题，这很累人。 他们想知道IE8为什么没有显示圆角，为什么在古老的Blackberry上应用程序看起来不一样，为什么笔记本电脑运行缓慢，为什么晚上10:52电子邮件无法正常工作，为什么浏览历史记录可见以及某人如何访问其Facebook帐户。

They won’t investigate themselves. They won’t Google. They’ll use you: their unofficial IT support lifeline. There are a number of options to consider. You could invoice them for your time? Or hide.

他们不会调查自己。 他们不会谷歌。 他们会使用您：他们非正式的IT支持生命线。 有许多选项可供考虑。 您可以为他们开具发票吗？ 或躲起来。

6.沮丧的设计师恐惧 (6. Frustrated Designer Fright)

Perhaps worse than non-technical colleagues are those “with an eye for UX”. The ones making this claim invariably never have those skills but it won’t stop them suggesting frivolous interface changes. Let’s move that button two pixels to the right? Let’s switch to purple — it’s an on-trend color. Let’s make it pop.

那些比“非专业的同事”更糟糕的是“关注UX”的同事。 提出这一主张的人总是不会拥有这些技能，但是这不会阻止他们暗示无聊的界面更改。 让我们将该按钮向右移动两个像素吗？ 让我们切换到紫色-这是一种流行的颜色。 让我们流行吧。

Fortunately, the frustrated designer quickly forgets their recommendations because they’re never documented and they change their mind frequently. Tell them their ideas will be implemented within a vague period and forget about it.

幸运的是，沮丧的设计师很快忘记了他们的建议，因为这些建议从未被记录在案，并且经常改变主意。 告诉他们，他们的想法将在一个模糊的时期内付诸实践，而忘记了。

7.“只是”抖动 (7. “Just” Jitters)

Fear the word “just”. It’s used to make sentences sound simple while introducing mind-numbingly complex functionality requiring a decade of intensive research, e.g.

害怕“正义”这个词。 它用于使句子听起来简单，同时引入需要数十年深入研究的令人难以置信的复杂功能，例如

• “Just make the free-text search better.”“只要使自由文本搜索更好。”
• “Just introduce some artificial intelligence.”“只介绍一些人工智能。”
• “Just allow users to talk to the application.”“只允许用户与应用程序对话。”

Education is your best option. Or perhaps nod thoughtfully and suggest an astronomical budget.

教育是您的最佳选择。 或若有所思地点头，并建议一个天文数字的预算。

8.“用不了多长时间”的担忧 (8. “It Won’t Take Long” Worries)

“Just” sentences are followed by this quote. It’s always made by someone with zero development experience and no knowledge of the project or its aims. Inevitably, the time taken to complete a feature is inversely proportional to their “estimate”.

引号后面是“仅”句子。 它总是由没有开发经验，对项目或其目标一无所知的人完成。 不可避免地，完成一项功能所花费的时间与它们的“估计”成反比。

Ignore imprecise statements. Time is relative; they may be thinking about one day’s implementation but you can presume whatever period you like.

忽略不精确的陈述。 时间是相对的； 他们可能正在考虑一天的实施，但是您可以假设自己喜欢的时间。

9.支持斗争 (9. Support Struggles)

Fixing bugs is easy. What’s difficult is working out what the problem is when faced with typical complaints such as “it doesn’t work”. Users will presume you’re a mystical entity who knows what OS they’re running, what software they’ve installed, what features they were using and what their screen looked like when they had a problem three weeks ago.

修复错误很容易。 困难的是要解决在遇到“不起作用”之类的典型投诉时出现的问题。 用户将假设您是一个神秘的实体，他们知道三周前遇到问题时，他们正在运行什么操作系统，已经安装了什么软件，正在使用什么功能以及屏幕看起来如何。

In their efforts to be helpful, the user won’t reveal what they were doing or the errors they encountered. It’s fun playing twenty questions only to discover they formatted their hard disk.

在努力提供帮助时，用户不会透露自己在做什么或遇到的错误。 播放二十个问题只是发现它们格式化了硬盘很有趣。

10.恐慌 (10. Screw-up Scares)

No one wants to screw up and some companies evolve an unhealthy blame culture. We’ve all done something stupid. We’ve all lost essential files or data. We’ve all regretted writing code in a particular way. It’s how we learn. Accept and admit to your mistakes — it’ll make you a better developer.

没有人愿意搞砸了，有些公司发展了一种不健康的责备文化。 我们都做了一些愚蠢的事情。 我们都丢失了必不可少的文件或数据。 我们都后悔以特定方式编写代码。 这就是我们学习的方式。 接受并接受您的错误-这将使您成为更好的开发人员。

11.无聊的负担 (11. Boredom Burdens)

We all want to work on cool stuff. We all want to remain interested. We all want to make a difference. But it doesn’t matter what you’re doing; boredom affects everyone regardless of their role. That said, if you’ve spent the past 25 years working on a COBOL-based tax assessment project, perhaps it’s time for a change of direction. You know what’s holding you back …

我们每个人都想研究很棒的东西。 我们都希望保持兴趣。 我们都希望有所作为。 但是，无论您在做什么，都没有关系。 无聊影响每个人，无论其角色如何。 就是说，如果您过去25年中一直在进行基于COBOL的税收评估项目，那么也许是时候改变方向了。 你知道是什么阻碍了你……

12.未知的厌恶 (12. The Uneasiness of the Unknown)

The previous sections can be summarized in a single statement: fear of the unknown. As a programmer, you’ll be placed in situations you’ve not experienced before. The work will be unfamiliar; you’ll never have used that technology or developed in that way.

前面的部分可以总结为一个声明： 对未知的恐惧 。 作为程序员，您将处于从未有过的情况中。 这项工作不熟悉； 您将永远不会使用该技术或以这种方式开发。

You have nothing to fear except fear itself. Embrace it: experience is good you may enjoy the change. You won’t know until you try …

除了恐惧本身，您没有什么可恐惧的。 拥抱它：经验是美好的，您可以享受改变。 除非尝试，否则您将不知道。

Have I missed your most troublesome terrors? What nightmares have you endured?

我想念你最麻烦的恐怖了吗？ 你经历了什么噩梦？

翻译自: https://www.sitepoint.com/12-scariest-developer-fears-halloween/

万圣节 数据