المعاناة في العمل ليست ضرورية

شاهدت في اليوم الآخر أداء كيت غريغوري في مؤتمر باسيفيك ++ 2018.


كيت مبرمج جيد ومتحدث عظيم. التقرير نفسه يثير الكثير من الأشياء المثيرة للاهتمام حول برمجة C ++ والبرمجة بشكل عام (تستحق نظرة). لكن الأهم من ذلك كله أنني كنت مدمنًا من قبل أحدهم (حرفيا في المرور) يعتقد أنها عبرت. تمكنت كيت باختصار شديد وفي حالة تحديد دوافع المبرمجين. بدت مثل هذا: "المبرمج ، أثناء العمل ، يسعى لتعظيم سعادته". يبدو مبتذلًا ، ولكنه في الحقيقة كذلك.

يمكننا القول أننا ندعم المشروع والعميل والشركة والإنسانية والسلام العالمي (وقد يكون هذا صحيحًا). لكن لنكن صادقين. نحن أناس ، ومثل جميع الناس ، أولاً وقبل كل شيء ، نسعى جاهدين لتحقيق أقصى قدر من السعادة - عالميًا طوال حياتنا ، واستراتيجيًا في وظائفنا ، وتكتيكيًا في المشروع الحالي ، والتافه هنا والآن ، عند كتابة هذه الوظيفة ، هذا السطر من التعليمات البرمجية. نعم ، نحن نقوم بذلك وسيكون من الجيد معرفة ما يجعلنا أكثر سعادة وما يجعلنا أقل. سيسمح لنا هذا بفهم زملائنا ومرؤوسينا وأنفسنا بشكل أفضل.

أريد أن أقوم على الفور بوضع قضايا الأجور وظروف العمل والرؤساء والموظفين وغيرهم. إذا كنت تعمل في مكان عملك ، فإن كل هذا يناسبك تقريبًا. دعونا نركز على ما يجعلنا سعداء وغير سعداء عند العمل مباشرة على الشفرة.

الاختبارات

جميع المشاريع ذات الاختبارات سعيدة بنفس القدر ، كل مشروع بدون اختبارات غير سعيد بطريقته الخاصة. يمكنني القول بثقة أن المبرمجين في المشاريع ذات التغطية الاختبارية الجيدة هم في المتوسط ​​أكثر سعادة من المشاريع التي لا تخضع للاختبارات بشكل عام. حتى أنني رأيت كيف أن المبرمجين ، الذين لم يوافق رؤسائهم معهم على كتابة اختبارات كاملة ، كتبوها سراً (أحيانًا حتى بعد ساعات). لماذا حدث هذا؟ الاختبار المكتوب يجعل المبرمج أكثر سعادة. وجودها في حد ذاته علامة بالفعل على أن شيئًا على الأقل في مشروعك يتم تنفيذه وفقًا لأفضل ممارسات الصناعة (حتى لو لم يكن الباقي). يظهر اختبار مكتمل بنجاح علامة اختيار خضراء جميلة ، ويثني على المبرمج (وبعد كل شيء ، ربما لن يثني عليه أي شخص آخر). يوفر الإنجاز الناجح لـ 100٪ من الاختبارات نوعًا من الأرضية المستقرة تحت قدميك ، عندما يمكنك بالفعل أن تؤمن بشيء - وهذا يضيف إلى ثقتنا اليوم وغدًا ، يجعلنا أكثر سعادة. وحتى الاختبار الفاشل يؤدي وظيفته - يخبرنا أننا كتبناه لسبب وجيه ، حيث نثني على بصيرتنا. إذا كنت ترغب في جعل المبرمج أكثر سعادة ، دعه (أو حتى يجبره على القوة) كتابة الاختبارات (بالطبع ، كل شيء جيد في الاعتدال).

تصحيح الأخطاء وتطوير وظائف جديدة

"لن أخبركم عن أوديسا بأكملها" ، لكن معظم المبرمجين الذين قابلتهم في حياتي كانوا أكثر ميلًا لكتابة وظائف جديدة من إصلاح رمز legac. لماذا؟ ولكن لأن لمس الخلل يمس مصيبة شخص آخر. حدث خطأ ما لشخص ما وكان من المهم للغاية أنه لم يكن كسولًا للغاية لدرجة أنه لم يثر حزنه على المطور. يجب أن يذهب إلى منصبه ، في محاولة للتكاثر. ثم بعد ذلك ، إما أنها ستنجح في التكاثر - وستكون هناك ضربة لتقدير الذات بسبب خطأ مقبول ، أو لن ينجح وسيكون من الضروري (يا إلهي ، لا!) الاتصال بشخص حي اكتشف المشكلة ومحاولة الحصول على مزيد من المعلومات. كل هذا لا يمكن أن يسمى لطيفا.

في الوقت نفسه ، تعد كتابة وظيفة جديدة لمسة محتملة من السعادة. لم نكسر أي شيء حتى الآن ، ليس ذنبنا. نحن نكتب كود جديد لحل مشاكل جديدة. ربما ستنجح. ربما نتلقى الثناء الذي يستحقه (المكافأة ، الترقية). هذا أقرب بالفعل إلى المستويات العليا من هرم الاحتياجات البشرية وفقًا لماسلو .

ما هو الاستنتاج؟ يجب أن يكون عمل المبرمج متوازنًا ، ويجب ألا يحتوي على إصلاح خطأ واحد. يحتاج كل مبرمج أن يعهد إلى تطوير ميزات جديدة من وقت لآخر. نعم ، ليس هناك مفر من تصحيح الأخطاء ، ولكن يمكننا على الأقل محاولة تحقيق توازن "صفر تقريبًا" من السعادة وعدم الرضا في هذا الأمر.

إعادة بيع

العمل مع كود جيد أمر جيد. لسوء الحظ ، لا يسقط رمز جيد من السماء. حتى أنه من المستحيل أخذها وكتابتها في المرة الأولى. علينا أن نجعل رمزًا جيدًا من السيء ، لأنه لا يوجد شيء آخر نفعله منه. هنا ، يقوم المبرمجون باختيار: كل يوم ، عندما يأتون للعمل ، يستمرون في المعاناة ويعملون مع كود سيئ ، أو لا يزالون يأخذون ويحاولون صنع كود جيد منه. في الحالة الثانية ، غالبًا ما يتعين عليك القتال مع قيادة لا تفهم ما يمكن أن تقضيه ساعات N هذه من الوقت إذا لم تتم إضافة ميزات جديدة إلى المنتج ولم يتم أيضًا إصلاح الأخطاء القديمة. نعم ، عليك أن تقاتل. لحسن الحظ ، لدينا في هذه الحرب حجج: الشفرة الموجزة والجميلة أقل عرضة للخطأ ، ودعمها يستغرق وقتًا أقل (ويكلف أموالًا أقل) ، ويجعلها أفضل للتغيير عندما تظهر متطلبات العمل الجديدة ، إلخ. بالإضافة إلى ذلك ، هذه الحرب ، كقاعدة عامة ، ليست طويلة: تنتهي بنوع من الحل الوسط مثل "لا ، لن أعطي شهر لإعادة البناء ، لكن دعنا نخصصها ساعتين في الأسبوع أيام الجمعة". حسنًا ، هذا جيد. لقد حصلنا على أنفسنا قطعة من السعادة. نعم ، ستظل بحاجة إلى البناء بيديك ، لكن هذا أصبح ممكنًا بالفعل.

استخدام المكتبات والأدوات الحديثة

ربما يعرف الكثير ألم الاضطرار إلى العمل في مشروع عالق لسبب ما في مترجم (إطار ، مكتبة) منذ سنوات عديدة. يشرحون لنا أنه لهذه الأسباب ولهذه الأسباب ، من المستحيل الترقية إلى الإصدار الجديد هنا والآن ، ولكن في يوم من الأيام ، على الأرجح ، إذا نجحت ... ماذا يمكنك أن تفعل؟ حسنًا ، أولاً ، يجب أن نعترف لأنفسنا بأن الظروف ليست في صالحنا وأن الوضع يجعلنا أكثر سعادة مما يمكن أن نكون. ثانيًا ، يمكن التعبير عن نفس الفكرة من قبل السلطات (أو العميل). من غير المحتمل أن يجادل أي شخص في هذا الأمر. وفي هذه اللحظة ، يمكنك محاولة المساومة لنفسك: على سبيل المثال ، وقت الاختبارات نفسها ، والوظائف الجديدة وإعادة البناء. (يمكنك زيادة الراتب ، لكن في بداية المقال ، وعدت بتركه خارج الصورة.)

بالمناسبة ، فإن الوقت الذي تقضيه في مثل هذه المهام المفيدة لا يمكن أن يجعلك أكثر سعادة هنا والآن فحسب ، بل يقضي أيضًا على الأسباب "المخيفة" التي تجعل من المستحيل التبديل إلى استخدام أدوات أحدث. الوضع الحقيقي من حياتي:

- لسنا متأكدين من أن الانتقال إلى مكتبة جديدة لن يجلب لنا مشاكل جديدة ...
- وهنا كتبت 200 اختبار للرمز باستخدام هذه المكتبة ، فلنحاول اجتيازها وسنطلقها.
- هيا ، هيا.

بعد أسبوعين - مكتبة جديدة في الإنتاج.

ربما يمكنك الاستمرار في استكشاف جوانب أخرى. لكن الفكرة العامة هي نفسها: بعض المهام والظروف تجعل المبرمج أكثر سعادة ، والبعض الآخر - أكثر سعادة. إذا كان هناك أكثر من الثانية - ستنخفض الحالة المزاجية والإنتاجية للمبرمج ، عاجلاً أم آجلاً سيؤدي هذا إلى مشاكل في المشروع أو إلى رحيله عن الفريق. لذلك ، يجب على كل من المبرمج ومديره التفكير ليس فقط في "الصالح العام" للمشروع أو الشركة أو المستخدم ، ولكن أيضًا كيفية البقاء سعيدًا نسبيًا مع المطور. وإلا ما هي الفائدة؟