對每個月一次的「Ask HN: Who is Hiring?」分析

timqian/hacker-job-trends 這個用 Node.js 開發的專案是針對 Hacker News 上的「Ask HN: Who is Hiring?」分析 (每個月一篇,拿來提供各家人馬留 comment 徵才的),把關鍵字丟進程式,程式就會分析每個月的出現數量,在 terminal 上產生趨勢圖表。而且支援加法或是減法計算,可以用在去掉重複的字 (像是 javajavascript)。

遠端工作的量慢慢增加:

而區塊練的量也在增加:

裝起來後看 php 的量好慘啊 XDDD

2011 年的研究,開放辦公室與病假的關聯性

忘記從哪邊冒出來的連結,反正是個 2011 年的研究:「Sickness absence associated with shared and open-plan offices--a national cross sectional questionnaire survey.」。2011 年在丹麥的研究:

METHODS: The analysis was based on a national survey of Danish inhabitants between 18-59 years of age (response rate 62%), and the study population consisted of the 2403 employees that reported working in offices. The different types of offices were characterized according to self-reported number of occupants in the space. The log-linear Poisson model was used to model the number of self-reported sickness absence days depending on the type of office; the analysis was adjusted for age, gender, socioeconomic status, body mass index, alcohol consumption, smoking habits, and physical activity during leisure time.

都是與 cellular office 比較,可以看出大於六個人的開放辦公室病假的量高出許多:

RESULTS: Sickness absence was significantly related to having a greater number of occupants in the office (P<0.001) when adjusting for confounders. Compared to cellular offices, occupants in 2-person offices had 50% more days of sickness absence [rate ratio (RR) 1.50, 95% confidence interval (95% CI) 1.13-1.98], occupants in 3-6-person offices had 36% more days of sickness absence (RR 1.36, 95% CI 1.08-1.73), and occupants in open-plan offices (>6 persons) had 62% more days of sickness absence (RR 1.62, 95% CI 1.30-2.02).

CONCLUSION: Occupants sharing an office and occupants in open-plan offices (>6 occupants) had significantly more days of sickness absence than occupants in cellular offices.

看起來只是拉數字出來分析... 另外信心區間的洞好大 XD

兩個都用 Slack 的公司可以直接在 Slack 上合作了

Slack 推出的新功能 Shared Channels:「Introducing Shared Channels: Where you can work with anyone in Slack」。

Shared Channels are a new kind of channel that connects two separate organizations, creating a common space for both sides to make use of Slack’s communication features and platform integrations when working together.

在截圖可以看到界面上,左半部會以 Shared Channels 顯示:

這邊也有提到 Shared Channels 需要透過管理員核准:

Accept the request: The other organization’s admin will receive a direct message from Slackbot, from which they can accept your request and add the channel to their workspace.

這樣就不用另外再開 guest 了...

創業的點子

在「Startup idea generator: find spreadsheet tasks and build something better」這邊看到很有趣的想法 XDDD 原討論區出於 Hacker News 上的 id=14631031 這則。

找到還在用 spreadsheet (或者說,Excel?) 的用途,然後設計新的產品 XDDD

1) Pick an industry
2) Ask someone in that industry what they use spreadsheets for
3) Build something better

算是一種很有趣但是也還蠻實際的想法 XDDD

在程式競賽得獎負面相關於工作的品質

2015 的文章以及演講,最近冒出來看到的。GooglePeter Norvig 提到了用 ML 的方式分析,發現程式競賽的成績與工作品質的負面相關性:「Being good at programming competitions correlates negatively with being good on the job」。

換句話說,程式競賽的成績反而是是個負面指標 (對於 Google 內的情況分析出來的,所以是基於 Google hiring process 的前提過濾過的)。

In this talk, Peter talked about how Google did machine learning and at one point he mentioned that at Google they also applied machine learning to hiring. He said that one thing that was surprising to him was that being a winner at programming contests was a negative factor for performing well on the job.

給了一些對原因的猜測:

Peter added that programming contest winners are used to cranking solutions out fast and that you performed better at the job if you were more reflective and went slowly and made sure things were right.

YouTube 的留言處也有一些猜測,像是:

What he's talking about is the fact that several extremely important parts of software engineering are not included in these contests, for example code reusability, maintainability, decomposition of the problem using the OO paradigm, etc. All of these make a good engineer, but are not necessarily needed in competitive programming contests.

「把工作自動化」的討論

最近在 The Workplace Stack Exchange 上還蠻火紅的一篇文章:「Is it unethical for me to not tell my employer I’ve automated my job?」。

作者的全職工作是從系統上抓資料出來,貼到 spreadsheet 上 (也許是 Excel?),這份工作的薪資還不錯,然後作者寫程式自動化掉後發現他每禮拜只需要做一兩個小時了:

There might be amendments to the spec and corresponding though email etc, but overall, I spend probably 1-2 hours per week on my job for which I am getting a full time wage.

然後在糾結要不要跟雇主講,跑上來發文 XDDD 有興趣的人可以去圍觀看一看下面的回應...

Slack 的 Screen Sharing

Slack 付費版將有 Screen Sharing 的功能了,對於 Remote Work 的團隊又更方便了:「Screen sharing comes to Slack video calls」。

When you’re working with teammates over a Slack video call, you may have something — a document, a chunk of code, the latest designs — that you want to share with your team. Now you can. Screen sharing is now available across teams on Slack’s paid plans.

需要使用 Windows 與 Mac 版的 desktop 處理:

Screen sharing is rolling out over the next few days to paid teams on the latest versions of our Slack for Mac and Slack for Windows desktop apps.

如何讓工程師一個禮拜工作 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.

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