Day 1 / 30 — المشكلة ليست بالحل… المشكلة أنك تفكر بالطريقة الخطأ
ليش أغلب المبرمجين يضيعوا أمام المشاكل؟ لأنهم يبدأوا بالطريقة الخطأ. تعلم كيف تبدأ التفكير كمبرمج حقيقي قبل أول سطر كود.
30 Day Problem Solving
Day 1 / 30
المرحلة الأولى: تفكيك العقلية القديمة
المشكلة ليست بالحل… المشكلة أنك تفكر بالطريقة الخطأ
أغلب المبرمجين يخسروا المشكلة… قبل ما يكتبوا أول سطر كود.
وليس لأنهم أغبياء.
بل لأنهم يبدأوا التفكير بالطريقة الخطأ.
أول ما يشوفوا problem جديدة… يصير عقلهم يدور على:
- حل محفوظ
- pattern شافوه قبل
- فيديو شافوه
- snippet يتذكروه
وإذا ما لقوا شيء مألوف… يبدأ التوتر.
تقرأ السؤال.
لا تفهمه بالكامل.
لكن تبدأ تكتب.
ليس لأنك فهمت المشكلة.
بل لأن عقلك يريد أن يشعر أنه يتحرك.
يفتح VS Code بسرعة. يجرب. يعدل. يحذف. يرجع يقرأ السؤال.
وبعد 15 دقيقة أحيانًا... تكتشف أنك لم تكن تحل المشكلة أصلًا.
كنت تحاول الهروب من شعور أنك لا تفهمها.
وبعدها يقتنع:
“المشكلة صعبة.”
لكن غالبًا… المشكلة ليست صعبة.
أنت فقط دخلت عليها بعقلية الهروب للحل.
أول خطأ يدمّر التفكير
أغلب الناس يعتقدوا أن الـ Problem Solving يعني:
“كيف أجد الحل بأسرع وقت؟”
لكن المبرمج الحقيقي لا يبدأ بالحل.
يبدأ بالفهم.
قبل أي سطر كود… قبل أي algorithm… قبل أي syntax…
هو يحاول يفهم:
- ما المطلوب فعلًا؟
- ما القيود؟
- ما الحالات الخطيرة؟
- أين التعقيد الحقيقي؟
- ما الشيء الذي قد يكسر الحل؟
لأن كتابة الكود بدون فهم المشكلة… يشبه بناء عمارة بدون فهم الأرض التي تبني عليها.
قد ينجح مؤقتًا. لكن أول ضغط حقيقي ينهار.
كيف يبدأ المبرمج القوي؟
المبرمج الضعيف يبدأ بالكود.
المبرمج القوي يبدأ بالأسئلة.
قبل أن يفكر بالحل… هو يحاول تفكيك المشكلة.
مثال بسيط:
إذا أعطيتك array وطلبت منك إيجاد duplicate.
المبرمج الضعيف يفكر مباشرة:
“شو الـ algorithm المناسبة؟”
أما القوي يفكر:
- هل الأرقام مرتبة؟
- هل هناك أكثر من duplicate؟
- هل المسموح استخدام memory إضافية؟
- ما حجم البيانات؟
- هل السرعة أهم أم الـ memory؟
لاحظ الفرق.
واحد يبحث عن حل محفوظ. والثاني يحاول فهم شكل المشكلة أولًا.
وهذا الفرق الحقيقي.
تجربة صغيرة
عندك array:
[1, 2, 3, 4, 4]
المطلوب إيجاد الرقم المكرر.
أغلب الناس مباشرة تفكر:
HashMap
أو:
Two Pointers
لكن هذا ليس أول سؤال.
أول سؤال يجب أن يكون:
- هل يوجد مكرر واحد أم أكثر؟
- هل الأرقام مرتبة؟
- هل أستطيع استخدام memory إضافية؟
- ما حجم البيانات؟
لاحظ ما الذي حدث.
أنت لم تقترب من الحل بعد.
لكنك أصبحت أقرب لفهم المشكلة.
وهذا بالضبط ما يفعله المبرمج القوي.
المشكلة ليست بالكود
كثير من الناس يظن أن المشكلة بالـ syntax.
لهذا ينتقل من:
- JavaScript
- إلى Python
- إلى Go
- إلى Rust
ويعتقد أن اللغة القادمة ستجعله أفضل.
لكن بعد فترة… يكتشف أن نفس المشكلة ما زالت موجودة.
لأنه لم يغيّر طريقة التفكير.
البرمجة ليست كتابة كود فقط.
البرمجة:
- تحليل
- تقسيم
- ملاحظة patterns
- فهم constraints
- اتخاذ قرارات
- التعامل مع الغموض
وهذا ما يجعل المبرمج قويًا فعلًا.
أول Mental Model
لا تبدأ بالسؤال:
“كيف أحل المشكلة؟”
ابدأ بالسؤال:
“كيف أفهم المشكلة صح؟”
لأنك إذا فهمت المشكلة فعلًا… فأنت أنهيت نصف الحل.
وهنا فلسفتي في البرمجة.
البرمجة ليست كتابة كود.
البرمجة طريقة تفكير.
ولهذا السبب شخصان قد يعرفان نفس اللغة ونفس framework.
لكن أحدهما يحل المشكلة خلال دقائق... والآخر يضيع لساعات.
الفرق ليس بالمعلومات.
الفرق بطريقة التفكير.
تمرين اليوم
اليوم لا أريدك أن تحل مشكلة.
اليوم أريدك أن تركز على فهم المشكلة فقط.
خذ ورقة وقلم أو افتح ملف ملاحظات.
اختر أي مشكلة برمجية واجهتها أو تجدها في الإنترنت.
لا تكتب أي كود.
بدلًا من ذلك، ابدأ بالإجابة على هذه الأسئلة:
- ما المطلوب بالضبط؟
- ما هي القيود التي يجب أن ألتزم بها؟
- ما الحالات التي قد تكسر الحل؟
- ما الأشياء التي لا أعرفها بعد؟
- كيف يمكنني تقسيم المشكلة إلى أجزاء أصغر؟
- هل يمكنني تبسيط المشكلة أو إعادة صياغتها بطريقة أوضح؟
كرّر هذه الخطوات حتى تشعر بأنك تفهم المشكلة بشكل أعمق.
هذه العادة ستغير طريقة تعاملك مع أي تحدي برمجي.
وهذه أول عادة سنحاول كسرها خلال هذه السلسلة.
أخطاء شائعة تدمر الـ Problem Solving
1. القفز للكود بسرعة
السرعة هنا ليست ذكاء.
غالبًا هي خوف من التفكير.
2. تجاهل الـ edge cases
كثير من الحلول تبدو صحيحة… حتى تأتي حالة صغيرة تكسر كل شيء.
3. محاولة حفظ الحلول
الحفظ يعطي شعورًا مؤقتًا بالقوة.
لكن أول مشكلة جديدة… تكشف الحقيقة.
4. ربط الثقة بمعرفة الحل مباشرة
المبرمج القوي لا يخاف عندما لا يعرف الحل.
لأنه يعرف كيف يبدأ التفكير.
وهذا أهم بكثير.
الخلاصة
إذا أول حركة تعملها لما ترى problem هي فتح VS Code… فأنت غالبًا بدأت غلط.
المبرمج الحقيقي لا يهرب للحل.
هو يفهم:
- المشكلة
- القيود
- الحالات
- التعقيد
- النظام كامل
قبل أن يكتب أي شيء.
وهنا يبدأ الـ Problem Solving الحقيقي.
1:1 Mentorship
إذا بدك تبني طريقة التفكير هاي بشكل حقيقي… وتتعلم كيف تفكر كمبرمج يبني systems ومنتجات حقيقية — تقدر تشتغل معي 1:1.