如何讓工程師一個禮拜工作 60~80 小時

從「How do you make programmers work 60-80 hours per week?」這邊看到的,出自 Quora 的「How do you make programmers work 60-80 hours per week?」。

看到標題的時候在想「這什麼詐騙集團類型問題 XDDD」,寫 code 的工程師一天可以專注三個小時就很了不起了好嗎,然後年紀愈大就愈難專注。每天可以工作十小時鐵定是一堆時間在看 YouTubeFacebookTwitter 的好嗎 XDDD

仔細看了文章以後,發現其實作者就是在講這個:

No programmers really work 60-80 hours a week, especially in a 5 day span. That is a 12-16 hour day, 5 days a week.

I promise you that any company that has programmers “working” that many hours is really only getting 2-4 hours of real work out of them each day. The rest of the time will be filled with pointless meetings, a fair amount of web browsing, and then a whole lot of looking busy.

真的有寫程式都知道的啦...

Stripe 的 Increment 雜誌

Stripe 推出了 Increment 雜誌,講團隊合作時的各種議題:「Introducing Increment」。

And so we've decided to start Increment, a software engineering magazine dedicated to providing practical and useful insight into what effective teams are doing so that the rest of us can learn from them more quickly.

雜誌網站上也有類似的描述:

A digital magazine about how teams build and operate software systems at scale.

Increment is dedicated to covering how teams build and operate software systems at scale, one issue at a time.

可以看一看 Stripe 對團隊合作的想法...

GitHub 允許員工在閒暇時間使用公司設備創作他們自己的東西

看到「GitHub now lets its workers keep the IP when they use company resources for personal projects」這則新聞,GitHub 正式的條款在「Balanced Employee IP Agreement (BEIPA)」這邊可以看到。

如同報導所提到的,只要不與工作內容相關 (或競爭),員工都可以保留權利:

This allows its employees to use company equipment to work on personal projects in their free time, which can occur during work hours, without fear of being sued for the IP. As long as the work isn’t related to GitHub’s own “existing or prospective” products and services, the employee owns it.

辦公室採用開放式空間的問題

這幾年對於開放式空間有不少反面意見出來,像是這幾天 BBC 登的「Why open offices are bad for us」。

這是目前的主流,大量的公司採用開放式空間:

Numerous companies have embraced the open office — about 70% of US offices are open concept — and by most accounts, very few have moved back into traditional spaces with offices and doors.

但人的效率會因為開放式空間大約掉 15%:

But research that we’re 15% less productive, we have immense trouble concentrating and we’re twice as likely to get sick in open working spaces, has contributed to a growing backlash against open offices.

採用開放式空間最常見的理由包括辦公室成本 (每個人平均分到的空間大小會比較低),另外一個是藉由開放式空間讓互相討論合作的成本降低,但因為開放式空間,反而是影響到別人的情況比討論合作的情況多,甚至是與工作無關的事情也會影響到期他人:

Beside the cheaper cost, one main argument for the open workspace is that it increases collaboration. However, it’s well documented that we rarely brainstorm brilliant ideas when we’re just shooting the breeze in a crowd. Instead, as many of us know, we’re more likely to hear about the Christmas gift a colleague is buying for a family member, or problems with your deskmate’s spouse.

其實科技的進步讓遠端溝通的成本降低了不少,像是 SlackZoom,現在未必要靠 open office 的架構讓大家溝通了。

Yahoo! 也放出了判斷是否為色情圖片的方案

感覺好像是從 AlphaGo 大勝李世乭開始,透過各類 neural network 的技術就一直冒出來...

Yahoo! 這次放出來判斷是否為色情圖片的也是同源的技術:「Open Sourcing a Deep Learning Solution for Detecting NSFW Images」。

當年沒辦法做的事情,現在的技術已經成熟到被 open source 出來了...

用 AspectMock 來替換 PHP function...

前幾天下班前同事說小鐵 jaceju 介紹了 Codeception/AspectMock 這個把 PHP function 抽換掉的套件,不需要靠 PECL 另外裝,不過缺點是只能抽換 namespace 裡面的 function... 不過這樣對於補 code coverage 也很夠了 :o

測了一下,寫了個小程式:

<?php

namespace myscript;

require __DIR__ . '/vendor/autoload.php';

\AspectMock\Kernel::getInstance()->init();

use AspectMock\Test;

echo time(), "\n";

Test::func(__NAMESPACE__, 'time', 'now');

echo time(), "\n";

然後跑出來變成:

1466612797
now

而字串 'now' 也可以換成 anonymous function,這樣已經可以做不少事情了...

Stack Overflow 做的 Developer Survey 2016

Stack Overflow 對開發者發問卷後把結果整理出來了:「Stack Overflow Developer Survey 2016 Results」,約 56k 個樣本數:

This year, 56,033 coders in 173 countries answered the call.

整個問卷分成五塊區域:Overview、Developer Profile、Technology、Work、Community,其中 Overview 的部份是給時間不多的人看的,整理了一些比較特別或是有趣的重點:

Most developers prefer dogs to cats. (But not developers in Germany.)

(唔?)

要注意的是,問卷只有英文版本,所以這份問卷明顯對於英文非母語的開發者會有比較低的填寫意願,會造成統計偏差問題,所以在讀之前要注意到:

Surveys aren’t perfect. While our large sample size helps offset some biases, it’s still biased against devs who don't speak English, or who don't like taking English-language surveys.

另外是有女性對這份問卷表示不滿:「Stack Overflow’s developer survey analysis hurts women」,尤其是 Stack Overflow 標示了只有 5.8% 的女性,這會導致女性樣本數在答案細分族群時的統計偏差的問題會很嚴重。

另外這篇文章的作者也對 Stack Overflow 裡的結論很不滿意。

回到原來文章,有些東西還蠻有趣的:

其中 Salary 這段應該是很多人都有動力去讀一讀了解的,裡面還包括了各地區與麥當勞的大麥克指數的相對數值分析,讓你有個參考值可以感覺。

KKBOX 徵才文

發現 WordPress 內建就有置頂功能 (Sticky),剛好開一篇來放目前我要找的職缺,先放幾個職缺,接下來會持續更新。試看看效果如何吧?

有興趣的可以把 resume 寄到 gslin at kkbox.com,或是純粹想問問題的也可以寄過來問。

最新更新時間:2015/10/09。

Continue reading "KKBOX 徵才文"

KKBOX 徵人:軟體開發中心 (i.e. Client Team)

索引:


在寫自家的介紹時,特地跑去跟軟體開發中心的主管要 Client Team 的介紹,人家交稿的速度快多了... Q_Q

Anyway,這篇是由 Client Team 的主管所寫的介紹,一樣是所有的部門都有職缺 (人力銀行上未必有開),有興趣的可以提供 resume 到 recruit at kkbox.com 這個信箱。


軟體開發中心 (Application Develop)

在 KKBOX 裡頭,我們還蠻習慣以老派的 Client/Server Side 來稱呼不同技術背景的開發人員,Client Side 說穿了就是開發 App 的那群人,只要你喊得出來的主要平台,大概就是我們負責的。

軟體開發隨著功能的演進,程式碼就會變得又肥又大,自然免不了些壞味道,面臨設計架構的難題,我們希望內部開發者能夠清楚三件事情: Design Pattern,Unit Test,和 Refactoring。上述觀念應當不用多說什麼,幾乎都變成顯學了。我們期盼透過一些原則和流程來讓開發工作變得不會那麼難以維護。

Client Side 目前共有四個 App 開發部門和 SQA 部門:

  1. Windows 開發部: KKBOX 在早期開發時,當時主流的作業系統還是 Windows XP,所採用的開發框架是 MFC,儘管技術很老,但那是個什麼事情都可以自己打造的年代,我們也樂此不疲。會用到 C++/COM 與微軟早年推出的視窗各類技術 MFC/ATL/DirectShow 。說個秘密,我們也還最低限度的維護著 KKman 呢。
  2. .NET 開發部: 主要負責的是 Windows Store App 和 Windows Phone 的開發,採用的是微軟在下個世代主推的 Universal App 開發框架來打造 KKBOX 在三個 Windows 平台的體驗。這部門需要熟悉的程式語言是 C#,部門有兩位微軟 MVP 相當熟悉微軟的平台技術,很活躍於微軟舉辦的聚會。
  3. Android 開發部: 很明顯地,就是在 Android 手機作業系統上開發 App 的部門,除了手機之外,我們也在 Tablet / STB / Smart TV 各式裝載 Android 系統的裝置上開發。需要熟悉 Java 程式語言和 Google Android SDK。這部門的開發人員很常在 Android Taipei 上出沒,分享開發心得。
  4. iOS 開發部: 聽名字應該也不用多解釋,主要就是在 Mac/iPhone/iPad 上開發 App,為了掌握最新技術每年我們都會派人前往舊金山參加 WWDC。需要會的程式語言是 Objective-C,當然蘋果力推的 Swift 也開始加入開發行列,每個月也都在 CocoaHeads 聚會中跟其他開發者閒聊。
  5. 測試開發部: 俗稱 SQA 部門,著重依據測試的原理和方法來設計測試案例,因此像是黑箱測試方法的 BVA 和 ECP,以及 MBT … 等等都是在設計測試案例時,會用到的測試原理。內部有個小組專門負責研究與建置自動化測試框架,讓各個專案可以各自依照需求建立自己的測試系統。需要熟悉 Python 程式語言,同時我們也將日常得到的心得放在「科科和測試 Testing with KK」上,提供給同樣想把軟體測試工作做好的每個人。

順道一提,除了 KKBOX 以外,還有 KKTIX,Hami Music 和日本服務 Utapass,也都是上述開發部門負責的。所以你要真的那麼愛寫 App 的話,那這裡應該蠻適合你的。

KKBOX 徵人

索引:


下面提到的所有職缺都有在找人,有些下面說明的職缺在人力銀行上不一定會開 (招募效果不好的會暫時先關掉,再研究要怎麼改),有興趣的可以寄信到 recruit at kkbox.com 這邊,如果只是想要問些問題的可以寄給我 gslin at kkbox.com

一般在介紹我所屬的部門時會這樣介紹:KKBOX 是 Client & Server 架構,所以這兩塊分成兩個 team。

R&D 的部份,Client Team 有五個團隊,前面是正式名稱,後面「」包起來的是我習慣的分類:

  • Windows 開發部:Windows 應用程式開發與維護。
  • .NET 開發部:Windows Phone (App) 程式開發與維護。
  • Android 開發部:「Google Team」。
  • iOS 開發部:「蘋果 Team」,包含 Mac 應用程式開發與維護。
  • 測試開發部:包括了上述的自動化測試以及手動測試。

我所屬的 Server Team 有三個 R&D 團隊:

  • 平台營運處:「API Team」,包括了開發與維護 KKBOX API,以及去接唱片公司的 API (像是,唱片公司會以 DDEX 格式將音檔提供給我們)。另外 KKBOX 的各類 Infrastructure 也會與這個團隊有關,像是 Search Engine 的建制。
  • 技術開發處:「Web Team」,包括了官方網站 (www.kkbox.com) 以及應用程式內的 Web View 的開發與維護,另外與網站相關的技術 (像是 Node.js)。而很多使用 HTML5 技術開發的 App 也是屬於這個團隊在處理。
  • 資訊系統處:「Billing Team」,包括了 KKBOX 內部的資訊系統,以及所有與金流相關的系統。

然後因為我在 Server Team 打雜,所以下面全部都是針對 Server Team 的職缺在說明... (當然,Client Team 的職缺也是可以寄信到上面講的信箱)

Overall

R&D 有兩個地點,一個在台北南港軟體園區,另外一個在高雄軟體科技園區。台北南港軟體園區是總部,目前有 250+ 人,高雄目前應該是 30+ 人。

內部大多使用 PHP 5.4+ 的環境 (大多都 PHP 5.5 了),有幾台機器用更舊的版本,目前正在 migrate 到 5.5。

PHP Framework 的部份,新的專案用 Laravel 4.2,目前計畫要換到 5.0。舊一點的專案用 Zend Framework 1.12,再舊一點的就是傳統的 PHP 了。

除了 PHP 外,還有用 Java (Search Engine 這塊) 與 Node.js (Server Push 機制),不過以 PHP 佔大多數。

資料庫的部份,MySQL 都已經是 5.6 (Percona 的版本,有單機版與 PXC 版本)。

版本控制的部份都用 Git,最早期的專案放在 GitHub 上,後來的專案有些放在 Gitolite,最近則是在轉移到 GitLab 上,配合 Merge Request 用。

冨樫...

要詳細說明公司福利以及這三個部門的職缺,但沒什麼力氣了,先讓我冨樫一下吧,晚點再開新的文章來寫... O_O