Hype Driven Development (一窩蜂驅動開發)

I want to share an article which has some reflective thoughts about technology culture in development teams.

Original post (In English): Hype Driven Development
Chinese translated vernio: 一窩蜂驅動開發

Short summary

It is common for many development teams which fall into:

  • Reddit/Stackoverflow Driven Development
  • Conference Driven Development
  • Loudest guy driven decisions
  • Gem/lib/plugin driven development

The problem is that sometimes the solution/technology people talk about in Reddit/Stackoverflow/Conference may be just specific solution/technology fit into their original problem and use cases. The solution/technology fit your development teams’s problem and use cases.

Another problem is that the technology people talk about may not be matured enough. Such immaturity may cause
serious potential problems.

The article also mentioned some solutions to these problems. The author suggest development teams to learn technology not just from blogs but also experience. It is better to make some quick prototype or POC experiments before making decisions to have better experience and understanding to the technologies.
On the other side, development teams should analyse and understand their own problems and use cases. Listing Pros & Cons and do comparison with different technology/solutions.

My personal thought

the real problem is never because of Reddit/Stackoverflow/Conference or whatever driven culture. The real problem is that we should have clear understanding and deep analysis about our problems and technologies.

5 ‘myths’ about microservices that people believe about but not always true

I want to share this article:
Microservices? Please, Don’t
Although the title of the article is “Don’t” but actually it is not dis-encourage you to not using microservice. It just talks about 5 ‘myths’ about microservices that people believe about but not always true.

Fallacy #1: Cleaner Code

“You don’t need to introduce a network boundary as an excuse to write better code.”

Fallacy #2: It’s Easier

“Distributed transactions are never easy.”

Fallacy #3: It’s Faster

“You could gain a lot of performance in a monolith by simply applying a little extra discipline.”

Fallacy #4: Simple for Engineers

“A bunch of engineers working in isolated codebases leads to ‘not my problem’ syndrome.”

Fallacy #5: Better for Scalability

“You can scale a microservice outward just as easily as you can scale a monolith.”

關於Fortel的長遠發展方向

關於 Fortel – 紫微斗數命盤網 ,
我做Fortel,其實就係要做風水術數上既digitalization。

長遠而言,我是想在做好基礎﹑核心價值以後,向外發展,發大黎做。

1) 擴展至一般用家audience
現在這個網站還是由專業用家所用為主,普通用家往往看不明白。
現時方向是集中資源做好針對core專業用家jounal的核心功能,包括起盤﹑搵盤﹑命盤解釋判斷上既Intelligent功能。
在做好基礎之後,我想做更多target to普通用家的功能。
最終希望成件事可以像普通星座網的易用程度一樣,就算未能深入也至少淺出,能帶到value給普通用家。

2) 結合其他風水術數
現時我學過的知識只有紫微斗數(初階入門)及面相(新手)。
但中國風水術數,其實都是基於陰陽五行之說。不同風水術學之間,也有互相結合的可能性。
所以我會去進修其他風水學知識,希望能發掘到integration point,去玩更多有趣的東西。

btw, 將來如果可以結合圖像分析技術的話,係可以玩到好多野。

-------------------

IT人好多,風水佬都唔少,但有冇IT風水佬?(爆漿瀨尿牛丸)
外國冇乜人識中國風水術數,華人地區可能冇乜人會諗住將風水玩digitalization。
做出黎有冇用?
有,而家已經好有用,老師同同學個個都用緊我套系統,轉變晒成個process。
依d就係我做依件事既價值所在。

懷有遠大理想﹑努力於時代變革更新﹑承傳後世,我的命盤說穿了就是這種命。
Just go ahead。

 

逸事:與同事談公司

今天搭車走時,跟一位在公司做了六年的同事傾談。
談到現在公司,同事說每年4﹑5月都很多人走,又請很多freshgrad回來。
這個現像有點熟口面。

我問他,公司不斷請freshgrad,又留不住有點年資的同事,那該會有人材斷層吧?
如果knowledge是「跟人走」的話,那知識會有斷層嗎?不過現在公司算是比較多/齊document之類的東西。(同事更正,他說team team culture未必一樣)
雖然document看起來很眼訓很悶,但其實又很重要,不過價值是隱性的,最有感受的應是新手/基層員工。
同事說,老闆看的是大數,有人走,就請另一個replace,所以覺得沒什麼大不了。

同事說,出面銀行﹑金融機構,人工﹑福利都好,常有員工跳槽過去。
其實IT行業,有人材需求,流動性高,跳槽跳來跳去是常事。
一個流動性高的行業其實不錯,因為至少有選擇,不會壟斷供求。
如果目標只是搵食,我覺得現在是ok的,不會發達,很難買到樓,但基本生活應付得到,有錢食飯睇戲。
不過目標set得太低﹑太滿足於comfort zone,將來迎面來的一定會比預期低,自己很可能被淘汰。
所以目標要set得高點,維持適量的challenge。