How to Become a Better Software Developer 如何成为一名更好的软件开发人员
Today I would like to share some thoughts on ways a software developers can improve their professional skills and become better at their work. The topics raised here are universal and not specific to any technology stack. Most of them are not even specific to IT, for that matter. These are general advice on how to develop your personal traits, improve collaboration with colleagues and clients, and advance your career as a software developer. 今天我想和大家分享一些关于软件开发人员如何提高他们的专业技能，如何更好地工作的想法。这里提出的主题是通用的，并不特定于任何技术堆栈。就这一点而言，它们中的大多数甚至不是特定于IT的。这些是关于如何发展你的个人品质，如何改进与同事和客户的协作，以及如何推进你作为软件开发人员的职业生涯的一般建议。
Some of the things in this article are subjective and reflect my personal experience, while others have been adopted and successfully used by others. 这篇文章中的一些东西是主观的，反映了我个人的经验，而另外一些东西已经被别人采用并成功的使用了。
Understand the Process End to End 从头到尾理解过程
A lot of developers think that software development is all about coding, and everything else is just people trying to be annoying and wasting their precious time. This cannot be further away from the truth. Before you get to code a piece of software, it undergoes a process of transformation from a vague idea into a carefully designed solution ready for implementation. And after you pushed your latest changes into Git the software is being tested, deployed, monitored, analyzed and improved on. Coding is just one of the many steps of the process. 许多开发人员认为软件开发就是编码，其他的一切都是人们在浪费他们宝贵的时间。这与事实相去甚远。在您开始编写一段软件代码之前，它将经历一个从模糊的想法到精心设计的解决方案的转换过程，以备实现。在您将最新的更改推送到Git之后，软件正在进行测试、部署、监视、分析和改进。编码只是这个过程中的许多步骤之一。
So why does this happen? Frequently, especially when working in larger organizations, different phases of the projects are handled by different teams or even departments. It all starts with the business analysts, who gather requirements. The requirements are then handed over to the designers that produce the mockups for developers. The developers code away and give the results to the QA engineers. If everything is OK, the artifact is sent to the operations teams that deliver it to the end users. This process is treated as a set of discrete steps without any feedback. Because of the lack of communication between the departments, their representatives often don’t really understand the goals of others and this leads to misunderstandings and even conflicts. 为什么会这样呢?通常，特别是在大型组织中工作时，项目的不同阶段由不同的团队甚至部门处理。这一切都从收集需求的业务分析师开始。然后将需求交给为开发人员生成原型的设计人员。开发人员编写代码并将结果交给QA工程师。如果一切正常，工件将被发送到将其交付给最终用户的运营团队。这个过程被视为一组没有任何反馈的离散步骤。由于各部门之间缺乏沟通，他们的代表往往不能真正理解他人的目标，从而导致误解甚至冲突。
Often the process of software development is treated as a set of discrete steps with no feedback.
通常，软件开发过程被视为一组没有反馈的离散步骤。
For many people nowadays this might sound too exaggerated. With the rise of agile methodologies, more companies move away from such a rigid approach towards smaller teams consisting of people of mixed specialty. But even then we see that people don’t really try to understand the work of others. How often have you been irritated with your designers because they want you to implement a custom checkbox that is just too time-consuming? And vice-versa, received criticism, because you forgot to use the correct font. 对于现在的许多人来说，这可能听起来太夸张了。随着敏捷方法的兴起，越来越多的公司不再采用这种死板的方法，而是采用由混合专业人员组成的小型团队。但即便如此，我们也看到人们并没有真正去理解别人的工作。您是否经常对您的设计人员感到恼火，因为他们希望您实现一个非常耗时的自定义复选框?反之亦然，因为你忘记使用正确的字体而受到批评。
A lot of these differences can be overcome by just paying attention to the work of others. Sit down with your designer and explain him, that implementing a custom checkbox takes a while and that there’s a library that offers a different similar checkbox you could reuse. In return, learn the basics of typography and understand why choosing a correct font makes a difference. Develop the same attitudes toward managers, business analysts, QA engineers, support and marketing specialists. Quoting T. Huxley: 只要关注其他人的工作，这些差异就能被克服。与您的设计人员坐下来，向他解释一下，实现自定义复选框需要一段时间，而且有一个库提供了另一个类似的复选框，您可以重用它。作为回报，学习排版的基本知识，并理解为什么选择正确的字体会有所不同。培养对经理、业务分析师、QA工程师、支持和营销专家同样的态度。引用t·赫胥黎:
Try to learn something about everything and everything about something.试着了解每件事，每件事。
By learning something from everybody, you will be able to anticipate their needs, shorten the feedback loop and enable more frequent deliveries. Plus it will earn you a lot of love and respect from everybody else. 通过向每个人学习，你将能够预测他们的需求，缩短反馈周期，并使交付更加频繁。此外，它会为你赢得很多人的爱和尊重。
Understand Your Client’s Needs 了解客户的需求
There’s one important thing that you need to understand about your customers: they don’t understand most of the stuff that you’re doing. Agile, functional programming or non-relational databases is all dark wizardry to them. Even the ones that closely follow your work and are genuinely interested are still mostly in the dark. This has a couple of consequences. 有一件重要的事情你需要了解你的客户:他们不理解你正在做的大部分事情。敏捷、函数式编程或非关系数据库对他们来说都是黑暗的魔法。即使是那些密切关注你的工作并真正感兴趣的人，也大多还是蒙在鼓里。这有几个后果。
The face of most clients when talking to software developers.
大多数客户在与软件开发人员交谈时的表情。
Hiring software developers for them requires a certain degree of trust. People often tend to feel uncomfortable about having to pay a lot of money for something they don’t understand. Remember last time you walked into an unfamiliar car repair service and weren’t sure if you could trust them with your ride? Well, your clients have the same feeling. Except there’s no car, there’s just a whole bunch of abstract non-tangible concepts which are supposed to somehow materialize into products and revenue. When working with new clients it’s important to earn their trust. Make sure they understand how you operate and aim to deliver results in smaller but frequent iterations. That way they can see the progress of your work, assess the intermediate results and provide their feedback. 为他们雇佣软件开发人员需要一定程度的信任。人们往往对不得不为他们不懂的东西付很多钱时感到不舒服。还记得上次你走进一家不熟悉的汽车维修服务公司，不确定能否信任他们为你提供的服务吗?你的客户也有同样的感觉。除了没有汽车，只有一大堆抽象的无形的概念，它们应该以某种方式物化为产品和收入。与新客户合作时，赢得他们的信任很重要。确保他们理解您如何操作，并以较小但频繁的迭代交付结果为目标。这样他们就能看到你的工作进展，评估中间结果并提供反馈。
Often clients tend to come up with their own solutions instead of sharing their problems. Since they have little idea of your capabilities, their solutions are often misjudged, under- or overambitious. Remember the old (and maybe fictional) quote by Henry Ford: 客户往往倾向于提出自己的解决方案，而不是分享他们的问题。因为他们不了解你的能力，他们的解决方案往往被错误地判断，不够或过于雄心勃勃。请记住亨利·福特(Henry Ford)的一句名言(或许是虚构的):
If I had asked people what they wanted, they would have said faster horses.如果我问人们想要什么，他们会说要更快的马。
Instead of going with the flow and silently implementing whatever the client wants, it’s sometimes useful to invite them to take a step back and discuss the problem that they wanted to solve in the first place. When combining their domain knowledge and your technical expertise, you’re are likely to arrive at a better solution. 与其随波逐流，默默地实现客户想要的任何东西，有时邀请他们后退一步，讨论他们最初想要解决的问题是有用的。当结合他们的领域知识和您的技术专长时，您可能会得到更好的解决方案。
Keep in mind, that not everybody likes having their ideas questioned and this tactic requires you to have some tact and inspire confidence in the client’s eyes. You will also need to leave your comfort zone and immerse yourself in their business, to be able to understand the problem and suggest a better solution. This can be challenging if you’re are working in complex industries such as finance or health care. But if you pull this off once, it’s likely that next time the client will return with a more open mind. 记住，不是每个人都喜欢自己的想法被质疑，这种策略需要你有一些机智，并在客户眼中激发信心。你还需要离开自己的舒适区，让自己沉浸在他们的业务中，以便能够理解问题并提出更好的解决方案。如果你在金融或医疗等复杂行业工作，这可能是个挑战。但如果你能做到这一点，下次客户可能会以更开放的心态回来。
Pick the Right Tools for the Job 选择适合这项工作的工具
If all you have is a hammer, everything looks like a nail. 如果你只有一把锤子，所有东西看起来都像钉子。
Often developers that learn only a single technology rush to apply it to every problem they encounter. Unsurprisingly, this kind of approach leads to sub-optimal results. Instead, when tackling a new problem, pause and think whether the tools at your disposal are really suitable for this kind of work. If you have doubts, investigate a bit and come up with a list of likely superior alternatives. To make it easier, compile a list of questions and assess different options one by one. The questions can be different for each assessment, but it can go along the way of: 通常，只学习一种技术的开发人员会急于将其应用于他们遇到的每一个问题。不出所料，这种方法会导致次优结果。相反，当你处理一个新问题时，停下来想一想你手头的工具是否真的适合这种工作。如果你有疑问，调查一下，列出一个可能更好的替代方案。为了让它更简单，编写一个问题列表，并逐个评估不同的选项。每个评估的问题可能不同，但也可能是这样的:
-
What platforms or devices must it support?它必须支持哪些平台或设备?
-
What are the non-functional requirements, such as performance or memory usage?什么是非功能性需求，例如性能或内存使用?
-
Is buying a license an option, or do you need something free or open-source?购买许可是一种选择，还是需要一些免费或开源的东西?
-
Does the solution provide everything you need out of the box, or will you need to write something yourself?解决方案是否提供了所有您需要的开箱即用的东西，还是您需要自己编写一些东西?
-
Do you have any other limitation, like company policies, legal considerations or a lack of specialists in your team?你有其他的限制吗，比如公司政策、法律考虑或者你的团队缺少专家?
Answering these questions should help you structure the options in your head and narrow them down to a shortlist of candidates.回答这些问题可以帮助你在头脑中构建选项，并将它们缩小到候选项的一个简短列表中。
Experiment Safely 实验安全
So what happens if you none of the things you know are a particularly good fit in your case and you want to try something new? The fact that you don’t experience with something doesn’t automatically mean that it’s out of the question. It just means that you need to consider some additional things: 那么，如果你所知道的事情中没有一件特别适合你，而你又想尝试新事物，会发生什么呢?你没有经历过某件事并不意味着这是不可能的。这只是意味着你需要考虑一些额外的事情:
Do you have enough time for preparation? If the timeline of the project is not stressful, you can learn as much as possible before you begin the implementation and pick up the rest along the way. Or at least adopt the “fake it till you make it” approach and convince the client that you know what you’re doing. 你有足够的时间准备吗?如果项目的时间表没有压力，您可以在开始实施之前学习尽可能多的东西，并在此过程中学习剩下的东西。或者至少采用“假装直到成功”的方法，让客户相信你知道自己在做什么。
Identify the things you need to test first. Take the “fail fast” approach and identify the crucial things that you need to evaluate before you can conclude the experiment. Having doubts about the performance of a system? Build a minimal prototype and run a load test. Uncertain about a particular library or integration with an external service? Implement that separately and then build the rest. 首先确定需要测试的内容。采用“快速失败”的方法，找出在实验结束前需要评估的关键因素。对系统的性能有疑问?构建最小原型并运行负载测试。不确定特定的库或与外部服务的集成?分别实现这一点，然后构建其余部分。
Keep in mind that going down this road is still risky both for you and your client, and they need to be aware of both the risks and the potential benefits. After all, a two-week investigation that might save months of work in the long run, this sounds like a pretty good deal. Even if the experiment fails, you only lose two weeks. The more trust you have with your client, the more they are likely to agree to something like this. 记住，这样做对你和你的客户都是有风险的，他们需要意识到这样做的风险和潜在的好处。毕竟，一项为期两周的调查从长远来看可能会节省数月的工作，这听起来是一笔相当不错的交易。即使实验失败了，你也只损失了两个星期。你对你的客户越信任，他们就越有可能同意这样的事情。
Build on the Shoulders of Giants 站在巨人的肩膀上
Reinventing the bicycle often leads to weird results. 重新发明自行车往往会导致奇怪的结果。
IT people often have two common characteristics: we are inventive and we enjoy our work. This sounds like a good thing, but it comes with an awkward side-effect: we tend to come up with our own solutions to problems that have been solved before. So whenever we’re faced with a choice of whether to use a framework, library or service or to implement it on our own, we tend to choose the latter. And this takes us on the futile journey of reinventing the wheel. Some of the common misbeliefs that lead to this are: IT人员通常有两个共同的特点:我们有创造力，我们享受我们的工作。这听起来似乎是一件好事，但随之而来的是一个尴尬的副作用:我们往往会想出自己的解决方案来解决以前已经解决的问题。因此，当我们面临是使用框架、库、服务还是自己实现它的选择时，我们倾向于选择后者。这让我们踏上了重新发明轮子的徒劳之旅。导致这一结果的一些常见错误信念是:
Implementing something yourself is easier than learning a 3rd party solution. While this may be a perfectly valid reason, it’s important not to oversimplify the task at hand. Often, something seems simple in the beginning but turns out to be much more difficult with progress. Eventually, you could end up spending a whole bunch of time handling bugs and edge cases that someone could have handled for you. 自己动手比学习第三方解决方案更容易。虽然这可能是一个完全合理的理由，但重要的是不要过于简化手头的任务。通常，事情一开始看起来很简单，但随着进展却变得更加困难。最终，您可能会花费大量的时间来处理bug和边缘案例，而这些都是其他人可以为您处理的。
This solution does more things than I need. Unless there are specific reasons why this is a bad thing, such as increasing the size of the resulting artifact, adding potential vulnerabilities or considerably slowing down the build, this is not usually a bad thing. You might end up needing it later. On the other hand, adding a whole library to use just one function might be an overkill. 这个解决方案做的事情比我需要的多。除非有特定的原因说明这是一件坏事，例如增加产生的工件的大小、添加潜在的漏洞或大大减慢构建，否则这通常不是一件坏事。你可能以后会需要它。另一方面，添加一个完整的库来只使用一个函数可能有些过分。
We can do it better. Although there are some successful projects that started with these words, this is not usually the case. Quality third part solutions are maintained by teams that have experience and resources devoted to solving this particular problem. To compete with them you need to be able to invest even more. Most projects have neither the resources nor the need to do that. 我们可以做得更好。虽然有一些成功的项目是以这些话开始的，但通常情况并非如此。高质量的第三方解决方案由具有解决此特定问题的经验和资源的团队来维护。为了与他们竞争，你需要能够投资更多。大多数项目既没有资源也没有必要这样做。
Code ownership and long-term maintenance will become a problem. Some people fear that if you go with a third party solution, you risk that the project at some point might become abandoned or unusable for whatever reason. The risk of product lock-in is real, and you should consider a possible mitigation strategy. If it’s an open-source project, would it be possible for you to fork it and maintain by yourself? Or if it’s a proprietary project, how much would it cost to replace it? Based on these inputs you can make a conscious decision on whether it’s worth the risk. 代码所有权和长期维护将成为一个问题。有些人担心，如果采用第三方解决方案，您可能会在某个时候因为某种原因而放弃或无法使用该项目。产品锁定的风险是真实存在的，您应该考虑一种可能的缓解策略。如果这是一个开源项目，你是否有可能自己开发并维护它?或者如果它是一个私有项目，替换它需要多少钱?基于这些输入，你可以有意识地决定是否值得冒险。
Learn Through Reimplementing 通过重新实现学习
There’s another side to this story. Reimplementing something yourselves is actually a great way to learn. While writing your own framework for a production project is almost always a bad idea, creating it as a learning exercise can be highly valuable. What better way to familiarize yourself with the problems that it solves by taking a crack at the same problems. Don’t go too deep into the rabbit hole, a simplified crude implementation will be enough to give you an understanding of the situation. 这个故事还有另一面。重新实现自己的东西实际上是一个很好的学习方法。虽然为生产项目编写自己的框架几乎总是一个坏主意，但是创建它作为学习练习可能非常有价值。还有什么更好的方法能让你通过尝试解决同样的问题来熟悉它所解决的问题呢?不要太过深入，一个简化的粗略实现就足以让您了解这种情况。
While you’re at it, don’t shy away from peeking into the sources of similar projects. Studying the code of open-source projects will allow you to benefit from the experience of more seasoned developers. 当你在做的时候，不要羞于查看类似项目的来源。研究开源项目的代码可以让您从经验丰富的开发人员的经验中获益。
Work on How You Work 学习你的工作方式
Strive for improvements not just in technological aspects, but in methodological as well. Just like properly designed and optimized software, a well-established workflow will allow you to work with fewer effort and stress while producing better results. Establishing an effective and efficient work process is not an easy task and there are numerous books and materials available on this topic. But for a start, consider the following areas for improvements: 不仅在技术方面，而且在方法方面也力求改进。就像正确设计和优化的软件一样，一个完善的工作流将允许您以更少的努力和压力工作，同时产生更好的结果。建立一个有效和高效的工作流程并不是一件容易的事情，有很多关于这个主题的书籍和资料。但首先，请考虑以下需要改进的领域:
Team and project management methodologies. Since most of us work in teams, it’s important to adopt a process that improves collaboration and establishes a common work rhythm for everybody. The agile movement in software development has given birth to a number of widely adopted methodologies, such as Scrum or Kanban. They help organize the overall work structure but don’t cover everything. There are other methodologies that help you make estimates, prioritize issues, improve communication, etc. You’ll need to identify the areas you are struggling with and look for best practices that help address your struggles. 团队和项目管理方法。由于我们大多数人都在团队中工作，采用改进协作并为每个人建立共同工作节奏的流程非常重要。软件开发中的敏捷运动催生了许多被广泛采用的方法，例如Scrum或看板。它们有助于组织整个工作结构，但并不涵盖所有内容。还有其他方法可以帮助您进行评估、确定问题的优先级、改进沟通等等。您需要确定您正在努力处理的领域，并寻找帮助您解决这些问题的最佳实践。
Personal processes. Like an orchestra, an effective team must have the same rhythm, but it doesn’t mean that everybody must work in an identical manner. Each person has their own preferences and should work in a way that makes them more productive. For example, a lot of people don’t like to be disturbed for hours when coding, but I, personally, like to work in short one-two hour bursts with breaks in between (a less strict version of the pomodoro technique). I also don’t like to work at home to avoid household-related distractions and prefer to work from an office or a cafe. Find out what works for you and stick to it, but also make sure that your habits don’t create problems for other team members. 个人的过程。就像管弦乐队一样，一支高效的团队必须拥有相同的节奏，但这并不意味着每个人都必须以相同的方式工作。每个人都有自己的喜好，应该以一种让自己更有效率的方式工作。例如，许多人不喜欢在编码时被打扰几个小时，但我个人喜欢在短时间内工作1 - 2个小时，中间休息一下(这是番茄工作法的一个不那么严格的版本)。我也不喜欢为了避免与家庭有关的干扰而在家工作，我更喜欢在办公室或咖啡馆工作。找出适合你的方法并坚持下去，但也要确保你的习惯不会给其他团队成员带来麻烦。
Engineering practices. A lot of practices lie on the border between technology and methodology and focus on improving the actual development process. For example, test-driven development and behavior-driven development help keep your code base well structured and tested. Code reviews help reduce defects in the code and also spread knowledge in the team. Continuous integration and continuous delivery ensure an easier and safer deployment process. Use these practices in combination with other organizational methodologies to achieve maximum results. 工程实践。很多实践都处在技术和方法的边界上，关注于改进实际的开发过程。例如，测试驱动开发和行为驱动开发有助于保持代码库的良好结构和测试。代码评审有助于减少代码中的缺陷，并在团队中传播知识。持续集成和持续交付确保了更容易和更安全的部署过程。将这些实践与其他组织方法结合使用，以实现最大的结果。
Remember, that there’s no process that will work for everybody, you need to trial it in your own environment. Also, make sure that you understand the process completely and implement it correctly. Seek advice from teams that have already gone through the process and benefit from their experience. Don’t neglect the software and material tools that will help you to adopt a process. Get a real Kanban board and a modern platform for continuous delivery. Adopting a new process will require effort and can even lead to a short-term loss of productivity. Give it some time and then do an evaluation of whether things have improved. 请记住，没有适合所有人的过程，您需要在自己的环境中进行试验。另外，确保您完全理解流程并正确地实现它。向已经经历过这个过程并从他们的经验中获益的团队寻求建议。不要忽视软件和材料工具，它们将帮助您采用流程。获得一个真正的看板和一个持续交付的现代平台。采用新流程需要付出努力，甚至可能导致短期的生产力损失。给它一些时间，然后评估事情是否有所改善。
Remove obstacles 移除障碍
A separate thing has to be said on addressing obstacles. It’s a common mistake to neglect small nuisances that might not seem important but can actually have a toxic effect on your work. Is your product designer sitting in a separate room or building? This means that it takes a bit more efforts to come over and have a conversation and some things will not be discussed. Is writing a new test difficult? Then a lot of things will not be tested. 在解决障碍问题上，还有一件事要说。忽略那些看似不重要但实际上会对你的工作产生有害影响的小麻烦是一个常见的错误。你的产品设计师是坐在一个单独的房间里还是在一栋大楼里?这就意味着你需要花更多的精力来和他们交谈，有些事情是不会被讨论的。写新考试难吗?那么很多东西将不会被测试。
None of these things are particularly dangerous by themselves, but they tend to pile up and cause serious consequences. And the nasty thing is, that you often don’t notice them until it’s already too late. Especially when there are always more serious perils to address. Remember the fable about the boiling frog and the notion of creeping normality. 这些东西本身都不是特别危险的，但它们往往堆积起来，造成严重后果。最糟糕的是，你经常会发现它们，直到为时已晚。特别是当总是有更严重的危险需要解决的时候。记住关于沸腾的青蛙的寓言和爬行的常态的概念。
Stay vigilant and fight these things at their roots before they get to you. 在这些事情发生在你身上之前，保持警惕，从根本上与之斗争。
Focus on the Fundamentals 关注基本原理
Fundamental concepts are the building blocks of your career. 基本概念是你职业生涯的基石。
IT is an extremely fast-paced industry. Every week new tools are released into the market. I’ve already mentioned the infamous “JavaScript fatigue” syndrome in my previous post. A lot of developers have been stressed and felt forced to re-evaluate their JS tech stack with each new project and that drove them nuts. Indeed, always being on the edge can be challenging, but there are a couple of ideas that can make it easier. 这是一个非常快节奏的行业。每周都有新的工具发布到市场上。我在上一篇文章中已经提到了臭名昭著的“JavaScript疲劳”综合症。许多开发人员都感到压力很大，他们不得不在每个新项目中重新评估他们的JS技术栈，这让他们抓狂。的确，总是处于边缘是有挑战性的，但是有一些想法可以让它变得更容易。
First of all, focus on the fundamentals. Even though new technologies appear quite frequently, new fundamental concepts are much more seldom. When learning something new, make sure you understand the underlying ideas that lead to this implementation. Chances are, these ideas are used in other projects as well, and once you encounter something similar, it will be easier for you to get a grasp of it. For example, modern JavaScript UI frameworks are based on components, and once you understand how to structure a component-oriented application using React, can use this experience when working Angular. In a similar manner ideas of Redux found their way into Angular, and reactive state management from Angular was implemented for React as MobX. 首先，关注基本面。尽管新技术经常出现，但新的基本概念却很少出现。在学习新东西时，确保您理解导致此实现的基本思想。很可能，这些想法也会在其他项目中使用，一旦您遇到类似的东西，就会更容易掌握它。例如，现代JavaScript UI框架是基于组件的，一旦您理解了如何使用React构造面向组件的应用程序，就可以在使用Angular时使用这种经验。类似地，Redux的思想也被引入到Angular中，Angular实现了对React as MobX的响应状态管理。
Take some time to familiarize yourself with the classical books on the topics of common patterns in software development such as “Enterprise Integration Patterns” by Gregor Hohpe and Bobby Woolf, the famous “Design Patterns: Elements of Reusable Object-Oriented Software” by the Gang of Four or different works of Martin Fowler. Although some of the things described in books may be outdated, you can use them to learn how the patterns evolved till today. 花些时间熟悉软件开发中常见模式主题的经典书籍，例如Gregor Hohpe和Bobby Woolf的《企业集成模式》，以及Martin Fowler的著名著作《设计模式:可重用面向对象软件的元素》。虽然书中描述的一些内容可能已经过时了，但是您可以使用它们来了解模式是如何演化到今天的。
Secondly, don’t rush to learn about every new thing out there. I understand that it’s tempting to follow every new thing that appears on Hacker News, but a lot of these things are just noise. Rather keep an eye out for things that have been circling in the community for some time now and have matured beyond the hype of initial discussions. Don’t give into FOMO. If you pay at least some attention to what’s going on, no important thing will pass unnoticed. 其次，不要急着去学习每一件新事物。我知道，关注黑客新闻上出现的每一个新事物都很有诱惑力，但其中很多只是噪音。相反，应该关注社区中已经出现了一段时间的事物，它们已经在最初的讨论中变得成熟了。不要向“社交控”屈服。如果你至少关注一下发生了什么，没有什么重要的事情会被忽视。
Bonus Tips 奖金提示
We’ve already talked about a lot in this article, but there are a few other points I would like to highlight before we wrap up. These few tips are focused more on your personal traits rather than professional, but I still believe that they have a high impact on your work life. 我们已经在本文中讨论了很多内容，但是在结束之前，我还想强调一些其他要点。这几条建议更多的是针对你的个人特点，而不是职业，但我仍然相信它们对你的工作生活有很大的影响。
Share the knowledge 分享知识
Often people think that hoarding valuable knowledge will make them indispensable. Having people like this in your team exposes you to the “bus factor” and can put you in a tough spot if such a person were to leave the project. If you are one of these people, consider that in addition to making you indispensable, your expertise also makes you unpromotable and “unvacationable”. You might miss out on other career opportunities in your organization because you are tied up in this role. Instead, share the knowledge with your colleagues, if possible delegate part of your work to them and use this collaboration to build even greater things on top of their work. 人们通常认为，储存有价值的知识将使他们不可或缺。在你的团队中有这样的人会让你暴露在“总线因素”之下，如果这样的人离开项目，会让你陷入困境。如果你是这些人中的一员，考虑一下，除了让你成为不可或缺的人之外，你的专业技能还会让你无法升职，“无法休假”。你可能会错过组织中的其他职业机会，因为你被这个角色束缚住了。相反，与你的同事分享你的知识，如果可能的话，将你的部分工作委派给他们，并利用这种合作在他们的工作之上建立更大的东西。
Don’t blame yourself or others 不要责备自己或他人
I remember a long time ago we had an incident in one project that was by my mistake. We’ve managed to recover from the incident quite quickly and I remember the client telling me: 我记得很久以前我们在一个项目中发生了一件事，那是我的错。我们很快就从事故中恢复过来，我记得客户告诉我:
You don’t judge a team by how they perform when everything goes according to plan, but by how they operate when the shit hits the fan.当一切按计划进行时，你不能通过他们的表现来判断一个团队，而是通过他们在糟糕的事情发生时的表现来判断。
No matter how good you are, sometimes things will go wrong and in such moments it’s important to be able to keep your cool and handle the situation with dignity and mutual respect. After the fire is put out, don’t focus on finding the scapegoat. This won’t help you avoid mistakes in the future, but will spear fear and doubt across the company. Instead, come together with the affected parties and do a common post-mortem. Focus on the things that lead to the problem, figure out why it happened and brainstorm on what you can improve your system or workflow to avoid this problem in the future. 不管你有多优秀，有时事情会出错，在这种情况下，保持冷静，以尊严和相互尊重的态度处理问题是很重要的。大火扑灭后，不要把注意力集中在寻找替罪羊上。这不会帮助你在未来避免错误，但会让整个公司充满恐惧和怀疑。相反，与受影响的各方一起进行共同的尸检。把注意力集中在导致问题的事情上，找出问题发生的原因，然后集思而行，思考如何改进系统或工作流，以避免将来出现这个问题。
Don’t be an asshole 别做混蛋
The developer community is a funny thing. On one side we see a lot of driven open-minded people that contribute to the community by working on open-source projects, giving speeches at conferences or writing articles. On the other side, we encounter people that troll new ideas, disrespect newcomers and demonstrate rude behavior to everyone around them. Don’t be one of those people. Be nice and spread the love. 开发人员社区是一件有趣的事情。一方面，我们看到许多积极开放的人通过开源项目、在会议上发表演讲或撰写文章来为社区做出贡献。另一方面，我们也会遇到一些人，他们对新想法嗤之以鼻，不尊重新来者，对周围的人表现出粗鲁的行为。不要成为那种人。善待他人，传播爱。
A lot of professional advice can be summed up with just four words.许多专业意见可以用四个词来概括。
Wrapping it up 包装起来
The best thing about our work is that it doesn’t have a limit. There’s are always new roads to travel and dragons to slay. Whether you’re just at the beginning of your journey or an experienced professional, keep these things in mind. They should help you find your way and become a better developer with each step taken. 我们的工作最棒的一点是没有限制。总有新的路要走，总有新的龙要杀。无论你是刚刚开始你的职业生涯，还是一个有经验的专业人士，请记住这些事情。它们应该帮助您找到自己的方法，并在每一步中成为更好的开发人员。
Do you have different advice to share with others? Feel free to post it in the comments and start a discussion! 你有什么不同的建议可以和别人分享吗?欢迎在评论中发表，并开始讨论!
Are you interested in learning web development or further improving your skills? Check devtrails.io for a collection of helpful guides to help you figure out your way around web development. 您对学习web开发或进一步提高您的技能感兴趣吗?检查devtrails。io的一组有用的指南，以帮助您找到您的方式周围的web开发。
文章来自：https://medium.com/devtrailsio/how-to-become-a-better-software-developer-dd16072c974e
