ทำไม Developer ควรทำ Side Project

โดยส่วนผมเชื่อว่าการเป็น Developer ที่ดีนั้นต้องกระตือรือล้นอยู่ตลอดเวลาเพื่อที่จะอัพเดทสิ่งใหม่ๆ ที่จะใช้ในการทำงานให้ดีและมีประสิทธิภาพมากยิ่งขึ้น ซึ่งหนึ่งในวิธีการที่ผมคิดว่าทำแล้วมัน work ก็คือ การทำ Side Project 

Side Project คืออะไร?

ถ้าตอบสั้นก็คือ มันก็คือโปรเจคนอกเวลางาน ใช่ครับ Developer ที่ดีควรจะต้องจัดสรรเวลามาพัฒนาความรู้ตัวเองโดยการคิด Project ที่ตัวเองอยากทำ ซึ่งอาจจะเอา Skill ที่เราอยากจะเรียนรู้เป็นตัวตั้ง ซึ่งสิ่งเหล่านี้อาจจะหาไม่ได้จากงานประจำของเราๆซึ่งอาจจะรวมถึง Freelance หรือ Part Time นะ

ตัวอย่างในวงการอื่นที่ผมเห็นชัดคือ วงการเพลง J-Rock ของญี่ปุ่นครับ (อย่างผมชอบฟัง 90’s เช่น X-Japan, Luna Sea, L’arc en Ciel) จะเห็นได้ว่านักดนตรีของวงพวกนี้เวลาที่พวกเค้าว่างจากวงหลักของเค้า เค้าก็จะมีงาน Side Project ที่เรียกว่า Solo Album กัน ซึ่งผมว่ามันเป็นการเติมไฟ หรือหา Idea หรืออะไรใหม่ๆให้ชีวิตและ Refresh ตัวเองจากการทำงานประจำนะ 🙂

ข้อดีของ Side Project

  • ได้ลองอะไรใหม่ๆ ตามกระแสบ้าง หรือตามความชอบส่วนตัวบ้างโดยไม่มีข้อจำกัดด้าน Business ทุกอย่างนั้น Drive มาจากตัวเราเอง
  • ได้หัดคิด Project แบบ End to End รวมถึงหัดวิเคราะห์ทั้ง workflow ทั้งตัว Project และได้ลองตั้งเป้าหมายและพยายามที่จะได้ทำให้ได้ผลลัพธ์
  • ถ้า Skill ที่อยากฝึกนั้นอยู่ในเทรนด์หลัก ก็ไปลองเข้าหา community สร้าง connection ได้อีกด้วย
  • เพื่อ Idea เวิร์คก็ไปทำ Start Up เลย :p
  • ซักวันเราอาจจะได้มาใช้สิ่งที่ได้จาก Side Project หรือบาง Idea ไปใช้ในชีวิตการทำงานจริงก็ได้ (ใครจะรู้)
  • สร้างคุณค่าให้ตัวเอง 🙂 เพราะสิ่งสำคัญที่สุดมันคือการเพิ่มศักยภาพของตัวเราเอง!!!

เพียงแค่ลองเริ่มทำ  Side Project ดูแบบสั้นๆเช่นจบให้ได้ใน 1-3 เดือน ทำอาทิตย์ละ 0.5-1 วัน ผมเชื่อว่ามันจะทำให้คุณสร้างความแตกต่างจาก Developer ทั่วไปได้ครับ และท้ายที่ถ้าคุณทำเป็นนิสัยได้ ผมรับรองได้ว่าคุณก็จะสามารถยกระดับตัวเป็นให้เป็น Developer ที่ Above Average ได้ 🙂

main-qimg-40c5c6bafdcd821c937d9f3f6e9d54f5-c

ว่าแล้วตอนนี้คุณๆเราๆท่านๆมี Side Project ในมือแล้วหรือยัง ????

เส้นทางสู่ 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 ระดับโลก!!!!!

 

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

ทักษะประจำกาย Developer #7 – มาพร้อมวิธีแก้ปัญหา

การที่จะเป็น Developer ที่เก่งกว่าคนทั่วไปนั้น เราควรจะต้องมีนิสัยอีกอย่างนึงที่ขาดไม่ได้คือ การชอบแก้ปัญหา

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

Come with Solution, not problem

ขั้นตอนที่ผมใช้บ่อยที่สุดในการไปขอความช่วยเหลือคนอื่นคือ

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

ยกตัวอย่าง(แบบกว้างๆ) เช่น  ผมมีปัญหาว่า Server ที่ผมดูแลทำงานช้าจัง ถ้าผมไปถามคนอื่นทันทีอาจจะไม่ได้คำตอบแน่นอน เราก็ต้องลองมาทำงานการบ้านกันก่อน เช่น

  1. ไปศึกษาว่าระบบช้าเพราะอะไร สมมติว่าเจอว่า CPU ทำงานหนักตลอดเวลา
  2. ลองแก้ปัญหาดูเราอาจจะพบว่ามีทางออก 2 ทาง
    A. อัพเกรด CPU ให้เร็วขึ้น
    ข้อดี – แก้ปัญหาได้ 20%
    ข้อเสีย – ใช้งบ 30,000 บาทต่อ Server และอาจจะมี  Downtime สูง
    B. ปรับปรุง Software ให้ดีขึ้น
    ข้อดี – รีดประสิทธิภาพครื่องปัจจุบันได้ดีขึ้น ดูเป็นวิธีของ Engineer ดีและประหยัดงบ
    ข้อเสีย – อาจจะต้องใช้เวลาในการแก้ไขมากซัก 1 เดือน
  3. ผมชอบ ทางเลือกที่ B นะดูท้าทายดี
  4. จากนั้นก็ลองไปปรึกษาคนอื่นๆในทีมงานว่ามันเป็นไปได้มั้ย

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

ทักษะประจำกาย 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

ทักษะประจำกาย Developer #3 – Root Cause กับ Workaround?

คำ 2 คำที่คุ้นเคยมากสำหรับเราชาว developer

Root Cause ก็คือ ต้นตอของสาเหตุ
Workaround คือ การแก้ปัญหาอ้อมๆ เพื่อบรรเทาทุกข์

บ่อยครั้งที่ชีวิตในการทำงานของ Developer เราอาจจะหา Root Cause ไม่ได้ในเวลาที่จำกัดแต่เรารู้ว่าปัญหาคืออะไร เช่น

1. เรารู้ว่าการเขียน code แบบนี้มันแก้ปัญหาได้(มั้ง)แต่ไม่รู้ว่าเพราะอะไร นี่เป็นตัวอย่างนึงของ Workaround
2. ระบบของเราทำงานไป 2 วันแล้วทำงานช้าลง เราก็จัดการ restart เครื่องใหม่มันก็หายละ (แล้วอีก 2 วันมันก็ช้าอีก)  นี่เป็นตัวอย่างนึงของ Workaround โดนที่เราไม่ได้มองเลยว่าทำไมระบบทำไมถึงช้าลงได้

หรือยกตัวอย่างง่ายๆ เวลา TV ที่บ้านสมัยก่อนไม่ชัด เราทำไงกันครับ…ตบ TV ไป 2 ที ชัดเลย นี่แหละ Workaround!

การใช้ Workaround บ่อยๆ จะทำให้ทุกอย่างทับถมกันไปหมด จนสุดท้ายระบบก็เละและยากต่อการดูแล

การเป็น Developer ที่ดีเราควรจะหลีกเลี่ยง Workaround และเข้าใจกับ Code ทุกบรรทัดที่เขียนลงไป รวมทั้งการมองปัญหาที่ Root Cause เพื่อที่จะแก้ปัญหาได้อย่างถูกจุดและยั่งยืน ถึงแม้ว่าจะต้องใช้เวลาและความมุ่งมั่นมากกว่าก็ตาม…