Monthly Archives: March 2015

ความเท่าเทียม

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

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

แต่หลังจากนั้นผมก็ได้มีโอกาสฟัง podcast สองอันนี้ ทำให้ผมเข้าใจอะไรมากขึ้น
http://devchat.tv/ruby-rogues/101-rr-diversity-with-ashe-dryden,
http://devchat.tv/ruby-rogues/179-rr-accountability-and-diversity-with-meagan-waller

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

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

แม้กระทั่งผู้หญิงที่เคลื่อนไหวด้านความเท่าเทียม เค้ายังออกมายอมรับว่าบางครั้งเค้าก็ตัดสินคนอื่นจากภายนอกเช่นกัน เค้าเล่าให้ฟังว่าตอนที่เค้าเจอผู้หญิงที่แต่งตัวสวยๆในงาน meetup เค้าคิดทันทีว่าผู้หญิงคนนั้นต้องไม่ใช่ developer แน่ๆ ต้องเป็น recruiter หรือ project manager แน่ๆ แล้วเค้าก็พบว่าเค้าคิดผิด ผู้หญิงเป็นคนนั้นเป็น developer ที่มีประสบการณ์มากกว่าเขาเสียอีก ผมได้ยินเรื่องนี้มาจาก podcast อันนี้ https://thechangelog.com/146/

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

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

อีกเรื่องหนึ่งที่ขัดกับความคิดของเราโดยทั่วไป คือ การที่มีค่านิยมรับคนเข้าทำงานด้วย open source contribution เค้าบอกว่าเราไม่ควรคัดคนออกเพียงเพราะเค้าไม่มี open source contribution มีหลายๆ คนที่เค้าไม่ได้มี public activity บน github แต่เค้ามีความสามารถ ตัวอย่างเช่น ผู้หญิงที่ต้องทำงานบ้าน ต้องเลี้ยงลูก ตามลักษณะครอบครัวแบบเก่า โอกาสในการ contribute open source ก็น้อยกว่าผู้ชายแน่นอน

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

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

คุณพร้อมจะสู้กับความยากลำบากใดในชีวิต

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

ผมมีโอกาสได้อ่าน  blog The Most Important Question in Your Life เค้าเสนอแนวคิดว่า แทนที่จะถามคำถามว่าอยากมีชีวิตอย่างไร ให้ถามว่าพร้อมที่จะเหนื่อย พร้อมที่จะลำบากกับสิ่งใด สิ่งใดที่เราอยากได้แต่เราไม่พร้อมที่จะลำบากเพื่อแลกมันมาถือว่าไม่มีความหมาย ความยากลำบากที่เราพร้อมจะเผชิญเหล่านั้นจะเป็นหนทางสู่ความสำเร็จ

อยากให้อ่าน blog นี้กันเอง ผมรู้สึกว่าอธิบายได้ไม่ดีเท่าเค้า แล้วลองนำมาคิดกับตัวเองดู

ขอยกตัวอย่างตัวเอง ผมอยากเป็น backend programmer เก่งๆ แต่ผมไม่เคยพยายามศึกษาในเรื่องที่ไม่รู้และไม่ถนัด ทั้งการศึกษา algorithm, data structure เพิ่มเติม ไม่เคยขุดไม่เคยลองเขียน OS, compiler, data structure แล้วผมจะเป็น backend programmer ที่เก่งได้อย่างไร หรือจริงๆแล้วผมก็ไม่ได้อยากเป็น เพราะผมไม่เคยใช้เวลาของผมลงไปสู้กับมัน

ได้ยินเรื่องนี้มาจาก Ben Orenstein ในช่วงท้ายบทสัมภาษณ์ของเค้าที่ The Cognicast EP 075

กำลังจะอ่าน Maybe Haskell

กำลังจะเริ่มอ่านหนังสือเล่มนี้ http://maybe-haskell.com/ ไม่คิดมาก่อนว่าจู่ๆ จะซื้อหนังสือ Haskell มาอ่าน แต่ไปหลงพลัง marketing ของคนเขียน จากบทสัมภาษณ์ใน podcast นี้ http://giantrobots.fm/137

เค้าเล่าว่าหนังสือเล่มนี้เล่า Haskell ในวิธีที่ต่างจากเล่มอื่นโดยพยายามอธิบายถึง Functor, Applicative และ Monad ซึ่งผมรู้สึกว่าตรงกับความต้องการพอดี

ส่วนตัวมีความหลังฝังใจกับ Functor นิดหน่อยสมัยพยายามเรียน Haskell เมื่อ 5 ปีที่แล้ว ตอนนั้นเรียนจาก video ชุดนี้ http://channel9.msdn.com/Series/C9-Lectures-Erik-Meijer-Functional-Programming-Fundamentals จำได้ว่าเข้าใจเนื้อหาโดยตลอด จนกระทั่งถึงเรื่อง Functor ที่ไม่เข้าใจเลยทำให้เลิกดู video ต่อไป เลยคาดหวังว่าหนังสือเล่มนี้จะแก้เรื่องที่ค้างใจนี้ได้

อีกแรงจูงใจหนึ่งที่อยากศึกษา Haskell ช่วงนี้ เพราะตั้งแต่ต้นปีมานี้ เริ่มเขียน Clojure ในงานมากขึ้น แล้วเริ่มรู้สึกว่าในบางจุด code maintain ยาก สาเหตุหนึ่งน่าจะเป็นเพราะแบ่ง pure function กับ state ได้ไม่ค่อยดี เลยคิดว่าถ้าได้ศึกษา Haskell ดูวิธีการจัดวาง code ที่แยก side-effect ออกซักหน่อย อาจจะพอได้ไอเดียในการจัดวาง code ใน Clojure มากขึ้น

ถ้ามีโอกาสอ่านได้อ่านจนจบแล้วผลลัพธ์เป็นยังไง จะมาเล่าให้ฟังอีกทีครับ

ปล. ถ้าใครสนใจหนังสือเล่มนี้ ใน podcast page มี link สำหรับลด 50% ด้วยครับ

สรุป The Recipe for the World’s Largest Rails Monolith

เค้าว่าระบบเค้าเป็น Rails app ที่ใหญ่สุดในโลก มาเล่าเรื่องการ scale ให้ฟังอย่างสนุกสนาน
– เขียน auto scaling
– เขียน deploy tool ใหม่
– เขียน activerecord adapter สำหรับ connect multiple databases
– เขียน tool สำหรับเอา spec ไปรันบน aws spot instance
– เขียน database cleaner ใหม่สำหรับ clean เฉพาะ table ที่ถูกแตะตอน test
– เขียน database migration tool ใหม่
– เขียน component framework ใหม่
– เริ่มเขียนปี 2007 ตอน rails 1.x, upgrade มาเรื่อยๆจนตอนนี้ 4.1 แล้ว upgrade โดยการทำ shadow server เปรียบเทียบ output ของ version เก่าและใหม่