เคยพูดไปเมื่อก่อนว่า โค๊ดที่ถือว่าเป็นโค๊ดมรดก หรือ Legacy Code นั้น ว่ากันว่าเป็นโค๊ดที่ไม่พึงประสงค์ เหมือนเป็นภาระที่สืบทอดกันมาเป็นรุ่น ๆ ในองค์กร ซึ่งเกิดจากการที่โค๊ดนั้นมันไม่มี Unit Test

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

ที่ว่าค่าใช้จ่ายสูง ใช้เวลามากนั้น น่าจะพอนึกภาพออก ยิ่งโค๊ดมีขนาดใหญ่มากก็ต้องเขียน Unit Test มากก็ไม่แปลกถูกไหมครับ

แต่ว่าโค๊ดเดิมต้องแก้ด้วยหรือ ?

คำตอบคือ แล้วแต่ว่าโค๊ดเดิมครับ แต่โดยทั่ว ๆ ไปมันก็มักจะมีโค๊ดที่เทสต์ได้ยากถ้าไม่มีการแก้ไขเลย

สมมติว่าผมมีคลาส Java ชื่อว่า Logger ละกัน มันไม่ได้ทำอะไรมากมาย แค่ว่าเขียน log ลงไปในไฟล์เท่านั้นเอง ... แบบนี้ (เขียนไม่เต็มนะครับ ขี้เกียจ 55)

class Logger {
  private FileWriter writer;
  public Logger(File file) {
    writer = new FileWriter(file);
  }
  public void log(String message) {
    Date date = new Date();
    writer.write(String.format("%D : %s"), date, message);
  }
}

ถ้าเราจะเขียนเนี่ยมันก็ค่อนข้างเป็นงานช้าง เพราะว่าสิ่งที่มันทำคือมันเขียนลงไฟล์ตรง ๆ เลย ... ตัว Unit Test ต้องไปอ่านไฟล์มันกลับขึ้นมาแล้วดูว่ามันเขียนถูกหรือเปล่า ... แล้วพอยิ่งพ่วงวันที่เข้าไปอีกก็เริ่มยากละ เพราะว่าเวลามันจะเปลี่ยนไปเรื่อย ๆ ตามวันที่เทสต์นั่นเอง

เราก็ต้อง refactor code โค๊ดให้มันมีการ "ยึดติด" น้อยลง แบบนี้ครับ

class Logger {
  private Writer writer;
  public Logger(Writer writer) {
    this.writer = writer;
  }
  public Logger(File file) {
    this.writer = new FileWriter(file);
  }

  public void log(Date date, String message) {
    writer.write(String.format("%D : %s"), date, message);
  }

  public void log(String message) {
    log(new Date(), message);
  }
}

ผมใช้วิธีสองอย่างในการทำให้ "การยึดติด" ลดลง คือการใช้ polymorphism - ใช้คลาส Writer แทนที่จะเป็น FileWriter และการใช้ parameter passing จากข้างนอกแทนที่จะเป็นการสร้างใหม่จากภายในคลาส (และมีอีก method นึงทำหน้าที่เป็นเหมือนกับการกำหนด default parameter) วิธีนี้ทำให้ผมไม่จำเป็นจะต้องอ่านไฟล์หลังจากที่เขียนลงไปแล้ว เพราะว่าผมสามารถใช้ StringWriter แทน FileWriter ได้นั่นเอง นอกจากนี้วิธีนี้ทำให้โค๊ดที่ใช้งานคลาสนี้สามารถใช้งานได้เหมือนเดิม เพราะว่า interface เดิมยังอยู่ครบเลยครับ

ส่วนตัว Unit Test นั้นก็สามารถเขียนแบบนี้ :-

class LoggerTest {
  @Test
  void test(){
    Stringwriter writer = new StringWriter();
    Logger logger = new Loger(writer);
    Date date = new GregorianCalendar(2000, 3, 15).getTime();

    logger.log(date, "test message");
    writer.close();
    assertEquals(writer.toString(), "03/15/2000 : test message");
  }
}

ยาวกว่าที่คิดแฮะ 555 setup ยาวครับ แต่จริง ๆ ก็ไม่ได้ซับซ้อนอะไร เทียบกับการไปอ่านไฟล์กลับขึ้นมาแล้วลำบากกว่าเยอะ แถมต้องมา parse ว่าวันที่ที่ log ไปมันวันที่เท่าไหร่อีก ... ดูลำบากชีวิตว่ามั้ยครับ

ตรงนี้แหละครับที่เป็นการวัดว่า ความสามารถในการถูกทดสอบ หรือ Testability นั้นมีมากน้อยแค่ไหน

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

จุดที่ต้องระวังอีกอย่างคือเปิดให้เข้าถึง method นั้นจะทำให้ user เข้ามาใช้ method นั้น ๆ โดยที่เราไม่ได้ตั้งใจให้เขาใช้ เพราะว่าต้องเปิดให้เข้าถึงจากภายนอก เราก็ต้องทำการจำกัดการเข้าถึงโดยไม่อนุญาตให้คลาสอื่นนอกจากคลาสที่เป็น unit test เข้าถึงได้นั่นเอง ซึ่งก็เป็นต้องดูเป็นรายภาษาไป อย่างของ C++ ก็อาจจะใช้ friend class ช่วย ส่วน Java ก็อาจจะเป็นการใช้ default access modifier ที่ไม่อนุญาตให้คลาสอื่น ๆ นอกจากคลาสใน package เดียวกันเข้าถึงได้ครับ

หรือในกรณีที่แย่ที่สุดก็ comment ไปเลยว่า user ไม่ควรใช้ method นี้ตรง ๆ นะ (ถ้าใช้แล้วเกิดอะไรขึ้นไม่รับผิดชอบ) ก็ยังได้ครับผม

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

2015-05-29 06_41_42-ZipPicView - idol-kinouchi-akiko-1334112557-BOBX.zip

หายหน้าไปนานนนน จนโฮสต์หมดอายุ 55 ขออภัยทุกอ่าน วันนี้จะขอแชร์แอพที่เขียนเล่น ๆ ในช่วงอาทิตย์ที่ผ่านมาครับ ชื่อว่า ZipPicView คือเจ้านี่เนี่ยมันเกิดจากความที่ผมมีไฟล์รูปอยู่ใน Zip อยู่จำนวนหนึ่ง (ไม่เยอะหรอกครับ มีอยู่ประมาณ 120GB :-)) ไอ้ครั้นจะแตกไฟล์มันออกมาก็ขี้เกียจ เพราะว่ามันเยอะ แต่โปรแกรมดูรูปในไฟล์ Zip ส่วนใหญ่มันออกแบบมาไว้อ่านการ์ตูน มันจะเอาไฟล์ย่อย ๆ มาเรียงกันหมดเลยโดยไม่สนใจว่าโครงสร้างของ directory เป็นยังไง (ส่วน Zip Folder ก็ทำงานได้ห่วยเกินทน)

ทางเลือกที่มีอีกทางคือ ACDSee ซึ่งก็ราคาพันกว่าบาท

เงินจำนวนนี้ไม่ได้มากมายอะไรก็จริง แต่ผมงก 5555 ล้อเล่นครับ พอดีผมหาโปรเจคเอาไว้เขียนซ้อมมืออยู่พอดี ก็เลยคิดว่าเขียนอะไรเล่น ๆ ดีกว่า

ZipPicViewWeb

2015-05-30 20_14_50-View Zip

เริ่มแรกผมเริ่มจากเวอรชันเว็บก่อน เพราะว่า คือ ... สมัยนี้อะไรก็เป็นเว็บไปหมด ผมก็เลยคิดถึงเว็บก่อนครับ ในตอนแรกสุดเลยผมว่าจะลองวิธีที่เดี๋ยวนี้เขานิยมกัน ก็คื่อการเขียนเว็บด้วย Node.JS แต่ว่า ด้วยความที่ Node.JS โปรเซสไฟล์เป็น Stream มันไม่เหมาะกับงานที่ผมใช้ (Zip File ออกแบบมาเป็น random access ครับ ต้องอ่านถึงท้ายไฟล์ถึงจะสามารถดึงเอา content ไปใช้ได้)

ก็เลยเปลี่ยนมาใช้ Java Backend แทน แต่ก็ไม่ได้เขียนเป็น Servlet หรอกครับ ผมใช้ Application Server จาก Eclipse ที่ชื่อว่า Jetty ในการพัฒนาครับ ตัวโปรแกรมไม่ได้มีอะไรมากเลย มันประกอบไปด้วยสองส่วน ก็คือหน้าที่สำหรับ browse หาไฟล์ zip ในเครื่อง (Host) กับหน้าสำหรับลิสต์ชื่อไฟล์รูปภาพใน zip file เท่านั้นเอง

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

2015-05-30 20_32_54-(JPEG Image, 1200 × 1800 pixels)

ก็ถือว่าใช้ได้ตามที่ต้องการพอดี

แอพตัวนี้ฝั่ง backend เป็น java อย่างที่ผมบอกไป แต่ฝั่ง frontend เนี่ยเป็น HTML5 (HTML + CSS +JS) ล้วน ๆ ครับ ไม่มี server-side script/app แม้แต่น้อย เป็นความตั้งใจเพราะมันเป็นเรื่องที่จะฝึกนี่ล่ะ

  • CSS เป็น Pure CSS
  • JavaScript เป็น jQuery เป็นหลักครับ แล้วก็มี lib อื่น ๆ อีกพอสมควร

ทีนี้ มาคิดอีกที ... เปิดดูอยู่คนเดียว ก็ไม่ได้ว่าจะแชร์ให้ใครดู ก็เลยเขียนเวอร์ชัน Desktop ขึ้นมาอีกตัวครับ

ZipPicViewDsk

ZipPicViewDSK เป็น Java Swing App ที่ทำงานเหมือนข้างบน (โดยหลักการนะครับ โค๊ดสองโปรแกรมไม่มีแชร์กันเลย 555) แต่จะตัดตัว file browser ออกไป (ใช้ open file dialog แทน) และเพิ่มตัวดูรูปเข้ามา

2015-05-30 20_13_04-ZipPicView - idol-arimura-kasumi-1376238044-BOBX.zip

Look and Feel ที่ใช้คือ Substance ครับ เพิ่มความหรูหราให้กับโปรแกรมได้มากมาย

2015-05-30 20_13_27-ZipPicView - idol-arimura-kasumi-1376238044-BOBX.zip

สุดท้ายแล้วผมว่า ถ้าเรามีอะไรที่อยากได้ เราสามารถลงมือทำเองได้ถ้าดูแล้วไม่ยากเกินไปครับ และได้เป็นการฝึกฝีมืออีกด้วย ที่ทำนี่จริง ๆ ไม่ได้ยากเลย

ทั้งนี้ขอขอบคุณองค์กรดังต่อไปนี้ครับ

  • Eclipse Foundation สำหรับ Eclipse IDE, Jetty Application Server, Xtend Programming Language
  • Apache Foundation สำหรับ Apache Commons Archive, Apache Ivy

และ library อื่น ๆ ที่ถูกใช้งานในโปรดักท์นี้ครับ

โค๊ดทั้งหมดถูกแชร์ขึ้นไปบน Github ด้วย License MIT License นะครับ เอาไปใช้เล่นกันได้ตามสะดวก

คิดว่าบางคนคงจำเรื่องดราม่า ที่มีคนจ้างศิลปินชาวญี่ปุ่นมาเอาต้นไม้อายุร้อยกว่าปีไปสร้างสรรค์ผลงานศิลปะ แล้วอ.เฉลิมชัยแกออกมาโต้บอกว่า "คนไทยไม่รู้อะไร มันเป็นงานศิลปะ โคตรคุ้ม" คืออ้างอิงจากสัมภาษณ์ที่ลงไทยรัฐก็แล้วกันนะครับ

อ.เฉลิมชัย ศิลปินผู้มีชื่อเสียง เริ่มเรื่องจากการเล่าถึงศิลปะของคนไทย ว่า โดยปกติแล้วนั้น คนไทยไม่มีพื้นฐานที่จะเข้าใจในเนื้องานศิลปะได้ แต่จะเข้าใจเพียงว่า งานศิลปะที่มีคุณค่า อันจะบ่งบอกว่าศิลปินผู้นั้นมีฝีมือสูง ต้องเป็นงานศิลปะที่มีความสวยสดงดงาม ต้องวาดเขียน หรือแกะสลักไม้ออกมาด้วยความประณีต ฉะนั้น เมื่อคนไทยมาเจองานศิลปะของ ดร.กมล ทัศนาญชลี ศิลปินแห่งชาติ สาขาทัศนศิลป์ แล้ว สมองสั่งการของคนไทยจะคิดไปในทันทีว่า “งานแบบนี้ ลูกกูก็ทำได้ เตี่ยกูก็ทำได้ หมาก็ทำได้ เอาต้นไม้สวยๆ มาตัดเป็นท่อน กูว่าต้นไม้ก็อยู่ของมันดีๆ ยังสวยกว่าเอามาตัดอะไรแบนี้ นี่มันทำลายธรรมชาติชัดๆ แต่ถ้าพี่กมล เอาต้นไม้ที่ว่านี้ มาตัดเป็นเรือสุพรรณหงส์ พญาครุฑ หรืออะไรก็ตามแต่ที่เป็นงานไทย เชื่อสิ ไม่มีใครเขาด่า จะมีก็แต่ชื่นชม และไม่มีใครเสียดายต้นไม้ ส่วนผลงานของพี่กมลนั้น ไม่ใช่ไม่สวย แต่นี่เป็นความสวยแบบ abstract (นามธรรม) สวยที่รูปอารมณ์ ไม่ใช่สวยที่รูปร่าง” อาจารย์เฉลิมชัย ชี้แจงโผงผางตามสไตล์

อืม ... ศิลปะเอง คนที่จะมองก็ต้องเป็นคนที่มีพื้นฐาน เป็นคนที่มีความเข้าใจ

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

สมมติอย่างเช่นเวลาที่มีคนเปิดเพลงขึ้นมาสักเพลงนึงในห้างสรรพสินค้าละกัน คนที่เดินผ่านไปผ่านมาก็อาจจะคิดว่า

  1. เพลงนี้เพราะจัง
  2. ทำนองเพลงนี้แปลกดี
  3. เอ๊ะ เทนชันตรงนี้สวยดีแฮะ
  4. หืม ท่อนส่งกลองตรงนี้เจ๋งดี
  5. เนื้อเพลงท่อนแรกก็สวยดี แต่ท่อนหลังมันดันไปแจ้งกับท่อนแรกซะงั้น เล่นคำมากไปหน่อยมั้ง
  6. มิกซ์มาไม่ดีเลย เสียงมันกลืน ๆ กันไปหมด
  7. เครื่องเสียงมีปัญหาหรือเปล่าเนี่ย ??

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

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

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

ทั้งนี้ผมก็พยายามมองแบบเลี่ยง ๆ ไม่ให้รู้ตัวนะ เกรงใจ 555

ปล. ทำไมจบโรคจิตได้ขนาดนี้นะ

เมื่อวันก่อนผมมีทำคลิปเกี่ยวกับการสัมภาษณ์งาน เห็นว่าเกี่ยวข้องกันก็เลยแปะไว้ด้วย ถ้าสนใจก็แวะกดดูได้นะครับ

เข้าเรื่องดีกว่า จริง ๆ เรื่องนี้เป็นเรื่องที่ผมเคยให้เพื่อน ๆ โหวดว่าอยากให้เล่าเรื่องไหน แล้วเรื่องนี้มาวินเลย (แบบท่วมท้นอีกต่างหาก) แต่เป็นเรื่องที่อยากเล่าน้อยที่สุดเลย เพราะมันค่อนข้างเกี่ยวข้องกับความมั่นคงส่วนตัวเนอะ 555 เอาเป็นว่าผมเล่าให้ฟังในบล็อกละกัน

ถ้าถามเรื่องนี้กับหลาย ๆ คนก็จะมีคนบอกว่า บ.เล็กท้าทายกว่า เติบโตเร็วกว่า บ.ใหญ่มั่นคงกว่า สวัสดิการดีกว่า ฯลฯ แต่ถ้าถามผมผมจะตอบว่า...

บ.ใหญ่มีคนเยอะกว่าบ.เล็ก ...

/me ได้ยินเสียงใครสักคนล้มโต๊ะ

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

หรือถ้าดูกันที่เรื่องของ facility เนี่ย คุณก็จะบอกว่า บริษัทใหญ่ ๆ มีออฟฟิศหรู ๆ มีห้องอาบน้ำ มีเครื่องถ่ายเอกสาร ผมก็จะบอกว่า บริษัทเล็ก ๆ จะมีคอมพิวเตอร์ดีกว่า มีอุปกรณ์ดีกว่า

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

ทำไมมันถึงยิ่งแพง เอาแบบนี้ก็ได้ สมมติว่าในออฟฟิศมีคอมพิวเตอร์ 20 เครื่องนะครับ สิ่งที่ต้องมีคือ คอมพิวเตอร์ 20 ชุด สวิตช์ 24 พอร์ต แล้วก็เราท์เตอร์สักตัวนึง พอละ ในทางกลับกันพอเป็นคอมพิวเตอร์ 200 เครื่อง จะบอกว่าใช้ คอมพิวเตอร์ 200 ชุด สวิตช์ 240 พอร์ต ต่อเข้าเราท์เตอร์ 10 ตัว มันก็ประหลาดใช่ไหมครับ (สามสายก็เยอะแล้ว) และต่อให้ทำแบบนี้สิ่งที่ต้องมีเพิ่มขึ้นมาคือฝ่าย Infrastructure คอยดูแลไม่ให้ระบบล่ม ในขณะที่ไอ้คอม 20 เครื่องเนี่ย ผู้จัดการบริษัทคนเดียวก็ดูแลได้

หรือ ไอ้ห้องอาบน้ำ ห้องนี้มันไม่ได้ใช้พร้อมกันทุกคนในออฟิศ เขาก็แบ่ง ๆ กันใช้ บางคนก็ไม่ใช้ ใช่ไหมครับ ดังนั้นสร้างสักห้องเดียวก็พอสำหรับคน 120 คน ในทางกลับกันถ้าเรามีคนแค่ 12 คน จะสร้างแค่ 0.1 ห้องมันก็ทำไม่ได้ใช่ไหมครับ (ว่าแต่ถ้าใครรู้วิธีสร้างห้องอาบน้ำ 0.1 ห้องนี่ก็มาเล่าให้ฟังกันด้วยก็ดีนะครับ)

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

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

พอเอาสองอย่างมารวมกัน เขาถึงเรียกว่า อำนาจมาพร้อมกับความรับผิดชอบไงล่ะครับ

จะว่าไป 120 คนนี่ก็ไม่ได้ใหญ่โตอะไรเลยนะ หลาย ๆ บริษัทมีคนหลักแสนมีสาขาอยู่ทั่วโลกด้วยซ้ำ ลองคิดดูละกันว่ามันจะเป็นแบบไหน (แต่ส่วนใหญ่แต่ละสาขาย่อยในแต่ละประเทศเขาจะมองว่าเป็นคนละองค์กรกันนะ)

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

ก็สรุปง่าย ๆ แหละว่า บ.เล็กกับบริษัทใหญ่ นั้นมีจำนวนคนนี่แหละเป็นรากฐานของความแตกต่าง เท่านั้นแหละ

ช่วงนี้เน้นทำคลิปเลยไม่ค่อยเขียนบล็อกเท่าไหร่ ถ้าใครต้องการสาระด้านบวก ลองดูคลิปดูนะครับ ส่วนใน Blog บางทีมันจะดาร์ก ๆ หน่อย :)

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

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

ดังนั้นมันไม่ได้ผิดอะไรเลยที่เราไม่รู้

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

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

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

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

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

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

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

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

PG-Talk เป็นช่องบน YouTube ที่ีผมตั้งขึ้นมาจากคำถามที่ว่า ถ้าย้อนกลับไปสัก 10 ปี ถึงตอนที่ยังเป็นนักศึกษาปีสุดท้าย เราควรจะเรียนอะไรเพื่อที่สามารถพัฒนาตัวเองในสายอาชีพได้ ช่องนี้จะเป็นการรวมเอาความรู้ต่าง ๆ ที่ผมเรียนรู้ในระหว่างการทำงานตลอด 9 ปีที่ผ่านมา เอามาเล่าให้ฟังในภาษาไทยเพื่อที่จะสื่อให้กับคนที่ต้องการจะเริ่มต้นได้รู้และเข้าใจได้โดยไม่ต้องมานั่งแปลภาษาอังกฤษกลับมาเป็นไทยอีกที

ตอนนี้มีอยู่ทั้งหมด 4 ตอน ซึ่งก็จะพยายามอัพเดตให้ได้อาทิตย์ละตอนเป็นอย่างน้อยครับ

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

ท่านใดที่สนใจก็รบกวน Subscribe กันหน่อยนะครับ แล้วก็กรุณาอย่าปิดโฆษณานะครับ ถ้าเกิดรายได้ดีผมอาจจะเลิกงานประจำไปเลยก็ได้นะ (คงยาก 555)

1

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

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

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

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

คือแบบ แทนที่จะต้องมานั่งเข้าเทรนนอกเวลางาน เอาเวลาไปเล่นโยคะหรืิอฟิตเนสดีกว่า อะไรทำนองนี้

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

ดังนั้นผมคิดว่าการสร้างวัฒนธรรมเพื่อสนับสนุนความแตกต่างนั้นจึงเป็นเรื่องที่สำคัญเหมือนกันนะ

ในหนังสือ How Google Works เขียนไว้ว่า ที่ Google จะมีการสนับสนุนให้พนักงานแต่ละคนใช้เวลาทำงาน 20% ไปกับการทำโปรเจคที่ไม่ได้เกี่ยวกับงานของตัวเองโดยตรง โดยโปรเจคที่ว่านั้นพนักงานเป็นคนเสนอและผ่านการรับรองจากผู้บริหาร และนั่นเป็นหนึ่งในวิธีการสนับสนุนการสร้างวัฒนธรรมที่สนับสนุนการเปลี่ยนแปลง (ผมเคยบอกแล้วว่าไม่ใช่มีแต่ Google ที่ทำนะ แต่เท่าที่ได้ยินมาก็มีน้อยมากที่มีวัฒนธรรมที่สนับสนุนความเปลี่ยนแปลงแบบนี้)

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

สำหรับคนเก่งแต่ไม่แกร่งพอ โลกองค์กรมันอยู่ยากครับ บอกตรง ๆ

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

อย่างสมมติ คุณบอกว่าจะนำเอา CouchDB (เป็นระบบ database แบบไม่มีความสัมพันธ์) เข้ามาแทนที่ MySQL เพราะสามารถดูแลได้ง่ายกว่า และใช้คนพัฒนาน้อยกว่า (อาจจะเพราะตัวผลิตภัณฑ์เป็น Web และใช้ JavaScript เป็นหลักอยู่แล้ว) คุณจะถูกต่อต้านจากฝั่งเทพ SQL ทันที ทั้ง ๆ ที่ยังไม่มีใครศึกษาข้อดีข้อเสียด้วยซ้ำ เพราะกลายเป็นว่าเขาต้องศึกษาภาษาใหม่ทั้งหมด (ทั้งนี้คนกลุ่มนี้หลายคนเขียนอะไรไม่ได้เลยนอกจาก SQL Query เพราะภาษามันเฉพาะทางมาก) และในระยะยาวเขาอาจจะทำไม่ได้และถูกบีบจนต้องลาออกไปก็ได้ และนี่ถ้าคุณดันไปเสนอให้เปลี่ยนจาก PHP เป็น Node.JS พร้อมกันเลยล่ะก็ คุณอาจจะไม่ได้กลับบ้านอีกเลยก็ได้นะ

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

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

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

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

เอ๊ะ จริง ๆ มันก็เป็นปีนี้ไปแล้วเนอะ

วันนี้พูดถึงสิ่งที่เรียกว่า "การยอมรับ" สักหน่อย คือ ผมจะไม่บอกนะว่ามันคืออะไร เพราะเอาจริง ๆ ผมก็ไม่รู้ (ฮา) แต่จะเล่าเรื่องของตัวเองให้ฟังละกัน

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

มึงเป็นใครมาสั่งกู

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

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

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

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

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

ผมคิดว่าก่อนที่จะทำตามคำสั่งใครคุณต้องสามารถยอมรับคำสั่งนั้นได้ก่อน ถ้าเกิดว่าคำสั่งที่ไม่น่าเชื่อถือ หรือเป็นคำสั่งที่แย้งกับกฎข้อต่าง ๆ คุณก็มีหน้าที่ที่จะปฎิเสธ เช่น คุณต้องปฎิเสธเวลามีคนมาขอยืม user id และ password ของตัวเคุณ ไม่ว่าเขาจะเอาไปทำอะไร และไม่ว่าเขาจะเป็นใครก็ตาม (เพราะมันเป็นการผิดกฎและข้อบังคับด้านความปลอดภัยอย่างชัดเจน)

และคุณเองก็คงจะยอมรับคนลักษณะนี้น้อยลงด้วยเช่นกัน เพราะเป็นผู้ที่พยายามทำให้คุณเดือดร้อนนั่นแหละ

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

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

ทั้งนี้การเป็นที่ยอมรับนี่ นอกจากเรื่องพวก ... เอ่อ คุณวุฒิ วัยวุฒิ หรืออะไรพวกนั้นนี่ จริง ๆ เรื่องของการประพฤติตัวนี่ก็มีผลมากนะ คนที่ดูท่าทางน่าเกรงขาม ทำตัวเหมือนกับข่มขู่คนอื่นตลอดเวลานี่ จะมีคนฟังแทบจะตลอด (ด้วยความกลัว อารมณ์ประมาณ "จ้าวแห่งหมัด" นั่นแหละ 55) ทั้ง ๆ ที่จริง ๆ เขาอาจจะเป็นคนไม่มีความสามารถอะไรเลย (เอาเข้าจริง ๆ หลาย ๆ คนที่ต้องทำตัวข่มขู่คนอื่นตลอดนี่ก็เพราะไร้ความสามารถนั่นแหละ) แต่คนที่มีทั้งบารมี ดูน่าเกรงขาม และมีความสามารถจริง ๆ ด้วยนี่จะเป็นคนที่ดูน่ากลัวและมีพลังวัตรสูงส่งมาก แค่มองหน้าก็สั่นไปทั้งตัวละ 555

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

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

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

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

อันที่จริงคนที่คิดอย่างเดียวโดยปราศจากพื้นฐานเนี่ย เราเรียกง่าย ๆ ว่าเป็นพวกเพ้อฝันครับ

จากประสพการณ์ส่วนตัวในระยะหลังผมพบว่าผมเจอคนที่ขาดความรู้พื้นฐานอยู่บ่อย ๆ อย่างเช่นที่เจอเอาหมาด ๆ เลยคือถามว่า integer ขนาด 32 บิตนั้นสามารถเก็บตัวเลขได้กี่หลัก (คำตอบคือ 10 ครับ ถ้าเป็น sign int จะเก็บได้ตั้งแต่ลบสองพันล้านกว่า ๆ ถึงสองพันล้านกว่า ๆ ทั้งนี้ถ้าจะเอาให้ปลอดภัยควรเก็บไม่เกิน 9 หลักนะครับ ไม่งั้นอาจจะเกิด overflow ได้เมื่อเกินสองพันล้าน ทั้งนี้เวลาฟังคำตอบก็ต้องดูเหตุผลประกอบครับ คำถามนี้ตอบว่า 9 ก็ได้เช่นกันด้วยเหตุผลเดียวกัน)

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

ผมยกตัวอย่างนึง ถ้าพูดถึง access level เราก็มักจะพูดว่า ฟังก์ชั่นควรเป็น public ในขณะที่ฟิลด์ควรเป็น private ดังนั้นจะมีบางคนเขียนคลาสตามนี้โดยไม่คิดอะไรเลยว่า public คืออะไร และ private คืออะไร ทั้ง ๆ ที่จริง ๆ ถ้าคิดกันตามตรรกกะแล้วฟังก์ชันที่เป็น private ก็มีประโยชน์ของมัน ส่วนฟิลด์ที่เป็น public ก็ไม่ใช่ปีศาจ (ผมใช้ constant public field ประจำ ใช้ในแนว enumerator น่ะครับ)

ยิ่งเทคนิคที่มีความยากสูง ๆ ความรู้พื้นฐานก็ยิ่งสำคัญมากขึ้น เช่นเรื่องของการทำ multi-thread คุณต้องรู้เรื่องของการทำ synchronization ต้องรู้เรื่องของ atomic operation ไม่ใช่สักแค่เอา lock ไปแปะหัวท้าย (เพราะนั่นคือการบังคับให้ทุกงานถูกประมวลผลตามลำดับ (serial) กลายเป็นว่าเขียนของยากมาโดยไม่ได้ประโยชน์อะไรเลย) ซึ่งมันเป็นการแก้ปัญหาที่ปลายเหตุละ

ที่สำคัญที่สุด มันไม่ผิดที่ไม่รู้ แต่ที่ผิดจริง ๆ คือรู้ทั้งรู้ว่าตัวเองไม่รู้ก็ปล่อยให้ตัวไม่รู้ต่อไปทั้งอย่างนั้นครับ ดังนั้นอะไรก็ตามที่คุณคิดว่าตัวเองขาดไปคุณต้องศึกษาเพิ่ม ส่วนตัวผมพบว่าวิธีการตรวจสอบว่าตัวเองไม่รู้พื้นฐานเรื่องไหนก็คือการเปิดหนังสือที่เป็น reference แล้วอ่านทีละเรื่องไปตามลำดับ อย่างตระกูล In The Nutshell ของ Oreilly เนี่ยเป็นตัวอย่างที่ดี ลองค่อย ๆ อ่านไปตั้งแต่ต้นยันจบแล้วดูว่าตัวไม่เข้าใจมากน้อยแค่ไหน ถ้าเกิดว่ามึนตั้งแต่หน้า 10 นี่ก็ควรทบทวนควรรู้ด่วนล่ะครับ

สร้างตึกเริ่มที่ฐานราก สร้างคนต้องเริ่มที่ความคิดพื้นฐานครับ ลองดูนะ