एक महान प्रोग्रामर के तीन गुण
Larry Wall के प्रसिद्ध programmer “three virtues”—laziness, impatience, और hubris—को फिर से देखा गया है, क्योंकि developers बहस करते हैं कि क्या आज भी दोषों को गुणों के रूप में पेश करना सार्थक है। टिप्पणीकार “hubris” के अर्थ पर बहस करते हैं, curiosity, fear, और pride जैसे विकल्प सुझाते हैं, और यह देखते हैं कि ये गुण सही संतुलन में automation, performance, और code quality को कैसे प्रेरित कर सकते हैं। अन्य लोग burnout, communication skills, बदलते tooling (Perl, Python, Ruby), और fun के लिए hacking तथा professional environments में maintainable systems बनाने के बीच के अंतर पर विचार करते हैं.
तीनों गुणों का पुनर्परिभाषण
- कई लोग “आलस्य” को नीरस काम को स्वचालित करने, न्यूनतम व्यवहार्य समाधान देने, और अति-जटिलता से बचने की प्रेरणा के रूप में देखते हैं; कुछ के लिए, यह उनका सबसे अच्छा पेशेवर गुण बन गया है।
- “अधीरता” को तेज़ build/test चक्रों और अधिक performant systems की चाह से जोड़ा जाता है, लेकिन कुछ लोग इसे आलस्य के साथ ओवरलैप करने वाला मानते हैं, अलग नहीं।
- “अहंकार” सबसे अधिक विवादित है: व्याख्याएँ अपने काम पर गर्व करने, ऐसा कोड लिखने की चाह जिसे दूसरे आलोचना न करें, या यह मानने तक फैली हैं कि कोई मानक “don’t roll your own” नियमों से आगे जा सकता है; दूसरी ओर, कुछ इसे वैध आलोचना को ठुकराने वाले विनाशकारी घमंड के रूप में देखते हैं।
वैकल्पिक या पूरक गुण
- सुझावों में शामिल हैं: जिज्ञासा (सीखने और सुधार की प्रेरक शक्ति के रूप में), complexity का भय (अहंकार को रोकने के लिए), हिचकिचाहट (सावधानीपूर्वक शुरुआती design), stupidity/भूलने की आदत (tests, types, और documentation को प्रेरित करने वाली), discernment, wisdom, humility, और communication skills.
- कुछ लोग तर्क देते हैं कि मूल ढाँचा “दोषों को गुणों में बदलना” rhetoric के लिहाज़ से महत्वपूर्ण है; अन्य लोग अधिक पारंपरिक सकारात्मक शब्दों को पसंद करते हैं।
Design, Rewrites, और YAGNI
- एक दृष्टिकोण: planning और discussion में अधिक समय लगाने से अधूरे initial designs के कारण होने वाले महँगे rewrites से बचा जा सकता है।
- प्रत्युत्तर: hindsight और survivorship bias; आप शुरुआत में सब कुछ बिल्कुल सही नहीं कर सकते, इसलिए सरल designs, reversible decisions, और refactoring को “comprehensive” upfront architecture से बेहतर मानना चाहिए।
- YAGNI पर ज़ोर दिया गया है: अनुमानित future requirements के लिए निर्माण न करें, लेकिन “naively simple” designs से सावधान रहें जो growth को रोक दें।
काम करने की आदतें, Burnout, और प्रेरणा
- overwork को एक वास्तविक कमजोरी के रूप में प्रस्तुत किया गया है, जो burnout और health issues में योगदान देती है; कुछ लोग “working hard” और “बहुत समय खर्च करना” में अंतर करते हैं और work meaning तथा personal traits को कारक मानते हैं।
- कई टिप्पणियाँ बताती हैं कि coding से प्रेम करने वाले कुछ लोग घंटों के बाद भी programming करते रहते हैं; अन्य लोग unpaid corporate overtime का विरोध करते हैं।
Perl, इतिहास, और अन्य भाषाएँ
- चर्चा याद दिलाती है कि ये virtues Perl की culture में कैसे फिट बैठती थीं: शक्तिशाली, संक्षिप्त, automation के लिए अच्छी, और अक्सर गैर-“official” programmers द्वारा उपयोग की जाने वाली।
- Perl की आलोचना “write-only” और अनुशासनहीन होने के रूप में की जाती है; कुछ लोग व्यवहार में इसके स्थान पर awk/sed, Tcl, Ruby, और Python जैसे tools द्वारा प्रतिस्थापन का वर्णन करते हैं।
- Python की सर्वव्यापकता और scripting सुविधा के लिए प्रशंसा की जाती है, लेकिन साथ ही यह भी आलोचना होती है कि यह बड़ी मात्रा में निम्न-गुणवत्ता वाले code को सक्षम बनाता है।
संचार और Meta-Discussion
- programming को मूलतः स्पष्ट लिखित संचार के रूप में प्रस्तुत किया गया है; language (किसी भी tongue) में mastery को अच्छे programming से मज़बूती से जुड़ा माना गया है।
- strengths/weaknesses वाले classic interview questions का मज़ाक उड़ाया गया है; गुणों को दोष की तरह पेश करने वाले चतुर जवाबों को कुछ लोग red flags मानते हैं।
- online advice देना जोखिम भरा माना गया है क्योंकि इससे आलोचना आकर्षित होती है, हालांकि इससे बेहतर approaches भी सामने आ सकती हैं।