- ผู้เขียนได้พบเจอนักพัฒนาหลากหลายคน และเริ่มครุ่นคิดถึงลักษณะร่วมที่นักพัฒนาที่เก่งที่สุดมีเหมือนกัน
- บทความนี้เป็นบันทึกข้อสังเกตที่เขียนขึ้นเพื่อสร้างแรงบันดาลใจให้กับนักพัฒนามือใหม่หรือคนที่อยากเติบโต
อ่านเอกสารอ้างอิงก่อน
- สิ่งสำคัญคือการสร้างนิสัยให้อ่านเอกสารทางการก่อน แทนที่จะไปหาใน Stack Overflow หรือ LLM ก่อนเสมอ
- เอกสารทางการของ Apache, Python, TOML และอื่น ๆ นั้น เขียนไว้ดีพอสมควรจริง ๆ
- การมีนิสัยเรียนรู้จากต้นทางโดยตรงจะช่วยได้มากในระยะยาว
เข้าใจเครื่องมือให้ลึก
- การ “ใช้” เครื่องมือเป็น กับการ “เข้าใจ” เครื่องมือนั้น เป็นคนละระดับกัน
- คนที่รู้จักเครื่องมือดีจะอธิบายการตั้งค่าแต่ละอย่างได้
- หากอยากเข้าใจให้ดี ต้องมองให้ครบทั้ง:
- ประวัติ (ทำไมมันถึงถูกสร้างขึ้นมา)
- ปัจจุบัน (ใครเป็นผู้ดูแลอยู่)
- ข้อจำกัด (เมื่อไรที่มันไม่เหมาะ)
- ระบบนิเวศ (เครื่องมือรอบข้าง ไลบรารี ฯลฯ)
ให้ครบทั้งหมด
- ถ้าใช้ Kafka เป็นเครื่องมือหลัก ก็ควรรู้มากกว่าระดับที่อ่านผ่าน ๆ มาจาก Reddit
อ่านข้อความ error ให้ละเอียด
- ถ้ามองข้อความ error อย่างตั้งใจ จะพบว่ามีคำใบ้อยู่ในนั้น
- นักพัฒนาที่เก่งที่สุดสามารถอนุมานปัญหาได้แม้มีข้อมูลเพียงเล็กน้อย
- ปัญหาถึง 80% แก้ได้เพียงแค่อ่านข้อความ error ให้ดี
แยกปัญหาออกเป็นส่วนย่อยให้ได้
- การติดขัดเป็นเรื่องที่ทุกคนเจอ และจะแก้ได้ก็ต่อเมื่อแยกมันออกเป็นชิ้นเล็ก ๆ
- คนที่มีประสบการณ์มาก หรือมีทักษะแก้ปัญหาสูง จะทำการแยกแบบนี้ได้อย่างง่ายดาย
- งานหลักของนักพัฒนาสุดท้ายแล้วก็คือการแยกปัญหาใหญ่ให้เป็นปัญหาเล็ก
- เมื่อค่อย ๆ แก้ปัญหาง่ายทีละข้อ ก็จะแก้ปัญหาใหญ่ทั้งหมดได้
จัดการโค้ดอย่างไม่หวาดกลัว
- นักพัฒนาที่เก่งที่สุดไม่กลัวการอ่านโค้ด
- พวกเขาไม่พูดว่า “นั่นไม่ใช่ขอบเขตของฉัน” แต่จะลองทำและเรียนรู้ไปเลย
- แม้เป็นโค้ดที่เพิ่งได้แตะครั้งแรก ก็มักกลายเป็นผู้เชี่ยวชาญของทีมได้อย่างรวดเร็ว
ช่วยเหลือผู้อื่นเสมอ
- นักพัฒนาที่คอยช่วยเหลือแม้ในช่วงที่ยุ่ง คือทั้งเพื่อนร่วมทีมที่ดีและผู้เชี่ยวชาญที่ยอดเยี่ยม
- ความอยากรู้อยากเห็นและท่าทีที่พร้อมร่วมมือกันเป็นคุณสมบัติจำเป็นของนักพัฒนาที่ดี
เขียน
- นักพัฒนาที่โดดเด่นมักสื่อสารเก่ง และถ่ายทอดความคิดออกมาเป็นลายลักษณ์อักษรได้
- พวกเขาแบ่งปันความคิดผ่านบล็อก การบรรยาย กิจกรรมโอเพนซอร์ส และอื่น ๆ
- ทักษะการเขียนเชื่อมโยงโดยตรงกับโครงสร้างของความคิด
- โค้ดของคนที่เขียนเก่งมักมีโครงสร้าง ชัดเจน และบางครั้งก็มีไหวพริบ
อย่าหยุดเรียนรู้
- คนที่ยังเรียนรู้อยู่เสมอไม่ว่าจะอายุเท่าไร คือ นักพัฒนาที่เก่งอย่างแท้จริง
- พวกเขาไม่ลังเลที่จะลองเครื่องมือหรือภาษาใหม่ ๆ
- พวกเขาไม่ได้ไล่ตามเทคโนโลยีล่าสุดแบบไม่ลืมหูลืมตา แต่สามารถวิเคราะห์ข้อดีข้อเสียได้ด้วยตัวเอง
- ต่อให้อายุน้อย หากติดอยู่กับกรอบความคิดเดิม การเติบโตก็จะหยุดลง
อย่ายึดติดกับตำแหน่ง
- นักพัฒนาที่ดีพร้อมเรียนรู้จากทุกคน ไม่ว่าตำแหน่งจะเป็นอะไร
- พวกเขามีท่าทีว่าต่อให้เป็นพนักงานใหม่ก็มีสิ่งให้เรียนรู้ได้
- พวกเขาได้รับแรงบันดาลใจจากบทสนทนากับคนที่มีมุมมองใหม่ ๆ
สร้างชื่อเสียง
- ทักษะสำคัญก็จริง แต่การทำให้ทักษะนั้น เป็นที่รับรู้ ก็สำคัญเช่นกัน
- ชื่อเสียงเป็นเครื่องมือในการขยายอิทธิพล
- สามารถสร้างชื่อเสียงได้ด้วยวิธีต่อไปนี้:
- สร้างหรือ deploy บริการสำคัญด้วยตัวเอง
- พัฒนาเครื่องมือที่เป็นที่รู้จัก
- มีส่วนร่วมกับโอเพนซอร์สชื่อดัง
- เขียนหนังสือที่ถูกอ้างอิงบ่อย
- ชื่อเสียงไม่ได้สร้างขึ้นชั่วข้ามคืน และต้องอาศัยความพยายามสม่ำเสมอกับเวลา
มีความอดทน
- ต้องมีความอดทนทั้งกับคนและกับคอมพิวเตอร์
- คนรอบตัวไม่ได้โง่ เพียงแค่มีข้อมูลไม่พอ
- หากไม่มีความอดทน ความไม่พอใจก็จะสะสมง่ายและทำงานร่วมกันได้ยาก
- การแก้ปัญหาที่ยากต้องอาศัยสมาธิและความมุ่งมั่น
อย่าโทษคอมพิวเตอร์
- นักพัฒนาที่เก่งที่สุดไม่โทษระบบหรือปัจจัยภายนอกเด็ดขาด
- ปัญหาที่ดูเหมือนสุ่มจากภายนอกก็มีเหตุผลเชิงตรรกะอยู่เบื้องหลัง
- สิ่งสำคัญคือท่าทีที่ขุดลึกลงไปจนพบสาเหตุให้ได้
รู้จักพูดว่า “ไม่ทราบ”
- ผู้เขียนเคยรอจังหวะที่ผู้สมัครจะพูดว่า “ไม่ทราบ” โดยตั้งใจระหว่างการสัมภาษณ์
- สิ่งสำคัญไม่ใช่คำตอบ แต่เป็นท่าที
- ผู้สมัครที่ดีที่สุดจะยอมรับว่าไม่รู้ แล้วเริ่มต้นใช้เหตุผลอนุมาน
- ท่าทีที่ยอมรับว่าไม่รู้ แสดงให้เห็นถึงศักยภาพในการเรียนรู้
- คนที่โกหกหรือแกล้งทำเป็นรู้ส่งผลลบต่อทีม
อย่าเดา
- ตามปรัชญาของ PEP 20 หากยังคลุมเครือ ก็อย่าเดาเด็ดขาด
- ความเสี่ยงของการเดา:
- ถ้าผิด ก็กลายเป็นบั๊ก
- ต่อให้ถูก ก็อาจทำให้เชื่อในสมมติฐานที่ผิดและก่อปัญหาในภายหลัง
- หากยังไม่มั่นใจ:
- ให้ถาม
- อ่านเอกสาร
- ใช้เครื่องมือดีบัก
- และค้นหาหลักฐาน
รักษาความเรียบง่าย
- คนฉลาดเขียนโค้ดที่ฉลาด แต่คนที่ยอดเยี่ยมเขียนโค้ดที่เรียบง่าย
- โค้ดที่เรียบง่ายเหมาะกับการบำรุงรักษามากกว่าอย่างชัดเจน
- การรู้ว่าตอนไหนควรซับซ้อนและตอนไหนไม่ควร นั่นแหละคือฝีมือที่แท้จริง
ข้อคิดส่งท้าย
- บทความนี้ไม่ใช่เช็กลิสต์ และวิศวกรรมที่ยอดเยี่ยมก็ไม่ใช่การแข่งขัน
- แต่ก็อย่าหลอกตัวเองว่าสามารถข้ามงานยาก ๆ ไปได้
- ไม่มีทางลัดสู่การเป็นนักพัฒนาที่ยอดเยี่ยม
19 ความคิดเห็น
ขอบคุณสำหรับบทความดี ๆ มากครับ!!
ฉันรู้สึกสบายใจที่บทความนี้ไม่ได้เป็นเช็กลิสต์ และรู้สึกมีกำลังใจจากคำพูดที่ว่าไม่มีทางลัด
ถ้าเข้าใจโปรเจกต์ของบริษัท
ไม่ว่าจะกลายเป็นนักพัฒนาระดับซีเนียร์ในสายไหน
ไม่ว่าสายนั้นจะเป็นเฟิร์มแวร์ แอป หรือเว็บ
ก็ดูเหมือนว่าจะต้องไปถึงระดับที่สามารถดู debug log ของเว็บ แอป หรือเฟิร์มแวร์
แล้วดีบักได้ว่าปัญหาเกิดขึ้นได้อย่างไร
ผมจำพฤติกรรมที่ตัวเองเคยคาดเดาไว้ตอนสัมภาษณ์ได้
โดยส่วนตัวแล้ว ผมให้ความสำคัญกับการ "คิดอยู่เสมอว่าตัวเองกำลังสร้างอะไรอยู่" ด้วยเช่นกัน
มีคำศัพท์ดี ๆ อย่าง Critical Thinking อยู่ด้วยนะ
ช่วยได้มากจริง ๆ ครับ ขอบคุณสำหรับบทความดี ๆ
งั้นก็ให้ LLM อ่านเอกสารทางการให้ซะเลยสิ!
RTFM: อ่านเอกสารอย่างเป็นทางการหน่อยครับ
แม้จะบอกว่าไม่ใช่เช็กลิสต์ แต่คงต้องเอามาเป็นเช็กลิสต์ของผมเองแล้วล่ะ
เห็นด้วยอย่างมากว่าควรอ่านเอกสารอย่างเป็นทางการให้แน่ใจ
ตอนเริ่มสอนเขียนโค้ด ผมรู้สึกว่าพรสวรรค์ความเป็นโปรแกรมเมอร์ของคนคนหนึ่งมักเริ่มปรากฏให้เห็นจากการที่เขาสามารถอ่านข้อความแสดงข้อผิดพลาดได้อย่างละเอียดรอบคอบหรือไม่
.... พวกที่ไม่มีความเข้าใจพื้นฐานว่า error กับ bug นั้นมีอยู่เสมอนั่นแหละคือพวกนักต้มตุ๋น
ประโยคเข้าใจยากเกินไป..
บนเว็บน่ะครับ
แม้จะไม่ใช่ทั้งหมด แต่ส่วนใหญ่ก็เป็นประเด็นที่ชวนให้เห็นด้วยนะครับ
ความเห็นจาก Hacker News
การไม่เดาสุ่มเป็นสิ่งสำคัญที่สุดในงานธุรกิจ
เวลารับมือกับสิ่งใหม่ ๆ จะชอบเดาเล็กน้อยก่อนอ่านเอกสารอ้างอิงอย่างลึกซึ้ง
การอ้างอิงซอร์สโดยตรงแทนการพึ่ง Stack Overflow หรือ LLM เป็นเรื่องที่ดี
นักพัฒนาที่ยอดเยี่ยมที่สุดสื่อสารและเรียนรู้กับผู้คนทุกระดับ
หากใช้ Stack Overflow เป็น ก็ช่วยได้มาก
โปรแกรมเมอร์ที่เก่งที่สุดสามารถสร้างผลงานยอดเยี่ยมได้แม้ไม่มีพื้นฐาน CS
นอกจากการเขียนโปรแกรมแล้ว การสื่อสารกับโดเมนธุรกิจก็สำคัญ
การอ่านและทำความเข้าใจข้อความ error ช่วยแก้ปัญหาได้มาก
asdfเพื่อจัดการเวอร์ชัน Python, Go และ NodeJS ก็สามารถแก้ปัญหาได้จากข้อความ errorasdfคืออะไร? คุณควรดูคำเตือนอืม ฉันว่าท่าทีที่ไม่พยายามจะเป็นที่สุดแบบเด็ดขาดน่าจะดีกว่านะ จะบอกว่าเขียนบ้าง... ช่วยบ้าง... คนแบบนั้นน่ะ...