متى أدركت أن العمل في التقنية لا يفتح أي أفق؟

المقال #BCGame @bcgame الراعي الحصري

الكثير من الأصدقاء الجدد الذين دخلوا المجال، بما في ذلك أنا في السابق، يؤمنون بمبدأ ثابت: طالما أن تقنيتي قوية بما يكفي، فلن أُستبدل.

لذا نعمل بجد. نتعلم Java، وGo، وRust، ندرس الكود المصدري، نحل الخوارزميات، نعمل على الخدمات المصغرة، ونستخدم السحابة الأصلية. اليوم لا زلنا نعبث بـSpring Cloud، وغداً ندرس Service Mesh، وبعد غدٍ، مع انتشار نماذج الذكاء الاصطناعي الكبيرة، نسرع لتعلم Prompt Engineering.

نعتقد أن هذا هو الطموح، لكنه في الحقيقة مجرد تآكل في السيبرانية.

تظن أنك تبني حواجز تقنية، لكنك في الواقع تساعد صاحب العمل على التحقق من جدوى التقنيات الجديدة.

في صناعة الإنترنت، سرعة تآكل التقنية أسرع من انخفاض أسعار العقارات التي تشتريها. قد تتعب من دراسة إطار عمل استغرقت ثلاث سنوات، وفجأة يطلق Google أو Facebook إصداراً جديداً، أو يغير مفهوم الهيكلية، وتتحول مهارتك الفريدة في القضاء على التنانين إلى ورق مهمل في لحظة.

لكن هذا لا يعني أن التعلم بلا فائدة، بل ربما يكون اتجاهك خاطئاً. بدلاً من السعي وراء الأطر التي تصبح قديمة خلال ثلاث سنوات، من الأفضل أن تتعمق في المنطق الأساسي الذي لن يتغير خلال عشر سنوات. على سبيل المثال، عندما تكون لا تزال تتردد بين استخدام Spring Cloud أو K8s، يفكر الخبراء الحقيقيون في اتساق البيانات في الأنظمة الموزعة. إذا أردت الخروج من دائرة الأطر، أنصحك بقراءة الكتاب الذي يُعتبر الإنجيل للBackend: 《تصميم أنظمة التطبيقات ذات الكثافة البياناتية》 (DDIA النسخة المقرؤة). يتحدث عن جوهر الأنظمة الموزعة، وقواعد البيانات، وتصميم الأنظمة. فهم هذه الأمور يمنحك القدرة على رؤية ما وراء الأطر الشائعة، مهما كانت غداً.

هل تتذكر تلك المجموعة من الإخوة الذين كانوا يعملون على Flash؟ أو أولئك الخبراء الذين برعوا في نظام Symbian؟

هل هم غير مجتهدين؟ هل هم غير أذكياء؟

عندما تتخلى عنك الأزمان، حتى كلمة وداع لن تقولها.

الأمر الأكثر رعباً هو أن قدرتنا على التعلم السريع، التي نفخر بها، هي في الواقع من أكثر خصائص الاستهلاك التي تفضّلها رأس المال.

لأنك تتعلم بسرعة، فإنك رخيص الثمن.

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

وفي هذه الحالة، قد تقول: لدي خبرة، أستطيع تجنب الأخطاء.

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

بالنسبة لصاحب العمل، المهم أن يعمل النظام.

كودك الأنيق، ونمط تصميمك، وفكرتك المعمارية، كلها أقل أهمية في نظر صاحب العمل من ذلك الشخص الذي يستطيع أن يشرب معه الخمر، ويعد له خططاً كبيرة، ويجعل عروض PPT تتلألأ.

هذه هي ظاهرة "العملات الرديئة تطرد الجيدة".

عندما تكتشف أن الشفرة الأساسية التي قضيت نصف شهر في دراستها، لا تساوي شيئاً مقارنة مع ذلك المهندس في الفريق المجاور الذي يصرخ يومياً بـ"تمكين، وأداة، ودائرة مغلقة، وحجم الحبيبات"، عندها يجب أن تستيقظ.

أكبر مأساة للمبرمجين هي أننا دائماً بعيدون عن المال.

نحن قوة إنتاج، لكننا لسنا من يتحكم في علاقات الإنتاج.

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

لماذا؟

لأن في المنطق التجاري، التقنية مجرد أداة.

مثل بناء منزل، أنت ذلك الشخص الذي ينقل الطوب ويضع الجدران. الجدران مستقيمة، والطوب يُنقل بسرعة، لكن من يربح في النهاية هو المطور العقاري، وموظفة المبيعات، وحتى جماعة المضاربين، وأنت لست إلا عامل الطوب.

وعلاوة على ذلك، غالباً ما تكون التقنية هي من يتحمل اللوم.

عندما يتعطل النظام، أنت من يتحمل المسؤولية. إذا تأخرت في الإطلاق، أنت من يتحمل المسؤولية. إذا كانت هناك أخطاء كثيرة، أنت من يتحمل المسؤولية.

لكن ماذا لو لم ينجح العمل؟

مدير المنتج قد يقول: أريد أن أنجح، لكن التقنية لا تدعني، لا يمكن تنفيذ هذه الميزة، الجدول الزمني طويل جداً.

انظر، كم هو مغلق تماماً.