ในความดิบมีความหวาน

May 11, 2009 by chatchai

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

ที่มึงมาเฝ้ากูบ่อยๆเนี่ย คิดไรกับกูป่าว มีคนเค้าสงสัย
— เออ
เออ เหี้ยอะไร
— เออ กูคิด
นี่มึงอย่ามาล้อเล่นนะ
— กูป่าว

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

read more

วางปืนคืนเมือง

Oct 8, 2008 by chatchai

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

There is no abstraction in the world that is worth taking other people”s lives for.

ไม่มีหลักการนามธรรมอันใดในโลกมีค่าพอให้เราไปเอาชีวิตผู้อื่นมาสังเวย
ไม่ว่าสังคมนิยม-คอมมิวนิสต์
หรือประชาธิปไตย!

read more

ผมรู้แล้วว่าทำไมผู้ชายถึงเลว

Sep 15, 2008 by chatchai

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

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

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

read more

Spurious Wakeup

Sep 14, 2008 by chatchai

I have finished reading Effective Java long time ago. It is such a great book. The more I passed through each page the more I realized how little I know about java programming. The distance between “coder” and “developer” is really far

I read most of the item listed in the book. One of the items I have skipped was Item 50: Never invoke wait outside a loop. The code below show the concept of this item

synchronized (obj) {
    while (<condition does not hold>)
        obj.wait();

     ... // Perform action appropriate to condition
 }

Looking at the name of the practice, I thought I knew all the reasons behind it so I just skipped it. Today I found an interesting post asking What is spurious wakeup. I read it and found that “threads can wake up on wait() for no reason at all”!!!!! There are quite many good references for this fact and one of them is, guess what, the item 50 of Effective Java. I would have known it for long time ago if I just read it. One of the reasons behind it stated in the item is that

The waiting thread could wake up in the absence of a notify. This is known as a spurious wakeup. Although The Java Language Specification [JLS] does not mention this possibility, many JVM implementations use threading facilities in which spurious wakeups are known to occur, albeit rarely [Posix, 11.4.3.6.1]

I thought sometimes it was OK to call wait() without condition-checking loop if the object to wait on represented just one condition, the object was shared only between waiting and notifying threads and the code’s execution order guaranteed that wait leaks would not occur. Now giving that JVM implementation can send spurious wakeup signal, the condition checking loop is A MUST

Apparently, the spurious wakeup is an issue (I doubt that it is a well known issue) that intermediate to expert developers know it can happen but it just has been clarified in JLS third edition which has been revised as part of JDK 5 development. The javadoc of wait method in JDK 5 has also been updated

A thread can also wake up without being notified, interrupted, or timing out, a so-called spurious wakeup. While this will rarely occur in practice, applications must guard against it by testing for the condition that should have caused the thread to be awakened, and continuing to wait if the condition is not satisfied. In other words, waits should always occur in loops

You may wonder (like me) why JLS designer decided to allow this kind of thing to happen. It’s not that I don’t want to use condition checking loop. The checking is the best practice that developers should always do no matter of them knowing anything about the spurious wakeup or not. But I just don’t see the benefit of allowing the wakeup for no reason. It turns out that this is something about performance as stated in Multithread Programming with Java

Due to some arcania in the hardware design of modern SMP machines, it proves to be highly convenient to define them like this. The hardware runs a little faster, and the programmer needs to reevaluate the condition anyway

read more

10 เรื่องที่โปรเจคเมเนเจอร์อยากให้ดีเวลลอปเปอร์เข้าใจ

Sep 14, 2008 by chatchai

Translated from : 10 things Project Managers wish Developers understood
Author : Frank Kelly

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

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

ดีเวลลอปเปอร์ : คุณยังจำปัญหาเรื่อง GUI ในสัปดาห์ที่แล้วได้หรือเปล่า?
(อีกนัยหนึ่งคือ: เจ้าปัญหาร้ายแรงนั่น ที่ผมหาทางแก้ได้ในที่สุดนั่นไง)
เมเนเจอร์: ปัญหาอันไหนละ?
(อีกนัยหนึ่งคือ: ผมเพิ่งจะใช้เวลา 3 ชั่วโมงในการตอบเมลล์กับคนอื่นอีก 14 คน และผมเหนื่อยเหลือเกิน)

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

• จะมีกี่ไฟล์ที่ได้รับผมกระทบจากการแก้ปัญหานี้ละ
• การเปลี่ยนของ SQL อันนี้จะกระทบกับประสิทธิภาพการทำงานยังไง
• การเปลี่ยนของ GUI นี้จะกระทบต่อการทำงานของลูกค้าหลักของเรายังไง
• ถ้าเราแก้ปัญหานี้แล้วมันจะไปทำให้เกิดปัญหาที่อื่นหรือเปล่า

8 ) ความเสี่ยงของโปรเจค: เทคโนโลยีใหม่ = ความเสี่ยง
ทุกครั้งที่คุณเริ่มต้นโปรเจคใหม่ ดีเวลลอปเปอร์ก็ชอบที่จะใช้เทคโนโลยีใหม่ๆ แต่คุณจะทุ่มทุกอย่างลงไปกับเทคโนโลยีใหม่ไม่ได้ เทคโนโลยีใหม่ย่อมจะนำความเสี่ยงมาสู่โปรเจค ประสิทธิภาพอาจจะเพิ่มขึ้นแต่มันจะคุ้มกับความเสี่ยงหรือเปล่า
ผมเคยมีเมเนเจอร์ที่เอาแต่ปฏิเสธเทคโนโลยีใหม่ๆ เขาไม่เข้าใจถึงความต้องการของดีเวลลอปเปอร์ ในการพัฒนาตัวเองและเรียนรู้เทคโนโลยียอดฮิต (อย่างเช่น Ajax)/ เฟรมเวิร์ค (อย่างเช่น Spring) มันช่างไม่เป็นที่น่าจูงใจเอาเสียเลย อีกอย่างหนึ่งคือ เทคโนโลยีมักจะช่วยให้ทำงานได้ประสิทธิภาพมากขึ้น มันไม่ใช่แนวคิดที่มองการณ์ไกลเลย ในการเอาแต่ปฏิเสธเทคโนโลยีใหม่ๆ
ผมก็เคยมีเมเนเจอร์ ที่คอยแต่มองหาเทคโนโลยีใหม่ๆเหมือนกัน แล้วโปรเจคก็ไปติดแหง่ก อยู่กับปัญหาทางเทคนิคอันแล้วอันเล่า และไม่เคยทำให้ซอฟแวร์ทำงานได้ ภายในเวลาที่กำหนดได้เลย เนื่องจากดีเวลลอปเปอร์ต้องใช้เวลามาก ในการเรียนรู้เทคโนโลยีใหม่ๆเหล่านั้น ในฐานะที่ผมก็เป็นดีเวลลอปเปอร์ ผมเข้าใจว่าพวกเขารักที่จะเรียนรู้ แต่ในฐานะของเมเนเจอร์ ผมต้องชั่งน้ำหนัก ระหว่างแรงจูงใจของดีเวลลอปเปอร์ กับเป้าหมายในการทำให้โปรดักสำเร็จใช้งานได้

7) ประสิทธิภาพ: เมเนเจอร์ที่ยอดเยี่ยม จะกันดีเวลลอปเปอร์ออกจากเรื่องบ้าบอต่างๆ ที่เกิดขึ้นในระหว่างการบริหารงาน อย่างเช่น เสปคที่ไม่ได้เรื่อง, แนวความคิดแปลกๆ, การเปลี่ยนลำดับความสำคัญของงาน หรือการประชุมที่มากจนเกินไป
ถ้าคุณคิดว่าหัวหน้างี่เง่า (pointy haired boss) ของคุณนั้นช่างเสียสติจริงๆ รอให้คุณเห็นพวกคนที่เขาทำงานให้ก่อนเถอะ ปัญหาในการพัฒนาซอฟแวร์ในปัจจุบันก็คือ มันต้องเกี่ยวข้องกับทีมมากมายหลายทีม ทีมของดีเวลลอปเปอร์, ทีมของ QA, ซัพพอร์ท, ฝ่ายลูกค้าสัมพันธ์, ฝ่ายที่ปรึกษา และทุกคนต่างก็มีมุมมองและเป้าหมายของตัวเอง พวกเขามีมุมมองในภาพที่ใหญ่กว่า หรือเป็นอีกมุมมองหนึ่งต่างออกไปเลย ดีเวลลอปเปอร์บางคนก็พอคิดได้ว่า ขณะที่สิ่งเหล่านี้ดำเนินไปนั้น เมเนเจอร์กำลังกันเวลาไว้ เพื่อให้คุณทำงานได้อย่างมีประสิทธิภาพ และทำในสิ่งที่คุณรัก นั่นคือการเขียนโค้ด

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

5) ทำในสิ่งที่เราไม่อยากทำ: เราเรียกประชุมก็เพราะมันเป็นสิ่งที่จำเป็น
ผมรู้ว่าการประชุมนั้นขัดจังหวะการเขียนโค้ด อันเป็นกิจกรรมสุดโปรดของคุณ แต่มันก็เป็นสิ่งที่ช่วยไม่ได้เลยในบางโอกาส ผมต้องการรู้ว่า คุณเข้าไจความเป็นไปในขณะนี้หรือไม่ จริงๆแล้วผมแทบจะไม่รู้เลยว่า ความคืบหน้าเป็นอย่างไรบ้างแล้ว จนกว่ามันใกล้ๆจะเสร็จโน่นแหละ โชคดีอยู่บ้าง ในฐานะที่ผมก็เป็นดีเวลลอปเปอร์(ในบางโอกาส) ผมใช้เครื่องมือเช่น FindBugs, PMD, CheckStyle เพื่อตรวจสอบโค้ด และใช้ Unit Test กับ Code Coverage เพื่อประเมิณคุณภาพของโค้ดอย่างคร่าวๆ แต่สิ่งที่วัดได้ก็เป็นแค่ตัวแทนของค่าที่ต้องการจริง นั่นก็คือ คุณภาพของโปรดักในมุมมองของผู้ใช้งานเท่านั้นแล้วมีวิธีอื่นไหนอีก ที่จะทำให้ผมรู้ความไปต่างๆได้อย่างรวดเร็ว การประชุมไงละ ขอโทษด้วยแล้วกันนะ

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

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

ดีเวลลอปเปอร์: “คุณรู้เรื่องคลาส Finder ที่ทีม X ทำขึ้นมาหรือยัง พวกเขาสร้าง Factory เมธอดอันไหม่ที่ไม่ปลอดภัยในการทำงานกับ thread ขึ้นมา ผมคิดว่ามันบ้ามากเลยละ พวกเขาไม่รู้เลยหรือไงว่า thread pool ของเราจะ … … …”
เมเนเจอร์(ผู้ที่กำลังครุ่นคิดอย่างหนักกับเรื่องอื่นอยู่ อย่างความขึ้นต่อกันต่างๆในโปรเจค): (คิดในใจ) เขาจะคิดว่าผมเป็นพวกงี่เง่าหรือเปล่านะ ถ้าผมจะตอบแค่ว่า “หือ”

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

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

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

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

read more