رسالة إلى كل مهندس برمجيات جديد، عن الأشياء التي لم يخبرني بها أحد في عقدي الأول. لا نصائح عامة — عادات محدّدة تتراكم، مع شواهد من خمسة عشر عاماً من الشحن الفعلي الذي سبق هذه الكتابة. لو أمكنني أن أرجع وأسلّمها لنفسي وعمري 22 سنة أبدأ عملي في مشروع HAKEEM للسجل الصحي الوطني في عمّان، كنتُ سأفعل.
أولاً: اقرأ الكود قبل أن تكتبه
أعلى عادة بالنسبة للمردود في عقدك الأول هي قراءة كود لم تكتبه أنت، في codebase إنتاجي، بنيّة حقيقية. لا مجرّد تصفّح. قراءة فعلية — ملفاً ملفاً، دالةً دالةً، مع سؤال “لماذا هذا هنا؟” عند كل تفرّع.
كل مهندس كبير أحترمه عنده نسخة من هذه العادة. يبدو الأمر واضحاً. إلا أنه أول شيء يتخطّاه المهندسون الجدد، لأن القراءة تبدو أقل إنتاجاً من الكتابة. الواقع عكس ذلك. الكتابة دون قراءة ستجعلك تعيد اختراع دوال موجودة في codebase، وتبتكر abstractions تتعارض مع ما هو قائم، وتقترح تصاميم تنتهك قيوداً كتّابها الأصليون أدمجوها في شكل الكود ذاته.
خصّص أسبوعاً كاملاً، في شهرك الأول في أي codebase جديد، للقراءة فحسب. مديرك سيظن أنك لا تنتج. بعد ثلاثة أشهر، ستكون مخرجاتك أفضل بشكل لافت من أقرانك الذين تخطّوا هذه الخطوة. هذا الفائدة المركّبة.
ثانياً: دوّن ما تتعلّمه
كل codebase يحتوي على invariants غير موثّقة. كل فريق عنده تقاليد تعيش في رؤوس ثلاثة أشخاص. كل نظام إنتاجي فيه حواف غريبة تعلّمها الناس على الصعب خلال الحوادث.
دوّنها حين تجدها. لا في ملف خاص — في المخزن المعرفي المشترك (docs المستودع، wiki الفريق، README الموديول الخاص). الكتابة تُجبرك على صياغة ما تعلّمته، وهذا يكشف الأشياء التي لم تفهمها فعلاً. يعني أيضاً أن الشخص التالي يستطيع أن يتخطّى الأسبوع الذي أمضيته للتوّ.
سأقول الجزء المزهوّ: تبني سمعة كمهندس مفيد أسرع بالتوثيق منه بالشحن. اشحن ووثّق وأنت تبني مسيرة. اشحن بدون توثيق وأنت فقط تُنجز تذاكر.
ثالثاً: قاعدة الساعة الواحدة للأسئلة
إن عُلّقت لساعة، اسأل. ليس ثلاث ساعات. ساعة واحدة.
كل مهندس كبير مرّ بهذا: حدّقت في الشاشة نصف يوم، لم تتقدّم، ثم قضى شخص ما 30 ثانية في الإجابة على سؤالك. ذاك النصف يوم ضاع. لم تتعلّم شيئاً لم يكن سؤال دقيق يعلّمك إيّاه. لم تُنتج شيئاً في ذلك النصف يوم أيضاً، مما يعني أن الفريق دفع ثمن صمتك.
الحجة المضادة: “أريد أن أحاول أكثر أولاً.” هذا الحدس صحيح، لكن المعايرة خاطئة في الغالب. ساعة. ثم اسأل. إن كنت تخجل من السؤال، اسأل على أي حال. الخجل ضريبة سمعة أصغر بكثير من ضريبة مهندس جديد يختفي لنصف يوم في كل مرة.
رابعاً: حين تُصحّح أخطاء، اسرد قصة
حين تُصحّح خطأً معقّداً، قل بصوت عالٍ (أو في ملف scratch طرفية، أو في قناة Slack مخصصة للتجارب) ما تفكّر فيه. “أعتقد أن X يحدث بسبب Y. إن كان كذلك، Z يجب أن يكون ملاحَظاً. دعني أتحقّق من Z. غريب، Z غير ملاحَظ. إذن X ليس بسبب Y. ما الذي قد يسبب X إذن؟”
هذا ليس للاستعراض. هذا كيف تتجنّب الدوران في حلقات. نسخة التصحيح المسرودة تكشف افتراضات كنت ستفعلها بصمت. لها أيضاً أثر جانبي: تحوّل تصحيحك إلى قصة ما بعد الحادثة التي تستطيع روايتها للآخرين، وهذا ذو قيمة هائلة للفريق.
خامساً: الاختبار أرخص من الخطأ الذي سيمسكه
كل مهندس جديد ذهبتُ معه للإرشاد عنده نفس إغراء السنة الأولى: تخطّى الاختبار “لأنني متأكد أن هذا يعمل.” الحقيقة الصريحة: لست متأكداً قط. لا أحد كذلك. الاختبار هو الدليل على أن الشيء يعمل. بدون الاختبار، “يعمل” مجرّد شعور، والشعور لا ينجو من المهندس التالي الذي يُعدّل تلك الدالة.
اكتب الاختبار. خاصةً لحالات الحواف. خاصةً لحالات الـhappy path “الواضحة” التي “تعمل بشكل جليّ.” الاختبارات التي تتخطّاها هي الاختبارات التي تمسك الأخطاء التي تشحنها.
سادساً: افعل العمل غير المُغري عن قصد
كل فريق عنده عمل لا يريده أحد: تحديث اختبار متقلّب، توثيق موديول محيّر، إعادة كتابة سكريبت هش، امتلاك قالب تسليم الاستعداد (on-call). تطوّع لفعله.
ثلاثة أسباب:
- تتعلّم النظام بطريقة عمل الميزات لا يعلّمك إيّاها.
- تبني السمعة المحدّدة للمهندس الكبير بوصفك شخصاً يُقلّل الفوضى. هذا يساوي أكثر من أي ميزة منفردة.
- المهندسون الكبار نادرون. كل فريق يحتاجهم. بناء دليل مرئي على أنك أحدهم هو أسرع طريق ليُعامَل بك معاملتهم.
سابعاً: مديرك الأول نقطة بيانات، لا معيار
إن كان مديرك الأول رائعاً، أجله — واعترف أنه استثناء. إن كان مديرك الأول سيئاً، فذلك ليس معياراً على المديرين عموماً. معظم المهندسين الكبار الذين أعرفهم مرّوا بالطيف كاملاً.
النتيجة العملية: لا تتخذ قرارات مسيرة طويلة الأمد بناءً على رأي مديرك الأول فيك. ذاك الرأي وجهة نظر شخص واحد، وذاك الشخص على الأرجح لم يتدرّب على الإدارة أيضاً.
وأيضاً: حين يعطيك مديرك الأول نصيحة تبدو خاطئة، اسأل “خاطئة كيف؟” بدلاً من رفضها أو قبولها. معظم نصائح المدير الأول نسخة مشوّهة من شيء مفيد حقاً. افككها معه. كثيراً ما يتعلّم هو أيضاً شيئاً من التفكيك.
ثامناً: محفظة المصدر المفتوح هي الطريق السريع الخفي
كل مهندس أعرفه انتهى في دور يحبّه كان له جسد عمل مرئي. ليس بالضرورة مشروعاً شهيراً — مرئي. مجموعة مساهمات OSS، أداة صغيرة كتبها ووثّقها، سلسلة منشورات، حديث في مؤتمر. شيء يجعل مدير التوظيف حين يبحث عنك يجد صورة متسقة تقول “هذا شكل تفكير هذا المهندس.”
قد تكون مهندساً ممتازاً دون أي من ذلك. ستحصل على فرص أقل. في كل مرحلة، امتلاك محفظة أرخص من عدمها. ابدأ واحدة. لا يجب أن تكون أمراً كبيراً. اشحن أداة صغيرة. اكتب ثلاث منشورات. ساهم في شيء تستخدمه.
أنا الحالي وأنا أشحن هذا الموقع الذي تقرأه هو، جزئياً، إعادة التزام بتلك النصيحة بالضبط. تكاسلت عنها لبضع سنوات. أُصلح ذلك الآن.
تاسعاً: المهارة المتراكمة هي الوضوح
ليس الذكاء. ليس السرعة. ليس العمق. الوضوح.
القدرة على شرح قرار في جملة واحدة. القدرة على كتابة رسالة commit تصف السبب. القدرة على ترك codebase يعرف فيه المهندس التالي ما يجري. القدرة على إخبار مدير المنتج أن الميزة ستأخذ ثلاثة أسابيع لا ستة، وإظهار السبب بالضبط.
كل شيء آخر ستتعلّمه في الطريق. الوضوح يتراكم، والمهندسون الذين يبنونه مبكّراً عندهم ميزة مركّبة على من لا يفعلون.
عاشراً (الهادئ): كن مريباً تجاه حماسك الخاص
أغلى الأخطاء التي شاهدتها — وارتكبتُها — تأتي من الإثارة بحل قبل أن تُفهَم المشكلة جيداً. “دعنا نُعيد كتابة هذا.” “دعنا نستخدم هذا الإطار الجديد.” “دعنا نقسّمه إلى services.” الإثارة إشارة، لكنها ليست دالة قرار. حين تلاحظ إثارة تجاه اختيار تقني، انتظر أسبوعاً. اكتب الخطة. نم عليها. اطلب من شخص أقل إثارة منك أن يفتّش عنها.
إن نجت الإثارة من الأسبوع، فهي حقيقية.
إن لم تنجُ، وفّرت على نفسك أشهراً.
هذا هو. هذه الرسالة. ليست كاملة، لكنها صادقة، وهي ما كنت أتمنّى أن يسلّمه لي شخص ما حين كان عمري 22. إن كنت تبدأ وظيفتك الأولى وأحدهم أشار عليك بهذا، يسعدني ذلك، وأتمنّى أن جزءاً منه يوفّر عليك وقتاً.