Monthly Archives: September 2012

ช่องน้อยที่ไม่พอตัว

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

คุณเคยคิดแบบนี้ระหว่างพัฒนาโปรแกรมอะไรซักอย่างไหม

  1. จะเอาไปทำไมว่ะ ไม่เห็นมีประโยชน์
  2. ทำไมอยากได้อะไรยุ่งยากจัง มันซับซ้อนเกินไปหรือเปล่า ทำง่ายๆไม่ได้หรือไง
  3. โอ๊ย ขอมาแบบนี้ระบบที่ช้าอยู่แล้วมันก็ยิ่งช้าไปอีกสิ
  4. ฯลฯ

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

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

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

สิ่งที่ควรทำเมื่อเข้าร่วมประชุม

  1. เตรียมศึกษาสิ่งที่จะประชุมไปก่อน จะได้เห็นภาพและตอบปัญหาได้
  2. พยายามควบคุมการประชุมให้อยู่ในประเด็น ต้องรู้ว่ามาคุยกันเรื่องอะไรครับ อย่าให้ออกทะเลกันมาก เสียเวลาเปล่า
  3. แสดงความคิดเห็นในด้านเทคนิค เช่น ความยากง่าย ผลกระทบต่อระบบ
  4. รับฟังความเห็นฝ่ายอื่น ให้เกียรติเค้าเพราะในฐานะที่เค้ามีการติดต่อกับผู้ใช้งานหรือลูกค้ามากกว่าเรา
  5. วิเคราะห์สิ่งที่กำลังจะตัดสินใจทำ ว่ามันแก้ปัญหาตรงความต้องการจริงหรือเปล่า มันแก้ปัญหาแบบขี่ช้างจับตั๊กแตนหรือเปล่า มีวิธีการที่ง่ายกว่าแต่แก้ปัญหาได้ตรงจุดมากกว่าหรือเปล่า

สิ่งที่จะได้รับเมื่อเราเริ่มเข้าร่วมประชุม

  1. ความรู้สึกสนุกมากขึ้นกับสิ่งที่จะทำ เพราะเราเห็นความสำคัญและที่มาของมัน
  2. สิ่งที่จะทำผ่านมาคัดกรองปัญหาด้านเทคนิคเบื้องต้นมาแล้ว ทำให้ระหว่างการพัฒนาปัญหาจะลดลง
  3. ลดช่องว่างการสื่อสารระหว่างเราและฝ่ายอื่นๆ ต่อจากนี้มีอะไรขาดตกบกพร่องจะคุยหาทางแก้ปัญหากันได้ง่ายขึ้น

ปัญหาที่จะพบเมื่อเข้าร่วมประชุม

  1. คิดไม่ทัน บางครั้งก็คิดไม่ทันหรอกครับว่าสิ่งที่จะทำมันอยากแค่ไหน หรือว่ามันมีผลกระทบแค่ไหน
  2. พูดไม่ทัน พอคิดไม่ทันมันก็ส่งผลให้เราพูดไม่ทันแหละครับ
  3. ไม่มีใครฟัง พอมีโอกาสพูดแล้ว ก็รู้สึกว่าส่ิงที่เราพูดไม่มีใครฟังเลย

ทั้งสามสิ่งนี้ต้องใช้การฝึกฝนและประสบการณ์เท่านั้นครับ อย่าคาดหวังว่าเราจะทำได้เพอร์เฟ็คตั้งแต่ต้น แต่ถ้าเราไม่เริ่ม เราก็จะไม่มีวันทำได้

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

เป้าหมายที่เปลี่ยนไป

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

ช่วงแรกเริ่มเขียนตอนปี 1 เทอม 2 รู้สึกสนุกดี และรู้สึกว่าตัวเองทำได้ ตอนนั้นไม่มีเป้าหมายอะไรชัดเจน

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

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

ความคาดหวังในช่วงหางาน และการทำงานช่วงแรกคือ อยากรู้ว่าจะเขียนโปรแกรมใหญ่ๆ ตั้งแต่เริ่มจนจบได้ยังไง เพราะสมัยเรียนมีแต่ทำโปรเจ็คเล็กๆ เข้าทำงานกับ Throughwave ตั้งใจว่าจะศึกษาและใช้งาน Design Patterns ให้แตกฉาน ได้อ่าน The Pragmatic Programmer ทำให้เริ่มสนใจ Clean code(1)(2) และ Polyglot Programming เริ่มสนใจ Functional Programming และ Immutability จำไม่ได้ว่าเริ่มสนใจ Agile และ TDD ได้ยังไง แต่จำได้ว่า เป้าหมายในตอนนั้นคือ อยากเขียนโปรแกรมให้มีความสุขเพราะอยากใช้ชีวิตนี้ไปกับมัน ซึ่งความสุขนั้นจะเกิดจากการรวมกันของ การเขียนโปรแกรมเสร็จทันเวลาและการได้โปรแกรมที่มีความมั่นใจว่าที่ทำไปมันไม่พัง

พอย้ายมาสิงคโปร์ มาด้วยความอยากหัด Ruby เพื่อเติม programming paradigm ให้ตัวเอง แต่โดนจับมาทำ PHP แต่ก็เลยถือโอกาสเก็บตักตัวความรู้ Front-end ที่ยังขาดอยู่ เพราะยังไงก็คิดว่าถ้าเราจะไปต่อได้ต้องพอทำได้ทั้ง stack

พอย้ายงาน ได้มาทำ Rails และ Agile เต็มตัวอย่างที่คาดหวังไว้ก่อนจะมาจากไทย เก็บตักตวงเรื่อง Agile จนรู้สึกว่าเริ่มอิ่มตัว รู้ว่าควรจะใช้อะไรเมื่อไหร่ ส่วน Ruby และ Rails ก็ทำได้ในระดับที่กลายเป็นอาวุธที่ถนัดที่สุด แต่ก็มีความตะขิดตะขวงใจในทางที่เลือกในการแก้ปัญหาบางอย่างของ community และตัว platform ที่รู้สึกว่ามันเป็นแค่การหลีกเลี่ยงปัญหา

ตอนนี้เวลาว่างเริ่มหันมาหัด Clojure พยายามจะเติมอีก paradigm ให้ตัวเอง หลังจากที่ล้มเหลวกับ Haskell และไปได้ครึ่งๆ กลางๆ กับ Scala ก็ไม่รู้จะไปได้ซักกี่น้ำ โดยความคาดหวังในปัจจุบัน คือ อยากหาวิธีการเขียนโปรแกรมที่ทำให้ความซับซ้อนของโปรแกรม เพิ่มขึ้นในแบบกราฟเส้นตรงกับปริมาณฟีเจอร์ที่เพิ่มขึ้นของระบบ ไม่ใช่ความซับซ้อนเพิ่มขึ้นเป็นแบบเอ็กซ์โพเนนเชียลอย่างที่พบในงานที่เคยทำผ่านมาทั้งหมด

ตลอด 7 ปีที่ผ่านมาถือเป็นการเดินทางที่สนุกทีเดียว

แนะนำ Janus ชุด plug-in สำหรับ vim

ช่วงนี้ที่บริษัท pair กันน้อยลง จากที่เคยใช้ RubyMine เป็น IDE หลัก ก็ได้กลับมาใช้ VIM อีกครั้ง จริงๆ ก็ติดใจ RubyMine อยู่เพราะมันมีฟีเจอร์อะไรหลายๆ อย่างที่คิดว่าถ้าเป็น text editor ทั่วไป ที่ไม่ได้ทำมาสำหรับรองรับ Ruby และ Rails โดยตรง ไม่น่าจะทำได้ แล้วก็รู้สึกว่าไม่หน่วงๆ เหมือน Eclipse ด้วย แต่ด้วยความที่ช่วงนี้ iMac แรมหมดแล้วอืดบ่อยๆ (แต่ก็พบว่าเปลี่ยนไปใช้ VIM ก็ไม่ช่วย) และนั่งดู screencast DestroyAllSoftware เห็นคนทำมันใช้ VIM แล้วเท่ดี เลยอยากกลับมาใช้ VIM อีกครั้ง พอกลับมาใช้ VIM และได้ศึกษาเจ้าชุด plug-in สำเร็จที่ชื่อว่า janus (ที่ลงไว้นานแล้ว รู้จักมาจากไหนก็ไม่รู้) จริงๆ จังๆ ก็รู้สึกว่ามันทำได้เกือบทุกฟีเจอร์ที่ใช้ใน RubyMine เลย

ข้อดีของ janus

  • ติดตั้งโคตรง่าย แค่รันคำสั่ง $ curl -Lo- https://bit.ly/janus-bootstrap | bash แล้วก็รอไป เสร็จแล้วก็พร้อมใช้เลย
  • มันรวม plug-in ที่ต้องใช้เอาไว้เกือบหมดแล้ว ตอนนี้ต้องลงเพิ่มอีกแค่ 2 อัน แถมเวลาจะอัพเดต plug-in ก็แค่รันคำสั่ง rake อย่างเดียวจบ
  • Customize ง่าย เพิ่ม vimrc จากที่มันกำหนดมาให้ ลงใน vimrc.before และ vimrc.after และลง plug-in เพิ่มก็แค่โหลด plug-in ที่ต้องการไปวางไว้ใน folder ~/.janus จะ disable plugin ไหนก็ทำได้

ทั้งหมดนี้ทำให้เวลาในการตระเตรียมและดูแลรักษาน้อยมาก มีเวลาเอาไปหัดพวกคำสั่งของ plug-in แทน ซึ่ง plug-in ที่ผมใช้บ่อยๆ ก็มีดังนี้

  • Rails ซึ่งทำทุกอย่าง ตั้งแต่ช่วยเปิดไฟล์ง่ายๆ, สลับระหว่าง test และ production code เร็วๆ, รัน test, browse code จาก class name, …
  • snipmate อันนี้จริงๆ ยังจำได้ไม่เยอะเท่าไหร่ ที่ใช้บ่อยๆ ตอนนี้ก็เอาไว้ เขียน print เร็วๆ
  • Ack คล้ายพวก find ทั้ง project
  • Ctrl-P เปิดไฟล์ตามที่เราพิมพ์ ฟีเจอร์หลักของ text editor ยุคปัจจุบัน (แต่มันไม่ฉลาดเท่าของ RubyMine)
  • Git ใช้พวก blame ก็สะดวกดี
  • NERDTree เอาไว้เวลาจำชื่อไฟล์ไม่ได้

กลับมาใช้ VIM รอบนี้ ก็รู้หลักสำคัญอีกอย่าง ที่ต้องปรับตัว คือ เปลี่ยนจากการใช้ tab ที่ติดมาจาก editor อื่นๆ มาใช้ buffer แทน ซึ่งพอเปลี่ยนมาใช้ buffer แล้วก็รู้สึกว่าเป็นธรรมชาติขึ้นเยอะ ไม่เหมือนตอนใช้ tab ที่มีอะไรแปลกๆ เช่น NERDTree แสดงอยู่บนแค่ tab เดียว

ใครใช้ VIM อยู่ก็ลองแวะไปดูเจ้า janus นี้หน่อยละกันนะครับ สะดวกดี ผมเชื่อว่าอีกหลายเจ้าที่ทำชุดรวม plug-in แบบนี้ เล่นอะไร เป็นยังไง ก็มาเล่าสู่กันฟังด้วยละกันครับ