อย่าเชื่อถือชุมชนเทคโนโลยี

อย่าเชื่อถือชุมชนเทคโนโลยี

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

ชุมชนเทคโนโลยีเชี่ยวชาญศิลปะในการให้คำแนะนำแย่ๆ

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

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

บางครั้งมันทำให้ฉันรู้สึกงี่เง่าเพราะฉันไม่ได้ใช้มัน

นักพัฒนารุ่นเยาว์ทำอะไร?

เมื่อ Junior Developer พบกับความเห็นพ้องต้องกันของชุมชน พวกเขามักจะทำอะไรมากที่สุด พวกเขาจะยอมรับสิ่งที่ชุมชนได้ "บรรลุฉันทามติ" ไว้ บ่อยครั้งโดยไม่คำนึงถึงความเหมาะสมกับบริบทหรือไม่

พวกเขาจะเริ่มเพิ่มเทคโนโลยีใหม่ให้กับโครงการของบริษัทหรือใช้เทคนิคใหม่ในโค้ดเบส

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

มีปัญหาอะไร?

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

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

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

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

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

มันเป็นความคิดที่น่ากลัว

ฉันทำผิดพลาดเหล่านี้ด้วย

ฉันถูกกัดด้วยพฤติกรรมที่ฉันเขียนถึงที่นี่ ฉันเคยเป็นนักพัฒนา คนนั้น ที่คอยรับฟังชุมชนอย่างสุ่มสี่สุ่มห้า

ย้อนกลับไปในสมัยของ Google Web Toolkit รูปแบบที่เรียกว่า Model-View-Presenter เป็นสิ่งที่ได้รับความนิยมอย่างมาก มันเรียกร้องให้มีนามธรรมมาต่อนามธรรมเพื่อแยกข้อมูล มุมมอง และการเชื่อมโยงระหว่างกัน

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

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

ฉันเคยเป็นนักพัฒนา t ที่คอยรับฟังชุมชนอย่างสุ่มสี่สุ่มห้า

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

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

มันสอนฉันถึงสิ่งที่อาจเป็นบทเรียนที่มีค่าที่สุดในอาชีพของฉัน: บริบทเป็นสิ่งสำคัญ

บริบทเป็นสิ่งสำคัญ

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

ดูว่าเกิดอะไรขึ้นเมื่อ NoSQL hype train มาถึง บทความประกาศอย่างมั่นใจว่าการจัดเก็บเอกสารจะเป็นคลื่นแห่งอนาคตและข้อมูลที่มีโครงสร้างนั้นก็ตายไปแล้ว เทคโนโลยีอย่าง MongoDB ทำให้ติดตั้งง่าย รันง่าย และสร้างต่อได้ง่าย การเขียนโค้ด bootcamps ทั่วโลกสอนสิ่งนี้ให้กับนักพัฒนาหน้าใหม่จำนวนมาก โดยไม่ต้องสอนพวกเขาว่าควรใช้เมื่อใด

ใครต้องการสคีมาอีกต่อไป เท่าที่ชุมชนเทคโนโลยีกังวล ไม่มีใครเลย

ปรากฎว่าคนที่ต้องการสคีมาจำเป็นต้องมีสคีมา และนั่นก็กลายเป็นซอฟต์แวร์ส่วนใหญ่ที่ทำอะไรที่น่าสนใจแม้จะอยู่ห่างไกลก็ตาม

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

เมื่อถึงตอนนั้น ชุมชนได้ย้ายไปยังผู้สร้างเรซูเม่ตัวใหม่ที่เป็นประกาย

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

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

คนตาบอดนำทางคนตาบอด

หาก “ชุมชนเทคโนโลยี” มีนักพัฒนารุ่นเยาว์จำนวนมากบริโภคและสร้างสรรค์เนื้อหา นั่นหมายถึงสองสิ่ง:

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

การพูดคุยกับชื่อเรื่องเช่น "Monoliths are bad" หรือบทความที่เรียก GraphQL ว่า "REST killer" ปรากฏขึ้นพร้อมสัญญาว่าจะมีกระสุนเงินตัวใหม่ การเสวนาเหล่านี้จะมีนักพัฒนารุ่นเยาว์คนอื่นๆ จำนวนมากเข้าร่วม ซึ่งใช้ข้อมูลอย่างมีความสุขและกระตือรือร้นและลงมือทำด้วยตนเอง

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

ฉันไม่ได้พยายามเรียนรู้และต้องการปรับปรุง สิ่งเหล่านี้คือสิ่งที่ฉันและคนอื่นๆ มองหาจากนักพัฒนา นักพัฒนาที่ไม่เรียนรู้กำลังซบเซา โดยเฉพาะในอุตสาหกรรมที่เปลี่ยนแปลงอยู่ตลอดเวลา

อย่างไรก็ตาม นักพัฒนาจำนวนมากที่อ่านหรือใช้เนื้อหาเหล่านี้ไม่ได้มองข้ามคำแนะนำไปในตัว หากพวกเขาทำ พวกเขาจะตระหนักว่าคำแนะนำมากมายมาจากคนที่ไม่ได้สร้างอะไรมากนัก หากมีสิ่งใดเลย

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

คำแนะนำมากมายมาจากคนที่ไม่ค่อยได้ก่อสร้างมากนัก หากมีสิ่งใดเลย

นักพัฒนาส่วนใหญ่ไม่ใช่ผู้เชี่ยวชาญ

ความจริงที่น่าอึดอัดก็คือนักพัฒนาส่วนใหญ่นั้นปานกลาง

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

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

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

นี่คือวิธีการทำงานของบริษัท: มีเพียงไม่กี่ทีมที่มีทีมงานที่ประกอบด้วยผู้เชี่ยวชาญเท่านั้น

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

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

มีวิศวกรซอฟต์แวร์เพียงไม่กี่เปอร์เซ็นต์เท่านั้นที่เป็นผู้เชี่ยวชาญ และทำได้ดีอย่างต่อเนื่อง

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

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

ประเด็นที่เป็นระบบ

มีระบบแรงจูงใจที่แปลกประหลาดภายในชุมชนเทคโนโลยีที่ขยายผลและเข้าถึงคำแนะนำที่ไม่ดีอย่างมาก

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

โอเพ่นซอร์ส = นักพัฒนาที่มีทักษะ?

โดยทั่วไปอุตสาหกรรมของเราถือว่าการมีส่วนร่วมของโอเพนซอร์สเป็นสิทธิในการโอ้อวด

มีระบบสิ่งจูงใจทั้งหมดที่ให้รางวัลแก่การพัฒนาบางสิ่งที่ใช้กันอย่างแพร่หลาย การสร้างห้องสมุดที่ประสบความสำเร็จและใช้กันอย่างแพร่หลายคือผู้สร้างเรซูเม่ที่สำคัญ (อย่างถูกต้อง) การมีพื้นที่เก็บข้อมูลที่มีดาว Github นับพันดวงถือเป็นเครื่องหมายแห่งความสำเร็จ ข้อมูลเหล่านี้คือข้อมูลรับรองที่ระบุว่า "จ้างฉัน" ใครบ้างจะไม่อยากจ้างผู้สร้าง Redux ซึ่งเป็นผู้ดูแล Ruby on Rails

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

ปัญหาคือมีรางวัลที่ใหญ่กว่าในการสร้างสิ่งใหม่มากกว่าการสร้างสิ่งมีคุณค่า

ผลไม้ที่แขวนน้อยที่สุดในการสร้างคือห้องสมุดที่ทำแบบเดียวกับห้องสมุดยอดนิยมอื่นๆ แต่ดีกว่าเท่านั้น ดูว่ามีหลายวิธีในการอัปโหลดภาพบน Rails — คลิปหนีบกระดาษ, Shrine, Refile, Carrierwave แล้วคุณมีหลายวิธีในการจัดการสถานะ เช่น Redux, Mobx, Recoil, Context ฯลฯ ตัวเลือกมีมากมายและเพิ่มขึ้นเรื่อยๆ

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

ภายในระบบนิเวศนี้มีนักพัฒนารุ่นเยาว์อยู่

นักพัฒนารุ่นเยาว์ต้องดำเนินการในระบบนิเวศนี้ซึ่งเราต้องประสบความสำเร็จ ดังนั้นนั่นคือสิ่งที่พวกเขาทำ

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

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

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

เพียงดูบทความเกี่ยวกับ Redux, GraphQL หรือ MongoDB เครื่องมือเหล่านี้มีประโยชน์อย่างยิ่งและเหมาะสมในบริบทที่ถูกต้อง แต่เป็นเรื่องยากที่จะเห็นคำแนะนำโดยละเอียดหรือคำแนะนำที่อธิบายบริบทเบื้องหลังการตัดสินใจได้อย่างเพียงพอ

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

ลดแถบลง

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

น่าเสียดายที่คำแนะนำส่วนใหญ่หลังจากนั้นหยุดอยู่แค่นั้น ฉันไม่ค่อยเห็นตัวอย่างที่แสดงให้คุณเห็นว่าอะไรไม่ควรทำ หรือการกระทำบางอย่างดังที่แสดงไว้จะสร้างความท้าทายในการบูรณาการในอนาคตได้อย่างไร

เป็นเรื่องที่คาดหวังได้ การบูรณาการไม่ใช่งานของห้องสมุด

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

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

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

คุณจะหลีกเลี่ยงมันได้อย่างไร?

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

รับข้อมูลความเป็นมา

วิธีแก้ปัญหาที่ถูกต้องกับปัญหาที่ผิดก็เหมือนกับการสาดน้ำใส่ไฟน้ำมัน

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

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

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

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

ปรับวิธีการแก้ปัญหา

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

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

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

หลีกเลี่ยงความไม่สอดคล้องกัน

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

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

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

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

คุณมีความรับผิดชอบ ที่จะไม่ทำสิ่งที่จะทำให้อนาคตธุรกิจของคุณเสียหาย

ถึงนักเขียน

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

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

ฉันรู้ว่าฉันลืมทำสิ่งนี้มาหลายครั้งแล้ว และใครจะรู้ว่าฉันหลงทางไปกี่ครั้งแล้ว

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