เมื่อสามปีก่อนผมมีโอกาศหยิบหนังสือเล่มนึงมาอ่านตอนช่วงเริ่มๆทำใหม่ๆ และคิดว่าเป็นหนังสือที่มีประโยชน์สำหรับคนที่พึ่งเริ่มเข้ามาสายนี้ เนื้อหาจะเป็นการปรับ mindset และเตรียมพร้อมเข้าสู่สนามจริง ในเล่มไม่มี code เล้ยย 55 มีแต่คำแนะนำ (how to)
คิดว่าคนที่ประสบการณ์สัก 0-1 ปี จะได้ประโยชน์เยอะสุดเลย เหมือนมี senior มาให้คำแนะนำดีๆ ส่วนคนที่มีประสบการณ์มาแล้วก็อ่านได้คับเพลินๆ วันนี้เลยเอา 40 อย่างที่ผมอ่านละชอบมาแชร์ให้เพื่อนๆด้วย เย้
คนเขียนคือคุณ Fernando Doglio ผู้มีประสบการณ์กว่า 20 ปีในวงการนี้
1.
True requirements
“I know that’s probably not what you want to hear, but these skills are the cornerstone of growing as a developer.
Any technical skill can be learned over time by reading a manual or watching a video. But the skills discussed in this section will be there, helping you through that learning process.”
You’ll become a developer by learning how to code, but if you skip these five skill, it’ll be like learning to run before knowing how to walk.”
Fernando บอกว่าพื้นฐาน หรือ เทคนิคการเขียนโค้ด ทุกคนสามารถเรียนรู้ได้ แต่ 5 อย่างนี้คือสิ่งที่อาชีพ developer จำเป็นต้องมี (Must Have)
- Patience (ความอดทน)
- Determination (ความมุ่งมั่น เพียรพยายาม)
- An eternal student mindset (เปิดใจเรียนรู้ไม่มีสิ้นสุด)
- Accepting criticism and learning from it (ยอมรับและเรียนรู้จากคำวิจารณ์ของคนอื่น)
- Knowing how to communicate (สื่อสารเก่ง)
ใครที่มี 5 อย่างนี้อยู่แล้วคือคนที่จะเป็น developer ได้สบายๆเลย ผมเห็นด้วยทุกประการ 🥹
2.
Don’t follow blindly
“You will never improve by repeating a task if you just keep mindlessly doing it over and over again. You need to understand what to aim for. Be clear about the standards you have to achieve and the best practice to follow.”
ทุกงานที่เราทำถ้าเราไม่รู้ว่าเราทำอะไร ทำแบบนี้ไปทำไม เราจะไม่พัฒนาเลย เราเลยควรที่จะรู้จัก best practice, standard ของภาษา หรือ pattern การเขียนโค้ดเพื่อรู้ว่าเรากำลังพัฒนามาถูกทางรึเปล่า (หลงทาง)
ตอบตัวเองให้ได้ว่า เรากำลังฝึกเขียนเพื่อพัฒนาตัวเองด้านไหน มี standard อะไรเป็นเป้าหมายของเรา 💯
3.
Your code needs to work
“When you’re writing code, the first version you write only need to have a single purpose: to do whatever job you need it to do. The initial goal is not to solve the problem quickly, or to solve it using the least amount of resources, or to fit any other constaints you might come up with. Your code just needs to work.”
Fernando แนะนำว่า code เวอร์ชั่นแรกเขียนให้มันใช้ได้ก่อนสำคัญที่สุด เอาให้ง่ายที่สุด ไม่ต้องไปคิดท่ายากเยอะ แล้วค่อยมา refactor ให้มันสวยหรือ performance ใส่ pattern ให้ดีทีหลัง
อย่าไปคิดทำเผื่อใช้ต่อในอนาคต เขาบอกไม่มีอยู่จริง ลุงถามว่าคุณรู้หรอว่าอนาคต business จะอยากได้แบบไหน ตัวเค้าเองยังไม่รู้เลย ผ่าม 55+
4.
Good is better than perfect
“Thinking we can create a perfect piece of code, especially on our first try, is not only foolish but misguided.
Code can be clay – it can take time to get it right.”
อย่าคาดหวังว่า code ที่เราเขียนหรือปัญหาที่เราแก้ครั้งแรกจะ perfect เลย มันเป็นไปไม่ได้ ลุง fernando บอกถ้าคิดแบบนั้นให้เลี้ยวกลับทันทีไปผิดทางแล้ว 😂
แต่เขาบอกถ้า code เราเป็น code ที่ต้องส่งให้อีกทีมใช้ (third party lib) หรือขึ้น production ให้ลูกค้าใช้จริงก็ควรจะต้องทำให้ดีให้สวย
แต่ถ้ามันเป็นแค่ feature นึงที่เราต้องทำส่งช่วง development ก็ไม่จำเป็น (เพราะ มันต้องมีช่วงกลับมา refactor code อยู่แล้ว)
Good beat Perfect always.
5.
Optimization trap
“Don’t fall for the early optimization trap”
ลุงบอกว่าการจะ optimize ให้โค้ดเราเร็วขึ้น ในเรื่อง performance มันต้องมีเลขวัดที่ชัดเจน ก่อนหน้านี้ใช้เวลาเท่าไหร่ ก่อนและหลัง ลุงบอกจะพูดเรื่องนี้ลอยๆตอนเรายังไม่มีข้อมูลมาคุยกันมันไม่ make sense เลย 55
เขาบอกให้เราทำ first version มาเสร็จแล้วรันดูผลลัพท์ จากนั้นค่อยเริ่ม optimize
Make it work then optimized 👍
6.
Code standard
“You should have a set of standards that cover style issues, you don’t have to agree with them, you just have to use them, especially if you’re joining the team after it’s been working together for a while.”
เขาบอกว่าเรื่อง code standard เป็นเรื่องของความเห็นซึ่งไม่มีใครเห็นตรงกันทั้งหมด แต่ใน project ควรจะต้องมีเพราะเราไม่ต้องมานั่งคิดว่าจะเว้นกี่บรรทัด จะใช้คำขึ้นต้นว่าอะไรดี ไม่เป็นไรแค่มีกฏสำหรับเราและทุกคนให้ทำเหมือนกันก็พอ เพราะ
- ช่วยให้ทั้งทีมอ่านง่าย
- มีประโยชน์ต่อคนรุ่นหลังที่เข้ามาทำในโปรเจค
ถ้าอยากอ่านเรื่องนี้ต่อผมมีเขียนไว้ใน ทำไม Code Convention ถึงสำคัญกับทีม
7.
Unacceptable code
“Sometimes a single line of code can require several paragraphs of documentation because it’s so optimized and minified that mentally parsing it taks too long. That is plain unacceptable in most situations.”
❌ ตัวอย่างที่ไม่ดี
let formattedEvens = (1...100).filter { $0.isMultiple(of: 2) }.map { "Number: \($0)" }.joined(separator: ", ")✅ ตัวอย่างที่ดี
let numbers = 1...100
let evenNumbers = numbers.filter { number in
return number.isMultiple(of: 2)
}
let formattedNumbers = evenNumbers.map { number in
return "Number: \(number)"
}
let result = formattedNumbers.joined(separator: ", ")ในภาษา programming เราสามารถทำทุกอย่างให้จบได้ในบรรทัดเดียว แต่มันไม่ควรทำ 55+
ในหนังสือ clean code เขาเรียกโค้ด แบบนี้ว่า รถไฟชนกัน 55+
เขียนโค้ดให้เข้าใจอ่านง่ายๆ ใช้หลายๆบรรทัด ดีกว่าเขียนแบบ 1 บรรทัดทำได้ทุกอย่าง
8.
Overengineering
“You can’t fall in love with your work that’s the first step into overengineering. Save that for your own time and your personal projects, when there is no deadline looming around the corner.”
Overengineering คือการแก้ปัญหาที่ง่ายด้วยวิธีที่ยาก
ด่านแรกของการ จะ overengineering เริ่มจากการที่เราหลงรัก code ตัวเอง
ถึงจุดนั้นเราจะใช้วิธีที่ดีที่สุด code pattern หรือ architecture ที่ถูกต้องเป๊ะตามหลักการ 100% ไม่ใช่ว่ามันไม่ดีแต่มันเสียเวลา เก็บแรงกับเวลาไปเข้า fitness เหอะ ลุงไม่ได้บอก 55
9.
Random bugs
“Truth is, there are no random bugs, there are only bug.”
ไม่มีบัคไหนเกิดขึ้นมาสุ่มๆ ทุกอย่างมีต้นเหตุ และเราในฐานะ developer ต้องหาให้เจอและแก้ให้ได้ ลุงบอกวิชาหาบัคแก้บัคใช้เวลาเป็นปีๆกว่าจะเก่ง
แต่ลุงคงไม่รู้ว่าอีกไม่กี่ปีที่ลุงเขียนหนังสือเล่มนี้ จะมี AI มาช่วยแล้วว 😏
10.
Just a developer
“You’re a developer, after all, not a React developer or a Java developer. You have to aim to be “just” a developer.”
ลุงใช้เวลาสักพักกว่าจะตกผลึกว่าภาษา มันเป็นแค่เครื่องมือในการแก้ปัญหาเท่านั้น อย่ายึดติดกับมัน
It’s about being a great develoepr, with no tags attached.
11.
Specific technology
“I encourage you to always be on the lookout for best practice specific to the technology you’re using, since there are exceptions and particular practices that don’t translate to other languages.”
แต่ไม่ใช่ทิ้ง tech ของภาษาไปเลย เพราะในแต่ละภาษามันจะมี best practice หรือคำสั่งเฉพาะตัวของมันอยู่ เราก็จำเป็นต้องรู้และ update ตัวเองเรื่อยๆเหมือนกัน
12.
Gut feeling
“There is no formular for understanding when to stop adding patterns and classes; you’ll get a feel for that over time.”
ในการทำงานบางที มันไม่มีสูตรตายตัวสำหรับทุกปัญหา บางทีเราต้องใช้ feeling ในการตัดสินใจ ว่าอะไรมากเกินหรือน้อยเกินไป หา balance ให้เจอ
13.
Funny terms
“KISS, DRY, YAGNI”
3 คำที่ dev ควรรู้เอาไว้
- Keep it simple stupid (เขียนโค้ดให้โคตรง่าย)
- Don’t repeat yourself (อย่าเขียนอะไรซ้ำๆ ใช้ function, class แทน)
- You aren’t gonna need it (อย่าเขียนเผื่อว่าจะเอาไว้ใช้ในอนาคต)
14.
Writing tests
“There are two times when you have to remember to write unit tests for your code: during development of a feature and when you change the code of a feature.”
มีแค่ 2 ตอนที่ควรเขียน test คือ
- During development (ตอนทำ feature ใหม่)
- When you change the code of a feature (ตอนแก้โค้ดเก่า)
พูดง่ายๆคือ ควรเขียนเทสทุกตอน 55+
15.
Refactoring
A clear goal is key to successful refactoring.
That goal can be anything from fixing a bug to improving the performance of your code. The point is to have an objective, and that objective will guide your refactoring plan.
Refactor โดยไม่มีจุดหมายทำให้เราลอยไปเรื่อยๆ ไม่รู้จะทำอะไร ยังไง
ลุงบอกว่าก่อน refactor
- ให้ดูว่าจะกระทบอะไร code เก่าจุดไหนบ้าง
- จำเป็นต้องมีแพลนก่อนเสมอว่าเราจะ เปลี่ยนอะไร หรือทำอะไรกับ code เก่ายังไง
ต้องรู้ให้ชัดว่าเราจะ refactor ไปเพื่ออะไร (clear goal) จะเป็นอะไรก็ได้เช่น
- แก้บัค
- เพิ่ม performance
16.
Working with testers
Being a good developer is not about writing code that doesn’t need to be tested,
but rather about (among other things) knowing how to work with testers and taking advantage of their expertise.
QA หรือ tester จะเป็นเพื่อนซี้เราตอนหาบัค(trust me bro) เรียนรู้ที่จะช่วยกันทำงานกับ testers จะช่วยเราให้เราทำงานง่ายขึ้นเยอะ
17.
Our opinion on others’ code
Don’t force your own opinion about how others should be coding. Stick to the standards everyone is meant to be following (including you).
อย่าเอาความคิดเห็นตัวเองเป็นหลักว่าคนอื่นควร code ยังไงรวมถึงเราด้วย ทำตามกฏที่มี
18.
Imposter syndrome
“I would bet that 99% of all developers go through this at the start of their career (and some still feel this way years later).
It’s called impostor syndrome, and we all have to deal with it at some point.”
อาการ imposter syndrome คือเสียงในหัวที่คอยบอกเราว่าเราไม่เก่งจริง, เราไม่ดีพอ, เราไม่ฉลาดพอจะเป็น dev, เราไม่เก่งเท่าคนอื่น น่าเศร้าที่คนในอาชีพนี้เป็นกันเยอะ
ลุงบอกว่าจริงๆแล้วมันไม่มีอะไรหรอก มันเป็นแค่เสียงในหัวเราเอง ถ้าเรามีอาการพวกนี้ยินดีด้วย ถือว่าผ่านการเป็น developer แล้ว 55+
ข่าวดีคือมันมีวิธีทำให้เสียงในหัวเราเงียบไปเยอะมากๆ คือ การเรียนรู้พัฒนาตัวเอง !!!
- Self-learning (เรียนรู้ ด้วยตัวเอง)
- Formal education (เข้าเรียนในมหาลัย)
มันอาจจะไม่ได้หายไปสะทีเดียว แต่หลักๆเลยคือ ยิ่งเราเรียนรู้เยอะเท่าไหร่ ยิ่งเก่งขึ้น เสียงในหัวจะยิ่งเบาลง เรื่องนี้เป็นเรื่องจริงในอาชีพเราเกิดขึ้นได้กับทุกคน
คนที่ทำงานบริษัทดังๆพวก facebook, netflix ก็ยังเป็นกัน ผมเข้าใจเลยเพราะเป็นคนนึงที่เสียงในหัวเคยบอกว่าเก่งไม่พอจะทำอาชีพนี้ ละปัจจุบันมันก็หายไปหมดแล้ว ใช่ครับ อาชีพหายไปแล้ว 😂 หยอกนะทำอยู่ 55 .. ผมจะบอกว่า imposter syndrome มันกลัว ความรู้ กับ Mindset มองโลกในแง่ดี ที่สุดแล้ว
สู้ๆครับ หาความรู้และเงียบเสียงพวกนั้นด้วยตัวเราเอง 👊
19.
Learning how to learn
“The learning process, which can take any shape or form and is uniqe for every developer, has one main objective: to give you autonomy.”
แต่ละคนมีวิธีเรียนรู้ไม่เหมือนกันบางคนอาจจะถามเพื่อนร่วมทีม, google หรือดูวิดิโอสอนออนไลน์ แต่สิ่งสำคัญคือทุกครั้งที่เราเรียนอะไรก็ตาม ให้โฟกัสกับการเพิ่ม autonomy
Autonomy คือการเข้าใจและแก้ปัญหาด้วยตัวเราเอง ซึ่งเราจะมีได้เราต้องเรียนรู้ที่จะเรียน “Learning how to learn” อย่าเรียนรู้จากคนอื่นเพื่อที่จะเอาแค่คำตอบ หรือ copy paste คำตอบจาก AI, Stack overflow อย่างเดียว
20.
Senior developers’ secret
Eventually you’ll learn a key secret that all senior developers know: There is no problem you can’t solve.
พอเราเรียนรู้ที่จะ เพิ่ม autonomy ได้มากพอ สุดท้ายเราจะเข้าใจความลับที่ senior developer ทุกคนรู้คือ ควรจ่าย sub ซื้อ AI premium ของทุกค่าย ยังง !!
“ไม่มีปัญหาไหนที่เราแก้ไม่ได้ 💪” ในหนังสือทั้งเล่มผมชอบประโยคนี้สุดละ ❤️
21.
Side project
Side projects aren’t meant to be original, innovative, or groundbreaking. You’re not looking to disrupt the software development industry; you’re looking to learn a new skill.
Fernando บอกว่ายิ่งถ้าเราไม่มีประสบการณ์ การทำ side project สำคัญมากเพราะมันช่วยให้เราเก่งขึ้น แต่หลายคนไม่รู้จะทำอะไรดี
Side project สามารถเป็นอะไรก็ได้ไม่ต้องยากหรือล้ำๆเลย ทำสิ่งที่สนุกๆ อาจจะ app เครื่องคิดเลข ง่ายๆก็ได้ หรือลองหา idea จากที่คนอื่นทำไว้แล้วก็ไม่ผิด key คือเอาไว้เรียนรู้จากมัน
22.
Burnout is real
Burnout is real. When burnout hits, anything else is more important than coding.
หาเวลาว่างทำอย่างอื่นนอกจาก coding ด้วย เพราะ burnout มันมีจริงยิ่งกว่าจริง 🤣 เพราะถ้า burnout แล้วมันกลับมายาก ถ้าถึงเวลานั้นทุกอย่างจะสำคัญกว่าการโค้ดไปแล้ว
23.
Mistakes
Mistakes are not a bad thing. In fact, they’re a teaching mechanism, and if we learn how to take advantage of them, we’ll be constantly improve, even when we break things.
ความผิดพลาดไม่ใช่เรื่องแย่เสมอไป
ไม่เป็นไรถ้าเราจะทำอะไรผิดพลาด แต่เราต้องเรียนรู้จากมันด้วย ความผิดพลาดคือครูที่ดีที่สุด 🙏 (แต่ลุงบอก be smart about them ด้วยนะคือผิดละเรียนรู้ อย่าผิดซ้ำ)
24.
Communication skills
Having great communication skills makes for great developers.
Dev ส่วนใหญ่ละเลยสกิลการสื่อสาร เลยทำให้ถูกมองว่า dev มักพูดไม่รู้เรื่อง แต่จริงๆแล้ว fernando บอกว่า skill การสื่อสารสำคัญพอๆกับสกิลเขียน code เลย .. ข้อนี้จริงที่สุด ✅✅
“dev ที่เก่งกาจคือ dev ที่สื่อสารเก่ง”
25.
Company red flags
“The promise of working for a great company should not be the only important factor when deciding to take a job. Passing on an offer that smells funny and then receiving the right one can be worth your while.”
Fernando บอกว่าให้คิดเยอะๆไว้ตอนจะหาบริษัท มีบางอย่างที่ควรสังเกตให้ดีเลยตอนสัมภาษณ์ เช่น
- Being a family
- Managers who remove themselves from failures
- Overtime
เขาบอกว่าการที่บอกว่าเป็นเหมือนครอบครัว ซึ่งสมัยนี้น่าจะเลี่ยงๆคำนี้กันแล้ว อาจจะต้องลองใช้ sense หาเอาเอง
ลองมองแบบนี้เพราะเราเสียสละให้ครอบครัวได้ยอมทุ่มเทให้ครอบครัวแบบไม่หวังอะไร แต่กลับกันโดยส่วนใหญ่เวลาที่เราต้องการความช่วยเหลือจากบริษัท เช่นลาป่วย หรือ ลากิจ ก็ยังต้องยื่นใบลา หรือแม้กระทั่งใบรับรองแพทย์ หรืออื่นๆ ไม่ใช่ว่าบริษัทโหดร้ายนะแต่ เราไม่ควรใช้ mindset ว่าบริษัทเป็นครอบครัว เท่านั้นเอง
เขาบอกให้มองหา leader ที่แชร์ความสำเร็จกับทีม แต่ถ้ากลับกัน คนที่โทษทีมตอนผิดพลาดคงไม่ต้องพูดเยอะ หนีให้ไวที่สุดเท่าที่จะเป็นไปได้ 😂
“A continuous overtime policy will only lead to the burnout of the team.”
Dev ที่ยังไม่มีประสบการณ์จะโดนกดดันให้คิดว่า การเป็น dev คือการทำงานให้หนัก ทำงานให้เสร็จไม่ว่าจะเกิดอะไรขึ้นก็ตาม (แบบไม่มี OT ด้วย 🥹🥹) Fernando บอกว่าเขาอยู่วงการนี้มา 20 ปีไม่เห็นด้วยกับการ overtime เลย
ไม่ผิดเลยถ้าเราจะเลิกงานตรงเวลา “Your personal time should be your priority” ข้อสามนี่เขาแนะนำว่าให้ถามไว้เลยเนิ่นๆตั้งแต่ตอนสัมภาษณ์
My opinion: เรื่องนี้ละเอียดอ่อน ขึ้นอยู่กับแนวคิดและความสมัครใจของแต่ละคนเลย แต่ถ้าถามผมคิดว่า เต็มที่เวลางานละถ้ามีอะไรเร่งด่วนสำคัญเราก็ควรให้บริษัทเต็มที่เสมอ – ถ้าบริษัทเห็นใจเราเขาก็จะไม่ให้เรา Overtime หนักๆตลอดเช่นกัน
26.
Good mentor
“Good mentors can be found in other places with less “bright” people as well.”
อย่าเลือกบริษัทเพราะที่นั่นมีคน “เก่งๆ” เยอะ fernando บอกว่าไม่ใช่คนเก่งทุกคนจะเป็น mentor ที่ดีอยากจะสอนเรา กลับกันในที่ๆมีคนเก่ง “กลางๆ” อาจจะมี mentor ที่ดีอยู่ก็ได้
ส่วนตัวคิดว่าจริง สกิลการเป็น mentor ต้องมี skill set หลายอย่างมากกว่า coding skill และที่สำคัญคือ มีใจที่อยากจะสอนและเห็นเราได้ดีจริงๆ ถ้าเจอคือโชคดีมากนะ
27.
Strong body
“Working as a developer is a very sedentary profession, and we tend to spend most of our days sitting in the same exact position. But we’re humans and we need physical activity.”
เราไม่ใช่หนึ่งเดียวกับเครื่องจักร
อาชีพเรานั่งจ้องคอมทุกวัน ตรงกันข้ามกับสิ่งที่มนุษย์เคยทำมาตลอดหลายหมื่นปี 🐒
จำเป็นมากๆๆที่เราต้องออกกำลังกาย เพราะนั่งเฉยๆทำให้ร่างกายเราอ่อนแอ นานๆไปไม่ดีแน่
การออกกำลังกายทำให้เลือดสูบฉีดขึ้นสมอง ทำให้เราคิดอะไรออกง่ายขึ้นด้วย 💡
Strong body, strong mind !!
28.
Estimation
“Estimation will always be wrong. I’ll let you in on a little industry secret: estimate is not about getting the number right, it’s rather about who gets the closest number.”
ทุกครั้งก่อนจะเริ่มทำงานเราต้องประเมิน (estimate) ว่าจะใช้เวลากี่วัน ซึ่งสกิลการ estimate เป็นสกิลที่คนที่พึ่งทำงานใหม่ๆจะยังไม่มี
Fernando บอกอย่าไปจริงจังกับการ estimate ขนาดนั้น (แต่ keep look ดูจริงจังไว้ เพราะฝั่ง business เขาต้องจริงจังเรื่องนี้ 55) เพราะ “มันเป็นไปไม่ได้” ที่จะบอกตัวเลขที่มันตรง เราทำนายอนาคตไม่ได้ เอาให้ใกล้เคียงที่เราคิดที่สุด
Trick ของการ estimate ก็คือแบ่งงานให้ย่อยๆที่สุดจนมันประเมินง่าย
29.
Appreciation
“Learn to appreciate the work of others, even if they don’t write code for a living. If they’re part of your team, that means they have a role to play, and it’s just as important and as relevant as yours.”
ใครที่อยู่ในทีมสำคัญทุกคน แม้เขาจะไม่ใช่ developer ก็ตาม เรียนรู้ที่จะชื่นชมงานของคนที่เขาไม่ได้ coding ด้วย!
30.
Ego is the enemy
“You can have developers who have worked for 10 years but are still inexperienced enough to run around with their egos unchecked. It’s a phase we all go through, but it’s also important that we learn enough to outfrow it.”
เรื่อง ego เป็นเรื่องที่มีทุกคน
1 ใน task ของทุกวันคือเราต้องกำจัด ego ของเราออกไป Fernando บอกคนที่ประสบการณ์เป็นสิบปีแต่ไม่เคยฝึกควบคุม ego มีอยู่ให้เห็นไม่น้อยเลย
Beamtan (Me): ผมคิดว่าถ้าเราต้องเจอ อยู่เฉยๆแต่ให้เรามองไว้เป็นแบบอย่างว่า “เราต้องเป็นคนที่ดีกว่านั้น” แบบนี้ดีกว่า เย้
Fernando: The ideal developer’s mindset, if you ask me, is that of an eternal student, always learning and always humble enough to recognize they can’t know it all, ever. ❤️
Fernando – dev ที่ mindset ดีจะเรียนรู้อยู่และถ่อมตัวอยู่ตลอด เพราะเขารู้ว่าตัวเองไม่สามารถรู้ได้ทุกอย่าง
อันนี้เรื่องจริงเพราะผมเองก็ต้องให้ น้องๆพี่ๆ ประสบการณ์น้อยกว่าหรือมากกว่าสอน ทุกคนมีสิ่งที่เราไม่รู้และสอนเราได้ทั้งนั้น
31.
Dangerous route
“As developers, sometimes we fall under the illusion that because we can code, we can code everything, and there is no need to depend on anyone else, not even on third-party libraies.
That’s a dangerous route to travel.”
ไปคนเดียวไปได้ไว ไปด้วยกันไปได้ไกล
บางทีเราจะคิดว่าเราสามารถทำทุกอย่างจบได้ที่เราเองไม่ต้องพึ่งใคร โค้ดคนอื่นก็ไม่ยอมใช้ อาจจะด้วยความเก่งหรือ ego เราเอง แต่ fernando บอกว่าอย่าเลยน้องมันเป็นเส้นทางที่อันตราย เราทำงานร่วมกับทีมให้ทีมช่วยและเราช่วยทีม ดีที่สุดแล้ว
32.
Ultimate form of ego
“The ultimate form of ego we’re always fighting against is the idea that not only are we better than others, but that it’s our job to correct them. I’ve had to deal with developers like that, both as a teammates and as a manager myself.
They are very hard to work with because you either work the way they want to or they won’t let you work. They might even go so far as to raise issues around the quality of your work until you comply with their ideals.”
ในอดีตลุงบอกว่า ego ขั้นสุดยอดที่ลุงเคยเจอมาคือ คนที่มีความคิดที่ว่าเราเหนือกว่าคนอื่น และ จับผิดคนอื่นไปด้วย .. แค่ได้ยินก็ร้องไห้แล้วคร้าบบ 😂
ลุงบอกว่าคนแบบนั้นทำงานด้วยยากมาก เพราะเขาจะบังคับให้เราทำตามวิธีของเค้า (micro-management) หรือไม่ก็ไม่ให้เราทำงานเลย หรือแม้แต่จับผิดงานเราด้วยเรื่องเล็กน้อย
เรื่องนี้เราทำอะไรไม่ได้ แต่เราเรียนรู้ได้ว่า อย่าทำแบบนี้กับใคร ลุงบอกว่า dev ทุกคนจะเรียนรู้จากการแก้ปัญหาด้วยตัวเอง ดังนั้น เวลาเราต้องช่วยใคร หรือเห็นใครติดปัญหา
- ใช้ความเคารพช่วยคนอื่นแก้ปัญหา และ อย่าคิดว่าเพราะมันง่ายสำหรับเรา มันจะง่ายสำหรับคนอื่น (ทำไมถึงแก้ไม่ได้?)
- ให้เขาแก้ปัญหาด้วยตัวเอง, ถามเขาก่อนว่าเขาอยากให้ช่วยมั้ย
Ego จะทำให้อาชีพเราลงเหวได้เลย ให้เราควบคุมมันตั้งแต่เนิ่นๆ จะยิ่งเติบโตไปได้ไกล
33.
Respect everyone’s time
“Respect everyone’s time. This is crucial for all teams, and it shows that you acknowledge everyone else and respect them.”
สิ่งสำคัญตอนเรา work แบบ remote คือเราควรเคารพเวลาของทุกคน เพราะมันโชว์ความเคารพของเราต่อทีม เช่น การติดต่องาน นอกเวลางาน
34.
Socialization
“One of the keys to a successful working environment and a performant and tight team is socialization.”
หนึ่งในสิ่งที่ทำให้คนนึงเป็น Top performer ในบริษัทได้คือการที่ คนๆนึงรู้สึกเป็นส่วนนึงของบริษัท มีสังคมมีเพื่อนที่ทำงาน
วิธีที่ทำให้เรามีส่วนร่วม เช่น ถ้าที่ทำงานชวนไปกินข้าวก็ควรจะไปด้วย, พยายามพูดคุยใน meeting online, คุยไร้สาระกันบ้าง
35.
Code review
“The main thing to understand about code reviews is that they’re not personal. If you don’t understand this, you won’t get any of the benefit.”
Code review คือการที่มีคนมาให้ความเห็นกับ code เราว่ามันดีหรือไม่ดีตรงไหน อย่าไปคิดว่าเป็นเรื่องส่วนตัว ไม่อย่างนั้นใจเราจะไม่เปิดรับฟังและเราจะไม่ได้เรียนรู้ข้อผิดพลาดเลย
36.
Correct your leader
“Don’t be afraid to challenge your lead’s ideas, but also be open to being corrected and educated by them as a response.”
เป็นหน้าที่เราที่จะต้องบอกหัวหน้าหรือ senior ถ้าเขาบอกหรือเข้าใจอะไรผิด (บอกอย่างสุภาพ) อย่ากลัวว่าเราไม่สามารถพูดได้เพราะ จริงๆแล้ว lead หรือ senior จะมีหน้าที่ดูภาพรวมเป็นหลัก ซึ่งอาจจะตกหล่น technical บางอย่างได้ เป็นเรื่องปกติ
Fernando บอก leader ที่ดีจะรับฟังเสมอ และเราเองควรจะสื่อสารแบบสุภาพด้วยเหมือนกันเช่น ถามคำถามแทนการพูดว่าเขาผิดยังไง สิ่งสำคัญคือวิธีที่เราจะบอกกับเขายังไงมากกว่า
เขาบอกถ้าถึงจุดที่ไม่มีใครกล้าเตือนหรือแย้งกับ leader เราได้เลยคือจุดที่อันตรายมาก
37.
Traits of a good leader
“The signature characteristic of a great leader is that they also have an eye set on the future.”
วิธีดูว่าหัวหน้าเราเป็นผู้นำที่ดีมั้ย (จะเป็น manager หรือเอาไว้ดูๆ teamlead, senior ก็ได้) หรือถ้าอยู่ในตำแหน่งนั้นอยู่แล้วลองมองไว้เป็น goal ก็ได้ครับ หรือใครที่มีครบอยู่แล้วผมคงต้องขอฝากตัวด้วย 😂
Fernando บอกให้ดูว่ามี 7 อย่างนี้รึเปล่า แต่ไม่ต้องแปลกใจ คนที่มีครบ 7 อย่าง คือผู้นำที่เพอร์เฟ็ค แต่หายากชนิดต้องพลิกแผ่นดินหา ใครเจอยิ่งกว่าถูกหวย
ในทางกลับกัน ลุงบอกว่าถ้าเจอหัวหน้าที่ไม่มีในนี้เลยให้หนีให้ไว 55 👋
- Challenge the status quo
- ชอบท้าทายสิ่งเดิมๆ leader ที่ดีต้องกล้าชน กล้าคิดต่าง กล้าท้าทายความคิดที่ผิดๆ
- ขอความเห็นจากทีมให้ validate ไอเดียของตัวเองเสมอว่าคิดถูกรึเปล่า
- และสอนน้องๆเรื่อง mindset ที่จะกล้าคิดต่างนี้ด้วย (challenging mindset)
- Clear expectations for everthing
- หัวหน้าที่ดีจะต้อง บอกความคาดหวังให้ชัดเจน ในทุกเรื่อง ไม่มีปล่อยให้ทีมเดาเอง
- Create a clear plan for success
- ดูแลน้องๆอย่างทั่วถึง มีแพลนเส้นทางที่เติบโตให้น้องๆในทีมทุกคน 🌳
- Prioritize the team over themselves
- คิดถึงทีมก่อนตัวเอง ให้เครดิตกับน้องๆในทีม
- ลุงบอก Above everything else, the team needs to be happy, or nothing else will work.
- ข้อนี้คุณเคน The standard เขียนไว้เป็นเล่มเลย ในหนังสือ The Invisible Leader
- Constantly looking for sustainable result
- ในด้านเทคนิค ⚒️: มีวิธีที่จะหาวิธีทำงานให้ดีแบบยั่งยืน มีระบบ เช่น CICD / automate test และอื่นๆ
- ในด้านนามธรรม 🧘: ถามตัวเองว่าทีมจะทำงานแบบนี้ได้อีกนานมั้ย หนักหรือเบาไปมั้ย สิ่งที่ทำอยู่ทำให้สภาพจิตใจทีมเป็นยังไงบ้าง
- Constantly trying to improve themselves
- พัฒนาตัวเองตลอดเวลา
- Build networks and are always looking for external collaboration
- คอยสร้าง connection ที่ดีกับคนอื่น และถ่อมตัวพอที่จะขอความช่วยเหลือจากคนอื่นและคนนอกบริษัท
38.
Ask for feedback
“Feedback is important to your career development, so it’s your right as an employee to receive it and your duty to request it if it’s not provided.”
Feedback สำคัญกับความก้าวหน้าเรา เพราะมันทำให้เรารู้ว่าเราต้องปรับปรุงตรงไหนหรือทำได้ดีแล้วขนาดไหนในความคิดเห็นของคนอื่น
ถ้าที่บริษัทไม่มีหรือไม่ได้ให้มานานแล้ว 3-4 เดือน ก็ควรจะต้องขอ feedback จากหัวหน้า หรือ เพื่อนร่วมทีม ได้แล้ว fernando บอกว่า It’s a MUST.
39.
Unsolicited Advice
“You’re giving feedback, not advice. Remember this one. You’re telling others. what you think about their work, not what they should do to improve it.
Giving feedback is great, but unsolitcited advice is terrible.”
Feedback ทำให้ทีมเติบโต แต่คำแนะนำที่ไม่มีใครขอทำให้ทีมอึดอัด ในช่วงเวลาที่เราได้มีโอกาศ feedback ให้คนอื่นควรจะ
- ✅ ให้ความเห็นของเราต่อภาพรวมงานที่เขาทำ (ความเห็นต่องาน) – (ตัวอย่าง: พี่ว่างานมันดีนะแต่มันขาดรายละเอียดนิดหน่อย)
- ❌ อย่าให้คำแนะนำว่าเขาต้องทำอะไร (ความเห็นต่อคน) – (ตัวอย่าง: จากที่ผ่านมาน้องต้องทำงานให้ละเอียดมากขึ้น ต้องใส่ใจรายละเอียดมากกว่านี้)
จนกว่าเขาจะขอคำแนะนำเองว่าต้องทำอะไร เพราะนอกจากคนฟังจะรู้สึกไม่ดี ยังจะรู้สึกว่าถูกตำหนิได้
40.
You are a developer, period
As long as you’re able to write code, you’re a developer, and don’t let anyone tell you otherwise.
สุดท้ายแล้ว ถ้าเราสามารถเขียนโค้ดได้แม้แต่บรรทัดเดียว ลุงบอกว่าเราเป็น dev แล้วแน่นอน
อย่าให้ใครที่มาบอกว่า เรายังอ่อนไป, เรียนจบไม่ตรงสาย หรือ อื่นๆ อย่าไปแคร์คำพูดพวกนั้นเด็ดขาด เชื่อมั่นในศักยภาพตัวเองแล้วลุยต่อไปครับ ❤️
ขอบคุณทุกคำแนะนำ, เนื้อหาและทุก คำพูด โดยคุณ Fernando Doglio จากหนังสือ Skills of a successful software engineer
Leave a Reply