उन नए सॉफ़्टवेयर डेवलपर्स के लिए सलाह जिन्होंने वे सभी दूसरी सलाह-निबंध पढ़ लिए हैं

सलाह और “विशेषज्ञों” पर भरोसा

• कई टिप्पणियाँ निबंध के इस बिंदु को दोहराती हैं: लोग इसलिए फॉलो किए जाते हैं क्योंकि वे अच्छी तरह लिखते या बोलते हैं, न कि इसलिए कि वे सही होते हैं।
• यह ब्लॉग पोस्ट, किताबों, YouTube, और यहाँ तक कि LLM आउटपुट पर भी लागू होता है; आत्मविश्वास से पेश करना ≠ सही होना।
• कई लोग संदेहवाद की सलाह देते हैं, लेकिन निंदकता के बिना: किसी भी best practice के पीछे के तर्क और “horror story” को समझें (Chesterton’s Fence analogy)।

सॉफ़्टवेयर, व्यावसायिक मूल्य, और बिक्री

• एक बार-बार होने वाली बहस: “software never makes money, only sales does.”
  • समर्थकों का कहना है कि software एक cost center है और लाभ transactions और customer acquisition से आता है।
  • आलोचक जवाब देते हैं कि software मूल्य बनाता है जिसे बेचा या किराए पर दिया जाता है; कई फर्मों में, software स्पष्ट रूप से revenue चलाता है और developer compensation इसे प्रतिबिंबित करता है।
• सहमति की बारीकी: business context मायने रखता है; tech का अस्तित्व business की सेवा के लिए है, लेकिन engineering को कम आँकना खराब परिणामों और अंततः attrition की ओर ले जाता है।

सॉफ़्टवेयर का उद्देश्य

• एक मजबूत दावा सामने आता है: “the only purpose of software is automation.”
  • समर्थक इसे video games तक बढ़ाते हैं, जिन्हें वे rule enforcement के automated रूप के रूप में देखते हैं।
  • विरोधी games, art, और non-automation उपयोगों को वैध उद्देश्य मानते हैं; वे इसे dogmatic overreach मानते हैं।

डेवलपर का काम

• एक लोकप्रिय थीम: आपका असली काम business/user समस्याएँ हल करना है, न कि “writing code” या “writing Slack messages.”
• कुछ लोग तर्क देते हैं कि यह rhetorical exaggeration है; अक्सर आपका काम code लिखना ही होता है, लेकिन ध्यान सही problem हल करने पर होना चाहिए, कभी-कभी और code न जोड़कर।

Docs, Specs, और Source Code

• एक पक्ष documentation को “cover to cover” पढ़ने और key tools के source का अध्ययन करने की वकालत करता है; उनका दावा है कि इससे long-term speed और “map awareness” मिलती है।
• बड़ा विरोध:
  • आधुनिक specs/libs हज़ारों पृष्ठों की हैं; उन्हें पूरी तरह पढ़ना या याद रखना असंभव है।
  • लोगों की learning styles अलग होती हैं; कई लोग iterative, problem-driven reading या tables of contents को skim करना पसंद करते हैं।
  • सुझाया गया समझौता: छोटे core toolset को गहराई से सीखें, व्यापक रूप से skim करें, और बाद में “where to look” जानें।

सादगी बनाम जटिलता और “सही तरीका”

• “don’t make things more complicated than necessary” (KISS) के लिए मज़बूत समर्थन है।
  • over-abstraction, premature generalization, और छोटे projects के लिए जटिल frameworks की आलोचनाएँ।
  • “Right Way Guys” की कहानियाँ जो तुच्छ code के लिए factories/builders/ORMs/staging थोपते हैं, या job security के लिए विशाल in-house frameworks बनाते हैं।
• प्रतिवाद: छोटे side projects “proper” infra और tooling का अभ्यास करने के लिए सुरक्षित जगह हो सकते हैं; जो overkill जैसा लगता है वह जानबूझकर किया गया learning हो सकता है।

Code Quality, Maintainability, और उत्कृष्टता

• कई लोग “clever” या “excellent” code की बजाय “clear, working code that’s easy to debug” पसंद करते हैं।
• “excellence” पर मतभेद:
  • कुछ कहते हैं कि यह वास्तविक है लेकिन खतरनाक (hubris, over-engineering)।
  • अन्य तर्क देते हैं कि excellence को खारिज करना mediocrity को अपनाना है; कुंजी ego नहीं, बल्कि working, maintainable solutions को लक्ष्य बनाना है।

Debugging, Code पढ़ना, और Tools

• कई टिप्पणियाँ एक खास debugging book की प्रशंसा करती हैं और debugging को एक core professional skill के रूप में रेखांकित करती हैं।
• सलाह: code को अच्छी तरह पढ़ना सीखें (उसे step through करने सहित), सिर्फ लिखना नहीं।
  • एक दृष्टिकोण: debuggers एक शक्तिशाली learning tool हैं, textbook के exercises की तरह।
  • दूसरा दृष्टिकोण: debuggers पर अत्यधिक निर्भरता एक crutch है; senior engineers को code को हमेशा execute किए बिना तर्क से समझना चाहिए।

सहयोग, Reviews, और विनम्रता

• Code reviews को high-leverage माना जाता है: वे code सुधारते हैं, reading skills सिखाते हैं, और design issues सामने लाते हैं।
• juniors के लिए सलाह:
  • ego छोड़ें, सीधे criticism को स्वीकार करें, प्रश्न पूछें, और गलतियाँ जल्दी स्वीकार करें।
  • समझें कि “best practices” और architectural decisions contextual होते हैं; seniors गैर-स्पष्ट कारणों से सही हो सकते हैं।

स्वास्थ्य, सैर, और संज्ञानात्मक बोझ

• “take walks” वाली सलाह को बहुत समर्थन मिलता है।
  • लोग report करते हैं कि walks या बस तालाब को घूरना भी मानसिक debugging और stress से निपटने के लिए शक्तिशाली हो सकता है।
• व्यापक बिंदु: अपने सिर में “state” को संभालें; notes/wikis के जरिए externalize करें और अपनी ऊर्जा की रक्षा करें (अनावश्यक complexity से बचकर)।