ما تمنيت لو عرفته قبل أن أبدأ تعلم البرمجة

مرحباً، أنا نيك. كتبت أول سطر برمجي لي قبل 9 سنوات. ومثل أي شخص بدأ رحلته في عالم البرمجة، كان جل اهتمامي ينصب على كتابة الأكواد. بالنسبة لي، كانت البرمجة أشبه بالسحر؛ تكتب شيئاً على لوحة المفاتيح، ويُظهر لك الحاسوب نتائج عملك على الشاشة فوراً. لكن هذا السحر بدأ يتلاشى عندما واجهت الواقع العملي وحصلت على وظيفتي الأولى كمطور full-stack قبل 6 سنوات. خلال هذه السنوات، واجهت الجوانب الجيدة والسيئة والقبيحة لمهنة البرمجة. وتعلمت 4 دروس جوهرية حول البرمجة والمسار المهني الذي كان من الممكن أن يساعدني بسهولة على تحقيق إنجازات أكبر بنسبة 297% لو كنت أعرفها عندما بدأت.

البرمجة ليست مجرد كتابة أكواد: التركيز على حل المشكلات

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

لهذا السبب، يهتم عدد قليل نسبياً من الناس بالتقنيات التي تستخدمها Google search تحت الغطاء. طالما أن الناس يستطيعون العثور على المعلومات ذات الصلة بواسطتها، فإنهم سيستخدمونها. هذا هو الدرس الأول الذي تمنيت لو عرفته عندما بدأت البرمجة. كنت سأقضي وقتاً أقل في كتابة ‘أفضل كود’ ووقتاً أطول في حل مشكلات العملاء بأسرع وأفضل طريقة ممكنة. لا تكتب الأكواد لمجرد الكتابة؛ بل حل مشكلات عملائك بالأكواد.

مهارات التواصل: مفتاح النجاح الذي يفوق المهارات البرمجية

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

إليك موقف حقيقي قد تواجهه:

يخبر فريق القيادة مدير المنتج الخاص بك أنهم يريدون إنشاء ميزة جديدة للمنتج وضمها إلى الإصدار التالي. الأمر ليس عاجلاً، لكنهم يريدون إطلاقها في أقرب وقت ممكن (كما هو الحال دائماً). يتصل بك مدير المنتج عبر Zoom، ويخبرك بما تحتاج إلى بنائه، ويسألك: ‘كم من الوقت تحتاج لبنائها؟’ تقوم بحساب تقريبي وتخبره: ‘أحتاج 20 ساعة’.

مدير المنتج غير راضٍ عن إجابتك. يريدون إطلاقها في أقرب وقت ممكن وإظهار الإدارة أنهم يستطيعون تحقيق النتائج بسرعة (وهذا موقف شائع جداً). لذا يسألك: ‘هل يمكنك بنائها في 10 ساعات؟ نحن بحاجة ماسة لهذه الميزة في الإصدار التالي من المنتج!’. وأنت تعلم أنك تستطيع ذلك إذا اختصرت بعض الخطوات (لا اختبارات، كود فوضوي)، ولكنك ستحتاج لاحقاً إلى إعادة هيكلته (refactor)، وسيستغرق ذلك 30 ساعة إضافية. لأن المهندسين الآخرين سيعملون مع الكود الفوضوي الخاص بك عندما يتم إصداره. وبعد إعادة الهيكلة، ستحتاج إلى دمج الكود الخاص بهم مع كودك.

إذن، إليك ما سيحدث بعد ذلك. إذا كانت لديك مهارات اجتماعية سيئة، فلن تتمكن من إقناع مدير المنتج بأنك تحتاج فعلاً إلى 20 ساعة لبناء هذه الميزة. لماذا؟ غالباً ما يتمتع مديرو المنتجات بمهارات اجتماعية جيدة، من واقع تجربتي. لذا، إذا لم تتمكن من إقناعهم بأن إعادة الهيكلة لاحقاً أسوأ من قضاء 20 ساعة الآن، فسوف يجادلونك بسهولة ويقنعونك بأن ‘إعادة الهيكلة لاحقاً أمر مقبول’. وعندها سيفقد الفريق بأكمله تلك الـ 30 ساعة الإضافية بينما تقوم بإعادة الهيكلة هذه (ولا أحسب الوقت الذي قد يستغرقه إصلاح الأخطاء غير المتوقعة أيضاً).

لكن إذا كانت لديك مهارات تواصل جيدة، فستتمكن بسهولة أكبر من إقناع مدير المنتج بالعكس. لذا، حسّن مهاراتك الاجتماعية بالإضافة إلى مهارات البرمجة (أرسل الميمات في محادثات المجموعات على Slack أو ما شابه ذلك!). وتذكر حقيقة بسيطة: الناس يعملون مع الناس، لا مع الآلات.

تعلم كيف تتعلم: سر إتقان البرمجة بفعالية

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

بعد أن طبقت الممارسة المتعمدة، بدأت ألاحظ مدى سرعة تقدمي في تعلم JavaScript. بدأت معرفتي تترسخ لفترة طويلة، وليس فقط لمدة 5 دقائق بعد الدروس التعليمية. لقد حددت هدفي النهائي، ووضحت لماذا كنت أتعلم JavaScript، وفهمت ما أحتاج لتعلمه وما لا أحتاج إليه.

إليك ما تحتاجه لتطبيق الممارسة المتعمدة بنفسك:

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

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

المهندسون الخارقون (10X Engineers) خرافة: تقبل حقيقة عدم معرفة كل شيء

في بداية مسيرتي المهنية، اعتقدت أن المبرمج العظيم هو شخص يعرف أطناناً من لغات البرمجة، والأطر البرمجية، والمنهجيات. كنت مخطئاً. هذا النمط من التفكير ولد لدي متلازمة المحتال (impostor syndrome). اعتقدت أنني لا أستحق منصبي الحالي، راتبي، وأنني ‘محتال’. لذلك بدأت بمتابعة كل مطور مشهور على Twitter، وقراءة كل منشور تقني، وتصفح آلاف مدونات المطورين فقط لأقنع نفسي بأنني أستحق ما لدي ولأشعر بأنني أقرب إلى لقب ‘المطور العظيم’. لم يكن هذا سلوكاً صحياً.

لكنه ساعدني على اكتشاف أن الكثير من الأشخاص الذين تابعتهم (والذين اعتقدت أنهم مهندسون خارقون 10X engineers) لم يكونوا يعرفون الكثير من الأشياء في الواقع. ربما كانوا يعرفون كيفية القيام ببعض المهام المعقدة التي تتطلب معرفة عميقة في مجالين، لكنهم في الوقت نفسه لم يكونوا يعرفون بعض الأشياء الأساسية. على سبيل المثال، كانوا يعرفون كيفية تصميم بنى قواعد بيانات عالية التوسع، لكنهم لم يكونوا يعرفون كيفية محاذاة عنصر عمودياً (vertical-align) باستخدام CSS.

شكر كبير لهؤلاء المطورين، مثل Dan Abramov (مبتكر Redux)، لإنشائهم موارد مثل هذه المقالة. لقد ساعدوا في علاج متلازمة المحتال لدي وأظهروا لي أنه لا بأس ألا تعرف كل شيء.

الخلاصة التقنية

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