Life On VM

คิดว่านี่เป็น milestone ใหญ่ๆอันแรกในชีวิตมนุษย์เงินเดือนครับ นั่นหมายถึงผมทำงานมาครบ life cycle ของมนุษย์เงินเดือนทั่วไปแล้ว คือ

• ตั้ง objectives
• ทำงาน
• ประเมิน performance กับหัวหน้างาน ว่า objectives ที่ตั้งไว้ทำได้ตามนั้นรึเปล่า ได้ระดับไหน
• ได้เงิน fixed bonus ปลายปี
• ได้เงิน performance-based bonus ตอนเมษา

(Your mileage may vary)

ที่ทำงานบรรยากาศดีครับ เพื่อนร่วมงานใจดีทุกคน ส่วนใหญ่จะเป็นพี่ๆ มีตั้งแต่รุ่นพี่ประมาณ 3 ปี จนถึงเพื่อนๆของอาจารย์ (ใหม่ๆ) ที่ภาคคอม 55+ แต่คนนอกมองเข้ามาในทีมอาจจะไม่รู้สึกว่าผมแตกต่างเท่าไหร่ เพราะหน้าแก่นำไปแล้ว T_T (เส้า) เคยไปประชุมกับ QA ทีมอื่น โดนเรียกพี่อีก (อ่าววว งอแง) Issues จากระดับบนในบริษัทไม่ค่อยลงมาถึงระดับผมเท่าไหร่ ส่วนหนึ่งคงเพราะ management ใน team อันได้แก่ group leaders และ manager แบกรับจัดการให้หมดแล้ว คนงานทำงานได้อย่างค่อนข้างสบายใจ :’)

เรื่องลักษณะงานที่ทำก็เคยเขียนไปบ้างแล้ว สิ่งที่ได้จากการทำงานที่นี่ คงเป็นเรื่องเทือกๆ Incident Management แล้วก็เรื่องของ Customer Support โดยที่คำถามจากลูกค้าหลายครั้งก็ถูกส่งมาในขณะที่เค้ากำลังอยู่ในขั้นตอนการ develop หรือ test ระบบ ซึ่งอาจจะไม่ร้อนแรงมาก แต่เมื่อไหร่มันมาจาก production environment มันจะเริ่มมีความร้อนขึ้นมาหน่อยๆ - -‘’ ต้องตอบให้เร็วขึ้นและหาต้นเหตุ (root cause) ให้เร็วมากขึ้น ซึ่งเคสแบบนี้ก็มีมาให้ทำเรื่อยๆ งาน specialized technical support แบบนี้มันมีอยู่เฉพาะบริษัทใหญ่ๆที่มีฐานลูกค้าใหญ่ และ “ชัดเจน” เรื่อง support เท่านั้น ดังนั้นมันก็ตามมาด้วยข้อเสียว่า career path ถ้าอยากจะโตในสาย technical มันค่อนข้างจะแคบมากอยู่

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

อีกเรื่องที่ได้ไปเต็มๆคือได้เห็นว่าคนที่เค้าอยากได้ real-time financial data ไปเนี่ยเค้าเอาไปทำอะไรกัน เรื่องนี้ก็ช่วยเพิ่มความสนใจในเรื่อง finance ให้ผมได้ระดับนึงเลยล่ะ >_<’ ตอนนี้แอบสนใจเรื่องแนวๆ Quantitative Finance อยู่หน่อยๆ มันก็เป็นความเชื่อส่วนหนึ่งของผมเลยแหละว่า skill ด้าน software development ของพวกเราวิศวคอมเนี่ย มันจะมีค่ามากที่สุดต่อเมื่อเรารู้เรื่องใน domain อื่นในเชิงลึกคู่กันไปด้วย หลายๆครั้งผมเลยพยายามหาอะไรใหม่ๆทำดูบ้าง

เรื่อง technical ผมยังไม่รู้สึกว่า skill ตัวเองพัฒนามากขึ้นเท่าไหร่ ส่วนหนึ่งเพราะบริษัทมีอะไรๆที่มันเป็นของภายในให้เรียนรู้เต็มไปหมด ประโยชน์ที่เราจะได้ติดตัวไปจากการศึกษาเรื่องพวกนี้มีแค่ idea และ concept ว่าระบบแบบนี้เค้าสร้างกันขึ้นมาให้ประสบความสำเร็จและขายได้ได้ยังไง ผมรู้จักเทคโนโลยีพวก Low-latency Message Bus ละเอียดขึ้นระดับนึงเลย ส่วนเรื่อง implementation มันก็มีการยอมรับและใช้กันแพร่หลายในบริษัทกลุ่ม financial นั่นแหละ ถ้าเปลี่ยน industry ขึ้นมา ความรู้ในระดับ imlementation พวกนี้ก็อาจจะไม่ได้ใช้เลย

ตั้งแต่ทำงานผมยังไม่เคยเจอปัญหาแบบที่เป็น technical แล้วปวดตับไป 3 วันอะไรแบบนั้นด้วยแหละ >_<’ ความลำบากส่วนใหญ่เป็นเรื่องวิธีการค้นหาข้อมูลมากกว่า ช่วงแรกๆที่ทำงานผมบ่นตลอดเวลาว่าอยากได้ internal google เพราะหาอะไรแทบไม่เจอเร้ยยย วิธีการแก้ปัญหาแบบปกติที่เอา keyword ไป search, เจอบลอก, แล้วแก้ปัญหา ไม่สามารถเอามาใช้ได้ที่นี่ ต้องเปลี่ยนวิธีการมาเป็นการค้นในตัว documentation จริงๆ แล้วก็ต้องทำความเข้าใจกับโค้ด C/C++ ขนาดใหญ่มากที่เราไม่ได้เป็นคนเขียนเอง - -‘’ มันก็เหนื่อยอยู่ แต่พอปรับตัวได้มันก็สนุกและทำให้เรากล้ามากขึ้นที่จะเข้าไปรื้อโค้ดของคนอื่นนะ นอกจากนี้ก็มี flight บังคับให้เรียนรู้เทคโนโลยีเก่าๆเพราะต้อง support บ้าง บางทีผมเห็นเพื่อนๆได้ทำงานที่เรียนรู้อะไรใหม่ๆ (โดยตัวเนื้องานเอง) ก็มีอิจฉาบ้างนิดหน่อย แต่ที่นี่ก็ยังเปิดโอกาสให้มี internal project เอามาทำได้เรื่อยๆนะ โดยถือว่าเป็นส่วนหนึ่งในการพัฒนาตนเองของพนักงาน

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

• มีความสามารถที่เป็น hard skill ในการทำงานตามงานที่กำหนดได้
• เข้าใจเรื่องทั่วๆไปเกี่ยวกับการทำงานในบริษัท: career path, โครงสร้างเงินเดือน, การประเมิน performance, โครงสร้างองค์กร
• ได้อยู่ในบรรยากาศการทำงานในบริษัท มีการทำงานร่วมกับคนอื่น เห็นความขัดแย้ง ….. blah balh

โดยรวมๆผมยัง enjoy กับการทำงานครับ พี่ร่วมทีมใจดี ขนมเยอะ ชีวิตราบรื่นจนรู้สึกว่า เฮ้ย สบายไปเปล่าวะ - -‘a (เอ๊ะ! ยังไง) อย่างไรก็ตาม กฎของแก๊น ยังเป็นจริงอยู่ครับ

เลือกได้แค่ 2 อันจาก

• งานสนุก ท้าทาย ได้เรียนรู้อะไรใหม่ๆ
• มีเวลาว่าง และมี work-life balance หรือเป็น family man
• จ่ายดีมาก มีตังค์ซื้อของ Apple

ถ้าใครทำให้ตัวเอง “เชื่อ” ได้ว่ามีทั้ง 3 อย่างพร้อมกัน ผมว่าคุณประสบความสำเร็จระดับนึงแล้วครับ ;)

หวังว่าคนอ่านคงได้อะไรไปบ้างครับ (พี่ที่ทีมถ้าหลุดข้ามาอ่านก็อย่าลืมคอมเม็นต์นะ :P) หลักกิโลหน้าคงเป็น “ทำงาน 3 – 4 ปี แรก”

Life career, reuters

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

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

• โค้ดสมัยเรียนค่ายโอลิมปิก
• โปรแกรมรายรับรายจ่ายง่ายๆบน Windows Mobile และโปรแกรมอื่นๆที่เคยส่ง บ.สามารถ
• โปรแกรม ChemLive! ที่ส่ง MS Imagine Cup
• โปรเจควิชา Database + Software Engineering ที่คณะ
• โปรเจคที่เคยส่งงาน RFID ของ NECTEC
• โปรเจคย่อยๆมากมายในวิชาเรียนอื่นๆ เช่น Fund Dist, Computer Security, Operating System, Computer Graphics, Image Processing, ..

ถ้าถามถึงโปรเจคทั้งหมดที่ยกมา ผมแทบ “จำไม่ได้” เลยว่าทำอะไรไปบ้างและได้อะไรมาบ้าง งานที่ทำไปบางชิ้นเอาไปวางไว้ที่ไหนก็ไม่รู้เหมือนกัน

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

• ผมไม่มั่นใจในงาน งานบางอันที่ต้อง “รีบปั่นรีบส่ง” หลังงานเสร็จ ผมจะคิดในใจ (ดังๆ) ว่า “ของมันไม่ดีจริง” แล้วหลังจากนั้นถ้ามีโอกาสอะไรที่จะเอาไป “ต่อยอด” งานได้ ผมจะรู้สึกหวั่นๆ เหมือนกำลังโดนจับผิด หลายครั้งมีโอกาสดีๆเช่น บ.ข้างนอก อยากให้เอาโปรแกรม ChemLive! ไปทำต่อ ผมก็ (น่าจะ) เป็นคนเดียวในทีมที่ไม่สบายใจเอาซะมากๆ ผมไม่อยากแบกรับภาระจากการซ่อมบำรุงงานที่ผมไม่มั่นใจ งานบางชิ้นในลักษณะนี้ก็เลยหายไปจากสารบบโดยปริยาย –..-‘’ เป็นนิสัยเสียที่น่าจะโดนเพื่อนๆร่วมทีมว่าอยู่เยอะเหมือนกัน
  
• งานไม่มั่นใจในผม หลายครั้งการเอางานที่เราคิดว่า “นี่ทำมาดีมากแล้วนะ” ไปส่งประกวด แล้ว Feedback จากกรรมการมันไม่เป็นไปอย่างที่คิด มันก็ทำให้เสียกำลังใจและพาลไม่อยากทำต่อได้ครับ ตัวอย่างที่เข้าเคสนี้คือโปรแกรม RFID ที่ค่อนข้างจะทุ่ม effort กันสูงมากทั้งทีม แต่มีปัญหาเรื่องการนำเสนอ (อ่านต่อที่ “การนำเสนอสำคัญกว่าโค้ด”)
  
• ผมกำลังทำการบ้านส่ง ผมไม่ได้เขียนโค้ด อันนี้เป็นพวกโปรเจคในคณะ ที่ส่วนใหญ่จะมีเดดไลน์และ scope ชัดเจน มันต่างจาก “ปั่นส่ง” ในข้อแรกตรงที่ งานในลักษณะนี้ มันเป็น “ปั่นส่ง” จากเริ่ม คือก็ทำให้เสร็จๆไปงั้น แต่ในเคสแรกตอนแรกอาจจะทำด้วยความสนุก แต่ตอนหลังโดนบีบให้ปั่น พอส่งเสร็จก็ลืมไปเลยว่าเคยทำ เช่นพวก Database หรือ Software Engineering

จวบจนสองโปรเจคสุดท้ายก่อนเรียนจบ คือ Game Programming กับ Senior Project  ผมก็รู้สึกว่าได้สร้าง “คุณค่า” ไว้พอสมควร

อย่างแรกคือ Game Programming ผมไม่รู้สึกว่าโค้ดตัวเองที่เขียนร่วมกับเพื่อนๆอีก 2 คนมัน “เละ” ถ้ามีโอกาสให้กลับไปทำโปรเจค Ogre อีกรอบนี่จะเป็นที่แรกที่ผมกลับไปดู :) 

ส่วน Senior Project ถึงแม้ผลลัพธ์มันจะออกมาไม่ดีเท่าไหร่และได้ชมเชยใน NSC แต่ผมก็รู้สึกว่าได้ตั้งใจทำเต็มที่แล้ว และทุกอย่างที่ทำทุกวันนี้ก็เข้าถึงได้โดยง่ายเพราะเอาไปวางไว้บน Project Hosting หลายครั้งยังต้องเข้าไปดู Code C++ ที่ตัวเองเขียนอยู่เลย (เพราะบางทีจำไม่ได้ว่าเขียนยังไง - -‘’)

ผมมีแนวทาง (ที่ตอนนี้ใช้อยู่เอง) ในการเพิ่ม “คุณค่า” ให้โปรแกรมที่เขียนดังต่อไปนี้

1. พยายามทำให้ Source Code ที่เขียนและงานที่ทำเข้าถึงง่ายที่สุด สมัยนี้มีเว็บประเภท Project Hosting ให้ใช้เยอะแยะ ทั้ง Git Hub, Google Code, Code Plex, Source Forge (แต่ก่อนประเทศไทยมี Code Bank ด้วย แต่ไม่รู้เจ๊งไปรึยัง)
2. จดบันทึกสิ่งที่ทำอยู่ ไม่ต้องละเอียดมาก (แต่ก็อย่าแย่ถึงขั้น “โอ้ววว ไพธอนหล่อแสรดดด” –..-‘a) เอาแบบไว้อ่านคนเดียวก็ได้ จะ Tweet หรือจะ Blog ก็น่าจะเวิร์คเหมือนกัน อันนี้จะเหมือนการ Document ตลอดเวลา แล้วตอนหลังเวลาติดปัญหาเดียวกันจะได้กลับมาดูได้ นอกจากนั้นอาจจะได้วิธีการที่ดีกว่าเดิมจากเพื่อนๆที่มาอ่านอีก (แนะนำวิธีจด)
3. วิ่งเข้าหาสิ่งใหม่ๆให้บ่อยๆ ในงานที่ทำเล่นๆหรือที่เดดไลน์มันไม่บีบคั้นมาก ลอง “เลือก” อะไรที่มันแตกต่างจากเดิม (และดูดีมีอนาคต :P) มาลองบ้างดีมั้ย?? สมัยนี้มีพวก Framework, Libraries, ภาษาใหม่ๆ ให้ลองใช้เยอะแยะ
4. อย่าปั่นงาน ..ทำยากโคดว่ะ

ขอให้สนุกกับการเป็นนักเขียนโค้ด “เชิงคุณค่า”

Direction value coder, career, thought

อ่ะแฮ่ม ความเดิมจากตอนที่แล้ว กรุณาอ่าน ทำงานสัปดาห์แรก และ ทำงานเดือนแรก

เป็น Support Consultant ทำอะไรบ้าง

ตอนนี้ทุกอย่างชัดเจนสุดๆครับว่าในแต่ละวันต้องทำอะไรบ้าง งานของผมคือการแก้ปัญหาและคำปรึกษาให้กับลูกค้าของรอยเตอร์ที่ใช้ผลิตภัณฑ์ตัวหนึ่ง จริงๆไอ่ผลิตภัณฑ์ที่ว่าจริงๆแล้วมันเป็น API สำหรับรับและส่งข้อมูลการเงินแบบเช่นพวกราคาหุ้น อะไรทำนองนั้น เราเรียกคำร้องขอของลูกค้าที่ส่งเข้ามาว่า Service Request หรือ SR โดยที่ SR ที่ว่าก็จะถูกกระจายให้กับ Consultant แต่ละคนทั่วถึงกัน จากที่เห็นมา SR ก็มีทั้งแบบง่ายๆ เช่นขอให้สอนวิธีใช้โปรแกรมตัวอย่าง หรือกระทั่งปัญหาที่เกิดบ้างไม่เกิดบ้างบน production (ถ้าเจอ SR แบบนี้กับตัวจะทำยังไงหว่า - -‘’) การโต้ตอบของทีมที่ผมอยู่จะทำผ่าน E-mail เท่านั้น ซึ่งจริงๆแล้วก็มีทีมอื่นอีกเหมือนกันที่ให้บริการแบบ On-site ราคาก็คงต่างกันล่ะมั้ง also …)

งานที่ทำส่วนใหญ่ก็จะเป็นการไล่โค้ด C++ ที่ใหญ่มากของ product ที่ลูกค้าไม่เห็น (text files ใหญ่รวมกันแค่ประมาณครึ่งร้อยเมกเอง :P) การขอข้อมูลจากทีมอื่นเพื่อเอามาประกอบการแก้ไขปัญหาและการโต้ตอบลูกค้า การพยายามสร้างปัญหาแบบเดียวกับที่ลูกค้าเจอให้เกิดที่ site ของเรา หรือเรียกว่าการ Reproduce ซึ่งเท่าที่เห็นหลายครั้งมันก็ยาก และก็การพยายามหาสาเหตุของปัญหาให้เจอ หรือที่เรียกว่า Root Cause

ได้ทำอะไรใหม่ๆบ้าง

สิ่งที่รู้สึกว่าใหม่ที่สุดกับตัวเองด้าน Technical คงเป็นเรื่อง Unix เพราะว่า product มันรันบนพวก Linux/Unix ด้วย ยิ่งช่วงหลังๆที่ได้ทำ SR Exercise ซึ่งเป็นการจำลอง SR พวกพี่เค้าก็เอาเคสที่ปัญหาเกิดเฉพาะบน Unix มาให้ทำ  ก็เลยต้องใช้ Unix

ตอนเข้ามาทำงานทีมนี้ก็จะได้เครื่องที่เป็น Solaris/SPARC ไว้ใช้แต่มันจะตั้งอยู่ในห้อง server ต้อง remote เข้าไป วันๆมาทำงานมีจอสองจอก็เลย Dedicate จออันนึงให้กับ PuTTy ไปเลย แล้วก็มี VIM  ซึ่งถือได้เลยว่าเป็นโปรแกรมที่ถ้าขาดไปผมคงทำอะไรบน Unix ไม่ได้สะดวกโยธินเท่าทุกวันนี้ T-T (ซาบซึ้งมาก)

ลูกค้าส่วนใหญ่ของทีมที่ผมทำอยู่ก็เป็น Developers ในสถาบันการเงินทั่วโลก และก็โต้ตอบกันผ่านทาง E-mail เท่านั้น ตอนรอยเตอร์มารับสมัครมีเพื่อนผมหลายๆคนสมัครตำแหน่งนี้ ตอนนั้นยังพวกเราก็ยังเป็นเด็กน้อย~ คงคิดว่าจะได้ติดต่อลูกค้า พาไปเลี้ยงข้าว ตีกอล์ฟ อะไรแบบนี้ - -‘’ 555+

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

ความจริงอีกอย่างที่ค้นพบ และ (สำหรับผม) น่าตกใจ คือมีคนอีกจำนวนมากที่เป็น “มหาเทพ” ด้าน technical แต่ไม่เคยปรากฎตัวออนไลน์! ผมคิดไปเองมาตลอดว่าคนเก่งๆในไทยอย่างน้อยก็น่าจะเคยปรากฎตัวใน community บ้าง แต่จริงๆมันไม่ใช่ครับ มีกลุ่มคนดังกล่าวเยอะมาก

ความสัมพันธ์ของ Support QA และ Developer

งานในรอยเตอร์ที่ไม่ใช่ Management มักจะจัดอยู่ใน 3 สปีชีส์นี้ได้เสมอครับ โดยปกติ Dev และ QA จะทำงานร่วมกันอยู่แล้ว ดังนี้

• Dev เขียนโค้ด QA เทสต์
• Dev แก้โค้ด QA เทสต์

เวลา Support รับ SR เข้ามา บางครั้งก็จะพบ Bug ในตัว product ก็จะส่งเข้าไปให้ Dev พิจารณาว่าจะแก้หรือไม่แก้ หรือบางครั้งก็เป็นการขอ Feature ใหม่ๆจากลูกค้า ก็ส่งให้ Dev พิจารณาอีกเหมือนกัน หลังจาก Dev จัดการเสร็จก็ส่งให้ QA ดูต่อตามสเตปเดิม

เค้าว่ากันว่าหน้าที่ของ Support คือปกป้อง Dev จากความวุ่นวายและความไม่เที่ยงตรงของโลกภายนอก (ลูกค้านั่นแหละ :P) ทำให้ Dev ได้มีเวลาโฟกัสกับสิ่งที่กำลังพัฒนาอย่างเต็มที่ เท่าที่เห็นมันก็เป็นแบบนั้นจริงๆนะครับ เวลาส่งพวกรายงาน Bug ไปอันนึงนี่ เขียนขั้นละเอียดขนาดอ่านจบรอบนึงก็แก้ได้เลย ไม่ต้องเสียเวลาไปไล่โค้ดเองอีกแล้ว

มนุษย์เงินเดือน

หลังจากมีเงินเดือนเป็นของตัวเองป๊าม๊าไม่เลี้ยงแล้ว เรื่องนี้ก็เป็นอีกเรื่องที่ต้องให้ความสนใจ ประเด็นสำคัญ (ในระยะสั้น) ก็คงมีเรื่องของการเอาเงินไปลงทุน แล้วก็เรื่องภาษีล่ะมั้งครับ ข้อดีอีกอย่างของการทำที่นี่คือทำให้ตื่นตัวเรื่องการเงินมาก เพราะข้อมูลมันไหลอยู่ตลอดเวลา งานที่ทำก็เรื่องการเงิน ตอนนี้ส่วนตัวก็ศึกษาเรื่องการลงทุนอยู่บ้าง รู้สึกว่าเป็นเรื่องหนีไม่พ้นที่ซักวันนึงต้องเจอครับ ตอนนี้ก็เปิดพอร์ตกับ KIM ENG เรียบร้อยแล้ว (หลังจากขี้เกียดอยู่นาน) อยากให้เพื่อนๆมาเป็นแมงเม… เอ้ย! มาศึกษาเรื่องการลงทุนด้วยกันเยอะๆครับ จะได้คุยกันได้ :)

ชีวิตช่วงนี้

ช่วงนี้ก็พยายามลดน้ำหนัก (อีกแล้ว) แต่ครั้งนี้รู้สึกมีหวังมากกว่าครั้งอื่นๆครับ โดยมีหลักการดังนี้

• กินสุกี้แห้งทะเล ตอนเที่ยง ทุกวัน (กินมาเดือนกว่าแล้ว เริ่มเบื่อ)
• วัน จ. – ศ. ไม่กินข้าวเย็น เสาอาทิตย์ ตามสบาย
• เต้นแอโรบิคเวลา 9:30 วัน จ. – ศ. (ทำมาได้ไม่นาน แต่เริ่มเบื่อหน้าครูสอนเต้นในวีดิโอแล้ว อยากหามาเพิ่ม)

ก่อนหน้านี้มักจะไปวิ่งออกกำลังกายที่สนามกีฬา (แห่งชาติ) แต่หลังๆรู้สึก overhead มันเยอะดังต่อไปนี้ ก็เลยเลิกไปแล้ว

• ทำให้ iPod มีแบตก่อน และมีเพลงใหม่ที่ยังไม่เบื่อ
• ใส่ถุงเท้า กางเกงวิ่ง รองเท้าวิ่ง เสื้อ
• เดินออกไปที่สนามกีฬา (รวมไปกลับประมาณ 15 - 20 นาที)
• วิ่ง (ประมาณ 20 – 30 นาที : เวลาต่ำสุดเพื่อให้เริ่ม Fat burn)

นอกนั้นก็ไม่ได้ทำไรมากมายครับ เล่น Street Fighter 4 บางวันอยากอ่านหนังสือก็อ่านบ้าง ศึกษาเรื่องการลงทุน (อย่างช้าๆ T-T แรงผลักดันมันต่ำน่ะ)

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

ปล. วันนี้โครตตั้งใจเขียนเลย อย่างที่เห็น

ปล2. ทำไมวันนี้เขียนได้ “ชีวิต” ขนาดนี้ T-T ไม่มีโค้ดซักบรรทัดเดียว

ปล3. อยากอ่านเรื่องทำนองเดียวกันจากเพื่อนๆนะครับ :)

Life reuters, fat burn, games, career, adsl

เดือนเมษายน 2552 ที่ผ่านมาเป็นเดือนแรกที่เข้าทำงานที่ Thomson Reuters เคยเล่าสั้นๆไปก่อนหน้านี้รอบนึงแล้วเรื่อง ทำงานสัปดาห์แรก สนใจลองอ่านดูได้นะจ๊ะ : )

ตอนนี้เพื่อนๆที่เข้าบริษัทไปตอนเดือนเมษาพร้อมกันก็มีหลายแผนก ทั้งเป็น Developer, QA, Infra และ Support จากที่ฟังมาดูเหมือนทุกคนจะถูก assign งานเป็นชิ้นๆกันหมดแล้ว แต่ผมยังต้องเทรนตามโปรแกรมอีก ~ 3 เดือน ก่อนจะเริ่มให้ Service ได้จริงๆ o__o’ หนทางยาวไกลเหลือเกิน ตอนนี้ที่เครื่องยังไม่มี Compiler เลยฮะ เหงาจัง T-T

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

ที่ทำงานมีเครื่องคอมพิวเตอร์ประจำตัวให้เป็น Dell รุ่นหนึ่ง  .. ซึ่งจริงๆแล้วเป็นรุ่นที่ลังเลก่อนหน้าจะถอย Thinkpad X200 เลยทีเดียว (จำได้ว่าน้ำหนักมันเบาพอๆกัน) อดรุสึกไม่ได้ว่าซื้อโน้ตบุ๊คมาไม่ค่อยคุ้มเลยแฮะ แหะๆ และเนื่องจากว่ามันเป็นรุ่นใหม่มากกกก ก็เลยได้กลายเป็นคนดังของแผนก RDC มีพี่ๆมารุมล้อมในชั่วข้ามคืน …’’

มีคอมก็ต้องใช้โปรแกรม แต่โดยปกติ จะลงโปรแกรมอะไรแปลกๆเพิ่มบนคอมต้องขออนุญาตก่อน ดังนั้นเลยต้องเป็นเด็กดี ใช้ IE6 เข้า GMail มันปรับให้เป็นโหมด Simple ให้อัตโนมัติ เศร้ามาก .. แต่ตอนนี้แฮปปี้แล้วด้วยเหตุผลบางอย่างครับ หึหึหึ

เอาไว้แค่นี้ก่อนดีกว่า ถ้ามีเหตุการณ์ตื่นเต้นจะเล่าต่ออีกรอบ :D

Life reuters, career

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

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

งานมันเริ่มจากการที่ลูกค้าส่ง Ticket เข้ามาครับ ซึ่งก็จะถูกส่งแยกย่อยเข้าไปในทีมย่อยของ Support อีกรอบนึง เช่น ลูกค้าที่ใช้ API ชุดนี้ ก็จะติดต่อกับ Support ที่ดูแล API ชุดนี้ เป็นต้น

Ticket ก็จะระบุรายละเอียดไว้ในรูปแบบค่อนข้างชัดเจนครับ ว่าปัญหาคืออะไร ต้องการอะไรจาก Support พร้อมแนบโค้ดที่สำหรับใช้ Reproduce ปัญหามาด้วย หรือถ้าเลวร้ายหน่อยเราก็ต้องดูรายละเอียด แล้วหาวิธี Reproduce เอง ไอ่คำว่า Reproduce นี่หมายถึงการทำให้ปัญหาแบบเดียวกับที่เกิดที่เครื่องลูกค้า มาเกิดขึ้นที่เครื่องของเราครับ จะได้สามารถแก้ปัญหาให้ได้ แต่ถ้า Reproduce ไม่ได้ คือทำงานที่เครื่องลูกค้ามีปัญหา แต่ทำงานที่เครื่องเราได้ปกติ ก็อาจจะเกี่ยวข้องกับ Environment บางอย่าง เช่น version หรือ config file หรือ วันเวลา หรือแม้กระทั่ง hardware ที่ใช้ครับ (64 หรือ 32 บิต ก็เป็น concern)

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

จากการได้เข้าร่วมประชุมกับพวกพี่ๆเค้าหนึ่งครั้ง (ซึ่งฟัง Jargon ภายในรู้เรื่องแค่บางตัวตลอด 2 ชม.) ก็พอจะทราบว่าปัญหามันก็ไม่ได้ง่ายเหมือนแก้บั๊กให้เพื่อนนัก +_+ การประชุมก็จะเป็นการสรุปเคสที่ทำไปในหนึ่งสัปดาห์ และช่วยกันออกความคิดเห็นเรื่องเคสที่ยังไม่เสร็จสิ้น หรือยังแก้ไม่ได้ เป็นการช่วยกัน Brainstorm แอบหวั่นๆเหมือนกันว่าพอทำงานจริงผมจะไหวรึเปล่า หรือจะหลุดวงโคจรรอยเตอร์ T_T ดังนั้นสรุปว่างานนี้นอกจากจะเน้น Technical Skill แบบกว้างๆแล้ว Analytical Skill และ Experience ก็สำคัญเช่นกัน

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

การเทรนสองวันที่ผ่านมาก็เป็นเรื่องภายในบ.ทั่วๆไป เช่น Policy ในการลงโปรแกรม หรือเรื่องสวัสดิการจากทาง HR โปรแกรมเทรนนิงพิเศษ การสนับสนุนค่าสอบ cert เป็นต้น ที่ผมรู้สึกว่าน่าตื่นเต้นที่สุดคงเป็นการสอบ IKM TeckCheck นี่แหละครับ เป็นการสอบวัดคะแนน Skill ในแต่ละหมวด (C++/C#/Java/Unix/Network) ว่าเป็นยังไง คะแนนก็จะถูกส่งไปที่ manager ด้วยแต่ก็จะไม่มีผลกับการคิด Performance หรืออะไรใดๆทั้งสิ้น โดยคะแนนที่ได้มาจะบอก ranking เทียบกับคนที่สอบเทสต์ตัวนี้ทั้งหมด เป็น percentile ก็น่าสนุกดีครับ พี่ที่พูดเรื่องนี้ให้ฟังเล่าว่ามีคนที่ได้ percentile 100 ในรอยเตอร์ก็หลายคนอยู่ คิดว่าคงไม่เตรียมตัวอะไรไปเพิ่มเติมจริงจังนัก เพราะยังสอบได้อีกหลายครั้ง

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

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

Life career, reuters