程序员的好习惯（翻译）
应该是去年十一月份的一次翻译，来源是 quora 的 https://www.quora.com/What-little-habits-made-you-a-better-software-engineer，时间真快啊
Your time is precious, save as much of it as you can. Automate everything. Once your time is a commodity, you can achieve your next great innovation.
你的时间是无比珍贵的事情，卓有成效的程序员通过自动化任何重复的事情。当你的时间是一个商品，你才可以达到你下一次更大的创新。
Use a powerful IDE (like vim), and configure it to do as much as possible for you. Strive for single command Build/Test/Deploy/Run.
使用一个更专业的开发工具(哪怕像vim),并且去配置它,让它可以为你做尽可能多的事情。努力去调整自己的工作流程，可以一键去 Build/Test/Delploy/Run. If you find yourself doing things frequently, make them happen in one button press, or one click. Or better yet, make them happen automatically.
＊如果你发现发现你经常会手动按顺序做一些事情，让这些事情可以一键完成，当然更好的情况下，让这些事情可以完全自动化发生。
Learn keyboard shortcuts and the unix command line. Almost any IDE will let you run complex build commands and even arbitrary terminal commands - these can be powerful and save you significant amounts of time.
＊ 学习快捷键和 unix 命令行。几乎所有的IDE都会允许你去执行复杂的build命令，甚至更多复杂的终端命令，这些知识会节约你大量的时间。
Ask questions, then ask more questions. If something is happening that you don’t understand, ask why. Then ask why that is. Then go away and research alternatives, and propose them. Ask questions until you could explain in complete detail to the next new developer that asks why. I am frequently surprised at the number of developers that don’t do this and just rely on the “because its always been/worked like that.”
＊ 问问题，问更多的问题。如果有些事情发生，但是你并不能真正真正的理解这些事情，要问为什么。然后问为什么这样会发生。然后就去做研究然后去和别人讨论这些问题。问问题直到你可以完整的向另外一个有这个疑问的工程解释清这个问题的全部细节。我经常很吃惊有大量的开发人员不是这样去对待问题的，而是只是回答，“啊，它就是这样的，我不知道”
Challenge the status quo by providing better alternative solutions - and make significant steps towards implementing them. If your tests are incomplete, or run once a day/week - then become the local Continuous Integration guru - pitch to your team the benefits and implement it. Once you are using it and it is helping you work better then get your team using it too.
要勇于挑战现状，现状可以通过开发人员提供更好的替代方案得到改进，并且真正努力的去尝试实现这些替代方案去改进并不如意的现状。如果你的测试覆盖率并不够，或者只是每天或者每周去跑一次，那么你可以尝试去搭建一个CI，把CI的益处展示给你的team，并且能够真正的把这些益处引入进来。 一旦你开始使用它，它会帮助你工作的更好，并且可以让你的团队走出原有的这个困境。
Don’t just challenge others, challenge yourself. Never written a web app? Write one. Never done python? Hijack UAVs with python.
不要只是质疑别人，挑战你自己。没有写过web app？那就去写一个，从来没有搞定过python？那就可以用python去搞定无人机相关的事宜。
Own something. Create something. Doesn’t have to be a technical project, could be an event, like a meetup or a hackathon, could be a game, a website, a blog.
去积累你的技术资产。真正的去创造一些事情。并不一定是一个开源项目，可以是一个事件，比如组织一次线下聚会，或者一次 hackathon，也有可能是写一个游戏，一个小网站，一篇blog。
Teach something. Java, public speaking, writing, chess, vim, tennis. 尝试的去教一些你已经开始学习的东西。java ，公众演讲技巧，简洁明了的协作，优雅的象棋，vim的技巧(long live nvim)，网球。
Be a beacon of excellence. Got a class/component that is rubbish? Fix it. Write code the right way. Don’t take shortcuts in your code. Make intelligent decisions and justify the pros and cons why you made that decision to those around you. Always make improvements to your code. Spot a TODO that would take less than an hour? Just Do It.
追随卓越。一个类或者一个组件写的很烂，开始动手把它写的很漂亮。以正确的方式编写代码。不要在代码上使用简写。想清楚整个代码，并且确定你写下的代码对其他代码的影响。永远不忘对你的代码进行求精。与其去对可能会有不需要多少时间进行修正的事情标记一个TODO，不如现在开始动手。 Browse the Stack Exchange in a topic you are familiar - like your favourite language. When you find something new to you, bottom out your knowledge of it as fast as possible. Know C? Whats branch prediction? This post will tell you - learn.
浏览那些你熟悉的话题，在 stack exchange 上，比如一门编程语言。当你发现在这个你熟悉的领域里有一些新的东西不是很清楚，那么尽快去从底层去夯实你的知识。精通C? 那么什么是分支预测？这样的东西会提醒你学习。^ Browse the Stack Exchange in a topic you are unfamiliar - everyday’s a school day. 浏览哪些你并不是特别熟悉的话题在 stack exchange 上，每天都是一个可以学习新东西的一天。
Learn to communicate. Written word, presenting, problem solving, small intense projects, large teams, small teams. 学习如何更好的交流，如何写一篇更好的文章，如何去做展示，如何和别人交流去真正的解决一个问题，在非常小的项目里怎么去做，在大的团队里怎么去做，在小的团队里怎么去做。
Document everything you do as you go. You can refer back to why you did things and rely on your previous solution to similar problems when faced with them. It also helps to capture your thought process and key pieces of information you may forget. I frequently flick back through my diary over the previous few days’ work.
对于你所做的每件事情记录一份文档。你可以通过这个，很快的回想起过去你为什么要做某类事情,或者很快的解决一个你曾经面对过的问题。养成这样一个习惯也可以帮助你记录当时的思考过程和可能遗忘的关键信息。我经常通过我的日记回顾之前几天的工作。
Document your code before you’ve written it. Use system diagrams, class hierarchies, flow charts to show how your code will work. If people have suggestions - and they will - you can make amendments much easily than when you have actually written the code. This is the other biggie that I see surprisingly few people do which can have the most negative effects. 在你写代码之前就应该写文档。使用一些系统设计图，类型架构图，流程图去描述清楚你的代码应该怎样工作。如果其他人有建议，他们一般会有，你可以及时的去做修正，在你真正开始写代码之前。这是另外让我非常惊讶的，很少有人去做的有益处的举动。 Be specific. So you’ve crafted your diagram for your new thing. Show it to everybody. Gather as much detail as possible. Ensure everybody agrees with the diagram, and if they don’t change the diagram. If anybody puts pen on your diagram, add those additions/corrections to the diagram. Keep the diagram up-to-date. 更具体。如果你对你可能要做的新事物打了更新，那么把它展示给所有人。对为这份更新手机尽可能多的细节。确认每个人都同意这份更新，并且确认每个人都不会更改这份更新。如果有人对你的草稿有建议，添加增加和修正到这份图纸上。保证你的图纸随时更新。
Learn about unconscious bias and male privilege. Learn about MBTI and which personality type you are and more importantly, how to interact best with other personality types. Learn about Emotional intelligence. Everybody in the world is different to you, and you need to know how to interact with them in the most efficient and constructive ways.
学习无意识偏见和男性特权。去了解你的职业性格，并且更重要的是学习如何与其他类型的人打焦点。学习情商，每个人在这个世界上都与你不同，所以你需要去学习如何有效的并且建设性的去和别人进行交流。
Regularly do something for your team. Bring in cookies. Teach a magic trick. Cultivate a bit of culture and encourage others to do the same. Only praise other peoples’ contributions. A cohesive team is hard to beat. 周期性的为你的团队做一些事情。带一些自己烘培的饼干，教team一个魔术技巧。雕刻一些团队文化，在自己奉行的基础上，鼓励大家去拥抱这些文化。为别人的贡献鼓掌。
Learn how to work with people. I personally really enjoyed The Pragmatic Programmer’s “stone soup.”
学习如何与人共事。我个人非常喜爱The Pragmatic Programmer’s 书里的 “stone soup 这一节.
Understand and use other people’s code. If you are implementing your own xml parser or csv reader or git hook there is a good chance you are Doing It Wrong. 理解并且使用其他人的代码。如果你正在实现实现一个你自己的xml parser 或者 csv reader 或者 git book 那么大部分情况下你是在做错误的事情。
Once you have written your code, and it works and passes your tests, go back and tidy it up. Re-run the tests. Now tidy it up some more. Each class should have a single responsibility and each function should do one thing. Functions should be less than 20 lines long in most instances. Use self documenting names for functions and variables. Spending time tidying up your code will be repaid 10-fold to you and the rest of your team. 一旦写完代码，确保代码是工作的，并且通过你所有的测试，然后重新去组织你的代码。再检查你的测试，然后再尝试去组织你的代码。每一个类都应该单一职责，而每一个函数都只应该负责做一件事。每个函数都不应该超过20行。尝试给每个函数和变量一个自解释的命名。花一部分时间去组织你的代码会节省10倍的时间对于你和你的团队。
Get involved. Take responsibility. If something isn’t right, fix it. If the deadlines are slipping suggest a solution and make others aware as soon as possible. Anybody can do this, even the most junior developers. This requires understanding of the bigger picture of the project, its direction and deadlines - so again - get involved. Save the day!
参与进去，负起该负的责任。如果一些事情并不正确，那么尝试去修正它。如果时间失控，那么提供一个建议，然后让其他人也意识到这个问题。每个人都可以做到这些，哪怕是一个初级的工程师。这需要对整个的工作做一个了解，包括这个项目的方向和截止日期。再强调一次，要参与进去。
Share lessons learned (when appropriate) with your team. Just figured out what happens when throwing an exception from inside a finally block in Java? Share it.
分享你学到的知识和你的团队。刚刚弄清楚异常到底发生了什么，分享它