Software Engineering - The Soft Parts软件工程-软件部分_the main value in software is not the code produce-程序员宅基地

技术标签: 文章  Powered by 金山文档  

Today I'll share some of the software engineering "soft skills" I've learned from my first 10 years on Google Chrome, where I am a Senior Staff Engineering Manager. On my 10th anniversary, I wanted to reflect on some of lessons that have stayed with me. I hope these prove useful to you during your career.

今天,我将分享一些软件工程“软技能”,这是我在Google Chrome上的前10年学到的,我是那里的高级工程经理。在我的十周年纪念日之际,我想回顾一下我的一些经验教训,希望这些对你的职业生涯有用。

Becoming a good engineer is about collecting experience. Each project, even small ones, is a chance to add new techniques and tools to your toolbox. Where this delivers even more value is when you can solve problems by pairing techniques learned on one project with tools learned working on another. It all adds up.

成为一名优秀的工程师需要积累经验。每个项目,即使是小项目,都是向您的工具箱添加新技术和工具的机会。当您可以通过将在一个项目中学习的技术与在另一个项目中学习的工具配对来解决问题时,这将带来更大的价值。一切都说得通。

I'll preface this by saying I am unimportant, unwise and unoriginal. YMMV :)

我先说我不重要,不聪明,没有独创性。YMMV:)

Skip to lessons most relevant for leaders/managers

跳到与领导者/经理最相关的课程

Table Of Contents 目录

Learning new things 学习新事物

The following pointers should help most junior or mid-career developers move forward, deal with changing technology, and build complex systems while following the standard processes in the software engineering paradigm and discovering new best practices. Apply first principles when you can. Learning to break down problems into smaller pieces is one of the most important skills in life.

下面的要点应该可以帮助大多数初级或中级职业开发人员向前迈进,处理不断变化的技术,并在遵循软件工程范式中的标准过程和发现新的最佳实践的同时构建复杂的系统。在可能的情况下应用第一原则。学会把问题分解成更小的部分是生活中最重要的技能之一。

Mastery

Technical mastery implies a high ratio of value shipped to hours worked.
掌握技术意味着价值与工作时间的高比率。

This means you can discern tasks that add value and help your team focus their energy in that direction. It also means you know how to avoid work that doesn't provide the team/company value - the best engineers can even steer whole teams away from work that isn't that useful. Work on what matters most.

这意味着您可以识别出增加价值的任务,并帮助您的团队将精力集中在该方向上。这也意味着你知道如何避免不提供团队/公司价值的工作-最好的工程师甚至可以引导整个团队远离没有那么有用的工作。做最重要的事。

I often get asked, "How do I know if I'm making the best use of my time?". There will almost always be tasks you can fill your time with to "feel" busy. The real trick here is making sure you are working on the right things. If you want to move mountains, focus on tasks that move the needle, even if that movement is small.

我经常被问到,“我怎么知道我是否最好地利用了我的时间?”“.几乎总是有一些任务可以让你“感觉”忙碌。这里真实的的诀窍是确保你正在做正确的事情。如果你想移山,那就专注于能移动指针的任务,即使移动很小。

Some questions you can ask yourself:

你可以问自己一些问题:

  • What are my goals? Are the tasks I'm focused on lining up with those goals?
    我的目标是什么?我专注的任务是否与这些目标一致?

  • Could there be something I could do differently or better?
    有什么我可以做得更好或更好的吗?

Even asking yourself such questions can be extraordinarily powerful.

即使问自己这样的问题也会非常强大。

Think critically and formulate well-reasoned arguments

批判性地思考,提出理由充分的论点

Critical thinking is the ability to use cognitive skills to think independently in order to make thoughtful decisions. Invest in this skill to improve your clarity of thought.
批判性思维是运用认知技能独立思考以做出深思熟虑的决定的能力。投资于这种技能可以提高你的思维清晰度。

As engineers, we can sometimes rush to solve a problem right away so it feels like we're making progress or looks like we're being responsive to stakeholders. This can introduce risks if we aren't fully considering causes and consequences. Put another way, critical thinking is thinking on purpose and forming your own conclusions. This goal-directed thinking can help you focus on root-cause issues that avoid future problems that arise from not keeping in mind causes and consequences.

作为工程师,我们有时会急于立即解决问题,这样我们就能感觉到我们正在取得进展,或者看起来我们正在对利益相关者做出回应。如果我们没有充分考虑原因和后果,这可能会带来风险。换句话说,批判性思维是有目的地思考并形成自己的结论。这种目标导向的思维方式可以帮助你专注于根本原因问题,避免未来因不牢记原因和后果而产生的问题。

In broad strokes, some of the questions I like to ask based on critical thinking are:

概括地说,我喜欢基于批判性思维提出的一些问题是:

  • How do we know we're solving the right problem?
    我们怎么知道我们在解决正确的问题?

  • How do we know we're solving the problem in the right way? (i.e. balancing rigor and efficiency, given our understanding of the problem and constraints)
    我们怎么知道我们在用正确的方法解决问题?(i.e.考虑到我们对问题和约束的理解,平衡严谨性和效率)

  • If we don't know the sources of our problem, how can we determine the root cause?
    如果我们不知道问题的根源,我们如何确定根本原因?

  • How can we break the key question down into smaller questions that we can analyze further?
    我们如何将关键问题分解为更小的问题,以便进一步分析?

  • Once we have one or more hypotheses, how do we structure work to evaluate them?
    一旦我们有了一个或多个假设,我们如何组织工作来评估它们?

  • What shortcuts might we take if we're under constraints (time pressure) without unduly compromising our analytics rigor around the question?
    如果我们受到限制(时间压力),我们可以采取哪些捷径,而不会过度损害我们对问题的分析严谨性?

  • Does the evidence sufficiently support the conclusions?
    证据是否足以支持结论?

  • How do we know when we are done? When is the solution "good enough"?
    我们怎么知道我们什么时候完成?什么时候解决方案“足够好”?

  • How do I communicate the solution clearly and logically to all stakeholders?
    如何将解决方案清晰、合理地传达给所有利益相关者?

I've found these questions often help. Sometimes we'll address the symptom of a problem, only to discover there are other symptoms that pop up. At other times, we might quickly ship a solution that creates more problems later down the road. With a lens on critical thinking, we might challenge assumptions, look closer at the risk/benefit, seek out contradictory evidence, evaluate credibility and look for more data to build confidence we are doing the right thing.

我发现这些问题常常很有帮助。有时候,我们会解决问题的症状,却发现还有其他症状会出现。在其他时候,我们可能会很快地发布一个解决方案,而这个解决方案在以后会产生更多的问题。有了批判性思维的透镜,我们可能会挑战假设,更仔细地观察风险/收益,寻找矛盾的证据,评估可信度,并寻找更多的数据来建立信心,我们正在做正确的事情。

For example, a common mistake I've seen engineers make is assuming correlation implies causation (i.e. just because two things correlate does not necessarily mean that one causes the other). A critical thinker might push back on assumptions such as this, asking why we believe them to be true.

例如,我见过工程师犯的一个常见错误是假设相关性意味着因果关系(即仅仅因为两件事相关并不一定意味着一件事导致另一件事)。一个批判性的思考者可能会推翻这样的假设,问我们为什么相信它们是正确的。

Critical thinkers: 批判性思考者:

  • Raise mindful questions, formulating them clearly and precisely
    提出有意识的问题,清晰而精确地表达它们

  • Collect and assess relevant information, validating how they might answer the question
    收集和评估相关信息,验证他们如何回答问题

  • Arrive at well-reasoned conclusions and solutions, testing them against relevant criteria and standards
    得出合理的结论和解决方案,并根据相关标准和标准对其进行测试

  • Think open mindedly within alternative systems of thought, recognizing and assessing, as need be, their assumptions, implications, and practical consequences
    在不同的思想体系中进行开放的思考,在需要时识别和评估它们的假设,含义和实际后果

  • Communicate effectively with others in figuring out solutions to complex problems
    与他人有效沟通,找出解决复杂问题的方法

Note: Critical thinking has both aspects of being a "soft skill" and a "hard skill", so is included in this write-up.

注意:批判性思维有“软技能”和“硬技能”两个方面,所以包括在这篇文章中。

Building a strong base 建立坚实的基础

Master the fundamentals and apply them repeatedly to acquire new skills.
掌握基本原理并反复应用以获得新技能。

The long-term value of learning the fundamentals is that they are transferable. The short-term is that they help you make better decisions and can make code more efficient.

学习基础知识的长期价值在于它们是可转移的。短期而言,它们可以帮助您做出更好的决策,并使代码更高效。

Transferable skills 可转移技能

Transferable skills are those you can take with you from project to project. Let's talk about them in relation to the fundamentals.

可转移的技能是那些你可以从一个项目带到另一个项目的技能。让我们来谈谈它们与基本原理的关系。

The fundamentals are the foundation of any software engineering career. There are two layers to them - macro and micro. The macro layer is the core of software engineering and the micro layer is the implementation (e.g. the tech stack, libraries, frameworks, etc.).

At a macro level, you learn programming concepts that are largely transferable regardless of language. The syntax may differ, but the core ideas are still the same. This can include things like: data-structures (arrays, objects, modules, hashes), algorithms (searching, sorting), architecture (design patterns, state management) and even performance optimizations (e.g. eager vs lazy evaluation, memoization, caching, lazy-loading etc). These are concepts you'll use so frequently that knowing them backwards can have a lot of value.

At a micro level, you learn the implementation of those concepts. This can include things like: the language you use (JavaScript, Python, Ruby, etc), the frameworks you use (e.g. React, Angular, Vue etc), the backend you use (e.g. Django, Rails, etc), and the tech stack you use (e.g. Google App Engine, Google Cloud Platform, etc). There involve details that can be valuable to gain expertise in to be effective, but are not always transferable.

在微观层面上,您将学习这些概念的实现。这可能包括以下内容:你使用的语言(JavaScript,Python,Ruby等),你使用的框架(例如React,Angular,Vue等),你使用的后端(例如Django,Rails等),以及你使用的技术堆栈(例如Google App Engine,Google Cloud Platform等)。其中涉及的细节可能对获得专业知识有价值,但并不总是可转移的。

By learning the fundamentals, you gain the skillset and tools to then ignore the fundamentals and grow.
通过学习基础知识,你获得了技能和工具,然后忽略基础知识并成长。

That said, pragmatically, no one has time to learn everything at the beginning of their careers. There comes a point when you shouldn't over-index on the fundamentals and learn what is needed to actually build applications for the real world. This is where the "learn by doing" approach comes in.

也就是说,实际上,没有人有时间在职业生涯开始时学习一切。有一点,当你不应该过度索引的基本面,并了解什么是需要实际构建应用程序的真实的世界。这就是“边做边学”方法的用武之地。

Efficiency

Understanding the fundamentals well can help you write more efficient code. This includes concepts such as time complexity (the time it takes to run your code), memory usage, and the trade-offs between performance and maintainability. These ideas allow you to make trade-offs that are helpful when building any reasonably large application. Speed is often critical for modern applications and can often impact end-user experience in a noticeable way.

很好地理解基础知识可以帮助你编写更高效的代码。这包括时间复杂度(运行代码所需的时间)、内存使用以及性能和可维护性之间的权衡等概念。这些想法允许您在构建任何合理的大型应用程序时进行有益的权衡。速度对于现代应用程序通常至关重要,并且通常会以明显的方式影响最终用户体验。

Better decision-making 更好的决策

Having a good understanding of macro and micro fundamentals can help you make better decisions.
对宏观和微观基本面有很好的理解可以帮助你做出更好的决策。

You can use the knowledge you've gained to make better decisions about which technologies to use and which ones to avoid based on the goals and constraints of any project. This can help you avoid the pitfalls of choosing the wrong technology or the wrong tool for the job.

您可以根据任何项目的目标和限制,使用所获得的知识来更好地决定使用哪些技术以及避免使用哪些技术。这可以帮助您避免为工作选择错误的技术或错误的工具的陷阱。

""You haven't mastered a tool until you understand when it should not be used." - @kelseyhightower

“你没有掌握一个工具,直到你明白什么时候不应该使用它。“- @kelseyhightower"

Software engineering involves thinking about many different layers - the core languages, the implementation, the infrastructure, the tools, and the people. Only having a surface-level appreciation for these layers can absolutely let you build faster. But really knowing the fundamentals (including O(n) time complexity) can help you go that much farther, especially when the landscape of languages and frameworks changes over time.

软件工程涉及到对许多不同层面的思考--核心语言、实现、基础设施、工具和人员。只有对这些层有一个表面的理解,才能让你更快地构建。但是真正了解基础知识(包括O(n)时间复杂度)可以帮助你走得更远,特别是当语言和框架的环境随着时间的推移而变化时。

Related reading:

Focus on the User and the rest will follow

以用户为中心,其他内容将随之而来

Start with the user experience and work backwards to the technology you need.
从用户体验开始,然后再回到你需要的技术。

Steve Jobs once famously said, "you've got to start with the customer experience and work backward to the technology. You can’t start with the technology then try to figure out where to sell it.".

史蒂夫·乔布斯曾经说过一句名言:“你必须从客户体验开始,然后再回到技术上。你不能从技术开始,然后试图找出在哪里出售它。“.

This quote has stuck with me, because as engineers, it's far too easy to start from a place of wanting to use specific solutions - whether due to popularity, developer experience or just personal preference - and try to find a way to rationalize using them. Instead, we should focus on who we're building for, what problems they have, and how the current options available are falling short.

这句话一直萦绕在我的脑海中,因为作为工程师,从想要使用特定解决方案的地方开始太容易了-无论是由于受欢迎程度,开发人员经验还是仅仅是个人偏好-并试图找到一种合理使用它们的方法。相反,我们应该关注我们正在为谁构建,他们有什么问题,以及当前可用的选项是如何不足的。

Great user experiences come from combining both points of view - both the customer and technology. Show people what you think they want and pay attention to what they say. There is of course, immense nuance to this problem space - what engineering choices will allow you to deliver a great experience on mobile hardware? What choices will impact engineering velocity? or scale? or hiring?. Ultimately, we benefit from having a relentless focus on the customer first and then navigating what allows us to address their needs within the constraints we have to work with.

出色的用户体验来自于两种观点的结合-客户和技术。向人们展示你认为他们想要的东西,并注意他们所说的话。当然,这个问题空间存在巨大的细微差别-什么样的工程选择将允许您在移动的硬件上提供出色的体验?哪些选择会影响工程速度?还是规模?还是雇人?最终,我们将受益于首先对客户的不懈关注,然后在我们必须处理的限制范围内引导我们满足他们的需求。

The best software is built by engineers who have empathy for their users.
最好的软件是由对用户有同情心的工程师开发的。

Business success depends on customer satisfaction which often translates to user experience in the case of software. Understand how the end-users experience the product or service. Make sure your solutions do not hamper their ability to do their jobs efficiently. If you are in a position that allows you to interact with end-users directly, attempt to understand their needs and pain points better.

业务成功取决于客户满意度,在软件的情况下,客户满意度通常会转化为用户体验。了解最终用户如何体验产品或服务。确保您的解决方案不会妨碍他们有效完成工作的能力。如果您的职位允许您直接与最终用户交互,请尝试更好地了解他们的需求和痛点。

Upgrading your skills 提升您的技能

Choose what's right for your use case and not the flavor of the month.
选择适合您的使用案例而不是本月的风味。

It's OK to use "boring” technology (what’s tried & tested) vs. the hype train. Languages, frameworks and libraries often evolve. Choose what helps deliver a great final product. When starting off a new project, begin with "boring" tech (but well understood) and then intentionally decide out of it to select the best tool for a problem.

使用“无聊”的技术(经过尝试和测试的技术)与炒作列车是可以的。语言、框架和库经常会发展。选择有助于交付出色最终产品的内容。当开始一个新项目时,从“无聊”的技术(但很好理解)开始,然后有意识地从中选择解决问题的最佳工具。

When picking new skills to learn or use, don't be afraid to choose something that's boring and not in the news. FOMO may not be productive when it comes to technology whether it be languages, frameworks, and libraries and tools. While it's important to know what to use, your main goal is to deliver an excellent final product. Please don't chase the new and shiny technologies unless you think they add value to your solutions. At the same time, don't shun something because it is not being talked about enough.

当选择新的技能学习或使用,不要害怕选择一些无聊的,不是在新闻。当涉及到技术时,无论是语言、框架、库和工具,FOMO都可能没有生产力。虽然知道使用什么很重要,但您的主要目标是交付出色的最终产品。请不要追逐新的和闪亮的技术,除非你认为它们能为你的解决方案增加价值。同时,不要因为谈论得不够而回避某件事。

Take advantage of new projects to learn new tech.
利用新项目学习新技术。

At the same time, personal and hackathon projects can be a great opportunity to learn new tech. Many of us have fewer opportunities to start something completely brand new, as opposed to working on an existing codebase where many decisions have been made. Such projects can be a low-risk way to research new tech, evaluate its strengths and weaknesses (at a small scale) and build up some first-hand knowledge that could be valuable to you in the future.

同时,个人和黑客马拉松项目也是学习新技术的绝佳机会。我们中的许多人很少有机会开始全新的东西,而不是在现有的代码库上工作,在那里已经做出了许多决定。这样的项目可以是一种低风险的方式来研究新技术,评估其优势和劣势(小规模),并积累一些对未来有价值的第一手知识。

Be curious and never stop learning
保持好奇心,永不停止学习
Write about what you learn. It pushes you to understand topics better. Sometimes the gaps in your knowledge only become clear when you try explaining things to others. It's OK if no one reads what you write. You get a lot out of just doing it for you.
写下你学到的东西。它促使你更好地理解主题。有时候,只有当你试图向别人解释事情时,你的知识差距才会变得清晰。如果没人读你写的东西也没关系。为你自己而做你会得到很多。

Learning should be a continuous process - people who claim to know everything about a particular technology are often not experts. Real experts are proficient with the technology but realize there is always scope for learning and improvement. Curiosity drives learning - so if you are curious about a new framework, google it, read the docs, try the tutorials, read the source! Learning need not happen in a classroom. It can happen anywhere, anytime. Take half an hour each day to read a chapter from a textbook, listen to a technology podcast, read development blogs or learn a new programming language.

学习应该是一个持续的过程--声称对某项特定技术了如指掌的人往往不是专家。真实的的专家精通技术,但也意识到总有学习和改进的空间。好奇心驱动学习-所以如果你对一个新的框架感兴趣,谷歌它,阅读文档,尝试教程,阅读源代码!学习不需要在教室里进行。它随时随地都可能发生。每天花半个小时阅读教科书中的一章,听技术播客,阅读开发博客或学习一门新的编程语言。

It's powerful for leaders to admit when they don't know something.
领导者承认自己不知道的事情是很有力量的。

Having this confidence lowers the expectation that Senior Engineers have to know everything. You absolutely don't need to have all the answers, but being able to admit you're human and are committed to figuring out how to solve problems with your team is the important part.

有了这种信心,就降低了高级工程师必须知道一切的期望。你绝对不需要知道所有的答案,但能够承认你是人,并致力于找出如何与你的团队解决问题是重要的部分。

Leaders also admit when they make mistakes.
领导者犯错误时也会承认。

It's important to teach your team how to handle mistakes with humility and the desire to learn and improve. The real world isn't perfect and it's totally okay to show your team it isn't perfect to prepare them for it.

重要的是要教会你的团队如何以谦逊的态度和学习和改进的愿望来处理错误。真实的世界并不完美,向你的团队展示它并不完美,让他们为之做好准备是完全可以的。

Be a caretaker, rather than an owner.
做一个管理者,而不是一个主人。

In the early stages of open-source projects, it's common to think like an owner. You often directly own proving out value, working on features, answering issues and advocacy. This can be great for getting something adoption, but may not be the best way to scale a project later down the line when staffing changes or your own time gets limited.

在开源项目的早期阶段,像所有者一样思考是很常见的。你经常直接拥有证明价值,开发功能,回答问题和宣传。这对于获得一些采用可能是很好的,但是当人员变化或您自己的时间有限时,这可能不是扩展项目的最佳方式。

After the initial crunch, another way to think of evolving your role is towards being a caretaker, rather than an owner. A caretaker might focus on scaling themselves out. This can be done by sharing as much knowledge as is possible with other maintainers, contributors and the community (via design docs, code comments, and other documented best practices). It also helps to grow the pool of reviewers with enough context to make the right decisions when you're no longer as involved.

在最初的危机之后,另一种思考角色演变的方式是成为一个看护者,而不是所有者。管理员可能会专注于扩展自己。这可以通过与其他维护者、贡献者和社区(通过设计文档、代码注释和其他记录的最佳实践)共享尽可能多的知识来实现。它还有助于增加审阅者的数量,当您不再参与时,这些审阅者有足够的背景来做出正确的决定。

This is often what projects need to be sustainable many years down the road.

这通常是项目在未来许多年内可持续发展所需要的。

Depth and breadth of skills 技能的深度和广度

Consider if being a jack of all trades and a master of one is right for you.
考虑一下,做一个万事通和一个万事通是否适合你。

One of the greatest skills you can master is learning how to learn. This should be a priority over say, just going deep on particular programming language or framework. It helps to stay curious. Once you have experience with this, you may question if you should aim to be a specialist or a jack of all trades.

你能掌握的最伟大的技能之一就是学会如何学习。这应该是一个优先级,而不是说,只是深入到特定的编程语言或框架。保持好奇心是有帮助的。一旦你有了这方面的经验,你可能会问,你的目标是成为一个专家还是一个万事通。

I personally like the idea of T-Shaped engineers. These are engineers who are a deep expert in one or a small number of skills (the vertical bar of the T), but who have a basic understanding of many other skills needed to build and run a product (the horizontal bar). Some teams like to rotate team members through a range of different specializations to build more T-Shaped team members.

我个人喜欢T型工程师的想法。这些工程师是一个或一小部分技能(T的竖条)的深度专家,但他们对构建和运行产品所需的许多其他技能(横条)有基本的了解。一些团队喜欢通过一系列不同的专业化来轮换团队成员,以构建更多的T型团队成员。

I've found that in mid-large sized teams, it's been effective to have folks who possess specialized skills in one area and the skills, versatility, and aptitude for collaboration to fill in for other people if necessary.

我发现,在大中型团队中,如果有必要,让那些在某个领域拥有专业技能、技能、多功能性和协作能力的人来代替其他人,是很有效的。

To experience is to learn 体验就是学习

When learning a new language, focus on building something tangible with it that gives you first-hand experience.
当学习一门新语言时,专注于用它建立一些有形的东西,给你第一手的经验。

If you are learning a new language, you need not memorize all its syntax or documentation to become a good developer. It's more important to know how to solve problems. Earn experience by writing a lot of relevant code or learning from existing code. The results should help you write efficient code in that language. As mentioned here, "The main value in software is not the code produced, but the knowledge accumulated by the people who produced it". However, please don't experiment in production when experimenting with new technology.

如果你正在学习一门新的语言,你不需要记住它的所有语法或文档来成为一名优秀的开发人员。更重要的是知道如何解决问题。通过编写大量相关代码或从现有代码中学习来获得经验。结果应该可以帮助您用该语言编写高效的代码。正如这里所提到的,“软件的主要价值不是产生的代码,而是产生它的人积累的知识”。但是,在尝试新技术时,请不要在生产中进行实验。

Technical Complexity 技术复杂性

Generic vs Specific code 通用代码与特定代码

Write code specifically for the problem at hand, but try to spot places where you can afford to make it a little generic.
专门为手头的问题编写代码,但是要尽量找出你能负担得起的地方,使它有点通用。

Often, we attempt to code things as generic as possible, and end up making what is effectively code soup that doesn't help accomplish the problem. Instead, building specifically for this problem, but trying to spot places it can be made just a little bit more generic, has altogether eliminated times I know I would've had to refactor again later if I hadn't been thinking of it.

通常,我们试图编写尽可能通用的代码,最终却使有效的代码汤无助于解决问题。相反,专门针对这个问题进行构建,但试图找出可以使其更通用的地方,这完全消除了我知道如果我没有想到它的话,我将不得不在以后再次重构的时间。

There are several principles commonly discussed that talk about design complexity. From the extreme programming world, you have:

关于设计复杂性,有几个经常讨论的原则。在极限编程世界中,你有:

  • YAGNI or You aren't gonna need it, which states that programmers should not add functionality until it is necessary.
    YAGNI或You aren 't gonna need it,这表明程序员不应该添加功能,直到它是必要的。

Both these principles aim to prevent over-engineering. However, these principles could be abused to create multiple simple solutions which do not integrate well.

这两个原则都旨在防止过度设计。然而,这些原则可能会被滥用,以创建多个简单的解决方案,这些解决方案不能很好地集成。

At the other end of the spectrum, you have the Abstraction principle that aims to reduce duplicate structures in the code whenever practical through abstraction and generalization. I prefer to take the middle ground between extreme abstraction and extreme simplicity by making code just a little generic. The AHA (Avoid hasty abstractions) principle promotes a similar idea.

另一方面,抽象原则旨在通过抽象和泛化减少代码中的重复结构。我更喜欢在极端抽象和极端简单之间采取中间立场,使代码稍微通用。AHA(避免匆忙抽象)原则促进了类似的想法。

Deep modules

Write code that solves complex problems for other developers but exposes functionality through a lucid interface.
编写代码,为其他开发人员解决复杂的问题,但通过清晰的界面公开功能。

If you are an API designer or developer - your responsibility is to provide an interface to simplify complex functionality for other developers. The purpose is defeated if the interface is too difficult to understand and imposes a cost on the programmer using it. This idea is reflected in the concept of Deep Modules - "The best modules are those with the greatest benefit and the least cost. The benefit provided by a module is its functionality, and the cost of a module is its interface."

如果你是一个API设计者或开发者,你的职责是提供一个接口来简化其他开发者的复杂功能。如果接口太难理解,并且给使用它的程序员带来了成本,那么这个目的就失败了。这个想法反映在深度模块的概念中-“最好的模块是那些具有最大收益和最小成本的模块。模块提供的好处是它的功能,模块的成本是它的接口。“

While the simplicity of an interface is desirable, complex problems sometimes require complex code to solve them (this if not a universal rule, but is often true). This complexity is better off embedded in code. When complex functionality is abstracted, the value provided to the end-user or interface user is higher.

虽然接口的简单性是可取的,但复杂的问题有时需要复杂的代码来解决它们(这虽然不是通用规则,但通常是正确的)。这种复杂性最好嵌入到代码中。当复杂的功能被抽象时,提供给最终用户或界面用户的价值更高。

An API with multiple visible functions and classes encompassing some functionality is more complex and challenging to search when compared to another with the same functionality implemented using fewer public functions/classes. New functions and classes add to the cost of the interface for maintenance programmers and library users.

与使用较少公共函数/类实现的具有相同功能的另一个API相比,具有包含某些功能的多个可见函数和类的API更复杂且更难搜索。新的函数和类增加了维护程序员和库用户的接口成本。

Learning on a maintenance project

在维护项目中学习

When working on legacy code in older systems, understand the difference between code that should stay and code that should go.
在旧系统中处理遗留代码时,请了解应该保留的代码和应该删除的代码之间的区别。

Any senior engineer should make an effort to understand the difference between code that should stay and code that should go.

任何高级工程师都应该努力理解应该保留的代码和应该删除的代码之间的区别。

Large, long-term production systems are going to have some bad code or code that doesn't have a good reason to remain anymore. It's healthy to appreciate why something is there (good reason? bad reason?). Remove the bad code and keep the good code.

大型的、长期的生产系统会有一些糟糕的代码,或者没有理由再保留的代码。欣赏为什么有些东西在那里是健康的(好的理由?)不好的理由?)。删除坏代码,保留好代码。

I've worked at many companies where folks assume what is legacy code is untouchable or is designed the way it is for a good reason, lost to the sands of time. This can lead to fear of change where you just keep on adding abstractions to a weak foundation.

我曾在许多公司工作过,那里的人们认为遗留代码是不可触及的,或者是出于一个很好的理由而设计的,已经被时间的沙子所遗忘。这可能导致对变化的恐惧,你只是不断地在一个薄弱的基础上添加抽象。

The software industry has reached a stage where many projects deal with the maintenance and migration of old or legacy systems. Don't get frustrated if you find yourself in one such team. There is much domain-specific knowledge that you can gain by looking at old code. While there may be good reasons for older code/validations existing in production, it's healthy not to assume every single line is still relevant.

软件行业已经到了一个阶段,许多项目都要处理旧系统或遗留系统的维护和迁移。如果你发现自己在这样的团队中,不要感到沮丧。通过查看旧代码,您可以获得许多特定于领域的知识。虽然在生产环境中存在较旧的代码/验证可能有很好的理由,但不要假设每一行都仍然相关。

Some software engineers are wary of touching code working in production for fear of introducing a bug. So they include conditions and repeat some code for newer use cases. Such workarounds may save time at that instant, but they become a maintenance nightmare over time. Don't assume that the existing code is blessed or infallible. There may be some aspect of scalability or efficiency previously overlooked that you could address.

一些软件工程师对接触生产环境中的代码持谨慎态度,因为担心引入错误。因此,它们包含条件并为新的用例重复一些代码。这样的变通方法可能在那一刻保存时间,但随着时间的推移,它们会成为维护的噩梦。不要认为现有的代码是有祝福的或绝对正确的。您可以解决以前忽略的可伸缩性或效率的某些方面。

Learning on a green-field project

在绿地项目上学习

Experiment, innovate, fail fast and get better at solving problems.
实验,创新,快速失败,并更好地解决问题。

Your learning journey is entirely different when you are tasked with building a system from scratch. As you start prototyping or implementing features iteratively, you learn what works and what doesn't. Agile methodology and the fail-fast principle help you validate your ideas earlier with fewer resources. They enable you to divide and conquer complex problems.

当你的任务是从头开始构建一个系统时,你的学习之旅完全不同。当你开始原型化或迭代地实现特性时,你会了解什么可行,什么不可行。敏捷方法和快速失败原则帮助您用更少的资源更早地验证您的想法。它们使您能够分解和克服复杂的问题。

Definition of done 完成的定义

Defining what is "done" is time-saving because it helps you estimate the effort required, plan for development, and avoid unnecessary revisions later.
定义什么是“完成”是节省时间的,因为它可以帮助您估计所需的工作量,计划开发,并避免以后不必要的修订。

Another Agile principle that comes in handy when dealing with complexity is agreeing on the definition of done. In addition to meeting user requirements and acceptance criteria, this could include other conditions such as code reviews, testing, documentation, etc.

另一个敏捷原则在处理复杂性时派上用场的是对完成的定义达成一致。除了满足用户需求和验收标准外,还可能包括其他条件,如代码评审、测试、文档等。

Phased roll-outs

A single large release may be divided into a series of lower-risk well-understood rollouts.
一个大的发布可以被划分为一系列低风险的、易于理解的推出。

Rollout plans are as important as the architecture and the code when planning releases for large-scale production systems. Phased releases with iterative development help you better manage risks due to significantly large changes. You can also create release strategies with the development and testing strategy to have an end-to-end plan for a complex release.

在计划大规模生产系统的发布时,推出计划与架构和代码一样重要。带有迭代开发的分阶段发布可以帮助您更好地管理由于重大变更而产生的风险。您还可以使用开发和测试策略创建发布策略,以便为复杂的发布制定端到端的计划。

Systematic debugging 系统调试

When debugging, you should try to resolve the issues systematically and rigorously to address all the test conditions.
在调试时,您应该尝试系统地、严格地解决问题,以解决所有测试条件。

Always read the error messages (and the stack trace). There's likely valuable information in there that will help you isolate the problem so you can resolve it. A surprising number of engineers ignore the insight error messages can give offer before looking for debugging help. Assume your machine is telling you what's wrong and may be correct, rather than assuming that making small edits and constantly re-running the code will fix the problem faster. If you write a solution that throws an exception and aren't reading the exception carefully, you may be wasting time. Often the error or exception message is a big hint what's actually wrong.

始终读取错误消息(和堆栈跟踪)。其中可能包含有价值的信息,可以帮助您隔离问题,以便解决问题。令人惊讶的是,许多工程师在寻求调试帮助之前忽略了错误消息所提供的洞察力。假设你的机器正在告诉你什么是错的,什么可能是正确的,而不是假设进行小的编辑和不断地重新运行代码会更快地解决问题。如果您编写的解决方案引发了异常,而没有仔细阅读异常,那么您可能是在浪费时间。通常错误或异常消息是一个很大的暗示,实际上是什么错了。

Design Docs

Importance of design docs 设计文档的重要性

Design documentation should not be an afterthought but an integral part of the software engineering process.
设计文档不应该是事后的想法,而是软件工程过程中不可分割的一部分。

A design document is a ubiquitous tool that can help you gain consensus from your peers or other teams who need to interface with your part of the system. Feedback from others enables you to identify gaps and refine your design. Design docs also serve as a valuable aid for engineers who would join the team in the future. It would help them understand the problem space and the trade-offs and alternatives considered when designing the solution. Design docs provide a space to capture all participants involved in the design and their contributions as part of the document history. This helps others understand who drove specific decisions and whom to contact for further elaboration.

设计文档是一种无处不在的工具,它可以帮助您从需要与您的系统部分进行交互的同行或其他团队那里获得共识。来自他人的反馈使您能够识别差距并改进设计。设计文档对于将来加入团队的工程师来说也是一种有价值的帮助。这将帮助他们了解问题空间以及在设计解决方案时考虑的权衡和替代方案。设计文档提供了一个空间来捕获设计中涉及的所有参与者及其贡献,作为文档历史的一部分。这有助于其他人了解是谁推动了具体的决策,以及与谁联系以进一步阐述。

Documentation process 文件编制过程

Coordinate reviews for the design doc and compare the design as it evolves with the original doc to verify that all the relevant constraints are being addressed.
协调设计文档的评审,并在设计与原始文档的演变过程中进行比较,以验证所有相关约束都得到了解决。

While one person can document the design, the actual design process occurs during a series of whiteboard meetings, random in-person discussions, slack threads, or email/phone discussions. Only after you put it down on paper can you identify contradictory commitments and see if the different parts you had discussed fit together. After creating the initial draft, coordinating a review ensures that all parties concerned are on board. However, it may happen that the implemented design does not match what is documented because something changed along the way.

虽然一个人可以记录设计,但实际的设计过程发生在一系列白板会议、随机面对面讨论、松散线程或电子邮件/电话讨论期间。只有在你把它写在纸上之后,你才能找出相互矛盾的承诺,看看你讨论过的不同部分是否适合在一起。在创建初始草案后,协调审查可确保所有相关方都参与其中。然而,可能发生的情况是,实现的设计与记录的内容不匹配,因为在此过程中发生了一些变化。

Communication

Be humble, communicate clearly, and respect others. It costs nothing to be kind, but the impact is priceless. Some may say good communication costs energy and thoughtfulness. There should be more energy for compassion.
要谦虚,沟通清楚,尊重他人。善良不需要付出任何代价,但它的影响是无价的。有些人可能会说,良好的沟通需要精力和体贴。应该有更多的同情心。

Communication is a critical part of the soft skills or people skills required to become an effective, productive, and efficient software engineer. Miscommunication can lead to incorrect functionality, incompatible code, or offensive team dynamic. Communication can help people understand requirements better and prevent issues from being escalated.

沟通是成为一名高效、多产和高效的软件工程师所需的软技能或人际技能的关键部分。错误的沟通可能导致不正确的功能、不兼容的代码或攻击性的团队动态。沟通可以帮助人们更好地理解需求,并防止问题升级。

The world may imagine software engineers to be people who spend their day writing code. However, to ensure that our products are helpful to others, we have to synchronize our efforts with others in the team and business and user expectations. This makes collaboration and communication the critical pillars of our jobs.

人们可能会把软件工程师想象成整天写代码的人。但是,为了确保我们的产品对其他人有帮助,我们必须与团队中的其他人以及业务和用户的期望同步我们的努力。这使得协作和沟通成为我们工作的关键支柱。

Junior developers mostly communicate with other team members, test engineers, and team leaders to share ideas and discuss alternatives for problem-solving. As we grow in our careers, the quantity of communication required to do our jobs effectively goes up. The number of emails, meetings, and public talks increases. We have to communicate with business leaders, managers, stakeholders, and team members. The more specialized your work, the greater the risk that others will not easily comprehend you.

初级开发人员大多与其他团队成员、测试工程师和团队领导交流,以分享想法并讨论解决问题的替代方案。随着我们在职业生涯中的成长,有效地完成工作所需的沟通数量也在增加。电子邮件、会议和公开演讲的数量增加。我们必须与业务领导者、经理、利益相关者和团队成员进行沟通。你的工作越专业,别人不容易理解你的风险就越大。

Customized communication 定制通信

Use language, concepts, and levels of detail relevant to your audience.
使用与受众相关的语言、概念和详细程度。

Whatever our level of understanding of a problem or a situation, when we discuss it with others, we have to tailor our words so that they can quickly grasp what is relevant to them:

无论我们对一个问题或一种情况的理解水平如何,当我们与他人讨论时,我们必须调整我们的措辞,以便他们能够迅速掌握与他们相关的内容:

  • When talking to a business person, talk about the business impact of what you are doing. Avoid using overly technical jargon.
    当你和一个商业人士交谈时,谈谈你所做的事情对商业的影响。避免使用过于专业的术语。

  • When talking to engineering management, communicate the technical impact or challenges.
    与工程管理人员交谈时,沟通技术影响或挑战。

  • When talking with a decision-maker, you describe available options and their implications and risks, not the details of how the options work.
    与决策者交谈时,你要描述可用的选项及其影响和风险,而不是选项如何运作的细节。

  • When providing a status update, be aware of what else has transpired and how your update is relevant to the project goals.
    在提供状态更新时,请注意还发生了什么,以及您的更新与项目目标的相关性。

The same principle applies when writing emails and presenting to a larger audience. Write what is relevant to the person or people receiving the message. You may have to defend your ideas when presenting. Phrase questions and responses in a thoughtful manner. Knee jerk responses are usually detrimental to communication.

同样的原则也适用于写电子邮件和向更大的受众展示。写下与接收信息的人相关的内容。你可能需要在陈述时为自己的观点辩护。以一种深思熟虑的方式提问和回答。膝跳反应通常对交流有害。

Being kind and considerate 善良体贴

Being nice is a superpower - wield it.
做个好人是一种超能力--好好运用它。

Being calm, kind, and helpful can take you further than cutting someone off. Be nice to people within your team as it will help make the team stronger and successful. Be friendly to those outside your team as well. Treat all the functions in your organization (HR, finance, or marketing) with equal respect. You may not help them directly, but you can always understand their work and empathize with them. Congratulate or appreciate others when they have done well or received accolades. Kindness is contagious. People you have been nice to are more likely to respond to any requests for assistance in the future.

冷静、善良和乐于助人比切断别人的联系更能让你走得更远。善待你团队中的人,因为这将有助于团队更强大和成功。对团队之外的人也要友好。平等地对待组织中的所有职能部门(人力资源、财务或营销)。你可能不会直接帮助他们,但你总能理解他们的工作,并与他们感同身受。当别人做得很好或获得荣誉时,要祝贺或感激他们。善良是会传染的。你一直善待的人更有可能在未来回应任何帮助请求。

Be liberal in telling folks they're doing a great job.
大方地告诉别人他们做得很好。

While it's important to give feedback when improvements are needed, it's also critical to give folks positive feedback if things are going well. This helps your team know that they're making a difference and are valued.

虽然在需要改进时给予反馈很重要,但如果事情进展顺利,给予人们积极的反馈也很重要。这可以帮助你的团队知道他们正在发挥作用并受到重视。

The power of NO NO的力量

Saying no is better than overcommitting.
说“不”总比过分承诺好。

Most of us are not great at saying "no" where more work is concerned. It is either because they don't realize that 'no' is an option, or we enjoy the challenge. However, overcommitting is a liability as it can lead to delays. Letting the other person know what is already on your plate and providing a reasonable estimate of how long it would take is a sign of respect. It gives the other person a chance to consider their options - ask someone else or extend their timeline. Management will not ask you to deliver something in record time if they know that it will significantly impact the quality of the product. If you are a senior manager, empower your team to say no to bad ideas.

我们中的大多数人都不擅长在涉及更多工作时说“不”。这要么是因为他们没有意识到“不”是一种选择,要么是我们喜欢挑战。然而,过度承诺是一种责任,因为它可能导致延误。让对方知道你已经在做什么,并合理估计需要多长时间,这是尊重的表现。这给了对方一个考虑自己选择的机会--问问别人或者延长他们的时间轴。管理层不会要求你在创纪录的时间内交付某些东西,如果他们知道这会显著影响产品的质量。如果你是一名高级管理人员,那就授权你的团队对坏主意说不。

""A senior developer (or any productive person) is good at saying no. People will ask for more of your time than you can spare. You can gently but firmly say no, direct people elsewhere (delegate), or ask people to discuss with your manager whether more of your time can be allocated to help them." [1]

“一个高级开发人员(或任何有生产力的人)都擅长说不。人们会要求你花更多的时间,而你却不能。你可以温和但坚定地说不,把人带到别处(委派),或者让人和你的经理讨论是否可以分配更多的时间来帮助他们。“[1]"

You can't please everyone - be extremely mindful when saying "yes" vs. "no".
你不可能让每个人都满意--在说“是”和“不”的时候要非常小心。

The counterpart to leaders saying "no" to everything is saying "yes" to everything and failing to set clear boundaries. Taking on more scope than can actually be executed reasonably well with your current resources can lead to heartache for you, your team and eventually your customers. This is particularly important for leaders to absorb as others will look to you to set the norms on when they should say "yes" or gently push back.

与领导人对一切说“不”相对应的是,对一切说“是”,而没有设定明确的界限。承担更多的范围,而不是用你目前的资源实际上可以合理地执行,这可能会导致你、你的团队和最终你的客户感到心痛。这一点对领导者来说尤其重要,因为其他人会指望你为他们什么时候应该说“是”或轻轻地推回去设定规范。

Acceptance and respect 接受和尊重

Admit when you don't know something and be open to asking for help, even from juniors.
承认你不知道的事情,并敞开心扉寻求帮助,即使是从晚辈。

It’s okay to admit when you don’t know something. One of the most important skills in software is being able to find answers and learn from them

承认你不知道的事没关系。软件中最重要的技能之一就是能够找到答案并从中学习

As a senior leader, learn to accept that juniors around you may be more aware of a project's technical nuances. It is okay to admit when you don't know something and let the junior engineers explain it. They will respect you more for your honesty and interest in learning, and you will get a better picture of what is going on and add value to it. As a junior engineer, you should explain technical concepts to seniors either openly or behind closed doors, depending on their comfort level.

作为一名高级领导者,要学会接受你周围的下级可能更了解项目的技术细微差别。当你不知道一些事情时,承认并让初级工程师解释是可以的。他们会因为你的诚实和学习兴趣而更加尊重你,你会更好地了解正在发生的事情并增加价值。作为一名初级工程师,你应该向高级工程师解释技术概念,无论是公开还是闭门,这取决于他们的舒适程度。

Information sharing 信息共享

Use meetings and Q&A sessions to ask the right questions, exchange knowledge and inform the team.
利用会议和问答环节提出正确的问题,交流知识并告知团队。

When running a meeting, don't be the only person talking. Meetings are an opportunity for others to share ideas and provide honest feedback - so listen and make space for others to contribute.

主持会议时,不要成为唯一发言的人。会议是其他人分享想法和提供诚实反馈的机会-所以倾听并为他人贡献空间。

Junior engineers may shy away from asking too many questions. If you are a senior, you can prompt them to ask the right questions by bringing up the context. When fielding questions, let the person asking know that you are glad they brought it up.

初级工程师可能会回避问太多的问题。如果你是一个高年级学生,你可以通过提出上下文来提示他们提出正确的问题。当回答问题时,让提问的人知道你很高兴他们提出了这个问题。

Flexibility

Defend your opinions stridently but also review them every time you have new evidence that contradicts them.
为你的观点辩护,但每次有新的证据与之相矛盾时,也要回顾一下。

Listening to other opinions is a key part of communication. It's essential because there may be more than one solution to a problem. Rather than being adamant about your views, listen and evaluate other options. Maybe they will bring forward an aspect that you had earlier overlooked. Paul Saffo's principle of "Strong opinions weakly held" tells us to defend our opinions stridently but also review them every time we have new evidence that contradicts them. It is a scientific evidence-based method that does not consider the person who came up with an idea or opinion.

倾听他人的意见是沟通的重要组成部分。这很重要,因为一个问题可能有不止一种解决方案。与其固执己见,不如倾听和评估其他选择。也许他们会提出一个你以前忽略的方面。 保罗·萨福的“强有力的观点弱有力的持有”原则告诉我们要尖锐地捍卫我们的观点,但每次我们有新的证据与之相矛盾时,也要回顾它们。这是一种基于科学证据的方法,不考虑提出想法或意见的人。

Maintaining a record 保持记录

A friendly email after an informal meeting helps reaffirm the key points or commitments made during the discussion.
非正式会议后的一封友好的电子邮件有助于重申讨论中的关键点或承诺。

A downside of exclusively verbal communication is that it can be forgotten or misremembered. Keeping a record of everything that transpired and getting a sign-off on relevant discussions eliminates this risk. If you or another person has agreed to help with a task, then confirm the deadline via email to ensure that everyone, including your supervisor, is on the same page. Keeping a record of such unplanned work would also be helpful during an appraisal discussion.

纯口头交流的一个缺点是它可能被遗忘或记错。记录所有发生的事情,并在相关讨论中签字,可以消除这种风险。如果你或其他人已经同意帮助完成一项任务,那么通过电子邮件确认截止日期,以确保每个人,包括你的主管,都在同一页面上。在评估讨论期间,对此类计划外工作进行记录也会有所帮助。

Good faith

Know when to keep quiet and observe the dynamics at play.
知道什么时候保持安静,观察比赛中的动态。

There may be situations where you don't understand some decisions, or they do not make sense for technical and business reasons. This may happen in multi-team discussions. Participate in good faith and assume that people will not risk being publicly malicious. Possibly you do not have the complete picture, or they have different priorities. Ask questions and state your opinions without getting angry or frustrated about the final decision.

在某些情况下,您可能不理解某些决策,或者由于技术和业务原因,这些决策没有意义。这可能发生在多团队讨论中。真诚地参与,并假设人们不会冒着被公开恶意的风险。可能你没有完整的图片,或者他们有不同的优先事项。提出问题并陈述你的观点,不要对最终的决定感到愤怒或沮丧。

Seniority

We aspire to grow in our career, either in our role or capabilities. While some are interested in senior technical positions, others wish to go for leadership or management roles. In either case, there are some key characteristics that people higher up in the seniority order exhibit. Throughout your journey, you may have mentors to guide your growth. Here's my approach to developing the qualities that can prepare you for a senior role.

我们渴望在我们的职业生涯中成长,无论是在我们的角色还是能力上。虽然有些人对高级技术职位感兴趣,但其他人希望担任领导或管理角色。无论哪种情况,资历较高的人都有一些关键特征。在你的人生旅途中,你可能会有导师来指导你的成长。以下是我的方法来培养你的素质,让你为高级职位做好准备。

Seniority and strategic thinking 资历和战略思维

Don't fail to make decisions or act given uncertainty.
不要在不确定的情况下不做决定或不采取行动。

Very often you will find that it's better to make any decision rather than no decision at all. It at least allows others to know what direction you're leaning towards. Sometimes as leaders we don't spend enough time reflecting on what decisions our teams are expecting us to make, but are not, because we're not 100% certain we have all the facts. We can and should try to build as complete a picture of the details needed to make confident decisions as we can, but this isn't always possible (e.g. in a time crunch). This can lead to long periods of waiting/uncertainty for teams where it can help to actively better yourself on how to make decisions even given limited information.

很多时候,你会发现做任何决定都比不做决定好。它至少让别人知道你倾向于什么方向。有时候,作为领导者,我们没有花足够的时间来思考团队希望我们做出什么样的决定,但事实并非如此,因为我们并不是100%确定我们掌握了所有的事实。我们可以也应该尽可能地建立一个完整的细节图,以做出自信的决定,但这并不总是可能的(例如在时间紧迫的情况下)。这可能会导致团队长时间的等待/不确定性,即使在信息有限的情况下,也可以帮助团队积极改善自己如何做出决策。

Leaders are people who have broadened their horizons to think strategically and lay out the roadmap for others.
领导者是那些拓宽了自己的视野,进行战略思考并为他人制定路线图的人。

Your ability to think and plan strategically and apply your thinking to larger scopes should ideally grow with experience. As an individual contributor, you may focus on assigned tasks or the features you are working on. The impact of your work extends beyond specific tasks and projects as you climb the ladder. When weighing options, you learn to look at the larger picture in terms of benefits and constraints. The scope of application of soft skills also increases. For example, if earlier you were making decisions for a team or addressing other engineers in your team, your choices and communication impact multiple teams as you grow.

你的思考和战略规划能力,以及将你的想法应用到更大范围的能力,应该随着经验的增长而增长。作为个人贡献者,您可以专注于分配的任务或您正在工作的功能。随着您的晋升,您的工作影响力将超出特定的任务和项目。在权衡选择时,你要学会从更大的角度看待利益和限制。软技能的应用范围也在扩大。例如,如果您以前为团队做出决策或与团队中的其他工程师沟通,那么随着您的成长,您的选择和沟通会影响多个团队。

Leading by example 以身作则

Teach your team to fish. Don't always solve problems for them, but gently guide them to develop the skills to solve themselves.
教你的团队钓鱼。不要总是为他们解决问题,而是温柔地引导他们发展自己解决问题的技能。

Engineering leaders empower. As you become more senior, it helps to give up your toys, coach, delegate & enable your team to succeed. It's how you scale effectiveness. This can be done by asking good questions more than (just) giving answers.

工程领导者授权。当你变得更高级时,给予你的玩具,教练,授权和使你的团队成功是有帮助的。这就是你如何提高效率。这可以通过提出好的问题而不仅仅是给出答案来做到。

You lead by example when assessing challenging problems and ask relevant questions when someone offers a solution.
在评估具有挑战性的问题时,你以身作则,并在有人提供解决方案时提出相关问题。

Seniors in the technical track are responsible for coordination, negotiation, and consensus-building within and outside their teams. They contribute to improving the overall team output and not just their own. As a senior engineer, you may occasionally code to acquire new skills or understand the ground reality, but that is not a part of your job description. Instead, you are someone who ensures that there aren't any missing pieces in the architecture diagram or loopholes in the code. You should be able to explain your decisions with evidence or reasons for how they would provide technical or business value.

在技术轨道的老年人负责协调,谈判,并在他们的团队内外建立共识。他们有助于提高整个团队的产出,而不仅仅是他们自己的产出。作为一名高级工程师,你可能偶尔会通过编码来获得新技能或了解实际情况,但这不是你工作描述的一部分。相反,您是确保架构图中没有任何缺失部分或代码中没有漏洞的人。您应该能够用证据或理由来解释您的决策,说明它们将如何提供技术或商业价值。

A senior engineer should be good at architecting software systems and human systems or teams. You can lead a diverse group of engineers, delegate tasks to them, mentor them to care about code quality/performance/simplicity. You can give feedback when required and defend them where necessary. At the same time, you should be able to market yourself, your work, and your ability to solve challenging problems to gain visibility in the organization. Overall, you should manage your relationships with people within your team and the management.

高级工程师应该擅长软件系统和人类系统或团队的架构。你可以领导一个多元化的工程师团队,将任务委派给他们,指导他们关注代码质量/性能/简单性。您可以在需要时给予反馈,并在必要时为它们辩护。同时,你应该能够推销自己,你的工作,以及你解决挑战性问题的能力,以获得组织的知名度。总的来说,你应该管理好你与团队和管理层中的人的关系。

Scale your effectiveness. 提升你的效率。

The world’s best engineering feats are accomplished by a team of engineers, not individuals. So, if you are trying to accomplish more, or show you're ready to become more “senior” in your company, multiply your effectiveness through collaboration and mentorship. Demonstrate how this adds value not only to yourself, but to other members of your team.

世界上最好的工程壮举是由一个工程师团队完成的,而不是个人。所以,如果你想完成更多的工作,或者想表现出你已经准备好在公司里变得更“高级”,那就通过合作和指导来提高你的效率。证明这不仅为你自己,而且为团队的其他成员增加了价值。

I felt like I was on the path to being a senior engineer at Google when I realized that to scale myself, I had to shift my mindset from "me" to "we". By collaborating with others, sharing what I learned, and focusing on lifting the skills and the expertise of people around me, we started to get so much more done.

当我意识到要想扩大自己的规模,我必须将思维模式从“我”转变为“我们”时,我感觉自己正在成为谷歌的高级工程师。通过与他人合作,分享我学到的东西,并专注于提升我周围人的技能和专业知识,我们开始做得更多。

When you start out as an individual contributor, you may not have a dedicated “team” you lead, but you can find like minded people to collaborate with (maybe aligned with your goals) and work together to accomplish a lot more than you could alone. As you get more senior, you evolve this thinking towards building out teams and continuous growth of your effectiveness.

当你开始作为一个个人贡献者,你可能没有一个专门的“团队”,你领导,但你可以找到志同道合的人合作(也许与你的目标一致),并共同努力,以完成更多的比你可以单独。随着你的职位越来越高,你会把这种想法发展到建立团队和不断提高你的效率。

Imposter syndrome

Accepting that it is okay to make mistakes, not know answers, or seek guidance can help overcome imposter syndrome.
承认犯错、不知道答案或寻求指导都是可以的,可以帮助克服冒名顶替综合症。

All of us have felt inadequate for a particular role or job at some point or other. Imposter syndrome is genuine and very common. It can affect even those who are evidently successful. You might feel like an imposter even as others look up to you for advice. You may never be cured of the syndrome, but it will push you to be curious and learn new things.

我们所有人都曾在某个时候或其他时候感到自己不适合某个特定的角色或工作。冒名顶替者综合征是真实的,非常常见。它甚至可以影响那些明显成功的人。你可能会觉得自己像个骗子,即使别人向你寻求建议。你可能永远无法治愈这种综合症,但它会促使你保持好奇心,学习新事物。

Mentoring

Mentoring others

Be the guardrail by giving timely information so that your mentees do not end up in a completely incorrect place but instead gain mastery by doing things themselves.
通过提供及时的信息来成为护栏,这样你的学员就不会最终陷入完全错误的地方,而是通过自己做事情来掌握。

You may find yourself in a mentor or mentee role at different times in your career. Mentoring need not be a formal process. You can look for opportunities to mentor others or allow yourself to be mentored even informally. Mentoring others gives you a chance to learn people skills yourself. Following are some key points to remember while mentoring.

您可能会发现自己在职业生涯的不同时期担任导师或学员的角色。指导不必是一个正式的过程。你可以寻找机会指导他人,或者允许自己接受非正式的指导。指导别人可以让你有机会自己学习人际交往的技巧。以下是指导时需要记住的一些要点。

Mentoring is about guiding people to discover answers themselves rather than giving them ready-made solutions. Allow your mentees to experiment when solving their problems. They are in the best position to assess risks and benefits. However, please give them the tools required to find answers. If it's a technical problem, suggest ideas and options to try out, but let them do the actual legwork. Let them share what they think and listen closely, ask questions, and engage in a dialog.

指导是引导人们自己去发现答案,而不是给他们现成的解决方案。允许学员在解决问题时进行实验。他们处于评估风险和收益的最佳位置。但是,请给予他们找到答案所需的工具。如果这是一个技术问题,建议的想法和选择尝试,但让他们做实际的跑腿工作。让他们分享他们的想法,仔细倾听,提问,并参与对话。

If someone fails to figure out solutions by themselves, show them how you would approach the problem and why you chose a particular pattern to solve it. Teach them how to analyze results or debug issues. Share your thought process as you diagnose the problem, try out solutions, implement them and debug them. Share your problem-solving techniques and not just the answer.

如果有人不能自己找到解决方案,向他们展示你将如何解决这个问题,以及为什么你选择了一个特定的模式来解决它。教他们如何分析结果或调试问题。在您诊断问题、尝试解决方案、实施解决方案和调试解决方案时,分享您的思维过程。分享你解决问题的技巧,而不仅仅是答案。

Organization-wide mentoring 全组织指导

Ensuring that mentorship is a part of a senior engineer's role also helps retain crucial domain knowledge when someone moves to another team, position, or organization.
确保指导是高级工程师角色的一部分,也有助于在某人转到另一个团队、职位或组织时保留关键的领域知识。

Suppose you are sincere about mentoring someone, and it is also a part of your job description. In that case, you have to make time in your schedule for mentoring activities. This will allow you to do it properly and make a difference in your mentees' lives. Some organizations may also have a defined process for the mentor/mentee discussions based on the career progression ladder and requirements for each step.

假设你真诚地想指导某人,这也是你工作描述的一部分。在这种情况下,你必须在你的时间表中为指导活动腾出时间。这将使您能够正确地完成它,并在您的学员的生活中发挥作用。一些组织还可能根据职业发展阶梯和每个步骤的要求,为导师/学员讨论制定了明确的流程。

Mentee's role

Mentors can offer you advice, but you are the only one who can take the initiative and act on any advice to manage your career and growth.
导师可以为你提供建议,但你是唯一一个可以采取主动并根据任何建议采取行动来管理你的职业生涯和成长的人。

Suppose you are a junior engineer who wishes to grow in an organization. In that case, there is only one piece of advice for you. Find strong mentors who can help you navigate the growth ladder.

假设你是一名初级工程师,希望在一个组织中成长。在这种情况下,只有一个建议给你。找一个能帮你在成长阶梯上导航的有能力的导师。

You will come across coaches, mentors, or colleagues you look up to throughout your career. They can offer you advice on how to develop your skills but you are the one who can act on it. When assimilating advice, beware of blanket statements regarding technology. Different situations need different principles, and what worked for one project may not work for another.

在你的职业生涯中,你会遇到你尊敬的教练、导师或同事。他们可以给你建议如何发展你的技能,但你是一个谁可以采取行动。当吸收建议,小心有关技术的笼统声明。不同的情况需要不同的原则,适用于一个项目的原则可能不适用于另一个项目。

Effective teams

Building Trust

Trust can unite team members to work towards a common goal while bureaucracy will divide them.
信任可以使团队成员团结起来,朝着共同的目标努力,而官僚主义则会使他们分裂。

When engineers come together for open-minded and unbiased brainstorming, it paves the way for new ideas and different perspectives that drive innovation. This leads to highly efficient and productive teams. However, effective collaboration among team members is only possible if the communication and relationships amongst team members are healthy. Here are some pointers for building, maintaining, and becoming a part of effective teams.

当工程师聚集在一起进行开放和公正的头脑风暴时,它为推动创新的新想法和不同观点铺平了道路。这导致了高效和富有成效的团队。然而,只有当团队成员之间的沟通和关系是健康的,团队成员之间的有效协作才是可能的。这里有一些建立、维护和成为有效团队一部分的建议。

Building trust is the most critical component of team building. Trust amongst team members across the hierarchy is necessary to get things done fast and for teams to be effective. Team members may use different software engineering processes such as reviews and tests for reviewing project health. However, these processes become tedious and bureaucratic without trust. For example, you will probably nitpick less during a code review if you trust an engineer with some code.

建立信任是团队建设中最关键的组成部分。跨层级的团队成员之间的信任对于快速完成任务和团队高效是必要的。团队成员可以使用不同的软件工程过程,如评审和测试,以评审项目健康状况。然而,如果没有信任,这些过程就会变得繁琐和官僚。例如,如果你信任一个工程师的一些代码,你可能会在代码审查中少挑剔。

Understanding the business model 了解商业模式

Understand the business impact of the change.
了解变更的业务影响。

When you receive a new set of requirements, understand the motivation behind them. Don't skim over the 'purpose' or 'business goals' section of the requirement documents. Ask questions to understand the business model and its relation to these requirements. An existing codebase or talking to subject-matter-experts (SMEs) can provide insights about the domain and the architecture. Refer to the documentation or map features and use cases to system processes and data flows.

当您收到一组新的需求时,请理解它们背后的动机。不要浏览需求文档中的“目的”或“业务目标”部分。提出问题以了解业务模型及其与这些要求的关系。现有的代码库或与主题专家(SME)交谈可以提供关于领域和体系结构的见解。参考文档或将功能和用例映射到系统流程和数据流。

""A lot of software engineers love to solve problems with a technical challenge. It can be more rewarding to understand the business side of things and be able to come up with cost effective solutions. Remember that your users/customers are also people trying to do their job, and get through the day or week, just like you are. Try not to make their lives harder than they already are." [1]

“很多软件工程师喜欢用技术挑战来解决问题。了解事物的业务方面并能够提出具有成本效益的解决方案可能会更有价值。请记住,你的用户/客户也是那些努力工作的人,他们和你一样,每天或每周都在努力工作。尽量不要让他们的生活比他们已经更困难。“[1]"

Increase your impact 增加您的影响力

Perceptiveness and astuteness about the business-software equation increases the impact of your work.
对业务软件等式的洞察力和敏锐度会增加您工作的影响力。

Getting a 360-degree view of the business and the product helps you contribute positively to the team and your projects. If you understand how sales or marketing think, you are better equipped to make the right decisions and do high-impact work. As your impact on a team's success increases, your job satisfaction and pay will improve. Your seniors will recognize your ability as a self-starter who can work independently without supervision and drive overall efficiency by doing what is suitable for the team, project, and business.

获得业务和产品的360度视图有助于您为团队和项目做出积极贡献。如果你了解销售或市场营销的思维方式,你就能更好地做出正确的决策,并做好高影响力的工作。随着你对团队成功的影响力增加,你的工作满意度和薪水也会提高。你的上司会认可你作为一个自我激励者的能力,你可以在没有监督的情况下独立工作,并通过做适合团队、项目和业务的事情来提高整体效率。

Work/life balance

If you are someone who has gained mastery over technical abilities, human factors, and domain knowledge, your skills as a software engineer will invariably be in demand. People in your team and organization will consult you. In addition to your engineering commitments, you will become a victim of collaboration overload. Ad-hoc requests can eat into your time and stop you from doing what you are passionate about.

如果你是一个掌握了技术能力、人为因素和领域知识的人,那么你作为软件工程师的技能将总是需要的。你的团队和组织中的人会向你咨询。除了您的工程承诺之外,您还将成为协作过载的受害者。临时的要求会占用你的时间,让你无法做自己热衷的事情。

Time management

Optimize your calendar for Deep Work
为深度工作优化日历

Block time on your calendar for focused deep work. I’ve done this for years and found it highly effective for writing design or strategy docs or just working on a hard technical problem. Deep work is distraction-free, high concentration work that creates a lot of value in a little time. Cal Newport’s Deep Work covers this topic well.

在你的日历上留出时间,专注于深度工作。我已经这样做了很多年,发现它对编写设计或策略文档或只是处理一个困难的技术问题非常有效。深度工作是一种不受干扰、高度集中的工作,它能在很短的时间内创造很多价值。Cal纽波特的深度工作很好地涵盖了这个主题。

Attention residue is an idea Cal talks about being why working deeply for extended periods is so beneficial. Every time you’re switching from one task to another, a residue of your attention remains stuck thinking about the previous task. This makes it hard to work with the necessary focus on what's really important.

注意力残留是卡尔谈到的一个想法,这就是为什么长时间深入工作是如此有益。每次你从一个任务切换到另一个任务时,你的注意力的残余仍然停留在思考前一个任务上。这使得它很难与必要的重点是什么真正重要的工作。

Deep work maximizes the amount of productivity you squeeze out of a limited time by focusing on a single task. No distractions, no Twitter, no chat or email. You reserve deep work for tasks that are cognitive heavy. I highly recommend trying it out.

深度工作通过专注于一项任务,最大限度地提高你在有限时间内挤出的生产力。没有分心,没有Twitter,没有聊天或电子邮件。你把深度工作留给认知繁重的任务。我强烈推荐你试一试。

I’ve also found that changing my location can sometimes help with deep work. We can sometimes fall into the trap of associating a specific place (like a desk, room or building) with a particular kind of task and adding a little variety can help reinvigorate us.

我还发现,改变我的位置有时可以帮助深入的工作。我们有时会陷入这样的陷阱:把一个特定的地方(比如桌子、房间或建筑物)与一种特定的任务联系起来,增加一点多样性可以帮助我们重新振作起来。

Avoid fracturing your working hours
避免打破你的工作时间

When an hour of work gets broken up into chunks of just a few minutes due to distractions, you become stressed. Identify the causes of distractions (whether it's you or others) and fix it. Otherwise your day won't be as productive.

当一个小时的工作由于分心而被分成几分钟的小块时,你会感到压力。找出分心的原因(不管是你还是别人)并解决它。否则你的一天就不会有效率。

Working in excess isn’t part of a good work ethic.
过度工作不是良好职业道德的一部分。

You can never work harder than everyone in the world. Many companies hold up overworked employees as the "standard", falsely concluding this is the same as having a good work ethic. Success comes from many factors and not just overworking.

你永远不可能比世界上任何人都努力。许多公司把过度劳累的员工作为“标准”,错误地得出结论,认为这与良好的职业道德是一样的。成功来自很多因素,而不仅仅是过度工作。

Constantly trying to outdo your standards is unrealistic.
总是试图超越你的标准是不现实的。

I have been guilty of this a lot. If you want to develop calm and avoid a crazy work environment, you must get comfortable with enough. As a manager or lead, your team might take your lead on how to approach this. Being OK with enough can set a good example.

我为此感到内疚了很多。如果你想培养冷静,避免一个疯狂的工作环境,你必须适应足够的。作为经理或领导,您的团队可能会在如何处理这一问题上领先于您。知足常乐可以树立一个好榜样。

Time is finite. Instead of trying to seek more time, eliminate unnecessary tasks.
时间是有限的。不要试图寻求更多的时间,而要消除不必要的任务。

Lots of guidance talks about rearranging work better. The real problem is trying to accomplish too much to begin with. Ruthlessly eliminate work that's unnecessary and time wasting vs. trying to manage limited time.

很多指导都在谈论如何更好地重新安排工作。真实的的问题是试图完成太多的开始。无情地消除那些不必要的和浪费时间的工作与试图管理有限的时间。

You don't have to know every last thing going on.
你不需要知道每一件事。

Many of us are afraid of missing out on every new story or update. This is one reason people get obsessed about checking Twitter, Reddit, Instagram etc every hour. I've certainly been through this. In reality, most of this information is just not that important. Instead, try switching to summary views of this news or set limits on how often you check it.

我们中的许多人都害怕错过每一个新的故事或更新。这也是人们每小时都要查看Twitter、Reddit、Instagram等网站的原因之一。我也经历过这些。事实上,这些信息中的大部分并不那么重要。相反,试着切换到这条新闻的摘要视图,或者限制你查看它的频率。

There are further thoughts on this topic in "It doesn't have to be crazy at work" by Jason Fried.

在Jason Fried的“It doesn't have to be crazy at work“一书中,有关于这个话题的进一步思考。

It's best to proactively save yourself from exhaustion by learning to say no, knowing when to stop, and planning your time to include breaks between work.
最好的办法是通过学会说“不”,知道什么时候该停下来,计划好你的时间,包括工作之间的休息时间,来主动地保存自己远离疲惫。

Time management and maintaining a good work-life balance are crucial for engineers at all levels. Regularly working overtime can lead to burnout and stress. Stress can cause other physical and mental health complications. It may be tempting to resolve an issue before you call it a day, but it could become a habit over time.

时间管理和保持良好的工作与生活平衡对各级工程师至关重要。经常加班会导致倦怠和压力。压力会导致其他生理和心理健康并发症。在你结束一天之前解决一个问题可能很诱人,但随着时间的推移,它可能会成为一种习惯。

Encourage breaks, holidays, and vacations both for yourself and your team.
鼓励你和你的团队休息、度假和休假。

Your health and family are vital. If you realize this as a senior engineer and set an excellent example for others in a team, it will foster overall wellbeing and happiness. On the other hand, exhaustion and burnout can lead to toxicity in the workplace.

你的健康和家庭至关重要。如果你作为一名高级工程师意识到这一点,并为团队中的其他人树立了一个很好的榜样,这将促进整体的幸福和快乐。另一方面,疲惫和倦怠会导致工作场所的毒性。

Update estimates as your understanding of problems improves

随着您对问题的理解的提高,更新估计

There will almost always be a customer or stakeholder for your work that will want to know when a project or task can be delivered and if this cost is worthwhile. This is totally reasonable. Sometimes they want to match a deadline or there are dependencies elsewhere that need to support your engineering work requiring planning.

几乎总是会有客户或利益相关者想知道项目或任务何时可以交付,以及这笔费用是否值得。这是完全合理的。有时他们想要匹配截止日期,或者在其他地方存在依赖关系,需要支持需要规划的工程工作。

Software deadlines are notoriously difficult to predict accurately. Deadlines that are based on estimates should only be given when projects are at a particular stage. When time passes, estimates should get updated as we learn more about the team's ability to solve the problem (the "informed" estimate). The first estimate (the "sizing") is often the least reliable, however it is a starting point that can get refined over time. This initial estimate is often very conservative - should the product requirements, UX or dependencies be unclear, a larger conservative estimate is often helpful for that first "size". I often have the best success here when such estimates are approached collaboratively with PMs so we are all on the same page about refining them.

众所周知,软件的截止日期很难准确预测。只有当项目处于特定阶段时,才应给出基于估计的截止日期。随着时间的推移,随着我们对团队解决问题的能力了解的更多,估计应该得到更新(“知情”估计)。第一个估计值(“大小”)通常是最不可靠的,但是它是一个可以随着时间的推移而改进的起点。这个初始估计通常是非常保守的--如果产品需求、用户体验或依赖性不清楚,则较大的保守估计通常对第一个“大小”有帮助。当与项目经理合作处理这些估计时,我经常会取得最大的成功,所以我们都在同一页上对它们进行细化。

The trouble with software estimates is when the first rough estimate gets cemented as the plan of record rather than a first draft. When teams on the critical path adopt it but view adjustments to the estimates as a hiccup by engineering (vs. step 1/n of an informed estimate) this can be an issue. Once a project has the greenlight, figure out the details better - this may mean an estimate of three months becomes two (or four) based on a deeper understanding of what will address the requirements.

软件评估的麻烦在于,当第一个粗略的评估被固定为记录计划而不是第一个草案时。当关键路径上的团队采用它,但将对评估的调整视为工程上的小问题时(与有根据的评估的步骤1/n相比),这可能是一个问题。一旦一个项目获得批准,就应该更好地确定细节--这可能意味着,基于对满足需求的更深入理解,三个月的估计可能会变成两个(或四个)。

You almost always want the estimates driving your schedule vs. having the schedule drive the estimates where possible. In my teams, while we do sometimes have unmovable deadlines (e.g. a conference), if the estimates overshoot these dates that's (often) fine - changing messaging (e.g. "preview"), framing ("coming in the near future") or punting to a future are always options we can discuss with leadership. I of course acknowledge this is not always trivial. When schedules do try to be pulled in, you can break work up into must-have vs. nice-to-have (and move these to a future sprint) then review if the must-haves meet your deadline.

您几乎总是希望评估能够推动您的计划,而不是让计划在可能的情况下推动评估。在我的团队中,虽然我们有时确实有不可移动的最后期限(例如会议),但如果估计超过了这些日期,那(通常)很好-改变消息传递(例如“预览”),框架(“不久的将来”)或将其推向未来总是我们可以与领导层讨论的选择。当然,我承认这并不总是微不足道的。当你的日程表确实被拉进来的时候,你可以把工作分成必须的和最好的(并把它们移到未来的sprint),然后检查必须的是否符合你的截止日期。

Should schedules still be too tight, there are other questions you can ask, such as "Can we add additional engineers to this project?" and "is there a large reduction of scope that would still make shipping on time compelling?".

如果时间表仍然太紧,您可以问其他问题,例如“我们可以为这个项目增加更多的工程师吗?””和“是否有一个大的范围缩小,仍然会使航运准时引人注目?“.

Cancelling projects is sometimes the right (if uncomfortable) call.

取消项目有时是正确的(如果不舒服)。

I hate this one, but cancelling a project can sometimes be the healthiest long-term decision for your team and organization. This is especially true if it is cancelled before it has had a chance to launch, gain traction then ultimately has to be deprecated because staffing on it can no longer be sustained. In case folks are wondering, yes I read Killed By Google. Aim to minimize the circumstances leaning up to projects getting cancelled as much as you can. I recently cancelled a multi-year project and it was rough.

我讨厌这个,但是对于你的团队和组织来说,取消一个项目有时是最健康的长期决定。尤其是如果它在有机会推出之前被取消,获得牵引力,然后最终不得不被弃用,因为它的人员配置无法再持续下去。如果人们想知道,是的,我读了《被谷歌杀死》。尽可能减少项目被取消的可能性。我最近取消了一个多年的项目,这是粗糙的。

When can this happen? You can make decisions about investing in a new project that are the right ones for a point in time. At that point in time, the stars may well have aligned (market-fit, organizational buy-in, staffing commitments) for it to completely make sense. A year down the line, things can change - the market, leadership, importance of the project. It's critical to regularly check on whether the assumptions you made when a project started continue to remain true through its lifetime.

什么时候能这样?你可以做出投资新项目的决定,这些决定在某个时间点是正确的。在那个时候,明星可能已经结盟(市场适合,组织买入,人员配置承诺),使其完全有意义。一年下来,事情可能会发生变化--市场、领导力、项目的重要性。定期检查您在项目开始时所做的假设是否在整个生命周期内都是正确的,这一点至关重要。

The more you can sustain confidence the assumptions are still true, the better a shot you have at the project being able to successfully launch and continue to be supported. Cancellations are hard for a number of reasons, not least that there are real people with real emotions who invested in building what they had hoped would launch. As a leader, navigating folks back out of a cancelled project onto others that successfully launch is complex, but important for getting folks back to a place of psychological safety, trust and happiness. On the customer side, be mindful of user trust and how your long-term decisions can impact this.

你越能保持信心,假设仍然是正确的,你就越有机会成功启动项目并继续得到支持。取消是很难的,原因有很多,尤其是有真实的的人与真正的情感谁投资于建设什么,他们希望将推出。作为一名领导者,引导人们从一个被取消的项目中回到其他成功启动的项目中是复杂的,但对于让人们回到一个心理安全、信任和幸福的地方很重要。在客户方面,要注意用户的信任以及您的长期决策如何影响这一点。

On technical debt: An ounce of prevention is worth a pound of cure

关于技术债务:一分预防胜过磅治疗

Titus Winters defines technical debt as "the difference between the code and systems we have today vs what we wish we had" with certain kinds of debt having a higher impact than others. Some debt can be due to mistakes that weren't caught early (oversight), others due to what was learned after-the-fact (hindsight) and some are due to the landscape of technical systems changing (context).

Titus Winters将技术债务定义为“我们今天拥有的代码和系统与我们希望拥有的代码和系统之间的差异”,某些类型的债务比其他债务具有更高的影响。有些债务可能是由于没有及早发现的错误(疏忽),其他债务是由于事后学到的东西(事后诸葛亮),还有一些债务是由于技术系统的环境变化(上下文)。

I have found that consistently prioritizing tackling technical debt is sometimes hard as you can't always quantify the bugs that didn't manifest or outages that didn't happen because you "paid debt down enough". Sustaining team interest in this kind of work and rewarding it during performance reviews is also really important. The cost of the "cure" however can be so much higher once problems really start to pile up over time. Similar to pollution, over the course of multiple years, prevention of technical debt is a cheaper strategy than mitigation at a later point.

我发现,始终如一地优先处理技术债务有时很难,因为你不能总是量化那些没有出现的bug,或者因为你“支付了足够多的债务”而没有发生的中断。保持团队对这类工作的兴趣,并在绩效评估中给予奖励也非常重要。然而,一旦问题真的开始随着时间的推移而堆积起来,“治愈”的成本可能会高得多。与污染类似,在多年的过程中,预防技术债务是一种比以后减缓成本更低的战略。

What can you do to prevent debt building up? Technical leads should regularly devote time in sprints to clean-ups and paying debt down in addition to building out new features. Reviewers should be cognizant of pushes for short-term velocity that may actually lead to problems further down the line. Managers and directors should be mindful of approving new projects that overlap with existing ones, unless you're certain the trade-offs are worthwhile(e.g. addressing debt in existing system just isn't worth it vs. building something new). Monitoring of project health is really important on top of all of this.

你能做些什么来防止债务积累?技术主管应该定期在sprint中投入时间来清理和偿还债务,以及构建新功能。评审员应该认识到,对短期速度的追求实际上可能会导致问题的进一步发展。管理者和董事应该注意批准与现有项目重叠的新项目,除非你确定权衡是值得的(例如,解决现有系统中的债务与建立新的东西相比不值得)。在所有这些之上,监控项目的健康状况非常重要。

Without breaks and a good work/life balance, you or your team can burnout.

如果没有休息和良好的工作/生活平衡,你或你的团队可能会精疲力竭。

Burnout is a form of exhaustion due to workplace stress that hasn't been successfully managed. I've seen many engineers hit burnout during the pandemic due to work stress, but it has always been present in tech. These days, I ask my reports, "how are your stress levels doing? what can I do to help?" in each 1:1.

倦怠是一种由于工作压力而导致的疲惫,这种压力没有得到成功的管理。我见过很多工程师在疫情期间因工作压力而精疲力竭,但这种情况一直存在于科技行业。这些天,我问我的报告,“你的压力水平如何?我能帮什么忙吗?”在每个1:1。

My experience with burnout is that it happens slowly and ends in apathy. You slowly start to feel low on energy, unmotivated, and exhausted all the while trying to cope with work stress as best you can. You question if there's something wrong with you, but fail to realize your body is working overtime to compensate for the lack of energy you have. You keep pushing yourself harder and harder, but eventually it feels like there's not much left to give.

我对倦怠的经验是,它发生得很慢,最后以冷漠告终。你慢慢地开始感到精力不足,没有动力,并且在尽你所能科普工作压力的同时筋疲力尽。你怀疑自己是不是出了什么问题,但却没有意识到你的身体正在加班加点地工作,以弥补你缺乏的能量。你不断地给自己施加压力,但最终你会觉得没有多少东西可以给予。

I hit burnout about 5 years ago, however am happy to say I turned it around. What led to it? It was an avalanche of things. I had been putting work first for years, working longer and longer hours and not saying "no" enough. I never took enough breaks or vacations. I was averaging 5 hours of sleep a night. When I was home, I was so low on energy that I wasn't "being present" nearly as much as I should have for my family. The "fix" was doing the opposite of those things: take breaks, get more sleep, squeeze more value out of the hours I do work, delegate better, and have a clear "stopping time" for work.

大约5年前,我遇到了倦怠,但我很高兴地说,我扭转了局面。是什么导致的?这是一个雪崩的东西。多年来,我一直把工作放在第一位,工作时间越来越长,而且说“不”的次数还不够多。我从来没有得到足够的休息或假期。我平均每晚睡5个小时。当我在家的时候,我的精力是如此的低落,以至于我没有像我应该为我的家人做的那样“在场”。“修复”是做相反的事情:休息一下,多睡一会儿,从我工作的时间里挤出更多的价值,更好地分配工作,并有一个明确的工作“停止时间”。

As managers, to avoid our reports burning out, I think it's important to try encouraging our teams to use their vacation time, take breaks and periodically check folks are actually doing okay where stress is concerned.

作为管理者,为了避免我们的报告被烧毁,我认为重要的是要鼓励我们的团队利用他们的假期,休息一下,定期检查人们在压力方面是否做得很好。

Executing in large organizations can feel slow. There are ways to navigate this.

在大型组织中执行可能会感觉很慢。有很多方法可以导航这个。

I've had many conversations with engineers that boil down to "why is shipping X moon-shot in (big org) so hard?". There's a great analogy by Alex Komoroske comparing large organizations to slime molds. That is to say, executing even simple things can start to feel way way slower than you might expect, due to coordination headwinds. Organizations have complex systems, structures and dynamics and headwinds rise when the number of people who must coordinate on a project increases.

我和工程师们有过很多次谈话,归结起来就是“为什么在(大组织)运送X月球探测器这么难?”“. Alex Komoroske有一个很好的类比,将大型组织比作黏菌。也就是说,由于协调的阻力,即使是执行简单的事情也会开始感觉比你预期的慢得多。组织具有复杂的系统、结构和动态,当必须协调项目的人数增加时,阻力就会增加。

There are many forces at play here, including underestimation of the difficulty of other's tasks (e.g. if they're building a dependency). You can't ignore these problems as it can make the dysfunction spread. One way to work through such headwinds is to decouple things as much as possible so they can land on an OK timeline and eventually converge towards shipping X.

这里有很多因素在起作用,包括低估他人任务的难度(例如,如果他们正在建立依赖关系)。你不能忽视这些问题,因为它可以使功能障碍蔓延。克服这种不利因素的一种方法是尽可能地解耦,这样它们就可以在一个OK的时间轴上着陆,并最终朝着发布X的方向收敛。

Rather than tackling all of X from the get-go, you can avoid solely shooting for the moon-shot (large risk efforts) and instead define roof-shots (safe steps to unlock value) that move you closer to your goals. I strongly recommend reading Alex's deck if this problem sounds familiar.

与其从一开始就解决所有的X问题,你可以避免只为登月而射击(大风险的努力),而是定义屋顶射击(释放价值的安全步骤),让你更接近你的目标。我强烈建议阅读亚历克斯的甲板上,如果这个问题听起来很熟悉。

Focus on problems vs. projects 专注于问题与项目

Let's imagine your users have an unsolved need (e.g. a problem). When you're an engineer attached to a particular project, it's normal to ask how your specific project is going to solve this problem (a local maxima). In a large organization with projects of similar shapes, it's very possible to see multiple engineers trying to independently think this way ("how does my project solve this problem?"). When you own a portfolio of projects however, this may not quite be clear-cut. What if users may use many of your projects together? Wouldn't it be weird if they each solved the problem in a slightly different way unaware of each other's approach? Instead, you want to ask "what's the right end-to-end solution to this problem?" and walk back to what project or changes to a series of projects will holistically address this need best. It may require getting folks working on the multiple related projects to collaborate more deeply. This can however result in a better, less confusing story for your users at the end of the day.

Conclusion

""Surround yourself by excellence and work with people who are the best at what they do" - Brian Staufenbiel

“让自己置身于卓越之中,与最擅长自己工作的人一起工作”- Brian Staufenbiel"

Invest in friendships and relationships with folks you can learn from. Be open to their guidance, mentorship, their successes, and their failures. Never be afraid to ask for help or insight. In a lot of cases, it's just a question away.

与你可以学习的人建立友谊和关系。他们的指导,他们的成功,他们的失败。永远不要害怕寻求帮助或洞察力。在很多情况下,这只是一个问题。

At every stage, remember that mastery over technology, business domain, and human resources at a given organization has to be cultivated over time. An organization cannot hire masters from another and expect them to be productive from day one. If you are a good engineer, you will contribute to your organization's growth. In return, new avenues will be available to you, allowing you to acquire new skills and grow yourself.

在每一个阶段,请记住,在一个给定的组织中,对技术、业务领域和人力资源的掌握必须随着时间的推移而培养。一个组织不能从另一个组织那里雇佣大师,并期望他们从第一天起就富有成效。如果你是一个优秀的工程师,你将为你的组织的发展做出贡献。作为回报,新的途径将提供给你,让你获得新的技能和成长自己。

With thanks to Leena Sohoni, Joshua Cruz, Kara Erickson, Jeff Posnick, Houssein Djirdeh and Sriram Krishnan for their kind feedback and contributions.

感谢Leena Sohoni、约书亚Cruz、Kara Erickson、Jeff Posnick、Houssein Djirdeh和Sriram Krishnan的反馈和贡献。

版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://blog.csdn.net/weixin_38556197/article/details/129685890

智能推荐

Coarse to Fine Vertebrae Localization and Segmentation论文笔记_spatialconfiguration-net-程序员宅基地

文章浏览阅读1.2k次。Coarse to Fine Vertebrae Localization and Segmentation with SpatialConfiguration-Net and U-Net 论文研读笔记文章目录Coarse to Fine Vertebrae Localization and Segmentation with SpatialConfiguration-Net and U-Net 论文研读笔记前言一、Abstract二、Method2.1 Spine Localization2.读入数据总_spatialconfiguration-net

微信小程序制作_uview怎么添加到小程序-程序员宅基地

文章浏览阅读385次,点赞2次,收藏4次。打开微信开发者工具后, 新建一个新的文件。开始配置首先在资源管理器中,可以看到初始文件拥有 miniprogram 文件夹, 找到app.json在json 配置文件中, 可以查询到 "page" 属性此时,在minprogram文件夹有会生成page的文件夹且拥有5个新的页面, 该文件为小程序中的各个子页面 "tabBar": { "list" : [{ "pagePath": "page/index/index-1", "text": "首页", ._uview怎么添加到小程序

分布式事务 (五) Seata AT模式-Spring Cloud微服务添加 AT 分布式事务_springcloudseata开启at-程序员宅基地

文章浏览阅读148次。文章目录下载订单项目案例(无事务版)Seata Server - TC全局事务协调器Seata Server 配置registry.conffile.conf启动参数设置启动 Seata Serverorder订单服务添加 Seata AT 事务order-parent 添加 seata 依赖配置application.ymlregistry.conffile.conf创建 seata 数据源代理启动全局事务启动 order 项目进行测试测试出现异常,回滚的情况storage库存服务添加 Seata AT _springcloudseata开启at

python运行时出现MySQLdb._exceptions.OperationalError错误解决方法_(mysqldb._exceptions.operationalerror) (1115, "err-程序员宅基地

文章浏览阅读9.7k次。上篇安装好mysqlclient之后进行连接mysql数据库,在连接的过程中出现以下错误:MySQLdb._exceptions.OperationalError:(2059,<NULL>)经过一番查找得知是因为mysql版本与我所使用的Python Flask不兼容,因此出现以上错误环境:mysql8.0 flask更多关于该错误在stackoverflow上的..._(mysqldb._exceptions.operationalerror) (1115, "errcode = 2, detailmessage =

Verilog 实现8位乘法器_mutipler 流程-程序员宅基地

文章浏览阅读2.5k次。`timescale 1ns / 1ps//////////////////////////////////////////////////////////////////////////////////// Company:// Engineer://// Create Date: 2021/04/17 10:29:35// Design Name:// Module Name: mutipler// Project Name:// Target Devices:// Tool Ver_mutipler 流程

华为机试108题 11-20_本题目要求输入n个字符串,按照ascii码值排序后,依次输出。 输入格式: 一行输入整-程序员宅基地

文章浏览阅读1k次。11. 数字颠倒 12. 字符串反转输入一个整数,将这个整数以字符串的形式逆序输出程序不考虑负数的情况,若数字含有0,则逆序形式也含有0,如输入为100,则输出为001输入:输入一个int整数输出:将这个整数以字符串的形式逆序输出示例:输入1516000输出0006151思路:字符串反转代码实现:str_num = str(input())print(str_nu..._本题目要求输入n个字符串,按照ascii码值排序后,依次输出。 输入格式: 一行输入整

随便推点

java.nio.file.files_JDK1.7 之java.nio.file.Files 读取文件仅需一行代码实现-程序员宅基地

文章浏览阅读273次。JDK1.7中引入了新的文件操作类java.nio.file这个包,其中有个Files类它包含了很多有用的方法来操作文件,比如检查文件是否为隐藏文件,或者是检查文件是否为只读文件。开发者还可以使用Files.readAllBytes(Path)方法把整个文件读入内存,此方法返回一个字节数组,还可以把结果传递给String的构造器,以便创建字符串输出。此方法确保了当读入文件的所有字节内容时,无论是否...

web基础---->Fileupload文件的上传-程序员宅基地

文章浏览阅读97次。  这里我们介绍文件上传的知识,使用的是apache的Commons FileUpload框架。文件上传的使用项目的部分结构如下:一、使用Commons FileUpload的上传功能,我们需要引入两个jar包:commons-fileupload和commons-io。首先我们列出html的部分<!DOCTYPE html><html lang="e...

解决IDEA2020.1新建项目需要重新配置maven_idea2020.1.1打开新项目时自动匹配maven-程序员宅基地

文章浏览阅读2.2k次。IDEA2020.1新建项目后的maven是默认配置,设置安装好的maven仓库File —> New Prijects Settings —> Setting for New Projects…2. 进入后设置Build, Execution, Deployment —> Build Tools —> Maven_idea2020.1.1打开新项目时自动匹配maven

Mongodb 性能测试_mongo单点性能-程序员宅基地

文章浏览阅读638次。转载地址 http://www.cnblogs.com/lovecindywang/archive/2011/03/02/1969324.html进行了一下Mongodb亿级数据量的性能测试,分别测试如下几个项目:(所有插入都是单线程进行,所有读取都是多线程进行)1) 普通插入性能 (插入的数据每条大约在1KB左右)2) 批量插入性能 (使用的是官_mongo单点性能

VB.net学习笔记(二十七)线程同步上_vbnet同步-程序员宅基地

文章浏览阅读9.2k次。X夫妇二人试图同时从同一账户(总额1000)中支取1000。由于余额有1000,夫妇各自都满足条件,于是银行共支付2000。结果是银行亏了1000元。这种两个或更多线程试图在同一时刻访问同一资源来修改其状态,并产生不良后果的情况被称做竞争条件。 为避免竞争条件,需要使Withdraw()方法具有线_vbnet同步

Unity中减少VR晕眩症的实用技术(Yanlz+Unity+XR+VR+AR+MR+SteamVR+晕眩症+征兆冲突理论+视野+帧速+相对运动错觉+光场VR+立钻哥哥+==)_unity 开发vr很头晕-程序员宅基地

文章浏览阅读4k次,点赞10次,收藏10次。《基于Unity与SteamVR构建虚拟世界》 《基于Unity与SteamVR构建虚拟世界》 版本 作者 参与者 完成日期 备注 SteamVR_Unity_V01_1.0 严立钻 2019..._unity 开发vr很头晕