员工讨厌行为管理软件_我讨厌软件工程师

员工讨厌行为管理软件

Meddy’s business grew massively over the last few years; our main metrics grew across the board. This meant that our engineering, operations, sales and marketing all had to grow to match the new demand.

在过去的几年中，Meddy的业务得到了巨大的发展。 我们的主要指标全面增长。 这意味着我们的工程，运营，销售和市场营销都必须增长以适应新的需求。

To be able to build the engineering team, I read 1000s of resumes and conducted 100s of interviews over the last few years. Hiring a frontend engineer was especially excruciating. One of the interviews in specific was so bad that it was almost like satire. The pinnacle of absurdity from this interview was the following interaction:

为了组建工程团队，在过去几年中，我阅读了1000份简历，并进行了100份采访。 雇用一名前端工程师尤其令人发指。 具体来说，其中一次采访是如此糟糕，以至于几乎就像是讽刺。 这次采访的荒谬之处在于以下互动：

“How do you feel about working on AngularJS?”

“您对使用AngularJS的感觉如何？”

“I’ll be honest, if I was offered a job with a company that is working on VueJS, I’d go with their offer.” 🤨🤨🤨

“说实话，如果我被一家从事VueJS工作的公司提供工作，我会接受他们的提议。” 🤨🤨🤨

I admire his honesty 😅, but I gave him some harsh feedback nonetheless. In that feedback I relayed how disappointed I was even though I didn’t know him. From what I’ve seen, his attitude was an accurate reflection of the egotistical attitude of the industry as a whole.

我很欣赏他的诚实😅，但是我还是给了他一些苛刻的反馈。 即使我不认识他，在反馈中我仍然感到非常失望。 从我所见，他的态度准确反映了整个行业的自我态度。

Engineers want to work in an ideal environment with bleeding edge tools solving complicated problems. They want to model controlled environments and provide perfect solutions. They want to develop perfectly pleated code and starch the edges, when clearly the problems of the real world are ragged and dirty. They wouldn’t even deign to touch an old framework.

工程师希望在理想的环境中使用一流的工具来解决复杂的问题。 他们希望对受控环境进行建模并提供完善的解决方案。 当明显的现实世界问题参差不齐时，他们希望开发出完美的打褶代码并为边缘添加淀粉。 他们甚至都不愿尝试使用旧框架。

What is surprising is how global this pandemic is. If you ask any product manager or technical lead what they hate the most about working with software engineers, in any country, there is a high probability they would say the same thing. I have, in fact, done exactly that. I asked 7 product managers and 3 technical leads from 5 different countries what they hated about working with their engineers and the answer I got was consistent with my own.

令人惊讶的是这种流行病的全球范围。 如果您问任何产品经理或技术负责人，他们最讨厌与任何国家的软件工程师合作，那么他们说同一句话的可能性就很高。 实际上，我确实做到了。 我问了来自5个不同国家/地区的7位产品经理和3位技术主管，他们讨厌与工程师合作，我得到的答案与我自己的一致。

Engineers do not focus on the bigger picture

工程师并不专注于大局

After more reflection on the detrimental effects of this tunnel vision I’ve come to realize that it produces engineers that don’t know what their role in a company is, don’t focus on delivering value, have an aversion to ugly solutions, and are easily seduced by perfect solutions.

在对这种隧道愿景的有害影响进行了更多的思考之后，我逐渐意识到，它产生的工程师不知道他们在公司中的角色是什么，不专注于提供价值，不愿接受丑陋的解决方案，以及容易被完美的解决方案所吸引。

In this article, I will be delving into each one of these points and give advice to eradicate the effects of this tunnel-vision. If you’re a software engineer this advice will help improve your career more than a computer science book would (don’t tell my professors I said that 🤫)!

在本文中，我将深入研究这些要点，并提供一些建议，以消除这种隧道视觉的影响。 如果您是软件工程师，此建议将比一本计算机科学书籍更有助于改善您的职业(不要告诉我的教授我这么说🤫)！

Note: This is an opinion piece. This advice is directed mainly towards engineers working in product-first companies. In engineering-first companies priorities are different.

注意：这是一个观点。 该建议主要针对在产品优先公司工作的工程师。 在工程优先公司中，优先级有所不同。

您在公司中的角色 (Your Role in a Company)

In order to get rid of tunnel-vision you first need to contextualize what you’re doing in a company. If you say your role in a company is to be a “programmer” then I can immediately tell that you don’t know what the hell you’re doing. Your role in the company is very much tied to the value you’re delivering.

为了摆脱隧道视觉，您首先需要将您在公司中所做的工作与环境联系起来。 如果您说您在公司中的角色是成为“程序员”，那么我可以立即告诉您，您不知道自己在做什么。 您在公司中的角色与您所提供的价值密切相关。

Coding, like most things, is just a tool used to reach an objective. For things to matter to us as human beings, they need to be visceral and tangible. For that, you need to have a purpose behind doing what you’re doing, and that is usually what people ask about. If you ask a person that’s eating food what they’re doing and they say “chewing” you’d think they’re insane! Technically they’re right, but what they’re doing is “eating”. What matters here isn’t what they’re doing, but the purpose they’re doing it.

像大多数事物一样，编码只是用于达成目标的工具。 为了让事情对于我们人类来说至关重要，它们必须是内在的和切实的。 为此，您需要在做自己要做的事情后有一个目的，而这通常是人们所要求的。 如果您问一个正在吃食物的人在​​做什么，而他们说“咀嚼”，您会认为他们疯了！ 从技术上讲，他们是对的，但他们正在做的是“饮食”。 这里重要的不是他们在做什么，而是他们在做什么的目的。

Your job in a company isn’t to code, your job rather is to deliver value to your users/clients. You’re hired for your skill of coding, but that doesn’t make you a coder, rather a team member who happens to know how to code.

您在公司的工作不是编码，而是为用户/客户创造价值。 您是因为编码技能而被录用的，但这并不能使您成为编码人员，而是使您碰巧知道如何编码的团队成员。

An engineer is simply a team member that knows how to code

工程师只是知道如何编码的团队成员

You might not think that this point is worth dwelling on, but I don’t think it’s so obvious. It’s in our culture that engineers measure each other’s value by the complexity or size of their software and deride each other if their work isn’t complex enough. In fact, it makes for some good hilarity.

您可能不认为这一点值得继续讨论，但我认为它并不那么明显。 在我们的文化中，工程师通过软件的复杂性或大小来衡量彼此的价值，并且如果他们的工作不够复杂，则会互相嘲笑。 实际上，这带来了很好的欢笑。

Funny because it’s true

有趣，因为它是真的

I’m not criticizing the humor that comes from this derision, I actually enjoy it very much. But humor imitates our reality, otherwise we wouldn’t find it funny. What I am criticizing is our belief of what value is in this industry.

我不是在批评这种嘲笑所带来的幽默，我实际上非常喜欢它。 但是幽默模仿了我们的现实，否则我们不会觉得它很有趣。 我所批评是我们的价值是什么在这个行业的信念。

Value in our industry, like any other industry, comes from achievement. Richard Stallman is a Harvard and MIT alum but he’s not well known for any of the code he built but rather for the contributions he’s done to the free software movement. Yet he’s regarded as one of the most influential Computer Scientists in America.

与其他任何行业一样，我们行业的价值来自成就。 理查德•斯托曼( Richard Stallman)是哈佛大学和麻省理工学院的校友，但是他所构建的任何代码都不为人所知，而是他对自由软件运动的贡献。 然而，他却被认为是美国最有影响力的计算机科学家之一。

Similarly, early engineers of successful companies are more sought after, even though at the early points of those companies their work was probably not very complex. This is because the value of the product is proportional to your own value as an engineer.

同样，成功公司的早期工程师更受追捧，即使在这些公司的早期，他们的工作可能并不十分复杂。 这是因为产品的价值与您作为工程师的价值成正比。

Value isn’t code complexity its value delivered to users

价值不是代码复杂性，价值是传递给用户的价值

Thus, it’s important to think of your role past the code itself and rather what you’re delivering. This distinction will help you focus on what’s most important: value delivered.

因此，重要的是要考虑代码本身之外的角色，而不是要交付的内容。 这种区别将帮助您专注于最重要的：交付的价值。

注重价值 (Focus on Value)

Focusing on delivering value will help you make better decisions during your development. Having a focus means that you move fast and work on problems that matter. Working on problems that matter at a fast pace is vital for companies to thrive, and happens to be the best antidote for code-induced insanity.

专注于创造价值将帮助您在开发过程中做出更好的决策。 专心致志意味着您可以快速行动并解决重要问题。 快速解决重要问题对于公司的发展至关重要，并且恰好是代码引起的精神错乱的最佳解药。

Note: The reason I’m saying focus on value delivered rather than output is because measuring output is rather difficult in software; software is intractable. It’s much easier to measure the impact of your code by pegging it to the impact of the product.

注意：之所以要讲的是专注于交付的价值而不是输出，是因为在软件中测量输出相当困难。 软件很难处理。 通过将代码与产品的影响挂钩来衡量代码的影响要容易得多。

To illustrate the importance of focus, I’d like to introduce you to the Duct Tape Programmer. A duct tape programmer is a concept that Joel Spolsky — founder of Stack Overflow — talks about on his blog. The analogy is while most teams argue whether to use titanium vs aluminum to build go carts the duct tape programmer would be speeding down hill, fixing his broken wooden cart with nothing but duct tape and the occasional squeeze of WD. His cart might be battered and haggard but it would also have a gold medal.

为了说明重点的重要性，我想向您介绍Duct Tape Programmer 。 胶带程序员是Stack Overflow的创始人Joel Spolsky在他的博客中谈到的一个概念。 打个比喻，大多数团队都在争论是否要使用钛对铝来制造手推车，这时胶带工程师会加速下坡，只用胶带和偶尔的WD挤压来修理他破损的木制手推车。 他的手推车可能被殴打和ha，但也将获得金牌。

Focusing on the objective leads to making sane engineering decisions, no matter how ugly they might be. Remember we’re in a company only to deliver value, nothing else. When your focus is the internals of the product rather than the objective, you would likely fall into the trap of working on unnecessary features and specifications.

专注于目标会导致做出明智的工程决策，无论它们多么丑陋。 请记住，我们在一家公司中只是为了传递价值，而没有别的。 当您的重点是产品的内部而不是目标时，您可能会陷入对不必要的功能和规格进行研究的陷阱。

Once we go back to the analogy, this becomes a lot clearer. If the hill was on was a flaming ridge you would build the cart with heat resistant material. If it was made out of ice and 100 feet tall, then you would want to install some brakes and a heating system. An ordinary hill only warrants building a normal cart stitched together with duct tape.

一旦回到类推，这将变得更加清晰。 如果山坡上是一块燃烧的山脊，则可以使用耐热材料建造手推车。 如果它是用冰做成的，高100英尺，那么您将需要安装一些制动器和加热系统。 普通的山丘只允许建造用胶带捆扎在一起的普通手推车。

When you’re focused on the objective of your product you tend to be more valuable to the team you’re working in. Remember, you’re not just an engineer but you’re also a team member. If you’re inundating the rest of the team with long deadlines and rigid solutions then you become a nuisance. You might think that the trade-off of this is a well-engineered solution and that has value of it’s own. The answer is no. Quick and ugly solutions help you make better engineering decisions.

当您专注于产品的目标时，对于您正在工作的团队来说往往会更有价值。请记住，您不仅是工程师，而且还是团队成员。 如果您要用漫长的期限和严格的解决方案淹没团队中的其他成员，那么您将成为一件令人讨厌的事情。 您可能会认为，这是一个精心设计的解决方案，并且具有其自身的价值。 答案是不。 快速而丑陋的解决方案可帮助您做出更好的工程决策。

拥抱丑陋的解决方案 (Embrace Ugly Solutions)

When you’re in a time crunch, ugly solutions are all you can muster. Having worked in a startup for close to 4 years, it’s common practice to try and find the quickest way to develop a solution. This made me truly realize the beauty of ugly solutions.

当您处于时间紧缩的时候，丑陋的解决方案就可以满足您的需求。 在一家初创公司工作了将近4年，通常的做法是尝试找到开发解决方案的最快方法。 这使我真正意识到了丑陋的解决方案的美。

To be clear, just because you’re laser-focused on the objective does not mean you won’t be making bad decisions. Problems and bad decisions are inevitable and often valuable. The best thing you can do is learn from them. Better yet, you can identify these problems via quick and dirty solutions. In this section, I will argue for the merit of ugly solutions and why embracing them will help in developing amazing problems.

需要明确的是，仅仅因为您专注于目标并不意味着您不会做出错误的决定。 问题和错误的决定是不可避免的，而且往往很有价值。 您可以做的最好的事情就是向他们学习。 更好的是，您可以通过快速有效的解决方案来确定这些问题。 在本节中，我将提出丑陋解决方案的优点，以及为什么接受这些解决方案将有助于解决令人震惊的问题。

解决方案揭示问题 (Solutions Reveal Problems)

Another instance that reminds of a duct tape programmer is in Ken Kocienda’s book, Creative Selection, as he recounts his time building Safari at Apple with a relatively small team of engineers. Ken and his partner wanted to use an open-source browser as a base for Safari. This open source browser was a fairly large and complex one and wasn’t very compatible with MacOS. Just booting up the software took months of work!

Ken Kocienda的书《创意选择》( Creative Selection)让人想起管道胶带程序员，这是他用相对较少的工程师团队在苹果公司开发Safari的时间。 Ken和他的搭档希望使用开源浏览器作为Safari的基础。 这种开源浏览器是一个相当大且复杂的浏览器，与MacOS不太兼容。 仅启动该软件就需要花费数月的时间！

Ken then hires a brilliant engineer working at Apple. The engineer produces a browser running on MacOS in just 2 days! Instead of using the same open-source repo, he used a much smaller unix-based one and ran it on an OS that’s running on top of MacOS. The browser ran very slowly and the input lagged. The solution was quite ugly, but it worked!

肯随后聘请了一位在Apple工作的出色工程师。 工程师只需两天就能完成在MacOS上运行的浏览器！ 他没有使用相同的开源仓库，而是使用了一个较小的基于unix的仓库，并在运行于MacOS之上的OS上运行它。 浏览器运行非常缓慢，输入滞后。 解决方案很丑陋，但是有效！

Having that ugly solution made the engineering team privy to all the problems that they needed to solve in order to complete building the browser. Ken describes this moment as if he was given a crystal ball. They still needed to make the browser run without depending on another OS, but they knew exactly what they needed to do in order to solve those problems.

拥有该丑陋的解决方案后，工程团队便无视他们需要解决的所有问题，以完成浏览器的构建。 肯形容这一刻就像是给了他一个水晶球。 他们仍然需要使浏览器在不依赖其他操作系统的情况下运行，但是他们确切地知道了解决这些问题所需采取的措施。

In fact, having any type of solution would reveal a lot about the problems you’re facing. If Ken and his team have gone with the original route of trying to make the larger project run on MacOS, they would’ve realized all the problems they’ve had to solve eventually. That’s what building a product means. The only thing in your control is how quickly you can reveal those problems. The sooner the better.

实际上，拥有任何类型的解决方案都会揭示您所面临的许多问题。 如果Ken和他的团队采用了尝试使大型项目在MacOS上运行的最初方法，那么他们将意识到最终必须解决的所有问题。 这就是构建产品的意义。 您唯一能控制的就是您能多快发现这些问题。 越早越好。

Ugly solutions allow you to quickly realize the problems you need to solve

丑陋的解决方案可让您快速意识到需要解决的问题

具体问题很容易解决(Concrete Problems are Easy to Solve)

If you have a very clear and basic problem that needs solving, then the solution is very straightforward. A complex problem is an amalgamation of smaller more basic problems. Properly understanding the complex problem means to properly understand its elements. This is referred to as the First Principles of Knowledge.

如果您有一个非常明确的基本问题需要解决，那么解决方案将非常简单。 一个复杂的问题是一些较小的基本问题的融合。 正确理解复杂问题意味着正确理解其要素。 这被称为知识的第一原理。

A great article that I go back to every once in a while is Farnam Street’s First Principles. The article explains — in part — that once concepts or ideas are taken down to their most basic elements, then understanding the concept becomes very simple. It’s how Elon Musk was able to build SpaceX rockets at unbelievably low prices. For context, the Falcon 9 cost per kilogram was around 15% of the average space shuttle. In an interview with Wired in 2012 he talks about how he was able to get the cost so low.

我不时回顾的一篇很棒的文章是《法南街的第一原理》 。 本文部分(部分)说明，一旦将概念或想法分解为最基本的要素，那么对概念的理解就变得非常简单。 这就是埃隆·马斯克(Elon Musk)以超低的价格制造SpaceX火箭的方式。 就背景而言，猎鹰9的每公斤成本约为平均航天飞机的15％ 。 在2012年接受《连线》杂志(Wired)采访时，他谈到了他如何能够降低成本。

“What is a rocket made of? Aerospace-grade aluminum alloys, plus some titanium, copper, and carbon fiber. And then I asked, what is the value of those materials on the commodity market? It turned out that the materials cost of a rocket was around 2 percent of the typical price” — Elon Musk.

“火箭是由什么制成的？ 航空级铝合金，再加上一些钛，铜和碳纤维。 然后我问，这些材料在商品市场上的价值是什么？ 事实证明，火箭的材料成本约为典型价格的2％”-伊隆·马斯克(Elon Musk)。

Once you clearly understand a problem that you need to solve, the solution is straightforward. Problems beget solutions. If I tell you that it’s raining outside, a great solution is to carry an umbrella. The solution is quite concrete once the problem is clear enough.

一旦清楚地了解了您需要解决的问题，解决方案就很简单。 问题带来解决方案。 如果我告诉你外面正在下雨，一个很好的解决方案是带把伞。 一旦问题很明显，解决方案就很具体了。

收集问题 (Collecting Problems)

If problems are easy and straightforward then shouldn’t building products be easy? The problem with building products isn’t figuring out the solutions but rather figuring out the problems.

如果问题既简单又直接，那么构建产品就不应该那么容易吗？ 构建产品的问题不是找出解决方案，而是找出问题。

Problems only reveal themselves once there are users using your product. This means that before users use your product, most of the problems you’re solving are either incomplete or invalid; in other words, you need to invalidate your assumptions. The best way to learn about the problems of the product is by creating an imperfect product and testing with users. That way you can collect concrete problems.

问题只有在有用户使用您的产品时才会显现出来。 这意味着在用户使用您的产品之前，您要解决的大多数问题都是不完整的或无效的。 换句话说，您需要使您的假设无效。 了解产品问题的最佳方法是创建不完善的产品并与用户进行测试。 这样，您可以收集具体问题。

This isn’t to say that you need usurp your PM and launch products over their heads. As an engineer you’re obliged to accept that users will interact with an imperfect product and ship anyways; all for the sake of collecting problems. Those problems would be concrete and well-defined. Solving them is not only easy, but it brings more value to your product.

这并不是说您需要篡改PM，并在他们的头上发布产品。 作为工程师，您有义务接受用户将与不完善的产品互动并以任何方式发货； 所有这些都是为了收集问题。 这些问题将是具体和明确的。 解决它们不仅容易，而且可以为您的产品带来更多价值。

The more problems you discover, the better your product is

发现的问题越多，您的产品越好

This is why building great products is difficult, because it takes time to farm all those problems.

这就是为什么很难制造出优质产品的原因，因为要花很多时间来解决所有这些问题。

This process of gaining context is difficult because you’re always finding out problems. If there is one thing you should take from this section it’s that quick and dirty solutions move the product forward.

获取上下文的过程很困难，因为您总是会发现问题。 如果您需要从本节中获得一件事，那就是快速而又肮脏的解决方案使产品向前发展。

避免完美的解决方案 (Avoid Perfect Solutions)

Not only is it difficult to try and visualize all the problems you need to solve before solving them, but I believe it’s harmful to try.

在解决问题之前，不仅很难尝试并形象化您需要解决的所有问题，而且我认为尝试这样做是有害的。

Perfect solutions are nice, but they’re like unicorns, if they do exist then they’re pretty rare. Thus, hunting unicorns is a foolish endeavor. One of the problems with the attitude of software engineers in the industry is that they believe that a perfect solution exists, much less that they can develop that solution within a feasible timeframe.

完美的解决方案很好，但是它们就像独角兽一样，如果确实存在，那么它们将非常罕见。 因此，狩猎独角兽是愚蠢的努力。 一个软件工程师在行业中的态度问题，是个EY谗已经是一个完美的解决方案存在，更不用说他们可以制定一个可行的时间框架内的解决方案。

Perfect solutions do not exist.

完美的解决方案不存在。

This delusion makes us do crazy things, like create a full infrastructure diagram or UML chart on day one. Or building a full scale authentication system on a listings site. Or building a pre-rendering solution for a site that is yet to exist. It’s all fluff when you don’t know what the problems are. And no matter how genius your PM, CEO or CTO is, unless they’re a messiah, they cannot predict all the problems either; humans are just bad at creating comprehensive lists of things.

这种幻想使我们做疯狂的事情，例如在第一天创建完整的基础结构图或UML图表。 或在列表网站上构建全面的身份验证系统。 或为尚不存在的站点构建预渲染解决方案。 当您不知道问题出在哪里时，这都是毛茸茸的。 而且，无论您的PM，CEO或CTO多么有才，除非他们是救世主，否则他们也无法预测所有问题。 人类只是无法创建事物的综合清单。

A perfect solution would entail that all the problems have been discovered. If that is the case, then why bother with the engineering aspect of building that solution. If all the problems have been discovered then all the engineering must’ve been already done in some shape or form in the past. It would be easier to just use that solution instead of re-inventing the wheel.

完美的解决方案将需要发现所有问题。 如果真是这样，那为什么还要打扰构建该解决方案的工程方面。 如果发现了所有问题，那么过去所有的工程都必须以某种形式完成。 仅使用该解决方案而不是重新发明轮子会更容易。

Think of a type of product that has most of their problems already discovered and see how they’re built. There are many examples: e-commerce, blog sites, landing pages etc. The specifications are so well defined that companies like Wix & Shopify were able to create an engine that generates online sites & stores with little to no operational cost. The engineering here is so trivial that we wrote code to write the code.

想一想一种已经发现了大多数问题的产品，然后看看它们是如何制造的。 有很多示例：电子商务，博客站点，登录页面等。规范定义得非常明确，以至于Wix＆Shopify等公司能够创建引擎来生成在线站点和商店，而运营成本很少甚至没有。 这里的工程是如此琐碎，以至于我们编写了代码来编写代码。

If you put all these together you’ll realize that the path to being a better software engineer is by contextualizing where tech lies in any product company. Technology is only a small part of any business. We’re there to support businesses, we’re seldom ever the center of businesses. Once you realize that, you can focus on delivering stuff that actually matters, making you more valuable in the market.

如果将所有这些放在一起，您将认识到成为一名更好的软件工程师的途径是通过上下文分析技术在任何产品公司中的地位。 技术只是任何业务的一小部分。 我们在那里为企业提供支持，而我们却很少成为企业的中心。 一旦意识到这一点，您就可以专注于交付真正重要的东西，从而使您在市场中更具价值。

That’s it 😁

就是这样

翻译自: https://medium.com/@ysr.sayed/what-i-hate-about-software-engineers-2d7d77d99129

员工讨厌行为管理软件