सबसे खराब किस्म का प्रोग्रामर
ओवरइंजीनियर्ड आर्किटेक्चर, “रॉकस्टार” डेवलपर्स और buzzword-आधारित तकनीकी विकल्पों को नाज़ुक, कठिन-से-मेंटेन सिस्टमों के लिए दोषी ठहराया जाता है, लेकिन कई लोग तर्क देते हैं कि मूल कारण व्यक्तिगत व्यक्तित्वों या भाषाओं से अधिक कमजोर इंजीनियरिंग नेतृत्व और प्रक्रिया है। टिप्पणीकार हाई-एम्बिशन कोडर्स, जो रेज़्यूमे और हीरोइक्स के लिए ऑप्टिमाइज़ करते हैं, की तुलना “बोरिंग,” रक्षात्मक इंजीनियरों से करते हैं जो सरल, स्थिर कोड शिप करते हैं जिसे दूसरे मेंटेन कर सकें, और नोट करते हैं कि प्रबंधन अक्सर पहले वालों को पुरस्कृत करता है। बहस भाषा और टूलिंग चुनावों (Rust बनाम Go, Java में FP, भारी फ्रेमवर्क) तक फैलती है, और यह कि क्या टीमों को अभिव्यंजक, जटिल स्टैक्स को प्राथमिकता देनी चाहिए या जानबूझकर बोरिंग, व्यापक रूप से समझी जाने वाली तकनीकों को, ताकि जोखिम कम हो और सहयोग बेहतर हो।
मूल कारण: प्रबंधन, “खराब प्रोग्रामर” नहीं
- कई लोग तर्क देते हैं कि असली समस्या कमजोर या अनुपस्थित तकनीकी नेतृत्व और प्रक्रिया है।
- गैर-तकनीकी प्रबंधन अक्सर ट्रेड-ऑफ़ समझे बिना समय-सीमाएँ और तकनीकी दिशा तय करता है।
- दो “जादूगरों” को बिना किसी रिव्यू या शुरुआती डेमो के अकेले कोर आर्किटेक्चर बनाने देना प्रबंधन की विफलता माना जाता है।
- प्रोत्साहन संरचनाएँ (चमकदार फ्रेमवर्क हैक्स, “आर्किटेक्ट” बनने पर प्रमोशन) हानिकारक व्यवहार को सक्रिय रूप से बढ़ावा दे सकती हैं।
ओवरइंजीनियरिंग और तकनीकी चयन
- यह व्यापक सहमति है कि स्पष्ट आवश्यकताएँ आने से पहले जटिल, सामान्यीकृत आर्किटेक्चर बनाना जोखिमपूर्ण है।
- कई किस्से: Angular/Spring CRUD ऐप्स को बेहद ज़्यादा ओवर-इंजीनियर किया गया; RabbitMQ के ऊपर कस्टम प्रोटोकॉल; “Java को Haskell की तरह लिखना” जिससे प्रदर्शन और स्थिरता की समस्याएँ हुईं।
- कुछ लोग TDD / क्रमिक प्रोटोटाइपिंग और ऊपर से “आर्किटेक्चर एस्ट्रोनॉटिंग” करने के बजाय काम कर रहे कोड से आर्किटेक्चर निकालने पर ज़ोर देते हैं।
रॉकस्टार / 10x मानसिकता और प्रोत्साहन
- “हाई परफ़ॉर्मर्स” जो बहुत सारा जटिल कोड शिप करते हैं, ज्ञान जमा कर लेते हैं, और फिर छोड़ जाते हैं, आम हैं।
- प्रबंधन अक्सर दिखने वाली व्यस्तता, LOC, और टिकट थ्रूपुट को पुरस्कृत करता है, न कि दीर्घकालिक मेंटेनबिलिटी को।
- कुछ लोग यह भी कहते हैं कि ये “रॉकस्टार” अक्सर सचमुच अधिक डिलीवर करते हैं, और उन्हें दोष देना कम-प्रभाव वाले साथियों और प्रबंधन की विफलताओं को छिपा सकता है।
टीम डायनैमिक्स, बस फ़ैक्टर, और बोरिंग कोड
- “बोरिंग,” रक्षात्मक, आसानी से समझ आने वाले कोड के लिए मज़बूत समर्थन है, भले उसे लिखने में ज़्यादा समय लगे।
- टीम की सफलता के लिए दस्तावेज़ीकरण, मेंटरिंग, कोड रिव्यू, और साझा स्वामित्व ज़रूरी है; अकेले हीरोइक प्रयास बस फ़ैक्टर को कम करते हैं।
- कई लोग नोट करते हैं कि असली टीम विकास धीमा और अधिक संवादात्मक होता है, लेकिन वह मेंटेन करने योग्य सिस्टम देता है।
भाषा और स्टैक की बहसें (Go, Rust, FP, आदि)
- कुछ लोग मानते हैं कि कुछ भाषाएँ (Rust, Scala) और शक्तिशाली फीचर सेट “सिर्फ़ चालाकी” या DSL-जैसे कोड को आकर्षित कर सकते हैं।
- अन्य लोग “Golang टीमें फलती-फूलती हैं, Rust टीमें rust करती हैं” जैसे व्यापक दावों से कड़ी असहमति जताते हैं, सफल Rust प्रोजेक्ट्स और संदिग्ध Go डिज़ाइन विकल्पों का हवाला देते हुए।
- सहमति: वास्तविक जोखिम टूल्स का गलत उपयोग, भाषाओं पर अनमेल पेराडाइम थोपना, या ऐसे स्टैक्स चुनना है जिन्हें टीम सामूहिक रूप से बनाए नहीं रख सकती।
सादगी बनाम anti-intellectualism
- बहुत से लोग CRUD/बिज़नेस ऐप्स के लिए “सिंपल भाषाएँ और बोरिंग टेक” का समर्थन करते हैं।
- अन्य लोग इस लेख और चर्चा के हिस्सों को anti-intellectualism की ओर झुकता मानते हैं, जो जुनून, उन्नत तकनीकों, या अभिव्यंजक भाषाओं को खारिज करता है।
- सुझाया गया संतुलन: सादगी और टीम की समझ को प्राथमिकता दें, लेकिन जब उन्नत टूल वास्तविक समस्याएँ स्पष्ट रूप से हल करें, तब उन्हें प्रतिबंधित न करें।