Fanboi Channel

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

Last posted

Total of 221 posts

190 Nameless Fanboi Posted ID:kKPvrhZOLi

>>189 ถ้าจะมาเป็น dev ทำงานจริงจำเป็นกว่า

191 Nameless Fanboi Posted ID:2IjyEbqevB

ปรึกษาหน่อยค่ะ

192 Nameless Fanboi Posted ID:On/WDCA26e

หนึ่งในเรื่องสำคัญที่หลายต่อหลายคนมองข้าม ก็คือ "พิมพ์ดีด"

ต้องฝึกให้คล่องนะ อย่างน้อยๆ นี่ 30 คำต่อนาทีขึ้นไปควรจะได้ ไม่งั้นจะ inefficient มากในการทำงาน

และแน่นอนว่าการพิมพ์ที่ดี ควรพิมพ์ได้โดยไม่ต้องมองแป้นพิมพ์เลยแม้แต่นิดเดียว

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

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

โปรแกรมฝึกพิมพ์ดีดดีๆ นี่ช่วยได้เยอะมากเลย

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

พิมพ์เร็วนี่ไม่ยากหรอก ถ้าพิมพ์เป็นจังหวะที่ดีและคงที่ได้ .... พิมพ์รักษาจังหวะไว้ จากนั้นมันจะค่อยๆ เร็วขึ้นเอง

อ่อ แล้วการคิด WPM (Words-per-Minute) ของมัน จะเอาจำนวนที่เราพิมพ์ผิดมาคิดด้วย ว่าจริงๆ แล้วเราพิมพ์ได้กี่คำต่อนาทีกันแน่

จะเห็นว่าในรูปแรก ผมพิมพ์ถูกหมด WPM ก็เป็นไปตาม Raw speed (95 WPM) แต่รูปที่สองนี่มีผิดอยู่หน่อย (2%) ทำให้แม้ว่าจะพิมพ์ที่ Raw speed 83 WPM ก็ถูก adjusted เหลือ 75

ที่สำคัญที่สุด คือมันทำบทเรียนหรือแบบฝึกหัดเองง่ายมาก ..... อย่างรูปสุดท้าย นี่ผมเอาโค้ด Haskell ที่ผมเขียนไว้สอนใน Workshop หนึ่งมาเป็นแบบฝึกหัดเลย

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

193 Nameless Fanboi Posted ID:mEaJ6TxBLG

Redis ได้เงินลงทุนรอบใหม่ มูลค่ากิจการเกิน $1 billion แล้ว unicorn ของจริงช่วงนี้มีแต่สาย technical

ในไทยหาคนยังหาที่เคยใช้เยอะๆคุยด้วยได้ไม่กี่คน มันดีมากจริงๆ ยิ่ง module ที่ทำจริงจังช่วง 3-4 ปีหลังนี้ ทั้ง graph, timeseries, search คือดีทั้งหมด ถึง feature จะไม่เยอะเท่าคู่แข่งแต่ใช้ง่ายกว่ามาก เสียดายยังไม่มีโอกาสได้ลองใช้ redisAI ที่เพิ่งออกมาใหม่ไม่นาน เพราะงานตอนนี้ไม่ได้ทำเรื่อง ML, AI หรือ Data โดยตรงแล้ว

194 Nameless Fanboi Posted ID:Z0x2Ht2SpO

>>193 quote เก่าแล้วป่าววะ กูเห็นใครๆก็ใช้

195 Nameless Fanboi Posted ID:NUAlkwJ4cO

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

อนาคต ทุกคนก็จะเขียนโปรแกรมเป็นหมด แต่โปรแกรมเมอร์ที่เขียนได้ดี ก็จะยังมีงานทำอยู่ดี

196 Nameless Fanboi Posted ID:RjknmBsvAI

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

"เดี๋ยวนี้สงสัยไม่สอนเรื่องนั้นเรื่องนี้"
"ทำไมไม่สอนเรื่องนั้นเรื่องนี้"
"ต้องให้ความสำคัญกับเนื้อหานั้นนี้มากกว่านี้"

ฯลฯ

ผมว่าผิดทางครับ ..... ปัญหาไม่ใช่เนื้อหา หรือการมองเห็นความสำคัญว่าจะต้องสอนหรอกครับ ......

ปัญหาใหญ่กว่านั้นคือ "วิธีการสอน" และ "วิธีการเรียนรู้" ครับ

ถ้าเราคิดว่าปัญหาคือ "เนื้อหาการสอน" เราก็จะไปแก้ที่เนื้อหา ต้องยัดเรื่องนั้น ต้องมีเรื่องนี้ ฯลฯ

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

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

คนสอนก็ทำอะไรไม่ได้ นอกจากสอนตามตัวอักษรและวิธีการในเนื้อหาแบบเป๊ะๆ เพราะตัวเองก็ไม่ได้เล่น ไม่ได้ตั้งคำถามอะไรเหมือนกัน ....

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

ยิ่งเราบอกว่าต้องสอนเรื่องนั้นเรื่องนี้เพิ่มเข้าไปไม่มีที่สิ้นสุด ปัญหานี้ก็ยิ่งหนักขึ้นทุกวัน

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

ปัญหาคือ "วิธีการสอน" และ "วิธีการเรียน" แหละครับ

มีแค่นี้จริงๆ

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

[Slide Story] น้องๆ และสหายหลายต่อหลายคน ที่มาเรียนเรื่อง Maths for Working Programmers และ Functional Programming กับผม หลายคนที่ยังใกล้ชิดมหาลัยอยู่ก็พยายามจะไปบอกให้มหาลัยสอนเรื่องพวกนี้บ้าง ...

ผมก็ต้องเตือนน้องๆ และมิตรสหายเหล่านี้เสมอว่า "สอนเรื่องนี้แบบผม เรียนเรื่องนี้แบบที่น้องเรียนกับผม น้อง/คุณก็อินแล้วก็สนุกแหละครับ" ....​ "เนื้อหาพวกนี้ มีในหลักสูตรนะ เรื่องนี้อยู่ตรงนี้ เรื่องนั้นอยู่ตรงโน้น ฯลฯ" .... เห็นไหม มีนะ ไม่ใช่ไม่มี ฯลฯ

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

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

รูป: นกแก้วบนเครื่องถ่ายเอกสาร ..... รูปที่อยู่ใน presentation slide ที่ผมเคยใช้บ่อยมาก เดี๋ยวนี้ไม่ค่อยได้พูดเรื่องนี้แล้ว

197 Nameless Fanboi Posted ID:/D5kF8KFla

ใน reddit มีคนเอามาแปะ ก็เล่าไปใน reddit แล้วเอามาเล่าให้คนไทยฟังบ้าง

ที่ Wongnai ใช้ ArgoCD อยู่มันจะเป็น step แบบนี้ครับ

1. project build & push docker ใน gitlab ci
2. step สุดท้ายของ ci เรามี tool มา clone ceylon (deploy manifest) repo, create branch, update image tag, push branch แล้วเปิด merge request (MR)
3. tool มันจะ mark MR ให้ auto merge on pipeline success เป็นอันจบ pipeline ของ project
4. pipeline ของ MR ที่เข้า ceylon มี tool validate (หวังว่าจะมีเวลา open source ให้) มันจะ run ArgoCD template ได้ JSON มาแล้วโยนเข้า kubeval
(แปลว่ามี check 2 ที่ คือ Jsonnet assert สำหรับ best practice check + kubeval เช็คว่า valid)
5. MR merge เสร็จแล้ว argocd auto sync ยกเว้น prod ต้องกด sync เอง

ฉะนั้นจากในบทความนี้เราเลยไม่ค่อยเจอปัญหาเหมือนเค้า

1. ผมเข้าใจว่าเค้า clone แล้ว push master แข่งกัน มันเลย race แต่เราเปิด MR แล้วให้ gitlab merge มันเลยไม่ต้องแย่งกันเพราะเราไม่ได้ตั้งให้ rebase ก่อน merge
จะมี race ก็คือ MR project เดียวรัน 2 อันพร้อมกัน อันนี้ช่วยไม่ได้นอกจากไปตั้ง Gitlab ว่าให้ยกเลิก pipeline เก่าเมื่อมีอันใหม่กว่า (ซึ่งเราไม่ได้เปิด)
2. เราใช้ deployment monorepo แถม branch เดียวทุก env ด้วย เลยไม่มีปัญหาว่า repo เยอะ งง
ทีมบ่นอยู่บ้างว่าอยากได้ branch เพิ่มจะได้ทดลองของได้โดยไม่กระทบ prod อันนี้ยังมองๆ อยู่ว่าจะทำยังไงไม่ให้มันระเบิดแบบเค้า
3. Visibility ยากนี่เรื่องจริง มี git log ก็จริงแต่ไม่รู้ว่ากด sync ใน ArgoCD ตอนไหนต้องไปค้น ArgoCD log
4. Validation เรามี validate tool เลยชิล

ปัญหาที่ผมเจอจริงๆ น่าจะเป็นว่า

1. Rollback ยากมาก คือต้องถอย commit ออก แต่พอ change มันเป็นแค่ปรับ image tag มนุษย์ทั่วไปเข้าใจไม่ได้ว่าถอยเท่าไรถึงจะหายบั๊ก (ถอยโค้ดยังอ่าน commit message พอได้) แล้วมันหลายขั้นตอนมาก คนเลยชอบไปกดใน ArgoCD ซึ่งมันทำให้ decouple cluster state ออกจาก git state หรืออีกทีคือถอย commit ในแอพเลยแล้วรอ build ซึ่งนานมากกกกก
2. Post deploy step ทำยากมาก เช่น deploy dev เสร็จแล้วรัน automate test ไม่รู้จะเช็คยังไงเลยว่า deploy ยังไง (MR merge แล้วแต่ก็ต้องรอ sync + pod rollout) ที่ทีมทำกันอยู่มีแต่ท่า hackๆ

198 Nameless Fanboi Posted ID:0yCFcOKe8j

>>197 wongnai ไปทำไรใน reddit

199 Nameless Fanboi Posted ID:m4O69XJjXm

สองสัปดาห์ที่ผ่านมาประชุมเยอะขึ้นมากๆ แต่รู้สึกว่าได้ทำงานเป็นชิ้นเป็นอันจากการประชุม ไม่ได้รู้สึกว่ามัวแต่ประชุมไม่ได้งาน

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

ผมเริ่มเห็นว่าการประชุมแบบนี้ Effective ต่ำและกินพลังงานเยอะ ไม่ได้แปลว่าควรเลิก แต่แปลว่ามีช่องให้พัฒนาได้เยอะ

ในโดเมนการพัฒนาซอฟต์แวร์ เครื่องมือที่สร้างความมั่นใจที่ดีที่สุดคือ Working software รองลงมาคือ Demo ส่วนการทำสไลด์หรือการพูดคุยย้ำๆ ว่า โปรเจ๊กต์ยังไปได้ งานยังดี อันนี้สร้างความมั่นใจได้น้อยกว่าอย่างมาก แถมยังต้องพูดย้ำบ่อยๆ แล้วเปลืองเวลา

จะพบว่าเวลาคุณรัน Agile, Scrum, etc. แล้วคุณต้องสร้างความมั่นใจทุกๆ สองอาทิตย์ มันจะบังคับให้คุณต้องมี Demonstratable Progress ในเลเวลนั้น

และมันจะกระทบไปถึงวิธีเขียนโค้ด Process การทำงาน การวางโครงสร้าง

พอมาถึงหัวข้อนี้ ผมไม่ Buy เลยว่าพอทำ Scrum แล้วจะทำให้ Architecture ห่วย แต่มันต้องใช้ Architecture style และ Mindset ที่ต่างกัน

เช่น หลายคนเชื่อว่าคุณสมบัติของ Fundamental Architecture ที่ดีคือสิ่งที่ทำครั้งเดียวแล้วทนทานใช้ได้ตลอดกาล ซึ่งพอเปลี่ยนวิธีทำงาน คุณสมบัติที่สำคัญกว่าในการทำงานแบบ Agile (ที่มี Feedback loop สั้น) ถ้าต้องแก้ แก้ง่าย ทุกคนแก้ได้หมด เป็นคุณสมบัติที่มี Priority สูงกว่าความทนทานใช้ได้ไม่มีวันพังไม่ต้องแตะ ในโลกแบบ Agile

เขียนไปเขียนมาแตกหัวข้อไปหลายเรื่องแฮะ ขอสรุปหน่อยว่า Reflect อะไรได้บ้าง

- การประชุมเป็นเครื่องมือที่คนนิยมใช้เมื่อต้องการ "สร้างความมั่นใจให้ผู้เกี่ยวข้อง" แต่ มันเป็นเครื่องมือที่ Effective ต่ำมาก ถ้าประชุมอันไหนมีหน้าที่แค่ "รายงานให้คนเกี่ยวข้องสบายใจ" แปลว่ามี Room for improvement เยอะมาก อย่างเลเวลแรก จากสไลด์ 30 นาที คุณเปลี่ยนเป็นทำเป็นเดโม 5 นาที ได้ความมั่นใจมากกว่าโดยใช้เวลาน้อยกว่าเยอะ ถ้าเปลี่ยนเป็นแค่ Deploy working software แล้วบอกให้คนเกี่ยวข้องมาลองเล่นเองได้ ยิ่ง Effective เลยใช่มั้ย และสิ่งที่ Effective ที่สุดคือ ทำให้เขาเชื่อมั่นจนเขาบอกเองว่า "ไม่ต้องอัพเดทพี่แล้ว พี่ไว้ใจทีม มีอะไรให้พี่ช่วยมั้ย ถ้าไม่มี พี่เอาเวลาไปทำอย่างอื่นดีกว่าว่ะ" อันนี้คือ End game และตราบใดที่ยังไม่ถึงตรงนี้ เรายังสามารถหาทางดิ้นเพื่อพัฒนาได้เรื่อยๆ

- พอพัฒนาข้อแรกมันจะมากระทบ Process การทำงาน ไปจนถึงโค้ดที่เขียนแต่ละบรรทัดเลยนะ ซึ่งไม่เป็นไร กระทบก็กระทบ ผมไม่เห็นว่าเสียหายอะไร แต่ต้องเข้าใจว่ามันกระทบ ซึ่งบางครั้งกระทบไปลึกซึ้ง ถึงนิยามว่า Practice ที่ดีไม่ดีคืออะไร Architecture ที่ดีไม่ดีคืออะไร นิยามและความเข้าใจมันจะเปลี่ยนได้

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

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

ผมเลยไม่มีปัญหากับการ Bend ตัวโค้ด สถาปัตยกรรม โครงสร้าง เพื่อแก้ความเสี่ยงข้อ 2 ทำไงก็ได้ให้ทำให้คนเกี่ยวข้องมั่นใจไม่ถอนทุน ถ้าต้องมี Automated test ก็ต้องมี ถ้าต้องมี Evolutionary architecture ก็ต้องมี ถ้าวางอะไรลงไปแล้วต้องแก้ทีหลัง ก็ต้องทำ (ตรงนี้มันเถียงกับความเข้าใจผิดของหลายๆ คนได้อีกว่า การทำ Engineering practice ห่วยๆ จะทำให้ปั่นงานเร็วกว่า มีอะไรไปอัพเดทสร้างความมั่นใจบ่อยกว่า ซึ่ง ผมว่าไม่ใช่)

ซึ่งผมมองว่ามันเสี่ยงกว่าเรื่องที่ว่าเลือก Tech stack ผิด เลือกภาษาผิด แบบคนละเรื่องเลยนะ พวกนั้นไม่ทำให้โปรเจ๊กต์พัง แค่ทำให้เหนื่อยเฉยๆ อ่ะครับ

200 Nameless Fanboi Posted ID:sGsDjKKpCs

ความเข้าใจผิดที่เห็นบ่อย

"การเลือกใช้ RDBMS แล้วทีมพัฒนาจะคิดเรื่อง Schema ให้ดี วางแผนเรื่องข้อมูลเยอะๆ แล้วเราจะได้ Structure ของข้อมูลที่ดี"

ผมคิดว่าการใช้ RDBMS โดยคาดหวังผลลัพธ์ว่าจะได้บังคับทีมพัฒนาให้คิดเรื่อง Data structure ให้ดีก่อนทำอะไร ไม่เคยได้ผลจริงเลย

อันนี้มักจะเป็นความเข้าใจของคนที่ดูแลฐานข้อมูลหรือ Infrastructure แต่ไม่ได้ร่วมงานกับทีมพัฒนา ที่ว่าพอเสนอ Field Migration แล้วถูกตั้งคำถามจากฉัน เขาจะได้คิดดีๆ ก่อนเสนอ แล้วเราจะได้มี Data schema ที่งดงามไม่ Bloat โอ้ มันช่างดี มันต้องได้ผลแน่ๆ

ในความเป็นจริงผมเห็นมาหลายระบบแล้ว พอคุณทำให้ Field Migration มันยาก คนไม่ได้คิดให้ดีก่อนเสนอ Schema change ครับ คนเขาจะพยายาม Reuse field เก่ามาใช้หลายๆ อย่างแทนครับ เพราะเขามานั่งรอคุณตั้งคำถามไม่ได้ เขามีงานที่ต้อง Deliver

สิ่งที่เกิดขึ้นคือเราจะมีฟิลด์ที่มีหลายความหมาย ซึ่งไม่ใช่การออกแบบที่ Data ที่ดีเลยแม้แต่นิดเดียว

นั่นคือ Actual consequence ไม่ใช่การที่คนคิดให้ดี แต่เป็นการที่คนขี้เกียจทำไปเลย

แต่ถ้าคนที่เสนอสิ่งนี้ ไม่ได้อยู่ในทีมพัฒนา เช่น อยู่ในองค์กรที่มี DBA แยกกันกับทีมพัฒนาอย่างสมบูรณ์จนกระทั่งไม่รู้เลยว่าข้อมูลพวกนี้ไปใช้ในส่วนไหนของซอฟต์แวร์บ้าง จะไม่รู้ไง เห็นว่า Database schema/Structure เหมือนเดิม ก็เข้าใจผิดไปว่านี่คือออกแบบ Data มาดีแล้ว

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

จนกระทั่งต้องเริ่มทำ BI ถึงจะเห็นปัญหาว่าอ้าว ฟิลด์นี้มันหมายถึงหลายอย่างเลยนี่หว่า จะเอาไป Analyze ยังไงล่ะ

RDBMS มีประโยชน์หลายอย่างมากๆ ผมก็ชอบ RDBMS แต่ผมไม่เห็นด้วยกับเคลมที่ว่า พอใช้ RDBMS แล้วจะบีบให้ทีมคิดให้ดีก่อนทำ Database schema ไม่เคยเห็นเกิดขึ้นจริงมาก่อน

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

201 Nameless Fanboi Posted ID:AKwUc3NDXR

ไปร่วมชุมนุมปลดแอกไม่ได้ว่าอะไร แต่ถ้าหัดเขียน PHP ไล่ออกจากบ้านแน่ไอ้อ้วน

202 Nameless Fanboi Posted ID:FhaoUngMmK

โดนปลุกมา zoom ฟังประชุมอันนึงคุ้มค่ามาก สรุปสั้นๆ Dev ที่เข้าใจ DeFi จะมีค่าตัวแพงมาก Dev ทั้งหลายจงไปลอง Uniswap , Compound , Sushiswap ให้เข้าใจกลไกอย่างถ่องแท้กันเถิด

203 Nameless Fanboi Posted ID:GdMXKWnKPv

ด้วยความเคารพ

Imperative “ไม่เท่ากับ” Loop
Functional “ไม่เท่ากับ” Map, Reduce

โว้ยยยยยยย

#ขอระบายหน่อย
#เจออะไรโง่ๆมา
#แค่เปลี่ยนLoopเป็นMapก็เขียนFPแล้ว

204 Nameless Fanboi Posted ID:Y2bsOizXKo

การศึกษาเรื่อง Deep Learning ในปัจจุบัน เรื่องแรกๆที่มักศึกษากันคือ "Computer Vision" ที่ใช้ Deep Learning ในการแปลผลด้วยเทคนิคต่างๆ ทำไมต้องเป็น "Computer Vision"?
ในยุค Cambrian (500+ ล้านปีก่อน) เป็นช่วงที่มีการเกิดขึ้นของสิ่งมีชีวิตที่เป็นสัตว์ (ไม่ใช่พืช) มากขึ้นอย่างชัดเจน เนื่องจากในช่วงนี้มีวิวัฒนาการที่สำคัญคือการรับรู้แสง หรือการมองเห็นนั่นเอง
การมองเห็นทำให้สัตว์ที่มีวิวัฒนาการด้านนี้เพิ่มจำนวนขึ้นอย่างมาก เนื่องจากการมองเห็นทำให้ หาอาหารได้ดีกว่า หลบหลีกศัตรูได้ดีกว่า และสามารถหาคู่เพื่อสืบเผ่าพันธ์ได้ดีกว่า ทำให้เกิดสายพันธุ์ของสิ่งมีชีวิตเกิดขึ้นมากมายอย่างเห็นได้ชัด
การจะพัฒนา Deep Learning ให้มีความฉลาด จึงเริ่มที่ Computer Vision เพราะเมื่อเครื่องจักรเข้าใจสภาพแวดล้อมในอย่างที่มนุษย์เข้าใจ (ด้วยการมองเห็น) ก็จะพัฒนาความฉลาดได้คล้ายคลึงมนุษย์ในอันดับต่อไปของการพัฒนา
เรื่องนี้ต่างจากการศึกษา Machine Learning หรือ Artificial Intelligence ในช่วงแรกที่มุ่งไปยัง "ความฉลาด" ที่มนุษย์มักคิดว่า "ฉลาด" เช่น กิจกรรมบางอย่าง แบบ เล่นหมากรุก เป็นต้น ซึ่งทำให้เราหลงทางในการพัฒนาด้าน AI ไปราวๆ 3 ทศวรรษ
บทความนี้ไม่ค่อยเกี่ยวกับ AI แต่เกี่ยวกับยุค Cambrian ที่มีความสำคัญต่อแนวคิดด้านการศึกษา AI

https://stem.in.th/kylinxia-zhangi/?fbclid=IwAR1YPs5oc1t-Nly1YGQX3sB9a7RDfA5o3HSyBUhReKTLKi2OitKmsh_YFxQ

205 Nameless Fanboi Posted ID:E2E2zlSyyd

>>204 มึงคิดได้ไงวะ แบบนี้ต้องมีการสูญพันธุ์ครั้งใหญ่ด้วยมะ พวก ai ที่เสียโอกาสจะได้มีโอกาสในการวิวัฒนาการ

206 Nameless Fanboi Posted ID:KKresiBSpf

พวก great dying ส่วนมากมันจพมาแบบสุ่ม

207 Nameless Fanboi Posted ID:Sqkl7T1fPA

>>206 ถ้ารู้ล่วงหน้ามันก็ไม่ตายกันดิคุณ

208 Nameless Fanboi Posted ID:RdjEjvbRqb

2020 Reflection - ปีแห่งการปล่อยวางความคาดหวังและอยู่กับความจริงมากขึ้น 🌧❤️

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

...

📌 แบบสรุป

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

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

...

📌 แบบยาว​ 😂

🌪 #มรสุมใหญ่เข้ามาแบบไม่ทันตั้งตัว

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

209 Nameless Fanboi Posted ID:RdjEjvbRqb

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

🛣 #ตามหาทิศทางของบริษัท
ในช่วงที่กัดฟันเพื่อทำบริษัทให้อยู่รอด ก็เริ่มเห็นว่าการ consult หรือ outsource ระบบ IT ด้านการเงินเป็นที่ที่มีความต้องการค่อนข้างสูงและสามารถทำเงินให้กับบริษัทได้ดีและเติบโตได้ระดับหนึ่งเลย

แต่ว่าเราและทีมก็ยังรู้สึกว่ามันไม่ใช่ทาง รู้สึกว่า passion ของเรา เป็นการสร้าง product ที่ได้มีโอกาสดูแล คุยกับลูกค้าและกำหนดทิศทางเองมากกว่า ทำให้รู้สึกขัดกับการรับ consult ที่ทำอยู่

👨‍💻 #ตามหาโอกาสใหม่ๆในHackathon
เพื่อที่จะเรียนรู้อะไรใหม่ๆ ในขณะเดียวกันก็จะได้รู้จักคนใหม่ๆ ก็เลยไปลงแข่ง Hackathon หลายรายการ ซึ่งก็ต้องขอบคุณเพื่อนร่วมทีมที่ทำให้ได้รางวัลใหญ่มา 2 รายการในปีที่ผ่านมา ทำให้ได้มีโอกาสได้ไปร่วมงานเพิ่มกับอีกหลายๆ Project เลย คุ้มค่ามากจริงๆ

ต้องขอบคุณคนรอบๆ ตัวเราที่นำพาเราไปเจอสิ่งดีๆ เยอะแยะเลย

⏸ #ได้มีโอกาสกลับมาอยู่กับตัวเองมากขึ้น
หลังจากรับ consult มาตลอดก็มีโอกาสได้หยุดพัก เลยคุยกับทีมให้หยุดพักกัน 2 สัปดาห์เลย หลังจากที่วิ่งไม่เคยหยุดนานมาก

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

#วางคาดหวังในตัวเองและคนอื่นลง
เรารู้สึกว่าตัวเองมีความคาดหวังที่มากเกินจริง ไม่ได้มองตามความเป็นจริง อย่างการทำงาน เราก็คาดหวังว่างานต้องเสร็จเร็ว พอมันไม่เร็วอย่างที่คิดก็โกรธ แต่เราโกรธอะไรหล่ะ โกรธตัวเอง โกรธทีม? แต่ว่าเราเองก็ทำที่เต็มที่แล้ว ทำไมเราต้องโกรธละ โกรธที่ไม่ได้ทำงานเกินเวลาหรอ ก็ดูไม่ถูกต้อง...

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

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

ระหว่างนั้นก็ได้โอกาสกลับมานั่งคุยกับทีมว่าอะไรที่เราอยากทำจริงๆ อะไร ก็เลยเลือก Product ด้าน Open Financial Data เพราะเชื่อว่าจะพาเราไปถึงเป้าหมายที่วางไว้ได้

🚧 #understand_first_not_build_first
รอบนี้มาเริ่มต้นใหม่ ก็พยายามเปลี่ยนวิธีการทำงาน จากที่ได้เรียนรู้ใน Hackathon คือหลายๆ ครั้งมีแค่ mockup และ slide ก็ขายของได้ ทำไมเราต้องรอให้เราทำ product เสร็จก่อนถึงจะขายละ ถ้าเกิดมันขายไม่ได้ละ ที่ทำมาก็เสียเปล่าสิ

210 Nameless Fanboi Posted ID:RdjEjvbRqb

ก่อนหน้านี้ด้วยความเป็น developer พอคิดอะไรได้ ก็อยากสร้างไปหมด โดยไม่รู้ว่า 1) ปัญหาของกลุ่มลูกค้ามีอยู่จริงมั้ย รุนแรงแค่ไหน 2) solution ที่เรามีมันแก้ปัญหาที่เค้ามีจริงมั้ย 3) ลูกค้าพร้อมจะจ่ายให้กับ solutionที่เรามีรึเปล่า

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

❤️ #ได้กลับมาเรียนรู้ตัวเองมากขึ้นอีก
หลังจากนั้นก็ได้มีโอกาสเขียน reflection บ่อยขึ้น เข้า workshop นพลักษณ์ แล้วก็การได้พูดคุยกับคนหลายๆ คน ทำให้เริ่มเข้าใจตัวเองมากขึ้นอีก โดยเฉพาะในเรื่องที่เหมือนเราค่อนข้างแคร์ในภาพ และมุ่งมั่นใจเป้าหมายมากๆ จนบางทีไม่ได้มองโลกตามความเป็นจริง แต่ไปมองเป็นสิ่งที่อยากให้เป็นมากกว่า ต้องขอบคุณคนที่ตั้งคำถามให้เราได้คิดเสมอด้วยนะ :)

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

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

211 Nameless Fanboi Posted ID:PXGSa4LBMc

ตอนนี้ไปขอดู ระบบซอฟต์แวร์เขา จะถามว่าระบบคุณนี่ PASS ไหม คือ เขาต้องอธิบายได้ว่า. Performance Availability Security Scalability ของระบบเขามีที่มาอย่างไรในการออกแบบ

บางคนใช้ container อย่างหวือหวา แต่ database ไม่ scale บางทีไม่ได้คิดถึง สมรรถนะของ disk and io subsystem บริหารผู้ใช้ไม่มี identity management ไม่ได้ลด attack surface ลง ไม่ได้ออกแบบให้ระบบ scale out ได้แต่ scale up แบบโบราณ บางที่ไม่ได้เห็นการแบ่งโมดูล การเชื่อมโยง flow และข้อมูล สารพัด ไม่ง่ายนะครับ พวกนี้ทำทีหลังยากมากมาก เช่นถ้าไม่มี role base control ต่อไปการจัดระดับการ access ของข้อมูลอาจจะทำยากหรือไม่ได้เลย
เวลาขอดูงานจะเริ่มที่ความคิดในเชิงสถาปัตยกรรมระบบเขาก่อน ถ้าเขาวางดีแสดงว่าทำเป็น ส่วนอื่นมักจะพอไปได้

212 Nameless Fanboi Posted ID:kBloiRTcoF

>>211 สมมติว่า ทำคนเดียว จะขึ้นทั้งหมดที่ว่ามามั้ย

213 Nameless Fanboi Posted ID:IGqiIHZGjD

𝐏𝐬𝟏 หลายๆอาชีพ มีมามีไป มีหายไป มีเกิดใหม่ ผมอยากให้เน้นความรู้พื้นฐานเอาไว้ให้แน่น เพราะจะทำให้เราเขยิบสาขา หรือเข้าสาขาใหม่ได้ง่าย ไม่โดนเท วิชาเหล่านี้คือหัวใจหลักที่ช่วยผมในทุกสายงานที่เข้าไป Engineer Mathematic, Algorithm​s and data structure, Database Systems, Statistic, Network, Data Communications, Signal Processing and Communication Systems
จะเห็นว่าวิชาเหล่านี้ ไม่มีคำว่า DS หรือDE เลย แต่พื้นฐานเหล่านี้ช่วยให้อ่านเพิ่มเติมได้ง่าย ทำให้ก้าวไปด้านไหนก็ไม่ยากเกินไป

214 Nameless Fanboi Posted ID:j3ElDAgiBp

ในขณะที่กำลังทำ personal side-project ก็เจอ quote นี้ .... มันโคตรจริงยิ่งกว่าจริง ... golden มาก ... ต้องเอามาลงไว้ตรงนี้ด้วย

“Businesses frequently prioritize new feature releases over fixing technical debt. They choose to work on revenue-generating work instead of revenue-protection work. This rarely works out as the business hopes, particularly as problems discovered during the final stages of uncompleted projects drag engineers away from the newer projects.”

― Dominica Degrandis

215 Nameless Fanboi Posted ID:r6.zhU1x7b

คำถามที่ผมเจอบ่อยที่สุดเวลาไปพูดเรื่อง quantum computation คือ เมื่อไรมันจะใช้งานได้จริง คำคอบคือ Now ครับ แต่ว่าจะใช้ได้เฉพาะกับงานบางประเภทเท่านั้น ยกตัวอย่างเช่น เรารู้กันดีว่าการทาสีแผนที่โดยใช้ไม่เกิน 4 สีเป็นปัญหาที่ยากมาก ใช้เวลานานในการคำนวณหากเราใช้คอมพิวเตอร์แบบปัจจุบัน (classical computer) แต่ถ้าใช้ quantum computer จะเร็วขึ้นกว่าเดิมมาก (แม้ว่ายังเป็น exponential อยู่แต่เร็วขึ้นประมาณ quadratic เท่า)
ในวิดีโอนี้ ลูกศิษย์ผม Wen Wen ใช้ quantum computer แบบที่เรียกว่า quantum annealer ของบริษัท D-wave ที่สหรัฐในแก้ปัญหาการทาสีแผนที่โดยใช้ไม่เกิน 4 สี ผลออกมาใช้ได้เลยทีเดียวครับ
ถามว่า D-wave ราคาเครื่องละเท่าไร ทำไมเราไม่ซื้อมาใช้เลยล่ะ ราคาประมาณ 100 ล้านเหรียญสหรัฐหรือประมาณ 3000 ล้านบาทครับ เอาปัญญาที่ไหนมาซื้อ แถมเราไม่ควรจะซื้อเทคโนโลยีของชาวบ้านด้วย เพราะเราจะไม่เรียนรู้อะไรเลย ซื้อใช้อย่างเดียว
ศูนย์เทคโนโลยีควอนตัมของ มช เรา เลยตัดสินใจว่าจะสร้าง quantum annealer ขึ้นมาเอง ราคาน่าจะถูกกว่าเยอะครับ ถ้าสำเร็จ เราจะได้เทคโนโลยีของเราเอง และทำให้ชาติไทยยืนเคียงบ่าเคียงไหล่กับต่างประเทศได้ ไม่เป็นเพียงผู้บริโภคเทคโนโลยีอีกต่อไปครับ
ปล. Wen Wen เป็นนักศึกษาวิศวะไฟฟ้า อินเตอร์เนชั่นแนลโปรแกรมปีสุดท้าย ของมหาวิทยาลัยขอนแก่น แต่มาฝึกงานที่ศูนย์ควอนตัม มช

216 Nameless Fanboi Posted ID:r6.zhU1x7b

ผมเห็นว่า "การขาดแคลนโปรแกรมเมอร์" หรือ "การที่เราต้องการโปรแกรมเมอร์จำนวนมาก" นั้น เป็น Quality Problem มากกว่า ​Quantity Problem ....
พูดอีกอย่างคือ เราไม่ต้องการโปรแกรมเมอร์มากแบบที่เราคิดหรอก .... แต่เราต้องการโปรแกรมเมอร์ที่เก่งกว่านี้ .... ซึ่งมันอาจจะทำให้จริงๆ แล้วเราต้องการโปรแกรมเมอร์จำนวนน้อยลงก็ได้
ทำไมอ่ะ?
คือ โปรแกรมเมอร์ห่วยๆ 1 คน .... สามารถเขียนโค้ดขยะที่ทำงานได้นะ แต่ต้องใช้โปรแกรมเมอร์อีก 2-3 คน (ที่อาจจะต้องเก่งกว่าเขาด้วย) ในการ maintain มันในระยะยาว และไม่มีเวลาไปแก้ไขไปรื้อไปปรับโครงสร้างอะไรกับตรงนี้ .... และถ้ายิ่งโปรแกรมเมอร์ห่วยๆ คนนี้ทำงานใหม่ไปเยอะเท่าไหร่ เรายิ่งต้องการคนมา maintain งานเขามากเท่านั้น ... ดังนั้น โปรแกรมเมอร์ห่วยๆ 1 คน ทำงาน 10 ปี ปีละ 1 งาน ... นี่อาจจะก่อให้เกิดความต้องการโปรแกรมเมอร์ที่เก่งกว่านั้นจำนวน 20-30 คนเลยทีเดียว ....
ถ้าเรามีโปรแกรมเมอร์ห่วยๆ มากเท่าไหร่ เรายิ่งต้องการโปรแกรมเมอร์มากขึ้นเท่านั้น
========================
ข้อความด้านบนนี้ Paraphase จากบทสัมภาษณ์ David Parnas (ที่ผมเห็นด้วยอย่างมากในประเด็นนี้) โดยการใส่ความเห็นส่วนตัวผมเพิ่มเติมลงไป ส่วนบทสัมภาษณ์ต้นฉบับคือ
Q: What is the most often-overlooked risk in software engineering?
A: Incompetent programmers.
There are estimates that the number of programmers needed in the U.S. exceeds 200,000. This is entirely misleading. It is not a quantity problem; we have a quality problem. One bad programmer can easily create two new jobs a year. Hiring more bad programmers will just increase our perceived need for them. If we had more good programmers, and could easily identify them, we would need fewer, not more.

217 Nameless Fanboi Posted ID:2LohaGvH3b

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

"ถ้าเขาไม่รับคุณ"
"ถ้าคุณไม่ดีพอที่เขาจะรับ"

เงินเดือนแค่ไหนคุณก็ไม่ได้ จบ

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

"คนเขาแย่งโปรแกรมเมอร์เก่งๆ กัน ตั้งเงินเดือนกันสูงๆ" เพราะเขาอยากจะจ้างคนเดียวด้วยเงินแสน แทนที่จะจ้างสิบคนด้วยเงินเท่ากัน (คนละหมื่น)...

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

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

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

หลายคนที่ผมรู้จัก นี่ถ้าเรียก 60-150k ผมรู้สึกว่า "สมเหตุผล"

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

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

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

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

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

สิ่งเดียวที่อัตโนมัติ คือ "ตกงาน"

218 Nameless Fanboi Posted ID:7trYK7nNs3

เมื่อปี 62 ผมได้มีโอกาสอ่านข้อความนึง จากกระทู้ที่โพสถามเรื่อง

"เงินเดือน กับ ความสามารถ และ ความรับผิดชอบ"
แล้วก็มาเจอคอมเม้นนึงซึ่งผมคิดว่าตอบได้ครบแทบจะทั้งหมด

ปี 63 ก็เอามารีโพส
ปีนี้ (64) ก็เจอเรื่องเดิมอีกแล้ว

จึงอยากนำมาแบ่งปันกันครับ

----------------------------

อันนี้ผมเคยบอกแล้วว่า เงินเดือน ไม่เกี่ยวกับ skill เลยซะทีเดียว มันมีปัจจัยหลายอย่าง

หลักๆคือ มันคือความพอใจของคนจ่าย ที่เค้าได้ผลประโยชน์ตามที่เค้าต้องการครับ

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

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

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

ทั้งหมดจึงขึ้นอยู่กับปัจจัยต่างๆ ซึ่งส่วนตัวผมเรียงลำดับความสำคัญดังนี้

- สถานะทางเศรษฐกิจของบริษัท
- ความสามารถในการแก้ปัญหาทางธุรกิจ(ไม่ใช่แค่แก้ปัญหาในการเขียนโปรแกรม)
- ความจำเป็นของงานต่อธุรกิจ
- มาตรฐานทางเงินเดือนของประเทศ
- ความเก่งในการ code ของคนคนนั้น

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

อย่าลืมว่าทุกบริษัทต้องการผลกำไร ไม่ใช่ product ที่โคตรเจ๋ง 100% code coverage แต่ไม่มีผลกำไรเลย

ผู้เขียน
Mahasak Pijittum

--------------------------

ที่จริงน่าเอาไปเรียบเรียงเขียน Blog มาก แต่ยังขี้เกียจอยู่ เอาไว้หายขี้เกียจค่อยว่ากันใหม่

และสุดท้ายนี้ "อย่าลืมว่าทุกบริษัทต้องการผลกำไร ไม่ใช่ product ที่โคตรเจ๋ง 100% code coverage แต่ไม่มีผลกำไรเลย"

219 Nameless Fanboi Posted ID:fSw1fEa/c0

อีกหนึ่งวันจะทำงานที่ใหม่นี้ครบปีแล้ว (ซึ่งจนถึงตอนนี้ก็ยังไม่เคยเข้าออฟฟิศเลยแม้แต่ครั้งเดียว) แต่ถึงเวลาจะผ่านไปแค่ปีเดียว ประสบการณ์นี่เยอะกว่าทำงานอื่น ๆ ในชีวิต 5 ปีซะอีก เรียกว่าแฮปปี้มากที่ได้มีโอกาสทำงานกับบริษัทที่ Professional ระดับนี้ ได้เรียนรู้อะไรเยอะเลย
.
เลยขอใช้โอกาสนี้มาจดบันทึกชีวิตการเป็นพนักงานง่อย ๆ ในบริษัทยักษ์ใหญ่สักหน่อยนึงว่าได้เรียนรู้อะไรมาบ้าง =)
.
1) เวลาทำงานไม่ใช่ Metric ที่เหมาะสมในการวัดผลงาน การวัดประสิทธิภาพผลงานด้วยตัวงานนั้นส่งผลดีต่อทุกสิ่งกว่ามาก
.
2) เพศ อายุ เชื้อชาติ หน้าตา สัดส่วน ไม่เคยส่งผลต่อความเก่งของใครเลย มาอยู่นี่ไม่เคยมองว่าโปรแกรมเมอร์หญิงไม่เก่ง ไม่เคยมองว่าอายุน้อยจะไม่เก่ง นี่มีกฎห้ามถามอายุด้วยซ้ำไปเพื่อไม่ให้เกิด Bias
.
3) จงเชื่อว่าทุกคนมีจุดประสงค์ที่ดีเสมอแล้วจะดีเอง ต่อให้การกระทำนั้นทำให้เรารู้สึกไม่ชอบ ก็จงมองให้มันเป็นการกระทำที่มาจากจุดประสงค์ที่ดี
.
4) Blameless เป็นวัฒนธรรมที่สำคัญมาก การไม่หาตัวคนผิด การไม่กล่าวโทษตัวตนแต่ใช้วิธีอุดปัญหาที่ระบบ
.
5) การดราม่าเป็นเรื่องที่ไร้สาระและไม่มืออาชีพที่สุดแล้ว ตั้งแต่ทำงานที่นี่มาไม่เคยเจอดราม่าในที่ทำงานเลยแม้แต่ครั้งเดียว ทุกคนให้เกียรติกันคุยกันด้วยเหตุผล และนั่นทำให้งานเดินอย่างมีประสิทธิภาพมาก
.
6) มีอะไรก็จงคุยกัน ไม่พอใจก็พูด ไม่เห็นด้วยก็พูด งานคืองาน ไม่คุยกันแล้วงานมันจะสำเร็จได้ยังไง
.
7) วัฒนธรรมการให้และการรับ Constructive Feedback ก็เป็นอีกอย่างในการทำให้ทุกคนเก่งขึ้นไปพร้อม ๆ กับสังคมการทำงานที่ดีขึ้น และ Constructive Feedback ก็ไม่ใช่การด่าแหลกแล้วอ้างว่าติเพื่อก่อ มันเป็นการกระทำที่ราคาถูกและไร้ค่า
.
8) คนเก่งจัด ๆ ไม่ได้แปลว่าจะเป็นสุดยอด Asset ของบริษัท สกิลทำงานเป็นทีมต่างหากที่สำคัญกว่ามาก
.
9) สกิลการสื่อสารเป็นสิ่งที่ "ต้องมี" ในการทำงานอย่างมืออาชีพ ไม่ใช่สิ่งที่มีก็ดี แต่มันต้องมี
.
10) เงินเดือนสูงสำคัญ(มาก)นะต่อการทำให้คนตั้งใจทำงานและอยากเก่งขึ้น ไม่ใช่เพราะกลัวตกงาน แต่มันทำให้โฟกัสงานได้อย่างเต็มที่ต่างหาก
.
11) Manager ไม่ได้ทำตัวเป็นหัวหน้าและอยู่เหนือกว่า Engineer แต่เป็นคนที่ทำอีกหน้าที่นึงเท่านั้น สุดท้ายทุกคนคือเพื่อนร่วมงานที่มีปลายทางเดียวกันคือการทำงานให้สำเร็จ การให้ Feedback ไปมาเป็นเรื่องปกติมาก
.
12) การทำงานหนักมาก ๆ ไม่ใช่สิ่งที่บริษัทใหญ่ของเมกันต้องการ แต่เค้าต้องการให้เราพักผ่อนและมีชีวิตของตัวเองด้วย "การพักผ่อนเป็นส่วนนึงของการทำงาน"
.
13) Fundamental คือทุกสิ่งสำหรับงาน Engineer ฐานแน่นฝึกได้ทุกอย่าง แต่ฐานอ่อนก็คือไปต่อยากมาก ความต่างของคนที่เก่งขึ้นไม่หยุดกับคนที่วนอยู่กับที่อยู่ที่ตรงนี้เลย (เห็นคนไทยเถียงกันว่าทำไมต้องรู้ว่า Quick Sort ทำงานยังไงไปทำไมถ้าโหลดมาใช้ก็จบแล้วก็ช่างปวดใจ)
.
14) ความสามารถในการเรียงลำดับความสำคัญ (P0-P3) เป็นอีกสกิลที่สำคัญสำหรับคนทำงานในทุกระดับหน้าที่
.
15) งานโปรดักส์มันไม่มีคำว่าเสร็จสมบูรณ์ (เพราะมัน Subjective) มันมีแค่ Ready to Launch หรือยัง ต้องรู้จักวางแผนว่าอะไรเป็นงานที่ Blocked ส่วนไหนเป็น Non-Blocked จะได้วางแผนการ Deliver ให้ตรงตาม Deadline ให้ถูก
.
16) จงให้เครดิตทุกคนกับทุกสิ่งที่เค้าทำ ถึงจะเป็นเรื่องเล็ก ๆ น้อย ๆ แต่ก็ช่วยทำให้บรรยากาศการทำงานดีมาก ๆ การขโมยเครดิตถือเป็นสิ่งที่ร้ายแรงมาก ห้ามทำเป็นอันขาด
.
17) การประชุมให้มีประสิทธิภาพต้องอาศัยการจัดการที่ดี การประชุมที่ดีจะช่วยลดเวลาทำงาน การประชุมที่ไม่ดีจะเป็นการเสียเวลาทำงาน จะประชุมต้องรู้จักวางแผนและควบคุมให้ดี
.
18) การประชุมที่ดีต้องมีเวลาล็อคไว้ชัดเจนและห้ามเกินเวลา
.
19) คนที่นี่ขยันเก่งขึ้นตลอดเวลามากทั้ง ๆ ที่งานเยอะมากอยู่แล้วก็ยังหาเวลาฝึกตัวเองเพิ่มได้อีก สุดท้ายคือทุกคนมีความสามารถในการบริหารเวลา ถือเป็นอีกสกิลที่ทุกคนควรมี
.
20) สำหรับสายงาน Software Engineer หลังจากลาออกจากที่นึงก็แทบจะได้งานใหม่ในอีกที่นึงทันที
.
21) การถูกรายล้อมด้วยคนเก่งจะช่วยให้เราเก่งขึ้นเองได้จริง ๆ
.
ไม่รู้ว่าโชคดีหรือโชคร้ายที่เริ่มงานปุ๊บก็ WFH ปั๊บ แต่ต้องบอกเลยว่าเพราะ WFH นี่แหละเลยได้เรียนรู้อะไรเยอะกว่าปกติมาก (โดยเฉพาะวิธีการทำงานและการจัดการเวลาของตัวเอง) ไม่รู้จะได้เข้าออฟฟิศเมื่อไหร่ ตลอดปีที่ผ่านมาเคยเจอเพื่อนร่วมงานตัวเป็น ๆ แค่ 3 ครั้งเอง แต่คิดว่าถ้าได้เข้าออฟฟิศคงได้เรียนรู้อะไรมากกว่านี้อีก
.
รออย่างใจจดใจจ่อ ไว้เจอกันน้าออฟฟิศคุงงง =)

220 Nameless Fanboi Posted ID:3hHd1LsHrF

มันลำบาก บ้าเนราอยากได้คนเก่งแต่ไม่มีงานดีๆให้คนเก่งมันทำ

221 Nameless Fanboi Posted ID:NVgyy+O4Un

https://discord.gg/69z5u4Z5