บทความนี้เป็นของคุณ Dan Goslen ซึ่งเขาจะมาถ่ายทอดประสบการณ์ของเขาเกี่ยวกับ 3 ข้อผิดพลาดที่ใหญ่หลวงของ Junior Software Engineer
ในช่วงที่เรียน Dan มีประสบการณ์เขียน Code มามากมายทั้งใน Class เรียน ทั้ง Personal Project และพวก Job เสริมต่าง ๆ หลายงาน ซึ่งเขารู้สึกมั่นใจมากว่า สักวันหนึ่งจะได้เริ่มงานในแวดวง Software Engineering จนหลังจากเรียนจบ เขาเริ่มงานเป็น Junior Software Engineer ซึ่งก็คล้าย ๆ กับ Junior Engineers คนอื่น ๆ เพียงแค่ 2 สัปดาห์แรกของการทำงาน เขาก็ทำงานพลาด Code ที่เขาเขียนเกิด Bugs ซึ่งมีส่วนทำให้สมาชิกในทีมต้องใช้เวลาทำงานเพิ่มขึ้นมากกว่าที่ควรเป็น
แต่ความผิดพลาดอันใหญ่หลวงที่กล่าวถึงนี้ ไม่ได้เป็นเรื่อง Bugs หรือทำ Project ไม่เสร็จตามเวลา แต่เป็นเรื่องของความ “กลัวที่จะถูกคนอื่นมองว่า ไม่เก่ง/ด้อยค่า” หรือที่หลาย ๆ คนรู้จักกันในชื่อ “Imposter Syndrome” กลัวคนอื่นจะหาว่า ทำไมไม่รู้จัก Idea/Concepts บางอย่างหรือทำไมไม่รู้จักวิธี Traverse Tree เป็นต้น ซึ่งเจ้าความกลัวนี่แหละที่ทำให้เกิดความผิดพลาดในการทำงานของเขา เรามาดูว่าสิ่งเหล่านั้นคืออะไรบ้าง
1. ไม่รู้จักถามให้มากพอ
หลายคนอาจจะเป็นแบบนี้คือไม่ค่อยชอบถาม ซึ่งอาจเป็นเพราะไม่มีประสบการณ์และความรู้ยังไม่มากพอ ก็เลยไม่รู้ว่าควรจะถามอะไรดี แต่สำหรับ Dan แล้ว เขาไม่เชิงว่าจะเป็นแบบนั้นซะทีเดียว เวลาอยากรู้อะไรเขาจะลอง Search หาข้อมูลเอง ไม่ว่าจาก Google หรือจาก Stackoverflow
ในที่ประชุม Dan มักจะพยักหน้า และเห็นด้วยอย่างเงียบ ๆ กับสิ่งที่คนอื่นในทีมพูด โดยหวังว่าพวกเขาจะไม่ขอข้อมูลหรือความเห็นจากเขาโดยตรง
ส่วนที่เกี่ยวกับ Code เอง Dan เพียงนั่งอ่าน Code แย่ ๆ (หน้าที่แรกของ Dan คือพยายามทำให้ Billing System มัน Update ยิ่งขึ้น) ซึ่งหวังว่า จะอ่านแล้วเข้าใจว่ามันทำอะไรบ้าง แต่ความจริงคือ “ไม่เลย” Dan ใช้เวลาหลายชั่วโมงเพื่อไล่ดู Code ที่เขาไม่สามารถเข้าใจได้ เพราะ เขากลัวเกินกว่าที่จะถามความหมายของคำย่อหรือคำศัพท์ต่าง ๆ ที่เขาไม่รู้จัก
จงกล้าถาม! จำไว้ว่า Engineer ทุกคนในทีมล้วนต้องเรียนรู้ทุกสิ่งที่พวกเขาต้องรู้ พวกเขาอาจมีบางสิ่งที่ไม่ได้เรียนรู้มาหรือไม่มีประสบการณ์ที่มากพอในทุก ๆ เรื่อง พวกเขาอาจต้องการความช่วยเหลือในการเรียนรู้ด้วยเช่นกัน ดังนั้น จงอย่าท้อแท้กับสิ่งเหล่านี้ง่าย ๆ
หรือบางทีพวกเขาก็อาจเป็นเหมือนคุณ คือแค่พยายามตามให้ทัน คุณจะรู้สึกประหลาดใจว่ามี Engineer กี่คนที่พยักหน้าและเห็นด้วยอย่างเงียบ ๆ เกี่ยวกับบาง Idea และบางสิ่งที่พวกเขาไม่มีความรู้ในเรื่องเหล่านั้นเลย
แทนที่คุณจะรู้สึกอาย จงเรียนรู้วิธีที่จะตั้งคำถามที่เหมาะสม ซึ่งมุ่งเน้นไปที่การยกระดับความเข้าใจสำหรับคนทั้งทีม ตัวอย่างเช่น:
“คุณพูดถึงบางสิ่งเกี่ยวกับ Partitioning ซึ่งผมไม่ค่อยเข้าใจ คุณช่วยอธิบายเพิ่มมากขึ้นอีกหน่อยได้ไหม?”
“ผมมีปัญหาในการทำความเข้าใจว่า Project นี้ได้รับการออกแบบมาอย่างไร? เรามีเอกสารอะไรที่คุณพอจะช่วยอธิบายให้มากขึ้น?”
“ผมพยายามที่จะเรียนรู้เพิ่มเติมเกี่ยวกับวิธีใช้ Ansible แต่ผมยังไม่ค่อยเข้าใจ คุณพอจะช่วยอธิบายให้ผมได้ไหม?”
2. เชื่อมั่นในความเห็นตัวเองมากเกินไป
ในทางกลับกัน เมื่อ Dan ไม่ได้ตั้งคำถาม หาข้อมูลทุกอย่างด้วยตัวเอง กลับทำให้เขาเชื่อมั่นในตัวเองมากเกินไป
Dan พบว่า สิ่งนี้เกิดขึ้นกับเขามาได้สักปีหนึ่งแล้ว เมื่อถึงจุดหนึ่งที่เราได้รับความรู้มาก ๆ และต้องการแสดงถึงสิ่งที่ได้เรียนรู้ในขณะทำงาน สิ่งนี้ทำให้เขาเรียนรู้ว่า “ประเภทของความผิดพลาดที่เกิดขึ้น จะเปลี่ยนแปลงไปเรื่อย ๆ ตลอดการทำงาน”
Dan รู้สึกว่า มันเร็วเกินไปที่จะยืนยันในความคิดเห็นของตัวเอง และเชื่อมั่นมากเกินกว่าที่จะรับฟังผู้อื่น
ในทีมของ Dan มี Senior Engineer คนใหม่ที่จะเข้ามาดูสิ่งที่คนในทีมสร้าง และเขาก็เริ่มต้นอย่างรวดเร็วเพื่อแสดงให้คนในทีมเห็นว่า ทำอะไรผิดไปบ้าง ซึ่งอันที่จริงควรมี Senior Engineers สัก 2 – 3 คนในทีมก่อนหน้านี้ด้วยซ้ำ
มันเป็นกระบวนการที่ Dan ตระหนักว่า เขายังไม่รู้ว่าเขากำลังทำอะไรอยู่ เขามีวิธีที่จะเรียนรู้มากกว่าที่เขารู้ ตอนนี้ Dan เรียนรู้ที่จะฟังมากขึ้น ตั้งคำถาม และเข้าใจว่าคนเราอาจไม่รู้ไปเสียทุกอย่าง
คุณอาจจะมีประสบการณ์ในลักษณะนี้มาบ้างแล้ว เวลาที่คุณรู้ว่าคุณได้เรียนรู้อะไรมามากมาย แต่คุณรู้จักถ่อมตน คุณก็จะมีโอกาสที่จะได้เรียนรู้อีกมากมาก หากเป็นไปได้ให้รีบปรับเปลี่ยนความคิดซะ ก่อนหน้านี้คุณอาจยอมรับว่าคุณไม่มีทางที่จะรู้ไปหมดทุกอย่าง แต่ยิ่งคุณเริ่มปรับปรุงตัวเองเร็วเท่าไร คุณก็จะได้เรียนรู้และเติบโตได้เร็วยิ่งขึ้น
3. ไม่ได้ทำ Project ที่ไม่เกี่ยวกับการ Coding
นี่คือสิ่งที่ Dan คิดว่าเป็นความผิดพลาดที่ใหญ่หลวงที่สุด แทนที่จะฝึกฝนพัฒนาการเขียน Code ให้ดีขึ้น แต่เขายังต้องจดจ่ออยู่กับ Code ที่อยู่ตรงหน้าเพียงอย่างเดียว
แต่อย่าเพิ่งเข้าใจผิด การที่ Dan Focus ไปที่ Code และ Project ของนายจ้าง ถือเป็นสิ่งที่สำคัญต่อการเป็น Engineer ที่ประสบความสำเร็จ อย่างไรก็ตาม เขาก็หวังว่าจะได้ไปบรรยาย 2 ชั่วโมงต่อสัปดาห์ของ Coding Project เพื่อทำการพัฒนา Open-Source หรือทำ Coding Challenges ใน LeetCode หรือ TopCoder
ส่วนใหญ่ Dan ทำงานในการสร้าง High-throughput และ Low-latency Distributed Services ซึ่งสื่อสารผ่าน RESTful API ที่บริษัท ช่วงแรกมันก็รู้สึกว่ามีความท้าทาย แต่หลังจากนั้นไม่นานพวกมันส่วนใหญ่จะมีความคล้ายคลึงกัน Dan จึงพบว่าเขาแก้ปัญหาพวกมันด้วยวิธีที่คล้ายคลึงกันมาก
แต่ Dan ก็ไม่ได้ทำงานเกี่ยวกับ Graphics หรือแม้แต่ Text Editors (รวมทั้งอื่น ๆ) แน่นอนว่า เขาไม่รู้ว่าพวกมันมีความท้าทายที่แตกต่างกัน
การทำงานกับ Code ที่นอกเหนือจาก Project งานหลักของคุณ ถือเป็นวิธีที่ยอดเยี่ยมในการเพิ่มทักษะการเขียน Code โดยรวมและช่วยให้ Resume น่าสนใจยิ่งขึ้นผ่านการมีส่วนร่วมใน Open-Source หากคุณใช้เวลาเพียงไม่กี่ชั่วโมงต่อสัปดาห์ เชื่อว่าคุณจะพบว่าทักษะของคุณจะพัฒนามากขึ้น แล้วในที่สุดคุณจะเป็น Engineer ที่มีคุณภาพและเก่งขึ้นอย่างแน่นอน
ISM Technology Recruitment Ltd. (#1 Tech Recruiter in Thailand) เราเชี่ยวชาญในธุรกิจ IT Recruitment & IT Outsourcing โดยเฉพาะ เปิดทำการกว่า 30 ปี มีพนักงานทุกสายและทุกระดับทางด้าน IT ที่ได้ร่วมงานกับลูกค้าองค์กรใหญ่ที่มีชื่อเสียงและบริษัทข้ามชาติมากมาย หากคุณเป็นคน IT ที่อยากทำงานท้าทายและร่วมงานกับองค์กรชั้นนำ สามารถฝากประวัติการทำงาน (Resume) ของคุณไว้กับ ISM ได้ที่ https://www.ismtech.net/submit-your-resume แล้วคุณจะพบว่าอนาคตและโอกาสก้าวหน้ากำลังรอคุณอยู่