當一個主管最糟糕的就是

1. 不信任下屬
2. 不加班就是不忙
3. 無法聽進下屬的話
4. 決定任何東西沒有與大家討論過
5. 用命令式口氣與下屬交談
6. 不了解全貌就否定新觀念
7. 以自己的標準衡量下屬
8. 不花時間了解下面的抱怨
9. 說自己很忙，所以工作要給下面做

對上對下的至理名言

當然，付錢的是老大，所以好像理所當然的上面一定是對的，除非你走人。

不過站在客觀立場上，還是有分所謂的對與錯，至於何謂「客觀立場」，我想那些著名的書籍應該可以「勝任」這樣的角色。

這些書籍有分好幾種角度來思考，有下看上，也有上看下。

如果每天上面與下面都拿一篇文章分別要求彼此照著客觀規則來走，不知道是上面要改的多還是下面？

破解無名小站

我其實可以理解想破解無名小站的心態，但我卻無法理解那些明明知道無名小站可以破解，卻還是要把裸照放在網路上的人 ...

身為一般使用者，想破解相簿自然是想看一些好康的，又或是與人結怨，想破解相簿讓他難堪，這是很容易理解的。

而身為技術人，骨子裡多少都會有一些不安分因子，總是會想要嘗試看看自己是否有辦法破解。

沒想到的是，無名小站的防護機制竟是如此的薄弱，連我這種菜鳥都可以輕易的破解自己跟朋友的相簿(朋友的相簿當然是經過他同意的) ...

奉勸大家真的不要再把隱私照放在網路上了！

Ruby 與 Python

Ruby 與 Python 的戰爭我想是永無止息的一天了 ...

對我這個菜鳥來說，其實我根本不知道兩者都優劣在哪，網路上充斥著似乎兩種語言都精通的高手們(還有精通超過五種語言的高手呢)，總是可以一直斥責對方，真神人境界也 ...

不知道何年何月何日我才可以有資格評斷兩種以上的語言呢 ...

目前台灣在網路上擁戴 Python 與 Ruby 的，我感覺就好像台灣政治的藍與綠，在氣質有根本上的不同 ...

藍 - Python
綠 - Ruby

說不定做個調查，還真的是如此呢！

不過常常看到某方的擁護者提出一個觀點－「寫程式是因人而異，所以那不是我們程式語言的錯」

這個論點其實是非常有問題的，工具的使用當然是因人而異，但卻不影響這個工具的客觀立場。

自行車給選手級的人騎著，當然是有機會可以超越機車，不過如果要環島一周，是那個工具比較優秀呢？

開發軟體時的自我要求

RD與業務的戰爭


這應該是個永遠的議題




其實我也染了許多業務的惡習，就是凡事容易求快，習慣先求成果，卻少了嚴謹的規劃。雖然資歷上我還是個菜鳥Programmer，但短短時間內卻也因為這樣的陋習多了不少困擾

1. 新人進來時，什麼都要親自下海教授
當然不是說就不需要教育訓練了，只是如果能整理一個好的教學文件，這樣的困擾可以減低不少，也可以增加新人學習效率

2. 移交部分開發工作給同事
反過來想，若是我必須接手另一個同事開發到一半的工作，我會希望有完整的文件可以瀏覽，並且coding style良好

3. 隨著code體積龐大，測試時間就只能等比往上加
這我想我連一般的programmer的資格都不夠，若是照著TDD來走，就不會有現在這樣的窘境了
可以參考這個網站

4. 使用者使用不便
這可能還是需要時間來磨練，現階段的我大概只能靠提供完整一點的文件來解決這個問題


要解決以上的問題，可能需要好好制定一些自我要求的流程了




除了事前完整的SA，在coding階段還是要有以下動作

1. 功能基本流程圖
若SA階段切不夠細，這邊就必須再設計出來

2. 功能概念簡報
盡量可以將每個功能切割成5張簡報以內可以呈現

3. Test code

4. 命名方式整理
不管是變數還是函式，都需要統一其命名格式，當然如果該程式語言有一個標準更好

5. coding style整理
其實上述應該算在這條之中，但刻意獨立出來重視命名方式

6. 邏輯性註解以及TODO

7. 功能使用方式簡報

8. 版本Release的更動紀錄


目前先這樣，有想到再補


可能會有些矯枉過正，但先這樣實行看看吧！不做做看怎麼會知道呢！