प्रोग्रामिंग, तेज और धीमा: डेवलपर्स और आत्मविश्वास का मनोविज्ञान

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

लेकिन पहले, कहानी ...

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

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

आपको कितना समय लगता है कि यह मुझे इस परियोजना पर ले गया? चार सप्ताह? शायद पाँच?

एमएम, वास्तव में: तीन महीने।

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

इन काले अवधियों में से एक में, मैंने फैसला किया कि आई विल नेवर मेक सम मिस्टेक अगेन।

दुर्भाग्य से, मेरे करियर के दौरान, मुझे कुछ मुश्किल का एहसास हुआ: मैं लगातार ऐसी गलतियाँ करता हूँ।

वास्तव में, मैंने भी कुछ बेहतर सीखा है: हम सभी ये गलतियाँ करते हैं।

हाल ही में, मैंने डैनियल कहमैन की पुस्तक, थिंकिंग, फास्ट एंड स्लो , एक व्यक्ति के संज्ञानात्मक प्रक्रियाओं, उसकी आश्चर्यजनक शक्तियों और (आश्चर्यजनक रूप से अनुमानित) कमजोरियों के बारे में मनोविज्ञान क्या जानता है, का एक व्यापक अध्ययन पढ़ा।

मेरा पसंदीदा हिस्सा सेल्फ-कॉन्फिडेंस है। यह पता चला है, चलो कहते हैं, डेवलपर्स के साथ कुछ कनेक्शन कैसे गणना करते हैं।

आपका परिकलन क्यों चूसना, भाग I: सॉफ्टवेयर लिखना = कुछ ऐसा जानना जिसे आप अभी तक नहीं जानते हैं

शुरू करने के लिए, मेरा मानना ​​है कि वास्तव में, केवल दो कारण हैं कि हमारी गणना इतनी खराब क्यों है। पहला कारण, एक प्रकार का अकल्पनीय सुधार: सॉफ्टवेयर लिखना एक ऐसी प्रक्रिया है जिसमें आपको यह पता लगाने की आवश्यकता है कि अविश्वसनीय रूप से सटीक विवरण में किसी चीज़ का वर्णन कैसे किया जाए ताकि आप कंप्यूटर को समझा सकें कि इसे कैसे किया जाए। लेकिन समस्या यह है कि उन हिस्सों में जिन्हें आप काम के शुरुआती चरण में पूरी तरह से नहीं समझते हैं, ऐसी कठिनाइयां हैं जो सामने आएंगी और कठोर रूप से आपको चोट पहुंचाएंगी।

और किसी भी तरह से सुधार करना पूरी तरह से असंभव है। और केवल अगर आप वास्तव में "पूरी तरह से समझते हैं कि क्या करना है," या आपके पास एक पुस्तकालय है या सॉफ्टवेयर का एक टुकड़ा है जो आपके लिए ऐसा कर सकता है, तो आप कुछ भी नहीं लिखते हैं। अन्यथा, अज्ञात प्रकट होता है, और अक्सर यह विस्फोट होता है। और यह ज्ञात नहीं हो सकता है कि इन समस्याओं को हल करने में कितना समय लग सकता है, शायद एक दिन, एक वर्ष, या आपके पास ब्रह्मांड की थर्मल मृत्यु से पहले पर्याप्त समय नहीं हो सकता है।

उदाहरण के लिए, मामले में जब यह पता चलता है कि विकास की ओर से शामिल कुछ अविश्वसनीय हैं ... तो आपको त्रुटियों वाले पूरे सरणी को फिर से लिखना होगा; या, जब डेटाबेस एन्कोडिंग के कुछ महत्वपूर्ण भागों को नहीं समझता है ... तो आपको अपनी सभी योजनाओं को खरोंच से पुनर्निर्माण करना होगा; या, शैली का एक वास्तविक क्लासिक, जब आप ग्राहकों को काम दिखाते हैं, लेकिन वे खुद को जो आदेश देते हैं, उसे स्वीकार नहीं करते हैं, लेकिन थोड़ा अलग चाहते हैं ... जो कई बार करना अधिक कठिन होता है।

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

और फिर भी ... हम इस तरह के प्रभावशाली गणना करना जारी रखते हैं।

और इससे भी बदतर, हम अपनी गणना में विश्वास करते हैं। मैं खुद अपने आप पर विश्वास करता हूं, जिस समय मैं उन्हें पैदा करता हूं।

तो, एक मिनट प्रतीक्षा करें, मैं क्या सुझाव दे रहा हूं कि सभी डेवलपर्स वैसे ही, पूर्वानुमानित सोच त्रुटियों के शिकार हो जाते हैं?

हां, यह वही है जो मैं पेश करता हूं।

क्यों आपकी गणना भाग II को चूसती है: आत्मविश्वास

"विशेषज्ञ" पूर्वानुमान बनाने की समस्या के बारे में काहेनमैन बहुत सारी बातें करते हैं। चौंकाने वाली व्यापक परिस्थितियों में, ये भविष्यवाणियां पूरी तरह से बेकार हैं। विशेष रूप से, कई, बहुत सारी स्थितियों में, निम्नलिखित तीन कथन सही हैं:

किसी भी भविष्य की घटनाओं के बारे में "विशेषज्ञों" के पूर्वानुमान इतने अविश्वसनीय हैं कि वे अनिवार्य रूप से अर्थहीन हैं;

2-हालांकि, जिन विशेषज्ञों की चर्चा की गई है, उनके पूर्वानुमानों की सटीकता पर अविश्वसनीय रूप से विश्वास है;

3- और सबसे अच्छा: ऐसा लगता है कि विशेषज्ञों की आत्मविश्वास की इस भावना को पूरी तरह से कम नहीं कर सकता है;

और अंतिम कथन, वास्तव में बकाया है, कि भले ही विशेषज्ञ ईमानदारी से अपनी असफलताओं का सामना करने की कोशिश करें, भले ही वे मानव सोच की इस कमी के बारे में गहराई से जानते हों ... फिर भी वे अपने पूर्वानुमानों की सटीकता में गहराई से आश्वस्त रहते हैं।

इस क्षेत्र में अपनी असफलताओं के बारे में चौंकाने वाली कहानी बताने के बाद काहेनमैन ने इसे कैसे समझाया:
"आप अपने भविष्य के निर्णयों में जो आत्मविश्वास महसूस करेंगे, वह आपके द्वारा पढ़े गए हर शब्द पर विश्वास करने पर भी नहीं होगा।"

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

यह महसूस करना कैसा है कि आप गलत हैं: सिस्टम I और II, और 3 सप्ताह और 3 महीने की समस्या

"थिंकिंग फास्ट एंड स्लो" में, कहमैन ने मनोविज्ञान के अधिकांश भाग को "विचारों" को नियंत्रित करने वाले दो "सिस्टम" के बीच की बातचीत के रूप में समझाया है: सिस्टम I और सिस्टम II। इस विषय पर मेरा बहुत छोटा सारांश इस प्रकार होगा: "सिस्टम II सटीक, तर्कसंगत, विश्लेषणात्मक सोच के लिए जिम्मेदार है, और सिस्टम I तेज, हेयुरिस्टिक और तुलनात्मक सोच के लिए जिम्मेदार है।"

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

यह देखने के लिए कि सिस्टम I और II की बातचीत वास्तव में कितनी भयानक हो सकती है, और एक ही समय में ईमानदार, भरोसेमंद गणना के साथ, मैं संक्षेप में अपने मित्र (और Hut8Labs सहयोगी) एडमंड बोर्गेंसन को माइक्रोफोन स्थानांतरित करने जा रहा हूं। उन्होंने अपने पत्र में इसका वर्णन इस प्रकार किया:

"जब मैंने खुद से पूछा" इस परियोजना में कितना समय लगेगा ", तो सिस्टम को इसके बारे में कोई पता नहीं था, लेकिन एक उत्तर प्राप्त करना चाहता था, और प्रश्न को ट्रांसकोड किया। किस समय? मुझे संदेह है कि "जैसा कि मुझे विश्वास है कि मैं यह काम कर सकता हूं," और यह, बदले में, एक निश्चित गुणांक के साथ एक समय गणना में बदल गया था, जो कि एक सापेक्ष मूल्य है (उदाहरण के लिए, जब बॉब डिग्री महसूस करता है X का आत्मविश्वास, वह हमेशा 3 सप्ताह के लिए प्रतिक्रिया देता है; जब सूसी को X के आत्मविश्वास की डिग्री महसूस होती है, तो वह हमेशा 5 सप्ताह तक जवाब देती है। "

यदि आप धीरे-धीरे महसूस करते हैं कि आपके पास दो "बड़े" समय मीटर हैं तो अपना हाथ उठाएं? उदाहरण के लिए, मेरे लिए यह "3 सप्ताह" और "3 महीने" है। पहला अर्थ है कि "यह जटिल लगता है, लेकिन अनिवार्य रूप से मुझे लगता है कि मुझे पता है कि यह कैसे करना है"; दूसरा अर्थ है: "वाह, यह मुश्किल है, मुझे पूरा यकीन नहीं है कि यह क्या होगा, लेकिन मुझे यकीन है कि मैं इसका पता लगा सकता हूं।"

आह, मुझे लगता है कि एडमंड पूरी तरह से सही है।

(उन लोगों के लिए जो घर पर खेलते हैं: मेरी "3 सप्ताह" की परियोजनाओं में शायद 5-15 सप्ताह लगेंगे, मेरी "3 महीने" की परियोजनाएं आमतौर पर 1-3 साल लगती हैं, उन दुर्लभ मामलों में जब कोई मुझे इसके लिए भुगतान करना चाहता है। )।

बहुत बढ़िया! अब हम इतना आत्मविश्वासी होना छोड़ दें!

आप इस दृष्टिकोण से सोच सकते हैं: "ठीक है, मैं देखता हूं कि आप कहां जा रहे हैं, दान, हमें सिस्टम II के बजाय सिस्टम II के सिद्धांतों के अनुसार इन गणनाओं को देखने की आवश्यकता है। इस प्रकार, हमारे सावधान, विश्लेषणात्मक दिमाग बेहतर गणना करेंगे।"

बधाई हो, आपने अभी-अभी झरने का आविष्कार किया है।

संक्षेप में, यह "प्रोग्रामिंग शुरू करने से पहले एक पूर्ण विनिर्देश का संकलन" करने के लिए दृष्टिकोण का अनुप्रयोग है: अपनी टीम को सहज गणना करने न दें, सभी को अपनी विश्लेषणात्मक क्षमताओं को सावधानीपूर्वक जुटाने और एक विस्तृत विनिर्देशन के साथ एक समाधान और छोटे हिस्सों में टूटी हुई गणना के साथ संपर्क करने के लिए मजबूर करें।

हालाँकि, यह विफलता के लिए बर्बाद है। हमेशा की तरह ...

यहाँ वास्तविक समस्या गलत माप के दो स्रोतों के बीच पारस्परिक क्रिया है: एक व्यक्ति के आत्मविश्वास के संबंध में मानवीय त्रुटि, और प्रत्येक वास्तविक सॉफ्टवेयर लेखन परियोजना में निहित अनिश्चितता का एक अभिन्न तत्व। यह अनिश्चितता इतनी गंभीर है कि एक स्वच्छ तर्कसंगत प्रणाली II भी सटीक भविष्यवाणियां नहीं कर सकती है।

सौभाग्य से, सोचने की ताकत के उपयोग को संयोजित करने का एक तरीका है, और एक ही समय में, वास्तविक दुनिया की अपूर्णता का सामना करना पड़ता है।

सबसे पहले, अपनी सोच की ताकत का उपयोग कैसे करें।

विशेषज्ञ कब सही हैं और अपने लाभ के लिए इसका उपयोग कैसे करें

Kahneman और अन्य शोधकर्ता उन स्थितियों की पहचान कर सकते हैं जहां विशेषज्ञ निर्णय पूरी तरह से गलत नहीं है। उनके अनुसार:

“यह पता लगाने के लिए कि क्या आप एक निश्चित सहज निर्णय पर भरोसा कर सकते हैं, आपको दो प्रश्न पूछने की आवश्यकता है: क्या वातावरण जिसमें निर्णय उपलब्ध प्रमाणों के आधार पर भविष्यवाणियां करने के लिए पर्याप्त जगह लेता है? "हाँ" का उत्तर निदान के लिए है, "नहीं" स्टॉक पिकर के लिए है। क्या पेशेवरों के पास सिग्नल और पैटर्न का अध्ययन करने का अवसर है? ”

"पत्राचार का अवसर" का अर्थ है बड़ी संख्या में पूर्ण पूर्वानुमान, साथ ही साथ उनकी सटीकता का अध्ययन करने के लिए निकट प्रतिक्रिया।

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

हालांकि, सॉफ्टवेयर विकास के लिए लागू निपटान का एक रूप है जो उपयुक्त है - 0-12 घंटे के कार्य यदि वे तुरंत लागू होते हैं। इस कोण से, चीजें अलग तरह से काम करती हैं:

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

सबसे अधिक परिचालन टीम मैं साप्ताहिक स्प्रिंट में किया गया था, जहां सब कुछ 0, 2, 4, या 8 घंटे में विभाजित किया गया था (और 8 घंटे के कार्यों में हमेशा कुछ अविश्वास था - किसी भी तरह, हमने उन्हें छोटे खंडों में तोड़ने की बहुत कोशिश की )। हमने उन्हें बहुत जल्दी और किसी तरह दुर्घटना से गणना की - इसके लिए हमने पोकर योजना की पांडित्य तकनीक का उपयोग नहीं किया।

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

रोको, रोको, रोको! चलो बस एक हजार 4 घंटे की गणना करते हैं!

मैं यह कैसे कह सकता हूं कि आप इन माइक्रो-कैलकुलेशन को कर सकते हैं, लेकिन किसी तरह आप इन्हें 6-18 महीने पुरानी गणनाओं पर लागू नहीं कर सकते हैं। क्या त्रुटि मान औसत नहीं हैं?

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

आप सोच सकते हैं: यह भी कैसे संभव है कि 4 घंटे में किया जा सकता है कि एक या दो महीने लग सकते हैं?

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

और यह हमें 4 घंटे का काम लग रहा था।

लेकिन जब हम उस स्थान पर पहुंचे, तो हमें एहसास हुआ कि IMAP सर्वर कनेक्शन राज्य का उपयोग करता है, HTTP सर्वर के विपरीत जिसका हम उपयोग करते हैं। यह पता चला है कि यदि हम पारदर्शी मोड में बैकअप सर्वर पर स्विच करना चाहते हैं, तो हमें दो सर्वरों पर कनेक्शन की स्थिति का प्रबंधन करना होगा या एक प्रॉक्सी लोड बैलेंसर लिखना होगा जो कनेक्शन स्थिति के लिए जिम्मेदार होगा और IMAP सर्वर के सामने स्थापित होगा।

हमें 3 महीने का प्रोजेक्ट (2) कैसा लगा।

यहां एक और कारण है कि छोटे स्प्रिंट इस सब की कुंजी हैं: उन्होंने बुरी तरह से गलत गणना की कीमत पर एक कठिन सीमा लगाई।

क्या हम पूरी गांड में हैं?

तो हम क्या करें? स्वीकार करें कि हमारी सभी परियोजनाएं विफलता के लिए बर्बाद हैं; हम अपने बाकी ग्राहकों के साथ अपने रिश्ते को बर्बाद कर देंगे क्योंकि हम अपने वादों को पूरा नहीं कर सकते हैं?

समाधान पहले इस तथ्य को स्वीकार करना है कि सटीक दीर्घकालिक गणना करना मौलिक रूप से असंभव है। एक बार जब आपको यह एहसास हो जाता है, तो आप अगले कार्य को कर सकते हैं, जो कि, हालांकि, संभालना काफी कठिन है: आप अपने विकास दल को मूल्यों के टन का उत्पादन करने के लिए कैसे प्राप्त कर सकते हैं, भले ही आप अधिक या कम महत्वपूर्ण दीर्घकालिक गणना नहीं कर सकते।

हम जो करने आए हैं वह मूल रूप से दुनिया के विभिन्न चुस्त विकास के तरीकों को अपनाने के पहले सिद्धांतों की व्याख्या है। मैं आपको अगले विषय में इसके बारे में अधिक बताऊंगा: “परियोजनाओं के लिए कोई समय सीमा नहीं है! कैसे ग्राहकों को आपसे प्यार करते हुए भी आप अपनी शर्तों को पूरा नहीं कर रहे हैं।

1., समूह <रेडियो पर एक दिनांकित संगीत लिंक> डाला गया, और हर कोई <a long -forgotten TV show> पर चर्चा कर रहा था।
2. अगर आपको लगता है: "एक मिनट रुको, 3 महीने के बारे में क्या, आपके 3-महीने की गणना के रूप में?", तो मुझे नहीं पता कि आप किस बारे में बात कर रहे हैं।

टॉल्स्टॉय समर कैंप स्टार्टअप स्कूल के हिस्से के रूप में अनुवादित