كتابة البرمجيات ليست صعبة، الصعوبة تكمن في التعامل مع «الإنسان» و«التعقيد». يشارك مهندس جوجل المخضرم خبرة 14 سنة، من التفكير في المستخدم إلى التعاون الجماعي، هذه 21 قاعدة ذهبية تساعدك على تحقيق مسيرة مهنية أعمق وأبعد.
(ملخص سابق: فتح الترجمة الفورية من جوجل رسميًا لجميع ماركات السماعات: أكثر من 70 لغة متاحة، هواتف أندرويد في أمريكا والمكسيك والهند أولاً)
(معلومات إضافية: جوجل تطلق رسميًا «Gemini 3»! تتصدر نماذج الذكاء الاصطناعي الأذكى عالميًا، ما المميزات؟)

فهرس المقال

• 1. المهندسون المتميزون مهووسون بحل مشاكل المستخدمين
• 2. «إثبات أنك على حق» لا قيمة له، الهدف هو تحقيق الأهداف الصحيحة معًا
• 3. التوجه نحو العمل. انطلق! يمكنك تعديل الصفحات السيئة، لكن لا يمكنك تعديل الصفحة الفارغة
• 4. الخبرة تظهر في الوضوح، والذكاء يظهر في الحمل
• 5. «الحداثة» هي قرض فائدة عالية يُقترض من الصيانة، التوظيف، والعبء الإدراكي
• 6. الكود لن يتحدث باسمك، الناس هم
• 7. أفضل كود هو ذلك السطر الذي لم تكتبه أبدًا
• 8. عندما يكون الحجم كبيرًا، حتى أخطاؤك لها مستخدمون
• 9. معظم الفرق «البطيئة» في الواقع هي فرق «غير مركزة»
• 10. ركز على ما يمكنك السيطرة عليه، وتجاهل ما لا يمكنك
• 11. التجريد لا يلغي التعقيد، بل ينقله
• 12. الكتابة تجبر على الوضوح، والتعليم هو أسرع طرق التعلم
• 13. جعل الأعمال الأخرى ممكنة هو عمل لا يقدر بثمن، لكنه غير مرئي
• 14. إذا فزت بكل نقاش، ربما تكون تجمع مقاومة صامتة
• 15. عندما يتحول المؤشر إلى هدف، فهو لم يعد مؤشرًا جيدًا
• 16. الاعتراف بـ «لا أعرف» يبني أمانًا أكثر من التظاهر بالفهم
• 17. سياقك أعمق من أي وظيفة قمت بها
• 18. معظم تحسينات الأداء تأتي من «إزالة العمل»، وليس من «الخوارزميات الذكية»
• 19. وجود العمليات يهدف إلى تقليل عدم اليقين، وليس لإنشاء سجلات
• 20. في النهاية، الوقت أثمن من المال، فتصرف بناءً على ذلك
• 21. لا توجد طرق مختصرة، لكن هناك تأثير الفائدة المركبة

• نقطة أخيرة

مدير الذكاء الاصطناعي في Google Cloud، آدي أوسماني، مهندس برمجيات مخضرم ومفكر، عمل كرئيس لتجربة المطورين في Chrome لمدة تقرب من 14 سنة، وشارك في مشاريع DevTools، Lighthouse، وCore Web Vitals. الآن، يتولى تنسيق العمل بين فريق Google DeepMind، والهندسة، والمنتجات، وعلاقات المطورين.

نشر في مدونته الشخصية في 3 أيام مقالًا عميقًا عن خبراته المهنية. جمع خبرته الطويلة في Google واحترافه المهني، وخلص إلى 21 نصيحة قيمة حول التواصل، الاختيارات التقنية، وتخطيط المسيرة المهنية، وملخصها كالتالي:

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

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

أشارك هذه النصائح لأنها من مهندسين كانوا دائمًا مستعدين لمساعدتي، وهذه لفتة مني للرد بالمثل.

1. المهندسون المتميزون مهووسون بحل مشاكل المستخدمين

حب تقنية معينة والبحث عن تطبيقاتها هو أمر مغرٍ جدًا. لقد فعلت ذلك، وفعل الجميع. لكن المهندس الذي يخلق أكبر قيمة هو «العمل العكسي»: الذي يهوى فهم مشاكل المستخدمين بعمق، ويترك الحلول تنشأ بشكل طبيعي من هذا الفهم.

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

2. «إثبات أنك على حق» لا قيمة له، الهدف هو تحقيق الأهداف الصحيحة معًا

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

المهارة ليست في «الصواب»، بل في المشاركة في النقاش لتوحيد الرؤى، وخلق مساحة للآخرين، والشك في يقينك. الرأي القوي، والانفتاح على الآخرين — هذا ليس لأنك تفتقر إلى الثقة، بل لأن القرارات في ظل عدم اليقين لا يجب أن ترتبط بكبريائك.

3. التوجه نحو العمل. انطلق! يمكنك تعديل صفحات سيئة، لكن لا يمكنك تعديل صفحة فارغة

السعي للكمال يؤدي إلى الشلل. رأيت مهندسين يناقشون أسابيع حول الهيكل المثالي لشيء لم يبنوه أبدًا. الحل المثالي نادرًا ما يأتي من التفكير فقط — بل من التصادم مع الواقع. يمكن للذكاء الاصطناعي أن يساعد في كثير من الحالات.

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

4. الخبرة تظهر في الوضوح، والذكاء يظهر في الحمل

الكتابة بكود «ذكي» هو غريزة مشتركة بين المهندسين، وكأنه إثبات على قدراتهم. لكن هندسة البرمجيات تعتمد على «الوقت» و«تفاعل مع مهندسين آخرين». في هذا السياق، الوضوح ليس أسلوبًا، بل هو خفض مخاطر التشغيل.

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

5. «الحداثة» هي قرض فائدة عالية يُقترض من الصيانة، التوظيف، والعبء الإدراكي

اعتبر تقنياتك كـ «رموز ابتكار» لشركة ذات ميزانية محدودة. كل تقنية غير قياسية تستهلك وحدة. لا يمكنك أن تتحمل الكثير. المهم ليس «عدم الابتكار أبدًا»، بل «الابتكار فقط حيث تحصل على مكافأة فريدة».

كل شيء آخر يجب أن يُفترض أنه «ممل»، لأن الممل يعني أن أنماط فشله معروفة. «الأداة الأنسب للعمل» غالبًا هي «الأداة التي تؤدي بشكل غير سيء في عدة مهام» — لأن إدارة حديقة تقنيات تصبح عبئًا حقيقيًا.

6. الكود لن يتحدث باسمك، الناس هم

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

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

7. أفضل كود هو ذلك السطر الذي لم تكتبه أبدًا

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

قبل البناء، اسأل نفسك سؤالًا عميقًا: «ماذا لو لم نفعل شيئًا؟» أحيانًا يكون الجواب «لا شيء سيء يحدث»، وإذا كان كذلك، فهذه هي الحلول. المشكلة ليست أن المهندس لا يكتب الكود أو لا يستخدم الذكاء الاصطناعي، بل لأنه يكتب كثيرًا لدرجة نسيان السؤال «هل يجب أن أكتب؟».

8. عندما يكون الحجم كبيرًا، حتى أخطاؤك لها مستخدمون

عندما يكون لديك عدد كبير من المستخدمين، أي سلوك يمكن ملاحظته يصبح اعتمادًا — سواء وعدت بذلك أم لا (قانون هيلرميت). هناك من يلتقط API الخاص بك، ويقوم بأتمتة ميزاتك الغريبة، ويخزن أخطائك.

وهذا يعطيك رؤية مهنية: لا تعتبر العمل على التوافق مجرد «صيانة»، بل هو «منتج بحد ذاته». التوافق هو المنتج نفسه. عند تصميم خطة للتخلص من شيء، اعتبره عملية انتقال تتضمن الوقت، والأدوات، والتعاطف. معظم «تصميم API» هو في الواقع «تقاعد API».

9. معظم الفرق «البطيئة» في الواقع هي فرق «غير مركزة»

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

10. ركز على ما يمكنك السيطرة عليه، وتجاهل ما لا يمكنك

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

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

11. التجريد لا يلغي التعقيد، بل ينقله

كل تجريد هو مقامرة، تراهن على أنك لن تحتاج لفهم التفاصيل الأساسية. أحيانًا تربح، لكن دائمًا هناك تسرب في التجريد. عندما يفشل، تحتاج إلى معرفة ما يحدث في الأسفل. المهندسون المخضرمون، حتى مع تراكم طبقات التقنية، يواصلون تعلم «الأساسيات». ليس من أجل الحنين، بل احترامًا لوقت فشل التجريد. استخدم أدواتك، لكن فكر في نماذج فشلها الأساسية.

12. الكتابة تجبر على الوضوح، والتعليم هو أسرع طرق التعلم

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

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

13. جعل الأعمال الأخرى ممكنة هو عمل لا يقدر بثمن، لكنه غير مرئي

«عمل الغراء» — التوثيق، التوجيه، التنسيق بين الفرق، تحسين العمليات — مهم جدًا. لكن إذا قمت به بلا وعي، فإنه يعيق نموك التقني ويجهدك. الفخ هو أن تعتبره «مساعدة»، بدلاً من أن تراه مساهمة واعية، ذات حدود، ومرئية. حدد وقتًا، وتناوب، وحول ذلك إلى مخرجات (وثائق، قوالب، أدوات تلقائية).

اعتبره تأثيرًا، وليس سمة شخصية.

14. إذا فزت بكل نقاش، ربما تكون تجمع مقاومة صامتة

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

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

15. عندما يتحول المؤشر إلى هدف، فهو لم يعد مؤشرًا جيدًا

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

أفضل الممارسات: لكل طلب مؤشر، قدم زوجًا من المؤشرات. واحد للسرعة، وواحد للجودة أو المخاطر. التزم بـ تفسير الاتجاهات، وليس عبادة العتبات. الهدف هو الرؤية، وليس المراقبة.

16. الاعتراف بـ «لا أعرف» يبني أمانًا أكثر من التظاهر بالفهم

المهندس المخضرم الذي يقول «لا أعرف» لا يظهر ضعفًا، بل يخلق «تصريحًا». عندما يعترف القائد بعدم اليقين، يرسل إشارة: أن الغرفة آمنة للآخرين. رأيت فرقًا لا يعترفون بالحيرة، وتكون أضرار ذلك كبيرة: لا أحد يطرح الأسئلة، ولا أحد يتحدى، والمبتدئون يصمتون، يظنون أن فقط هم من لا يفهم. أظهر فضولك، وستحصل على فريق يتعلم حقًا.

17. سياقك أعمق من أي وظيفة قمت بها

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

18. معظم تحسينات الأداء تأتي من «إزالة العمل»، وليس من «الخوارزميات الذكية»

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

19. وجود العمليات يهدف إلى تقليل عدم اليقين، وليس لإنشاء سجلات

أفضل العمليات تجعل التنسيق أسهل، وتقلل من تكلفة الفشل. أسوأ العمليات هي «دراما البيروقراطية» — وجودها ليس للمساعدة، بل لإلقاء اللوم عند وقوع المشاكل. إذا لم تستطع شرح كيف تقلل عملية ما المخاطر أو تزيد الوضوح، فهي عبء. إذا قضيت وقتًا أكثر في توثيق العمل من إنجازه، فهناك مشكلة كبيرة.

20. في النهاية، الوقت أثمن من المال، فتصرف بناءً على ذلك

في بداية مسيرتك، كنت تستبدل الوقت بالمال، وهذا طبيعي. لكن عند نقطة معينة، يتغير الحساب. ستدرك أن الوقت هو مورد غير قابل للتعويض. رأيت مهندسين مخضرمين يكدحون من أجل ترقية، أو تحسين نسبة مئوية صغيرة من الراتب. بعضهم نجح، لكن معظمهم يتساءلون بعد ذلك: هل كان ذلك يستحق الثمن الذي دفعوه؟ الجواب ليس «لا تعمل بجد»، بل «اعرف ما تتداول فيه وكن واعيًا به».

21. لا توجد طرق مختصرة، لكن هناك تأثير الفائدة المركبة

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

نقطة أخيرة

هذه الـ 21 قاعدة تبدو كثيرة، لكن الفكرة الأساسية منها فقط قليلة: ابقَ فضوليًا، وكن متواضعًا، وتذكر أن العمل دائمًا يتعلق بالإنسان — بما في ذلك المستخدمين الذين تبني لهم منتجاتك، والزملاء الذين تبني معهم.

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

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