أخطاء كادت أن تنهي مسيرتي في البرمجة

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

كانت هذه الأخطاء كالتالي:

الخطأ الأول: وهم ضرورة تعلم كل شيء

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

• بايثون (Python)
• بي إتش بي (PHP)
• جافا سكريبت (JavaScript)، بما في ذلك جي كويري (jQuery)
• دوت نت إم في سي (.NET MVC)
• تطوير تطبيقات سطح المكتب (Desktop Application Development)
• تطوير تطبيقات الموبايل (Mobile Application Development)

كنت أنتقي من كل بستان زهرة بمنتهى العشوائية، وأتعلم أمورًا سطحية جدًا عن كل مجال، ثم أشعر بأنني وصلت إلى القمة. كنت أقول لنفسي: “أنا الآن أفهم كيف يصنعون تطبيقات أندرويد باستخدام جافا، لقد وصلت!”. للأسف، كانت هذه تصورات خاطئة جدًا.

الخطأ الثاني: وضع خطط غير واقعية

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

• مذاكرة تطوير تطبيقات الموبايل لمدة ساعة.
• مذاكرة تطوير الويب لمدة ساعة.
• مذاكرة تقنية مختلفة كل ساعة لمدة 8 ساعات يوميًا.
• أداء التمارين في النادي الرياضي.
• تناول طعام صحي.
• قراءة كتاب كل يوم.
• تخصيص وقت للقراءة اليومية.

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

الخطأ الثالث: الاستعجال والبحث عن المال

كان لدي دائمًا شعور بأنني متأخر، وكنت في عجلة من أمري للوصول إلى النجاح المادي الذي كنت أقرأ عنه. كنت أبحث في جوجل وأجد أن مهندس البرمجيات في شركة جوجل يتقاضى 200 ألف دولار سنويًا. في المقابل، كانت المشاريع التي أحصل عليها كـ “فريلانسر” لا تتجاوز 50 أو 100 دولار.

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

ملاحظة: لم يوجهني أحد لأهمية مفاهيم مثل هياكل البيانات (Data Structures)، الخوارزميات (Algorithms)، أنماط التصميم (Design Patterns)، أو تصميم النظم (System Design). كل هذه الركائز الأساسية لم يكن لدي أي تصور عنها.

نقطة التحول: صدمة سوق العمل

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

كانت التطبيقات التي أبنيها تتبع بنية بسيطة:

• Controller: كنت أضع فيه كل منطق العمل (Business Logic).
• View: كنت أستخدمها لعرض HTML باستخدام محرك القوالب Razor.
• Model: كنت أستخدمه للتعامل مع قاعدة البيانات عبر Entity Framework.

كنت أشعر بأنني مدهش، لكن في الحقيقة، كل ما كنت أفعله هو عمليات CRUD بسيطة (Create, Read, Update, Delete). المشكلة أنني كنت المبرمج الوحيد في شركة ناشئة لا يملك أصحابها خبرة تقنية، فكانوا يصفقون لأي شيء أفعله، مما عزز لدي شعورًا زائفًا بالتميز.

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

• “ما هي بنية البصلة (Onion Architecture)؟” - كل ما عرفته هو أن البصلة تتكون من طبقات.
• “ما الفرق بين أنواع الربط المختلفة في SQL مثل LEFT OUTER JOIN وغيرها؟” - لم أكن أعرف، لأنني كنت أعتمد كليًا على ORM مثل Entity Framework وأستخدم Include() لجلب البيانات المرتبطة.
• “ما هي معايير اختيارك لقاعدة البيانات؟ متى تختار MySQL أو PostgreSQL أو SQL Server؟” - لم يكن لدي إجابة.

في نهاية المقابلة، قال لي المحاور:

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

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

الطريق الصحيح: التركيز على الأساسيات

بدأت أركز على المذاكرة الحقيقية. قرأت كتبًا عن الأساسيات، وتعلمت عن:

• أنماط التصميم (Design Patterns): فهمت أهميتها وكيفية تطبيقها.
• الخدمات المصغرة (Microservices): استوعبت مفاهيم مثل وسطاء الرسائل (Message Brokers) مثل RabbitMQ، وأنماط مثل Saga و Choreography.
• أهمية السؤال: تعلمت أن أسأل دائمًا “لماذا؟” و”كيف؟”. لماذا أستخدم هذه التقنية؟ وكيف سأطبقها عمليًا؟

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

خلاصة الرحلة

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

بالإضافة إلى المهارات التقنية، تعلمت أهمية المهارات الشخصية (Soft Skills)، مثل القدرة على تقديم نفسك والتعبير عن أفكارك بوضوح. لكن هذه المهارات يجب أن تأتي كنتيجة لامتلاكك قاعدة تقنية صلبة، وإلا فعن أي شيء ستتحدث؟

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