รู้สึกอย่างไร เมื่อเป็น Developer ที่แย่ที่สุดในทีม พร้อมคำแนะนำ

See the original English version of this article here

เรื่องราวในบทความนี้เป็นประสบการณ์ตรงจากคุณ Brian Jenney ในฐานะ Full-stack Developer ซึ่งเขาเคยทำงานกับบริษัทไอที Start-up แห่งหนึ่ง และในตอนนั้นเขาเป็น Developer ที่แย่ที่สุดในทีม จนถูก CTO ซึ่งเป็น Co-founder เรียกเข้าไปคุย กับบทความ รู้สึกอย่างไร เมื่อเป็น Developer ที่แย่ที่สุดในทีม พร้อมคำแนะนำ

หลังจากที่คุณ Brian Jenney เข้าร่วมทำงานกับบริษัทแรก ในฐานะ Developer ได้ 2 ปี เขาก็รู้ตัวว่า ถึงเวลาที่ต้องเปลี่ยนงานแล้ว

การตัดสินใจครั้งนี้ไม่ใช่เรื่องง่าย เพราะคุณ Brian มีความสุขกับการทำงานที่นี่มาก เพราะเขาชอบทั้งเพื่อนร่วมงาน ผู้จัดการ รวมถึงตัวบริษัทด้วย แต่คุณ Brian ตระหนักรู้ดีว่า เพื่อที่เขาจะได้เติบโตและก้าวหน้าในฐานะ Developer เขาจำเป็นต้องรู้จักกับกลุ่มเทคโนโลยีใหม่ ๆ และเรียนรู้วิธีการทำงานที่แตกต่างจากที่เขาเคยเจอ และแล้วคุณคุณ Brian ก็ได้ผ่านการสัมภาษณ์รอบแรกกับบริษัท Start-up แห่งหนึ่ง ซึ่งบริษัทแห่งใหม่นี้ใช้ EmberJS, Rails และ Postgres แต่ในเวลานั้นคุณ Brian เคยใช้เพียงแค่ C#, SQL และ AngularJS

สำหรับการเริ่มต้นใหม่ในครั้งนี้  เงินเดือนของคุณ Brian ได้เพิ่มขึ้นสองเท่าเลยทีเดียว ซึ่งการได้ปรับเงินเดือนขนาดนี้ ถือว่าไม่ใช่เรื่องง่าย คุณว่าไหมล่ะ?

ในวันแรกก็รู้สึกว่า มันเกินความสามารถ

Co-founders ของบริษัท Start-up แห่งนี้ ทั้ง 5 คนได้ลงนิตยสาร Forbes ด้วย ซึ่งพวกเขามีประสบการณ์การทำงานในบริษัทหลายแห่ง ในกลุ่ม FAANG และ Lead Developer ของบริษัทนี้ คือผู้สร้าง Library ยอดนิยม สำหรับ EmberJS แล้วมองกลับมาที่คุณ Brian ผู้ซึ่งไม่เคยมีประสบการณ์เกี่ยวกับ Ember, Ruby หรือทำงานในบริษัท Start-up เลย แต่คุณ Brian ก็คิดในใจว่า อย่างน้อยเขาก็รู้เกี่ยวกับ Javascript (หรือเขาคิดไปเอง)

ในวันแรก ไม่ได้มีการปฐมนิเทศหรือแนะนำบริษัทแต่อย่างใด ดังนั้นคุณ Brian จึงได้จับคู่ทำงานกับ Lead Developer และ CTO โดยตรง

เพื่อนร่วมทีม: คุยเรื่องตลกเกี่ยวกับ Djikstra

คุณ Brian: คือใครหรอ? (เพราะเขาไม่เคยรู้จักมาก่อน)

เพื่อนร่วมทีม: Bug ที่มี Closure Scope

คุณ Brian: คืออะไรนะ?

เพื่อนร่วมทีม: Hoisting ที่ส่งผลต่อการทดสอบ

คุณ Brian: ผมไม่เคยเขียนการทดสอบแบบนี้มาก่อน

ซึ่งที่กล่าวมาข้างต้น คุณ Brian รู้ดีว่าเพื่อนร่วมทีมอดทนกับเขามามาก จนกระทั่ง…

ในที่สุด คุณ Brian ก็ถูกเรียกตัว เพราะขาดพื้นฐานที่จำเป็นและประสิทธิภาพในการทำงาน

เรื่องที่ 1: มี Bug เกิดขึ้นจากการที่คุณ Brian เข้าใจผิดเกี่ยวกับวิธีการทำงานของ Enums ซึ่งส่งผลให้มีอีเมลนับพันถูกส่งถึงลูกค้า

เรื่องที่ 2: มี Feature ที่ต้องใช้เวลานานกว่าที่ควรจะเป็น เกือบ 1 เดือน เนื่องจากคุณ Brian ไม่ได้ขอความช่วยเหลือจากเพื่อนร่วมทีม

คุณ Brian ไม่สามารถจัดการปริมาณงานของตัวเองได้ และเป็นเรื่องยากที่เขาจะเข้าใจแนวคิดการเขียนโปรแกรมบางอย่าง เช่น Closure, Classes และ Testing ซึ่งทำให้การทำงานร่วมกันกับ Developers รายอื่นหรือ การจับคู่ทำงาน เป็นเรื่องที่น่าเบื่อ

คุณ Brian ได้มีโอกาสพูดคุยกับ CTO/Co-founder และเขาได้แนะนำคุณ Brian ในเรื่องที่ต้องปรับปรุงและพัฒนา ดังนี้

• เรียนรู้พื้นฐานของ JS (Closures, Promises, ES6 Classes)
• พูดคุยและขอความช่วยเหลือ เมื่อจำเป็น
• หยุดลงมือแก้ไขสิ่งที่เกิดขึ้นอย่างรวดเร็ว และให้ตรวจสอบสาเหตุของปัญหาก่อน

สิ่งเหล่านี้ดูเหมือนจะเป็นสิ่งที่สามารถทำได้จริง และคำแนะนำเหล่านี้ ทำให้คุณ Brian เข้าใจมากขึ้น

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

นี่คือสิ่งที่ คุณ Brian ไม่ได้ทำ:

1. ซื้อหลักสูตร Udemy มากมาย (ซึ่ง คุณ Brian ซื้อ 1 หลักสูตรเกี่ยวกับ EmberJS)
2. อ่านบทความมากมาย และเข้าใจผิดว่าสิ่งที่ทำอยู่ จะทำให้ก้าวหน้าในหน้าที่การทำงาน
3. ตกหลุมพราง ของ YouTube (หมายความว่า การเริ่มต้นด้วยวิดีโอหนึ่ง แล้วคลิกวิดีโอแนะนำ ซึ่งนำไปสู่เนื้อหาต่อเนื่องที่อาจไม่เกี่ยวข้องโดยตรงกับการค้นหาหรือความสนใจตั้งแต่เริ่มแรก)
4. เลิกโกรธและโมโห

สิ่งที่ได้ผลดีมาก สำหรับ คุณ Brian ในการปรับปรุงทักษะการสื่อสารและการเขียน Code

1. ขอให้ Lead Developers แนะนำหนังสือ (เพิ่มเติมด้านล่าง)
2. อ่านเกี่ยวกับ Classes, Closure และ Promises จากนั้นลองเขียน Code ตัวอย่างดู เพื่อทำความเข้าใจแนวคิดอย่างแท้จริง
3. ตั้งเป้าหมายที่จะถามอย่างน้อย 1 คำถาม ในทุกการประชุม และรายงานสถานะและความคืบหน้าให้กับทีมฟังอย่างโปร่งใส
4. อาสาตรวจสอบ Issue สำคัญต่าง ๆ เพื่อเรียนรู้ว่าอะไรคือสาเหตุ

และในบริษัท Start-up แห่งนี้ คุณ Brian ไม่เคยเป็น Developer ที่แย่ที่สุดอันดับ 2 ในทีมเลย

ในที่สุดคุณ Brian ก็ออกจากบริษัท Start-up แห่งนี้ และไปทำงานในบริษัท Start-up ขนาดใหญ่ ซึ่งเขาได้เลื่อนตำแหน่งเป็น Senior โดยใช้บทเรียนที่คุณ Brian ได้เรียนรู้จาก CTO/Co-founder ซึ่งข้อเสนอแนะและคำแนะนำต่าง ๆ ช่วย คุณ Brian ได้มาก ถึงแม้ว่าตอนนั้นเขาจะรู้สึกแย่มากก็ตาม

หากการอ่านคือสิ่งที่คุณชอบ… นี่คือรายชื่อหนังสือที่ช่วยให้ คุณ Brian เป็น Developer และ Engineering Manager ที่ดีขึ้น:

1. Clean Code in Javascript
2. The Phoenix Project
3. Functional-Light JS
4. The Manager’s Path
5. System Design Interview by Alex Xu

หากคุณรู้สึกเหมือนเป็น Developer ที่แย่ที่สุดในทีม (และมันทำให้คุณรู้สึกแย่มาก) ลองคิดว่าสิ่งเหล่านี้เป็นโอกาสในการเรียนรู้และพัฒนาตนเองได้

และคุณ Brian ได้กล่าวทิ้งท้ายคำแนะนำที่ซ้ำซากจำเจ (แต่มันอาจจะไม่ช่วยอะไร) ไว้ว่า

“การลงมือทำช่วยคลายความวิตกกังวลได้”

ดังนั้น ลองหาและระบุจุดอ่อนของคุณ วางแผนเพื่อเสริมความแข็งแกร่ง

และอาจอ่านหนังสือบางเล่ม (ที่แนะนำด้านบน) และเพิ่มระดับทักษะของคุณ

และทั้งหมดนี่ก็คือ รู้สึกอย่างไร เมื่อเป็น Developer ที่แย่ที่สุดในทีม พร้อมคำแนะนำ

เมื่อ หางาน IT ให้ ISM Technology Recruitment เป็นอีกหนึ่งตัวช่วย เพื่อให้คุณได้ “ชีวิตการทำงานในแบบที่คุณต้องการ” เพียงส่ง Resume มาที่นี่

ISM เชี่ยวชาญในธุรกิจ IT Recruitment & IT Outsourcing โดยเฉพาะ ได้เปิดทำการมาแล้วกว่า 30 ปี มีพนักงานทุกสายและทุกระดับทางด้าน IT ที่ได้ร่วมงานกับลูกค้าองค์กรใหญ่ที่มีชื่อเสียงและบริษัทข้ามชาติมากมาย

Source: https://brianjenney.medium.com/