من مشرف شبكة صالة ألعاب إلى مهندس معماري

قبل أن أصبح مهندساً معمارياً للبرمجيات، كنت الشخص الذي يُصلح الشبكة في صالة ألعاب إلكترونية في عمّان. وقبل ذلك، كنت بائعاً وكاشيراً في محل كمبيوتر. كان عمري 17 حين بدأت، و22 حين غادرت ذلك العالم لإتمام درجتي في نظم المعلومات والبدء ببناء البرمجيات مهنياً.

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

Explosion Network Gaming Centre، 2007–2009

المسمى الوظيفي كان مشرف شبكات ومدير. في الواقع: كنت أُشغّل الشبكة، وأتعامل مع المال، وأدير الأجهزة، وأتعامل مع العملاء، وأحياناً أحظر لاعبين على الغش في Counter-Strike.

نعم، كنت الشخص الذي يحظر لاعبين على الغش في Counter-Strike. لا أندم على شيء.

الشبكة كانت LAN مادية - كابلات وسويتشات وDHCP وراوتر لمزود الإنترنت وحوالي 30 جهاز Windows XP يُستخدم بشدة، باستمرار، من مراهقين لا يملكون أي تعاطف مع نوافذ وقت التوقف. حين ينكسر شيء، كان يجب إصلاحه الآن. ليس “سنعالجه في الـsprint القادم.” ليس “دعني أفتح تذكرة.” الآن. الشخص عند المكتب ينتظر، العداد يدور (كنا نحسب بالساعة)، وكنت أنا فريق العمليات بأكمله.

هذا الضغط ليس مُجهداً بالطريقة التي يكون فيها الـon-call في شركة تقنية. إنه أبسط وأكثر فورية: إنسان حقيقي يقف أمامك، يخسر المال لأن الجهاز في المحطة 12 لا يستطيع الوصول لخادم اللعبة. أصلحه.

ما تُعلّمك إياه LAN مادية ولا تُعلّمه AWS

حين تكون الشبكة مصنوعة من كابلات يمكنك لمسها، تتوقف الشبكات عن كونها مجردة. “الاتصال متوقف” يعني شيئاً محدداً. يعني: هل الكابل ثابت؟ هل منفذ السويتش مضاء؟ هل تأجير DHCP حديث؟ هل تعثّر أحد على الكابل المار خلف لوحة الحائط مجدداً؟

تتبّعت مشكلة شبكة بالمشي الجسدي على امتداد كابل أكثر مما أستطيع عدّه. هذه ليست مهارة تظهر في ملف LinkedIn. لكنها بالتأكيد أساس الحدس الذي لديّ حين يكون شيء خاطئاً في نظام موزع: المشكلة في مكان محدد. اعثر عليها. لا تخمّن من لوحة التحكم؛ تتبّع المسار.

معظم المهندسين الذين عملت معهم ممن انتقلوا مباشرة من شهادة الحاسوب إلى البنية التحتية السحابية لديهم نموذج ذهني لـ”الشبكة” كـAPI. تستدعيها، تستجيب (عادةً). حين لا تستجيب، تقرأ سجلات CloudWatch. هذا جيد. ينجح. لكنك تعتمد على نموذج شخص آخر لما تفعله الشبكة.

إذا تتبّعت كابلاً، لديك نموذج مختلف. الشبكات أشياء مادية بنقاط فشل غالباً ما تكون محرجة في بساطتها. حلقة spanning tree أسقطت صالة ألعاب ليلة جمعة هي نفس فئة مشكلة خطأ BGP configuration أسقط منطقة بيانات - الطوبولوجيا فشلت بطريقة متوقعة كان يجب أن يتوقعها أحد. الإحراج يتضاعف، لكن الفئة لا تتغير.

سنوات الكاشير، وما تُعلّمه المعاملات المالية

قبل صالة الألعاب، كنت في Collection Computer Systems: بيع أجهزة كمبيوتر، استلام نقود، صيانة أساسية للحاسوب. كان عمري 17.

التعامل مع المال يغيّر طريقة تفكيرك في القيمة. ليس بالمعنى الفلسفي - بالمعنى الحرفي جداً. تطوّر حدساً حين على وشك العميل المغادرة، وما هو الهامش المعقول على بيع ما، ولماذا المنتج الذي لا يمكن شرحه في 30 ثانية لن يُباع من أرضية التجزئة مهما كان متفوقاً تقنياً.

كنت في اجتماعات هندسية يُقدّم فيها شخص حلاً صحيحاً بوضوح - صارماً تقنياً، موثّق الأدلة، القرار الصحيح واضح - ثم يراه يموت لأن لا أحد في الغرفة ربطه بما كان العمل يحاول تحقيقه. هذا فشل في التواصل، لا فشل تقني. المهندسون الذين مروا بمسارات تضمّنت عميلاً على الجهة الأخرى من مكتب عادةً تعلّموا هذا مبكراً وبصرية أكبر ممن انتقلوا مباشرة للتطوير.

العميل ليس قصة مستخدم. العميل شخص يمكنه المغادرة. كل ما بعد ذلك - المعمارية والـuptime وأولوية الميزات - في خدمة أن يجد ذلك الشخص سبباً للبقاء.

الجزء الذي لا يتوقعه الناس: MUMPS، 2010

بعد نادي OSS، وبعد شهادتي، ذهبت إلى EHS/HAKEEM - نظام الرعاية الصحية الوطني في الأردن - وقضيت وقتاً أكتب روتينات MUMPS على VistA. MUMPS، إن لم تكن مألوفاً بها: لغة من عام 1966، لا تزال تُشغّل أنظمة مستشفيات حول العالم، مشهورة بغرابتها ومشهورة بأهميتها.

أُذكر هذا في سياق المسار غير الاعتيادي لأنه طبقة أخرى من نفس الشيء: الأشخاص الذين يكتبون برمجيات رعاية صحية تبقى تعمل 30 عاماً لديهم علاقة مختلفة بالصحة من الأشخاص الذين يعالج خط نشرهم حالات التراجع. في نظام تكون فيه للمخرجات الخاطئة عواقب سريرية، تعريف “منتهٍ” مختلف. لا تشحن لترى ما يحدث.

صالة الألعاب علّمتني: أصلحه الآن، العميل ينتظر. MUMPS علّمتني: كن متأكداً جداً مما تفعله، المريض يعتمد عليك. كلاهما صحيح. إنهما في توتر، ومعظم مسيرتي كانت التنقل في ذلك التوتر في سياقات تقع في مكان ما بين القطبين.

ما يستحقه المسار غير الاعتيادي فعلاً

كنت على الجانب التشغيلي من المكتب بطريقة لم يكن عليها معظم المهندسين المعماريين. أمسكت بالكابل الذي كان يسبب المشكلة. شرحت لمراهق لماذا حُظر حسابه بمصطلحات دقيقة تقنياً ومفهومة في نفس الوقت. أخذت نقوداً مقابل شيء بنيته (أو أصلحته) وفهمت فوراً هل كان يساوي السعر.

هذه ليست المهارات في CV. إنها المهارات تحت المهارات في CV.

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

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

لا أعتقد أن على الجميع البدء ككاشير ليصبحوا مهندسين معماريين جيدين. لكنني أعتقد أن المهندسين الذين كانوا في الطرف المتلقي من نظام - الذين كانوا الشخص الذي تعتمد تجربته على ما إذا كانت الشبكة تعمل - يحملون شيئاً يصعب اكتسابه من الجهة الأخرى من لوحة المفاتيح وحدها.

مساري كان تجزئة، ثم مشرف شبكات في صالة ألعاب، ثم MUMPS، ثم أنظمة موزعة. إنه ليس وصفة. إنه مساري فقط، ولن أستبدله بالخط المستقيم.