ทำไม Coding Coding จึงเป็นสุดยอดอาชีพ Hack

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

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

สำหรับฉัน ชุมชนนั้นคือ Founders and Coders ซึ่งเป็น bootcamp JavaScript ฟรีที่ช่วยให้ฉันเปลี่ยนอาชีพจากการเขียนคำโฆษณาเป็นการเขียนโค้ด แม้กระทั่งตอนนี้ หลังจากเรียนจบหลักสูตรไม่ถึงหนึ่งปี ฉันก็แทบไม่อยากจะเชื่อเลยว่าตัวเองได้รับค่าจ้างเพื่อพัฒนาซอฟต์แวร์

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

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

การจับคู่ที่สมบูรณ์แบบ

ประสบการณ์ครั้งแรกของฉันในการเขียนโปรแกรมคู่คือการพบปะสำหรับผู้เริ่มต้นที่เรียกว่า Coding For Everyone วิธีการทำงาน: ผู้คนจับคู่บ่อยครั้งกับคนที่พวกเขาไม่เคยพบ เพื่อแก้ปัญหา JavaScript ร่วมกันในแล็ปท็อปเครื่องเดียวกัน บุคคลหนึ่งสวมบทบาทเป็น 'นักเดินเรือ' และเสนอรหัสที่พวกเขาคิดว่าควรเขียน "คนขับ" อีกคนพิมพ์คำแนะนำบนแล็ปท็อปและถามคำถามเมื่อใดก็ตามที่ไม่ชัดเจน คุณยังคงทำเช่นนี้ โดยสลับบทบาทบ่อยๆ จนกว่าจะสิ้นสุดเซสชันสองชั่วโมง

ในทางทฤษฎี มันง่าย ในทางปฏิบัติไม่มาก

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

โชคดีที่เราติดอยู่กับมัน ฉันไปพบอีกครั้งในสัปดาห์ถัดไป นับตั้งแต่นั้นมา ฉันใช้เวลาหลายร้อยชั่วโมงในการจับคู่กับนักพัฒนาซอฟต์แวร์หลายสิบคน และฉันได้เรียนรู้มากกว่าที่ตอนแรกคิดว่าจะเป็นไปได้

การเขียนโปรแกรมคู่เป็นวิธีที่รวดเร็วอย่างเหลือเชื่อในการเรียนรู้ ความมหัศจรรย์ของวิธีการนี้ - เมื่อคุณเอาชนะความอึดอัดในเบื้องต้นได้แล้ว - ก็คือให้ผลลัพธ์ทันที การวนรอบความคิดเห็นบางอย่าง เช่น ภาวะฟองสบู่ในตลาดหุ้น อาจใช้เวลาหลายชั่วโมง วัน หรือแม้กระทั่งเดือนในการแก้ไข การเขียนโปรแกรมจับคู่ใช้เวลาไม่กี่นาที หากไม่ใช่วินาที เมื่อคุณใส่เครื่องหมายอัฒภาคผิด ตาสองคู่สามารถตรวจพบข้อผิดพลาดได้เร็วกว่าหนึ่งตา ต้องการค้นหา StackOverflow เพื่อหาเบาะแสเกี่ยวกับข้อความแสดงข้อผิดพลาดอันธพาลหรือไม่ คุณและคู่ของคุณสามารถอ่านหัวข้อต่างๆ ได้ โดยลดเวลาที่ใช้ในการหาคำตอบลงครึ่งหนึ่ง

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

“บรรดาผู้มีสติปัญญาเฉลียวฉลาดล้วนทำงานสิ่งเดียวกัน ในเวลาเดียวกัน ในพื้นที่เดียวกัน บนคอมพิวเตอร์เครื่องเดียวกัน”

— Woody Zuill โค้ช Agile และ Mob Programming Trainer

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

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

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

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

แหล่งข้อมูลและการอ่านเพิ่มเติม

• “บทบาทการเขียนโปรแกรมคู่” Jordan Poulton, GitHub
• “มิตรภาพที่ทำให้ Google ยิ่งใหญ่” James Somers, The New Yorker
• “การเขียนโปรแกรมกลุ่มคน: แนวทางทั้งทีม” Woody Zuill, YouTube

วิศวกรรมเอาใจใส่

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

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

การเอาใจใส่อาจเป็นเครื่องมือที่ประเมินค่าต่ำที่สุดในคลังแสงของนักพัฒนา เป็นเหตุผลที่ IDEO ให้การวิจัยผู้ใช้เป็นศูนย์กลางของกระบวนการออกแบบ และเหตุใด Etsy จึงขอให้นักออกแบบและผู้จัดการผลิตภัณฑ์ของตนทำการหมุนเวียนทางวิศวกรรม ความเห็นอกเห็นใจเกิดขึ้นเมื่อเรามีโอกาสได้เห็นว่างานของเราส่งผลกระทบต่อผู้อื่นอย่างไร ไม่น่าแปลกใจเลยที่การเขียนโค้ดร่วมกันเป็นวิธีที่ดีในการสร้าง

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

การเขียนเอกสารที่ดีสำหรับโค้ดของคุณยังมีประโยชน์อีกด้วย การดำเนินการง่ายๆ อย่างการสร้าง readme พร้อมคำแนะนำในการติดตั้งที่ชัดเจนแสดงถึงความเห็นอกเห็นใจสำหรับทุกคนที่ต้องการทำงานกับโค้ดของคุณ Tom Preston-Werner ผู้ก่อตั้ง GitHub สนับสนุนแนวทางการพัฒนาแบบ readme-first

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

— ทอม เพรสตัน-เวอร์เนอร์ ผู้ก่อตั้ง GitHub

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

แหล่งข้อมูลและการอ่านเพิ่มเติม

• “ตามคำขอเอาใจใส่และดึง” Slack Engineering, Medium
• “การพัฒนาที่ขับเคลื่อนด้วย Readme” Tom Preston-Werner, GitHub
• “สิ่งที่ Google เรียนรู้จากการแสวงหาเพื่อสร้างทีมที่สมบูรณ์แบบ” Charles Duhigg, The New York Times Magazine

ความสำเร็จเปรียว

ตั้งแต่ชั่วโมงทำงานหลายล้านชั่วโมงในการผลิตภาพยนตร์ CGI ไปจนถึงการพัฒนาอย่างเข้มข้นที่นำไปสู่การเปิดตัววิดีโอเกมที่มีงบประมาณสูง ความสำเร็จด้านเทคนิคที่สูงตระหง่านต้องใช้ความพยายามอย่างมาก ครั้งแรกที่ฉันเห็น codebase ของนายจ้างคนปัจจุบัน ฉันรู้สึกทึ่งกับความใหญ่โตของมันทั้งหมด ไม่มีใคร สร้าง สิ่งนี้ขึ้นมาได้อย่างไร?

คำตอบคือ ทุกคน สามารถสร้างได้มากกว่า ใครๆ ด้วยกรอบการทำงานร่วมกันที่เหมาะสม ในบริษัทที่สนับสนุนการเขียนโค้ดร่วมกัน ซอฟต์แวร์ไม่ได้เกิดขึ้นจากความพยายามของอัจฉริยะเพียงคนเดียว มีวิธีการทำงานร่วมกันที่ช่วยให้ทีมที่ยอดเยี่ยมทำงานได้อย่างยอดเยี่ยม นักพัฒนาที่ Founders และ Coders ฝึกฝนวิธีการพัฒนาซอฟต์แวร์ยอดนิยมที่เรียกว่า 'Agile' และจากประสบการณ์ของผม มันทำให้ 'การทำงาน' อยู่ในทีมพัฒนาข้ามสายงาน

หนังสือทั้งเล่มเขียนเกี่ยวกับ Agile แต่นี่คือบทสรุปของแนวคิดหลัก:

• ทีมพัฒนาผลิตภัณฑ์จะแบ่งงานชิ้นใหญ่ออกเป็นหน่วยย่อยๆ ที่เรียกว่า 'user Stories' จัดลำดับความสำคัญของงาน และส่งมอบภายใน 2 สัปดาห์ที่เรียกว่า 'sprints'
• ตราบใดที่โปรเจ็กต์ดำเนินต่อไป วัฏจักรจะเกิดขึ้นซ้ำแล้วซ้ำอีก และความต้องการผลิตภัณฑ์ใหม่ก็จะถูกป้อนเข้าสู่งานในมือสำหรับการวิ่งในอนาคต
• ทีมงานจัดการประชุมแบบสแตนด์อัพทุกวันเพื่อหารือเกี่ยวกับความคืบหน้าและจัดการกับตัวบล็อก
• กระบวนการนี้มีทั้งแบบเพิ่มขึ้นและแบบวนซ้ำ: ซอฟต์แวร์ถูกสร้างขึ้นและส่งมอบเป็นชิ้น ๆ และปรับแต่งในการวิ่งต่อเนื่อง

ในฐานะคนจรจัดเรื้อรังที่มีโปรเจกต์ทำงานอดิเรกเดี่ยวมักจะยอมจำนนต่อ 'ฟีเจอร์คืบคลาน' ฉันรู้ดีว่ามันง่ายแค่ไหนที่จะเสียเวลาไปกับการสร้างสิ่งที่ไม่มีใครเคยใช้ ฉันชอบวิธีที่ Agile บังคับให้คุณจัดลำดับความสำคัญเรื่องราวของผู้ใช้ เพื่อให้ทั้งทีมสามารถมุ่งเน้นไปที่การนำเสนอคุณลักษณะที่ผู้ใช้ของคุณสนใจจริงๆ เป็นแรงจูงใจที่จะรู้ว่าคุณทุกคนมีเป้าหมายร่วมกันในการสร้างผลิตภัณฑ์หรือบริการที่จะมีชีวิตต่อไปหลังจากที่คุณเสร็จสิ้นการทำงานแล้ว

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

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

การนำหลักการ Agile ทั้งหมดเหล่านี้ไปปฏิบัติอาจเป็นเรื่องที่ท้าทาย โดยเฉพาะอย่างยิ่งเมื่อไม่มีใครในทีมคุ้นเคยกับวิธีการทำงานนี้ ที่ Founders and Coders นักเรียนส่วนใหญ่ต้องใช้เวลาพอสมควรในการสร้างนิสัยในการทำสแตนด์อัพประจำวัน อย่างไรก็ตาม หลังจากฝึกฝนตามโครงการเป็นเวลา 18 สัปดาห์ คุณพบว่ากระบวนการและทักษะการสื่อสารของคุณพัฒนาขึ้นอย่างมาก เมื่อคุณเริ่มงานกับลูกค้ารายแรก คุณได้สร้างแบบจำลองทางความคิดที่ชัดเจนขึ้นเกี่ยวกับวิธีการสร้างเว็บแอปแบบฟูลสแตกในทีม

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

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

แหล่งข้อมูลและการอ่านเพิ่มเติม

• “ Agile คืออะไร” สตีฟ เดนนิ่ง จาก Forbes
• “โอบรับ Agile” Darrell K. Rigby, Jeff Sutherland, Hirotaka Takeuchi, Harvard Business Review
• “โอกาสในการขอดึงครั้งแรกที่ยอดเยี่ยม” Shmavon Gazanchyan, Deloitte Digital

คำแนะนำเครื่องมือเข้ารหัสการทำงานร่วมกันระยะไกล

ในช่วงหลายปีที่ผ่านมา เครื่องมือทำงานทางไกลได้ก้าวมาถึงจุดที่บริษัทสำคัญๆ อย่าง Gatsby และ Zapier กลายเป็น “ระยะไกลมาก่อน” แม้ว่าจะยังคงเป็นที่ทราบกันดีว่าสิ่งนี้จะกลายเป็นเทรนด์หรือไม่ แต่ก็ปลอดภัยที่จะบอกว่าทีมพัฒนาจากระยะไกลอยู่ที่นี่เพื่ออยู่ต่อ

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

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