المبرمجون لديهم أقوال مختلفة حول المشاكل الصعبة. ربما خياري المفضل : "هناك مشكلتان صعبتان في علوم الكمبيوتر: إبطال ذاكرة التخزين المؤقت والتسمية والخطأ لكل وحدة".

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

وهذا صعب للغاية.

كما هو الحال في جميع المجالات المهنية ، طور المبرمجون مصطلحاتهم الخاصة لنقل المفاهيم بسرعة.

Technolepet

المصطلحات مهمة جدا. إذا اخترت أنا وزميلي خوارزمية لحل مشكلة معينة ، فيمكننا القول "الخيار الأول O(n^2)مع الحد الأدنى من النفقات العامة من البداية ، والثاني يتم استهلاكه O(n log n)، ولكن مع التثبيت والتكوين المكلفين" .

تقول هذه الجملة المفردة الكثير ، ما هي السيناريوهات التي يجب استخدام الخوارزمية وكيف يتم تنفيذها تحت غطاء المحرك:

الخيار A رائع لنظام مع كمية صغيرة من المدخلات.
يعتبر الخيار B رائعًا للعمل مع كمية كبيرة جدًا من بيانات الإدخال ، حيث سيتم تعويض التكاليف المرتفعة لتثبيت النظام وتكوينه بأداء أفضل في العملية.
إذا كنت تنوي استخدام الخوارزمية في حلقة ، فيجب عليك تحديد الخيار الأول لتجنب تثبيت رمز وتكوين باهظة الثمن.
ربما يمكننا تقليل تكلفة تثبيت الخيار B باستخدام التخزين المؤقت.
ربما ، في الخيار A ، تتم مقارنة كل عنصر من عناصر الإدخال مع جميع العناصر الأخرى (على سبيل المثال ، for x in inputs { for y in inputs { if some_condition(x, y) { ... }}}).
ربما يقوم الخيار B بإنشاء شجرة أولاً ، ثم يقوم بإجراء بحث خطي ، يتبعه بحث في هذه الشجرة.

كما ترون ، تمكنا من نقل عدة فقرات من المعلومات في جملة واحدة ، ببساطة باستخدام المصطلحات الصحيحة.

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

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

هذا ما أسميه تكنولث ، غموس مبرمج.

بصراحة ، عادة ما لا يحتاج الأشخاص من مناطق أخرى إلى هذه التفاصيل والشروط ، وهم لا يهتمون حقًا.

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

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

لا يهم أننا نستخدم البحث A * هنا (على عكس خوارزمية Dijkstra أو البحث بالعرض). لا يهم أنه في الألعاب ، يتم استخدام البحث * ليس فقط لتحريك الشخصيات. يكفي أن يعرف المحاور أنه يمكنك العثور على طريقة جيدة من A إلى B وأننا نستخدم أدوات موثوقة تم اختبارها بالفعل في مجالات أخرى.

لا يؤلمني إظهار توضيح لما تعنيه ...

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

لا تفهم الأمر بشكل خاطئ ، في بعض الأحيان تكون هناك حالات يسأل فيها محاور كفؤ بما فيه الكفاية: "هذا صعب للغاية ، لماذا لا تجعل X فقط؟" - وعليك أن تثبت أنك خبير هنا ، لكنه لا يعرف ما يتحدث عنه ... ولكن لا يزال بإمكانك القيام بذلك بطرق مختلفة.

لا تحاول استخدام تكنولوبيت لإرضاء نفسك ، فهي تنبذ الناس وتشوه مهنتنا.

احترام

لذا ننتقل تدريجيًا إلى النقطة التالية ... لا تنسى الاحترام.

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

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

غالبًا ما أجاب مهندس البرمجيات الذي ذكرته عن ذلك: "إنه ... معقد" عندما سأل شخص "عادي" عن كيفية عمل هذه الوظيفة أو تلك. يبدو الأمر كما لو كان الرمز معقدًا جدًا لدرجة أنه بدون 20 عامًا من تجربة البرمجة لا يمكنك فهمه.

لا تقم بمثل هذا.

أفضل إجابة:"إذا قمت بتبسيط الأشياء قليلاً ، فعندئذ نقوم بعمل X ، ثم نفعل Y ، وأخيرًا نقوم Z ، ولكن عليك أن تضع في اعتبارك عشرات المواقف الحدودية (ربما تشرح واحدة أو اثنتين) ، لكن الجوهر هو هذا . " إن زملائك أذكياء وبدون المصطلحات التقنية قادرون تمامًا على فهمك.

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

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

التجسيد والمبالغة والقياس

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

لنفترض أن شركتك لديها نظام شراء عبر الإنترنت. يريد المسوق فهم السلسلة بأكملها من الطلب عبر الإنترنت إلى تسليم الطرد من أجل الإجابة على أسئلة العملاء بشكل أفضل. يمكنني قول شيء كهذا:

, . www.example.com, «» ( -, ).

(-). , () . , , , (, ).

( ), , . , , ( — , ), .

( ) . , , .

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

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

هذا اختلاف دقيق ، لكننا نقوم بتجسيد الخوارزمية. نقول إنه "يريد حقاً أن يجعل X" أو "يحاول جاهداً أن يتجنب Y". غالبًا ما يساعد ذلك الناس على الفهم .

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

ارسم صور جميلة

يبدو هذا مبتذلًا ، لكن أحيانًا تكون الصورة حقًا تساوي ألف كلمة.

قبل شهرين ، كنت أقرأ دورة في الراديو ، ولم تتذكر الفتاة القريبة الأزرار التي يجب الضغط عليها في قائمة شاشة LCD مقاس 16 × 2 صغيرة.

سألت إذا كانت تستطيع رسم رسم بياني.

ظنت أنني رجل ذكي وسخرت منها.

لكنني لم أكن أمزح.

بدلاً من ذلك ، وجدت قطعة من الورق ، وقمنا معًا بصنع شيء مثل هذا:

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

لكنها هي (وكل شخص آخر في هذه المرحلة) لا تهتم بالعلم. لقد حصلوا على خريطة يمكنهم استخدامها للتنقل في واجهة المستخدم.

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

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

قمت بتسريع ميزة $ عشرة أضعاف

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

من ناحية ، إلى السؤال عما فعلته الأسبوع الماضي ، يمكنك إخبار الشخص بالحقيقة: "أضفت ذاكرة التخزين المؤقت lookup_something ()لتسريع البحث العام وترجمة الخوارزمية من detect_collisions()c O(n^2)إلى O(n log n)" ، ولكن مع احتمال كبير أنهم لن يفهموا أي شيء (انظر تقنية ) .

يمكنك أيضًا أن تقول إنك "حسّنت الإنتاجية" ، لكنها تبدو كعذر ، وسيفكر المدير في سبب توظيفك.

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

في معظم الحالات ، قمت بالفعل بتحسين أداء العديد من الوظائف ، ولكن إذا لم تكن هذه الوظائف بمثابة اختناق في الأداء ، فمع احتمال كبير لن يرى أي فرق.

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

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

يبدو لي أنه من الأفضل محاولة إيجاد حل وسط بين الدقة والفهم. إذا أجريت تغييرًا يعمل على تحسين التعقيد الخوارزمي لجزء من التعليمات البرمجية (على سبيل المثال ، وظيفة تم detect_collisions()التبديل من O(n^2)إلى O(n log n)) ، فيمكنك القول:"يمكن أن تتحول الوظيفة X الآن إلى قدر كبير من المدخلات في فترة زمنية معقولة ، ولكنها لم تفعل ذلك من قبل . "

من الطبيعي أن تقول "لا أعرف" ...

... واستمر على هذا النحو: "... ولكن إذا أعطيتني خمس دقائق ، يمكنني أن أخبرك" .

كثيرا ما أرى هذا. يخاف الناس من إظهار جهلهم ، لذلك هم صامتون أو يعذبون أو يخترعون شيئًا ما.

على سبيل المثال ، إذا جاء إليك مدير وسأل: "طلب العميل الوظيفة X ، فهل هذا ممكن؟ وكم من الوقت سياخذ؟ "

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

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

هذه طريقة رائعة لفقدان احترام الزملاء والرؤساء.

من ناحية أخرى ، فإن عبارة "غير متأكد ، ولكن امنح 5-10 دقائق ، وسأحصل على إجابة" تظهر عدة أشياء في وقت واحد:

أنت على استعداد للاعتراف بأنك لا تعرف كل شيء (أي لست أنانية نرجسية).
أنت مسؤول عن كلماتك ولا تريد إعطاء إجابة غير دقيقة.
أنت تحترم الشخص بما يكفي لقضاء جزء من وقتك للمساعدة في الإجابة على سؤاله.
أنت رجل جيد :).

(ولديك الوقت الكافي لمعرفة ذلك).

يشبه المثل القديم :

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

تقاعد المهندس القديم ، وبعد بضعة أسابيع انهارت الماكينة الكبيرة ، وهو أمر مهم جدًا لدخل الشركة. لم يتمكن المدير من تشغيل الماكينة مرة أخرى ، لذلك دعت الشركة المهندس القديم كمستشار مستقل.

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

في اليوم التالي ، يتلقى المدير فاتورة من المهندس القديم مقابل 5000 دولار. المدير غاضب ويرفض الدفع. يؤكد المهندس القديم أن هذا سعر عادل. يرد المدير أنه إذا كان هذا سعرًا عادلًا ، فيمكنك طلب تفاصيل الحساب.

حساب جديد مفصل يبدو كالتالي ...

Hammer: $ 5

تعرف على مكان إصابة السيارة بمطرقة: 4995 $

يمكن لأي شخص جوجل أي سؤال. لكن مهندس البرمجيات فقط يعرف الكلمات الرئيسية التي يجب استخدامها وكيفية تفسير النتائج.

الموجودات

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

يُنظر إلى المبرمجين (ليس بدون سبب) كأشخاص لديهم مهارات اجتماعية واتصال ضعيفة. لكن جزءًا كبيرًا من عملنا يتطلب التواصل الفعال. آمل أن تجربتي ستساعدك في شيء.

قد يعتبر البعض أن هذا "سياسة المكتب" والتلاعب بآراء الآخرين. إليك ما سأجيب عليه:

نعم. ولكن هل هذا لا ينطبق على معظم التفاعلات الشخصية؟

يساعد علم النفس المبرمجين على التحدث بنفس اللغة مع غير المبرمجين ويعملون معًا لتحقيق هدف مشترك.

الكلام صعب. مقالات حول التواصل مع غير المبرمجين