本文為譯文，譯者為 Leo Hui(我自己！)。
Businesspeople dig numbers. They don’t necessarily want to hear that you got something done; they want to hear how much you got done—especially relative to past results or some other relevant benchmark—and they want to know the value of what you did.
商人關(guān)注的是量化，他們想從你哪里通道你做了什么，帶來了什么價值，而不是你做了多少。
Some professionals have it easy when it comes to quantifying their job performance. Salespeople can measure their achievements in dollars and cents, for example, and many other fields also have clear-cut numbers with which to calculate their contributions.
教授可以輕松地量化出他們的工作，銷售人員可以計算出他們的收益。其他的領(lǐng)域也可以通過一些方式算出他們的貢獻(xiàn)。
For software developers and some other technology-based roles, however, quantifying your work can be a struggle without a straightforward solution. Yet doing so is crucial not just in job searches, but in many aspects of a software engineer’s career: performance reviews, effectively communicating up the chain of command, working efficiently with non-technical business units, and ensuring you’re properly valued within your organization.
但是從事軟件開發(fā)以及技術(shù)相關(guān)的人員，量化工作確實一個困難的事情。量化這件事情，不是在求職，更是一個技術(shù)人員生涯的一部分?？冃гu估，有效的了解溝通，高效的和非技術(shù)人員合作，確保你再團(tuán)隊或組織中的價值。
So how do you measure the value of the applications you build, scale, monitor, test, and otherwise support? Here are some of the approaches used at New Relic, as well as industry best practices:
但是我們要如何量化工作中的價值呢？這里有一些 New Relic 推薦的做法：
“I like to see work accomplishments described in terms of situation, action and results,” says Merilee Krebs, a technical recruiter at New Relic. “What was the business or technical problem to be solved? What unique actions did you take to resolve them and what was the resulting improvement.”
New Relic 的技術(shù)招聘人員這樣說："我喜歡看到用情況，行動和結(jié)果去描述工作成果， 技術(shù)人員需要解決的問題是什么？采用什么樣的行動去解決和提升這個問題。"
What does that look like in the real world? Try asking yourself some pointed questions: Did your monitoring and testing lead to a code update that cut down on help desk tickets by X percent? That’s quantitative gold right there. Did you deliver a new app six weeks ahead of schedule? Yeah, you’ll want to brag about that (in a professional manner, of course). Can you connect your code to strategic company objectives? Please, do so. Are you doing something that’s outperforming the traditional standards in your industry? You should be able to quantify the achievement is some way.
現(xiàn)實世界中是怎樣的呢？你試著問自己一些關(guān)鍵的問題：你有在更新你的代碼的時候去監(jiān)控和測試...這就是量化的目標(biāo)。如果你在日程表前六周就完成了一個 app，你肯定會去炫耀一下。但是你有考慮公司的戰(zhàn)略目標(biāo)嗎，如果沒有，請思考一下。...
If this exercise feels unnatural to you, you’re not alone—many programmers often aren’t born sales and marketing pros. If they were, they’d probably work in sales or marketing. So let’s consider six ways to better measure and communicate the value of your code and related work.
你是不是感受到一些不同的感覺，這不是你一個人的問題，技術(shù)人員的通病。如果技術(shù)人員做好了量化這一塊，那么他們也許就去從事銷售了。所以，讓我們考慮六種去量化你代碼以及工作的方式：
Think in percentages
Get involved with open source projects
Measure progress, not just products
Keep a work journal
Communicate in two languages
在我們關(guān)于高效代碼審查的博文中，我們建議使用一個檢查清單。在代碼審查中，檢查清單是一個非常好的工具——它們保證了審查可以在你的團(tuán)隊中始終如一的進(jìn)行。它們也是一種保證常見問題能夠被發(fā)現(xiàn)并被解決的便利方式。
軟件工程學(xué)院的研究表明，程序員們會犯15-20種常見的錯誤。所以，通過把這些錯誤加入到檢查清單當(dāng)中，你可以確保不論什么時候，只要這些錯誤發(fā)生了，你就能發(fā)現(xiàn)它們，并且可以幫助你杜絕這些錯誤。
為了幫助你開始創(chuàng)建一個清單，這里列出了一些典型的內(nèi)容：代碼審查清單。
你同樣需要把特定語言中有可能引起錯誤的問題添加到清單中。
這個清單故意沒有詳盡的列出所有可能會發(fā)生的錯誤。你不希望你的清單是這樣的，太長了以至于從來沒人會去用它。僅僅包含常見的問題會比較好。
把使用清單作為你的起點，針對特定的使用案例，你需要對其進(jìn)行優(yōu)化。一個比較棒的方式就是讓你的團(tuán)隊記錄下那些在代碼審查過程中臨時發(fā)現(xiàn)的問題，有了這些數(shù)據(jù)，你就能夠確定你的團(tuán)隊常犯的錯誤，然后你就可以量身定制一個審查清單。確保你刪除了那些沒有出現(xiàn)過的錯誤。（你也可以保留那些出現(xiàn)概率很小，但是非常關(guān)鍵的項目，比如安全相關(guān)的問題）。
基本規(guī)則是，清單上的任何條目都必須明確，而且，如果可能的話，對于一些條目你可以對其進(jìn)行二元判定。這樣可以防止判斷的不一致。和你的團(tuán)隊分享這份清單并且讓他們認(rèn)同你清單的內(nèi)容是個好主意。同樣的，要定期檢查你的清單，以確保各條目仍然是有意義的。
有了一個好的清單，可以提高你在代碼審查過程中發(fā)現(xiàn)的缺陷個數(shù)。這可以幫助你提高代碼標(biāo)準(zhǔn)，避免質(zhì)量參差不齊的代碼審查。
掃碼關(guān)注鍍金池微信號
手機訂課，優(yōu)惠多多
