คำแนะนำสำหรับนักพัฒนาซอฟต์แวร์มือใหม่ที่อ่านบทความแนะนำมาหมดแล้ว
(buttondown.email)- ในช่วงต้นของอาชีพ แม้แต่คำแนะนำด้านการพัฒนาจากคนดัง ก็ไม่ควรทำตามตรง ๆ โดยไม่พิจารณาก่อนว่า เหมาะกับสถานการณ์ของตัวเองหรือไม่ และคำกล่าวอ้างจำนวนมากในวงการซอฟต์แวร์ก็มักไม่มีหลักฐานที่ยืนยันได้ชัดเจนนัก
- หากมีไอเดียที่ชอบ ก็ลองลงมือทำเองได้ แต่ตราบใดที่ไม่รบกวนเพื่อนร่วมงาน การลองผิดลองถูกก็เป็นส่วนหนึ่งของ กระบวนการเรียนรู้
Debugging: The 9 Rulesเป็นหนังสือเริ่มต้นที่อ่านง่ายและแนะนำได้ เพราะพูดถึง ทักษะการดีบัก ซึ่งหนังสือสำหรับผู้เริ่มต้นมักละเลย- “วิธีที่ถูกต้อง” หรือ “แนวปฏิบัติที่ดีที่สุด” มักเกิดจากกรณีล้มเหลวเฉพาะแบบและเส้นทางทางประวัติศาสตร์ จึงควรแยกตัวเทคนิคออกจาก วิธีการเผยแพร่แนวคิดนั้น
- หากได้ลองใช้ความสามารถที่ซ่อนอยู่ของเครื่องมือ งานของแผนกอื่น และการเขียนโปรแกรมหลายรูปแบบตั้งแต่เนิ่น ๆ ก็จะหางานด้าน ซอฟต์แวร์ ที่เหมาะกับตัวเองได้ง่ายขึ้น
ท่าทีต่อการรับคำแนะนำ
- คำแนะนำสำหรับนักพัฒนาที่ถูกอ่านอย่างแพร่หลาย บางครั้งก็แพร่เพราะผู้เขียน เขียนเก่ง ไม่ใช่เพราะเป็นโปรแกรมเมอร์ที่ยอดเยี่ยมเสมอไป
- ไม่จำเป็นต้องปฏิเสธคำแนะนำทุกอย่างโดยอัตโนมัติ แต่ควรพิจารณาอย่างรอบคอบว่าจะนำมาปรับใช้กับสถานการณ์ของตัวเองอย่างไร
- คำกล่าวอ้างว่าเป็น “ความจริงเชิงวัตถุ” เกี่ยวกับซอฟต์แวร์ควรถูกฟังอย่างระมัดระวัง เพราะเนื้อหาที่มีการศึกษาทางวิทยาศาสตร์จริง ๆ ยังมีไม่มาก และผลการศึกษาก็มักไม่ได้ให้ข้อสรุปที่ชัดเจน
- ไม่จำเป็นต้องกังวลเกินไปว่าจะเผลอเรียนรู้ “สิ่งที่ผิด”
- หากชอบไอเดียของใครสักคน ก็ลองทำเองได้
- ตราบใดที่ไม่ได้ไปรบกวนเพื่อนร่วมงานอย่างจริงจัง ต่อให้ภายหลังย้อนมองแล้วคิดว่าน่าจะทำอีกแบบ สุดท้ายมันก็ยังกลายเป็นการเรียนรู้ได้
- Debugging: The 9 Rules เป็นหนังสือที่แนะนำสำหรับนักพัฒนามือใหม่
- อ่านง่าย และพูดถึงทักษะสำคัญอย่าง การดีบัก ซึ่งหนังสือ “โปรแกรมเมอร์มือใหม่” เล่มอื่น ๆ แทบไม่ค่อยพูดถึง
- จะยืมจากห้องสมุดหรือขอให้บริษัทซื้อให้ก็ได้
ข้อจำกัดของ “วิธีที่ถูกต้อง” และแนวปฏิบัติที่ดีที่สุด
- ในบางช่วง คุณอาจเชื่อมั่นมากว่าตัวเองได้ค้นพบ “Right Way” ของการเขียนโปรแกรม และถ้าทุกคนทำตามแนวทางนั้น วงการนี้จะดีขึ้น
- มีการยกตัวอย่างเช่น การพัฒนาแบบขับเคลื่อนด้วยการทดสอบ, การเขียนโปรแกรมเชิงฟังก์ชัน, Lisp, และ formal methods
- การหลงใหลในแนวทางแบบนั้นอาจหลีกเลี่ยงได้ยาก และอาจเป็นประสบการณ์ที่รู้สึกดีด้วย แต่สิ่งสำคัญคืออย่าทำให้อัตลักษณ์ของตัวเองกลายเป็น “Right Way Guy”
- เมื่อเวลาผ่านไป คุณจะได้เรียนรู้ว่าไม่ว่าแนวทางไหน การเขียนโปรแกรมก็ยังอาจน่าหงุดหงิดและยุ่งเหยิงได้ และต่อให้ไม่ใช้แนวทางนั้น ก็ยังสร้างซอฟต์แวร์ที่ยอดเยี่ยมได้
- เมื่อรู้จัก “Right Way” หลายแบบแล้ว ก็จะสามารถหยิบมาผสมใช้ให้เหมาะกับปัญหาได้
- “Right Way” แบบแรกที่ได้เจอ มักมาจากคนที่อินกับแนวทางนั้นอย่างเต็มที่
- ภายหลังไม่จำเป็นต้องโทษคนนั้นมากเกินไป และควรระวังไม่สับสนระหว่างตัวเทคนิคจริง ๆ กับ วิธีที่เขาใช้โปรโมตมัน
- ไอเดียจำนวนมากจำเป็นต้องถูกปรับบางส่วน เพื่อให้ใช้ร่วมกับไอเดียอื่นได้ มากกว่าจะใช้ในรูปแบบบริสุทธิ์เดิมทั้งหมด
- อย่างที่ Julia Evans พูดไว้ว่า “เบื้องหลังแนวปฏิบัติที่ดีที่สุดทุกข้อ มี เรื่องสยองขวัญ อยู่”
- หากมีแนวปฏิบัติที่ดีที่สุดข้อไหนที่คุณไม่เข้าใจ ก็ลองตามหากรณีล้มเหลวที่ทำให้มันถือกำเนิดขึ้น
- ถ้ากรณีล้มเหลวนั้นไม่เกี่ยวกับสถานการณ์ของคุณ ก็เลือกวิธีอื่นได้เช่นกัน
- แนวปฏิบัติที่ดีที่สุดและธรรมเนียมปฏิบัติจำนวนมากมีลักษณะ พึ่งพาเส้นทางเดิม
- คุณอาจทำตามเพราะเมนเทอร์ของคุณทำ และเมนเทอร์คนนั้นก็ทำตามเมนเทอร์ก่อนหน้าอีกทอดหนึ่ง
- วิธีการที่เคยถูกสร้างขึ้นเพื่อแก้ปัญหาในอดีต อาจเกี่ยวข้องกับปัจจุบันน้อยลงแล้ว
- ธรรมเนียมบางอย่างที่ฟังดูเหมือนคำอธิบายย้อนหลังก็อาจเป็นแบบนั้นจริง ๆ และหากค้นดู ก็อาจย้อนรอยกระบวนการก่อตัวของมันได้
วิธีขยายความเข้าใจในงานจริง
- การเดินเล่นถูกเสนอเป็นนิสัยที่ช่วยจัดระเบียบความคิดได้
- เครื่องมือที่คุณใช้อยู่ส่วนใหญ่ มักมีความลึกที่ซ่อนอยู่
- ไม่จำเป็นต้องฝึกให้เชี่ยวชาญระดับผู้เชี่ยวชาญกับทุกอย่าง ไม่ว่าจะเป็นภาษาโปรแกรม, Git, หรือเครื่องมืออย่าง JIRA
- แต่ก็ควรใช้เวลาราว 5–10 นาทีเพื่อดูว่ามันทำอะไรได้มากกว่านี้อีกบ้าง
- การพูดคุยกับคนจากแผนกอื่นในบริษัทจะช่วยให้เข้าใจงานกว้างขึ้น
- อาจคุยกับฝ่ายซัพพอร์ต, ฝ่ายที่ดูแลโดเมนธุรกิจ, ฝ่ายขาย เป็นต้น
- หากมีเวลาและขอได้ไม่ลำบาก ก็มีข้อเสนอให้ลองตามดูงานของพวกเขาด้วย
- ในช่วงต้นอาชีพ ถ้าเป็นไปได้ก็ควรลองงานเขียนโปรแกรมหลายประเภท
- ไม่จำเป็นต้องย้ายงานเสมอไป เพราะบริษัทส่วนใหญ่ก็มีงานเขียนโปรแกรมหลายแบบอยู่พร้อมกัน
- หากเป็นบริษัทพัฒนาเว็บ ก็อาจลองงานฟรอนต์เอนด์, แบ็กเอนด์, งานปฏิบัติการ, หรืองานฐานข้อมูลได้
- สิ่งนี้ช่วยเรื่องการเรียนรู้ก็จริง แต่ที่สำคัญกว่านั้นคือเพิ่มโอกาสในการค้นพบงานซอฟต์แวร์ที่คุณชอบจริง ๆ
- มีตัวอย่างส่วนตัวว่าตอนงานแรกเริ่มจากฟรอนต์เอนด์แล้วรู้สึกลำบาก แต่หลังจากย้ายไปแบ็กเอนด์ก็มีความสุขมากขึ้น
- วงการซอฟต์แวร์เปลี่ยนแปลงตลอดเวลา จึงมีเหตุผลที่มักแนะนำว่าอย่าหลงไปกับกระแสเฟรมเวิร์ก แต่ให้โฟกัสที่ ทักษะพื้นฐาน
- ด้วยอินเทอร์เน็ต, โอเพนซอร์ส, งานคอนเฟอเรนซ์ และสิ่งอื่น ๆ ข้อมูลในวงการซอฟต์แวร์จึงแพร่กระจายเร็วมาก
- กำแพงในการแชร์ไอเดียนั้นต่ำมาก จนแม้แต่โปรเจกต์ส่วนตัวที่มีคนใช้เพียงคนเดียวก็ดูเหมือนเป็นสิ่งที่หลายคนรู้จัก
- เทคโนโลยีจำนวนไม่น้อยที่คุณได้ยิน อาจมีฐานผู้ใช้เล็กและไม่ได้ถูกนำไปใช้อย่างแพร่หลาย
- หากคุณสนใจมาก จะเป็น early adopter ก็ได้ แต่ถ้าไม่ ก็รออีกสักสองสามปีเพื่อดูว่ามันอยู่รอดจริงไหมก็ไม่เป็นไร
- ไม่มีใครทำนายอนาคตได้ และแม้แต่ปัจจุบันเองก็เป็นผลลัพธ์ที่เคยคาดเดาได้ยาก
- สิ่งสำคัญคือทำให้ดีที่สุด ใช้ชีวิตให้สอดคล้องกับคุณค่าของตัวเอง และมีท่าทีที่เพลิดเพลินกับกระบวนการ
1 ความคิดเห็น
ความคิดเห็นบน Hacker News
ช่วงหลังผมทำโปรเจกต์งานอดิเรกกับนักพัฒนารุ่นจูเนียร์คนหนึ่งและนักพัฒนาที่ไม่จูเนียร์เท่าไรอีกคน ทั้งคู่เป็นสาย “ยึดติดกับวิธีที่ถูกต้อง”
สำหรับบอต Discord + โค้ด Rust ราว 300 บรรทัด ที่ตอนนี้มีแค่พวกเราเท่านั้นที่จะรัน พวกเขาเรียกร้องให้มีเอกสารครบถ้วน, QA กับ VM แยกสำหรับ “โปรดักชัน”, การ deploy ด้วย systemd, ระบบ template สำหรับสตริงไม่กี่ตัว ไปจนถึงชั้น ORM สำหรับ SQL query แค่สี่รายการ
โปรเจกต์นี้อย่างมากก็มีคนใช้ราว 10 คน และนี่ก็เป็นแค่ครึ่งหนึ่งของข้อกำหนดสำหรับรีลีส “0.3” เท่านั้น แถมยังวางแผนจะออกแบบเกินจำเป็นไปมากกว่านี้อีก ผมเลยถอนตัวจากโปรเจกต์นั้น
ตอนเริ่มเขียนโปรแกรมใหม่ ๆ ผมเองก็เป็นคนแบบนั้นอยู่หลายปี แต่ได้เรียนรู้ว่าในวิทยาการคอมพิวเตอร์มีเรื่องที่ลึกกว่าพวก best practices หรือ code style มาก และสุดท้ายสิ่งสำคัญคือ โค้ดที่ทำงานได้จริง
หมายถึงการทุ่มความสนใจอย่างไม่ได้สัดส่วนไปกับรายละเอียดเล็กน้อยแทนที่จะเป็นปัญหาหลัก มีอุปมาว่าคณะกรรมการอนุมัติโรงไฟฟ้านิวเคลียร์กลับไม่คุยเรื่องโรงไฟฟ้า แต่คุยกันแค่สีของที่จอดจักรยานข้าง ๆ
กรณีนี้ก็เช่นกัน การไปโฟกัสเรื่องแยก QA/VM โปรดักชัน, deploy ด้วย systemd, template สำหรับสตริงไม่กี่ตัว, ORM สำหรับ SQL ไม่กี่คำสั่ง ในโปรเจกต์ที่มีผู้ใช้ 10 คน ดูเหมือนตัวอย่างคลาสสิกของ กฎแห่งความจุกจิก
เรื่องแบบนี้โดยเฉพาะนักพัฒนาจูเนียร์จะเข้าใจและถกเถียงได้ง่าย จึงมักเข้ามามีส่วนร่วมมากขึ้น ขณะที่ฟีเจอร์หลักที่ยากจริง ๆ กลับถูกละเลยได้ง่าย
อย่างไรก็ดี ผมไม่คิดว่าการทำเอกสารส่วนที่มีความหมายของโปรเจกต์ให้ดีเป็นการหมกมุ่นกับเรื่องจุกจิก
การเขียน systemd unit หรือการใช้ ORM ไม่ได้กินเวลามากอย่างที่คิด แต่ภายหลังเมื่อมีใครมาดู หรือมีคนอื่นอยากร่วม contribute ก็ช่วยได้มากทีเดียว
ทำไว้ตอนที่บริบทยังอยู่ในหัวจะง่ายกว่า และเมื่อโปรเจกต์ใหญ่ขึ้นแล้ว งานจุกจิกแบบนี้แทบจะไม่ถูกจัดการ
เพราะเป็นโปรเจกต์งานอดิเรก พวกเขาอาจอยากทำให้ “ถูกต้อง” เพื่อ เรียนรู้เครื่องมือและได้ความพึงพอใจ ก็ได้
ตอนต้นมีฉากที่ต้องซื้อเราเตอร์ราคา $50 แต่เมื่อตัวละครคนหนึ่งเสนอว่าลองซ่อมเราเตอร์เดิมดูไหม คนอื่น ๆ ก็ตอบว่า “ลองแล้ว” แทบจะก่อนที่ประโยคจะจบ
ฉากนี้แสดงให้เห็นว่าพวกเขารู้จักกันดีมากและใช้เวลาด้วยกันมาก จนแทบอ่านใจกันได้
แต่พอมีคนพูด “yes” กับการซื้อเราเตอร์ใหม่ อีกคนกลับตอบว่า “ต้องใช้ aye”
กล่าวคือกฎเรื่องคำที่ต้องใช้ในการลงคะแนนตัดสินใจของธุรกิจเสริมเข้มงวดมาก และไม่สำคัญเลยว่าพวกเขาจะสนิทกันจนต่อประโยคกันได้แค่ไหน, เป็นเราเตอร์ราคา $50 หรือรายได้จากงานเสริมจะเล็กน้อยเพียงใด
กฎกำหนดให้ใช้ aye
คนบางส่วนที่ยึดติดกับ “วิธีที่ถูกต้อง” ดูเหมือนเป็นคนที่ประสบความสำเร็จจากการลอกความรู้ที่เก็บอยู่ในภูมิปัญญารวมของสังคมมาใช้ แต่ไม่ค่อยรู้ว่าจริง ๆ แล้วในหัวตัวเองเกิดอะไรขึ้น
ข้อดีคือได้รับสืบทอดวิธีการที่พิสูจน์แล้วมาโดยไม่ต้องค้นพบเองอย่างยากลำบาก แต่ข้อเสียคือไม่เข้าใจอย่างแท้จริงว่าสถานการณ์แบบใดที่วิธีนั้นจะนำไปสู่ความล้มเหลว
ในคอมเมนทารีของผู้กำกับบอกว่าฉากนี้ตั้งใจใส่ไว้เพื่อแสดงให้เห็นว่าตัวละครบางคนจริงจังกับกฎมากเกินไป ขณะที่บางคนก็ไม่จริงจังพอ
เหตุผลที่แนะนำแนวปฏิบัติแบบลัทธิบูชาสินค้าให้คนอื่นก็ดูคล้ายกัน ยิ่งมีคนทำตามมากเท่าไร เมื่อแนวปฏิบัตินั้นล้มเหลวอย่างหายนะ โอกาสที่คนที่ล้มเหลวจะไม่ใช่ตัวเองก็ยิ่งมากขึ้น
ช่วงนี้เห็นกรณีแบบนี้บ่อยมาก และผมเรียกคนพวกนี้ว่า จูเนียร์ที่ฉลาด ไม่สำคัญว่าจะมีประสบการณ์ 1 ปีหรือ 20 ปี
จูเนียร์ที่ฉลาดรู้จัก design patterns ส่วนใหญ่ และอ่าน Mythical Man-Month มาแล้ว แต่เพราะอยากลองเทคโนโลยี ภาษา หรือเฟรมเวิร์กใหม่ ๆ จึงถือค้อนใหม่เงาวับแล้ววิ่งหาสิ่งที่ดูเหมือนตะปู
แล้วก็ตัดสินใจแปลก ๆ เพราะไม่เข้าใจพลังที่ฐานข้อมูลเก่า ๆ ซึ่งปรับแต่งมาดีแล้วสามารถมอบให้ได้
ด้วยประสบการณ์ 20 ปี ผมเห็นมามากว่าโปรเจกต์แบบนั้นจบลงอย่างไรในอีก 5–10 ปีข้างหน้า เมื่อทีมเดิมเกินครึ่งออกไปแล้ว และผมก็เก็บส่วนที่มีคุณค่าจริงไว้ แต่ตัดครึ่งหนึ่งที่ไร้ประโยชน์ออก
เราไม่ได้เปิดอนุบาลนักพัฒนาที่พยายามจะสนุกให้ได้ทุกวิถีทาง แต่เราทำงานให้ธุรกิจที่จ่ายเงินและคาดหวังผลลัพธ์ที่เสถียรและค่อนข้างรวดเร็ว
การลองของใหม่เพราะเป็นเทคโนโลยีล้ำสมัยหรือเพื่อเลี่ยงความน่าเบื่อ ในระยะยาวมักทำให้พังมากกว่าซ่อมให้ดีขึ้น
ควรนำเทคโนโลยีที่ทั้งทีมเข้าใจและชำนาญได้มาใช้ ไม่ใช่เอาเทคโนโลยีที่มีซูเปอร์สตาร์เบื่อ ๆ คนเดียวเท่านั้นที่รู้เข้ามา
ถ้าอยากใส่รายการเทคโนโลยีในเรซูเม่ให้เต็ม ก็ไปทำในบริษัทแบบนั้นได้ และที่แบบนั้นก็มีข้อดีของมัน
แต่คนแบบนี้ก็มักไม่อยู่ยาวอยู่ดี ดังนั้นมูลค่าเพิ่มโดยรวมก็น่าสงสัย สำหรับบางคนมันอาจน่าเบื่อ แต่ผมเรียกสิ่งนี้ว่า วิธีแบบผู้ชำนาญ
ยิ่งถ้าเป้าหมายของ side project คือให้บริษัทต่าง ๆ มาดู GitHub ของเรา ก็ยิ่งดูสมเหตุสมผลขึ้น
เอกสารสำคัญมาก ผมมีโปรเจกต์ค่อนข้างเรียบง่ายหลายตัวที่มีไม่ถึง 300 บรรทัด รวมทั้งบอตและเว็บสเครเปอร์ แต่ตอนนี้รันไม่ได้แล้วเพราะไม่ได้ทำเอกสารไว้
Raspberry Pi ที่เคยรันมันตายไปแล้ว และผมก็ไม่รู้จะเริ่มแก้ virtual framebuffer แบบ headless อย่างไร หรือจะ debug ข้อผิดพลาดลึกลับที่ค้นหาแล้วไม่เจอผลลัพธ์ที่มีประโยชน์อย่างไร
ถ้าเคยทำเป็นคอนเทนเนอร์ไว้ หรืออย่างน้อยบันทึกขั้นตอนการตั้งค่าไว้ ปัญหาแบบนี้ก็คงไม่เกิดขึ้น
เป็นบทความที่ดี และอยากให้มีคนอ่านมากกว่านี้
ผมทำงานด้านซอฟต์แวร์ โดยเฉพาะด้านการจัดการข้อมูลมา 15 ปี และได้เรียนรู้สิ่งนี้พอดี
Kesamutti Sutta ที่ได้เรียนรู้จากพื้นฐานพุทธศาสนาเถรวาทก็ช่วยได้มากเช่นกัน
เนื้อหาคืออย่าทำตามไปตรง ๆ เพียงเพราะได้ยินซ้ำ ๆ กันมา เพราะเป็นธรรมเนียม เพราะเป็นข่าวลือ เพราะมีอยู่ในคัมภีร์ เพราะเป็นการคาดเดา สัจพจน์ หรือตรรกะที่ดูสมเหตุสมผล เพราะความลำเอียงต่อแนวคิดที่ครุ่นคิดมานาน เพราะใครบางคนดูมีความสามารถ หรือเพราะเป็นคำพูดของอาจารย์
คำแนะนำที่ว่าให้ยอมรับเมื่อเรารู้ด้วยตนเองว่า “สิ่งนี้เป็นกุศล ไม่น่าตำหนิ ผู้มีปัญญาสรรเสริญ และเมื่อนำไปปฏิบัติแล้วย่อมนำไปสู่ประโยชน์และความสุข” มีประโยชน์มากในชีวิต แม้หลังจากที่ผมกลายเป็นอเทวนิยมตั้งแต่สมัยมัธยมต้นแล้วก็ตาม
มีคนอ้างว่ามีการบิดคำแปลให้ดูมี ความหมายแบบเหตุผลนิยม มากขึ้น
ถ้าเป็นจริงก็น่าเสียดาย เพราะผมอยากเชื่อว่า Buddha เป็นคนที่ “ตรัสรู้” แบบนี้จริง ๆ
https://fakebuddhaquotes.com/do-not-believe-in-anything-simply-because-you-have-heard-it/
เห็นด้วยกับส่วนที่บอกว่าอย่ากังวลมากเกินไปว่า “โดนหลอก” หรือ “เรียนรู้อะไรผิดมา”
ผมเรียนรู้ TDD ตอนที่มันกำลังเป็นกระแสไหม? ใช่ ตอนนี้ใช้ TDD ไหม? ไม่ แต่ TDD สอนให้ผมเขียนโค้ดที่ดีขึ้นไหม? ใช่
ภาษาที่ผมไม่ได้ใช้ในงานอีกแล้วก็เหมือนกัน ทุกอย่างสอนอะไรบางอย่างให้เรา
เราจะหา จุดกึ่งกลางที่ดี ไม่ได้ ถ้าไม่เคยเลยเถิดไปทั้งสองด้านเล็กน้อย
ถ้ามีโค้ดอยู่แล้วและต้องการขยายมัน การเขียนเทสต์สักสองสามตัวรอบ ๆ วิธีใช้งานก็สมเหตุสมผล
ถ้ายังไม่มีโค้ด แต่มีโครงสร้างอยู่ในหัว และแยกส่วนที่สร้างก่อนแล้วทดสอบได้ออกมาได้ แบบนั้นก็มีความหมายเช่นกัน
มันไม่ใช่ TDD ในความหมายบริสุทธิ์ แต่ใกล้กับ การพัฒนาที่มีเทสต์ช่วยประกอบ มากกว่า และถือว่าใช้จิตวิญญาณของ TDD อยู่
การเรียนรู้สิ่งที่ไม่ดีก็เป็นส่วนสำคัญมากในการเข้าใจว่าแนวทางไหนดีกว่าหรือแย่กว่า
ไม่ได้หมายความว่า TDD เองไม่ดี แต่ถ้ายึดติดมากเกินไปก็อาจกลายเป็นเรื่องไม่ดีได้
ท้ายที่สุดมันก็สอดคล้องกับความเชื่อทั่วไปที่ว่า “ความผิดพลาดคือหนทางแห่งการเรียนรู้”
แนวทางและหลักการพวกนี้โดยทั่วไปควรรู้ไว้ แต่ปัญหาเกิดขึ้นเมื่อผู้คนรับมันเหมือนศาสนา
ในวงการของเรา พวกยึดอุดมการณ์ เป็นตัวปัญหาจริง ๆ
สั้น เหมาะเจาะ และเข้าใจได้ทันที
เป็นบทความและคำแนะนำที่ดี
สุดท้ายเมื่อช่วงฮันนีมูนจบลง เราจะได้เรียนรู้ว่าไม่ว่าจะใช้ “วิธีที่ถูกต้อง” แบบไหน การเขียนโปรแกรมก็ยังน่าหงุดหงิดและยุ่งเหยิง และต่อให้ไม่ทำตามวิธีนั้นก็ยังสร้างซอฟต์แวร์ที่ยอดเยี่ยมได้
เมื่อเวลาผ่านไป เราจะได้เรียนรู้ “วิธีที่ถูกต้อง” อีกเป็นสิบ ๆ แบบ แล้วนำมาผสมใช้ให้เหมาะกับปัญหา
แต่ในช่วงไม่กี่ปีที่ผ่านมา ดูเหมือนนักพัฒนาจำนวนมากติดอยู่กับ การหมกมุ่นกับวิธีที่ถูกต้อง จนไม่สามารถขยายความรู้และมุมมองได้
ถ้าเป็นจริงก็น่าเศร้า และผมก็ไม่แน่ใจว่าสาเหตุคืออะไร
อาจเป็นเพราะสมาธิที่สั้นลงในยุคนี้ทำให้การขยายความรู้อย่างมีประสิทธิภาพทำได้ยาก และตำแหน่งที่อยู่ตอนนี้ก็สบายเกินไป
หรืออาจเป็นเพราะรางวัลจากการเรียนรู้เฉพาะเฟรมเวิร์กบางตัวนั้นมากเกินไป และแรงจูงใจในการเรียนรู้ความรู้พื้นฐานว่าข้างในทำงานอย่างไรนั้นมีน้อยเกินไป
เลยไม่มีเวลาเรียนรู้บทเรียนจากงานปัจจุบัน และเมื่อบทเรียนนั้นมาถึง ก็มีโอกาสสูงว่าจะย้ายออกไปแล้ว
ขณะเดียวกันก็ไม่มีพื้นที่พอที่จะไม่โฟกัสกับ เทคโนโลยีกระแสใหม่
กระแสแบบนี้ขัดขวางการเติบโตอย่างมาก
คำแนะนำ 1 เซ็นต์ของผมคือแบบนี้ สถานะคือศัตรู ต้องลดสถานะในทุกที่ที่ทำได้
ไม่ใช่แค่สถานะในโค้ด แต่รวมถึงจำนวนสิ่งที่ต้องเก็บไว้ในความจำระยะสั้นเพื่อทำงาน และรายละเอียดเฉพาะโปรเจกต์ที่ต้องจำทั้งหมดด้วย
สถานะคือศัตรู ถ้าสามารถอนุมานจาก first principles ได้ ก็ควรพยายามทำแบบนั้นเสมอ
บางส่วนในนี้เป็นคำแนะนำที่ไปไกลกว่าแค่สำหรับโปรแกรมเมอร์
ข้อแรกเป็นสิ่งที่ทุกคนควรนำไปขบคิด ผู้เขียนและนักเขียนเรียงความจำนวนมากถูกอ่าน ไม่ใช่เพราะเป็นผู้เชี่ยวชาญในหัวข้อนั้น แต่เพราะ เขียนเก่ง
ควรออกไปเดินเล่นด้วย
ควรลองทำงานหลาย ๆ ประเภท และเรียนรู้งานตำแหน่งอื่น ๆ ภายในบริษัทด้วย
โดยเฉพาะในบริษัทใหญ่ งานที่เราทำอยู่อาจเป็นสิ่งที่ต้องถูกแก้ไขซ้ำหรือหาทางเลี่ยงจัดการที่ไหนสักแห่ง และถ้าเราปรับเปลี่ยนมันได้ ทุกคนก็อาจทำงานง่ายขึ้น
ข้อแรกยังเป็นเหตุผลว่าทำไมเราควรตั้งข้อสงสัยกับสิ่งที่เรียนรู้จากบริการแชร์วิดีโออย่าง YouTube ด้วย
ถ้าพูดอย่างน่าเชื่อถือและนำเสนอไอเดียอย่างมืออาชีพ ผู้คนก็จะรับไอเดียนั้นอย่างจริงจัง แม้มันจะมีข้อบกพร่องก็ตาม
ในโลกที่มีการเปิดเผยว่า “นักเขียนเรียงความ” บางคนโดยพื้นฐานแล้วแค่อ่านบทความ Wikipedia กับโพสต์ Reddit ให้ฟัง เราจำเป็นต้องมีท่าทีที่พยายามแยก ความดูน่าเชื่อของการนำเสนอ ออกจากความถูกต้อง
ผมอยากขยายข้อ 10 เพิ่มด้วย การพูดคุยกับผู้คนที่เกี่ยวข้องจะช่วยให้มองเห็นได้ดีขึ้นว่าซอฟต์แวร์หรืองานพัฒนากำลังพยายามแก้ปัญหาอะไร และยังช่วยค้นหาจุดเจ็บปวดที่เราไม่เคยมองเห็นเอง
ยกเว้นกรณีส่วนน้อยมาก ๆ ซอฟต์แวร์ไม่ได้ถูกใช้เพื่อซอฟต์แวร์เอง แต่ใช้เพื่อแก้ปัญหา
มันอาจเคยอ่านคำตอบที่ “ถูก” จากอินเทอร์เน็ตหรือที่ไหนสักแห่งในกระบวนการฝึก แล้วพูดซ้ำอย่างน่าเชื่อถือโดยไม่ได้พิจารณาว่าจริงหรือไม่
ผมชอบ หนังสือดีบัก ที่บทความแนะนำมาก จนซื้อหลายเล่มไปแจก
แจกให้ทั้งเพื่อน อินเทิร์น นักวิทยาศาสตร์ข้อมูล และแม้แต่ผู้บริหาร คนที่อ่านแล้วต่างก็ขอบคุณ
ในนั้นมีเทคนิคง่าย ๆ ดี ๆ หลายอย่างสำหรับแก้ปัญหาในระบบเทคนิคขนาดใหญ่ จึงมีประโยชน์กับแทบทุกคน
อ่านง่ายและน่าสนใจ และยังมี “เรื่องเล่าจากสนามรบ” มากมายที่ช่วยเติมสีสันและบริบทให้คำแนะนำที่อาจแห้งแล้งได้
https://debuggingrules.com/
คำพูดที่ว่า “ผู้คนฟังผมไม่ใช่เพราะผมเป็นโปรแกรมเมอร์ที่เก่ง แต่เพราะผมเป็น นักเขียนที่ดี” ไม่ได้หมายความแค่ว่าเราควรระวังเวลาอ่านเนื้อหาของคนที่เขียนเก่งเท่านั้น แต่ยังเกี่ยวข้องกับวิธีที่เราเข้าหางานของเราด้วย
ถ้าเขียนเก่ง ความสามารถในการรับมือกับผู้อื่นก็มักจะดีขึ้นโดยรวม
สำหรับนักพัฒนาซอฟต์แวร์ การเขียนและการสื่อสารคือแกนหลักของงาน
ถ้าเป็นมือใหม่ แนะนำให้ลองเขียนถึงความยากลำบากที่เจอ การทดลอง และกระบวนการคิดของตัวเอง
ถ้าเป็นไปได้ก็ควรเขียนเอสเซย์ด้วย เพราะจะกลายเป็นทักษะที่มีประโยชน์มากในช่วงหลังของอาชีพ
มีประโยคหนึ่งที่อธิบายให้มือใหม่เข้าใจอย่างถูกต้องได้ยาก นั่นคือ “งานของคุณไม่ใช่การเขียนโค้ด”
เราใช้โค้ดเป็นเครื่องมือในการแก้ปัญหา
โค้ดเป็นวิธีไปให้ถึงเป้าหมาย ไม่ใช่เป้าหมายในตัวมันเอง
ถ้าเขียนโค้ดเพื่อโค้ดเอง ก็จะนำไปสู่ผลลัพธ์ที่ผิด
ต้องโฟกัสที่ การแก้ปัญหา และถ้าไม่แน่ใจว่าโค้ดของตัวเองกำลังแก้ปัญหาอะไร ก็ควรหยุดเขียนโค้ดแล้วหาคำตอบนั้นให้ได้ก่อน
แล้วแต่บริษัท อาจเป็นอีเมลก็ได้
การตอบคำถาม การทำงานร่วมกัน และการมีอิทธิพลต่อทิศทางของทีมและองค์กรอาจรู้สึกเหมือนเป็นงาน แต่การสื่อสารก็เหมือนโค้ด คือเป็นเครื่องมือสำหรับสร้างสิ่งที่มีประโยชน์ ไม่ใช่สิ่งที่มีประโยชน์ในตัวมันเอง
โค้ดส่วนใหญ่ แม้แต่โค้ดที่เขียนเป็น “โค้ดเพื่อโค้ด” ก็ถือว่าแก้ปัญหาบางอย่างอยู่
โปรแกรมเมอร์จำนวนมากก็รู้อย่างน้อยโดยไม่รู้ตัว จึงเขียนโค้ดแบบนั้น
ปัญหาที่แท้จริงคือคนอื่น ๆ เช่นคนฝั่งธุรกิจที่ใส่สูท อยากให้โค้ดนั้นแก้ ปัญหาอีกแบบหนึ่ง
เพียงแต่โค้ดนั้นต้องเป็น โค้ดที่ถูกต้อง
โดยทั่วไปกว่านั้น อธิบายได้ว่าเป็น “การใช้ระบบซอฟต์แวร์เพื่อแก้ปัญหาทางธุรกิจ”
ถ้าบอกจูเนียร์แบบนี้ จะช่วยให้เขาโฟกัสกับความต้องการทางธุรกิจ และสามารถตัดสินคำพูดของ MBA ผู้จัดการ หรือ PM อย่างมีวิจารณญาณเพื่อทำสิ่งที่ถูกต้องได้
แต่การมีซอฟต์แวร์ไว้ขายให้ VC นั้นมีคุณค่าในตัวเอง
ดังนั้นบางครั้งคุณก็ได้รับเงินมาเพื่อ เขียนโค้ด จริง ๆ