IT討論區(236) - Make IT Great Again!

See counter argument

你唔可以用常理諗呢間公司的

睇你請咩人啫
請junior 就problem solving
請senior/architect 一定係design pattern 緊要
有個好既repo 規劃做好多事起上黎係事半功倍

請senior/architect 一定係design pattern 緊要

以親身經歷黎講 完全不能苟同
可能有啲outliner 但係當你有個team lead成日注重”design pattern/best practice” 但連check個系統係咪healthy都唔撚識個時 真係十二分影響士氣
都係個句 你靚code ase整到你可以效率乘十都好 你本身係零 乘咩都係零
而且你會有個乘零點一既士氣factor

可唔可以解釋下check 個系統係咪healthy 係咩意思
個team lead 咁注重呢啲都係做醜人啫…
統一左個design pattern 大家都有好處
如果唔係第時有bug 要fix 嗰時真係gg

Business revenue

可唔可以解釋下check 個系統係咪healthy 係咩意思

故事係 我地要輸流每朝check個system正唔正常
有次條友講完開始check之後 咩撚都發現唔到

好在relevant既同事自己發現到有個大issue 有啲component冇起到 自己fix到
講緊我地有個dashboard 有component冇起到係紅色一眼會望到

之後過左25分鐘 佢先raise到一個好細既issue
但呢個issue其實前一日已經係group chat提左出黎係known issue

如果唔係第時有bug 要fix 嗰時真係gg

都係個句 你今日係廢既 今日係冇生產力既 日後個multiplier係幾大都好 零乘咩都係零

手巴對條team既整體主張係 大部分人強於problem solving
Team lead強於both 而且展現出黎係重視problem solving (重唔重視”design pattern/best practice”方面 如果你唔會因此忽略problem solving 其實a類人唔care你同時重視呢啲野)
可以請少部分人返黎雕花 但係自己開條branch去做refactor 唔好阻鳩住出feature 唔好比做feature既人高人工(or高人工唔好比做feature既人知)

唔係話”design pattern/common practice”唔好 但要諗係咪過度側重而不自知 要諗過度側重既壞影響

我親身經歷黎講 買咖啡俾老板係會高人工啲

女黎？

刷鞋還刷鞋，同老板落bar飲酒食雪茄的確對career有啲幫助，會聽到啲平時喺office (non-HQ)冇機會聽到嘅野，得到佢信任多少少，雖然人工唔代表會加特別多，但cut budget交人嗰時就有得頂下

親身經歷不要有trainee

同埋同老板落bar飲酒食雪茄，邊個埋單先？

得信任不加人工，呢啲老板跟嚟有乜意思。最尾咪又係騎牛揾馬

通過AI驅動嘅FinOps分析，軟件工程師最常開啟嘅軟件竟然係Excel，而唔係編程工具或其他開發軟件。呢個可能係因為軟件工程師喺日常工作中花咗好多時間喺Excel上，可能係用嚟做數據分析、報告、預算等工作。

呢個發現可能會引申一啲問題，例如：
- 軟件工程師點解會花咗咁多時間喺Excel上？
- 軟件工程師係咪缺乏更好嘅工具或技能嚟處理數據同報告？
- Excel係咪已經成為軟件工程師工作嘅一部分？

叫得老板都有番咁上下大粒，唔俾佢埋單就唔俾面佢啦

Team building/entertainment可以出公數添，但啲大粒佬通常都pay out of pocket

又唔係非黑即白嘅

得信任，然後多機會lead大project gain exposure，然後有晉升發展，咁咪加人工長做長有，呢條path未必差過跳黎跳去，因為公司有咁上下多人，internal networking, politics都緊要

當然如果佢一味畫餅嘅，呢啲老闆你都唔會想跟得耐

希望新司好老板，或者有其他兄弟內推下我

可唔可以內推我bug gor

工程師應該放心大膽地創造技術負債
身為軟體工程師，你應該要盡量寫出無法維護的程式碼，而且絕對不寫測試。

喺軟件工程領域，「反模式」（anti-pattern）同「反生產性」（counterproductive）嘅概念可以更具體咁應用喺開發過程同專案管理上。

1. 反模式（Anti-pattern）：
- 喺軟件開發中，反模式指嘅係啲睇似合理但實際上會導致問題嘅設計或實現方式。例如：
- 神物件（God Object）：將過多功能同數據集中喺一個物件入面，導致程式碼難以維護同擴展。
- 意大利麵條程式碼（Spaghetti Code）：程式碼結構混亂，缺乏清晰嘅模組化，導致理解同修改變得困難。
- 金錘子（Golden Hammer）：過度依賴某種技術或工具去解決所有問題，而忽視咗其他可能更合適嘅解決方案。

2. 反生產性（Counterproductive）：
- 喺軟件工程中，某啲做法可能會導致團隊效率降低或者專案進展緩慢。例如：
- 過度文檔化：雖然文檔好重要，但過度寫文檔可能會消耗開發時間，令開發人員無法專注於實際編碼。
- 頻繁嘅會議：過多會議可能會打斷開發流程，導致開發人員無法高效工作。
- 不合理嘅程式碼審查流程：如果程式碼審查過於嚴格或者頻繁，可能會導致開發人員士氣下降同生產力降低。

喺軟件工程中，識別同避免反模式同反生產性嘅做法係提高團隊效率同程式碼質量嘅重要步驟。

巴打你都好極端下
同埋你個例子似係你個team lead 廢多啲
通常有權講design pattern 既人最少都senior/arch level，有返咁上下實力同你所講既problem solving skills
請個junior 返黎幫大家set system architecture 成件事一定會柒
一黎無經驗，二黎枝笛唔會有人想聽