تکنیکی انگریزی: سمجھا جانا، نہ کہ صرف سنا جانا

کام پر ہونے والی بیشتر تکنیکی غلط فہمیوں کا گرامر سے کوئی تعلق نہیں۔ ایک ٹکٹ غلط پڑھا جاتا ہے، ایک Slack پیغام نظر انداز ہو جاتا ہے، ایک standup اپڈیٹ سب کو اس بات میں الجھا دیتا ہے کہ اصل میں کیا ہوا۔ اگر آپ نے سیکیورٹی یا dev ٹیمز پر کام کیا ہے جہاں درجنوں مختلف ممالک کے لوگ ہوں، تو آپ کو پہلے سے معلوم ہے کہ حقیقی مہارت روانی نہیں ہے — یہ وقت کے دباؤ میں درستگی ہے۔

گرامر بتل نہیں ہے

مقامی بولنے والے مسلسل الجھائو ٹکٹس لکھتے ہیں۔ مسئلہ عام طور پر ساخت ہے، الفاظ نہیں۔ ایک پیغام جیسے "the API is being weird again, might be related to that thing from yesterday" ناکام ہوتا ہے قطع نظر لہجے یا گرامر اسکور کے۔ اس کا موازنہ کریں: "POST /users/create returns 500 since 14:02 UTC. Started after yesterday's deploy (commit a3f9c1). Logs attached." یہ دوسرا ورژن کام کرتا ہے کیونکہ یہ حقیقت کو آگے رکھتا ہے، ایک ٹائم سٹیمپ دیتا ہے، اور مشکوک وجہ کا نام دیتا ہے۔ کوئی بھی اسے پڑھتے ہوئے، کسی بھی ٹائم زون میں، جانتا ہے کہ اگلا قدم کیا ہے۔

یہ تقسیم شدہ اور سیکیورٹی ٹیمز میں لگ بھگ کسی اور جگہ سے زیادہ اہم ہے۔ 3am پر ایک incident response چینل میں احتیاط کی زبان یا لمبی سیاق و سباق کے لیے گنجائش نہیں ہے۔ اگر انگریزی آپ کی پہلی زبان نہیں ہے، تو آپ کو یہاں فائدہ ہے: آپ پہلے سے ہی سوچنے پر مجبور ہیں کہ آپ اصل میں کیا کہنا چاہتے ہیں۔ مقامی بولنے والے اکثر اس مرحلے کو چھوڑ دیتے ہیں اور بکواس کرتے ہیں۔

تین sentence شکلیں جو کام لکھنے کا 90% احاطہ کرتی ہیں

زیادہ تر تکنیکی مواصلات تین نمونوں میں فٹ ہوتا ہے:

1. State + evidence — "The login endpoint fails intermittently. Error rate is 3% over the last hour, all 502s, all from us-east-1."
2. Ask + constraint — "Can you review the firewall rule change before 4pm? It's blocking the deploy."
3. Decision + reason — "We're rolling back to v2.3.1. The new rate limiter is dropping legitimate traffic."

ان شکلوں کو یاد رکھیں اور آپ لگ بھگ کچھ بھی لکھ سکتے ہیں جو ایک standup، ٹکٹ، یا postmortem کو بغیر فخر والی لغت تلاش کیے ضرورت ہے۔ فخر والی لغت عام طور پر وہ جگہ ہے جہاں غیر مقامی بولنے والے وقت اور اعتماد کھوتے ہیں — شاندار الفاظ تلاش کرتے ہوئے۔