0%

終於成為正式的前端工程師?

image alt

到職前與入職後

從事平面設計近十年,轉換成前端工程師是一個不容易的事情,過去美學教育的思維是比較多重思考且主觀的,跟程式思維完全大不同。從感性到理性需要做許多的調整,在過去一年的學習與努力下,其實我也不知道自己跟業界的落差到底有多少,面試後也只是大概知道可能在業界需要哪方面的人才,但還是不確定是否能夠踏進來程式領域,看到網路上許多文章都說,除了會議之外,如果不需要討論或是開會,基本上純開發與維護真的可以遠端工作,只要一台電腦基本上很多程式上的事情都可以解決,但前提是要累積足夠的開發經驗與技術能力,才能往這個方向前進。

原本天真的以為可以至少有一天可以遠端工作,真是太好笑了。

另外前端一開始其實有預想一些狀況,比如說:可以做比較多的互動界面。但後來更廣泛的理解前端介面,其實只要是人為使用的都可以說是前端介面的範疇,而目前任職的領域是負責專案後台的開發,所以互動的內容是不高的,但所需要的技術含量是不少的,後台有些看似理所當然的功能,都需要使用很多 JavaScript 來實現。

到職前後一定會跟預期有落差,這個落差可能來自於專案內容,公司文化,還有使用的工具,但我自己是用開闊的心態來看待前端,因為對我來說都是可以學習的。

預想與現實的落差

可能在準備作品集的過程已經學習很多,加上線上老師教學很多闡述能力是很好的,進入職場才會發現有些人講中文,可能聽起來卻不知道在講什麼內容,不要預想每個工程師都會像老師有很好的闡述能力,另外專案的內容也會跟預想的的不同,現實的專案畢竟就是要符合客戶與公司內部使用,所以有趣程度一定大不相同,後台所需要的介面就是要清楚明瞭,乾淨簡單,要馬上得到資訊,互動性一定是較低的,而後台卻也是許多產業所需要的前端介面。

還有部門文化不一定都會熱絡討論,可能都在同個空間工作,但會說上話的卻只有一兩天這種現象。

面對專案的技術力

任職三個月以來,技術力的提升是快速的,因為要因應專案需求,會大量的 google 找資源,建立資源,努力寫需求的練習,技術力一次會學習很多,但卻比較沒有章法,我利用部落格寫成筆記,把重複會遇到的放在部落格,之後再從部落格找資料就好。有時候在專案上會卡關很久,也相對反映出自己的技術力還有許多要加強的地方,不足是一定的,要寬心面對這件事情,今天要比昨天的自己更強就是了。

感恩的心態

老實說,感恩的心再踏入前端領域後,就一直是這樣,網頁很老實,給什麼就回饋什麼,非常現實,也無法讓自己一步登天,只能誠實面對自己的不足,並且提出問題有人回答都要感恩,因為都是非義務,也非必要的回答,但能在問題提出,有經驗的工程師願意做出回答並指點迷津,都要向他們感恩。

並且一路上家人的陪伴與支持,更是要感恩,因為最辛苦的不是自己而已,而是他們陪伴的心與實質付出的行動。

不恥下問

在程式沒有蠢問題,因為程式語言也是一門語言,而語言是需要使用與養成的,唯有不斷的提問跟反覆練習,才能慢慢的熟練,許多答案是問出來的,不一定是想出來的。與經驗較豐富的工程師提問,而提問不一定是要拿到答案,而是跟著他們的思維走一遍,並且自己再多練習幾次,答案便會呼之欲出。

整理在專案上的學習

分類資料夾很重要,把資源有系統的整理,不僅在找線索快速,也讓自己整理過去學習的思緒,把遇到不熟悉或是新的知識轉換成為文字與部落格,最大的受益者一定是自己。慢慢的會發現,許多情境都很像,只是主題不同,專案很多都是換湯不換藥。

工作時間的調配

學習可以納入工作時間的一部分,我會利用早上兩個小時先做學習,因為精神較好,專注力較集中,效果也較好,而下午較長的時間,拿來解決專案問題,並善用 codepen 或是其他程式網站,把不懂的 code 先記錄下來,再反覆的研究,使用 todolist 規劃自己每天的進度,並搭配番茄鐘是很好的成效,透過番茄鐘可以知道自己在專案上花了多少時間,讓自己適當工作也適當休息。

目前平均在工作上大概都花費 12~14 顆番茄鐘,並設定短休息 5 分鐘與長休息 10 分鐘,希望可以在提升效率能夠控制在 10 顆番茄鐘內。

工作前的第一件事

整理思緒

不要馬上工作,我會在座位上先禱告沉澱心情,讓自己安靜心,進入工作模式與思維,不要馬上開網頁跟專案,思維模式開始運作後,會比較進入狀況。

不要打開 email

通常急事一定會打內線連絡,email 我都是接近中午才開,還有下午三點左右再開一次,看看是否有重要行政通知。

與同事的溝通

人際互動在職場是很重要的環節,關係打好了,工作上也會比較舒服,不會因為爭執影響情緒,導致工作效益降低,並且思考如何以團隊勝利主義出發,團隊變強,自己也是相對變強。

前端與後端

前後端完整分離的公司可遇不可求,大多中小企業人力不足,幾乎前後端都要有了解,只是了解層面多寡,建議都吸收,都了解。有利無弊!

撰寫程式碼的思維

對於有些工程師來說,寫 JavaScript 才是寫程式(笑),這是個人觀點問題,個人就不評論,但主管告訴我,寫 JS 可以用兩個方向做思考,動作與程序,先有動作,再把程序連接起來,最後再來優化,這樣比較不會卡關,並且把問題切到最碎片化,就會發現其實每一個小問題都會回到最基本的程式架構。

放棄吧!不要鑽牛角尖

對於有些程式碼的來源不一定當下馬上要弄懂,因為工作是解決問題,並非做學問,做中學是最快的方式,可能當下不懂,但寫多了,假以時日再回來看程式碼,會突然發現懂了,所以卡關超過 30 分鐘,先放下吧!繼續往下走。

不只找貴人,也要成為別人的貴人

對我來說,output 比 input 的學習成效更高,在尋求幫助之時,也把得到的答案與做法寫下來,並分享在部落格,或許這個方法也間接幫助到遇到相同問題的人,甚至還會招喚大神出來修正觀念,怎麼說都是賺到。

正確的問題才會得到正確的答案

從設計師轉換成工程師最棒一個禮物就是學習如何提出正確的問題,很多時候會不知道怎麼提問,但透過提問不只是把問題重新整理,在整理的過程中,還有可能會找到答案,減少不必要的問題。

無法改變環境,那就先適應環境

沒有相關資訊背景,轉換職涯跑道會遇到一個狀態就是技術力掌握度不如同部門的人,而我目前任職的公司每一個人在專案上都有一定的經驗程度,先排除程式碼寫得好不好,再怎麼樣程式邏輯都比我這個跨行的來得強,雖然在技術上有些沒有使用,也很想導入新技術,但因現在無法改變環境,就先透過試用期觀察以下幾點:

  1. 部門文化:我個人覺得這很重要,觀察就有同仁之間的互動與風氣,講話方式與音量,就可以知道這個公司的專案樂趣度到哪裡。(好吧!可能我的公司滿無聊的 XD)
  2. 會議氛圍:在會議上也可以觀察出與會者與報告者,以及上位者的互動,來看一下這間公司的眼界到哪裡,部門主管與高層主管之間的想法是否一致,跨部門會議的共識是否相同,都是很值得觀察的地方。
  3. 行政運作:像我是待在中型企業,有些行政聯繫方式也可以看得出公司運作的狀況,使用的工具或是聯繫的管道,是較傳統還是新穎,至於是否先進,就見仁見智了,對於行政來說,可以順利運作就好。
  4. 閒聊話題:除了工作與專案外,同事們都在聊什麼? 我們部門是很少講話,真的滿悶的,不過隔壁部門到是滿常講幹話就是了。

如果一行程式碼無法解決,那就寫兩行

身為剛入職的前端工程師,除了把握學習的機會外,也要規劃怎麼讓自己在專案中成長,若有機會多看前人的程式碼有個好處,去了解原本程式碼脈絡跟思維,但也不要太苛求自己要馬上寫出行雲流水般的程式碼,因為那是不可能的,但可以具備一個思維是把程式碼改成可讀性更高或著更值觀的程式碼是件很棒的事情,當哪天或其他工程師接手時,不用再看邏輯,而是看程式碼。但還是要追求簡短又可讀性高的程式碼,這個就要靠專案慢慢來成長了。

先求可以讓專案動起來,哪天有空再回頭重構程式碼,也是檢視自己能力的好機會。

保護眼睛

因為要長時間看螢幕,我入職後就去配了一副抗藍光眼鏡,真的長時間看電腦比較不疲勞喔!!
如果配合番茄鐘休息,起來伸展跟走走,會更好,讓眼睛適當休息,也讓身體休息。

結語

前端工程師是一條不順遂的道路,要習慣跟挫折相處,因為光是一個 bug 就可以卡個幾個小時甚至幾天,但破解後真的會有滿滿的成就感,加上載具的蓬勃發展,許多技術如雨後春筍般出現,可能會無所適從,不過也不需要太緊張,掌握好基本觀念,其他都是這些基本觀念延伸出來的工具,並且多跟厲害的人交流,日積月累一定會成長的。