Fanboi Channel

มิตรสหายนักพัฒนาซอฟต์แวร์ท่านหนึ่ง

Last posted

Total of 169 posts

140 Nameless Fanboi Posted ID:/h95nb2ahk

เว็บที่ให้เราเขียนโค้ดออนไลน์แต่ละที่มีข้อดีข้อเสียแตกต่างกันครับ ก่อนหน้านี้ผมชอบเขียนบน LeetCode เพราะเขียนโจทย์ได้ดีกว่าที่อื่น อ่านเข้าใจง่าย แต่ช่วงนี้หันมาเล่น Clash Of Code แทนครับ เพราะเน้นให้เราคิดเร็ว พิมพ์เร็ว ไม่ยอมแพ้อะไรง่ายๆ

ช่วงนี้ Clash Of Code มีคนจากเมืองไทยติดอันดับ Top 10 ด้วยครับ ตามมาเชียร์และมาฝึกเขียนโค้ดกันได้ที่นี่ครับ

https://www.codingame.com/multiplayer/clashofcode

141 Nameless Fanboi Posted ID:g963aIIwH9

แคลชพ่อมึงตายแห่งควยโค้ดสตาร์

142 Nameless Fanboi Posted ID:g963aIIwH9

เน็ตเหี้ยและล่มจมเพราะโค้ดสตาร์

143 Nameless Fanboi Posted ID:g963aIIwH9

ศาสนาแรกของโลกก็คือศาสนาโค้ดสตาร์

144 Nameless Fanboi Posted ID:K5IFc0yFCJ

เห็นคนแชร์เรื่องสัมภาษณ์งานในสมาคมอะไรซักอย่าง ทำให้อยากเขียนสิ่งนี้ขึ้นมาเลย

ชีวิตนี้ ผมสัมภาษณ์งานไม่ผ่านเยอะมากเลยนะ น่าจะเยอะกว่าที่หลายคนคิดไว้

แต่สุดท้าย เวลามันใช่ มันใช่ของมันเอง

ตอนที่ผมเข้า Taskworld ใหม่ๆ ใช้ Git เป็นงูๆ ปลาๆ มาก Javascript build รวมกันยังไงก็ไม่รู้ คนอื่นเขา Grunt เขา Webpack ของเราที่ทำมาตลอดยังแค่ใช้ script มารวมๆ กันอยู่เลย เขียน React ก็ไม่เคย ตอนนั้นได้งานทำ SPA มาคือเขียน Framework SPA เล็กๆ เอง เพราะไม่รู้จัก React

ที่อื่นจะไม่รับก็ไม่แปลก จะบอกว่าไม่เชี่ยวชาญพอก็เถียงไม่ได้แหละ

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

=============================

ถ้าเรามองจากมุมของคนที่ออกแบบสัมภาษณ์ ไม่แปลกเลยที่จะหาวิธีการพัฒนาให้มันแฟร์ขึ้น แม่นยำขึ้น ดีขึ้น

แต่ถ้าเราเป็นคนสัมภาษณ์ ก็อยากจะให้มองมันอย่างเข้าใจ

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

บางทีมันไม่มีใครผิดใครถูกหรอก หรือเปล่าประโยชน์ที่จะไปหา

มันก็แค่ไม่ใช่เวลาไม่ใช่โอกาส ก็แค่นั้น

=============================

ผมเชื่ออย่างหนึ่งว่า กฎแรงดึงดูดมีจริงนะ

ผมเป็นคนที่ออกความเห็นเยอะ เขียนอะไรเยอะ

คนชอบก็มี คนไม่ชอบก็มี พูดมากขนาดนี้ คนหมั่นไส้ก็คงมีเยอะแน่ๆ

บางคนมาเห็นความเห็นแล้วจะตัดโอกาสของเราไม่อยากร่วมงานกับเรา ไม่อยากให้โอกาส คิดว่าแบบแนวคิดของเราไร้สาระ ตัดโอกาสทิ้ง เกิดขึ้นได้มั้ย ก็คิดว่าเกิดขึ้นได้

แต่ชีวิตมันกินทุกโอกาสไม่ได้

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

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

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

มันเป็นธรรมดาของโลกนี้ ไม่ได้มีใครผิดใครถูก มันแค่เข้ากันไม่ได้

สัมภาษณ์งานก็เหมือนกัน ถ้ามันไม่เหมาะ เวลามันไม่ใช่ โอกาสไม่ใช่ มันก็ไม่ได้ ก็แค่นั้นแหละ

=============================

อยากให้กำลังใจน้องๆ หรือเพื่อนๆ พี่ๆ ที่อาจจะกำลังย้ายงาน

วันนี้เราสัมภาษณ์ไม่ผ่าน เราอาจจะคิดว่า มันต้องมีใครผิด ไม่ฉันผิด ก็อีกคนผิด ไม่ฉันแย่ ก็บริษัทแย่ พยายามอธิบายด้วยแนวคิดผิดถูก

ความผิดหวังเป็นเรื่องธรรมดา ผมผ่านมาเยอะนะ

แต่จริงๆ โลกมันซับซ้อนกว่านั้น เป็นสีเทามากกว่านั้น

อยากให้เชื่อมั่นว่าสุดท้ายโลกจะหาสิ่งที่ใช่เข้ามาหาเรา ผลักสิ่งที่ไม่ใช่ออกไปจากเรา

กฎแรงดึงดูดมีจริงเสมอ ผมเชื่อ และก็ผ่านมาแล้ว

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

แต่กฎแรงดึงดูดจะทำงานได้ดี เราต้องมั่นคง ต้องมี Integrity คอยพัฒนาตัวเองในแนวทางที่ตัวเองเป็นอยู่สม่ำเสมอ จนความเป็นตัวตนชัดเจนขึ้น

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

ความไม่ชัดเจนนั้นอาจจะเกิดจากความไม่มั่นใจในตัวเอง หรืออาจจะเกิดจากเจตนาที่หลอกลวง ผมมิอาจตัดสินว่ามาจากเจตนาใด

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

ชีวิตช่วงไหนที่ผมสับสนกับตัวเองมากๆ โอกาสต่างๆ ที่เข้ามาก็จะสับสนมาก พอๆ กับความสับสนภายในจิตใจ

ผมถึงเชื่อในกฎแรงดึงดูด

และก็อยากเตือนด้วย

ถึงแม้จะเชียร์ว่า ให้เป็นตัวตนของตัวเอง แต่ก็อย่าให้ความเป็นตัวเรามันไม่ได้ไปบดบังคนอื่น Abuse คนอื่น

ว่าการทำให้ตัวเองเด่นโดยกดคนอื่นให้ด้อย โยนความผิดให้สิ่งรอบข้าง โดยอ้างว่านี่คือความเป็นตัวตน ฉันไม่แคร์ วางตัวเหนือกว่า มันไม่น่ารักนะ

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

แสดงความเป็นตัวตนในกาลเทศะและเวลาที่เหมาะสม ไม่กดคนอื่นลงเพียงเพื่ออยากขับเน้นตัวเองให้เด่นขึ้น

ทั้งให้กำลังใจและก็เตือนสตินะ

145 Nameless Fanboi Posted ID:hVKt8ve17r

ก็หีแม่มึงมันสวิงกิ้งแบบโค้ดสตาร์

146 Nameless Fanboi Posted ID:hVKt8ve17r

การที่เว็บบอร์ดนี้มันร้างเพราะSIRNมันโดนลักพาตัวโดยโค้ดสตาร์

147 Nameless Fanboi Posted ID:hVKt8ve17r

โค้ดสตาร์แม่งแย่งข้าวกูแดก

148 Nameless Fanboi Posted ID:hVKt8ve17r

โค้ดสตาร์มันชาติเหี้ยทำให้กูปวดหัว

149 Nameless Fanboi Posted ID:hVKt8ve17r

ฝุ่นPM 2.5 เกิดขึ้นมาได้ก็เพราะว่าโค้ดสตาร์

150 Nameless Fanboi Posted ID:l7gjDlZ9Af

โค้ดสตาร์ทำให้กูต้องมานอนตอนนี้

151 Nameless Fanboi Posted ID:.BrhVtl6PZ

>>150 มึงรอเล่นมุกนี้มานานมั้ยเนี่ย

152 Nameless Fanboi Posted ID:dgPoGmed5u

>>151 ไม่นานเพราะไอเหี้ยโค้ดสตาร์นี่แหละ

153 Nameless Fanboi Posted ID:l4YnjwzBB5

รถติดก็เพราะโค้ดสตาร์มอมเมาคนมาเรียน

154 Nameless Fanboi Posted ID:l4YnjwzBB5

รู้ไหมว่าขนาดพระเยซูยังนับถือศาสนาโค้ดสตาร์เลย

155 Nameless Fanboi Posted ID:l4YnjwzBB5

พระแม่อุมาหน้าหีไปเรียนกับโค้ดสตาร์แล้วมาปิดถนนสีลม

156 Nameless Fanboi Posted ID:Dd8heMKoaN

โค้ดสตาร์ทำให้ประชาชนคนไทยยากจน

157 Nameless Fanboi Posted ID:HtSfFE/JRk

ทำไมมีการปิดถนนที่อนุเสาวรีย์ตอนเช้า กับสีลมตอนเย็น ๆ เมื่อวันก่อน พอรู้บ้างไหม

158 Nameless Fanboi Posted ID:/DjWmyGu27

เรื่องขำๆของเซเลปท่านนึง

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

รอบสอง บอกว่าจะไม่ยุ่งกะกลุ่ม level 1 แต่เข้ามายังไงไม่รู้ ก็มีดราม่าตามคาด แล้วรอบนี้ ออกเอง แอตมิน แคบไว้ แต่บอกชาวโลกว่า แอตมินเตะออก

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

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

มีน้องที่ทำงานด้วยบอกเคยไปเรียน PHP yii ด้วย แล้วเหมือนติด config ก็เลยไปช่วยดู กลับโดนตวาดใส่ “เก่งแล้ว มาเรียนทำไม” อีหยังวะ ยังงี้ก็ได้เหรอ

แยกย้ายทำงานๆ

159 Nameless Fanboi Posted ID:fLJEn7Z5Db

>>157 เพราะอีพระอุมาหน้าหีมาเรียนโค้ดสตาร์เลยต้องปิดถนน

160 Nameless Fanboi Posted ID:I2P6cl4lEI

วันนี้นั่งอ่านว่าผิดหวังจาก Blazor แล้วจะไปลองเล่นอะไรดีสำหรับโฮมเพจเกม (คงไม่ interactive มาก แต่อย่างน้อยอยากทำเว็บที่ประกอบจาก component) ตอนแรกว่าจะลองศึกษา React Hooks แต่ใน documentation ก็ได้รู้จักกับ Svelte https://svelte.dev/

อันนี้มันเท่ตรงที่ UI Framework ปกติจะให้เราเป็นคนเขียนโปรแกรมตามกติกาแล้วเราจะพอดูออกว่า จังหวะนี้นั้นนี่เองที่ framework รู้ว่าเราอยากจะอัพเดทชิ้นส่วนไหน แต่ก็ไม่ได้รู้หมดเด๊ะๆขนาดนั้น ก็เลยต้องควบคู่กับการ diff DOM + อาจจะมีตัวช่วยอย่าง ID ประจำ element นิดหน่อยจะได้เปลี่ยน DOM ถูกที่ เช่นถ้า React ก็จะมีจังหวะตอน set state

แต่ Svelte ก้าวข้ามไปอีกขั้นคือเป็น compiler ซะเลย คือเว็บสุดท้ายที่ออกมาไม่มี framework ให้โหลดมาคู่กันด้วยซ้ำ เพราะโค้ดที่เราเขียนนั่นแหละกลายเป็น DOM manipulation ด้วยตัวเองไปแล้ว! (ประมาณว่าออกมาเหมือนเหมือนเราทนเขียน web app แล้วมาแก้ DOM ด้วยมือแบบไม่มีเครื่องมืออะไรเลย)

เขาก็เลยสร้าง syntax ภาษาใหม่ .svelte ขึ้นมาที่หลุดจากบ่วง JS ได้เลยไหนๆก็เป็น compiler แล้ว ทีนี้ก็ไม่ต้องมีพิธีที่รู้สึกได้ว่ากำลังครอบอยู่บน JS อีกต่อไป assignment เปล่าๆอย่าง foo = 50 อะไรงี้ compile กลายเป็น DOM change ซะงั้นได้ครับ ที่สำคัญไม่มีการ diff เกิดขึ้นด้วยซ้ำเพราะโค้ดสุดท้ายมันกำลังแก้หน้าเว็บสดๆจริงๆ เขาวิจารณ์ไว้ว่า Virtual DOM is pure overhead (https://svelte.dev/blog/virtual-dom-is-pure-overhead)

ตอนนี้ยังไม่ถึงไหนเท่าไหร่ แต่ syntax เขียนค่อนข้างสนุกดี ดูเหมือนโล่งๆไม่มีอะไรแต่ component ก็พร้อมใช้งานแล้ว ยากแค่ต้องมาทำความเข้าใจ bundler อย่าง Rollup / Webpack อีกหน่อยครับถ้าจะ extend (แต่อีกมุม มันก็คือความโปร่งใสดีว่าเว็บเราออกมาเป็นก้อนๆนี้ ไม่เหมือน Blazor ที่เป็น .dll วุ่นวายไปหมด)

*Angular ก็เป็น compiler เหมือนกัน ที่เขียนขึ้นมาสดๆยังใช้จริงไม่ได้ https://angular.io/guide/aot-compiler ไม่เหมือน React ที่เป็นสั่ง JS lib จริงๆ (แต่ก็ต้อง compile จาก JSX ก่อนอยู่ดี) แต่ทั้งคู่ไม่ได้ฉีกห่างออกจาก JS เว่อร์เหมือน Svelte

*แปลว่า ผอมเพรียว

161 Nameless Fanboi Posted ID:WZqtoxmmK9

ตระหนักไว้เสมอว่ามีคำว่า "Engineer" ในชื่อตำแหน่งของ "Software Engineer"
.
เป็นสิ่งนึงที่เรียนรู้มาจากอาจารย์ที่เคารพมากตอนป.ตรี อาจารย์ท่านถามว่า
.
"... รู้มั้ยทำไมงานพวกเราถึงถูกเรียกว่า Software Engineer ? ..."
.
"... ก็เพราะสิ่งที่เราต้องทำมันเป็นงาน *วิศวกรรม* ยังไงหละ ..."
.
สีหน้าสงสัยปนสนใจของเราทำให้ยังไม่ทันที่จะเอ่ยปากถาม อาจารย์ก็เดาออกทันทีว่าเราจะถามอะไร อาจารย์เลยตอบคำถามที่เรายังไม่ทันถามได้ทันที
.
"... วิศวกรซอฟต์แวร์หนะ เราไม่ได้แค่เขียนโปรแกรมให้ใช้งานได้นะ แต่หน้าที่ของเราคือต้องแก้ปัญหาทางคอมพิวเตอร์โดยคำนึงถึง *ความคุ้มค่าที่สุด* ให้ได้ด้วย ..."
.
ตั้งแต่นั้นเป็นต้นมา คำว่า "คุ้มค่าที่สุด" ก็ถูกฝังไว้ในหัวและกลายเป็นแกนกลางของการแก้ปัญหาใด ๆ ในทุกงานของเรา ความเข้าใจเพียงเบาบาง ณ ตอนนั้นก็ค่อย ๆ ถูกประสบการณ์หล่อหลอมให้เข้าใจมากขึ้นจนรู้แล้วว่ามันไม่ใช่แค่เรื่องของการพัฒนาซอฟต์แวร์ แต่กับทุกเรื่องในชีวิตเลย
.
อาจจะสงสัยว่าความคุ้มค่าที่สุดที่ว่าคืออะไร ? คำตอบคือ "เราต้องรู้ว่าจุดประสงค์ของงานนั้น ๆ คืออะไร สิ่งที่ได้กลับมามีมูลค่ามากน้อยแค่ไหน และเราต้องลงทุนลงแรงไปมากน้อยเพียงใดถึงจะคุ้มกับสิ่งที่ได้มา"
.
งานที่ทำแล้วใช้ครั้งเดียวทิ้ง ทำ Big-O แย่ ๆ โดยใช้เวลา 30 นาทีในการเขียนแล้วปล่อยให้มันรัน 1 ชั่วโมงเต็มก็ยังคุ้มค่ากว่าเขียนโปรแกรม 3 วันเต็มด้วย Big-O เทพ ๆ แต่รัน 1 นาทีเสร็จ ... แล้วก็โยนทิ้งไป
.
งานที่รันตลอดเวลา ลงทุนเขียนโปรแกรมเป็นเดือนให้ทำงานได้ ≤ O(log n) นี่แหละคือความเหมาะสมและคุ้มค่ากับสิ่งที่ได้มา
.
แต่ถ้างานมีเวลากระชั้น การนั่งทำ Big-O เทพ ๆ แล้วส่งงานไม่ทันก็อาจจะส่งผลเสียต่อธุรกิจ ก็ต้องสามารถบาลานซ์ได้ว่าจะต้องทำด้วย Big-O เท่าไหร่เพื่อให้ประสิทธิภาพยอมรับได้และส่งงานทัน แล้วค่อยมา Optimize ให้ดีขึ้นทีหลัง
.
Code Quality เทพเนียนกิ๊กแต่ Deliver งานตามกำหนดไม่ได้ รันโปรดักชั่นไม่สำเร็จ สเกลไม่รอด ธุรกิจพังไม่เป็นท่า บริษัทเจ๊ง ถ้าเทียบกับ Code Quality พอดี ๆ เขียนเทสต์ในส่วนที่จำเป็น ส่งงานทัน บริษัทกำไรเพิ่มแล้วค่อยมาปรับ Code Quality ให้สมบูรณ์ทีหลัง
.
งาน Software Engineer กับธุรกิจจึงเป็นเรื่องเกี่ยวข้องกัน หน้าที่นึงของ Software Engineer คือจะต้องสามารถนิยามคำว่า "ความคุ้มค่า" ของงานที่ตัวเองทำให้ได้
.
และการจะทำสิ่งนี้ได้นั้น เราจะต้อง "ประเมินมูลค่าของสิ่งที่ทำและสิ่งที่ตัดสินใจไม่ทำให้ได้"
.

162 Nameless Fanboi Posted ID:WZqtoxmmK9

การเขียนโปรแกรมดีเลิศ Code Quality ดี โค้ดดูแลง่าย - มีมูลค่าบวก
.
การเขียนโปรแกรมดีเกินไปจนสิ่งที่รับกลับมามีค่าน้อยกว่าแรงที่ลงลงไป (Overengineer) - มีมูลค่าลบ
.
การเขียนโปรแกรมแย่ แก้ทุกอย่างแบบ Quick & Dirty จนโค้ดดูแลไม่ได้ในระยะยาว (Technical Debt) - มีมูลค่าลบ
.
การเขียนโปรแกรมด้วยภาษาที่หาคนร่วมทีมได้ง่าย - มีมูลค่าบวก
.
การเขียนโปรแกรมด้วยภาษาที่ต้องควานหาคนทั้งปฐพีถึงจะเจอคนทำเป็นสักคน - มีมูลค่าลบ
.
การส่งงานทัน - มีมูลค่าบวก
.
การส่งงานไม่ทัน - มีมูลค่าลบ
.
การจะทำงานสักงานนึงก็ต้องเอาค่าด้านบนพวกนี้มาบวกกัน ดิฟนิดหน่อย อินทิเกรดนิดนึง (เพราะมันมีเรื่องเวลามาเกี่ยวข้อง ความคุ้มค่าระยะสั้น ความคุ้มค่าระยะยาว ล้วนมีผลต่อการตัดสินใจ) แล้วถึงตัดสินใจกันว่าจะเดินไปทางไหน
.
จะเห็นว่างานของ Software Engineer ไม่ใช่แค่เขียนโปรแกรมให้จบ ๆ ไป ไม่ใช่การเขียนให้ Code Quality ดีเลิศที่สุดในปฐพี ไม่ใช่การเขียนโค้ดที่ประสิทธิภาพล้ำจนเอาคนไปแข่ง ACM ได้ แต่เป็นการ "หาจุดคุ้มค่าที่สุดแล้วทำอย่างเหมาะสม" ต่างหาก
.
บ่อยครั้งมากที่มีคนถกเถียงกันเรื่อง Code Quality เอย เรื่องประสิทธิภาพการทำงานของโค้ดเอย เรื่องการเขียน Test เอย แล้วผลก็คือเสียงแตก จะบอกว่าไม่มีทางหรอกที่แต่ละคนจะให้คำตอบเหมือนกัน เพราะเรายังไม่ได้นิยามคำว่า "คุ้มค่า" ร่วมกันเลยนี่
.
เมื่อความคุ้มค่าไม่เหมือนกัน แล้วจะคาดหวังให้การตัดสินใจของแต่ละคนเหมือนกันได้ยังไงอ่ะ ?
.
ไม่ต้องไปถึงขั้นคนไม่รู้จักกันมาคุยกันใน Facebook Group หรอก แค่ในบริษัทตัวเอง ฝ่าย Business กับฝ่ายเขียนโปรแกรมก็ไม่สามารถคุยกันรู้เรื่องได้แล้วถ้าไม่สามารถคุยด้วยจุดมุ่งหมายเดียวกันได้
.
แล้วอะไรคือจุดมุ่งหมายร่วมกันของบริษัทหละ ?
.
"ธุรกิจก็คือธุรกิจ" ไม่ว่าจะทำอะไร ยังไงก็ต้อง Business-Driven อยู่แล้ว ถ้าไม่มีกำไรบริษัทแล้วจะไปต่อยังไง ถ้าสิ่งที่ทำกลับทำให้บริษัทขาดทุนแล้วจะเปิดบริษัทต่อไปทำไม หน้าที่ของ Software Engineer คือต้องประเมินมูลค่าออกมาเป็นตัวเลขและความคุ้มค่าให้ได้ เพื่อเอาสิ่งเหล่านี้ไปคุยกับฝ่าย Business หาจุดคุ้มค่าร่วมกันแล้วมุ่งหน้าสู่ทางนั้นเต็มอัตรา
.
ถ้ายังทำไม่ได้ นั่นแปลว่าคุณยังทำให้คนอื่นมองเห็นมูลค่าของงานที่คุณทำไม่ได้นั่นเอง
.
เป็นสกิลนึงที่อยากให้คนสาย Software Engineer ฝึกไว้ อย่าเอาแต่เขียนโปรแกรมไปวัน ๆ แต่เมื่อได้โจทย์อะไรมา เราจะต้องสามารถวิเคราะห์สถานการณ์ วางแผนไว้หลาย ๆ แบบ ประเมินมูลค่าของแต่ละแบบแล้วเลือกแผนที่ "คุ้มค่า" ที่สุด
.
เพราะมันไม่มีหรอกคำตอบที่ดีที่สุดสำหรับทุกสถานการณ์ มันมีแค่ "ทางที่เหมาะสมที่สุด" เท่านั้นแหละ
.
เหมือนที่เธอกับเราเหมาะสมกันไง 😳😳😳

163 Nameless Fanboi Posted ID:WZqtoxmmK9

พี่โดมพูดเรื่องนึงได้น่าคิด

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

Line ก็มาหลัง MSN หลัง Pirch หลัง ICQ
Gmail มาหลัง Hotmail
Booking Agoda พวกนี้ก็มีมานานแล้ว
Kapook มาหลัง Yahoo

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

164 Nameless Fanboi Posted ID:Xwx2VBLIQm

At my (now former) company, we use a metric called SHOT to track the performance within a portfolio. It's some in-house calculation no one else uses, but it's been around for like 20 years even though no one remembers what the acronym is supposed to mean. My task was to average it over a time period, with various user-defined smoothing parameters... to accumulate it, in essence.

So, I don't like long variable names like "accumulated_shot_metric" or "sum_of_SHOT_so_far" for what is ultimately just the cumulated SHOT value. So I gave it the short name, "cumShot", not thinking twice about it, and checked it into the code. Seeing that it passed all tests, I went home and forgot about it.

Two months later, today, my boss called me into a meeting with HR. I had no idea what was going on, but apparently, the "cumShot" variable had become a running joke behind my back. Someone had given a printout to the CEO, who became angry over my "unprofessional humor" and fired me. I didn't even know what anyone was talking about until I saw the printout. I use abbreviated variable names all the time, and I'm not a native speaker of English so I don't always know what slang is offensive.

I live in California. Do I have any legal recourse? Also, how should I explain this in future job interviews?

165 Nameless Fanboi Posted ID:.ioNbtqt3s

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

166 Nameless Fanboi Posted ID:9d3UIqdxmc

ถามเหตุการณ์สมมติกับเพื่อนโม่งหน่อยครับ

สมมติมี Startup ด้านการเงินสัญชาติยุโรปมาตั้งบริษัทในไทยแห่งหนึ่งเพื่อ develop software ให้บริษัทแม่แล้วไม่จ่ายเงินเดือนพนักงานมา 2 เดือน รวมถึงค้างค่าใช้จ่ายต่าง ๆ เช่น ประกันสังคม (ไม่ได้ส่งมาหลายเดือน), AWS, Jira, Bitbucket, ค่าเช่าออฟฟิศ ฯลฯ เพราะอ้างว่าเงินทุนก้อนใหญ่มากกำลังจะเข้ามา (ซึ่งไม่น่าจะจริง) แต่ติดปัญหาเรื่องการเดินเอกสาร และให้พนักงานทำงานฟรีมา 2 เดือนจนขึ้นเดือนนี้ถึงให้หยุดอยู่บ้านไปก่อน และในระหว่างนี้พนักงานหลายคนก็เดือดร้อนเรื่องเงินเพราะมีภาระต้องผ่อนหนี้ค่าบ้าน/คอนโด/รถ หรือส่งลูกเรียนแบบนี้

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

ย้ำว่านี่เป็นเหตุการณ์สมมตินะครับ

167 Nameless Fanboi Posted ID:uq2L9xGw2Y

ไปอ่านบล็อกนึงใน Reddit ที่ Github บอกว่าเขาไม่ใช้ Foreign key constraint เพราะอะไร

มีคนอ่านบอกว่า ปัญหานี้มันเฉพาะตัวของ Github ไม่ใช่ปัญหาที่คนทั่วไปเจอ

ผมตอบว่า No one tasked to solve generic problem, ever. แล้วผมก็แชร์บล็อกนี้เลยใน Tech Articles Group

================

ผมอยากชวนคิดว่า เราอยากจะหา Generic solution หรือมักจะเรียกอีกชื่อหนึ่งว่า "Best practice" ที่ใช้ได้ในกรณีทั่วไปเพื่ออะไร

ถ้าระบบหรือที่ไหนเจอ Generic problem เขาก็ไปอ่าน Generic solution แล้วก็ทำตามนั้นก็จบ จะจ้างเรามาทำงานทำไม คนเขียนวิธีอย่างละเอียดในการแก้ไข Generic problem มีเยอะแยะไปหมด

ทุกคนทุกระบบ เจอ Specific problem ที่จำเป็นต้องใช้ Specific solution ในการแก้ไขทั้งนั้น ดังนั้น ในแง่นี้ การที่เรารู้จัก Generic solution หรือ AKA. Best practices ไม่ได้การันตีเลยว่ามันจะแก้ไขปัญหาของเราได้ ต้องบอกว่าส่วนมากจะไม่ได้ด้วยซ้ำไป

อ้าว แล้วถ้างั้นเราควรจะทิ้ง Best practice ไปมั้ย ไม่สนใจเลยเหรอ? เราจะเรียน Best practices ไปทำไม

เพราะเวลาพัฒนาระบบเนี่ย มันไม่มีใครรู้ว่า Solution คืออะไรไงล่ะ ถ้ามีคนรู้จริงๆ แล้วเนี่ย งานมันไม่มาถึงเราหรอก

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

ทีนี้ประโยชน์ของ Best practices มันก็คือตรงนี้ คือคุณลอง Apply best practices ไปในตอนที่ยังหา Solution ที่เป๊ะๆ ไม่เจอ โอกาสที่มันจะใกล้เคียงกับ Solution มีเยอะกว่า Apply อะไรก็ไม่รู้มั่วซั่วเยอะ ดังนั้น เวลาไม่รู้อะไร ผมก็แนะนำ Best practices ก่อนเสมอ เป็น Bet ที่ดีกว่าลองมั่วซั่วแน่ๆ คุณควรจะรู้แล้วใช้มันเป็นฐานตั้งต้นเสมอ

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

================

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

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

ทุกวันนี้ ทุกคนอยากให้มีคนรู้คำตอบ แต่ไม่มีใครอยากผ่านขั้นตอนในการ "ค้นหาคำตอบ" ตัว Business อยากให้มีคนรู้คำตอบ Investor คาดหวังว่าจะมีคนรู้คำตอบ Junior คาดหวังว่าจะมีคนรู้คำตอบ Senior คาดหวังว่าคนอื่นจะรู้คำตอบ แต่ไม่มีใครอยากผ่านขั้นตอนการค้นหาคำตอบ

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

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

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

168 Nameless Fanboi Posted ID:uq2L9xGw2Y

>>166 ฟ้องกรมแรงงานก่อนได้เปรียบ

169 Nameless Fanboi Posted ID:3jb8hqnwz8

ผมเห็นด้วยที่ว่า Agile ไม่ได้แปลว่า เร็ว (ใน Absolute Term/Sense) ... ทุกอย่างมันขึ้นกับ Frame of Reference ว่าเราเอาอะไรไปเทียบกับมัน และมันเหมาะสมหรือไม่ มัน Overkill เกินไปหรือเปล่า ในทุกเรื่อง

ผมเห็นว่าทุกกระบวนการ มันมี Scale ที่เหมาะกับมันเอง สิ่งที่จะทำให้มันยากลำบากและช้าลง ไม่ใช่ที่ตัวกระบวนการ แต่เป็นการไม่เหมาะสมกันระหว่าง Process และ Scale ต่างหาก

นี่ยังไม่รวมถึงลักษณะงาน และเป้าหมายนะ ... เช่น ถ้าเป็นงานแบบ "ใช้แล้วทิ้ง" ใน Scale ที่เล็กพอที่จะ Cowboy-Developer ได้ตรงๆ แบบดุ่มๆ ไปเลย เดี๋ยวก็เสร็จ และการันตีได้ว่าไม่ต้องดูแลต่อ (ไม่ว่าจะโดยใครก็ตาม) การทำ Agile ก็ Overkill ไม่ต่างอะไรกับการใช้ Process อื่น ...

แต่กับอีกหลายงานมันก็ไม่ใช่แบบนั้น

จริงๆ ก็ไม่ต่างจากเรื่องบริหารบริษัทหรอก บริหาร Enterprise แบบ SME ก็ตาย บริหาร SME แบบ Enterprise ก็ตาย ... บริหาร SME แบบงานส่วนตัว ข้ามาคนเดียว ก็ตาย บริหารงานที่ทำคนเดียวแบบ SME ก็ตาย ... ทั้งนั้นแหละ

ประเด็นมันไม่ใช่ Agile เร็วหรือไม่เร็ว เพราะตัวมันเองไม่ใช่ความเร็ว เพียงแต่ว่าเมื่อนำมันไปใช้กับ "งานบาง Scale" แล้วมัน "เร็วกว่า Waterfall-based ในระยะสั้นและระยะกลาง" และ "เร็วกว่า Cowboy-Develop ในระยะกลางและระยะยาว"

ซึ่งพอเรา "เคยชิน​" กับ Frame of Reference บางอย่าง (พูดอีกอย่าง คือเรามี Implicit Frame of Reference) เราอาจจะรู้สึกว่ามัน "เร็วขึ้น"​ เสมอ แต่ถ้าเราเคยชินกับอีก Frame หนึ่ง เราอาจจะรู้สึกว่ามัน "ช้าลง" เสมอ เช่นกัน

การนำ Process ไปใช้ ถ้าเรารู้สึกว่ามันเร็วขึ้น แปลว่า Scale ของงานที่เราทำ และ Process มันมี matching ที่ดีกว่า แต่ในขณะเดียวกันถ้ามันช้าลง แปลว่า matching มันไม่ดี

ประเด็นสำคัญคือ ... ทีมงานหลายทีม ใช้ Process ผิด Scale .... ส่วนหนึ่งก็เพราะว่าตอนเรียน เรียน Process for Enterprise มา .. แต่ตอนทำโปรเจ็คจบ หรืองาน Freelance แรกๆ ดันทำแบบ Cowboy ....

ต้องยอมรับกันนะ ว่างานบ้านเราที่ต้องใช้ Scale ระดับ Enterprise มันไม่ได้มีเยอะขนาดนั้น แต่งานส่วนมากมันเกิด Scale ของ Cowboy Coding ไปเยอะอยู่

Agile จึงเป็นทางออกที่ดี และผมเห็นว่ามันเป็น Bootstrapping Platform ที่ดี สำหรับการ Rescale Enterprise ให้เป็น Smaller Units ในการทำงานต่างๆ

แต่ที่แน่ๆ คือ เราต้องแยกแยะให้ออกระหว่างตัวปรัชญา (Philosophy) ของแต่ละอย่าง กับ "Implementation" ของมันทั้งหลาย ไม่ว่าจะเป็นการ Implement แบบไหนก็ตาม

หลายอย่าง Philosophy ดีมาก เช่นพวก CMMi แต่ตัวปรัชญามันเอาไปทำอะไรไม่ได้ มันก็ต้องมี Implementation ... ซึ่งแน่นอนว่า Implementation ทุกตัวมันจะเหมาะกับบางรูปแบบ (เช่น บางตัวเน้นการใช้เอกสาร) ... แต่ถ้าเราถอดเปลือกของ Implementation กลับไปมองที่ประเด็นของปรัชญาของมัน เราอาจจะสร้าง Process ใหม่ๆ ได้โดยไม่อิงกับ Implementation บางแบบที่ไม่เหมาะสม ได้ทั้งนั้น

ก็เช่นเดียวกันกับ Agile .... ณ วันที่ผมลงชื่อใน Manifesto เมื่อประมาณ 15 ปีก่อน ....​ ณ วันนั้นมันยังไม่มี Agile Methodology หรือ Agile Process มากมายดังเช่นทุกวันนี้ ยังไม่มี Scrum ไม่มี Kanban ไม่มีอะไรทั้งนั้น ... พวกนี้เกิดจากการเอาปรัชญาไปใช้สร้าง Process ของตัวเอง จนมันเวิร์กขึ้นมา และทำจนเชี่ยวชาญ จนมันเร็ว

บางที กลับไปหาปรัชญามันซะบ้าง แล้วก็คิดบ้าง ว่ามันไม่มี one size fit all ... และทุกอย่างมันไม่มี absolute term

ผมจะลบโพสท์นี้ในอีก 1 ชั่วโมง