إلى كل UI/UX Designer وأي واحد يشتغل في المجال السوفتوير...
الـ AI مش جاي ياخذ مكانك، الـ AI جاي يفضحك! أيوه والله، الـ AI بيورّي الناس كلها إن أي حد يقدر يسوي اللي تسويه إذا كان شغلك بس تنفيذ وأدوات.
يعني لما تجي تصمّم لعيادة أسنان، مش تفكر كيف تخلي شكل السِنة حلو وبس، لا، تفكر في إحساس الشخص اللي خايف يروح للدكتور، تفكر كيف تطمّنه من أول ما يشوف التصميم.
شغلتك مش صورة وبس، شغلتك توصّل إحساس! تحرّك قرار، مش مجرد شكل. وهذا شيء الـ AI ما يقدر عليه.
الشطارة اليوم مش إنك تعرف تستخدم الأدوات! الشطارة إنك تكون مفكّر بصري، تفهم كيف تحل مشاكل حقيقية في السوق، تكون فاهم سيكولوجية المستخدم، تكون دارس تسويق، تقرأ، تسأل، تفكّر، تجرّب، تغلط، وتقوم تشتغل من جديد.
اللي الـ AI مستحيل يسويه هو طريقة تفكيرك… كيف تفكّك المشكلة؟ كيف تربط بين فكرة العميل واحتياج الناس؟ كيف تعرف متى تستخدم الأحمر… ومتى لا؟ كيف تخلي تجربة المستخدم سلسة من أول ما يشوف التصميم لحد ما يضغط على الزرار؟
هذا شغلك، وهذا الفرق بينك وبين AI.
#التصميم_مش_أدوات #فكر_قبل_ما_تصمّم #AI_مايقدر_يفكر_مكانك

طيب، اليوم لما نجي نتكلم في أي موضوع، لازم نحدد حاجة مهمة: من اللي بيتكلم؟ ومن اللي بيسمع؟ تمام؟ يعني، ممكن تكون بتتكلم مع شخص مبتدئ، أو شخص فاهم ومتخصص. وكذلك اللي بيتكلم نفسه، ممكن يكون فاهم، وممكن يكون مش فاهم. فالكلام اللي بتقوله بيختلف حسب المجتمع اللي بتخاطبه.
خلونا ناخذ مثال من الواقع:
أنت ساكن في بيت، ومقفل بقفل تمام. مقتنع إن القفل هذا بيحمي بيتك من أي حد يدخل؟ طيب، لو المفتاح حق القفل يقدر أي حد يعمله عند الحداد اللي تحت البيت ب ٣٠٠ ريال؟
لو جيت تقول "أنا مركب قفل بيحمي البيت"، هذا كلام ينفع تقوله لأطفال في أولى ابتدائي. لكن لو بتكلم مندوب شركة تأمين، لازم تقوله بطريقة ثانية: "أنا عندي قفل بيحمي بيتي من أي حد ما مابش معه ٣٠٠ ريال يشتري المفتاح من الحداد اللي تحت". لكن لو المفتاح مرمي قدام الباب، فأنت ساعتها بتقول: "القفل بيحمي البيت من أي سارق أعمى"، لأنه أي سارق عادي بيشوف المفتاح ويفتح الباب.
طيب، لو ما فيش حداد، وأنت ساكن في الدور الأرضي وشباكك مفتوح؟ هل القفل بيحمي البيت؟ لا، لأن الشخص مش محتاج يدخل من الباب أصلاً، يدخل من الشباك. لكن لو الشباك صغير وما يقدر يدخل منه إلا الأطفال، ساعتها بتقول: "بيتي محمي من أي حد وزنه أكثر من ٢٥ كيلو".
كل هذا نفس الفكرة، نفس القفل، بس طريقة الكلام تختلف حسب اللي بيسمع. وهذا هو اللي يربطنا بالموضوع الأساسي: الناس اللي تتكلم عن الأمان (Security) والحماية (Protection)، وما تفهم الفرق بينهم.
في بعض الناس لما تستخدم "const" أو تعدل في بعض الفيلدات، تقول: "إحنا كذا أمنّا البيانات عشان ما حدش يعدلها". طيب، هل فعلاً هذا يمنع أي حد من التعديل؟ خلونا نشوف.

عندك ثلاث أنواع من الناس يتعاملوا مع الكود حقك:

زملاؤك في الفريق: عندهم وصول مباشر للكود، ولو عايزين يعدلوا حاجة، بيعدلوها. مش لأنك عملتها "const"، بل لأن الشركة عندها سياسة مراجعة للكود، واللي ما يوافق عليه الـ Code Review ما يتم.

الأطراف الخارجية: بغض النظر عن أي حماية تسويها، كل لغة برمجة تقدم طرق للوصول للبيانات والتعديل عليها. مثلاً، في C++ ممكن يرمي الكائن كله داخل Pointer ويعدل فيه، وفي C# و Java عندك Reflection.

المستخدم النهائي: التطبيق لما يشتغل، النظام يشوف البيانات كأنها بيانات في الذاكرة، أي شخص معه Debugger أو Memory Viewer يقدر يعدل عليها.

بالتالي، لو كان هدفك تمنع أي تعديل، فشلت فشل ذريع، لأن أي حد يتعامل مع السيستم حقك يقدر يغيره.

وهنا نرجع للفرق بين الأمان والحماية:

Security (الأمان): أنك تمنع حد ما تريده يغير البيانات.

Protection (الحماية): أنك تمنع التغييرات غير المقصودة.

مثال:

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



الفرق بين Data Protection و Data Security كبير جداً، وللأسف بعض الناس اللي يقولوا عن نفسهم متخصصين ما يفرقوا بينهم. كل اللي يعرفوه هو إنهم "بيمنعوا الناس من التعديل"، وهذا كلام ممكن يجي من شخص ما يعرف برمجة أصلاً.
فالنهاية: إذا كانت الكبسولة (Encapsulation) ما قدرت تمنع التعديل تماماً فهي فشلت من أول مبدأ في الـ OOP وانتهى الحوار!

#عيد_انتبه_لمنزلك
#رسالها_100_معيد_ودكتور

تعلم كيف تتعلم ! لو صببت الحليب قبل الشاهي أو العكس هل في فرق ؟

موضوع الأمن السيبراني مش قصة tools  مدري ايش عندما حتى تدخل المجتمعات هذا أو أي جانب منهم حتى عندما تدخل معهم تفقد الثقه الموضوع ليس هذا والامن والحماية مبني على أساس قوي وبلاش تضيع وقتك في اختراق شبكة جارك أو أين كان طبعا هذا ليس اختراق والا تتعب في ال social engineering و الويب dark  هم من عمل التكنلوجيا وفر الكل واحد سوق ومستفيد من الكل المتهبشين والي لا يعرف القانون فتح له سوق والي ماشي بالقوانين وفر له كذلك تعلم برمجة صح وكل خطوة فكر ازي تحميها  .
#ازي_وضع_الأمن_السيبراني

في الإمتحانات online يتم إعتماد طريقة غش متعارف عليها عند أي شخص في مجال IT
تنصيب بيئة virtualisation ك VMware أو virtual box.
ثم تصميم جهاز يتقاسم hardware مع النظام الأساسي (وينداوز مثلا)
ينصح استخدام OS ك Ubuntu على الجهاز الافتراضي.

بعد الانتهاء يتم اختيار مواصفات الشبكة بحيث يتم عزل التواصل بين الجهاز الاصلي و الحقيقي ،فيمكن اختيار خيار bridge adapter مثلا و نعطي الجهاز الافتراضي IP مختلف من الجهاز الأصلي .

بعد الانتهاء يتم فتح الايمايل الخاص بك في الجهاز الافتراضي و اجراء الامتحان عليه ، بينما يمكن عمل screen shoot للأسئلة و تنزيلها مباشرة على الجهاز الأم و البحث بحرية على الاجوبة بالذكاء الإصطناعي.
الطريقة الثانية هي مشاركة واجهة الحاسوب مع شخص آخر متصل مع حاسوبك حيث يمكنه الإجابة بدلا عنك حتى ولو كان بعيد بتقنيات ك RDP, team viewer,x11forwarding +SSH, . و هي طريقة متعارف عليها في الجامعات الأوروبية خاصة لذلك فالاساتذة في جامعات اوروبا لا يزالون ليومنا هذا يعتمدون اختبار الورق.
الطريقة الثالثة هي عن طريقة الخدمات السحابية ،فيمكن إعداد Session Manager في AWS أو Bastion Host في Azure للسماح بالوصول عن بُعد.

#vmware #azure #aws #virtualisation #cloud #computing

شوف… في أشياء لو ما أحد تكلم عنها بوضوح، بتظل تتكرر وتكلفنا كثير بدون ما ننتبه. تخيل معاك نظام أكثر من واحد يستخدمه، وكلهم يشتغلوا على نفس البيانات بنفس الوقت… أنا أشوفها كل مرة: واحد عدّل، والثاني عدّل، وكل واحد يظن إنه اشتغل لحاله، والنتيجة؟ تضارب، بيانات ضاعت، أو أحد كتب فوق الثاني. ولا أحد درى.

وهنا تظهر فكرة يسموها "Optimistic Locking"، بس هي مش مسألة اسم أو مصطلح… هي فكرة ببساطة تقول: "تأكد إنك آخر واحد شاف البيانات قبل ما تغيّر فيها."

يعني بدل ما نقفل البيانات ونمنع الكل يعدل (زي Pessimistic Locking)، نخلي الكل يشتغل بحرية… لكن نحط شرط بسيط: إذا أحد سبقك وعدّل، ما نسمح لك تحفظ إلا لما تشوف التحديث الجديد.

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

بالنسبة للتعديل (PUT أو PATCH) لما ترسل الطلب، تحط الهيدر If-Match: "" وتقوله: "أنا بأعدّل، بس فقط لو البصمة هذي نفسها ما تغيّرت." لو تغيّرت؟ السيرفر يرد عليك بـ:

412 Precondition Failed "يعني أحد سبقك وعدّل، لازم تسحب التحديث الجديد وتشوفه أول، بعدين قرر."

والنقطة اللي ناس كثير ما ينتبهوا لها هي حتى عند القراءة (GET) تقدر تحط If-None-Match: "" وهنا تقول للسيرفر: "عطني البيانات فقط لو تغيّرت من آخر مرة." لو ما تغيّرت؟ السيرفر يرد بـ:

304 Not Modified "يعني لا ترجع لي نفس البيانات مرة ثانية، وفر علي البيانات والباندويث."


وش الفايدة؟ فايدتها قوية جدًا في الأنظمة الكبيرة أو اللي فيها بيانات تتكرر كثير. بدل ما كل شوي تجيب نفس البيانات من السيرفر، تستخدم ETag وتخليها كمرجع، وإذا البيانات نفسها؟ السيرفر يقول لك: "مافي جديد"، وأنت ترتاح.

تخيل آلاف الأجهزة تشيك بيانات بنفس اللحظة، لو كلها سحبت البيانات من جديد وهي نفسها؟ ضياع وقت وضغط على السيرفر بلا معنى. لكن مع ETag و If-None-Match؟ تقليل هائل في الاستهلاك، وتحسّن في الأداء، وكل هذا بصمت وذكاء.

والمقارنة هنا مع العكس تمامًا:
لو تجاهلت الـ ETag وفكرت تعدّل بدون أي تحقق، فاحتمال كبير تعدّل على بيانات قديمة بدون ما تدري، والنتيجة: بيانات ضاعت، أخطاء حصلت، أو تقارير صارت فيها تناقضات.

ولو في الـ GET تسحب البيانات في كل مرة بدون ما تسأل إذا تغيّرت؟ يضيع عليك وقت، موارد، وسرعة… والنتيجة تجربة مستخدم بطيئة ومتكررة بدون فائدة.

الخلاصة؟ مش لازم توقف الناس من التعديل، ولا تمنعهم من الوصول، بس خلي بينهم وبين الحقيقة شرط بسيط: "تأكد إنك ما تشتغل على شي قديم."

وهذا الشيء، رغم بساطته، يحل مشاكل كثيرة ويخلي النظام أذكى وأرتب، ويحمي بياناتك من الضياع بصمت.

ونقطة أخيرة… مش كل تعقيد في الكود شر، أحيانًا سطر واحد زي If-Match أو If-None-Match يحميك من أيام من التحقيق في bugs ما حد داري من فين طلعت.

ما تتعامل مع ETag؟ يعني أنت تسحب بيانات "تظن" إنها صحيحة… وتعدل على شيء "تفترض" إنه ما تغيّر… بينما النظام يقول لك: "أنا ما أقدر أضمن لك شيء."

#التزامن_مش_ترف #OptimisticLocking #DotNet #كود_يعيش_طويل #خلي_الكود_يحميك_مش_يعلقك

أهمية مراجعة الكود Code Review ستزداد في الفترة المقبلة مع الإعتماد المتزايد على الذكاء الإصطناعي التوليدي.
الوقت الذي نربحه في كتابة الكود بفضل ال AI سيسخر فيما بعد لقراءة ومراجعة وإعادة ترتيب ذلك الكود (قانون انحفاظ الطاقة 😀).
هناك مقولة في عالم البرمجة (منسوبة لمصمم لغة بايثون) تقول أن "الكود يُقرأ أكثر مما يُكتب"، ويبدو لي أنها عبارة سنسمعها أكثر وسيكون لها مسوعات أقوى في المستقبل القريب.

#الموضوع_كبير

سؤال في احد المقابلات الوظيفيه سؤال معرفة طريقة تفكيرك

في البداية x مجهول
داخل الwhile ايش المعادلة التي عندما نطبع x يطلع لي 4545454545....

int x=?

while(true)
{

x =??;

print x ;
}
Output
4
5
4
5
4
5
4
الخ ب يهنق البرنامج ع قولت المصريين

حاليآ الكثير من الطلاب والطالبات ما يعرفون اين يتجهون في مجال البرمجه بعد انتهى سنه اولى.


الحل بيدك:
1-السؤال اي شخص له خبره كبيره ف البرمجه.
2-البحث والإطلاع وهاذا اهم نقطة.
3-الحل الاخير اسأل نفسك لماذا دخلت التخصص هاذا ،اذا ما تقدر تجاوب عن هاذا السؤال فنصيحه فلتغادر هاذا التخصص.


وشكرا...

اختصار البرمجه في كلمتين من وجهة نظري:

knowledge معرفة

innovation ابتكار

🔶 4 قواعد للنجاح :

1 - لا يمكنك الفوز إلا عندما يكون عقلك أقوى من عاطفتك ...
2 - الإنضباط يؤدي إلى العادات.. العادات تؤدي إلى الإستمرار ..الإستمرار يؤدي إلى النمو ..

3- كلما كنت أكثر هدوءأ كلما كانت أفكارك أكثر وضوحا تحرك باستراتيجية وليس بعواطف.

4- الأعذار تجعل اليوم سهل ولكن الغد أصعب، الإنضباط يجعل اليوم صعبا ولكن الغد أسهل.

ليه ممكن تحتاج Message Broker في النظام حقك؟
خلينا نرجع خطوة لورا.
لو إنك تبني web server، كيف بيتعامل مع عدد كبير من الـ requests؟
بيحصل ذا عن طريق إنه يحطهن في queue في الذاكرة،
لأنه لو فتحت thread لكل request، ممكن النظام ما يقدرش يتحمّل العدد الكبير ذا، وكلهن يفشلن (بسبب context switching).
عشان كذا وجود queue بيساعد إنك تتحكم بعدد الـ requests اللي النظام شغّال فيهن بنفس الوقت، والباقي ينتظر دوره في الـ queue.
وطبعًا تقدر تكبّر النظام باستخدام load balancer وتزيد عدد الـ instances، وذا بيخليك تستقبل وتنفذ عدد أكبر من الـ requests،
طالما ما فيش bottlenecks ثانية.
بس إيش المشكلة هنا؟
أولًا، كل ذا داخل الذاكرة، يعني لو حصل restart فجأة، الـ requests اللي في الطابور بتروح.
وثاني حاجة، لسه في حدود للذاكرة حق كل instance،
والـ queue لازم يكون له حجم معيّن عشان تتجنب مشاكل زي memory leak.
ولو امتلى الـ queue، بتبدأ ترفض الـ requests وبتخسرهن.
هنا يجي دور الـ Message Broker، بيقدم لك عدة فوائد:
أولًا، عندك نظام ثاني يضمن إن الرسائل ما تروح، تقدر ترسل الرسالة هناك وتجي تستهلكها وقت ما يكون في thread متاح.
ولو السيرفر حصل له restart، الرسائل تظل موجودة، ما تروح.
ثانيًا، السيرفر حقك يقدر يستقبل الـ request ويرسله للـ message broker،
وهذا أسرع بكثير من تنفيذ الطلب على طول.
وبالتالي تقدر تتعامل مع عدد أكبر من الـ requests بسهولة وتنفذهن لاحقًا.
لكن في أسئلة مهمّة:
كنت ترسل request وتنتظر الرد عشان تعرضه للمستخدم،
الحين بتحتاج تغير هذا الشي، وتستقبل الرد من الـ back-end عن طريق WebSocket أو Server-Sent Events.
هل ممكن الرسائل تروح لو الـ message broker حصل له restart؟
هنا تقدر تضمن إنك تخزن الرسائل بشكل durable،
ومعظم الأنظمة ذي تدعم cluster mode عشان تضمن إنها دايمًا شغّالة (high availability).
هل ضروري أستخدم Message Broker؟
مش دايمًا. في طرق ثانية، مثل إنك تسوي retry من الـ client side،
بس لازم تضمن حاجات زي idempotency وexponential backoff.
لكن الـ message broker بيساعدك كثير لو النظام حقك عليه ضغط كبير جدًا.
كل ذا يعتمد على استخدامك ونوع النظام اللي تبنيه.
لأن استخدام أدوات زي message broker لها فوائد،
لكن كمان فيها تعقيد، من ناحية التكلفة أو الصيانة.
وهو مش حل سحري بيحل لك كل المشاكل.
في مشاكل ثانية بتحتاج تتعامل معها، زي كيف تضمن إن الرسالة وصلت،
أو كيف تحسن الأداء حق الـ consuming، ومشاكل ثانية غيرها.


#البرمجة #تصميم_الأنظمة #MessageBroker #نصائح_للمطورين #هندسة_البرمجيات #برمجة_ويب #أداء_عالي #نظام_موزع #تقنيات_حديثة

بتشوفوا كثير هالأيام ناس يقولوا "تبني تطبيق كامل في ساعتين أين كان ".
الكلام ذا مش كذب، بس خذوها بعقل.

ما حد قال إنك بتسوي ERP يحل مشاكل المحاسبة وإدارة الموارد، وتخلي أوراكل أو غيرها ترجع بيتها!

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

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

استخدموا عقولكم، هي أغلى نعمة، لا تضيعوها.

الجامعة هي الفرصة الي من خلالها تتعلم أشياء كثيره  فستغلها بكل طاقتك كلامي ليس تطلع الأول وتكون تنين الدفعة 💁‍♂️

ما هي بعض الحقائق العظيمة عن البرمجة؟

·√ المبرمج لا يقوم بإصلاح أجهزة الكمبيوتر

·√ البرمجة تعني التفكير وليس الكتابة.

·√العد يبدأ من صفر وليس من واحد.

·√ حتى بعد الانتهاء من الحصول على درجة علمية وانهاء الدورات والعمل على مشاريع ، فإن التعلم لا يتوقف أبدًا. إذا كنت تريد أن تظل قادرًا على المنافسة ، فيجب عليك أيضًا العمل على مشاريع شخصية تجبرك على استخدام لغات وبرامج لم تستخدمها أبدًا في الوظيفة.

·√لست بحاجة إلى مهارات رياضية متقدمة لتصبح مطورًا. ومع ذلك ، ستحتاج إلى اساسيات الجبر ، والمنطق ، ومهارات حل المشكلات ، والأهم من ذلك كله ، الصبر.

·√ لست بحاجة إلى شهادة لكي تكون مطورًا - البرمجة مثل أي مهنة تقريبًا: إذا كنت جيدًا فيها ، فسوف يدفع لك الناس مقابل مهاراتك ، بغض النظر عن كيفية وصولك إليها.

·√النوم مع مشكلة برمجية يمكن أن يحلها بالفعل.

🤔💡 بتواجه مشاكل في حل المسائل ال problem solving ؟ مش عارف تبدأ منين؟

على منصة NeuroTech، وفرنالك مسار متكامل لتعلم Problem Solving.
هيساعدك تفكر بشكل منطقي ومنهجي لحل أي مشكلة برمجية بكفاءة👌🏻

📌 إيه اللي هتتعلمه؟
✅ إزاي تحلل المشكلة وتحدد الحل الأفضل؟ 🧐
✅ الalgorithms وData structure الأساسية 🛠️
✅ طرق تحسين الأداء وحل المشاكل بكفاءة عالية ⚡
✅ تطبيق عملي على مسائل حقيقية ومسابقات برمجية 🏆

🎯 لو عايز تطور مهاراتك في Problem Solving، ده المسار اللي هيخليك جاهز لأي تحدي

🔗 ابدأ رحلتك الآن:
www.neurotecheg.com/ar/حل-المشكلات

#ProblemSolving #Coding #Algorithms #NeuroTech #حل_المشاكل #neurotechplatfom #منصة_نيوروتك

يتعلم الإنسان بطريقتين:
القراءة

ومصاحبة منهم اذكى منه!

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

صدقني، هالأسلوب يخسّرك كثير. لأنك لما تلبس قناع الفاهم، تحرم نفسك من فرصة حقيقية للتعلم. يمكن صاحبك عنده خبرة، أو مرّ بتجربة، أو قرأ شيء مفيد، ولو سألته وقلت له: "صراحة أول مرة أسمعها، ممكن توضح لي؟" — راح يقدّرك ويحترم فيك رغبتك في الفهم.

لا تخلي الكبرياء يمنعك من إنك تطور نفسك. مافيش إنسان يعرف كل شيء، والعلم عمره ما كان عيب، العيب إنك تتهرب من الفهم علشان ما يبان إنك مش عارف.

خليك دائمًا من النوع اللي يسأل، ويفهم، ويتواضع. التواضع في طلب العلم رفعة، مو نقصان. واللي يسأل اليوم، بكرة يكون هو اللي يُسأل.

في فرق كبير جدًا بين إنك تكون Developer وإنك تكون Software Engineer…
الـ Developer ممكن يشتغل على كتابة الكود وتنفيذ المطلوب، لكن الـ Software Engineer الحقيقي هو Problem Solver… شخص بيفكر قبل ما يكتب، وبيفهم المشكلة بعمق قبل ما يتحرك.
في بداية أي طريق في البرمجة، بيكون التركيز كله تقريبًا على الأدوات:
اتعلم لغة كذا، خُش في فريمورك كذا، ابني مشروع، حل مسائل...
لكن قليل جدًا اللي بيقولك إن البرمجة مش هدف، دي وسيلة.
وإنك ممكن تكتب كود قوي، لكن ما تكونش مهندس برمجيات ناجح.
في فرق كبير بين Software Developer وSoftware Engineer.
الـ Developer ممكن يكون بيعرف يكتب كود ينفذ المطلوب حرفيًا.
لكن الـ Software Engineer، قبل أي سطر كود، بيفكّر:
– ليه بنعمل ده؟
– إيه المشكلة أصلًا؟
– وإيه أبسط حل ممكن يتنفذ؟
– وهل محتاجين فعلًا نكتب كود؟ ولا الحل أبسط من كده بكتير؟
الـ Engineer بيفهم إن كل سطر كود هو عبء مستقبلي.
الكود اللي هتكتبه النهاردة، هو نفسه اللي هتصينه، وتراجع فيه Bugs، وتدافع عنه وسط Production Crashes بعد شهور.