نوشته های معشوقه نرم افزار

 یک احمقِ  ‌بابرنامه، می‌تواند

یک نابغه بدون برنامه را شکست دهد.

وارن بافت

- جایی به اسم بهشت وجود نداره؟! 

+نه جاناتان، جایی به اسم بهشت وجود نداره.

بهشت، به تکامل رسیدنه.

جاناتان مرغ دریایی 

ریچارد باغ

تنها وسوسه‌ای که کسی هرگز نتوانسته بر آن غالب شود :

"وسوسه امید!"

پرندگان می‌روند و در پرو می‌میرند

رومن گاری

جرأت کنید راست و حقیقی باشید.

جرأت کنید زشت باشید! اگر موسیقی بد را دوست دارید، رک و راست بگویید.

خود را همان که هستید نشان بدهید.

این بزک تهوع انگیز دوروئی و دوپلهویی را از چهره روح خود بزدایید، با آب فروان بشوئید!

ژان کریستوف

رومن رولان

درباره‌ی آلِن کِی و مسئله آموزش 

آلن کی§ به  انگلیسی Alan Curtis Kay ، پیش گام برنامه‌نویسی شی‌گرایی(Object Orientation)، یکی از طراحان زبان برنامه‌نویسی اسمالتاک(Smalltalk) و از مشهورترین صاحب نظران  حوزه رابط کاربری، از دنیای برنامه نویسی، مرورگر ها ، اشیاء و توهم الگوها(patterns) می‌گوید. آلن‌کی در17 مِی  سال 1940 چشم به جهان گشود. او یکی از پیشتازان و دانشمندان موثر در زمینه کامپیوتر و برنامه‌نویسی است. او هم‌اکنون مسئول سازمانی به نام (Viewpoints Research Institute (VPRI است که کارش حمایت از ایده‌های آموزشی  و بهبود در زمینه آموزش جهانی است.

زبان اسمالتاک 

در سپتامبر سال 1972، آلن‌کی طراحی اولیه اسمالتاک را به پایان رساند. دن اینگالس(Dan Ingalls§) ظرف چند روز پیاده‌سازی آن را انجام داد و زبان را اجرایی کرد. مسأله بعدی این بود که کودکان اسمالتاک را یاد بگیرند و استفاده کنند. هدف آلن کی جاه‌طلبانه بود: او می‌خواست اسمالتاک، انقلابی در روش آموزش کودکان پدید آورد. آلن کی تحت تأثیر افکار ژان پیاژه، جروم برونر(Jerome Bruner§) و رودولف آرنهایم(Rudolf Arnheim§)، معتقد شده بود که میزان فراگیری کودکان از طریق مشاهده تصاویر بیشتر از خواندن متن است. در فاصله‌‌ی زمانی کوتاهی پس از آن، تد کِهلِر(Ted Kaehler§) و دیانا مِری(Diana Merry§) با استفاده از اسمالتاک ابزارهای تصویرسازی‌ را به وجود آوردند.
آلن کی، آدل گلدبرگ(Adele Goldberg§) و استیو وبر را که در استنفورد بودند برای کار با کودکان استخدام کرد. گلدبرگ در سال 1974 روشی برای آموزش اسمالتاک از طریق جعبه نمایشی کوچکی به نام Joe ابداع کرد. فرمانی نظیر Joe turn 30!» جعبه را 30 درجه می‌چرخاند و فرمان Joe grow 15!» ، جعبه را 15 درصد بزرگتر می‌کرد. جعبه‌ی کوچک، قابل تکثیر بود، می‌توانست با استفاده از فرمان forever do» به طور مداوم بچرخد و نظایر آن. 

برای اینکه بدانید این دستورات چگونه کار می‌کند و آلن‌کی چطور  آن‌ها را در کامپیوتر طراحی و استفاده کرد، می‌توانید ویدئویش را در تد(این لینک§) مشاهده کنید.

پیش‌بینی درست آلن کی در مورد کامپیوترهای شخصی

متأسفانه مدیریت شرکت زیراکس مانند آلن‌کی  علاقه‌مند به آموزش بچه‌ها نبود. در سال 1976، سرانجام بازدارندگی‌های بوروکراتیک سازمانی پیروز شد و مدیریت شرکت تصمیم گرفت منابع دیگری را  در اختیار طرح‌های نرم‌افزاری و سخت‌افزاری PARC قرار ندهد. آلن‌کی و همکارانش نیز متقابلاً اصرار داشتند که شرکت باید ریسک بیشتری بپذیرد. آلن‌کی در یادداشتی به مدیریت زیراکس، به درستی پیش‌بینی کرد که در دهه‌ی 1990 میلیون‌ها رایانه‌ی شخصی وجود خواهد داشت و این رایانه‌ها نیازمند نوعی خدمات اطلاعاتی سراسری مانند اینترنت خواهند بود. اگر می‌گویم به درستی، منظورم این نیست که آن موقع واقعیت داشت و درست بود. اما الان که مدت‌ها از آن سال‌ها می‌گذرد، مشخص شده که پیش بینی‌های آلن‌کی درست از آب درآمده است(مانند پیش‌بینی‌های مارشال مک‌لوهان). آلن‌کی عقیده داشت که زیراکس با در اختیار داشتن منابع تولیدی، بازاریابی قوی و در اختیار داشتن بهترین طراحان نرم‌افزار جهان» باید سهم عمده‌ای از این بازار را به دست آورد. البته این اتفاق روی نداد.

نظر آلن کی در مورد این شکست

آلن کی می‌گوید:  آنها اهمیت موضوع را درک نمی‌کردند. البته ما هم در آماده کردن ذهن آنها خوب عمل نکردیم. حتی اگر ما کارمان را خوب هم انجام داده بودیم باز هم تاجران بیشتر شبیه مهندسان هستند تا دانشمندان. یعنی آنان عمل را بر اندیشه ترجیح می‌دهند. در حالی که در بعضی مواقع، مخصوصاً وقتی که با پدیده‌ی جدیدی روبرو هستیم باید وقت بیشتری را صرف درک آن کنیم، نه این که فقط نگران باشیم که چه کاری با آن می‌توانیم انجام دهیم. این اتفاق یکبار دیگر هم برای شرکت زیراکس در دهه‌ی پنجاه روی داده بود. در آن زمان، آرتور لیتل (شرکتی در زمینه‌ی مشاوره‌) پیش‌بینی کرده بود که در آینده هیچ‌ بازاری برای فتوکپی و کسب و کار آن وجود نخواهد داشت.» 

استیو جابز و آلن کی

گرچه زیراکس حمایت‌های مالی خود را از پروژه‌ کی قطع کرد ولی وضع در شرکت اپل به گونه‌ای دیگر بود. در سال 1979، استیو جابز، جف ارسکین و چند نفر دیگر از کارشناسان فنی اپل به سراغ آلن‌کی و همکارانش آمدند و از کارهای آنها بازدید کردند. آنها تحت تأثیر کارهایی که آلن‌کی و همکارانش انجام داده بودند قرار گرفتند ولی شگفتی آنها وقتی بیشتر شد که استیو جابز ایراداتی از ر وش نمایش اطلاعات گرفت و دان اینگا مشکل را در کمتر از یک دقیقه برطرف کرد. جابز سعی کرد که این نرم‌افزار را از زیراکس بخرد اما زیراکس، با وجودی که سرمایه‌گذاری اندکی هم در اپل کرده بود، از این کار سر باز زد. 

اسمالتاک که اکنون توسط یکی از شعبه‌های زیراکس به نام پارک پلیس به فروش می‌رسد و همین الان هم به خاطر انعطافپذیری فوق‌العاده‌اش همچنان مورد تحسین است.

گفتگو با آلن کی از زبان اندروبینستاک

در ماه ژوئن سال 2012 ، انجمن محاسبات ماشینی ACM  صدسالگی آلن تورینگ را با برگزاری کنفرانسی جشن گرفت که در آن بیش از سی برنده جایزه تورینگ سخنرانی کردند. در یکی از زمان های استراحت ، من موفق شدم تا مصاحبه ای را با آلن کی ترتیب دهم ؛ یکی از برندگان جایزه تورینگ که نوآوریهای بسیاری به وی نسبت داده می‌شود. آلن کی اعتقاد دارد که بهترین راه پیش بینی آینده ، اختراع آن است.

   -بینستاک: مصاحبه را با پرسشی در رابطه با یک داستان معروف آغاز میکنم. گفته شده که شما تا زمانی که به کلاس اول بروید، بیش ازصد کتاب خوانده بودید و این مطالعات باعث شده بود تا شما متوجه شوید که معلم ها مدام در حال دروغ گفتن به شما   هستند.

• آلن کی : بله این داستان نخستین بار در یکی از نوشته هایی مطرح شد که برای یک مجلس یاد بود نوشته شده بود.

  - بینستاک: پس شما آنجا در اول کلاس نشسته بودید و فهمیدید که معلم ها دروغ میگویند. آیا این موضوع را به دانش آموزان دیگر منتقل  کردید؟

• آلن کی : در واقع اگر شما یک دیوانه تمام عیار نبوده و از نوع  خاص خود شیفتگی رنج نبرید، عموما خود را بسیار نرمال فرض می‌کنید. بنابراین من درباره این موضوع فکر نمی‌کردم. من در کل آدم درونگرایی بودم و سعی می‌کردم سرم به کار خودم باشد. تنها موقعی ار خودم سرسختی نشان می دادم که مجبورم می‌کردند با آنها همراهی کنم.

  -بینستاک:  پس در نهایت به آنها دروغگویی شان را ثابت کردید؟

• آلن کی : بله. البته چیری که من را منقلب کرد ، چند سال بعد اتفاق افتاد. در آن زمان من یک نسخه از مجله لایف را پیدا کردم که عکس های مارگارت بورک وایت از اردوگاه بوخن والد» نازی ها در آن زمان چاپ شده بود. این موضوع به دهه 1940 در یک مزرعه و بدون دسترسی به تلویزیون. در آن لحظه  من فهمیدم که بزرگسالان چقدر می توانند خطرناک باشند، منظورم خیلی خطرناک است! من کلا آن تصویر را فراموش کردم ، اما همواره کابوس می دیدم  و فراموش کرده بودم که این تصاویر از کجا وارد ذهن من شده اند. هفت یا هشت سال بعد ، شروع کردم به وصله زدن کار های قدیمی .
  رفتم و مجله را پیدا کردم.این شاید نقطه من بود که دیدگاهم را راجع به زندگی تغییر داد. در این نقطه بود که من به آموزش و تخصیلات علاقه مند شدم . علاقه من به آموزش ، خیلی حالت خارق العاده و سحر آمیزی ندارد. من علاقه به خصوصی به کمک به کودکان ندارم، اما شیفته ساختن بزرگسالانی بهتر هستم .

هجوم اروپایی در علوم کامپیوتر 

آلن کی : شما باید با ویلیام نیومن صجبت کنید که همین جا حضور دارد. او بخشی از جنبش فرار مغزهای انگلستان بود.در میان آنها کریستوفر استراچی نیز حضور داشت که من وی را یکی از 10 دانشمند برتر تاریخ علوم کامپیوتر می دانم.آن ها همچنین پیتر لندین را داشتند.در واقع آنها پیش از ما مدیریت حافظه و time sharing   را داشتند . و ناگهان در اوایل 1960 شرایط زندگی در بریتانیا به حالت بحرانی رسید و دانشمندان جوان این کشور راه ایالات متحده را پیش گرفتند .
ویلیام یکی از افرادی بود که به معنای واقعی کلمه ، حوزه گرافیک کامپیوتری را بنا نهاد. او نخستین کتاب مشهور این حوزه را با عنوان "اصول گرافیک کامپیوتری تعاملی " به همراه رابرت اسپراول تالیف کرد . ویلیام به هارواد آمد ، تحت نظر ایوان ساترلند تحصیلات تکمیلی خود را آغاز کرد  و در سال 1965 یا 1966 دکترایش را گرفت . ویلیام سپس به دنبال ایوان به یوتا رفت و وقتی زیراکس پارک تاسیس شد ، به این موسسه تحقیقاتی آمد . 

در فرانسه نیز ، البته به دلایلی متفاوت ، اتفاق مشابهی رخ داد . بنابراین یکی از مواردی که منفعت بسیاری برای ما داشت این بود که توانستیم بریتانیای ها و فرانسوی های بسیار مستعد را  با آن فرهنگ خاص و بی محابای شان جذب کنیم . این افراد از مهم ترین بخش های پیشرفت علوم کامپیوتر در ایالات متحده بودند. به عنوان مثال ، نخستین فونت های آوت لاین توسط پاتریک بادلایر که دکترایش را در یوتا گرفته بود ، در پارک ابداع شد . سایه گذاری روی اشیاء سه بعدی به افتخار هنری گورو Henri Gouraud " گورو " نامیده شد. وی نیز در یوتا بود . دقیقا همان زمانی که ایوان نیز در یوتا بود.

پی‌‍‍‍‍‍‍‍‍‍‍‍‍‍‌نوشت: " هیچ‌گاه برنامه‌نویس خوبی نبوده‌ام" عنوان مصاحبه بینستاک با آلن‌کی بوده است

مطالب مرتبط :

چیزهایی که برنامه‌نویس‌ها باید بدانند-بازبینی کُد

چرا باید کُد را بازبینی کرد

این سوالی است است که ماتیاس کارلسون(Mattias karlsson§)، در کتاب 97Things Every Programmer Should Know،از خواننده خود پرسیده است. قبلا اینجا §درباره‌ی کتاب 97 چیزی که یک برنامه‌نویس باید بداند مطلبی را نوشته‌ام و در اینجا لازم به توضیحات اضافی نیست و یک راست می‌روم سر اصل مطلب. 

در حقیقت ماتیاس کارلسون در کتاب 97 چیزی که یک برنامه‌نویس باید بداند در صفحه 28 نمی‌گوید که چرا باید کُد را بازبینی کرد، بلکه می‌گوید، بهتر است که شما کُد را بازبینی کنید. 

"? You Should Do Code Review. Why "

حال خودش در پاسخ به  این سوال بیان می‌کند که بازبینی کُد باعث می‌شود که کیفیت کُد افزایش یابد و باعث کاهش نرخ خطا یا در حقیقت نرخ شکست نرم‌افزار می‌شود. اگر با نرخ شکست نرم‌افزار آشنا نیستید،می‌توانید به  مطلبی که در این باره§ نوشته‌ام مراجعه نمایید. 

در حقیقت بازبینی کُد در اکثر موارد باعث می‌شود کیفیت کُد ما افزایش یابد. یعنی می‌توانیم دوباره روی کُِدهای که نوشته‌ایم فکر کنیم و با خود بگوییم آیا نمی‌شود این کُدها را بهتر از اینی که هست نوشت؟ 

 بازبینی کُد چیست

برای این‌که به یک تعریف جامع و نسبتاً کامل از بازبینی کُد برسم، کتاب‌ها و سایت‌های مختلفی را مطالعه و جستجو کردم،اما هیچ‌کدام از آنها به اندازه تعریف سایت Smart Bear کامل نبودند.                                                                                                                                                                                           

Code Review, or Peer Code Review, is the act of consciously and systematically convening with one’s fellow programmers to check each other’s code for mistakes, and has been repeatedly shown to accelerate and streamline the process of software development like few other practices can.

من فقط سعی کردم که قسمتی از متن  که عمل بازبینی کُد را تعریف می‌کند، بیاورم و اینجا بنویسم. حال اگر کسی می‌خواهد به طور کامل بداند که پروسه بازبینی کُد چیست و چگونه انجام می‌شود می‌تواند به ادامه تعریف بالا در این لینک§ برود و با بازبینی کُد به طور کامل آشنا شود. 

در این مطلب نمی‌خواهم به بررسی عمل بازبینی کُد و تعریف آن بپردازم. چون هرکسی تا حدودی که برنامه‌نویسی کرده باشد و در یک تیم کار کرده باشد، می‌داند که بازبینی کُد چیست و دقیق‌تر اگر بگویم، باید بگویم که بازبینی کُد بیشتر در تیم‌های برنامه‌نویسی انجام می‌گیرد نه در انفرادی و کار کردن با خود. 

چون بازبینی کُد زمانی موثر است که شما درون یک سیستم یا تیم باشید و بتوانید اثرات مخرب و مفید کارهای دیگران را نیز بر روی کار و کُدهای خودتان حس کنید. البته بازبینی کُد عملی است که انفرادی انجام می‌گیرد اما باید درون تیم یا یک سیستم باشد تا معنا پیدا کند. یعنی اینگونه نیست که با خود بگویید به‌به عجب کُدی نوشته‌ام و اعتماد به نفسی کاذب را در درون خودتان ایجاد کنید. 

باید کُدی را که نوشته‌اید در درون یک سیستم و در ارتباط با دیگر قسمت‌های سیستم به مرحله آزمایش(تست) بگذارید تا مشخص شود که عیب و ایرادهای کُد شما چیست و باید کدام قسمت‌های کُد را اصلاح نموده و در بعضی مواقع باید کُدهایی را حذف یا اضافه کنید. هر چند ممکن است پیش خودتان حس کنید که بهترین کُد را نوشته‌اید، اما تا زمانی که در بوته‌ی آزمایش سیستمی(سازمانی) که قرار است برای آن برنامه بنویسید، گذاشته نشود، کیفیت کُد شما مشخص نخواهد شد و عمل بازبینی کُد معنایی نخواهد داشت. 

بازبینی سیستمی کُد 

ماتیاس کارلسون در ادامه به بحث بازبینی کُد به این مطلب اشاره می‌کند که اکثر کسانی که بازبینی کُد انجام می‌دهند، حال خوشی از انجام این‌کار نصیب‌شان نمی‌شود. چون در بیشتر مواقع با مشکلاتی دست و پنجه نرم کرده‌اند که منشاء آنها کسی یا چیزی دیگری بوده که خارج از کنترل خود شخص برنامه‌نویس بوده‌است. 

خب راه حل این مشکل چیست و چگونه می‌توان حال خوشی را نصیب کسانی کرد که بازبینی کُد انجام می‌دهند. از نظر ماتیاس کارلسون که بگذریم و اگر بخواهم از تجربیات خودم استفاده کنم، مشکل را در معماری سیستم یا کسی که سیستم را تعریف کرده است دیده می‌شود. اگر یک سیستم و اجزا و روابط آن به طور صحیحی ترسیم و درک و طراحی شوند، کمتر کسی با مشکل مواجه خواهد شد. 

به نظرم این وظیفه معمار سیستم است که باید مشخص کند کِی و کجا و چه کسانی باید بازبینی کُد انجام دهند. حال می‌خواهم نظر ماتیاس کارلسون را هم در ادامه بیاورم تا بتوانیم به یک توصیف کامل‌تر و جهان‌بینانه‌تری برسیم. 

توصیف ماتیاس کارلسون از این مشکل و شکایتی که برنامه‌نویس‌ها باید انجام بدهند :

I have seen organizations that require that all code pass a formal review before being deployed to production. Often, it is the architect or a lead developer doing this review, a practice that can be described as architect reviews everything. This is stated in the company’s software development process manual, so the programmers must comply.

چه زمانی نیاز به بازبینی کُد وجود دارد 

سازمان‌های بسیاری هستند که می‌خواهیم برای آن‌ها برنامه بنویسم. اما اکثر آن‌ها یا بازبینی کُد را لازم نمی‌بینند یا نمی‌خواهند که هزینه این کار را پرداخت کنند. مواقعی هستند که ما یک برنامه را می‌خواهیم برای یک شخص یا سازمان بنویسیم که فقط برایش کار کند کافی است. یعنی نه لازم می‌بینیم که به نگهداری این نرم‌افزار بپردازیم و نه طرف مقابل هزینه‌ای برای این‌کار پرداخت خواهد کرد. 

اما بحث ما نرم‌افزارها یا سیستم‌هایی است که قرار است Sustain  یا Maintain شوند. یعنی قرار است این سیستم چند سال کار کند و در طول این چند سال هم ممکن است که با تغییراتی مواجه شود و برای انجام آن تغییرات هم، ما(یعنی شرکت یا تیمی که در آن کار می‌کنیم) را مسئول می‌دانند و هزینه‌ی آن را نیز پرداخت خواهد کرد. 

البته اکثر شرکت‌های نرم‌افزاری موفق در جهان 80 تا 90 درصد درآمدهای خود را از طریق Sustain  یا Maintain بدست می‌آورند. خب اینجاست که بازینی کُد و مسائل آن مطرح می‌شود. در این مواقع باید پایداری و نگه‌داری سیستم(نرم‌افزار) را در نظر داشته باشیم و این کار باید در ابتدا توسط معمار سیستم یا معمار نرم‌افزار انجام شود و مشخص کند که مسئول بازبینی کُدِ کدام یک از قسمت‌ها یا بخش‌های نرم‌افزار به عهده اوست و همزمان تعیین کند که برای بررسی و بازبینی کُدِ سایرِ قسمت‌هایِ نرم‌افزار  چه کسانی مسئول هستند. 

اگر این‌کار در ابتدای طراحی سیستم انجام نگیرد و معمار سیستم(نرم‌افزار) بیخیال آن شود، در زمان استقرار نرم‌افزار یا  Deploy کردن آن باید تاوان سنگینی را بپردازد. بعضی اوقات باعث می‌شود که کل یک قسمت یا سازمان را دوباره طراحی کرد. 

هدف بازبینی کُد

هدف بازبینی کُد همان تصحیح کُدهای مشکل‌دار است. یعنی کُدهایی که باعث می‌شود یک قسمت از نرم‌افزار با سایر قسمت‌های هم‌خوانی و هماهنگی نداشته باشد. به عبارتی Integrity و  Synchronization نداشته باشد. اما بازبینی کُد فقط تصحیح کُدهای مشکل‌دار نیست، بلکه هدف بازبینی کُد به اشتراک‌گذاری دانش می‌باشد. یعنی بهتر است که این‌گونه باشد. 

اشتراک‌گذاری دانش یعنی به اشتراک‌گذاری همان کُدی که نوشته‌ایم. چون به نظرم هرکسی به اندازه‌ی دانش‌اش می‌تواند کُد بزند و هیچ  چیزی مثل کُدی که نوشته است دانش او را به نمایش نمی‌گذارد. 

اشتباه متوجه منظور من نشوید. منظور من جنگ و دعوا نیست. این‌که چه کسی کُد بهتری نوشته است و چه کسی کُد ضعیف‌تری نوشته است. بلکه وقتی در یک تیم کار می‌کنیم باید این مسئولیت را در نظر بگیریم که خطایی در کُد من ممکن است زحمات کسی دیگر را تباه کند. پس بهتر است که کُدهای خود را با دیگران به اشتراک بگذاریم. اما اینجا یک بحث پیش‌ می‌آید. مالکیت کُد. 

مالیکت کُد

مالکیت کُد یعنی این‌که هر کسی مسئول کُد خود است و باید مسئولیت خطای خود را نیز بر عهده بگیرد. اما اجازه می‌دهد که سایرین بدون هیچ زمینه‌ای و بدون هیچ سوءگیری‌ای کُد او را بخوانند و بتوانند از او یاد بگیرند و هماهنگی خود را با او بیشتر و بهتر نمایند.

ماتیاس کارلسون درباره‌ی مالکیت کُد نظر خود را اینگونه بیان می‌کند و اظهار می‌کند که بهتر است بدین طریق بازبینی کُد انجام گیرد:                                      

Sharing your code with other programmers enables collective code ownership. Let a random team member walk through the code with the rest of the team. Instead of looking for errors, you should review the code by trying to learn and understand it.

ماتیاس کارلسون بحث مالیکت جعمی را به میان می‌آورد. به بیان ساده اگر بخواهم منظور او را بیان کنم، می‌توانم این‌گونه بگویم که: همه ما یک سیستم هستیم و باید با یکدیگر، جدای از عنوان شغلی که داریم، همکاری و هماهنگی داشته باشیم و از دانش یکدیگر جهت بهتر کردن کیفیت کارکرد سیستم(نرم‌افزار) استفاده کنیم.

اگر بازبینی کُد بدین طریق انجام گیرد، احتمال این‌که اعضای تیم باهم ارتباطات بهتر داشته باشند و بتوانند حال خوش یا Fun را تجربه کنند، بیشتر خواهد شد. 

توصیه‌هایی برای بهتر کردن پروسه بازبینی کُد 

در پاراگراف آخر ماتیاس کارلسون توصیه‌های دارد که خیلی زیباست.                                                                                                                            

 1) به صورت تفریح (Fun) درآوردن عمل بازبینی کُد شاید بهترین و مهمترین دستاورد در یک تیم نرم‌افزاری در جهت موفقیت باشد. 

2)بازبینی کُد، بازبینی افراد است. اگر جلسه بازبینی کُد رنج‌آور یا کسل کننده است، سخت می‌شود افراد را تشویق به پروسه بازبینی کُد کرد. 

3) جلسه بازبینی کُد را به صورت یک جلسه دوستانه و غیر رسمی اجرا کنید. این‌گونه افراد با انگیزه بیشتری به اشتراک کُد و دانش خود متمایل می‌شوند. 

همخوانی توصیه‌های کارلسون با  آیین پیروزی جک ولش 

چند روز پیش که ویدئویی از جک ولش دیدم که داشت در ارتباط با آیین پیروزی صحبت می‌کرد. بعد از مطالعه صحبت‌ها و توصیه‌های ماتیاس کارلسون، ارتباط عجیبی با صحبت‌های جک ولش مشاهده و حس کردم . ویدئوی زیر را ببیند به طور کل منظور متوجه من خواهید شد. 

عنوان بحثی که جک ولش در آن به سخنرانی می‌پردازد اینست : 

Drive Business Growth by Building the Right Team

مدت زمان: 2 دقیقه 5 ثانیه

پی نوشت :  

هر چه‌قدر گشتم، نتوانستم زیرنویسی برای این فیلم پیدا کنم. به همین خاطر خودم دست ‌به‌کار شدم و شروع کردم به ترنسکریپت کردن صدای جک ولش. 

اگر متوجه عیب و ایرادی در متن شدید، به من اطلاع دهید تا اصلاح کنم. 

(Drive Business Growth by Building the Right Team(Jacnk Welch-Subtitle 

in the end do you have a right successors line lined up do you have the team that's going support that successor,
see , i think the business is not about strategy, that's follow great team, i don't think about next year's budget , i think about the best people on the field.
i live that every day, i'm evaluating people in every meeting, every meeting of personnel meeting.
might be budget review ? No it's a personal review. you want to.
don't kid yourself that's what it is .
you're assessing people all the time and the heat is on for them to get better and better and better , and if you driving that if you not fully in love with some chrony that you got there.
if you falling in love with somebody's relative or something else , you better off . because you're always trying to get winning team , you're always trying to be whether it be forty youngies or this is not football team , Green Bay Packers or wheather you want to pitch but ,you want to be a winner and you are relentless in building that team.
and if you've got a team , that team sustain you generation after generation. a culture of fairness , a culture you can define that culture those behave as you want, you get those and you get a great team , man you can't be beat.
you'll think they'll figure out the changes send some people over the always ask me : this is changing , that's changing , well if you right players , they'll love the change , those every time as a change ,it's an opportunity. must people suck that summer when the change comes , kill those people .
know you want. , how can i change it , how can i leverage that new reg. how can i leverge that new standard. that you want to keep winning.

مطالب مرتبط:

آلن کی: هیچ‌گاه برنامه‌نویس خوبی نبوده‌ام

چیزهای که یک  برنامه نویس  باید بدانند