เรื่องเล่า...จากเดี่ยวโปรแกรมเมอร์ ตอนที่ 1

ที่มา link…

ผมทำงาน .NET มาตั้งแต่ปี 2003 มักต้องเจออะไรใหม่ๆให้ขบคิดเสมอว่าจะทำอย่างไงกับปัญหาที่เกิดขึ้นโดยส่วนมากก็จะ Google ไปเรื่อย มี Website อยู่ไม่กี่ Website ที่ Bookmark ไว้เพื่อคอยแวะเวียนเข้าไปดูว่ามีอะไรอัพเดตเกี่ยวกับวงการ .NET Developer บ้าง ซึ่งหนึ่งในนั้นก็คือ coredeveloper มีบทความๆหนึ่งที่ผมเพิ่งได้อ่านเมื่อต้นๆปีที่แล้วที่อ่านแล้วผมถึงกับสะอึกแล้วตั้งคำถามกับตัวเองอยุ่หลายวันในหลายๆเรื่อง ช่วงหลังๆมานี้เท่าที่ดูไม่ค่อยมีการ Update ใน Web coredeveloper เลยจึงทำการ Copy เนื้อหาจาก Blog ที่คุณ นันคอม แปลมาจากคุณ Matt Gullett มาเก็บไว้ใน Blog ของตัวเองเพราะอยากเก็บไว้ค่อยเตือนใจตัวเองไม่ให้หลงทาง

เกิ๊นนำซะยาวมาเข้าเรื่องกันดีกว่า The Standalone Programmer: Tips from the trenches

--- เริ่มละนะ ---

ก่อนจะเข้าเรื่อง

ต้องขอบอกก่อนว่า ผู้เขียนได้อ่านหนังสือเกี่ยวกับ Project Management, SDLC, Code Quality และอะไรอีกมากมายหลายเล่ม แต่ส่วนใหญ่แล้ว ความรู้จากหนังสือเหล่านั้นก็มักจะประยุกต์ใช้กับกรณีที่ "เดี่ยว" ทั้งหลาย ต้องประสพชะตากรรมกับโปรเจคบิ๊กเบิ้มไม่ได้ เพราะเดี๋ยวก้อแนะนำว่าต้องใช้โปรแกรมเมอร์หลายคนมั่งละ ต้องมี QA มั่งละ...

ตอนนี้ผู้เขียนได้ทำงานกับบริษัทปัจจุบัน (เมื่อปี 2002) นี่มา 3 ปีดีดักได้แล้ว นี่ยังนับว่าโชคดีที่เจ้านายยังมีพื้นโปรแกรมมิ่งมาบ้าง ไม่อย่างนั้นคงจะลำบากกว่านี้ และในเมื่อว่าไม่มีคนช่วย ผู้เขียนจึงต้องคอยพัฒนาตัวเองเพื่อทำงานในหน้าที่ให้ได้สำเร็จลุล่วง บทความนี้จึงกลั่นมาจากประสบการณ์ทำงานของผู้เขียน ที่ได้พยายามหาทางที่ดีที่สุด ที่จะมาใช้แก้ปัญหาต่างๆ ที่เกิดขึ้น ซึ่งแน่นอนว่า อาจจะไม่ใช่ทางที่ดีที่สุด หรือแม้แต่เป็นทางที่ถูกต้องเลยก็ได้...แต่สิ่งที่ผู้เขียนหวังว่าจะได้รับ คือการแลกเปลี่ยนความคิด มากกว่า

บทความนี้แบ่งเป็นสองส่วน คือ Non-Technical และ Technical ซึ่งเป็น "เรื่องเล่า" จากทั้งสองมุมมองในชีวิตโปรแกรมเมอร์คนหนึ่ง ซึ่งแน่นอนว่า ก็ต้องมีมุมที่ไม่มีเรื่อง Technical บ้างละ...

เรื่องทั่วไป ไม่เกี่ยวกะด้านเทคนิค

ตั้งเป้าหมายให้กับตัวเอง

เป้าหมาย ไม่ว่าจะระยะสั้นหรือยาว ก็ดีทั้งนั้น และนี่คือสิ่งที่สำคัญที่สุด ที่ผู้เขียนทำเป็นประจำ การมีเป้าหมาย จะทำให้เราค้นพบตัวตน และหนทางในวันข้างหน้าในสายอาชีพของเราได้ แล้วยังช่วยให้เราไม่ไขว้เขวจากงานของเรา แอบเข้า JobDb ไป Search งานใหม่อีกด้วย

การตั้งเป้าหมาย ควรจะเป็นเป้าหมายที่ เป้นไปได้ และมีระยะเวลาที่แน่นอน เช่น

• เดือนนี้จะต้องอ่านหนังสือให้ได้ 1 เล่ม
• ปีนี้จะหัดภาษาใหม่ 1 ภาษา
• จะปล่อย Shareware มาขาย 1 ตัวในปีนี้

เป้าหมายไม่ใช่กฏหมาย เราสามารถเปลี่ยนแปลงแก้ไขมันได้ แต่ไม่ใช่ว่านึกจะเปลี่ยนก็เปลี่ยนละ ก่อนที่จะเปลี่ยนแปลงอะไร ลองมาสำรวจดูว่า อะไรทำให้เราบรรลุเป้าหมายนั้นไม่ได้ เป็นเพราะเวลาน้อยไปหรือเปล่า? ถ้าใช่ ครั้งต่อไปเราก็จะประเมิณถูกว่า เราต้องใช้เวลามากกว่านี้ ในการทำอะไรคล้ายๆ กัน ที่นี้พอรู้แล้วก้อต้องปรับเงื่อนเวลาให้ยาวออกสักหน่อย เพื่อให้ถึงเป้าหมายได้

แต่ที่เป็นไปได้อีกอย่าง คือ ถ้าเป้าหมายมันเกินจะเอื้อม อย่าง ปีนี้ จะหาเงินให้ได้ 7 หมื่นสามพันล้าน ซึ่งก็คงมีไม่กี่คนที่ทำได้ (ผู้แปล: เจอแล้วคนนึง) เราก็ต้องมานั่งดู แล้วย่อยเป้าหมายให้มันเล็กลงหน่อย ตามหลัก Divide-and-Conquer ที่เราใช้กันบ่อยๆ เวลาเขียนโปรแกรม แต่ต้องย่อยให้มันเป็นทางที่นำไปสู้เป้าหมายที่แท้จริงที่เราตั้งไว้ตอนแรกได้ด้วย อย่างเช่น ปีนี้เราจะหาให้ได้ 3 พันก่อน แล้วปีต่อไปอีก 7 หมื่น แล้วปีที่สามอีกล้านนึง เป็นต้น

อย่างที่เรารู้กันดีนั่นแหละ ว่าการเอาชนะตัวเองมันยากขนาดไหน การตั้งเป้าหมายให้ตัวเองทำตามก็ยากพอกัน เพราะเราจะต้องมาเอาชนะตัวเอง ไม่ให้เล่นเกมบ้าง ไม่ให้นอนตีพุงบ้าง ซึ่งก็อาจจะต้องอาศัยการเสียสละ เพื่อให้เราไปถึงเป้าหมายได้บ้าง เอาแต่สบายอย่างเดียว ก็คงจะย่ำอยู่กะที่ และเป้าหมายที่ตั้งไว้ซะดิบดีก้อจะเลื่อนไปเรื่อยๆ เพราะอ้างกับตัวเองว่าไม่มีเวลา จริงไหมละ?

อ่านให้ได้มากกว่าปีละ 3 บรรทัด

ผู้เขียนแนะนำว่า อ่าน อ่าน อ่าน อ่านมันเข้าไป คนไทยเนี่ย อ่านกันปีละแค่ 3 บรรทัดโดยเฉลี่ย (แน่ละ ไม่รวม Blog ไม่รวม Hi5 แน่ๆ) ทางหนึ่งในการได้ความรู้แบบไม่ต้องย่อยเลยก็คือการอ่านเนี่ยแหละ มันสำคัญมากกับความสำเร็จในระยะยาว เราไม่จำเป็นจะต้องรู้แค่เรื่องเดียวเสมอไป วันนึงเราอาจจะต้องไปทำงานที่ใช้ความรู้หลายๆ อย่างประกอบกันก็ได้

โลกนี้ดีอย่างที่มักจะมีคนเก่งกว่าเราเสมอ และคนเก่งๆ ก็มักจะชอบแต่งหนังสือ เขียน Blog ให้เราอ่าน เราก็เลยสามารถซึมซับความเก่งเขามาได้ โดยไม่ต้องออกแรงไปเสาะหาความรู้โดยการวิจัยคนคว้าเอง ซึ่งนับว่าเป็นเรื่องที่ดีเลยละ

ในช่วงปีแรกๆ ของการทำงาน ผู้เขียนไม่เคยคิดเลยที่จะอ่านหนังสือด้านโปรแกรมมิ่ง ผู้เขียนตะบี้ตะบันเขียน (โปรแกรม) อย่างเดียว ติดตรงไหนก็ไปหาโค๊ดมาอ่าน แน่นอนว่า มันก็ใช้ได้ในชั่วระยะเวลาหนึ่ง แต่พอทำไปซักพัก มันก้อจะต้องมีบ้างหละ ที่เราไปติดเข้ากับปัญหาที่ไม่ค่อยจะมีคนเจอ หรือไม่มีคนมาเขียนโค๊ดให้อ่าน ถึงตรงนี้ ผู้เขียนจึงคิดได้ว่า เอ้อ หนังสือเนี่ยก็สำคัญ ทิ้งไม่ได้

หลังจากคิดได้ ผู้เขียนก็ทำผิดใหญ่หลวงอีกครั้ง โดยการตะบี้ตะบันอ่านมันแต่หนังสือด้านโปรแกรมมิ่ง/โค๊ดดิ้ง อย่างน้อยมันก็ช่วยให้ผู้เขียนรู้ถึงเรื่องของหลักการแก้ปัญหา ด้านอัลกอริธึ่มต่างๆ ที่เอามาประยุกต์ใช้ได้กับงานที่ทำ แต่นั่นก็ยังไม่พอ เพราะเรื่อง GUI, Usability ที่หลายคนมองข้ามไป แม้กระทั่งเรื่อง Database ก็สำคัญไม่แพ้กัน การอ่านทำให้เราเห็นโลกที่กว้างขึ้น มีกรอบความคิดที่กว้างขึ้น ก็ย่อมทำให้เราทำงานได้ดีกว่าเดิม และหางานใหม่ได้ง่ายกว่าเดิมด้วยเหมือนกัน

อย่ามองข้ามหนังสือด้าน Marketing หรือ Branding ละ อย่าลืมว่า เราไม่ได้อยู่คนเดียวในบริษัท คงต้องมีบ้างที่เราต้องทำงานร่วมกับคนกลุ่มนี้ ถ้าเราเข้าใจว่า เขาต้องการอะไร เราก้อจะทำงานร่วมกันได้ราบรื่นขึ้น และเข้าใจกันมากขึ้น ผิดพลาดน้อยลงใช่ไหมละ ต้องเข้าใจหน่อยว่า จะให้คน Marketing มาเข้าใจเรื่องโปรแกรมมิ่ง ก็คงจะยากอยู่เหมือนกัน

ออกมาเจอชาวบ้านชาวเมืองเขาบ้าง

ตอนช่วงแรกๆ ที่ผู้เขียนเริ่มทำงานใหม่ๆ ผู้เขียนก็จะขลุกอยู่แต่ใน Cubicle ของตัวเองนั่งก้มหน้าก้มตาโค๊ดมันทั้งวันนั่นแหละ นอกจากจะไปกินข้าว กับเข้าห้องน้่ำเท่านั้น นี่เป็นนิสัยที่ผิดอย่างมาก เพราะว่า....

• ชาวบ้านเขาก้อจะคิดว่า ไอ้นี่มันสังคมแปลกแยก ถ้าเป็นโปรแกรมที่ใช้ภายใน คนใช้เขาก็ไม่กล้ามาบอกปัญหา หรือคุยปัญหากับเรา แล้วเผลอๆ อาจจะพาลคิดไปว่าเราหยิ่งอีก
• การทำอะไรติดต่อกันนานๆ มันก้อจะ หมกหมุ่น เหมือนติดอยู่ใน Infinite Loop ไม่เชื่อลองลุกออกไปเดิน เล่นบ้าง แล้วกลับมาสิ บางทีอาจจะคิดทางออกหรือโค๊ดดีๆ ออกก็ได้
  (ผู้แปล: อันนี้จริงมากๆ ครับ นอกจากเวลาเรานั่งยาวๆ แล้วจะเสี่ยงต่อ Economy Class Syndrome หรือเลือดในหลอดเลือดดำที่ขาแข็งตัวแล้วเนี่ย บางทีฝืนนั่งไปมันก้อคิดไม่ออกอยู่ดี แต่ถ้าผู้แปลได้เดินไปดูนู่นดูนี่ เปลี่ยนบรรยากาศ ไปเมาท์กับคนข้างโต๊ะบ้าง พอกลับมา หรือแม้กระทั่งระหว่างเดินไป มันก้อมักจะคิดออกได้อย่างง่ายดาย โดยเฉพาะอย่างยิ่ง เวลาไปปลดทุกข์ในห้องน้ำเนี่ย หัวแล่นดีนักเชียว)

ข้อดีของการไปเจอโลกกว้างเนี่ย เราก็จะได้สัมผัสกับผู้ใช้จริงๆ ว่าเวลาเขาทำงาน เขาทำงานยังไง ใช้งานยังไง ไม่ใช่ว่านั่งเทียนของเราคนเดียว แล้วคิดไปเองว่าชาวบ้านเขาจะต้องใช้อะไรบ้าง ต้องทำอะไรกับโปรแกรมเราบ้าง

การประชุมก็อาจไม่แย่เสมอไป

จำไว้เลยว่า ถ้ามีองค์ประกอบเหล่านี้

• ไร้ Agenda : ถ้าคนเรียกประชุมเอง มันยังไม่รู้จะพูดอะไรบ้าง ก้อหยิบหมอนมาเลยดีกว่า
• ยาวข้ามวัน : อันนี้ต้องมีคนพูดมาก หรือไม่ก็มีเรื่องจะคุยมากไป (การประชุมที่มันยาวกว่า 1 ชั่วโมงนี่ก้อถือว่ายาวเกินไปแล้ว)
• คนเข้าเยอะ
• มีแต่คนที่ไม่รู้เรื่อง

จงหลีกเลี่ยงการประชุมแบบนี้ [ผู้แปล: เห็นด้วย!!!!] เพราะมันไม่ก่อให้เกิดสาระอะไรกับชีวิต แต่การเข้าร่วมประชุมก็จะช่วยให้...

• ให้เราฝึกพูดเรื่อง Technical ยากๆ ให้คน Marketing ฟัง ยิ่งพูดบ่อย ก้อยิ่งคล่อง ว่างั้น
• เข้าใจมากขึ้น ว่าคนอื่นๆ ที่เข้าร่วมประชุม เขามีลักษณะความคิดยังไง
• สุดท้าย ช่วยฝึกการจด และย่อยข้อมูล จากการประชุม [ผู้แปล: ลองหาหนังสือเรื่อง MindMaps มาอ่านดูครับ จะช่วยให้คุณจดได้ดีขึ้น และช่วยให้คุณจำมันได้ง่ายขึ้น โดยเลียนแบบการทำงานของสมองเลยทีเดียว ยกเว้นแต่ว่า คุณสามารถสรุปอะไรๆ ในหัวเองได้อยู่แล้ว ก็ไม่ต้อง]

ทีนี้ ถ้าต้องเป็นฝ่ายเรียกประชุมบ้าง ก็ต้อง

• วางโครงคร่าวๆ ว่าจะพูดอะไร.. คือต้องมี Agenda นั่นแหละ
• ลองพูดให้คนที่ไม่รู้เรื่องอะไรกะเราเลยฟังดู จะได้เช็คว่า เราเตรียมมาดีหรือยัง พูดให้เขาเข้าใจได้ไหม
• กำหนดเวลาให้แน่นอน
• อย่าไปมั่วเชิญใครไม่รู้มา เอาเฉพาะคนที่เขาเกี่ยวข้องจริงๆ