المهارة التي لا تُصحَّح
الجامعة تقيس ما تكتبه من صفحة فارغة. والعمل يقيس ما تفهمه من شيفرة كتبها غيرك.

في الجامعة، كل تقييم تقريبًا يبدأ من صفحة فارغة. يُطلب منك أن تكتب برنامجًا فتكتبه، ثم يُصحَّح ما كتبته أنت. أربع سنوات وأنت تتدرّب على مهارة واحدة: إنتاج شيفرة جديدة تحت ضغط الوقت.
ثم تدخل أول فريق حقيقي، فتكتشف أن العمل نادرًا ما يبدأ من صفحة فارغة. يبدأ من مستودع فيه عشرات آلاف الأسطر، كتبها أشخاص لم تقابلهم، ونصفهم غادر الشركة. ومهمتك الأولى ليست أن تكتب شيئًا، بل أن تفهم شيئًا.
ولم يصحّح لك أحد هذه المهارة من قبل.
ما الذي تقيسه الجامعة فعلًا
الواجب الجامعي مصمَّم ليكون قابلًا للتصحيح. ولكي يكون قابلًا للتصحيح يجب أن يكون صغيرًا، ومعزولًا، وله إجابة معروفة سلفًا. وهذه الشروط الثلاثة هي بالضبط ما لا يتوفر في أي شيفرة حقيقية:
- الشيفرة الحقيقية كبيرة، ولا يمكن الاحتفاظ بها كاملة في رأسك.
- الشيفرة الحقيقية متشابكة، وتغيير سطر هنا يكسر اختبارًا هناك.
- الشيفرة الحقيقية ليس لها إجابة نموذجية، بل قرارات اتُّخذت لأسباب لم تُكتب في أي مكان.
والمفارقة أن الجامعة ليست مخطئة في ما تُعلّمه، بل في ما تحذفه. أنت تحتاج فعلًا إلى أن تعرف كيف تكتب. لكن الكتابة هي الجزء الذي ستقضي فيه أقل وقتك.
ما الذي تغيّر في السنتين الأخيرتين
الفجوة قديمة، لكنها اتسعت بسرعة غير معتادة.
في دراسة من كامبريدج ومايكروسوفت، وجد الباحثون أن نحو ٥٠٪ من وقت البرمجة صار يمضي في التعامل مع النموذج، وأن ٣٥٪ منه تحديدًا يذهب إلى مراجعة اقتراحاته والتحقق منها.
وفي استطلاع شمل ٧٠٥ مطوّرين في أكثر من ستين دولة، تبيّن أن ٢١٪ فقط يقضون أكثر من نصف أسبوعهم في كتابة شيفرة جديدة من الصفر، وأن ٦٧٪ صاروا يقضون في مراجعة شيفرة ولّدها الذكاء الاصطناعي وقتًا أطول مما كانوا يقضونه قبل سنة، وأن ٥٢٪ يقضون وقتًا أطول في تصحيح مشكلات أدخلها النموذج.
اقرأ الأرقام الثلاثة مرة أخرى. كلها تقيس الشيء نفسه: الوقت الذي تقضيه أمام شيفرة لم تكتبها.
بعبارة أخرى: المهارة التي لم تُصحَّح لك مرة واحدة في الجامعة صارت المهارة التي ستمارسها أكثر من غيرها. وهذا يشمل مراجعة ما يكتبه لك النموذج، فهو أيضًا شيفرة كتبها غيرك — إلا أنها تصل إليك واثقة، ومنسّقة، وبلا تاريخ.
كيف تتدرّب على ما لا يُصحَّح
القراءة مهارة، وتُتقن بالتمرين لا بالنية. وهذه ثلاثة تمارين عملية:
- اقرأ قبل أن تكتب. قبل أي تعديل، اقرأ تاريخ الملف.
git logليس للفضول، بل لسؤال واحد: لماذا صار هذا السطر هكذا؟ - تتبّع سؤالًا واحدًا. لا تحاول فهم المشروع كله دفعة واحدة. اختر سؤالًا محددًا — من أين تأتي هذه القيمة؟ — واتبعه حتى نهايته.
- اشرحها بصوت عالٍ. إن لم تستطع شرح الدالة في جملتين، فأنت لم تفهمها بعد.
وهذه أوامر أستعملها كثيرًا للتمرين الأول:
git log --oneline -- src/payload.config.ts
git log -S "disablePayloadAccessControl" --oneline
git blame -L 80,100 src/payload.config.ts
الأمر الثاني هو الأهم. -S يبحث في تاريخ المستودع كله عن اللحظة التي ظهر فيها نص معيّن أو اختفى، وهو أسرع طريقة عرفتها للانتقال من «ما هذا؟» إلى «من كتبه، ولماذا».
ما الذي أقوله فعلًا
لا أقول إن الجامعة بلا فائدة. أقول إن هناك مهارة لن يصحّحها لك أحد، ولن تظهر في أي معدّل تراكمي، وستحدد سرعتك في أول سنة عمل أكثر من أي مادة درستها.
ابدأ بمشروع مفتوح المصدر تستعمله أنت فعلًا. افتح README، ثم افتح أول ملف يذكره، ثم اقرأ حتى تفهم شيئًا واحدًا فهمًا كاملًا. لن يصحّح لك أحد. وهذه هي النقطة.
مقال جديد كل ما تعلّمت شيء يستاهل
بريد واحد لكل مقال، ولا شيء ثاني.
قريبًا