ملف GitHub الخاص بي كان مقبرة: كيف أنقذتني ‘المساهمات الصغيرة المستمرة’ من جحيم المبرمج المجهول؟

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

تقدمت لوظيفة أحلامي في شركة تقنية كبيرة تعمل عن بعد. المقابلة الأولى كانت ممتازة، والثانية (التقنية) كانت أفضل. شعرت أن الوظيفة في جيبي. في نهاية المكالمة، قال لي مدير التوظيف بلهجة ودودة: “ممتاز يا أبو عمر، كل شيء يبدو رائعاً. سألقي نظرة سريعة على ملفك في GitHub لنرى بعض أعمالك، ثم نعود إليك…”.

في تلك اللحظة، شعرت ببرودة تسري في جسدي. ملفي في GitHub؟ أي ملف؟ ذلك المكان الذي كان أشبه بمقبرة رقمية. بضعة مشاريع بدأت بحماس قبل سنتين مع رسالة “Initial commit” ثم تُركت لتموت بسلام. تقويم المساهمات (Contribution Graph) كان صحراء قاحلة من المربعات الرمادية. الصمت الذي تلا جملته على الطرف الآخر من المكالمة كان يصم الآذان. لم أحصل على تلك الوظيفة. في ذلك اليوم، أدركت حقيقة مؤلمة: مهاراتي، ما لم تكن مرئية، فهي غير موجودة. كنت شبحاً رقمياً، “مبرمجاً مجهولاً” في عالم يعترف فقط بالدليل الملموس.

مقبرة المشاريع المنسية: هل ملفك يشبه ملفي القديم؟

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

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

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

الصحوة: كيف اكتشفتُ سر “المساهمات الصغيرة المستمرة”؟

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

نظرت عن كثب. كانت مساهماتهم شيئاً من هذا القبيل:

• docs: Fix typo in installation guide
• refactor: Improve readability of calculateTotal function
• feat: Add loading spinner to login button
• chore: Update dependencies to latest version

كانت تلك لحظة “وجدتها!”. السر لم يكن في حجم المساهمة، بل في استمراريتها. إن بناء هوية تقنية قوية على GitHub لا يتعلق بالبطولات الفردية، بل بالالتزام اليومي البسيط. إنها ماراثون، وليست سباق 100 متر. ومن هنا، ولدت استراتيجيتي التي أنقذتني: “المساهمات الصغيرة المستمرة”.

خطة العمل: كيف تحوّل ملفك من مقبرة إلى حديقة غنّاء؟

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

الخطوة الأولى: ابدأ بما لديك (ابدأ من الموجود يا خوي)

أكبر خطأ هو انتظار “الفكرة العبقرية”. لا تنتظر. انظر إلى ما لديك الآن على جهازك. هل كتبت سكربت بايثون صغيراً لتنظيم ملفاتك؟ هل صممت صفحة هبوط بسيطة كتمرين على HTML/CSS؟ هل لديك مشروع جامعي قديم؟ كل هذا ذهب!

نصيحة أبو عمر: اختر أصغر مشروع أو سكربت لديك. حتى لو كان 50 سطراً فقط. أنشئ له مستودعاً (Repository) جديداً على GitHub، واكتب له ملف README.md بسيطاً، وارفعه. مبروك، لقد قمت بأول مساهمة حقيقية لك! هذه هي الشرارة الأولى.

الخطوة الثانية: قوة التعديلات اليومية الصغيرة (كل يوم لو سطر)

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

• تحسين التوثيق: صحح خطأ إملائياً في ملف README.md. أضف قسماً يشرح كيفية تشغيل المشروع.
• إضافة التعليقات: هل لديك دالة معقدة قليلاً؟ أضف بضعة أسطر من التعليقات تشرح ما تفعله.
• إعادة الهيكلة (Refactoring): هل هناك دالة طويلة جداً؟ قسمها إلى دالتين أصغر وأكثر وضوحاً.
• تحديث الاعتماديات (Dependencies): هل يستخدم مشروعك مكتبات خارجية؟ تحقق من وجود تحديثات لها وقم بتحديثها.

للتوضيح، انظر إلى هذا المثال البسيط لإعادة هيكلة دالة في JavaScript.

قبل:

// Calculates price with tax and discount
function calculateFinalPrice(price, quantity, tax, discount) {
  const priceWithoutTax = price * quantity;
  const taxAmount = priceWithoutTax * tax;
  const priceWithTax = priceWithoutTax + taxAmount;
  const discountAmount = priceWithTax * discount;
  const finalPrice = priceWithTax - discountAmount;
  return finalPrice;
}

بعد (مع إعادة الهيكلة والتعليقات):

/**
 * Calculates the total price before any deductions or additions.
 * @param {number} price - The price per item.
 * @param {number} quantity - The number of items.
 * @returns {number} The total base price.
 */
function calculateBasePrice(price, quantity) {
  return price * quantity;
}

/**
 * Calculates the final price after applying tax and discount.
 * @param {number} basePrice - The total price before tax/discount.
 * @param {number} taxRate - The tax rate (e.g., 0.15 for 15%).
 * @param {number} discountRate - The discount rate (e.g., 0.10 for 10%).
 * @returns {number} The final payable price.
 */
function calculateFinalPrice(basePrice, taxRate, discountRate) {
  const priceWithTax = basePrice * (1 + taxRate);
  const finalPrice = priceWithTax * (1 - discountRate);
  return finalPrice;
}

هذا التعديل البسيط هو مساهمة ممتازة. رسالة الـ commit يمكن أن تكون: refactor: Decompose calculateFinalPrice into smaller functions for clarity. هذا يظهر أنك تهتم بجودة الكود وقابليته للقراءة.

الخطوة الثالثة: اقتناص الفرص في العالم المفتوح (صيد المساهمات)

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

كيف تجدها؟ اذهب إلى GitHub وابحث عن المشاريع التي تستخدمها أو تحبها. في قسم “Issues” الخاص بالمشروع، ابحث عن الوسوم (Labels) التالية:

• good first issue
• help wanted
• documentation
• beginner friendly

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

الخطوة الرابعة: التوثيق هو مساهمة ذهبية (الـ README هو واجهتك)

اسمع مني هذه النصيحة الذهبية: معظم المبرمجين يكرهون كتابة التوثيق. وهذا بالضبط ما يجعلها فرصة عظيمة لك! مشروع صغير مع ملف README.md ممتاز يبدو أكثر احترافية ألف مرة من مشروع ضخم بلا أي شرح.

نصيحة أبو عمر: ارجع إلى مشاريعك القديمة. اقضِ نصف ساعة في كتابة ملف README.md واضح ومنظم. اشرح ما هو المشروع، ما هي التقنيات المستخدمة، كيف يمكن تثبيته، وكيف يمكن استخدامه (مع مثال بسيط). هذه أفضل 30 دقيقة ستستثمرها في هويتك التقنية.

تغيير العقلية: من “مبرمج الأفكار العظيمة” إلى “المبرمج الفعّال”

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

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

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

الخلاصة: قطرة فوق قطرة تصنع نهراً 💧

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

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

يلا يا جماعة، ورجونا همّتكم. أفضل وقت لزرع شجرة كان قبل عشرين عاماً، وثاني أفضل وقت هو الآن. والأمر نفسه ينطبق على ملفك في GitHub. ابدأ اليوم، ولو بتعديل حرف واحد في ملف README. المهم أن تبدأ. ✅