اللغة الإنجليزية التقنية: أن تُفهم، لا أن تُسمع فقط

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

لماذا القواعد النحوية ليست العائق

المتحدثون الأصليون يكتبون تذاكر مربكة طوال الوقت. المشكلة عادةً البنية، لا المفردات. رسالة مثل "API يتصرف بشكل غريب مرة أخرى، قد يكون مرتبطاً بذلك الشيء من أمس" تفشل بغض النظر عن اللهجة أو درجة القواعس. قارنها بـ: "POST /users/create يرجع 500 منذ 14:02 UTC. بدأ بعد نشر أمس (commit a3f9c1). السجلات مرفقة." تعمل النسخة الثانية لأنها تضع الحقيقة في البداية، وتعطي طابع زمني، وتسمي السبب المشبوه. أي شخص يقرأها، في أي منطقة زمنية، يعرف ما يجب فعله بعد ذلك.

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

أشكال الجمل الثلاثة التي تغطي 90% من كتابة العمل

معظم التواصل التقني يندرج في ثلاثة أنماط:

1. البيان + الدليل — "نقطة نهاية تسجيل الدخول تفشل بشكل متقطع. معدل الخطأ هو 3% خلال الساعة الماضية، كلها 502s، كلها من us-east-1."
2. السؤال + القيد — "هل يمكنك مراجعة تغيير قاعدة جدار الحماية قبل الساعة 4 مساءً؟ إنه يحجب النشر."
3. القرار + السبب — "نحن نعود إلى v2.3.1. معدل حدود الطلب الجديد يسقط حركة المرور الشرعية."

احفظ هذه الأشكال وستتمكن من كتابة أي شيء تقريباً قد تحتاجه standup أو تذكرة أو postmortem دون الوصول إلى مفردات معقدة. المفردات المعقدة هي عادةً حيث يفقد المتحدثون غير الأصليين الوقت والثقة — البحث عن