เส้นทางสู่ Developer ระดับโลก (มั้ง)

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

และในฐานะที่เป็น Developer ผมขอกล่าวถึงเฉพาะมุมมองของ Devloper ดังนั้นตัดส่วน Business ทิ้งไปเลย

1. อยู่กับ Techonology ที่ Project ใช้อย่าง Expert

เป็น Developer ที่อาจจะเก่งหรือทำงานได้ในระดับหนึ่งของ Project ที่ตัวเองนั้นทำอยู่ อย่างน้อยควรจะต้องรู้ว่า Technology ที่ตัวเองใช้อยู่มี Best Practices อะไร รวมถึงรู้ว่ามี Trap อะไร อาจจะได้มีโอกาสศึกษาอะไรใหม่ๆบ้างถ้าทาง Project นั้นต้องการใช้

กลุ่มนี้ คุณๆอาจจะใช้ Technology ล่าสุดในวันนี้เพราะทีมหรือ Project ใช้อยู่ แต่จริงๆไม่ควรรอทีมนะ ไม่งั้นผ่านไป 2-3 ปีแล้วยังอยู่แต่กับ Technology นี้ก็จะ Outdate ได้ง่ายๆ

2. ติดตามข่าวสาร IT หรือ Tech อย่างสม่ำเสมอ

เป็น Developer ที่รู้ว่าแต่ละ Products หรือว่า Tools หรือ Frameworks มีอะไรออกใหม่บ้างทำให้มี Idea ในการที่จะพัฒนา Project ที่ตัวเองทำอยู่เพราะได้รับ Input ใหม่ๆ

กลุ่มนี้อาจจะต้องระวังกับดักที่ว่าเราดันสนใจแต่ข่าว Consumer เช่น Apple ออก Product อะไรใหม่, Android ออกรุ่นใหม่ หรือ Program/App นู่นนี่มี Update อะไรบ้างเพราะปัจจุบันนี้ข่าวพวกนี้ใครๆเค้าก็รู้กันแล้วครับ

ผมมองว่าระดับนี้ต้องติดตามข่าวสำหรับ Software Development นะครับ

3. ลองใช้ Tech ต่างๆที่ใหม่ๆที่ตัวเองสนใจ

เป็น Developer ที่นอกจากจะติดตามข่าวสารต่างๆแล้ว ยังใช้เวลาทำการลงมือศึกษาเองด้วย อาจจะเป็นลักษณะเอามาทำ Prototype ของ Project ที่ตัวเองทำอยู่ หรือเป็น Side Project แบบทำเล่นๆ (หรือทำขายจริงจัง) ผมว่าอยากให้ทุกๆคนอย่างน้อยๆมาอยู่จุดๆนี้กันครับ

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

4. Contribute ให้กับ Community ต่างๆ

เป็น Developer ที่สามารถเข้าไปมีบทบาทในชุมชนต่างๆ เช่นงาน Event หรือการมีส่วนร่วมในการพัฒนา Open Source ผมเห็นปัจจุบันมีเยอะมากๆ น่าดีใจจริง คนไทยเทพพพพพ

ผมอยากเห็น Developer ไทยมาถึงจุดๆนี้กันเยอะๆ (รวมถึงตัวผมเองด้วย)

5. สร้าง Community ใหม่ๆเอง!

เป็น Developer ที่เป็นคนคิด Community ต่างๆได้โดยเฉพาะ Framework ที่ให้คนอื่นมาช่วย Contribute และได้รับการยอมรับจาก Community

กลุ่มนี้ผมไม่สามารถ Comment ได้ครับเพราะยังไม่ถึงขั้น (5555) แต่ผมว่านี่แหละ Developer ระดับโลก!!!!!

 

ป.ล. บทความนี้เป็นความเห็นส่วนตัวล้วนๆและเอาไว้เตือนใจตัวเองครับ 🙂

Advertisements

Fear Driven Development

จะเกิดอะไรขึ้นถ้า Developer ต้องทำงานอยู่ภายใต้สิ่งแวดล้อมที่มีความกลัวครอบงำ…

ทีมที่ทำงานด้วย Fear Driven Development (FDD) นั้นจะทำให้ Developer นั้นรู้สึกว่า

  • กลัวที่จะทำผิด
  • ไม่กล้าแก้ Code
  • ไม่กล้า Refactor
  • ไม่กล้า Commit หรือ Push Code
  • ไม่กล้าเปลี่ยน Design
  • ไม่กล้าท้าทาย UI/UX หรือ Product เพราะกลัวได้งานเพิ่ม
  • ไม่กล้ารับปาก เพราะกลัวทำไม่ได้
  • ไม่กล้าออกความเห็น เพราะกลัวต้องรับผิดชอบกับ Idea ตัวเอง
  • ไม่กล้าเปลี่ยน Tools หรือ Framework
  • กลัวว่า Software นั้นจะมี BUG ซึ่งเห็นเหตุผลให้เกิด Process ต่างๆมากมาย
  • และสุดท้ายทำให้ Developer ใช้เวลาไปกับงาน Admin/Process มากกว่าการเขียน Code….

ความกลัวและไม่กล้าต่างๆเหล่านี้ทำให้ Project ไปได้ช้าลงแน่นอน รวมถึงทำให้เกิด Over-Engineer (การ Design Software เกิด Use case ที่จะเกิดขึ้นจริง) และกลัวการ Estimate ซึ่งเป็นการบอกเวลาว่า Project นี้จะเสร็จตอนไหนกับเหล่าท่านๆผู้บริหารระดับสูงทั้งหลาย จึงทำให้การ Estimate (ประเมิณ) กลายมาเป็นการลงรายละเอียดซึ่งใช้เวลาเยอะมากจนกว่าจะได้ตัวเลขออกมาก

วัฒนธรรมกลัวตกงาน

เป็นลักษณะหนึ่งของ FDD ซึ่งเกิดจากทีมใช้งาน Developer อย่างหนักและมีการกดดันกันว่าถ้ามีปัญหากับโปรเจคอาจจะโดนไล่ออกได้ ซึ่งการทำแบบนี้ไม่อาจจะทำให้ทีมนั้นมี Productivity ที่ดีได้ รวมทั้งยังขาด Innovation ด้วยรวมถึงทำให้เกิดความกดดันต่างๆและทำให้อัตรา Turn-Over สูงขึ้น ซึ่งในทีมที่มีวัฒนธรรมแบบนี้ส่วนใหญ่ก็จะมีการยกย่องคนที่เรียกว่า Hero(Hero Driven Development) ซึ่งเป็นคนที่ทำให้แต่ละ Release นั้นผ่านไปได้จะได้รับการยกย่องและสุดท้ายก็จะกลายเป็นว่าทีมนั้นต้องการ Hero ตลอดเวลานี่แหละคือปัญหา!

รวมถึงวัฒนธรรมการ Blame เช่นเมื่อเวลามีปัญหาเกิดขึ้นก็หาคนทำผิดแทนที่จะช่วยกันแก้ปัญหาให้ User…

วัฒนธรรมกลัวการแก้ Code

อีกสิ่งที่น่ากลัวของการพัฒนา Software ซึ่งก็คือ Developer ไม่กล้าแก้ไข Code ซึ่งอาจจะเป็นเพราะว่า Code นั้นเก่ามากๆซึ่งปกติน่าจะเกิดจากการที่ไม่เข้าใจ Code ชุดนั้นมากกว่า ลักษณะของ Code ประเภทนี้คือมันก็ work ดีเกือบทุก case แต่ถ้าจะต้องแก้ Developer ก็จะกลัวจะเกิดผลที่คาดไม่ถึง รวมทั้งเกิด Bug ต่างๆ และที่เลวร้ายไปกว่านั้นคือไม่กล้าแก้ Code ของตัวเอง!

สุดท้าย

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

ถ้า Developer ไม่กล้าแก้ Code แล้วใครจะกล้าแก้ล่ะ???

เรียบเรียงจาก:

http://www.hanselman.com/blog/FearDrivenDevelopmentFDD.aspx

 

Microsoft CEO – Satya ทำงานยังไง แล้วพวกเราล่ะ?

ทาง Wall Street Journal ได้ทำ clip 2-3 นาที ซึ่งเป็นการสัมภาษณ์คุณ Satya – CEO ของ Microsoft เกี่ยวกับวิธิการทำงานของเค้าเป็นการถามตอบสั้นๆที่ทำให้รู้จักตัวเค้ามากขึ้น

สิ่งที่ผมดูแล้วชอบเป็นพิเศษคือคำถามที่ว่า

How do you run a meeting? (คุณดำเนินการประชุมยังไง) ใน นาที 1.05

คุณ Satya ตอบได้กระชับมากว่า
Listen More,  Talk Less and be decisive when the time comes” – ฟังเยอะ พูดน้อยแเละเด็ดขาดเมื่อถึงเวลา

ผมรู้สึกถึงพลังของผู้นำที่มีพื้นที่ให้พนักงานได้มีโอกาสแสดงความคิดเห็น มากกว่ารอคำสั่งจาก Leader ซึ่งผมว่าดีมาก

อย่างไรก็ตามสำหรับ Engineer อย่างพวกเราผมว่า

Talk Less, Code more, Show working software”  😉

เห็นด้วยมั้ยครับ…

Hero Driven Development

วันนี้ผมจะเล่านิทานให้ฟัง….

กาลครั้งหนึ่งนานมาแล้ว ณ หมู่บ้านที่สงบสุขท่ามกลางชีวิตที่เรียบง่ายของชาวบ้านที่ใช้ชีวิตอย่างมีความสุข

Screen Shot 2559-06-26 at 6.33.21 PM.png

สิ่งที่ไม่คาดคิดก็เกิดขึ้น ได้มีมังกรวายร้ายปรากฏตัวขึ้นมาเพื่อทำลายหมู่บ้าน

Screen Shot 2559-06-26 at 6.33.52 PM

ชาวบ้านได้ตื่นตระหนกและทำการสวดอ้อนวอน

Screen Shot 2559-06-26 at 6.35.36 PM.png

ทันใดนั้นเองก็ได้มี คนๆนึงที่ใครๆก็เรียกเค้าว่า ฮีโร่ ปรากฏกายขึ้นมา พร้อมประกายแห่งความหวัง

Screen Shot 2559-06-26 at 6.37.02 PM.png

แน่นอนว่าด้วยความเก๋าของฮีโร่ + กำลังใจอย่างเต็มเปี่ยมของชาวบ้าน
เค้าก็จัดการมังกรร้ายได้อย่างง่ายดาย…

Screen Shot 2559-06-26 at 6.37.34 PM.png

ในที่สุดชาวบ้านก็กลับมาใช้ชีวิตอย่างมีความสุขเช่นเดิม

Screen Shot 2559-06-26 at 6.33.21 PM.png

HAPPY ENDING

(?)

นิทานที่ผมเล่าไปนั้นสามารถตีความให้เกี่ยวกับการพัฒนา Software แบบ Hero Driven Development ได้

ซึ่งนั่นก็คือ..ในทุกครั้งที่มีแหตุการณ์ไม่ปกติ เช่น ปัญหาร้ายแรง/critical bugs/server ล่ม  ทีมงานทุกคนในทีมก็จะเฝ้ารอให้มีคนใดคนนึงที่พวกเค้าเชื่อว่าเก่งที่สุดดังเช่นฮีโร่ จะออกมาแก้ปัญหานี้ให้พวกเค้า และพวกเค้าจะทำหน้าที่นั่งเชียร์ คอยหาขนม และให้กำลังใจอยู่ห่างๆ อย่างห่วงๆ(?)
และเมื่อปัญหานี้ได้ถูกแก้ไป ทีมงานก็กลับไปทำงานตามปกติจนกระทั่งจะเกิดเหตุการณ์นี้ขึ้นอีกในอนาคต….

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

ปัญหาเหล่านี้ไม่ใช่ปัญหาของฮีโร่แต่เป็นปัญหาของทีม!

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

และสุดท้ายหวังว่า เราจะสร้างหมู่บ้าน Super HERO ไปได้ด้วยกัน

เรียบเรียงจาก
http://carlokruger.com/?p=35
http://highlevelbits.com/2014/08/hero-driven-development.html

ทักษะประจำกาย Developer #6 – Craftsmanship Developer นักพัฒนายอดฝีมือ

การเป็น developer ที่ดี นั้นไม่ใช่แค่ทำให้ software/program/app ทำงานได้ตามที่ user ต้องการ แต่ควรจะมีสิ่งที่มากกว่านั้น
แล้วสิ่งๆนั้นคืออะไรล่ะ?

Working Software นั้นอาจจะเพียงพอที่จะทำให้ปิดโปรเจคหรือส่งมอบให้ user ไปใช้งานได้ แต่ข้างในระบบนั้นอาจจะเต็มไปด้วย shortcut, hack, debt ต่างๆเต็มไปหมด ซึ่งเป็นสิ่งที่ไม่ควรสำหรับ Craftsmanship developer

ถ้าเราต้องการก้าวผ่านระดับ good developer ไปสู่ Craftsmanship developer สิ่งแรกที่ควรคิดถึงเลยคือ

well-crafted software – ก็คือ software ที่ออกแบบอย่างปราณีต,  code design สวยงาม เป็นระบบระเบี่ยบ อ่านง่ายและง่ายต่อการเข้าใจ

การจะสร้าง well-crafted software ได้นั้น ก็ต้องใช้ประสบการณ์และความทุ่มเท มากขึ้นแน่นอน
ผมว่าเราเริ่มจากแนวคิดง่ายๆก่อนเลยนะ

  • สมมุติว่าเราทำ implement จบไป 1 feature
  • ลองใช้เวลากับ code ที่เรา implement ไปซักพักนึง แล้วถามตั้งคำถามว่า …. “เราจะทำให้มันดีขึ้นยังไง”?
  • แล้วลองใช้เวลาอีกซักพักเพื่อแก้ไขสิ่งที่เรา implement ไป
  • ถ้าไม่พอใจก็ถามคำถามเดิมกับตัวเอง ว่า “มันน่าจะดีขึ้นได้อีกนะ?”
  • ผมเชื่อว่าการทำแบบนี้สม่ำเสมอจะทำให้ไปถึงจุดที่เรา implement สิ่งที่เรียกว่า well-crafted software ได้ในซักวันหนึ่ง

more info: http://manifesto.softwarecraftsmanship.org/

ทักษะประจำกาย Developer #5 – ไม่มีใครขายงานของเรา ได้ดีเท่าตัวเรา

เนื่องจากนิสัยโดยทั่วไปของ Developer ชอบคุยกับคอมพ์มากกว่ากับคน ทำให้ขาดทักษะในการพูดและการ Present

แต่ผมคิดว่า Present ให้เป็นนี่ล่ะ เป็นอีกหนึ่งจุดที่ทำให้เราก้าวผ่านขีดจำกัดของ Developer โดยทั่วไป

ผมดูทีวีแล้วก็ได้ยินประโยคนี้ “ไม่มีใครขายสิ่งที่เราทำ ได้ดีเท่าตัวเรา” ซึ่งผมก็เห็นด้วย 100% เพราะคนที่ทำควรจะต้องรู้จากข้อดีและจุดขายของสิ่งที่ทำไป แต่การที่จะนำเสนอสิ่งนี้ หรือพูดให้คนอื่นเข้าใจหรืออินตาม จะทำได้ยังไง นี่เป็นความท้าทายมาก

Developer โดยทั่วไปเวลาทำการขายของ(Present งาน) จะชอบการพูดถึง technology ที่ใช้ logic ที่เขียน และการเรียงลำดับขั้นตอนที่ไปๆมาๆ แล้วก็วนมาว่าเขียน Code อะไรไปบ้าง

คนฟังที่ไม่ได้อยู่ในพื้นฐานหรือทำงานด้วยกันมาอาจจะไม่เข้าใจและเกิดอาการหลุด..

ดังนั้นการขายของหรือการ Present งานสำหรับ Developer เราควรจะต้องรู้ว่ากำลังขายให้ใคร
เช่น การ Present งานให้กับ Stake Holders หรือว่า คนที่ไม่ใช่ technical เราควรจะเน้นที่ประโยชน์มากกว่ารายละเอียดการ Implement

ท้ายที่สุดจงจำไว้ว่า งานของเรา เราคือคนขายที่ดีที่สุด!!!

ทักษะประจำกาย Developer #4 – Eating your own dog food

แปลตรงตัว การกินอาหารหมาของตัวเอง
เป็นคำเปรียบเทียบว่า ถ้าเราทำอาหารหมา เราก็ควรกินอาหารหมาที่เราทำ จะได้รู้ว่าอร่อยรึเปล่า

แต่จริงๆเป็นการเล่นคำในวงการ software development ว่า การที่เราสร้าง Product อะไรมานั้น เราในฐานะผู้ใช้สร้าง ก็ควรจะใช้งานมันด้วย และที่สำคัญถ้าใช้ในชีวิตประจำวันได้เลยยิ่งดี ซึ่งแนวคิดนี้จะทำให้ Product/Software ที่พัฒนาออกมาได้รับ feedback ที่เร็วขึ้น รวมทั้งได้แง่มุมจากการใช้งานจริงของคนภายใน ก่อนที่จะส่ง Product ออกไปให้ User ใช้

แนวคิดนี้เปลี่ยนมุมมองของการพัฒนา software เลยนะ ผมว่า
เนื่องจากปกติแล้ว Developer จะชอบจดจ่อแต่กับการเขียน Code และเขียนให้เสร็จ แต่จะชอบละเลยการทดสอบ(Test) ซึ่งปกติ Developer จะ Test โดยสนใจผลลัพธ์ของ software ว่าทำงานถูกต้องรึเปล่า(ซึ่งนั่นก็เป็นข้อดี) แต่อีกมุมหนึ่งซึ่งเป็นหัวใจของการ Test ก็คือประสบการณ์ที่ดีของผู้ใช้ (User Experience)

ผมชอบแนวคิดนี้นะ จริงๆไม่ใช่เฉพาะแวดวง Software หรอกที่จะประยุกต์ไปใช้ได้ ผมว่ามันใช้ได้กับทุกผลิตภัณฑ์ เช่น

  1. ถ้าทำธุรกิจอาหาร คุณก็ควรจะกินอาหารจากฝีมือตัวเอง หรือ เซฟ ประจำร้าน อย่างสม่ำเสมอ เพราะถ้าคุณกินแล้วไม่อร่อย คุณคาดหวังจะให้คนอื่นกินอร่อยเหรอ?
  2. เซลล์ขายรถยี่ห้อ A ถ้าคุณเองดันใช้แต่รถยี่ห้อ B แล้วคุณจะแนะนำสิ่งดีๆ หรือประสบการณ์ดีๆจากรถยี่ห้อ A ได้ยังไง
  3. ถ้าคุณเปิดร้านกาแฟ แต่ตกเย็นคุณไปนั่งจิบกาแฟ s… แทนการชงเอง

ทั้งนี้และทั้งนั้น ก็อย่าลืมที่จะ Eating other dog food ด้วยนะครับ เพื่อเป็นการเปิดโลกและสร้างประสบการณ์ใหม่ๆ แล้วนำมาใช้กับชีวิตเรา 😉

ref: https://en.wikipedia.org/wiki/Eating_your_own_dog_food