做爲程序員,我真的有時候特別想 debug 這個世界。看看這個世界到底是怎麼運行的。由於常常會遇到她的輸出跟我斷言的不同,或者我以爲正常的輸入,卻被她斷定爲非法。程序員
先分享兩件事吧。函數
第一件事,記得去年考駕照的時候,應該是在練科目三。教練帶着我練車,當開到一個地方時,讓我停車。而後跟我說:『這裏是一個考點,看到前面那棵樹沒?考試的時候,你把車開到離那棵樹大概這麼長的距離,停一下車』。我頓時懵逼了,我發現我對『大概這麼長』徹底沒有個概念。我就問教練『大概這麼長是多長?』,這下就輪到教練懵逼了,而後,就聽到後座早就等的不耐煩排隊練車的三個同窗跟教練異口同聲的對我說『大概這麼長就是這麼長呀』,同時給我一個看着智障同樣的眼神。大概這麼長就是這麼長,那究竟是多長,我完全凌亂了。那一刻我才發現我和世界不同。測試
好在後來教練沒有放棄對個人治療,但我能明顯感受出來,她教個人方式跟其它人不太同樣。後面跟我說話的畫風都是這樣的。『看到前面那棵樹沒?考試的時候,你把車開到離那棵樹半米的距離,停一下車。看到那個花臺沒?車輪與花臺平行,而且保持20公分的距離。看到前面那個電線杆沒?車頭與它的夾角成60度的時候,方向盤及時回正』,半米、平行、20公分、60度,這些詞讓我以爲這纔是正確的描述。但我仍是不明白別人是怎麼明白『大概這麼長』是多長的。debug
第二件事,我發現我怎麼都學不會作菜。究其緣由是什麼呢?由於我發現本身徹底看不懂菜譜。每次看到裏面充斥着相似鹽少量、醋若干、醬油適量等這樣的描述我都氣不打一處來。我若是本身明白適量是多少,我還去看菜譜幹什麼。我一直以爲寫這種菜譜的人,內心一點 B 數都沒有。可是呢?跟上面練車的例子同樣,別人就是能夠經過這些少量、若干、適量的字眼學會作菜,還作的不錯。這樣看來我可能纔是那個沒有 B 數的那個。設計
說到 B 數,我其實以爲這是一個比較粗俗的詞彙。可是,我一時又想不到有什麼詞能夠去替換它。若是非要找個詞的話,我就想起之前上學打『英雄聯盟』的時候,各類坑隊友。隊友老是能預判出哪一個草叢可能有人,哪一個地方會有誰來 gank 你,何時該到哪裏去。他們之間的溝通,一個眼神、一個信號就夠了。而我啥也 get 不到,老是送人頭,打單機。後來我就問他們是怎麼感受出來,簡直像開掛同樣,我怎麼什麼也感受不到。他們給個人評價是『由於你沒有意識』。對,就是『意識』這個詞。調試
爲何我沒有意識。可能意識這個東西比較偏感性思惟,而我偏理性思惟,也可能我天生就是一個意識薄弱的人。可是毫無疑問的是,當我選了理科,當我進入社會成了一名程序員,都一直在弱化意識這個東西。cdn
就拿代碼來講,代碼裏面寫的最多的是什麼,應該是方法。每一個系統是由 N 個類組成,每一個類又是由 N 個方法組成。而方法又叫函數,取自數學上的概念。wiki 上是這樣描述它的,『_函數就像機器或黑箱,給予輸入值便產生惟一輸出值』。_注意惟一這個詞,理論上函數的外部輸入值同樣,最終獲得的結果也是同樣。咱們寫代碼的時候大部分狀況下也是這樣,少部分狀況下不一致極可能是由於 BUG。這就跟意識沒有半毛錢關係了,一般在你輸入的時候就能知道他應該有什麼樣的輸出,用程序員的話說就是斷言。而如何知道輸出斷言,不是靠感受出來的,是你經過邏輯一步一步推導出來的,容不得半點感性思惟在裏面。blog
另一個場景,你們就很熟悉了。就是跟產品經理平常吵架。吵的緣由以下,好比加需求了、好比改需求了、再好比需求不明確了。。。無外乎都是圍繞着需求的。而其中最傷腦筋的就是需求不明確。開發
最近幾年 AI 很是火,每種職業都有一種,之後會不會被 AI 取代的焦慮,程序員也不例外。之前就看到過這樣的帖子,做者表達出相似的擔心。帖子的大概內容就是以爲 AI 發展十分迅速,假以時日,可能之後就沒有什麼程序員了,只有產品經理。之後開發系統的場景多是這樣的,產品經理登陸一個 AI 系統,在系統界面劈哩叭啦把需求輸入進去,而後 AI 系統根據輸入的需求瞬間生成了一堆代碼,組成一個新的系統。看到這個帖子,我瞬間就感覺到了那種焦慮,而後我就往下拉,看帖子的回覆,當我看到回覆裏面點贊最高的那一條時,我馬上就釋然了。點贊最高的那一條回覆是這樣說的『這種場景永遠也不可能出現,除非有一天,產品經理能把他們的需求說清楚』。🤣get
需求是程序員與產品經理之間永恆的話題。每次產品提需求,你都是先拋一個 5W2H 的靈魂拷問。作什麼、爲何作、誰來作、何時作、在哪裏作、怎麼作、作多少。有一點不清楚都要找產品經理倒騰清楚,說不清楚你們都別下班。記得,之前我在網上查項目經理與產品經理的區別。知乎上有一個答案讓我印象深入,他說『產品經理着眼於作正確的事情,項目經理着眼於正確的作事情』。項目經理其實表明了程序員這一類羣體。這個回答其實很好的闡述二者的關係。產品經理其實更多的是設計出一張正確的圖紙,而咱們程序員做的是拿着這張圖紙正確的去實施。其實,常常咱們會自嘲是搬磚的,可是若是從這方面看,還真是這個樣子。
產品經理會去想作什麼,爲何這麼作等問題。而咱們可能只是被動去想怎麼作。這是如今企業工做高度分工的緣由致使的。這自己無可厚非,可是若是久而久之,可能會剝奪咱們的思考能力。由於很大一部分思考,產品經理幫你作了,你不清楚的就找產品經理問清楚,缺少思考的過程,長此以往很容易變成了一個沒有感情的代碼機器。
上面說的是工做上,生活中更是這樣,雖然有本書叫做《人人都是產品經理》,可是現實世界中確定不是這樣。教練跟我說的時候,我拋個 5W2H 問題給她,她可能轉身一腳就把我踹下車了。生活中太多不許確、不明確、不科學、不冪等的事情了。只能學的去接受,生活中沒有產品經理,先什麼都理好了,而後告訴你怎麼作,也沒有測試同窗,幫你一遍遍調試定位問題。咱們不能由於工做的分工緣由,養成了依賴別人思考的習慣。要學着適當的跳出程序員的思惟去看這個世界。
本文由博客一文多發平臺 OpenWrite 發佈!