For the young, bright-eyed software engineers who are starting out in their careers, here are some of the best tips I’ve either read or received as a software engineer.

对于刚起步的年轻，眼光灿烂的软件工程师，以下是我作为软件工程师阅读或获得的一些最佳技巧。

Most of the advice here caters to the software engineering crowd, but I believe there are many tips that are applicable regardless of your profession.

这里的大多数建议都适合软件工程人群，但是我相信有很多技巧都可以适用，无论您的职业是什么。

In short, my best advice is:

简而言之，我最好的建议是：

• Underpromise, overdeliver承诺不足，超额投放
• Perfect is the enemy of good完美是善的敌人
• Stay on a path留在路上
• Collect feedback early尽早收集反馈
• Seek before you ask在问之前先寻求
• Optimize for simplicity为简单而优化

If you prefer to watch this in a video format, I’ve made a Youtube video here:

如果您喜欢以视频​​格式观看此视频，请在此处制作YouTube视频：

承诺不足，超额投放 (Underpromise, Overdeliver)

Underestimating the amount of work needed to accomplish a feature is an extremely common mistake among new, and even experienced, engineers.

在新的甚至是经验丰富的工程师中，低估完成一项功能所需的工作量是一个非常普遍的错误 。

If you look at the number of projects that are over-budget and/or delivered late, you’ll be very surprised. It’s a crazy number, something to the tune of 50%.

如果您查看超预算和/或延迟交付的项目数量，您会感到非常惊讶。 这是一个疯狂的数字，大约50％。

Let’s consider that for a second: 50% of all projects are either over-budget or delivered late.

让我们考虑一下： 所有项目中有50％要么预算超支，要么延迟交付。

That means out of every 1000 projects, 500, or half of them, are delivered late or over the estimated budget. It just baffles me.

这意味着在每1000个项目中，有500个或其中一半交付晚于或超出了预算。 这让我感到困惑。

I recall distinctly during my first tech project that I was given the autonomy to lead the feature development. That meant I was the go-to guy who would write up a technical design doc detailing how much time it would take to develop the entire feature, how many engineers we would need, and so forth.

我清楚地记得在我的第一个技术项目中，我有自主权来领导功能开发。 这意味着我是一名入门人员，他将撰写一份技术设计文档，详细说明开发整个功能所需的时间，我们需要多少工程师等等。

Being the eager, young engineer that I was, I grossly underestimated the amount of time needed to get things done. Something to the tune of 2–3x.

作为我那位急切的年轻工程师，我严重低估了完成工作所需的时间。 大约2到3倍。

I was quite disappointed with myself at the time, and as a result of that, I had a strained relationship with some of my coworkers, too.

当时，我对自己感到非常失望，因此，我与一些同事的关系也很紧张。

My manager then sat me down and gave me some life-changing advice. He said to me, always underpromise and overdeliver.

然后我的经理坐了下来，给了我一些改变生活的建议。 他对我说， 总是承诺不足和交付过多。

What that means is that you should be conservative with your estimations, provide sufficient buffer for your estimations for various things to go wrong (because anything that can go wrong, will), and aim to deliver your project ahead of time/under the cost.

这意味着您应该保守估计，为各种错误的估计提供足够的缓冲(因为任何可能出错的都会 )，并力争提前/以低成本交付项目。

The benefits:

好处：

1. Gives you ample time to develop and refactor as needed. Feature development is always a good time to go back and fix some of the technical debt you (or the team before you) have accumulated over the years.

   给您充足的时间来发展和 根据需要进行重构。 功能开发始终是回溯并解决您(或您之前的团队)多年来积累的一些技术债务的好时机。

2. Allows time to figure out the best design, and not just a working design.

   允许有时间找出最佳设计，而不仅仅是可行的设计。

3. There are many things that can go wrong during feature development. A co-worker goes on vacation, you get sick, meetings, your kid gets sick, your car gets hit, and the list goes on. It’s important to recognize that things can go awry, and you want to ensure you have a buffer in your schedule.在功能开发过程中可能会出错。 一位同事去度假，生病，开会，孩子生病，汽车撞车，清单还在继续。 重要的是要认识到事情可能会出错，并且您想确保自己的日程安排中有缓冲。

4. Being able to produce high-quality work consistently as a result of #2, and able to deliver on-time every single time as a result of #3, you’re now recognized as a high-performer within the company who knows what you’re talking about and can be counted on. Win-win!

   由于＃2能够始终如一地产生高质量的作品，并且由于＃3能够每次都能按时交货，因此您现在被公认为公司内的高绩效人才，他们知道自己的情况正在谈论，可以指望。 双赢！

You might argue that the downside of under-promising is that others will think you’re being lazy by estimating 10 weeks’ worth of work for something that could be done in 2 weeks.

您可能会说，承诺不足的缺点是，其他人会认为您懒惰了，因为他们估计10星期的工作量可以在2周内完成。

To be honest, I struggled with this for a while, too. However, I then realized that as long as you communicate openly and stay consistent with the stakeholders throughout the process, you’ll be fine.

老实说，我也为此挣扎了一段时间。 但是，我然后意识到，只要您公开交流并在整个过程中与利益相关者保持一致，就可以了。

You’re the person responsible for providing the cost because others rely on your expertise. They know that you’re the one most intimate with the codebase, and they trust you to provide a best-guess. Various things can happen during feature development, and as long as you’re openly communicating, everything will be fine.

您是负责提供费用的人，因为其他人依赖您的专业知识。 他们知道您是与代码库最亲密的人，并且他们相信您会提供最好的猜测。 在功能开发过程中可能会发生各种各样的事情， 只要您公开交流 ，一切都会好起来的。

完美是善的敌人 (Perfect is the enemy of good)

As a software engineer, you tend to find that a project lacks this or needs that before it can go out the door. A project could be a coding project or just a technical design doc that you need to write.

作为软件工程师，您往往会发现一个项目缺少此项目或需要该项目才能将其发布。 项目可以是编码项目，也可以只是您需要编写的技术设计文档。

What often happens is that as you delve deeper into the project, you start to find that there is more stuff that you haven’t accounted for. You then roll up your sleeves and set your sights on getting to the bottom of things. You decided to spend the next few hours researching and trying to get everything wrapped up.

经常发生的是，随着您对项目的深入研究，您开始发现还有更多未说明的内容。 然后，您卷起袖子，将目光投向事物的底部。 您决定在接下来的几个小时中进行研究，并尝试将所有内容整理好。

Ten hours in, nothing actually gets done and you pile up more work than before.

十个小时之后，实际上什么也没完成，您的工作量比以前多了。

If this sounds familiar to you, then you’re not alone.

如果您觉得这很熟悉，那么您并不孤单。

This happens to everyone — and it happens to the best of us. I believe that we have been conditioned from a young age to produce work that is “perfect” or “complete.” However, in reality, there is no such thing as a perfect solution.

这发生在每个人身上，也发生在我们所有人身上。 我相信我们从小就被限制从事“完美”或“完整”的作品。 但是，实际上，没有完美的解决方案。

We live in a world of constraints, and there’s a trade-off for every important decision that we make.

我们生活在一个充满约束的世界中，我们做出的每个重要决定都需要权衡取舍。

The key here is recognizing we don’t know everything. You might not realize it, but there is a myriad of alternatives behind most decisions you make.

这里的关键是要认识到我们并不了解一切 。 您可能没有意识到，但是您做出的大多数决策背后都有无数的选择。

For example, as a computer science major, what should you do for a first job out of college? Other than working for a startup or a major tech company, you could also work overseas as a freelancer, start a Youtube channel, teach computer science on Udemy, start a blog, or start your own company. The list of options is limitless, and the decision you make today will be based on several key criteria.

例如，作为计算机科学专业的学生，​​从大学毕业后应该做什么？ 除了在初创公司或大型科技公司工作外，您还可以在海外担任自由职业者，建立Youtube频道，在Udemy上教授计算机科学，建立博客或建立自己的公司。 选项列表是无限的，您今天做出的决定将基于几个关键标准。

You’ll eventually make a decision that is best for you, and not necessarily objectively the best, because everyone is unique and there’s no one-size-fits-all.

最终，您将做出最适合自己的决定，而不一定是最客观的决定，因为每个人都是独一无二的，而且不可能一刀切。

The best we can do in such a situation is to collect as much information as possible, acknowledge the risks in what we do not know, and make the best decision from there.

在这种情况下，我们能做的最好的事情就是收集尽可能多的信息，承认我们所不知道的风险，并据此做出最佳决策。

The way I think about it is I assign a probability for the worst case scenario, and use that for my decision-making process. This is something I learned from a book called Principles by Ray Dalio, which is a great book that I highly recommend.

我的思考方式是为最坏的情况分配一个概率，并将其用于决策过程。 这是我从雷·达里奥(Ray Dalio)的一本名为《原则》的书中学到的，这是我极力推荐的一本好书。

If the probability of something going horribly wrong is statistically significant, I either:

如果发生严重错误的可能性在统计上是显着的，那么我要么：

1. Look for a better solution or寻找更好的解决方案或
2. Find ways to mitigate the risks such that they are no longer statistically significant.寻找减轻风险的方法，使其不再具有统计意义。

Once a decision is made, I then execute on it and move on.

一旦做出决定，我就执行它并继续前进。

Rinse, and repeat for every problem that I encounter. I find joy in solving these problems, and in some ways, life’s joy is in solving problems of varying magnitude and complexity.

冲洗，并针对遇到的每个问题重复进行。 我发现解决这些问题很高兴，从某种意义上说，生活的喜悦在于解决各种规模和复杂性的问题。

保持前进 (Stay on path)

Feature creep is one that naturally comes to mind as a counter-example.

作为特征，特征蠕变是自然而然地想到的。

You keep wanting to add more features because you feel the current one looks like it was downloaded off of the 90s’ world wide web. You feel that it’s not ready. You think that no one would ever want to use your product.

您一直想添加更多功能，因为您觉得当前的功能看起来像是从90年代的互联网上下载的。 您觉得还没有准备好。 您认为没有人会想要使用您的产品。

However, note that all these things are going on in your own head. None of this is validated. You don’t know what people want until you put something in their hands.

但是，请注意，所有这些事情都在您自己的脑海中进行。 没有一个经过验证。 您不知道别人想要什么，除非您将某些东西交到他们手中。

What you should aim for is to set a fixed goal at the beginning of your project, and strive to achieve it no matter what.

您的目标是在项目开始时设定一个固定的目标，无论如何都要努力实现。

The benefits are two-fold:

好处有两个：

1. This reduces feature creep and forces you to focus. Volumes of books have been written on this, and I won’t bore you with the specific details. Staying laser-focus is crucial, regardless of your position.

   这样可以减少特征蠕变并迫使您集中精力 。 关于这方面的书已经很多了，我不会为您带来具体的细节。 无论您处于什么位置，保持激光聚焦都是至关重要的。

2. We humans love instant gratification. If you can release something in 2 weeks, then do it! Plan ahead for what your project should be able to achieve in 2 weeks, and then put it in the hands of your users! It’s a very satisfying feeling, and even if it does fail miserably, at least you stuck to your goal and you’ve now collected valuable feedback to iterate on.

   我们人类喜欢即时的满足感。 如果您可以在2周内放出东西，那就去做吧！ 提前计划您的项目在2周内将要实现的目标，然后将其交到用户手中！ 这是一种非常令人满意的感觉，即使确实失败了，也至少您坚持了目标，现在您已经收集了宝贵的反馈意见以进行迭代。

This brings me to my next point.

这把我带到了下一点。

尽早收集反馈 (Collect feedback early)

I personally think that we should always aim to release early, release often, and collect feedback as soon as possible.

我个人认为，我们应该始终致力于早日发布，经常发布并尽快收集反馈。

Of course, I recognize that this is possible primarily for software projects. But hear me out.

当然，我认识到这主要适用于软件项目。 但是，请听我说。

Releasing often and releasing early allows you to collect feedback early. Having a healthy feedback loop is a very important, if not the most important, aspect of your project.

经常发布并提前发布可让您尽早收集反馈。 有一个健康的反馈回路是项目的一个非常重要的，如果不是最重要的方面。

You should incorporate a feedback loop early on in your product development so that you know you’re developing the right product for the right people with the right constraints.

您应该在产品开发的早期就加入反馈循环，以便您知道自己正在为具有适当约束的适当人员开发适当的产品。

It’s equally important to note that releasing early doesn’t mean releasing a broken product. A broken product is never useful for anyone, and that’s just being disrespectful to your users.

同样重要的是要注意， 尽早发布并不意味着发布损坏的产品。 损坏的产品永远不会对任何人有用，而这只是对用户的不尊重。

You should figure out, and deliver, a minimum-viable-product (MVP), which means the bare minimum way your product should perrom in order to satisfy a need.

您应该弄清楚并交付最低可行产品(MVP)，这意味着您的产品应满足的最低限度需求。

One thing to note is that collecting feedback doesn’t mean it needs to be feedback from every single user.

需要注意的一件事是，收集反馈并不意味着它需要每个用户的反馈。

Consider segmenting your users. Get a small set of users, ideally from various backgrounds (and not just friends and family). Get your product in their hands so that if you mess up, at least your other users won’t have realized it yet and you will have time to fix it.

考虑细分用户。 最好能有少量用户，这些用户最好来自各种背景(而不仅仅是朋友和家人)。 将您的产品交给他们，这样，如果您搞砸了，至少其他用户还没有意识到，您将有时间修复它。

在问之前先寻求 (Seek before you ask)

A lot of younger engineers tend to ask questions without attempting to find the answers themselves. When they run into something they haven’t encountered before, their first instinct is to ask a senior engineer how it’s done and how to accomplish something.

许多年轻的工程师往往会问问题而没有试图自己找到答案。 当他们遇到以前从未遇到过的事情时，他们的第一个直觉是询问高级工程师如何完成工作以及如何完成某些工作。

It will do you a lot of good to seek the answer yourself before asking anyone. The reason is two-fold:

在问任何人之前自己寻求答案会很有帮助。 原因有两个：

1. Diving deep allows you to explore areas you might’ve never explored before. It gives you an opportunity to gain exposure and be familiar with a different code base.深潜可以让您探索以前从未探索过的区域。 它使您有机会获得曝光并熟悉不同的代码库。

2. As you move to a more senior position, people rely on you for guidance. You will become the senior in the group over-time. People go to you for help and you’ll need to learn this skill later anyway.

   当您升任更高职位时，人们会依靠您提供指导。 随着时间的推移，您将成为小组的高级成员。 人们会向您寻求帮助，无论如何您以后都需要学习此技能。

Many developers joke that most of their time is spent on Googling and StackOverflow. I wholeheartedly agree with this, but not for reasons you might think.

许多开发人员开玩笑说，他们的大部分时间都花在Googling和StackOverflow上。 我完全同意这一点，但并非出于您可能会想到的原因。

The ability to find answers to an ambiguous problem is a highly coveted skill. The Internet has developed over time into an easily-accessible treasure trove of information that you can plug into at any time, anywhere, on any device.

找到一个模棱两可的问题的答案的能力是一项令人垂涎的技能。 随着时间的流逝，Internet已发展成为易于访问的信息宝库，您可以随时随地在任何设备上插入这些信息。

Yet, the ability to ask the right questions is much more difficult to acquire than the ability to answer them.

但是， 提出正确问题的能力比回答问题的能力要困难得多。

As you move along your professional career, you’ll start to realize that figuring out the right questions will be a skill you need to learn, and if you do master it, it will do you wonders.

随着您职业生涯的发展，您将开始意识到找出正确的问题将是您需要学习的一项技能，如果您掌握了它，那么您会感到纳闷。

为简单而优化 (Optimize for simplicity)

Strive for simplicity in your work and in your life.

在工作和生活中力求简单。

Often times I see junior developers work on a coding project and they’ll use abstraction, inheritance, interfaces, and some very interesting frameworks. Yet, in spite of all this fanciness, they’re writing new code that adds more complication than needed.

通常，我看到初级开发人员从事编码项目，他们将使用抽象，继承，接口和一些非常有趣的框架。 然而，尽管如此，他们还是在编写新的代码，这些代码增加了不必要的复杂性。

People who maintain this code are not going to be the same people who write it, most of the time. Any extra layer of complexity added on will make it much more difficult to onboard new engineers.

大部分时间，维护该代码的人不会与编写该代码的人相同。 任何增加的复杂性都会使新工程师的加入变得更加困难。

As you mature as a software engineer, you realize that writing code isn’t just a matter of optimizing for performance but also optimizing for people. It’s just as important to write code that others can reason about easily.

随着您成为软件工程师的成熟，您会意识到编写代码不仅是针对性能进行优化的问题，而且还针对人员进行优化。 编写其他人可以轻松推理的代码也同样重要。

This is where code readability and code organization come into play.

这是代码可读性和代码组织起作用的地方。

Unless performance is a real concern, always opt for the simpler, cleaner approach.

除非真正关心性能，否则请始终选择更简单，更清洁的方法。

I believe that simplicity extends to life outside of work as well. Keep your life free of distractions. Reduce the number of unnecessary belongings you have in your life. Focus on things that matter to you. Optimize your life for experiences and not for possessions. These are some of the things to keep in mind as you move through life.

我认为，简单性也延伸到工作以外的生活。 保持生活不受干扰。 减少生活中不必要的物品数量。 专注于对您重要的事情。 优化您的生活以获得体验，而不是拥有财产。 这些是您一生中要记住的一些事情。

我读过的书和喜欢的资源 (Books I’ve read and resources I’ve enjoyed)

• Principles by Ray Dalio — ? One of the best books I’ve read in a while. The author talks about principles we can apply both in life and at work. I incorporated his framework for solving problems into my daily life

  Ray Dalio的原则 -？ 我一段时间以来读过的最好的书之一。 作者讨论了我们可以在生活和工作中应用的原则。 我将他解决问题的框架融入了我的日常生活中

• How to win friends and influence people — Classic book on building and managing relationships with people ?. This book helped me understand how to manage my relationships in the workplace.

  如何赢得朋友并影响人 -关于建立和管理人际关系的经典著作？ 这本书帮助我了解了如何在工作场所管理自己的人际关系。

• The Senior Software Engineer — ? Great book with action items on how to mature as a software engineer. This is where I learned how to Seek before You Ask.

  高级软件工程师 -？ 一本很棒的书，其中包含有关如何成为一名软件工程师的行动项目。 在这里，我学会了如何先问后问。

• Crucial Conversations — Great book on how to deal with people in a high-stakes situation. Very applicable across different aspects of life. Whether it’s negotiating for a higher pay ? or figuring out communication issues with your spouse ?, this book has some good tips on solving those problems.

  至关重要的对话 -关于如何与处于高风险状态的人打交道的好书。 非常适用于生活的各个方面。 是否正在谈判获得更高的薪水？ 还是弄清楚与配偶的沟通问题，这本书提供了解决这些问题的一些技巧。

• Lean Startup — Good book on how to use a Minimum-Viable-Product (MVP) to test out an idea before investing further. I’ve used this to test out several startup ideas in the past.

  精益创业 -关于如何在进行进一步投资之前如何使用最低可行产品(MVP)进行测试的好书。 过去，我曾用它来测试几个启动想法。

• Purple Cow —? Loved this book. Mainly used this to test different startup ideas I have in mind. It talks about how to market your startup and what makes it standout from the rest.

  紫牛 -？ 喜欢这本书。 主要用于测试我想到的不同的启动想法。 它讨论了如何营销您的初创公司，以及如何使其在其他公司中脱颖而出。

• Evernote — Best note-keeping app ? I’ve ever used. Highly recommend it!

  Evernote-最佳笔记应用程序？ 我曾经用过。 强烈推荐！

• Moleskin notebook — I really enjoy this one. The quality of it is extremely high. The price is slightly higher, but since I use it on a daily basis, I consider it a good investment. Holding a beautiful notebook in my hands every day makes me more excited to write more notes.

  Moleskin笔记本 -我真的很喜欢这一本。 它的质量非常高。 价格略高，但是由于我每天使用它，因此我认为这是一笔不错的投资。 每天我手里拿着一个漂亮的笔记本，让我更加兴奋地写下更多笔记。

• Pilot G2 (Black) — Easily the best pens I’ve ever used, and only pens I’ll use. I buy them in bulk from Amazon and keep them around everywhere I go. I have one in my backpack, one in office, and one in my home office so that I always have a pen around. It writes great, the ink flows smoothly, and I just love the feel of writing in it. Coupled with the Moleskin, sometimes I just want to pick up the G2 to jot random things on there because these two are so perfect together.

  G2飞行员(黑色) —轻松获得我曾经使用过的最好的笔，只有我会使用的笔。 我从亚马逊大量购买它们，并随处携带。 我的背包里有一个，办公室里有一个，家庭办公室里有一个，所以我周围总是有一支笔。 它书写出色，墨水顺畅流动，我只是喜欢用它书写的感觉。 加上Moleskin，有时候我只想拿起G2在那儿随意玩，因为这两者非常完美。

Follow me on Twitter, Facebook, and LinkedIn. Sign up for my mailing list where I regularly send tips, tricks, and industry learnings.

在Twitter ， Facebook和LinkedIn上关注我。 注册我的邮件列表 ，我在那里定期发送提示，技巧和行业知识。

If you enjoyed this article, comment below: what is your #1 best tip for a software engineer?

如果您喜欢这篇文章，请在下面评论： 对软件工程师来说，您最好的＃1秘诀是什么？

翻译自: https://www.freecodecamp.org/news/how-to-be-a-successful-software-engineer-6f82a5b1a82e/