一個二流程式設計師的自白

今天看到這篇文章，心理有些想法，
雖說文章所說的不一定都是對，
但對於專業來說並不是每個人都是頂尖的，
如果一個人的能力尚屬普通的情況下，
也仍然要找到其生存的方法。
對於技能來說，有些人覺得夠用就好，
有些人追求頂尖，都事在人為。
不過大老闆大概都希望自己的員工都是追求頂尖的吧，
有時沒有所謂一步登天，也得一步一步來，
不論一流二流，掌握生存的方法之外，
收穫多少也會反應自己做事的原則與能力，
不然就看你運氣好不好了。


簡單的翻譯一下，有誤還請指教：

—————————————————————————————————


Confessions of a mediocre programmer

一個二流程式設計師的自白

Date(日期): March 9th, 2010
Author(作者): Alan Norton

Alan Norton reveals how he makes the best of his average coding skills to survive as a mediocre programmer.

艾倫諾頓揭露對於二流程式設計師來說，如何盡其最大力量發揮其中等水平的程式設計能力

—————————————————————————————————

I have always enjoyed writing code, not because I was good at it, but in part because it was such a challenge. I found no thrill in commanding a personal computer to display “Hello World!” on a monitor. Seeing three red cherries or the Ace and Jack of spades show up on a monitor is a different matter entirely. One of the first programs I wrote out of college was a slot machine program written in Northstar Basic for the Northstar Horizon, followed by a graphics-based Blackjack program written for the Northstar Advantage.

　　我總是樂於撰寫程式，但不是因為我很善於這檔事，而是某種程度上這是個有挑戰性的事，對我來說能命令電腦在螢幕上顯現出『Hello World!』的字串不是一件很令人興奮的一件事，不過如果出現撲克牌符號應該就完全不同了。大學畢業後我撰寫的第一批程式，其中包含有相容於 Northstar Advantage 系統的圖形界面撲克牌二十一點程式，接著還寫了運作於 NorthStar Horizon 系統，用 Northstar Basic 寫成的吃角子老虎程式。

As much as I enjoy programming, I must in all honesty admit that I am a mediocre programmer who has always found a way to get to the big payoff — that is, when the program ran without syntax errors and something magical happened. It is not too surprising then that I never worked as a programmer per se; I found my talents more in line with those needed to be a good developer. But before we go any further, I’ll give you my definition of a mediocre programmer.

　　可以說，我熱衷於寫程式，但老實說我也承認我是一個總能找到方法完成事情的二流程式設計師，並且只要寫出來的程式沒有語法上的錯誤或意外的狀況發生就行了，所以這也不另人意外的，本質上，我工作起來從不像一個程式設計師，不過我覺得自己還是有作為一個研發人員的天份。但是在談論之前，我想談談我對於二流程式設計師的定義。

Mediocre programmer - A programmer who has a limited toolset. He knows the syntax of only the simplest commands, but he knows where to find the syntax for more complex commands. He doesn’t know how to write the most efficient code, but he knows how to rewrite and test the code for greater efficiency if he must. He runs into more roadblocks along his passage to success, but he views each as a challenge and is confident that he will find a path around each roadblock. He may take longer to get there, but he always reaches his goal. He doesn’t know how to create a DLL, but he knows he can if necessary. Like most programmers, he doesn’t particularly like documenting his work but does so anyway because he is a professional.

　　二流程式設計師：一個局限於手邊能使用工具的程式設計師，只知道最簡單的命令語法，但是知道去何處尋找複雜語法的資料，不過不知道如何去撰寫最具效率性的程式碼，但如果需要的話，也知道如何去重寫或測試出擁有最具效率性的程式碼。不過在撰寫程式的過程中，在達成目的前可能會碰上比較多狀況，但視之如挑戰，雖說也許會花很多時間，但對所面對的每個困難也都有信心去一一解決，至少總是能夠達成目標。例如也許不知道如何去創建 DLL，但如果有必要去這麼做的話也知道如何去達成，如同大部分的程式設計師，二流程式設計師不特別喜歡著墨於處理文件相關方面的工作，但無論如何二流程式設計師還是具有專業性的。

The job dictates the skill set

所作的工作會支配著所會的技術

While I would have loved to continue writing games, the desire to eat led me to the local job market; companies have this strange requirement better known as real work that must be accomplished. Production, human resources, accounting, inventory tracking, and metrics reporting are just a few of the necessary evils of doing business — you know, the really boring stuff.

　　雖然我喜愛繼續著墨在遊戲方面的程式撰寫，不過胃口大一些我也會寫一些有市場需求的程式，許多公司總對於一些必須完成的實際工作有特別的需求。這都牽涉到在做生意的時候，於生產、人事、會計、存貨盤點或數據衡量報表方面等一些必要作業，都是一些令人感覺無趣的部份。

My skill set changed dramatically when I was actually paid to program. It doesn’t take a lot of advanced coding skills to move data around and magically turn it into information.

　　後來，我在所會技能方面有很多的改變，主要是因為我花很多時間在程式上，但在資料轉換或讓資料呈現為有用資訊方面也並沒有用到很多進階的程式技巧。

I was hired by Hughes Aircraft to support its Production Control department with IT services. My job required developer/analyst skills, and I loved my work. Programming was but a means to an end.

　　我曾經受雇於 Hughes Aircraft 這家公司的資訊服務部門，去支援另一個產品控管部門的作業，這工作我需要研發與系統分析的技能，總的來說我喜歡這個工作，寫程式只不過是一個達成目的工具而已。

A developer has to wear many hats

研發人員總有多種面貌

Programmer is but one of the many roles of a developer; you often have to wear the following hats as well:

Buyer (with budget)
Scavenger (no budget)
Analyst
Designer
Planner
Programmer
Coordinator
Tester
Documenter
Support technician

程式設計師只不過是作為研發人員所扮演的多種角色中的其中之一種角色，這些角色如下：

採購人員（公司有給予預算的情況下）
免費可再利用資源的尋找者（義務性）
分析師
設計人員
規劃人員
程式設計師
協調人員
測試人員
文件製作人員
支援工程師

It is not too surprising then when a developer is not considered an expert in one or more of these roles. For me that job function was programming.

　　如果一個研發人員沒有成為這幾種角色當中的其中一種的專家，也無須過於驚訝，對我來說自己的主要職責還是在程式撰寫。

How I survived

如何生存

Even with my less than stellar programming skills, I was very successful as a developer. Here are some tips I learned over the years and how I survived as a mediocre programmer to make the best of my average coding skills:

　　即使我擁有較少的程式撰寫技巧，但我總是能成功的扮演了研發人員這樣的角色，這裡有一些我在這幾年所學到的東西，告訴我當自己是一位二流程式設計師的時候該如何生存，並且盡情發揮自己平庸的程式設計能力：

Requirements — I got a complete and accurate list of the system requirements up-front. Waiting until you begin coding means that you haven’t based the system design on the requirements.

需求：對於預先需要的系統需求我有完整且詳細的列表，在開始撰寫程式前，會有一段等待時間，不會只依賴需求去作系統的設計。

Analysis and design — I got the analysis and design right. An average programmer has an advantage over a great programmer if the former gets the analysis and design right, and the latter gets it wrong.

分析與設計：我自己擁有分析跟設計的權力，假如一個二流程式設計師擁有分析與設計的權力，所擁有的優勢會大過沒有此類權力但設計能力較強的程式設計師，後者可能也因為沒有這些權力而失敗。

Project plan — I confess that I didn’t use a formal project plan early-on in my career. It wasn’t until I joined CSC, and I had to use more formal documentation techniques, that I began using project plans. It was then that I fully realized the advantage a mediocre programmer has when using a well thought-out project plan.

專案計畫：我承認早期我沒有一個正式的專案計畫，直到我到 CSC 工作，我必須學會更多比較正式的文件技巧，於是我開始進行專案的規劃，後來我深刻體驗到對於一個二流程式設計師來說，運用一個深思熟慮的專案計畫所擁有的優勢在哪。

Well-thumbed manuals — I always kept the manuals close at hand. I also invested in additional reference materials.

手邊有工作必備的手冊：我手邊總會帶著工作需要的手冊，並且投資在這上面。

Copy-and-paste programmer — I don’t mind admitting that I was a copy-and-paste programmer. Over the years, I wrote a lot of code that could be reused in a new project. I always took the time to write the code at least once so I had some knowledge of how the code worked. However, I never copied code written by someone else while on the job, and I never used code I had developed at another company. The golden rule and copyright laws apply to intellectual property: You may not copy and use someone else’s code unless expressly permitted, or you are granted special permission.

善於利用過去已經寫好的程式碼：我不避諱我是一個會利用其他現成程式碼的程式設計師，經過許多年，我寫了很多程式碼，有時新專案的時候仍然會用得到，至少我曾經花費時間去撰寫這些程式碼，所以知道它如何運做，但無論如何，我不會引用別人的程式碼，我也未曾利用我在別的公司開發的程式碼，這牽涉到智慧財產權：除非得到同意或給予特別的授權，不能任意複製或使用他人的程式碼。

Perseverance — I never gave up, and I always believed I could accomplish any programming task.

毅力：我從沒放棄過，並且總是相信自己能夠勝認任何程式撰寫的工作。

Tools — When I needed a faster computer but it was not budgeted for, I found a manager who was willing to give me part of their budget in trade for my computer. Beg, borrow, or trade to get the tools you need to accomplish your task and always ask your manager; a good manager will do his or her best to find a way to get the software, hardware, manuals, or help you need if it is justified.

工具：當我需要一台更快的電腦但沒有足夠的預算時，無論用什麼方式，我會找主管解決這問題，不論是用借的或其他方式去得到我需要的工具以完成工作，所以有這需求的時候我總是會向主管開口，在有正當理由的情況下，一個好的主管會盡它所能去取得你需要的軟體、硬體與書籍等你需要的資源，幫助你完成任務。

Serendipity — Also known as the “Just write code and it will get done” strategy. There were times as a junior programmer that I just wrote code, and it all came together. I liken it to that game of chess that you play and suddenly discover that you have given yourself the opportunity for checkmate in two moves. This isn’t how programming should be done, but since I am confessing my professional sins, I have to include this item.

發現意料之外的解決方法的運氣：即所謂的『動手去寫，程式自然就會完成』的策略，當我還是一個初學的程式設計師的時候，我有很多次都是直接就下手去撰寫程式，最後很自然的就將程式完成了，這就像下西洋棋，邊下邊走的過程中你才發現有機會在兩步之內擊敗對手，雖然這不應該是程式設計應當去作的一件事，但由於職業上的罪惡感，我承認從過去到現在我有這個想法，所以寫下了它。

The bottom line

底限

I have one final confession to make: I don’t appreciate being thought of as a second-class team member. I have known superb but rather naive programmers who really believed that if you can’t write “sophisticated” code, you are worthless to the team and company. This elitist belief that average programmers are inadequate and incapable of producing high-quality code is almost always wrong and offensive. I am somewhat amused and amazed by the notion that you aren’t a good programmer if you can’t __ (fill in the blank).

　　最後我要承認的一件事：我不喜歡把自己看成是一個團隊中的二流成員，我認識過天生的程式設計高手，他們相信如果你不能寫出高超的程式碼，你對公司或團隊就沒有價值，這種精英主義的信念，對於能夠寫出好品質的程式碼的二流程式設計師來說，是錯誤且相當不敬的，所以對於那些不能做什麼就代表就不是好的程式設計師的說法我感到可笑且驚訝。

You don’t have to be a whiz-bang programmer to be a great developer, particularly if you are developing business-related systems. Yes, I am a mediocre programmer, primarily because I never needed to be a great programmer.

　　對於成為一個好的研發人員來說，成為一個一流的程式設計師並不是必要的，特別是你在開發商業系統的時候，的確，我是一個二流設計師，主要也是因為我並不需要去成為一個頂尖的程式設計師。

I am not condoning mediocrity; you should always do your best in whatever you do — including programming. It can be difficult to identify the “best” code, however. Code that is more efficient may be harder to maintain. It can be argued that any code that gets the job done is good code. Code is like a Soma cube; there are 240 ways to solve a Soma puzzle and many ways to write code that accomplishes a task. The bottom line is to get the job done as best you can — which even a mediocre programmer can do.

　　以上文章，不代表我覺得人應該成為一個平庸之才，你應該盡你所能去作你想要作的事，包括程式設計，但無論如何在程式撰寫方面，有時很難判定什麼是『最好的』程式碼，最有效率的程式碼可能很難去維護，任何能夠達到目的的程式就是好程式的說法的確有所爭議，但程式碼就像索馬拼圖遊戲，你有 240 種方法去解開索馬拼圖遊戲所產生的謎題，撰寫程式碼也同樣有許多方法可以去完成，底限就是以一個二流程式設計師能作的來說，你能盡你所能的去完成工作。