Just My Life & My Work

Posts tagged ‘work’

[圖解] 老闆、專業經理人與freelancer的差異

在資訊爆炸的網路時代,文字內容充斥在各種訊息管道,如FB和Line是台灣人最常使用的社群平台,這麼多文字訊息怎麼消化得完?此時就有賴組織能力非常優秀的網友幫我們整理成圖表。這次我發現圖解老闆、專業經理人與freelancer的差異非常具有參考價值,於是就張貼出來分享囉~

其實這張圖是在2018年10月被我看到,它是篇幅員廣大的文章,把老闆、專業經理人與freelancer的差異講得非常深入淺出,對於一個一輩子都在工作的人,想必能從中獲得些什麼,僅管可能一輩子都只是個「員工」。

我跟大部分勞工朋友一樣,目前只是一家中型企業中的員工,協助開發公司產品iOS App。過去曾有數次創業邀請與參與,結果都不甚理想,也不能說完全沒有收穫,一開始是美麗且偉大的藍圖展現,熱情噴發想要做點與眾不同的事,逐漸遇到挑戰與困難在前頭,才了解理想與現實的差距很大。

我公司的Team Leader算是個專業經理人,24小時隨時on call,回想當時我剛加入IT Team,也才10人左右的團隊,如今已經超過人左右的團隊,半年後如今已經超過20人。有一大部分的人才來自過去的前同事,還有這些前同事的介紹如高中、大學、同事等等。我想多善加利用人脈資源,加上細心與毅力的溝通能力,是可以組織個好團隊!

曾經我想當個Freelancer,自己決定上下班時間,雖然經歷過後實現困難,但也不是那麼遙不可及,我會持續朝這方面前進,在正職工作之餘發展能變現的興趣。

半年後我才分享,可見我這一段日子過得很不優哉?其實就是忙歸忙,想法很多卻來不及整理出文章,看來做自己比當老闆、專業經理人與freelancer還要重要呀XD~

參考:從商業角度探討老闆、專業經理人與freelancer的差異成為自由工作者兩年後

廣告

[iOS] 改善Xcode編譯速度

專案已經開發超過一年半,累積的檔案數量已將近2500個(可見文章:專案檔案數遞增),想必日後編譯速度將會越來越慢,會深刻地影響我們開發的效率,尤其是在要了解前人所寫的程式碼,我們總是會稍微修改一下變數/參數來嘗試是否為增修的關鍵目標,所編譯頻率相當大,三不五時就要按Command+R

我嘗試過許多改善開發效率的方法,其中有三個可以嘗試:

  1. 提高XCode編譯時使用的執行緒數
  2. 將Debug Information Format改為DWARF
  3. 將Build Active Architecture Only改為Yes

1和3在我們的專案早已設定完畢,只剩下2可以嘗試,沒想到效果超好,提升幾乎10倍快的編譯速度!

(繼續閱讀…)

[iOS] 專案檔案數遞增

本週輪到我第二次「文字探討」,這一次我分享進階除錯技巧,關於XcodeLLDB。首先我表明為何需要學習進階除錯技巧,因為我們公司開發產品,歷時一年五個月專案檔案數遞增有目共睹,我特別透過Git回溯各時期的版本,來指令算出專案有多少個檔案。

檔案數隨著時間呈現性成長!

為何要查詢專案檔案數?這跟編譯時間有很大的關係呀!

(繼續閱讀…)

[圖解] 技術債 (Technical Debt)

最近陸續有新人來公司報到,我跟一位很年輕成功轉型工程師的同事(原本是教小學生課輔,網路看影片自學寫程式)聊週末去哪玩,他提到自己想要還技術債 (Technical Debt),我以為他要改前人留下來的專案,他說因為很多技術還沒有熟悉,所以想要更用功在鑽研技術上。

突然我想到小英總統2018年底變成辣台妹,因為人家說她「撿到槍」。原本的意思是貶義,拿到不屬於自己的東西(也就是贓物),就說那是撿來的。對於小英勇敢回應強勢的對岸,就變成褒義,表示拿到神級武器,可以從挨打的份逆轉成反擊!不過扯遠啦XD~

後來他表明不曉得技術債真實意義,我便簡單解釋,因為急著要完工,難免會以不周全的寫法完成程式功能,之後若要增修專案,就會面臨之前的「遺毒」。下圖可以明白技術債的陰影面積XD~

製圖的作者很神奇,使用我非常喜歡的動畫獵人拿酷戮的念能力可以來做解釋,胖娃隨著時間債會越滾越大,最後破產就會讓敵人無法使用念能力。若拿來比喻軟體工程,技術債若隨著時間累積,到一定的程度使人難以再做增修,此時專案就要宣告「打掉重練」!

要快又要好,實在不是很容易!除非專案只是一次性,若要長期維護的話,還是要有品質地實作呀~

想起先前分享的文章:設計師的心聲專案的三個要素

註:拿酷戮的念能力「天上不知唯我獨損」(推測是放出系的念獸)另外十分擅長於逃跑。「天上不知唯我獨損」是將念借給對方並以複利計算的高利貸,由胖娃娃「波克里林」計算,在借貸內攻防皆不會受到傷害,借貸額數超過對方念的最大值就會破產,「討債魔」出現強制對方進入絕的狀態30天。

參考:Scrum Estimation-Scrum Estimation Model獵人WiKi – 拿酷戮•拜因有效面對技術債專案中的隱形殺手:技術債

失業給付與提早就業獎金

新工作邁入第五個月,想起失業給付在就業超過三個月後,已能夠申請提早就業獎金。我是使用Mac上網使用自然人憑證,在網站申請:勞保局網站-個人網路申報及查詢作業。也下載勞保局行動服務App,來查詢當前審核進度。

時程記錄如下:

  • 3/3:申辦
  • 3/4:核定
  • 3/12:核付
  • 3/15:匯款

很好~勞保局E化作得讓我用的很方便!

(繼續閱讀…)

概念驗證 (Proof of Concepts)

我們開發軟體會透過Jira來記錄細節,像是新增功能修正錯誤,甚至還有概念驗證 (Proof of Concepts)

概念驗證(英語:Proof of concept,簡稱POC)是對某些想法的一個較短而不完整的實現,以證明其可行性,示範其原理,其目的是為了驗證一些概念或理論

(繼續閱讀…)

[圖解] 軟體工程師離職後

去年還在健康科技公司上班時看到這張圖解軟體工程師離職後,還覺得是個開玩笑的狀況,沒想到終於被我遇到啦⋯⋯

曾經有聽說過,某新創公司的產品是由超強老闆寫出來,上線營運後發現市場接受度相當高,有意擴張規模而雇用幾個工程師來承接他之前寫的產品,這是我朋友吉米的前公司做博弈軟體的故事。

產品創始人把心中的想法迅速時做出來,透過雛形來測試市場接受度有多高,開發軟體過程想必不會寫得很有彈性,因為「彈性」是需要大規模超仔細地想各種可能發生的情況。比如若我當初只想要搞定80%的狀況,大概一個月就能做出來;若我要再觸及剩下的20%,可能要再多花兩個月才能完工。於是乎我會選擇前者!

當驗證市場可行後,接下來就來補剩下的20%。然而儘管只是20%,想要在既有的架構上可就不太容易擴展,而老闆僱用來的工程師肯定不可能全盤了解當初寫的架構與流程,因為裡頭包含各種Features、Bugs、User Cases、Work Flows、Workarounds等。加上老闆所展現的Coding StyleLogic,與雇用來的工程師所使用的並不一致,導致剩下的20%由老闆來寫只要兩個月,而若讓雇用來的工程師來寫的話就高達半年⋯⋯

回想我還在健康科技公司時,是如此呼風喚雨,iOS App由我一個人獨自從無打造出來,後進來的Android工程師都要仿照我的方式來實現,畢竟小而美的創業公司資源不多,要盡可能使用最少資源來達成目標。對比現在港商的工作狀況,產品已經由資深同事開發10個月,架構是由他建立起來的「樂高系統」,MVC架構非常分明,就好比我當初使用MVP架構HiLife App,然而相對的所花費的時間變多。

過去一個大功能我能在一天內完工,現在一個小功能我可能一天內還無法安心動手,落差非常大啊⋯⋯有時候真的想要不管既有架構,把可運行的Code塞進去,馬上就可以有正確的效果,只是長久來看,只會不斷增加「技術債」,這我在圖解理想與實際的軟體架構有提過。

想起我偉大的前同事德叔說:

要Refactor他人寫的Code需要很大的氣度。

我在下方回答笑說:

我寧願寫Code給別人Refactor,也不要別人寫Code給我Refactor!

對我來說,加入新創公司就是想快速成長,要像個成長駭客一樣跟著產品進化,來盡可能獲得較多的成就感!最終實現自我~

於是乎,之後若要我選擇的話,我肯定會選擇從「無」開始打造產品,因為我可以根據當時的規格(畫面、功能、流程等)來決定架構,可以很快就把既定的藍圖實現出來。

我心中有好多Idea要實現啊⋯⋯

標籤雲

%d 位部落客按了讚: