एक प्रोग्रामर को क्या टोपी नहीं पहननी चाहिए? [बन्द है]

Question

मेरे अनुभव में, सॉफ्टवेयर डेवलपर्स कई टोपी पहनते हैं और विभिन्न जिम्मेदारियों के साथ कई भूमिकाएं भरते हैं। न केवल कोडिंग से, बल्कि कभी-कभी एसक्यूएल भी लिखना, यूजर-इंटरफेस डिजाइन करना, डेटाबेस डिजाइन करना, ग्राफिक्स हेरफेर, यहां तक ​​कि क्यूए परीक्षण भी।

यदि प्राथमिक भूमिका सॉफ़्टवेयर / कोड लिखना है, तो डेवलपर को क्या भूमिकाएँ नहीं लेनी चाहिए? क्या वहां पर कोई?

इस प्रश्न का आशय इसलिए नहीं है क्योंकि एक डेवलपर किसी अन्य भूमिका को भरने में असमर्थ है - लेकिन अतिरिक्त भूमिका होने के कारण वास्तव में प्राथमिक भूमिका के विरुद्ध काम करता है , या वास्तव में किसी ऐसे व्यक्ति की समर्पित भूमिका होनी चाहिए जो मुख्य रूप से कार्यक्रम नहीं करता है।

Comments

एक बोनट ... ओह रुको ..

— ChaosPandion

आईएमओ के एक प्रोग्रामर को उन बड़े मैक्सिकन सोमब्रेरोज़ में से एक नहीं पहनना चाहिए, क्योंकि ब्रिम मॉनिटर के खिलाफ धमाका करता रहेगा।

— मैसन व्हीलर

@Peter टर्नर: 'awesomest प्रोग्रामर हैट' उन नोवेल्टी जॉब्स में से एक होगा जो दो बीयर कैन की गणना करता है। ही, नो बीयर। लाल सांड।

— ब्लेयरहिपो

अरे नहीं। ऐसा होनहार शीर्षक ...

— कोई भी

@ मॉसन, सोमबरो को मॉनिटर पर रखते हुए चमकदार स्क्रीन में प्रतिबिंबों के खिलाफ ढाल देगा। दूसरे शब्दों में - तकनीक।

Answer 1

Sysadmin। सॉफ्टवेयर विकसित करना और आईटी बुनियादी ढांचे को संभालना दो अलग-अलग कौशल हैं जो बाहरी व्यक्ति के समान हैं। (यह सब सिर्फ कंप्यूटर पर धमाका है, ठीक है?) एक छोटी सी कंपनी के लिए, प्रलोभन कार्यालय में सभी मशीनों के लिए कंप्यूटर गाय को जिम्मेदार बनाने के लिए बहुत मजबूत होगा।

यदि आप वास्तव में दोनों टोपी, भयानक पहनने के लिए कौशल है; लेकिन यह उन चीजों में से एक है जो लोगों को एहसास होने की तुलना में बहुत अधिक समय सिंक हो सकता है, और यदि आप स्वयं के रूप में शिक्षण कर रहे हैं, तो संभावना है कि आप इसे बहुत अच्छा नहीं कर रहे हैं।

Comments

यह। गंभीरता से, सिर्फ इसलिए कि मैं कंप्यूटर पर काम करता हूं इसका मतलब यह नहीं है कि मैं बुनियादी ढांचे को ठीक कर सकता हूं। आप सिर्फ अपने डेवलपर्स का समय बर्बाद कर रहे हैं।

— जैको प्रीटोरियस 20

+1 नुकसान जो एक शौकिया सिसाडमिन द्वारा किया जा सकता है वह बहुत बड़ा है।

— davidtbernal

और अगर आपको सिसडमिन टोपी मिलती है, तो वे आपको सुविधाओं के प्रबंधक टोपी के साथ चिपका सकते हैं, जिसे हर कीमत पर टाला जाना है।

— HLGEM

OTOH, मैं एक कंपनी में एक अविश्वसनीय रूप से अक्षम और सुस्त आईटी विभाग के साथ काम करता हूं। मैं अपना फायरवॉल परिवर्तन करने में सक्षम होने के लिए क्या नहीं दे पाऊंगा ...

— गाबय मुथरत

किसी ने बताया कि मेरे बॉस ने कपड़े नहीं पहने थे, लेकिन उन्हें बताया कि वह कंप्यूटर सेट करने वाले फर्श से गंदा हो जाएगा। उन्होंने मुझे संकेत दिया कि मैं यह कर रहा हूं। मैं लगभग उनके डेस्क पर कूद गया और उनका गला घोंट दिया, लेकिन मैंने अपनी कॉफी छीनी और उल्लेख किया कि मैं हार्डवेयर नहीं करता।

— जेफ

Answer 2

आप अपने नियोक्ता से जो भी टोपी पहनते हैं, पहनें। यही आपको टीम का खिलाड़ी बनाता है। यही आपको समस्या का हल बनाता है ।

लोगों को एक "डेवलपर" या एक "वास्तुकार" या एक "विश्लेषक" होने के विचार में भी रास्ता मिल जाता है। कि पेंच। आपको प्रॉब्लम सॉल्वर होना चाहिए। कोड आपके बेल्ट में सिर्फ एक उपकरण है।

समस्या हल करना कभी भी शैली से बाहर नहीं जाता है।

अगर मेरा नियोक्ता चाहता है कि मैं तकनीकी सहायता करूं या कंप्यूटर का निर्माण करूं, तो ऐसा ही हो। यह लगता है कि वे अपने पैसे बर्बाद कर रहे हैं, एक डेवलपर वेतन पर विचार कर रहे हैं, लेकिन यह उनका व्यवसाय है। मैं यहां समस्याओं के समाधान के लिए हूं। हालांकि मैं ऐसा कर सकता हूं, मैं करूंगा। और अगर मुझे लगता है, एक निश्चित समय के बाद, मेरी प्रतिभा बर्बाद हो गई है या मेरी नौकरी की संतुष्टि नहीं है, जहां मैं चाहता हूं कि यह हो, तो मुझे बस एक और काम करने का अधिकार है।

लेकिन मूल प्रश्न के लिए - ऐसी कोई टोपी नहीं है जिसे आप नहीं पहनते हैं। हेक, अगर वे चाहते हैं कि आप कॉफी प्राप्त करें, तो करें। उनकी समस्याओं का समाधान; बस यह जान लें कि यदि आप बदलाव चाहते हैं तो आपको दूसरी नौकरी खोजने का अधिकार है।

Comments

@ जोश: मुझे लगता है कि उन में से एक होगा "नई नौकरी खोजें" स्थितियां।

— एडम लेअर

बस इससे सावधान रहें। बॉस कुछ भी करने के इच्छुक लोगों का फायदा उठाते हैं। बस सुनिश्चित करें कि आपको सही ढंग से मुआवजा दिया जा रहा है।

— टोनी

मुझे नहीं लगता कि क्रिस काफी कुछ कह रहा है "कुछ भी करो" (ठीक है, वह अंत में थोड़ा सा है; मैं किसी के लिए कॉफी नहीं लाऊंगा जो मुझे शराब भी नहीं पिलाता), लेकिन यह कहना कि "मैं एक डेवलपर हूं, मैं अभ्यस्त एक प्रिंटर कारतूस बदल "बस snooty किया जा रहा है।

— पीटर बॉटन

मैं असहमत हूं। यह कहना आसान है कि एक डेवलपर को कुछ भी पूछने में सक्षम होना चाहिए, लेकिन इसका मतलब यह नहीं है कि वह / वह चाहिए। इन स्थितियों में कुछ विवादास्पद रुचिकर समस्याएं हैं। मैं उत्पादन प्रणालियों तक पहुंच नहीं चाहता क्योंकि मुझे दोष दिया जाएगा जब वे नीचे जाते हैं ("ओह, अच्छा XXX पिछले महीने में था, इसलिए मुझे यकीन है कि उसने कुछ गड़बड़ कर दी है क्योंकि वह एक देव है, एक व्यवस्थापक नहीं है")

— एमबीोनिग सेप

-1; यहाँ सत्य की एक कर्नेल है, लेकिन इस मानसिकता के लिए कुछ स्टार्क सीमाएँ हैं जो इस उत्तर को स्वीकार करने के लिए पर्याप्त नहीं है। जब सही अंतर्निहित समस्या यह है कि आपका नियोक्ता कार्मिक प्रबंधन में क्या बेकार है? मैंने एक बार एक कार्यालय को ढहते हुए देखा क्योंकि उच्च-अप ने शूद्रों के बुद्धिमान, योग्य इंजीनियरों को उन भूमिकाओं में जोर दिया, जिनसे वे घृणा करते थे और बहुत खराब प्रदर्शन करते थे। "नहीं!" सबसे अच्छी बात है कि आप अपने और अपने नियोक्ता दोनों के लिए कर सकते हैं।

— ब्लेयरहिपो

Answer 3

परीक्षक!

जरूरत पड़ने पर टेस्टर स्कूल से सीधे हमें परीक्षक भेजें!

परीक्षकों के बिना लोगों को बल्ले से काम करने की उम्मीद है क्योंकि प्रोग्रामर परीक्षक है और वे बहुत स्मार्ट हैं इसलिए इसे काम करना चाहिए।

मैं नहीं कह रहा हूं कि डॉगफूडिंग एक अच्छा विचार नहीं है। मुझे लगता है कि परीक्षक अब बहुत महत्वपूर्ण हैं कि मैं एक प्रोग्रामर हूं।

Comments

अच्छे समर्पित परीक्षक निश्चित रूप से अंडर रेटेड हैं!

— पीटर बॉटन

कुत्ते का भोजन!? मैं केवल फाइव स्टार लॉबस्टर खाना बनाती हूं! ... और यही कारण है कि जब मुझे कुछ खराब होता है तो मुझे यह बताने के लिए एक परीक्षक की आवश्यकता होती है। मैंने बात बनाई और जाना कि यह कैसे काम करता है। यूआई बनाने वाला कोई भी व्यक्ति कभी भी इसे पूरी तरह से जांचने के लिए योग्य नहीं होता है, सिर्फ इसलिए क्योंकि वे जानते हैं कि यह कैसे काम करता है, न कि यह कैसे काम करता है जो किसी के साथ नहीं है।

— मॉर्गन हेरलॉकर

सामान्य रूप से परीक्षक होने में कुछ भी गलत नहीं है। आपके खुद के कोड के लिए केवल परीक्षक होना गलत है। प्रोग्रामर मन में मान्यताओं के एक सेट के साथ कोड करते हैं, और यदि परीक्षक के पास समान धारणाएं हैं, तो वे अप्रत्याशित भागों का उपयोग नहीं करेंगे, और कुछ कीड़े याद करेंगे।

— dbkk

अपने खुद के कोड का परीक्षण निश्चित रूप से एक बड़ा नहीं-नहीं है। एक प्रोग्रामर बहुत सारे अन्य सामान को कवर कर सकता है, लेकिन वास्तविक कार्यात्मक परीक्षण (यदि आप यूनिट परीक्षण नहीं कर रहे हैं तो आप वैसे भी प्रोग्रामर नहीं हो सकते हैं) अपने स्वयं के कोड का एक बहुत बुरा विचार है। इसके साथ डॉगफूडिंग अच्छा है, मन।

— ग्लेनट्रॉन

+1 - प्रोग्रामर प्रोग्राम का उपयोग करने के तरीके के बारे में गैर-प्रोग्रामर से विशिष्ट रूप से अलग सोचते हैं। क्या आप कभी "फ़ाइल -> सहेजें" मेनू आइटम में बग की खोज कर सकते हैं?

Answer 4

आपको ऑफिस हार्डवेयर समस्याओं के लिए गो-टू- मैन बनने से सावधान रहना चाहिए । इसमें पीसी समस्या निवारण, सर्वर व्यवस्थापक, बैकअप, और यहां तक ​​कि फ़ोन सिस्टम कार्य शामिल हो सकते हैं। मैंने अपने पिछले हार्डवेयर अनुभव का उल्लेख करने की गलती की, और अंततः मेरे हार्डवेयर / समस्या निवारण कर्तव्यों को मेरे प्रोग्रामिंग कर्तव्यों के साथ गंभीर रूप से विरोध किया।

Comments

दोषियों को बताएं कि उन्हें आपके बॉस से अनुमति की आवश्यकता है, और इसके लिए उपयोग किए गए सभी समय को पंजीकृत करें।

@ थोर हार्डवेयर सामान पर काम करने की दिशा-मेरे मालिक से। यह ऑफिस के लिए मददगार था, लेकिन मैं प्रोग्रामिंग पर अपने करियर को उतना फोकस नहीं कर पाया, जितना मुझे उस समय पसंद था।

— जॉन ऑनस्टॉट 19

@, यदि बॉस कहता है कि आपको इसे करने की आवश्यकता है, तो ठीक है ... आपको इसे करने की आवश्यकता है। आप उसके साथ चर्चा कर सकते हैं कि यह संतोषजनक है या नहीं, और यदि आप एक समझौते के लिए नहीं मिल सकते हैं, तो यह छोड़ने का समय है।

+1 वही बात मेरे साथ हुई है। वे चाहते हैं कि मैं न केवल कोड लिखूं, बल्कि ब्रोबिंग वेंडर्स के साथ नेटवर्क के मुद्दों से भी निपटूं और इससे काफी तनाव पैदा हो गया है।

— रिच

Answer 5

एक प्रोग्रामर को अपने स्वयं के कोड के लिए एकमात्र परीक्षक नहीं होना चाहिए ।

डेवलपर्स मान्यताओं के एक सेट के साथ कोड लिखते हैं। यदि परीक्षकों के पास मान्यताओं का एक समान सेट है, तो वे उन सीमाओं के बाहर अप्रत्याशित कार्यक्षमता का प्रयोग नहीं करेंगे, और कई मुद्दे पूर्ववत रहेंगे।

इसके अलावा, आगे बढ़ने के लिए, देवता चीजों को तोड़ने की कोशिश करने के लिए अत्यधिक प्रेरित नहीं हैं, जबकि परीक्षक (शायद एक अवचेतन स्तर पर) हैं।

इसका मतलब यह नहीं है कि देव परीक्षण बेकार है। इसके विपरीत - अच्छा देव परीक्षण परीक्षकों को गहरे मुद्दों को खोजने पर ध्यान केंद्रित करने में सक्षम बनाता है। हालांकि, समर्पित परीक्षण एक समर्पित परीक्षक का विकल्प नहीं है ।

Answer 6

दो मैं बल्ले से सही सोच सकता हूं।

1. तकनीकी सहायता। मैं यहाँ नहीं हूँ ग्राहकों को नई साइट के माध्यम से काम करने में मदद करने या उन्हें सिखाने के लिए कि सुविधाओं का उपयोग कैसे किया जाए।
2. हालांकि इस प्रक्रिया में विभिन्न बिंदुओं पर ग्राहकों के साथ इंटरफेस करना आवश्यक हो सकता है, जब तक कि आप एक प्रबंध प्रोग्रामर नहीं होते हैं जब तक कि आप वास्तव में सुविधाओं और डिजाइन कार्यान्वयन के बारे में उनसे सीधे संवाद न करें।

आप कह सकते हैं कि सीएसएस / यूआई विकास प्रोग्रामिंग "दायरे" के बाहर होगा, लेकिन मेरे अनुभव में यह आज एक आवश्यक कौशल है। आप केवल तालिकाओं से दूर नहीं हो सकते हैं और इसे सही ढंग से लागू करने के लिए किसी और पर निर्भर हैं। मुझे डिज़ाइन लागू करना या नया डिज़ाइन संभालने के लिए कोड को बदलना पसंद नहीं हो सकता है, लेकिन यह नौकरी का हिस्सा है।

प्रश्न लिखना ठीक है, क्यू / ए परीक्षण ठीक है (और आईएमओ प्रोग्रामर का काम होना चाहिए , एक बाहरी विभाग है जो इसे ढूंढता है, लेकिन पहले आपको इसका परीक्षण करना चाहिए)। सर्वर प्रशासन एक ग्रे क्षेत्र का एक सा है। इस पर निर्भर करता है कि परियोजना कितनी बड़ी है या यदि आपके पास एक समर्पित सर्वर व्यवस्थापक है तो इसकी आवश्यकता हो सकती है या नहीं।

Comments

बिंदु 2 के बारे में, कम से कम एक कंपनी है, जिसके पास एक संस्थापक सिद्धांत के रूप में है कि कोड लिखने वाले व्यक्ति को ग्राहक से सीधे बात करनी चाहिए: निर्वासन के अपने फायदे हैं।

— फ्रैंक शीयर

Answer 7

सामान्य तौर पर, यह मेरा अनुभव रहा है कि अधिकांश प्रोग्रामर को यूजर इंटरफेस के रूप और स्वरूप को विकसित नहीं करना चाहिए - हालांकि मैं निश्चित रूप से एक यूआई विकसित करने में सक्षम हूं (और अक्सर एक प्रोटोटाइप का निर्माण या अवधारणा का प्रमाण तैयार करते समय), यह है एक मानव कारक व्यक्ति के लिए बेहतर छोड़ दिया गया है (जो हमारी छोटी कंपनी में एक ग्राफिक कलाकार है, जो स्क्रीन लेआउट भी करता है और अधिकांश मैनुअल और ब्रोशर बनाता है)।

साथ ही, डेवलपर्स को क्यूए परीक्षण नहीं करना चाहिए - यह क्यूए विभाग का काम है (जिस कंपनी में मैं काम करता हूं वह एम्बेडेड चिकित्सा उपकरण बनाती है, इसलिए यह एक आवश्यकता है कि परीक्षण एक अलग विभाग द्वारा किया जाए)।

दूसरी ओर, मुझे कोई कारण नहीं दिखता है कि डेवलपर्स डेटाबेस को डिज़ाइन नहीं कर सकते हैं और SQL लिख सकते हैं, अगर उनके पास ऐसा करने के लिए पृष्ठभूमि है - मैंने कई बार किया है।

Comments

+1 सहमत है कि डेवलपर्स द्वारा QA परीक्षण जिसने इसे लिखा था वह उद्देश्य को हरा देता है।

— Spong

@ जोश कुछ क्यूए परीक्षण डेवलपर्स द्वारा किया जा सकता है, लेकिन मुख्य क्यूए परीक्षण दूसरों द्वारा किया जाना चाहिए। यदि आप अपने खुद के ऐप का परीक्षण करते हैं, जो आपने लिखा है, तो आप किसी भी संभावित समस्याओं के बारे में अवचेतन से चलेंगे। मुद्दा उन समस्याओं की खोज करना है जो डेवलपर्स को खोजने में असमर्थ हैं, एक तरह का आँखों का ताज़ा सेट।

— स्पंज

@JoshK @ChaosPandion सहमत है, डेवलपर्स द्वारा कुछ पूर्व परीक्षण किया जाना चाहिए - लेकिन यह भरोसा नहीं किया जाना चाहिए, इस प्रकार उन लोगों द्वारा क्यूए परीक्षण को अलग करें जिन्होंने इसे विकसित नहीं किया था।

— स्पंज

-1: मैं असहमत हूं कि प्रोग्रामर GUI को डिज़ाइन नहीं करना चाहिए। मैंने एक छोटी सी कंपनी में 8 साल काम किया है, और मैंने सभी यूजर इंटरफेस को डिजाइन किया है। मैंने हमेशा Microsoft द्वारा उत्कृष्ट डिजाइन दिशानिर्देशों का पालन किया, और HMI डिजाइनिंग पुस्तकों के एक जोड़े को पढ़ा। हमने बाहरी चित्रकारों को केवल ग्राफिक्स के लिए आउटसोर्स किया।

— जादूगर79

एक बात जो मुझे यहाँ परेशान करती है, वह यह है कि एक ग्राफिक्स व्यक्ति UI को डिज़ाइन करने के लिए प्रोग्रामर की तुलना में बेहतर है। यह हो सकता है कि आपके ग्राफिक कलाकार इंटरफेस डिजाइन करने में बहुत अच्छे हैं, लेकिन सामान्य स्थिति में यह भ्रामक, अनुपयोगी, सुंदर इंटरफ़ेस में बदल सकता है, भ्रामक के विपरीत, मुश्किल से प्रयोग करने योग्य, बदसूरत इंटरफ़ेस आप स्टीरियोटाइप प्रोग्रामर से प्राप्त करेंगे।

— डेविड थॉर्नले

Answer 8

तकनीकी सहायता

टेक-सपोर्ट कॉल लेने से मेरा बहुत सारा दिन बर्बाद होता है ...

कुछ लोकप्रिय हैं:

• "मेरा खाता बंद है" या "मैं अपना पासवर्ड भूल गया"
• "मेरा" फ़ोन | कीबोर्ड | माउस | कंप्यूटर] काम नहीं करता है "
• "मेरा कंप्यूटर धीमा है, क्या आप इसे असामान्य कुछ भी देख सकते हैं?"
• "जब मैं इस बटन पर क्लिक करता हूं तो X क्यों होता है? इसे Y करना चाहिए"
• "मुझे ये पॉपअप मिलते रहते हैं ...." या "मुझे लगता है कि मेरे पास एक वायरस है"
• "यह व्यक्ति अब यहाँ नहीं है, क्या आप उनके सभी सामानों को निष्क्रिय कर सकते हैं?"
• "हमारे पास एक नया कर्मचारी है, क्या आप उन्हें लॉगिन, सुरक्षा कार्ड, फोन एक्सट, ईमेल आदि के साथ सेट कर सकते हैं?"

Answer 9

कोई भी भूमिका जो उसे खुद को प्रबंधित करती है। छोटी टीमों में, अक्सर वरिष्ठ डेवलपर्स में से एक को परियोजना प्रबंधक बनाने की प्रवृत्ति होती है, लेकिन उसे टीम में एक प्रोग्रामर के रूप में भी रखते हैं। यह सभी प्रकार की समस्याओं की ओर जाता है, क्योंकि इस आदमी, एक प्रोग्रामर के रूप में, मूल रूप से अप्रबंधित है। अन्य टीम के सदस्यों को सभी कार्यों को सौंपने के बजाय, वह अक्सर उनमें से कई को खुद को सौंपने के लिए, विशेष रूप से सबसे कठिन कार्यों को करने के लिए लुभाया जाएगा। इसलिए सबसे कठिन कार्य, जिन लोगों को समस्याएँ उत्पन्न होने की सबसे अधिक संभावना होती है, उन्हें एक ऐसे व्यक्ति को सौंपा जाता है जो केवल 50% प्रोग्रामर के रूप में उपलब्ध होता है और ऐसी रिपोर्ट्स को कोई नहीं। जब टीम के अन्य सदस्य अपने गधे को मारने के बजाय देने में असमर्थ होते हैं, तो वह अपने कार्यों को करने की कोशिश करेगा, क्योंकि, एक परियोजना प्रबंधक के रूप में, वह सफलता के लिए जिम्मेदार है और इसे प्राप्त करने का सबसे सुरक्षित तरीका यह है कि वह स्वयं करे। है ना?

Answer 10

किसी ऐसी चीज के लिए तकनीकी सहायता, जिसे विकसित करने, तैनात करने या बनाए रखने में आपका कोई हाथ नहीं है, और इसके लिए कोई प्रशिक्षण नहीं लिया गया है और बड़े बदलावों के लिए अप-टू-डेट नहीं रखा गया है। मेरी नौकरी का एक हिस्सा उन ग्राहकों के लिए फोन का जवाब देना हो गया है, जो कहते हैं कि उनका इंटरनेट काम क्यों नहीं कर रहा है। मैं व्यवसाय के उस आधे हिस्से से नहीं निपटता, इसलिए मैं उन्हें उपयोग के बारे में कुछ नहीं बता सकता।

यह तकनीकी सहायता नहीं कर रहा है, कि इसमें कोई समस्या नहीं है। चीजों को विकसित करने की कोशिश करते हुए यह एक सचिव / तकनीकी सहायता लड़का है।

यह पूरे दिन शिकायत करने वाले लोगों को सुनने और उन्हें कुछ भी नहीं बता पाने के कारण काफी कर योग्य हो जाता है। मैं हर कीमत पर इससे बचने की सलाह दूंगा।

Comments

हाँ, दिन भर में कई बार व्यक्तित्व को बदलना पड़ता है। जब आप लगातार बाधित हो रहे हों तो उन कार्यों पर काम करना मुश्किल होता है जिनमें एकाग्रता की आवश्यकता होती है।

— रिच

Answer 11

बिक्री ।

कुछ गरीब बग्गर को ऐसा करना पड़ता है, लेकिन यह सुनिश्चित करना चाहिए कि डेवलपर्स न हों।

Answer 12

जैसा कि मैंने बड़ी उम्र पा ली है, मैंने महसूस किया है कि सबसे अच्छा है अगर डेवलपर्स अपनी तैनाती नहीं करते हैं (मैंने इस एक दांत और नाखून को लड़ा है)। उन्हें उत्पादन डेटाबेस का कोई अधिकार नहीं होना चाहिए सिवाय चुनिंदा अधिकारों के। हमारे कोड को बहुत कम बगिया मिली (और एक ही चीज़ कई बार फ़सल नहीं की, क्योंकि परिवर्तन केवल ठेस में किया गया था और बाद में देव की तैनाती ने इसे फिर से लिखा था, तब हम जल्दबाज़ी में ठेस पर ही तय करते हैं, कुल्ला करते हैं और दोहराते हैं) जब हम इसे अन्य लोगों को देने के लिए शुरू करने के लिए शुरू किया था और त्वरित फिक्स उत्पादन परिवर्तन करने की अनुमति नहीं दी जा रही थी क्योंकि तैनाती काफी सही नहीं थी। इसके अलावा हमने उन आकस्मिक "अपडेट्स को बंद कर दिया, जहां क्लॉज बिना हाइलाइट किए हुए था जिसने टेबल के हर रिकॉर्ड को बदल दिया"।

Comments

हाँ, हाँ और हाँ। कभी भी डेवलपर्स को उत्पादन के लिए कोई पहुँच नहीं दें और मंचन के लिए बहुत सीमित (और अधिमानतः कोई नहीं)। अगर और कुछ नहीं तो यह उस तनाव को कम कर देता है जो वे उजागर करते हैं।

— एलग्रिन्गोग्रांड

हाँ! मैं एक डेवलपर हूं, और मैं इस सभी उत्पादन सामग्री तक पहुंच नहीं चाहता हूं । और सॉफ्टवेयर की तैनाती करने वाले अन्य लोगों के साथ, यह तैनाती प्रक्रिया का एक और परीक्षण है। (और शायद desaster वसूली बाहर इस के साथ ही सुधार होगा।)

— चापलूसी

Answer 13

कलाकार और यूजर इंटरफेस डिजाइनर ।

अधिकांश प्रोग्रामर कलाकृति पर बहुत खराब होते हैं, लेकिन कंपनियां किसी कलाकार को अपने उत्पादों के लिए चित्र और आइकन बनाने के लिए भुगतान करने की जहमत नहीं उठाती हैं, और केवल "प्रोग्रामर आर्ट" का उपयोग करती हैं - घृणित परिणामों के साथ। (विंडोज विस्टा तक, यह मैक और पीसी के बीच सबसे तुरंत स्पष्ट विभेदक कारक था - मैक सुंदर और मैत्रीपूर्ण दिखते थे, पीसी एक नजर थे)

इसी तरह, बहुत सारे प्रोग्रामर उपयोगकर्ता इंटरफ़ेस में बहुत रुचि नहीं रखते हैं - वे मुख्य रूप से अपने कोड के बारे में परवाह करते हैं। वे सीधे अपने सदस्य चर की सामग्री को सीधे कुछ संपादन योग्य क्षेत्रों में उजागर करते हैं, अक्सर देखभाल नहीं करते हैं जहां वे अपने प्रपत्रों पर बटन और फ़ील्ड डालते हैं, और यह मानते हैं कि यह पर्याप्त है, जिसके परिणामस्वरूप अनुपयोगी सॉफ़्टवेयर है। (जब तक आईफोन उन्हें यह दिखाने के लिए नहीं आया कि आप वास्तव में एक फोन यूआई बना सकते हैं जो उपयोग करने के लिए अच्छा था, तब तक संपूर्ण मोबाइल फोन उद्योग इसके लिए बहुत दोषी था)

लोटस नोट्स इस बात का एक चमकदार उदाहरण है कि प्रोग्रामर को बाहर निकालने में मदद करने के लिए पेशेवर डिजाइनर न मिलने पर ये दोनों चीजें कितनी खराब हो सकती हैं।

Comments

"अधिकांश प्रोग्रामर Artwook में बहुत खराब हैं" और "बहुत सारे प्रोग्रामर बहुत रुचि नहीं रखते हैं" समान नहीं है क्योंकि "कोई प्रोग्रामर दिलचस्पी नहीं रखता है" और "सभी प्रोग्रामर खराब हैं"। मैं वास्तव में एक जोड़े को जानता हूं जो इस पर काफी अच्छा करते हैं।

— MIA

@ जिम लियोनार्डो: वास्तव में। इसलिए मैंने "सभी" के बजाय "सबसे" और "बहुत" कहा। :-)

— जेसन विलियम्स

Answer 14

समग्र परीक्षण और परीक्षण योजनाएं लिखना। गंभीरता से, दोस्तों, मैं अपनी स्वयं की परीक्षण योजनाएं लिख सकता हूं, लेकिन इसका मतलब है कि उत्पाद में बेकिंग जो भी गलतफहमी, गलत धारणाएं, और संज्ञानात्मक गलतियां हैं जो मैंने सामान लिखते समय की थी। यह केवल एक चीज थी जिसके बारे में मुझे एक कंपनी में काम करने से नफरत थी; जहां मैं अभी हूं, हमारे पास कम से कम कोड समीक्षाएं हैं जो संभवतः इस सामान को पकड़ेंगे।

Comments

हां, किसी भी कोड के बनने से पहले, अधिकांश परीक्षण विनिर्देशों के साथ लिखे जाने चाहिए। यद्यपि एक डेवलपर के पास अतिरिक्त ज्ञान है कि उन्होंने जो कुछ भी छुआ है उसके ज्ञान के आधार पर परीक्षण करना कोई बुरी बात नहीं है।

— पीटर बॉटन

Answer 15

कभी भी अधिक "हैट" न पहनें, जो आपको यथोचित रूप से संभाल सकते हैं और साथ में आराम कर सकते हैं, यह कहकर कबूतर छेद डेवलपर्स को कोशिश कर रहे हैं कि उन्हें ए या बी नहीं करना चाहिए , एक महान यूआई डिजाइनर किसी का ध्यान नहीं जा सकता है क्योंकि किसी को लगता है कि प्रोग्रामर से दूर रहना चाहिए यूआई।

दिन के अंत में सभी के पास अलग-अलग ताकत और कमजोरियां होने वाली हैं और एक अच्छे प्रबंधक / पर्यवेक्षक / टीम लीडर को उनके लिए काम करने वाले लोगों को यह सुनिश्चित करने का सबसे अच्छा तरीका पता होना चाहिए कि प्रतिभाओं का उचित उपयोग किया जा रहा है। इसी तरह, यदि आप यूआई डिजाइन करने या अंतिम उपयोगकर्ताओं के साथ व्यवहार करने में सहज नहीं हैं, तो आप टीम को बताएंगे ताकि आप उस क्षेत्र में अपनी भूमिका को कम कर सकें। हालाँकि, आपको किसी अन्य क्षेत्र में कुछ अतिरिक्त काम लेने के लिए तैयार रहना चाहिए।

इसके अलावा, यदि आप बहुत अधिक टोपी पहन रहे हैं (जैसे प्रोग्रामर, यूआई डिजाइनर, परीक्षक, व्यापार विश्लेषक, आदि) तो आप या तो उनमें से कुछ पर खराब काम करने जा रहे हैं, या आप खुद को जला देंगे। सुनिश्चित करें कि आप जानते हैं कि आप कितने हैट को संभाल सकते हैं और उस स्तर के आसपास काम का बोझ रखने की कोशिश कर सकते हैं।

इसके अलावा, वास्तव में कोई "टोपी" नहीं है जो एक डेवलपर को नहीं पहननी चाहिए यदि उनके पास उस भूमिका में उत्कृष्टता प्राप्त करने का कौशल है।

Answer 16

मैं कोई भी नौकरी लेने के लिए हूं जो मुझ पर फेंकी जाती है अगर और केवल अगर:

• मैं अपने कौशल स्तर और संभावित निहितार्थों के बारे में अग्रिम रूप से चेतावनी देता हूं और मेरे मालिक ने फैसला किया है कि यह स्वीकार्य है
• एक गुरु स्तर का व्यक्ति है जो (और शायद किसी स्तर पर होगा) मुझे कुछ अप्रत्याशित से निपटने में मदद करता है
• कुछ डॉक्यूमेंटेशन, ऑनलाइन पूछे गए सवालों आदि के माध्यम से पढ़ें।

इस तरह मैं ज्यादातर अपने बॉस के खिलाफ बीमित हो जाता हूं और अगर कोई गलत हो जाता है, तो यह कम से कम निश्चित है।

Answer 17

डेवलपर्स स्थिति में हितधारक हैं (जैसे ग्राहक, मालिक आदि), इसलिए उन्हें एक सार्थक नौकरी की उम्मीद करने का अधिकार है। मेरी राय में, इसका मतलब है कि अपनी ताकत के साथ काम करने का अवसर ।

इसलिए, एक डेवलपर को ऐसी टोपी नहीं पहननी चाहिए जो सक्रिय न हो, व्यक्तिगत विकास में योगदान दे, और चरम प्रदर्शन का नेतृत्व करे - और "टोपी" से समय चुराए जो इन चीजों को करते हैं।

केवल अपने स्वयं के कोड का परीक्षण नहीं करने के अलावा, मुझे लगता है कि कोई भी "टोपी" ठीक है अगर टोपी पहनने वाले डेवलपर के लिए यह सार्थक काम है।

Answer 18

"डिजाइनर" या "रचनात्मक आदमी"। आप निर्दोष रूप से अगले ऑनलाइन विज्ञापन अभियान के लिए मार्केटिंग टेक्स्ट लिखने के लिए एक एप्लिकेशन के इंटरफ़ेस का एक नकली रूप से एक साथ डालेंगे या x_x को जानने से पहले नीले रंग के "सही" शेड के बारे में अंतहीन चर्चा करेंगे।

Answer 19

कि एक पुआल के साथ बियर के डिब्बे के साथ टोपी। बुरा विचार अगर तुम पकड़े जाओ।

संपादित करें:

यहाँ मैं नफरत करता हूँ, लेकिन वह बहुत बड़ा इनाम रखता है - यह मुझ पर एक बड़ा संकेत है जो कहता है कि यदि यह चीज़ टूट जाती है तो यह आपकी सारी गलती है। हैं - अब तहखाने में वापस जाओ ... अच्छा लड़का ... यही है।

दोष टोपी।