DEV ที่กูเคยเจอไร้ประโยชน์กว่า AI อีก
Last posted
Total of 1000 posts
DEV ที่กูเคยเจอไร้ประโยชน์กว่า AI อีก
>>975 หลักๆ เลยตำแหน่งนี้เอาไว้คุยอย่างเดียว ไม่ว่ากับกับลูกค้า คุยกับเซล ทำงานกึ่ง AE หา Supplier ติดต่อปริษัท server / service / license ต่อรองกำหนดส่ง ประสานงานข้ามสาขา จัดคิวงาน
ไอ้ตำแหน่งนี้ไม่ต้องมีก็ได้ถ้า Dev ทำงานพร้อมคุยได้ตลอดวัน
กูเคยทำควบ PM กับ Dev นะ สรุปคือไม่รอดจ้า ประสาทจะแดกเอา ระชุมทั้งวันอารมณ์ขึ้นๆ ลงๆ เพราะต้องผ่านลูกค้าประสาทแดก Supplier ห่วยแตกนั่นแหละ ได้มาทำงาน Dev ได้ทำเอาตอนทุ่มนึงตอนนั้นก็คิดอะไรไม่ออกแล้ว สุดท้ายต้องโอนงาน PM ไปให้คนอื่นแทน
ปล. เวลาทำงานส่วนมากมันก็บ่นว่างานกูหนักสุดทุกคนนั่นแหละ เพราะมันมองเห็นแค่งานตัวเองไง เอาแบบ Sale ก็ได้ถ้าดูผ่านๆ ไอ้นี่งานไม่หนักเลยได้ยอดได้เงินเพิ่มและ บริษัทก็โอ๋มากไม่ต้องเข้างานก็ได้ แต่ถ้าลองไปทำจริงจะรู้ว่าเครียสชิบหาย บุคคลิกบางคนนี่ไม่เหมาะทำไม่ได้
>>977 กูคือคนที่บ่นนะ ขยายความเพื่อความเคลียร์ละกันว่าไอ้งานคุย+ทำเอกสารตาม process ของบริษัท ซึ่งเป็นหน้าที่ของมันโดยตรงมันยังไม่ทำเลย เฉไฉโยนให้คนอื่นคุยแทน/ทำแทน มีคนเหลืออดไปจี้ในที่ประชุมว่าแต่นี่มันหน้าที่มึงนะมันยังหน้าด้านหาข้ออ้างไม่ยอมทำเลย ส่วนถามว่าทำไมไม่ฟ้องผู้ใหญ่ คือนึกภาพบริษัทใหญ่มากๆ แถมในโปรเจคคือคนทีมไหนก็ไม่รู้มีเป็นสิบทีม ไม่รู้จะฟ้องใคร ฟ้องผู้ใหญ่ไปก็ดูเป็นคนขี้ฟ้องเปล่าๆอีก
>>977 PM ที่กูเจอไม่ทำอะไรเลยอ่ะมึง ไม่ต้องติดต่ออะไรด้วย ซึ่งจริง ๆ ต้องทำเอกสารนะแล้วก็ต้องช่วยทีมตัดสินใจในบางเรื่อง แล้วทีมกูก็เล็กมากมันไม่ต้องมีก็ได้อ่ะ เอา dev มาเพิ่มยังทำให้งานออกมาเยอะกว่าอีกอ่ะแต่ไม่เอา เอาคนไม่รู้ห่าอะไรมาเป็น PM ก็ไม่ได้เพิ่ม productivity ทีมอะไรอยู่ดี สรุปคือกูเห็นด้วยกับมึงตรงที่ว่าถ้า dev พร้อมคุยก็ไม่ต้องมีก็ได้ แต่ถ้าทีมใหญ่ stakeholder เยอะก็ควรมีอ่ะ มันจะทำให้การทำงานราบรื่นขึ้นมาก ๆ แต่ถ้ามีแล้วเหมือนไม่มีไม่ต้องมีดีกว่า
>>978 มึงเจอคนเหมือนกูเลยนะ คนที่กูเจอก็โยนแม่งตลอด เบลมเก่งเป็นที่หนึ่ง งานตัวเองไม่ทำไรเลยดีแต่พูดอย่างเดียว พูดทีก็ถามว่า dev จะเสร็จเมื่อไหร่ ทำไมอันนี้ไม่เสร็จ ทำไมอันนี้บอกเวลาเลยไม่ได้ แต่ไม่เคยคิดจะเข้าใจห่าไรเลย ลอยตัวเหนือทุกอย่าง กูก็อยากถามมากว่าจะมีไว้ทำไม แบบที่ดี ๆ ก็คงมีมั้ง แต่กูโชคร้ายไม่เจอ ดันเจอพวก free rider
Complex System, Emergent
นอกเรื่องหน่อยเพื่อนโม่ง กูจะไปสาย FullStack ยุคนี้เวบมันมีโฮสเจ้าใหนดีๆบ้างสำหรับเวบแอป
แล้ว docker / kuber aws เรียนตัวใหนดี หางานในไทย
แล้วเวบขนาดใหญ่ lazada shopee nocnoc ใช้ตัวใหน
มือใหม่เปิดโลกทำเวบจ้า
คือกูจะทำ demo project webapp + mobile + backend กะทำไว้ต่อยอดเป็น pitching project ด้วยเลย
แต่กูโง่เรื่องเวบมาก เพราะบ้านไม่รวย สมัยเรียนค่าโฮสแพงๆไม่มีจ่าย ทำได้แค่พวกโมบาย ตอนนี้มีตังแล้ว หน้าใหม่หัด FS
กึ่งๆโดนบังคับให้มาเป็น team lead แล้วรู้สึกไม่ค่อยชอบเลยว่ะ อยากทำงานนั่งเขียนโค้ดเงียบๆ ไม่ต้องยุ่งคนอื่นเกินจำเป็น
ไม่อยากมาเข้าประชุม ทำดีไซน์ ทำสไลด์ บรีฟงานน้อง ตรวจงานน้อง คุยกับคนทีมอื่นแล้ว...
>>987 ก่อนจะมางอแง มึงลองสมัครแล้วเข้าไปอ่านก่อนเถอะโยม
ตัวที่ใช้งานมันก็แค่ตัวติดตั้งนะ สมมุติ html / css / javascript มึงก็ไปใช้ codepen เขียนบนเว็ปได้เลย กะอีแค่เปิดเว็ปอะไรก็ได้มือถือ table ได้หมด
ส่วน requirement มันคืกกรณี run บนเครื่อง ส่วนเหตุผลมันก็เขียนบอกว่าไม่อยากยุ่งยากเสียเวลาไล่เพราะแต่ละเครื่องชอบลงเหี้ยอะไรไว้หลากหลายต้องมา support พวกโง่งอแง config มั่วซั่วไป Mac / Linux จบๆ อย่างน้อยก็ไม่มีอะไรไปป่วนระบบมัน กรณีใช้ Win ก็ลง Virtual Machine รัน Linux ไปดิ
ปล. อยากให้สอนส่วนติดตั้งบน win ตรงๆ เริ่มต้นด้วยพื้นฐาน แล้วถ้ามึงเป็น newbie ด้วย กูแนะนำให้มึงไปซื้อ course udemy เหอะ
hello พี่โม่ง ว่าจะเรียนโทไอที เรียนที่ไหนดีครับ เล็ง ลาดบังกะ มศว ไว้อยู่
เห็นมีคุยกันเรื่อง front end สายเว็บ สงสัยว่าเวลาพวกมึงจะเลือก framework นี่เลือกจากอะไร
แล้วเคยรู้สึกว่าตัวเองเลือกผิด ต้องมาเริ่มเรียนรู้ใหม่หมดจนเสียเวลาเสียโอกาสบ้างมั้ย
คือกูเป็น backend แล้วเวลาฟังคนเป็น front end สายเว็บ คุยกันแล้วรู้สึกเหนื่อยแทน
ทั้ง framework เลือกผิดชีวิตเปลี่ยน กับเทรนด์ที่แม่งเปลี่ยนกันเป็นว่าเล่น
>>991 มองแนวกว้างดูไม่ว่าภาษาไหน หรือจะวาดกระดาษ concept responsive ภาษาไหนก็เหมือนกันหมด ส่วนที่เหลือถ้าพวก web / app ยิ่งง่าย ให้ยึดหลัก html css ธรรมดาที่เหลือมันแค่ตัวช่วย (บางที framework เสือกช้ากว่าเขียนดิบ) วางโครงได้ที่เหลือ animation มันแค่แฟชั่น แฟนซี เอาจริง timing ถ้ามึงเคยเขียนเกมนี้หมูเข้าปาก
ส่วน backend web ช่วงหลัง ส่วนตัวแล้วถ้าไม่ใด้ทำอะไรบ้าบอคอแตก กูใช้ wordpress ปิดงานซะส่วนมากว่ะ เพราะถ้าใช้ framework เป็นทางการ รู้สึกเปลือง ในเมื่อส่วนที่จะใช้เดี๋ยวนี้มันมีให้ครบหมดแล้ว ต่อ firebase / cronjob / ap / แบ่งระดับ account มันทำได้หมด เลยใช้อะไรที่ปิดงานไวดีกว่า
Agoda เปนไงบ้างพี่โม่ง รีวิวหน่อย
มีใครเคยสัม lseg/abacus/techx บ้างอ่ะ อยากรู้สัมเป็นไงบ้าง
เราจะวิจารณ์หรือด่า Solution ได้ยังไงถ้าเรายังไม่เข้าใจเลยว่าเขาจะแก้ปัญหาอะไร
สมัยก่อนคนหลายคนวิจารณ์ Go ว่าห่วยเพราะไม่มี Generic โดยไม่เข้าใจว่า Go มันออกแบบมาเพื่อเน้นแก้ปัญหาอะไร คือเขาต้องการ System programming language ที่มี Dev productivity ที่ดีและ Learning curve ต่ำ เขาก็เลยไม่ได้ให้ความสำคัญกับเรื่องนั้นจนมันมาหลังๆ
สมัยนี้เห็นคนบ่นว่าเว็บ Complex กว่าทำ UI สมัยก่อน แต่ไม่ได้เข้าใจว่า Web app เดี๋ยวนี้มันมี Brand identity ที่ต้องใส่เข้าไปในแต่ละเว็บไซต์หรือแม้แต่เว็บแอพ ลองทำ ปุ่ม Label Textbox ที่แบบต้องได้สีได้ลุคแอนด์ฟีลที่ใช่ที่เข้ากับ Brand identity ในสมัยที่เรามี Winform ดิ เหนื่อยมากนะ
(นี่ผมยังไม่นับเรื่อง Interactivity นะ เว็บเดี๋ยวนี้กรอกฟอร์มเป็น Wizard แบบสมัยก่อนไม่ได้แล้วนะ)
บางคนอาจจะเถียงกลับว่า UI ที่ดีควรล้อเข้ากับ Native อะไรที่อยู่บนแมคก็ควรมี Look & Feel แบบแมค อะไรบนแอนดรอยด์ต้องเป็นตาม Guideline ของแอนดรอยด์ดิวะ ทำไมคนสมัยนี้ UX ทำตามใจแบรนด์ตัวเองหมดไม่เคารพแพลตฟอร์มเลย
อันนี้คือข้อแตกต่างระหว่างโจทย์ที่ว่า
"เราให้ความสำคัญกับปัญหานี้เยอะไปมั้ยทำไมเราต้องมาบ้าเรื่องทำ Custom UI ที่ตรงกับแบรนด์ Identity ขนาดนี้ มันใช่มั้ยเนี่ยที่จะเอาปัญหานี้มาเป็นจุดโฟกัสของงานแล้วสร้างเฟรมเวิร์คเยอะแยะไปหมด"
กับ
"ปํญหานี้ที่เราเลือกมาแล้วว่าจะแก้ เราจะสร้าง Custom UI ให้ได้แล้วเนี่ย เราได้สร้าง Solution ที่ดีสมเหตุสมผลมั้ย มัน Unnecessary bloat, ไร้ประสิทธิภาพและซับซ้อน complex เกินไปมั้ย"
เนี่ยเป็นข้อแตกต่างที่ชัดเจนมาก คำถามแรกคือ Design question ส่วนคำถามที่สองคือ Problem solving question สองโจทย์นี้เป็นโจทย์คนละระดับกันเลย มันเอามาปนกันแล้วจะงงไปหมด
มันเหมือนคุณวิจารณ์ว่าค้อนแม่งแย่เพราะเอามาใช้ตีลูกปิงปองแล้วมันตีไม่เป็นโดนเลยเงี้ย มันไม่ได้เว้ย เออ คุณไม่สนใจเรื่องตอกตะปูสนใจแต่เรื่องตีปิงปองก็ไม่ผิดอะไรนะ แต่วิจารณ์ค้อนในกรอบที่ราวกับว่าคนสร้างและใช้ค้อนเขาไม่ได้อยากตอกตะปูแต่อยากตีปิงปองเนี่ยมัน..... ผิดที่ผิดทางไปหมด
ในซอฟต์แวร์นี่เจอบ่อยมากที่คนใช้เลนส์แบบฉันอยากจะตีปิงปองเลยวิจารณ์ทุก Design decision ราวกับว่าทุกๆ System ออกแบบมาตีปิงปอง
"Go ไม่มี Generic ไม่มี Type system ที่ดี กาก" โปรแกรมเมอร์ที่คิดว่าโลกนี้ Type safety เท่านั้นคือปัญหาที่สำคัญ
"Ruby on Rails ช้า กาก" โปรแกรมเมอร์ที่คิดว่า Machine performance เท่านั้นคือปัญหาที่สำคัญ
(ซึ่งแปลกไอ้แนวคิดแบบที่ว่าปัญหาที่กูสนใจเท่านั้นคือปัญหาสำคัญของโลกนี้ที่ทุกระบบต้องออกแบบโดยใส่ใจสิ่งนี้เป็นที่สุดนะเว้ย เจอบ่อยในโปรแกรมเมอร์ต่างชาติมากกว่าไทยแฮะ ถ้าจะมีอะไรที่คิดว่าโปรแกรมเมอร์ไทยโดยเฉลี่ยทำได้ดีกว่าก็เรื่องนี้)
"Modern web development สมัยนี้มัน Bloat และซับซ้อนไปหมด" เนี่ยเจอคนที่วิจารณ์อย่างเข้าใจว่า Modern tooling มันมีไว้แก้ปัญหาอะไรน้อยมากๆ คือผมก็คิดว่า Modern tooling มันมีอะไรให้พัฒนาได้เยอะและก็มีข้อให้ติเยอะมากเลยนะ
แต่เจอแบบ "ทุกคนควรกลับมาทำ DOM Manipulation เพราะมันเร็วกว่าเปลืองทรัพยากรน้อยกว่าและไม่ซับซ้อน" อันนี้คือดูไม่เข้าใจไปเลยว่านี่มันค้อนตอกตะปู ไม่ใช่ไม้ปิงปองเว้ย
คือผมคิดว่าเราจำเป็นจะต้องเข้าใจว่า
1. Design กับ Problem solving มันเป็นโจทย์คนละแบบ การเลือกปัญหาที่ใช่ กับการแก้ปัญหาที่เลือกมาแล้ว มันคือโจทย์คนละอย่างกันเลย ถ้าไม่เข้าใจว่ามันคนละเรื่องก็จะมองหรืออ่าน Solution แบบผิดเพี้ยนไปหมด ยังไม่ต้องพูดถึงการวิจารณ์
2. การเลือกปัญหาให้มันทำผ่านการเข้าใจว่ามนุษย์เรามี Unmet need อะไรบ้างที่เป็นไปได้
3. ความสามารถในการเข้าใจ Empathize กับ Unmet need ที่ "ตัวฉัน" รู้สึกเฉยๆ เป็นทักษะสำคัญที่ต้องมีในการทำงาน Design Software, Solution and Architecture มากกกก มากกว่าที่หลายคนอาจจะตระหนักรู้ (อย่างเช่นหลายคนที่ทำงาน low-level ก็มีที่มองว่าไอ้พวกที่มันโอดร้องว่าอยากได้เครื่องมือที่ช่วยทำงานง่ายขึ้น ต้องการ Garbage collector มันก็แค่คนขี้เกียจไม่มีทักษะในการจัดการเมมโมรี่! เราต้องทำของที่ไวสิวะแล้วต้องเข้าใกล้ Machine level ให้มากที่สุดสิวะ! อันนี้ก็คือขาดสามารถในการ Empathize ไปเลย)
เลือกปัญหามาแก้ถูก บางทีทำงานไม่ตรงเป๊ะลูกค้ายังเซ็นผ่านเลย เลือกปัญหาผิดมาแก้ ตรงตามสโคปในสัญญาทุกตัวอักษรยังไฝว้กันได้เลย (ผมไม่ตัดสินละกันว่าอันนี้ดีหรือไม่ดี แต่เป็นเรื่องที่เกิดขึ้นจริง)
นั่นแหละที่สอน Humanistic architecture ก็คือตั้งใจจะ Address เรืองนี้ เป็นคอร์สที่ผมอยากสอนที่สุด คิดเอาเองว่ามีประโยชน์กับโปรแกรมเมอร์ที่พร้อมรับ อย่างน้อยผมก็พบว่าสำหรับตัวเองมันเป็นแกนกลางการทำงานของผมเลย
บางคนอ่านคอร์สและอ่านรีวิวอาจจะงงว่าเรื่องแบบจิตวิทยา การเข้าใจตัวเอง การเข้าใจคุณค่าและพื้นฐานของความต้องการมนุษย์ มันเกี่ยวข้องกับ Software architecture design ยังไง งาน Software Architecture มันน่าจะเรียนเรื่องแบบ Distributed system, database, horizontal scaling, idempotency, design pattern อะไรพวกนี้ไม่ใช่เหรอ
ผมคิดว่ามันเกี่ยวอย่างที่สุดแล้ว เกี่ยวแบบคือ Step 0 ในระดับรากฐานที่สุดเลย คุณเลือกปัญหาอะไรมาแก้ก่อนล่ะ ปัญหาระบบล่ม? ปัญหาต้นทุน? ปัญหาฟีเจอร์ออกช้า? หรือไม่เลือกอะไรเลยออกแบบไปเรื่อยเปื่อย? ถัดมา คุณ Trade อะไรทิ้งไป ลดความสำคัญของปัญหาอะไรลงไปบ้าง
นี่อ่ะคือแกนกลางของงานออกแบบ Architecture ชัดๆ
ทั้งทักษะการ Problem solving และทักษะการ Design มันสำคัญทั้งคู่ แต่ที่สำคัญเลย มันเป็นคนละทักษะกันครับ และถ้าไม่เข้าใจ คิดว่าโลกซอฟต์แวร์มีชุดปัญหาชุดเดียวเท่านั้นที่สำคัญ (เช่นระบบไม่ล่มบ้างล่ะ ความมี Resource efficient บ้าง ต้นทุนการรันอินฟรา ความปลอดภัยขั้นเทพบ้าง) คุณจะไม่สามารถเห็นคุณค่าของ Solution หรืองานออกแบบที่ออกแบบมาแก้ปัญหาที่คุณไม่ได้เลือกได้เลย
ในประเทศไทยผมยกและซูฮกให้พี่เดฟไปแล้วเรื่องการสอนทักษะ Problem solving ผมว่าผมสอนได้ทั้งไม่ดีและไม่ลึกเท่าแกหรอก ให้แกดีกว่า
(ถ้าพี่ผ่านมาอ่านแล้วอยากให้ Tag บอกได้ เผื่อให้คนตามไปดูพี่ออกคอร์ส)
ผมอยากเสริมจุดที่ผมว่านักพัฒนาหลายคนมองข้ามคือจุดของงาน Design เวลามีคนความต้องการขมุกขมัวที่อึดอัดไปหมดจนพร้อมจ่างเงินมากมาย เราจะออกแบบว่า Concrete problem ที่ช่วยเยียวยาความต้องการนั้นได้คืออะไรนะ
แล้วจากจุดนั้น จึงทำการ Problem solving ต่อไป
(นี่เริ่มมาจากฟังคลิปใหม่ของ Theo ที่นั่ง Defend web development จากพวก "ปรมาจารย์ด้าน Performance" ต่างๆ ที่นั่งด่าว่าทำเว็บสมัยนี้มัน Bloat มัน Complex ช้าไปหมดมีแต่เครื่องมือไร้สาระแก้ปัญหาไร้สาระ ก็แบบ..... ของขึ้นอ่ะนะ เข้าอกเข้าใจในโจทย์กันก่อนดีมั้ยคะ)
มันมีหลายภาษาและหลาย Solution design ที่ผมกล้าพูดว่ามันออกแบบมาโคตรดีและงดงามจัดๆ แต่ผมไม่ชอบ เพราะมันไม่ได้แก้ชุดของ Problem ที่ผมคิดว่า Matter ในประสบการณ์ส่วนตัว ผมก็สามารถซาบซึ้งในความสวยงามของมันได้ และเลือกใช้มันได้เวลาที่ต้องการอ่ะครับ
1000
Topic has reached maximum number of posts.
Please start a new topic.
Be Civil — "Be curious, not judgemental"
All contents are responsibility of its posters.