AI کے دور میں اپنے پورٹ فولیو کو کیسے بلند کریں: ٹیکنیکل رائٹر سے لے کر ڈویلپر ایجوکیٹر تک

کچھ عرصہ پہلے تک، تکنیکی تحریری پورٹ فولیو بنانا اتنا ہی آسان ہوسکتا ہے جتنا کہ ویب سائٹ بنانا، مضامین کی فہرست شامل کرنا، اپنے تحریری تجربے کو بیان کرنا، اور اپنے سماجی پروفائلز سے لنک کرنا۔

یہ اب کافی نہیں ہے۔

ڈویلپرز AI اسسٹنٹ سے API کی تفصیل تیار کرنے، دستاویزات کا خلاصہ کرنے، ٹیوٹوریل آؤٹ لائن بنانے اور کوڈنگ آرٹیکل کا پہلا ورژن سیکنڈوں میں لکھنے کے لیے کہہ سکتے ہیں۔

اس سے تکنیکی مصنفین کی میز پر آنے والی تبدیلیاں آتی ہیں۔

ایک قابل قدر مہارت اب صرف تکنیکی طور پر درست جملے تیار کرنا نہیں ہے۔ یہ ٹیکنالوجی کو اچھی طرح سے سمجھنے کے بارے میں ہے کہ کیا لکھنا ہے، یہ جانچنا کہ ہدایات عملی طور پر کام کرتی ہیں، اس بات کی نشاندہی کرنا کہ ڈویلپرز کہاں جدوجہد کرتے ہیں، اور اس علم کو دستاویزات میں تبدیل کرنا ہے جسے کوئی لاگو کر سکتا ہے۔

یہ میری پورٹ فولیو ویب سائٹ کے پیچھے بنیادی خیال ہے۔

میں نے اسے صرف ایک آن لائن ریزیومے سے زیادہ بنایا ہے۔ میں آپ کو دکھانا چاہتا تھا کہ ڈویلپر کی تربیت سے کیسے رجوع کیا جائے۔

اس مضمون میں، میں وضاحت کرتا ہوں کہ میں نے اپنا پورٹ فولیو کیسے بنایا، اس کے پیچھے کی ٹیکنالوجی، میں نے ایپلیکیشن کی ساخت کیسے بنائی، میں نے اسے کیسے لگایا، اور AI کے اس دور میں ڈویلپرز کے لیے تکنیکی مصنف ہونے کے بارے میں میں نے پروجیکٹ سے کیا سیکھا۔

انڈیکس

تکنیکی تحریر میں کیا تبدیلی آئی ہے؟

آئیے بڑے سوال کے ساتھ شروع کرتے ہیں۔ تکنیکی مصنفین کو سافٹ ویئر ڈویلپمنٹ کو سمجھنے کی ضرورت کیوں ہے۔?

کیونکہ سامعین بدل چکے ہیں۔

API گائیڈز کو پڑھنے والے ڈویلپرز کو صرف کسی ایسے شخص کی ضرورت نہیں ہے جو وضاحت کر سکے کہ اینڈ پوائنٹ کیا کرتا ہے۔ آپ کو کسی ایسے شخص کی ضرورت ہے جو سمجھتا ہو کہ اینڈ پوائنٹس آپ کی درخواست میں کیسے فٹ ہوتے ہیں۔

ایک سادہ API کمانڈ پر غور کریں۔ POST /api/users

ایک نوآموز مصنف اس کی وضاحت اس طرح کر سکتا ہے:

یہ اختتامی نقطہ ایک نیا صارف بناتا ہے۔

یہ جملہ تکنیکی طور پر درست ہو سکتا ہے۔ تاہم، ڈویلپرز کو ابھی کچھ اور سوالات بھی ہو سکتے ہیں، جیسے:

• اختتامی نقطہ کو کس تصدیق کی ضرورت ہے؟

• آپ کو کن ہیڈرز کی ضرورت ہے؟

• درخواست کا جسم کیسا لگتا ہے؟

• کون سے فیلڈز کی ضرورت ہے؟

• اگر توثیق ناکام ہو جاتی ہے تو کیا ہوتا ہے؟

• کامیاب جواب کیسا لگتا ہے؟

• کیا اسٹیٹس کوڈ واپس کیا جاتا ہے؟

• اگر ای میل پہلے سے موجود ہے تو کیا ہوگا؟

• کیا اختتامی نقطۂ نظر غیر مقلد ہیں؟

• مجھے جاوا اسکرپٹ یا ازگر میں جواب کو کیسے ہینڈل کرنا چاہئے؟

اچھی ڈویلپر دستاویزات ان سوالات کے جوابات دیتی ہیں۔

یہ لکھنے کی مہارت سے زیادہ لیتا ہے۔ تکنیکی تحقیقات کی ضرورت ہے۔

یہی وجہ ہے کہ مجھے لگتا ہے کہ کردار پہلے سے بدل رہا ہے۔ تکنیکی مصنف کی طرف ڈویلپر معلم.

ڈویلپر ایجوکیٹرز صرف ٹیکنالوجی کی وضاحت نہیں کرتے۔ دوسرے ڈویلپرز کو اسے کامیابی سے استعمال کرنے میں مدد کریں۔

AI تکنیکی مصنفین کو متروک کیوں نہیں کرے گا۔

اگرچہ AI نے ہمارے لکھنے تک پہنچنے کا طریقہ بدل دیا ہے، لیکن مجھے نہیں لگتا کہ سبق یہ ہے کہ تکنیکی مصنفین کو AI سے بچنا چاہیے۔

سبق یہ ہے کہ ہمیں اسے مختلف طریقے سے استعمال کرنے کی ضرورت ہے۔

AI بار بار ہونے والے کاموں میں مدد کرنے میں بہت اچھا ہے۔

• ابتدائی خاکہ بنائیں

• متبادل وضاحتیں پیش کریں۔

• پیچیدہ جملوں کو آسان بنانا

• ممکنہ کنارے کے معاملات تلاش کریں۔

• نوٹس کو ڈرافٹ میں تبدیل کریں۔

• ٹیسٹ کیس بنائیں

• غیر مانوس ترکیب کی وضاحت

• ساخت کا جائزہ

• ذہن سازی کی مثال

• نقطہ نظر کا موازنہ

تاہم، اہم اختلافات ہیں. AI درستگی کی ذمہ داری کو تبدیل کیے بغیر میری سوچ کو تیز کر سکتا ہے۔

ایک بار جب AI اسسٹنٹ Node.js مثال تیار کرتا ہے، آپ کو اسے چلانے کی ضرورت ہے۔

اگر آپ کسی API کی وضاحت کرتے ہیں، تو آپ کو اس تفصیل کا API نفاذ یا سرکاری دستاویزات سے موازنہ کرنا چاہیے۔

جب کوئی حکم تجویز کیا جاتا ہے، تو اس پر عمل کرنا ضروری ہے۔

اگر کوئی ٹیوٹوریل بنتا ہے، تو آپ کو شروع سے ہی اس پر عمل کرنا چاہیے گویا آپ قاری ہیں۔

وہ ورک فلو AI کا کردار ادا کرتا ہے”برائے مہربانی یہ میرے لیے لکھیں۔برائے مہربانی اس مضمون کی تحقیق، جانچ، چیلنج، اور بہتر بنانے میں ہماری مدد کریں۔

یہ بہت زیادہ مفید رشتہ ہے۔

آپ جو سکھاتے ہیں اسے بنانے کے قابل ہونا ضروری ہے۔

یہ شاید سب سے بڑا سبق ہے جو میں کسی ایسے شخص کو دینا چاہوں گا جو ڈویلپر پر مرکوز تکنیکی مصنف بننا چاہتا ہے۔

ضروری نہیں کہ دستاویزات لکھنے سے پہلے آپ کا سینئر سافٹ ویئر انجینئر ہو۔ لیکن آپ کو کوڈ کو استعمال کرنے اور اس کی وضاحت کرنے کے قابل ہونے کی ضرورت ہے۔

آپ کو ڈیولپمنٹ ورک فلو کو اچھی طرح سمجھنا چاہیے تاکہ ریپوزٹریز کی جانچ پڑتال، انحصار انسٹال کریں، ایپلیکیشن چلائیں، غلطیاں پڑھیں، کوڈ کو ٹھیک کریں، مثالوں کی جانچ کریں، اور کیا ہوا اس کی وضاحت کریں۔

مثال کے طور پر، اگر آپ React ٹیوٹوریل لکھ رہے ہیں، تو آپ کو React سے اتنا واقف ہونا چاہیے کہ مثالیں کب نامکمل ہیں۔

REST API کی دستاویز کرتے وقت، آپ کو HTTP طریقوں، ہیڈرز، تصدیق، اسٹیٹس کوڈز، JSON پے لوڈز، اور ایرر ہینڈلنگ کو سمجھنے کی ضرورت ہے۔

اگر آپ GitHub ایکشنز کے بارے میں لکھ رہے ہیں، تو آپ کو ورک فلو، ایکشنز، ٹرگرز، رنر، راز، اور تعیناتی کے مراحل کو سمجھنے کی ضرورت ہے۔

اگر آپ Python پیکیج کو دستاویز کرتے ہیں، تو آپ کو اس پیکیج کو انسٹال کرنے اور مثالوں کو چلانے کے قابل ہونا ہوگا۔

مقصد ہر چیز کو جاننا نہیں ہے۔ مقصد یہ ہے کہ آپ جو کچھ لکھتے ہیں اس کی تصدیق کرنے کے لیے تکنیکی طور پر اتنا خود مختار ہونا ہے۔

یہ وہ معیار ہے جو میں پورٹ فولیو اور تکنیکی دستاویزات لکھتے وقت استعمال کرتا ہوں۔

میرا پورٹ فولیو اپنے آپ میں ایک سافٹ ویئر پروجیکٹ ہے۔

ہوم پیج فوری طور پر بتاتا ہے کہ میں کیا کرتا ہوں۔

دستاویز کے ڈویلپر اصل میں اسے نافذ کر سکتے ہیں۔

وہ جملہ جان بوجھ کر دیا گیا ہے۔

میں نہیں چاہتا کہ میرے ممکنہ کلائنٹس یہ جاننے کی کوشش میں دو منٹ گزاریں کہ آیا میں مارکیٹنگ کا مواد، بلاگ پوسٹس، یا ڈویلپر دستاویزات لکھتا ہوں۔

سائٹ فوری طور پر آپ کے مقام کا تعین کرتی ہے۔

سافٹ ویئر انجینئر × ٹیکنیکل رائٹر

یہ پھر چار فعال علاقوں کو ظاہر کرتا ہے:

1. API اور SDK دستاویزات

2. کوانٹم اور گہری تکنیکی دستاویزات

3. کوڈ ہیوی تکنیکی سبق

4. کلاؤڈ، ڈی او اوپس، اور دستاویزات بطور کوڈ

پورٹ فولیو میرے کام کے عمل کو بھی ظاہر کرتا ہے۔

1. ذخیرہ پڑھیں۔

2. ایک مثال بنائیں۔

3. اپنے کوڈ کی جانچ کریں۔

4. اپنے کاغذات بھیجیں۔

یہ عمل صرف یہ کہنے سے زیادہ اہم ہے کہ "میں ایک تکنیکی مصنف ہوں۔”

آپ کے پورٹ فولیو کو اس بات کا ثبوت فراہم کرنا چاہیے کہ آپ کیسے کام کرتے ہیں۔

تکنیکی مصنف کے پورٹ فولیو میں کیا شامل ہونا چاہئے؟

اگر آپ آج شروع کر رہے ہیں، تو اس طرح کے سوالات کے ساتھ شروع نہ کریں: میری پورٹ فولیو ویب سائٹ کیسی ہونی چاہیے؟?

کے ساتھ شروع کریں: ایک مضمون کے ساتھ مجھ پر اعتماد کرنے سے پہلے ایک امکان کو کیا ثبوت کی ضرورت ہے؟?

میں نے اپنا پورٹ فولیو چھ چیزوں کے ارد گرد بنایا۔

1. تکنیکی شناخت صاف کریں۔

اپنے زائرین کو یہ اندازہ لگا کر مت چھوڑیں کہ آپ کیا کرتے ہیں۔

بجائے: مصنف | بلاگر | مواد تخلیق کار

آپ کہہ سکتے ہیں: تکنیکی مصنف | API دستاویزی مصنف | ڈویلپر معلم

یا اگر آپ اس طرح کوڈ کرتے ہیں: سافٹ ویئر انجینئر × ٹیکنیکل رائٹر

آپ کی پوزیشننگ کو فوری طور پر زائرین کو بتانا چاہیے کہ آپ کس کی مدد کرتے ہیں اور آپ کس قسم کا تکنیکی مسئلہ حل کرتے ہیں۔

2. حقیقی مثالیں۔

مضامین کی فہرست مفید ہے، لیکن حقیقی دنیا کی مثالیں بہتر ہیں۔

اگر آپ API دستاویز لکھ رہے ہیں، تو براہ کرم API کی مثال دکھائیں۔ اگر آپ SDK دستاویز لکھ رہے ہیں، تو براہ کرم مجھے SDK گائیڈ دکھائیں۔ اگر آپ ٹیوٹوریل لکھ رہے ہیں، تو براہ کرم دوبارہ پیدا کرنے والا کوڈ فراہم کریں۔ اگر آپ DevOps مضمون لکھ رہے ہیں، تو ہمیں اپنی تعیناتی گائیڈ دکھائیں۔

آپ کے پورٹ فولیو کو درج ذیل جواب دینا چاہیے:

کیا یہ شخص حقیقت میں اس ٹیکنالوجی کی وضاحت کر سکتا ہے جسے وہ سمجھنے کا دعوی کرتا ہے؟

3. تکنیکی گہرائی کا ثبوت

میرے پورٹ فولیو میں درج ذیل حل ہیں:

• جاوا اسکرپٹ

• ازگر

• ٹائپ اسکرپٹ

• رد عمل

• Node.js

• apis

• azure

• CI/CD

• چومنا

• آئی بی ایم کوانٹم

• خوش ہو جاؤ

• قیمت میں کمی

• کوڈ کی قسم کی دستاویز

30 مہارتوں کی فہرست بنانے کی ضرورت نہیں ہے۔ درحقیقت، ہر چیز کی فہرست آپ کی پوزیشننگ کو کمزور کر سکتی ہے۔ ایک ایسی مہارت کا انتخاب کریں جس کا آپ عملی مظاہرہ کر سکیں۔

4. شائع شدہ کام

شائع شدہ مضامین اس بات کا ثبوت فراہم کرتے ہیں کہ تکنیکی تصورات کو حقیقی قارئین تک پہنچایا جا سکتا ہے۔

میرا پورٹ فولیو میرے کام کو اوپن سورس پبلیکیشنز اور ٹیکنالوجی بلاگز سے جوڑتا ہے۔

لیکن صرف یہ نہ لکھیں: 20 مضامین شائع ہوئے۔. مجھے مضمون دکھائیں۔ اپنے قارئین کو اپنے کام کا معائنہ کرنے کا ایک طریقہ دیں۔

5. پروجیکٹ

پروجیکٹ لکھنے اور انجینئرنگ کے درمیان فرق کو ختم کرنے میں مدد کرتے ہیں۔

ایک اچھی پروجیکٹ آئٹم کو ان چار سوالات کا جواب دینا چاہئے:

• مسئلہ کیا تھا؟

• آپ نے کیا بنایا یا دستاویز کیا ہے؟

• کون سی ٹیکنالوجیز شامل ہیں؟

• پروجیکٹ نے کیا دکھایا؟

آپ کا پروجیکٹ صرف ایک React پورٹ فولیو ویب سائٹ نہیں ہونا چاہیے۔ یہ قاری کو تقریباً کچھ نہیں بتاتا۔

اس کے بجائے:

React، TypeScript، TanStack Start، Tailwind CSS، اور Netlify تعیناتی ورک فلو کا استعمال کرتے ہوئے ایک ڈویلپر پر مرکوز تکنیکی تحریری پورٹ فولیو بنایا۔

اب یہ منصوبہ تکنیکی صلاحیتوں کو فراہم کرتا ہے۔

6. اگلی کارروائی صاف کریں۔

آپ کے پورٹ فولیو کو زائرین کو یہ سوچتے ہوئے نہیں چھوڑنا چاہیے کہ آگے کیا کرنا ہے۔

مخصوص تجاویز کے ساتھ بند کریں، جیسے: ہمیں اپنے API ریپوزٹری یا SDK دستاویزات کا لنک بھیجیں اور ہم مخصوص دستاویزات کے خلا کی نشاندہی کریں گے۔

یہ کہنے سے کہیں زیادہ طاقتور ہے: اگر آپ تکنیکی تحریری کام کرنا چاہتے ہیں تو براہ کرم مجھ سے رابطہ کریں۔

پہلا بیان آپ کے امکان کو کچھ خاص کرنے کے لیے دیتا ہے۔

میرے پورٹ فولیو کے پیچھے ٹیکنالوجی

میں نے اپنا موجودہ پورٹ فولیو ایک جدید React پر مبنی اسٹیک کا استعمال کرتے ہوئے بنایا ہے۔

اہم حصے مندرجہ ذیل ہیں:

• رد عمل

• ٹائپ اسکرپٹ

• Tanstack شروع کریں

• ٹین اسٹیک راؤٹر

• تیز

• ٹیل ونڈ سی ایس ایس

• shadcn/ui جزو

• لوسڈ ری ایکٹ

• این پی ایم

• گٹ اور گٹ ہب

• اطلاع دیں۔

اہم بات یہ نہیں ہے کہ وہ ایک ہی اسٹیک استعمال کرتے ہیں۔ آپ سادہ HTML اور CSS کا استعمال کرتے ہوئے تکنیکی دستاویزات کا پورٹ فولیو بنا سکتے ہیں۔

جدید ایپلیکیشن اسٹیک کو منتخب کرنے کی میری وجوہات جزوی طور پر عملی اور جزوی طور پر جان بوجھ کر تھیں۔

میں اپنا تعارف کسی ایسے شخص کے طور پر کرتا ہوں جو ڈویلپرز کے ساتھ کام کرتا ہوں۔ پورٹ فولیو کو خود یہ ظاہر کرنا چاہیے کہ میں جدید ترقیاتی ورک فلو کے اندر کام کر سکتا ہوں۔

میں React کیوں استعمال کرتا ہوں۔

React انٹرفیس بنانے کا ایک جزو پر مبنی طریقہ فراہم کرتا ہے۔

اپنی پوری ویب سائٹ کو ایک بڑی HTML فائل میں بنانے کے بجائے، آپ اپنے انٹرفیس کو دوبارہ قابل استعمال ٹکڑوں میں توڑ سکتے ہیں۔

مثال کے طور پر، نیویگیشن اجزاء کو متعدد صفحات پر دوبارہ استعمال کیا جا سکتا ہے۔ بٹنوں کو پوری درخواست میں دوبارہ استعمال کیا جا سکتا ہے۔ متبادل طور پر، آپ پراجیکٹ کارڈز کو ڈپلیکیٹ مارک اپ کے بجائے دوبارہ قابل استعمال اجزاء کے طور پر ڈسپلے کر سکتے ہیں۔

یہ دستاویزی نقطہ نظر سے بھی مفید ہے۔ جب آپ اجزاء پر مبنی ترقی کو سمجھتے ہیں، تو آپ دوبارہ قابل استعمال تصورات، انحصار، ان پٹ، آؤٹ پٹس، اور طرز عمل کے لحاظ سے دستاویزات کے بارے میں سوچنا شروع کر دیتے ہیں۔

ڈویلپرز کی دلچسپی یہی ہے۔

TypeScript کیوں؟

TypeScript جاوا اسکرپٹ میں جامد ٹائپنگ کا اضافہ کرتا ہے۔

پورٹ فولیو پروجیکٹس کے لیے، آپ یہ بحث کر سکتے ہیں کہ ٹائپ اسکرپٹ غیر ضروری ہے۔

یہ مناسب ہے۔

تاہم، TypeScript کا استعمال اس ترقیاتی ماحول کی عکاسی کرتا ہے جس کا سامنا آپ کو جدید ایپلی کیشن کی دستاویز کرتے وقت کرنا پڑے گا۔

یہ آپ کو اجزاء اور افعال کے ذریعے منتقل ہونے والے ڈیٹا کی شکل کے بارے میں سوچنے پر بھی مجبور کرتا ہے۔

مثال کے طور پر:

type Project = {
  title: string;
  description: string;
  technologies: string[];
  url: string;
};

اب آپ کے پاس ایک واضح معاہدہ ہے کہ اس منصوبے میں کیا شامل ہے۔

یہ ذہنیت براہ راست تکنیکی دستاویزات میں ترجمہ کرتی ہے۔

جب آپ کسی API کو دستاویز کرتے ہیں، تو آپ بنیادی طور پر معاہدے کی دستاویز کر رہے ہوتے ہیں۔

• ان پٹ

• طاقت کی پیداوار

• قسم

• مطلوبہ فیلڈز

• انتخاب کا میدان

• غلطی

• متوقع رویہ

آپ کو TanStack کے ساتھ کیوں شروع کرنا چاہئے؟

پورٹ فولیو درخواست کی ساخت اور روٹنگ کے لیے TanStack Start کا استعمال کرتا ہے۔

ابتدائیوں کے لیے اہم سبق یہ نہیں ہے کہ آپ کو TanStack Start سیکھنا ہوگا۔ ایسا نہیں ہونا چاہیے۔

یہاں سبق یہ ہے کہ تکنیکی مصنفین کو آرام دہ اور پرسکون نیویگیٹ فریم ورک بننے کی ضرورت ہے۔

جب آپ اپنے کلائنٹ کے ذخیرے میں کسی غیر مانوس فریم ورک کو دیکھتے ہیں، تو آپ کو درج ذیل سوالات کا جواب دینے کے قابل ہونا چاہیے:

• راستہ کہاں ہے؟

• اجزاء کہاں ہیں؟

• درخواست کی ترتیب کہاں ہے؟

• مشترکہ افادیت کہاں ہیں؟

• اثاثے کہاں ہیں؟

• ایپلیکیشن کے ذریعے ڈیٹا کیسے منتقل ہوتا ہے؟

• ایپلی کیشنز کیسے بنتی ہیں؟

• یہ کیسے تقسیم کیا جاتا ہے؟

یہ سوالات کسی مخصوص فریم ورک کو یاد کرنے سے زیادہ اہم ہیں۔

وائٹ ڈویلپمنٹ کو ہینڈل کرتا ہے اور ورک فلو بناتا ہے۔

وائٹ ترقی کے تجربے اور پیداوار کی تعمیر کے لیے ذمہ دار ہے۔

ترقی کے دوران، آپ مقامی طور پر اپنی ایپلیکیشن کو چلاتے اور اس میں ترمیم کرتے وقت فوری فیڈ بیک حاصل کر سکتے ہیں۔

پروڈکشن کی تعمیر قابل تعیناتی اثاثے بناتی ہے۔

اس پروجیکٹ کے لیے، اس کا بنیادی مطلب یہ ہے کہ ورک فلو ہے۔ npm install اور npm run dev ترقی کے دوران اور بعد میں npm run build پروڈکشن ایپلی کیشن تیار کرتے وقت۔

وائٹ کی موجودہ دستاویزات ڈویلپمنٹ سرورز اور پروڈکشن کو ورک فلو کے دو اہم حصوں کے طور پر بیان کرتی ہیں۔

اہم تکنیکی تحریری اسباق میں شامل ہیں: ترقی اور پیداوار میں فرق جانیں۔

مندرجہ ذیل کام کرنے کے لیے ٹیوٹوریل: localhost یہ ایک خودکار تعیناتی ٹیوٹوریل نہیں ہے۔

ڈویلپرز کو یہ جاننے کی ضرورت ہے کہ جب ان کی ایپلی کیشنز ان کے کمپیوٹر سے پروڈکشن ماحول میں منتقل ہوں گی تو کیا تبدیلیاں رونما ہوں گی۔

Tailwind CSS اسٹائل کو ہینڈل کرتا ہے۔

میں نے Tailwind CSS کا استعمال کرتے ہوئے بصری نظام بنایا۔

ہر جزو کے لیے بڑی حسب ضرورت اسٹائل شیٹ لکھنے کے بجائے، آپ براہ راست مارک اپ میں یوٹیلیٹی کلاسز بنا سکتے ہیں۔

مثال کے طور پر:

اس سے وقفہ کاری، نوع ٹائپ، ریسپانسیو لے آؤٹ، اور اجزاء کی طرزوں پر تیزی سے تکرار کرنا بھی آسان ہوجاتا ہے۔

ایک بار پھر، تکنیکی مصنفین کے لیے سبق یہ ہے: Tailwind کو جانیں کیونکہ ہر تکنیکی مصنف کو اس کی ضرورت ہوتی ہے۔.

سبق یہ ہے: یہ سمجھنے کے لیے کافی فرنٹ اینڈ ڈیولپمنٹ سیکھیں کہ آپ جن سسٹمز کو دستاویز کرتے ہیں وہ درحقیقت کس طرح تشکیل پاتے ہیں۔.

Lucide React شبیہیں فراہم کرتا ہے۔

ہم انٹرفیس شبیہیں کے لیے Lucide React استعمال کرتے ہیں۔

مثال کے طور پر:

import { ArrowRight } from "lucide-react";

اگر ضرورت ہو تو جزو پھر آئیکن کو رینڈر کر سکتا ہے۔

اس طرح کے چھوٹے انحصار سمجھنے کے قابل ہیں کیونکہ وہ جدید فرنٹ اینڈ ریپوزٹریز میں مسلسل ظاہر ہوتے ہیں۔

موجودہ کوڈبیس کی دستاویز کرتے وقت، آپ کو یہ پہچاننا ہوگا کہ آیا درآمد ایپلی کیشن کا حصہ ہے، فریق ثالث کا انحصار، فریم ورک کی خصوصیت، یا مقامی افادیت۔

تنصیب اور ترتیب کو بیان کرتے وقت یہ فرق اہم ہو جاتا ہے۔

سمجھ package.json

اپنے JavaScript پروجیکٹ میں ان پہلی فائلوں میں سے ایک ہے جس کا میں معائنہ کرتا ہوں۔ package.json

یہ فائل آپ کو آپ کے پروجیکٹ کے بارے میں بہت کچھ بتاتی ہے۔

ان میں شامل ہوسکتا ہے:

• پروجیکٹ میٹا ڈیٹا

• سکرپٹ

• انحصار

• ترقی کے انحصار

• پیکیج کی ترتیب

تکنیکی مصنفین کے لیے، یہ JavaScript کے ذخیرے میں سب سے زیادہ مفید فائلوں میں سے ایک ہے۔

اگرچہ ٹیوٹوریل نے قاری کو پانچ پیکجز کو دستی طور پر انسٹال کرنے کی ہدایت کی تھی، لیکن وہ پیکجز پہلے ہی انسٹال ہو چکے تھے۔ package.jsonٹیوٹوریل غیر ضروری کام پیدا کر رہا ہے۔

اس کے بجائے، قارئین کو صرف ضرورت ہو سکتی ہے: npm install.

پیکیج فائلوں کو سمجھنے سے آپ کو ایسی ہدایات لکھنے سے بچنے میں مدد ملے گی جو آپ کے اصل پروجیکٹ سے میل نہیں کھاتی ہیں۔

پاتھ فائلوں کو سمجھنا

پورٹ فولیو مختلف صفحات کی نمائندگی کرنے کے لیے روٹ فائلوں کا استعمال کرتے ہیں۔

درخواست میں درج ذیل راستے شامل ہیں:

 /about
 /services
 /projects
 /writing
 /contact

ہر راستہ مناسب صفحہ پیش کرنے کا ذمہ دار ہے۔

مثال کے طور پر، رابطے کا راستہ صفحہ میٹا ڈیٹا اور صفحہ کے اجزاء پر مشتمل ہے۔

یہاں ایک آسان ورژن ہے:

export const Route = createFileRoute("/contact")({
  head: () => ({
    meta: [
      {
        title: "Contact Casmir Onyekani",
      },
    ],
  }),
  component: ContactPage,
});

یہاں اہم چیز حفظ نہیں ہے۔ createFileRoute. یہ سمجھنے کے بارے میں ہے کہ آپ کا کوڈ کیا کر رہا ہے۔

راستہ وضاحت کرتا ہے:

1. URL

2. صفحہ میٹا ڈیٹا

3. اس راستے کے لیے فراہم کردہ جزو

تو سورس کوڈ خود کارآمد دستاویزات بن جاتا ہے۔

اجزاء دوبارہ قابل استعمال انٹرفیس حصوں کو الگ کریں۔

یہ پروجیکٹ دوبارہ قابل استعمال اجزاء بھی استعمال کرتا ہے۔

شروع سے ہر بٹن، کارڈ، نیویگیشن عنصر، یا UI عنصر بنانے کے بجائے، دوبارہ قابل استعمال اجزاء آپ کو عام رویے اور طرزوں کو سمیٹنے کی اجازت دیتے ہیں۔

یہ پہلی چیزوں میں سے ایک ہے جو میں کوڈ بیس کی دستاویز کرتے وقت تلاش کرتا ہوں۔

اگر ڈویلپر پوچھتا ہے۔ میں بٹن کیسے بناؤں؟? اگر آپ کے پروجیکٹ میں پہلے سے ہی دوبارہ قابل استعمال ٹیگز موجود ہیں، تو میں آپ کو مارک اپ کی 40 لائنوں کو کاپی کرنے کے لیے نہیں کہنا چاہتا۔ Button عنصر میں ان کی طرف اشارہ کرنا چاہتا ہوں کہ پروجیکٹ پہلے سے ہی کون سے تجریدات استعمال کر رہا ہے۔

اچھی دستاویزات سافٹ ویئر فن تعمیر کی پیروی کرتی ہیں۔ یہ لڑتا نہیں ہے۔

اثاثے بھی دستاویزات کی کہانی کا حصہ ہیں۔

آپ کے پورٹ فولیو میں آپ کی پروفائل امیج اور دیگر بصری وسائل جیسے اثاثے شامل ہیں۔

وہ عام طور پر ایسے مقامات پر رہتے ہیں جیسے:

public/
src/assets/

اختلافات کو سمجھنا ضروری ہے۔

کچھ اثاثے آپ کے ایپلیکیشن کوڈ میں درآمد کیے جاتے ہیں۔ دیگر کو براہ راست جامد فائلوں کے طور پر فراہم کیا جا سکتا ہے۔

دستاویزات لکھتے وقت یہ فرق کرنے سے مبہم ہدایات سے بچنے میں مدد ملتی ہے، جیسے کہ ڈویلپرز کو ایسی تصاویر کھینچنے کے لیے کہنا جن کی ایپلی کیشن عوامی ڈائریکٹری سے پیش کرنے کی توقع رکھتی ہے۔

ایک بار پھر، دستاویزات کا معیار اکثر عمل درآمد کی بظاہر چھوٹی تفصیلات کو سمجھنے پر منحصر ہوتا ہے۔

کنفیگریشن فائلوں کی اہمیت

ابتدائی تکنیکی مصنفین مکمل طور پر توجہ مرکوز کر سکتے ہیں:

src/

تاہم، حساس معلومات اکثر سورس ڈائرکٹری سے باہر رہتی ہیں۔

درج ذیل فائلیں پورے پروجیکٹ کو متاثر کر سکتی ہیں۔

package.json
vite.config.ts
tsconfig.json
.gitignore

آپ کے پروجیکٹ پر منحصر ہے، آپ کو اس طرح کی فائلیں بھی مل سکتی ہیں:

eslint
prettier
Tailwind
Netlify
environment variables
GitHub Actions

یہ فائلیں اس بات کی وضاحت کر سکتی ہیں کہ پراجیکٹ کو کیسے بنایا گیا، تصدیق کی گئی، فارمیٹ کی گئی اور اسے کیسے لگایا گیا۔

اگر آپ اسے نظر انداز کرتے ہیں، تو آپ اپنے ڈویلپر ورک فلو کے ایک اہم حصے سے محروم ہو سکتے ہیں۔

تعمیر اور دستاویز کرتے وقت AI کا استعمال کیسے کریں۔

اس پورٹ فولیو کی ترقی کے دوران AI کام آیا۔

لیکن میں نے اسے بطور ڈویلپر نہیں سمجھا۔ میں نے اس کے ساتھ ترقیاتی معاون کی طرح سلوک کیا۔ بڑا فرق ہے۔

آئیے کہتے ہیں کہ ایک خرابی پیش آگئی۔ پوچھنے کی بجائے میرے پورے منصوبے کو ٹھیک کریںآپ پوچھ سکتے ہیں: اس خرابی کو بیان کرتا ہے اور وجہ فائل کی شناخت کرتا ہے۔.

پھر فائلوں کو اسکین کریں۔ میں پوچھ سکتا ہوں: اس خرابی کی تین ممکنہ وجوہات کیا ہیں؟? پھر ہم اس امکان کی جانچ کرتے ہیں۔

میں پوچھ سکتا ہوں: رسائی کے مسائل کے لیے براہ کرم اس جزو کا جائزہ لیں۔. پھر تجاویز خود دیکھیں۔

یہ ایک فیڈ بیک لوپ بناتا ہے۔

        AI suggestion
             ↓
        My investigation
             ↓
        Code change
             ↓
        Run the application
             ↓
        Test the result
             ↓
        Document what actually worked

اس طرح ہمارے خیال میں ٹیکنالوجی کے مصنفین کو AI کا فائدہ اٹھانا چاہیے۔

تکنیکی فیصلے کو آؤٹ سورس کرنے کے بجائے، چیزوں کو تیز کرنے کے لیے AI کا استعمال کریں۔

تکنیکی مصنفین کے لیے سب سے اہم AI ٹیکنالوجی

فلائی پر لکھنا مفید ہے۔ لیکن میں اس کے اوپر کچھ اور شامل کروں گا: "چیک کریں”۔

خوبصورت اشارے درست جوابات کی ضمانت نہیں دیتے۔

جب AI اسسٹنٹ مندرجہ ذیل کمانڈ دیتا ہے: npm install some-packageآپ کو یہ جاننے کی ضرورت ہے کہ آیا وہ پیکیج موجود ہے۔

ایک بار API مثال فراہم کرنے کے بعد، آپ کو اپنی درخواست کی جانچ کرنی چاہیے۔

React مثال فراہم کرنے کے بعد، آپ کو ایپلیکیشن چلانے کی ضرورت ہے۔

اگر کوئی فریم ورک کسی خاص خصوصیت کو سپورٹ کرنے کا دعویٰ کرتا ہے، تو آپ کو فریم ورک کی موجودہ دستاویزات یا سورس کوڈ کے خلاف دعوے کی تصدیق کرنی چاہیے۔

یہ خاص طور پر اہم ہے کیونکہ سافٹ ویئر میں تبدیلی آتی ہے۔ ایک ٹیوٹوریل جو دو سال پہلے درست تھا وہ کمانڈز پر مشتمل ہو سکتا ہے جو آج استعمال نہیں ہوتے۔

اس لیے تکنیکی مصنفین کو جانچنے کی عادت درکار ہے۔ ماخذ → نفاذ → ٹیسٹ → تفصیل بلکہ فوری → جواب دیں → پوسٹ.

میرا ترقیاتی کام کا فلو

تکنیکی منصوبے پر کام کرتے وقت، میں مندرجہ ذیل ترتیب میں سوچتا ہوں:

        Understand
            ↓
          Build
            ↓
          Test
            ↓
        Document
            ↓
         Review
            ↓
        Publish

اسی ورک فلو کا اطلاق تکنیکی تحریر پر ہوتا ہے۔

ہم کہتے ہیں کہ ایک کلائنٹ مجھے API ذخیرہ فراہم کرتا ہے۔ میں فوری طور پر خالی دستاویز نہیں کھولتا اور لکھنا شروع نہیں کرتا۔

سب سے پہلے، آئیے درج ذیل کرتے ہیں:

• ذخیرہ چیک

• شناخت کریں کہ آپ کی درخواست کیسے چلتی ہے۔

• انحصار انسٹال کریں۔

• پروجیکٹ پر عمل درآمد

• متعلقہ API افعال تلاش کریں۔

• ایک درخواست کرو

• اصل میں کیا ہوا لکھیں۔

اس کے بعد ہی ہم گائیڈ لکھنا شروع کرتے ہیں۔

یہ AI سے 2,000 الفاظ کا مضمون تیار کرنے کے لیے کہنے سے سست ہے۔ تاہم، یہ دستاویزات تیار کرتا ہے جس کے مفید ہونے کا امکان زیادہ ہوتا ہے۔

Netlify پر اپنا پورٹ فولیو تعینات کریں۔

ایک بار جب میری درخواست مقامی طور پر کام کر رہی تھی، مجھے اسے ویب پر ڈالنے کی ضرورت تھی۔

میں نے نیٹریفائی کا استعمال کیا۔ گٹ پر مبنی پروجیکٹس کے لیے، تعیناتی کا ورک فلو آسان ہے۔

بنیادی بہاؤ مندرجہ ذیل ہے:

        Local project
             ↓
            Git
             ↓
        GitHub repository
             ↓
           Netlify
             ↓
        Production site

Netlify آپ کے Git ریپوزٹری سے منسلک ہو سکتا ہے اور تبدیلیوں کے آگے بڑھنے کے ساتھ ہی آپ کے پروجیکٹ کو خود بخود بنا اور تعینات کر سکتا ہے۔

وائٹ پروجیکٹ کے لیے ایک عام پروڈکشن سیٹ اپ یہ ہوگا:

اس کا مطلب ہے کہ Netlify بلڈ کمانڈ چلائے گا اور نتیجے میں آنے والی پروڈکشن فائل کو شائع کرے گا۔

تکنیکی مصنفین کے لیے یہ ایک اہم تصور ہے۔ تعیناتی دستاویزات میں صرف یہ نہیں کہنا چاہئے: آپ کی درخواست Netlify پر تعینات کر رہا ہے۔. آپ کو ریپوزٹریز، بلڈ کمانڈز، آؤٹ پٹ ڈائریکٹریز، اور ہوسٹنگ پلیٹ فارمز کے درمیان تعلقات کو بیان کرنا چاہیے۔

تکنیکی مصنفین کے لئے گٹ کیوں اہم ہے۔

گٹ صرف ایک ڈویلپر ٹول سے زیادہ ہے۔ یہ ایک دستاویزی ٹول بھی ہے۔

اگر ماخذ کوڈ کے ساتھ دستاویزات موجود ہیں تو، گٹ فراہم کرتا ہے:

• ورژن کی تاریخ

• انڈے کا پودا

• کھینچنے کی درخواست

• جائزہ لیں

• تبدیلیوں کو ٹریک کریں۔

• تعاون

تصور کریں کہ ایک ڈویلپر API کے اختتامی نقطہ کو تبدیل کرتا ہے۔

اگر دستاویزات ایک ہی ذخیرہ میں ہیں، تو ان کی تبدیلیاں اسی ورک فلو میں دستاویز کی تازہ کاری کو متحرک کرسکتی ہیں۔ یہ دستاویزات کے طور پر کوڈ کی بنیاد ہے۔

آپ کو شروع سے گٹ ماہر بننے کی ضرورت نہیں ہے۔ تاہم، آپ کو بنیادی باتوں سے واقف ہونا چاہئے:

git clone
git checkout
git pull
git add
git commit
git push

آپ کو یہ بھی سمجھنے کی ضرورت ہے کہ کس طرح پل کی درخواستیں اور تبدیلیاں مقامی شاخوں سے مشترکہ ذخیروں میں منتقل ہوتی ہیں۔

ڈویلپر ٹیکنیکل رائٹر بننے کے لیے ابتدائی افراد کو کیا سیکھنے کی ضرورت ہے۔

اگر آپ آج تکنیکی تحریر لکھنا شروع کریں تو میں آپ کے سیکھنے کو پانچ حصوں میں تقسیم کروں گا:

1. پروگرامنگ کی بنیادی باتیں

ایک پروگرامنگ زبان سے شروع کریں۔

JavaScript یا Python عملی انتخاب ہیں کیونکہ یہ بہت سے ڈویلپر ماحولیاتی نظام میں ظاہر ہوتے ہیں۔

سیکھیں:

• متغیر

• فنکشن

• اشیاء

• انتظام

• حالات

• لوپ

• ماڈیول

• ہینڈلنگ میں خرابی

• غیر مطابقت پذیر پروگرامنگ

• پیکیج مینجمنٹ

آپ کو تمام زبانیں جاننے کی ضرورت نہیں ہے۔ ڈویلپرز کو یہ سمجھنے کے لیے کافی پروگرامنگ علم کی ضرورت ہوتی ہے کہ وہ کیا کر رہے ہیں۔

2. ویب اور API کی بنیادی باتیں

اگر آپ ڈویلپر دستاویزات لکھنا چاہتے ہیں تو جانیں کہ ویب کیسے کام کرتا ہے۔

سمجھیں:

پھر کچھ بنائیں۔ مثال کے طور پر، ایک چھوٹا API بنائیں اور اس کے لیے دستاویزات لکھیں۔

اس ایک مشق کے ساتھ، آپ تکنیکی تحریر کے بارے میں درجنوں مضامین پڑھنے کے بجائے API دستاویزات کے بارے میں مزید جانیں گے۔

3. ڈویلپر ٹولز

اپنے آپ کو درج ذیل سے آشنا کریں:

• وی ایس کوڈ

• خوش ہو جاؤ

• گٹ ہب

• ٹرمینل

• پیکیج مینیجر

• براؤزر ڈویلپر ٹولز

• قیمت میں کمی

• ماحولیاتی متغیرات

• JSON

• بنیادی ڈیبگنگ

یہ ٹولز اس ماحول کا حصہ ہیں جس میں ڈویلپر کی دستاویزات بنائی اور استعمال کی جاتی ہیں۔

4. دستاویزی مہارت

لکھنے کا طریقہ سیکھیں:

• ریڈمی فائل

• شروع کرنا گائیڈ

• سبق

• API حوالہ

• SDK گائیڈ

• ٹربل شوٹنگ گائیڈ

• تصوراتی دستاویزات

• مائیگریشن گائیڈ

• کنفیگریشن گائیڈ

اور سمجھیں کہ ان فارمیٹس میں مختلف قسم کے کام ہوتے ہیں۔

API حوالہ ٹیوٹوریل نہیں ہے۔ ٹیوٹوریل تصوراتی رہنما نہیں ہے۔ اور README مکمل ڈویلپر پورٹل نہیں ہے۔

ایک اچھا تکنیکی مصنف فرق جانتا ہے۔

5. AI سے چلنے والا ورک فلو

آخر میں، AI کو مؤثر طریقے سے استعمال کرنے کا طریقہ سیکھیں۔

اس کے لیے استعمال کریں:

• تحقیق کی حمایت

• دماغی طوفان

• کوڈ کا جائزہ

• ٹیسٹ کیس بنائیں

• ترمیم کریں

• خلاصہ

• تنظیم نو

• فرق کی شناخت

• تفصیل کا موازنہ کریں۔

تاہم، آپ کی ملکیت برقرار ہے:

• تکنیکی فیصلے

• ذریعہ چیک کریں

• کوڈ ٹیسٹنگ

• حقیقت کی درستگی

• ہاں

• حتمی وضاحت

مقصد یہ نہیں ہے کہ ورڈ جنریشن میں AI کا مقابلہ کیا جائے۔ مقصد یہ ہے کہ کوئی ایسا شخص بن جائے جو جانتا ہو کہ وہاں کون سے الفاظ ہونے چاہئیں اور کیا وہ صحیح الفاظ ہیں۔

آپ کے پورٹ فولیو کو ان مہارتوں کا مظاہرہ کرنا چاہیے۔

یہی وجہ ہے کہ میں نہیں سمجھتا کہ تکنیکی مصنف کے پورٹ فولیو کو آن لائن ریزیومے کے طور پر سمجھا جانا چاہیے۔

آپ کا پورٹ فولیو ایک ڈیمو ماحول ہے۔

• اگر آپ API کو سمجھنے کا دعوی کرتے ہیں تو مجھے API دستاویزات دکھائیں۔

• اگر آپ سافٹ ویئر ڈیولپمنٹ کو سمجھنے کا دعویٰ کرتے ہیں تو مجھے ایک سافٹ ویئر پروجیکٹ دکھائیں۔

• اگر آپ ٹیوٹوریل لکھنے کا دعویٰ کرتے ہیں، تو براہِ کرم دوبارہ پیش کی جانے والی مثالوں کے ساتھ ٹیوٹوریل پوسٹ کریں۔

• اگر آپ Git اور docs-as-code کو سمجھنے کا دعویٰ کرتے ہیں، تو مجھے اپنے ترقیاتی ورک فلو کے دوران محفوظ اور برقرار رکھی ہوئی دستاویزات دکھائیں۔

• اگر آپ AI کو مؤثر طریقے سے استعمال کرنے کا دعویٰ کرتے ہیں، تو ایک ورک فلو دکھائیں جہاں AI تصدیق کو تبدیل کیے بغیر کاموں کو تیز کرتا ہے۔

پورٹ فولیو خود اس کا ثبوت ہے۔

اگر آپ آج شروع کریں گے تو آپ کیا کریں گے؟

اگر آپ ابتدائی ہیں، تو آپ کو ایک پیچیدہ پورٹ فولیو بنانے کی ضرورت نہیں ہے جیسا کہ میں نے بنایا تھا۔

چھوٹا شروع کریں۔

استعمال کرتے ہوئے ایک سادہ ویب سائٹ بنائیں:

Home 
About
Projects 
Writing 
Contact

پھر تین طاقتور منصوبے شامل کریں:

پروجیکٹ 1: API دستاویزات

ایک چھوٹا REST API بنائیں۔

دستاویز:

• ثبوت

• اختتامی نقطہ

• پیرامیٹر

• جسم کی درخواست کریں

• جواب

• غلطی

• ہاں

پروجیکٹ 2: ڈویلپر ٹیوٹوریل

React یا Python کے ساتھ کچھ بنائیں۔ پھر ایک ٹیوٹوریل لکھیں جو آپ کے خالی پروجیکٹ پر دوسرے ڈویلپرز کو آپ کے کام کے نتائج کی رہنمائی کرتا ہے۔

پروجیکٹ 3: تعیناتی گائیڈ

پروجیکٹ کو تعینات کریں اور تعیناتی کے عمل کو دستاویز کریں۔

کمانڈز، کنفیگریشن، ماحولیاتی متغیرات، تعمیراتی عمل، اور ٹربل شوٹنگ کے اقدامات شامل ہیں۔

اب آپ کا پورٹ فولیو اس طرح کچھ نہیں کہتا: تکنیکی دستاویزات لکھ سکتے ہیں۔. یہ ظاہر کرتا ہے۔

اصلی پورٹ فولیو ٹیسٹنگ

یہاں ایک آسان ٹیسٹ ہے جسے آپ اپنے پورٹ فولیو میں اپلائی کر سکتے ہیں۔

براہ کرم اپنے URL کو کسی ایسے شخص کے ساتھ شیئر کریں جو آپ کو نہیں جانتا۔

ان سے پانچ سوالات پوچھیں:

• یہ شخص کیا کرتا ہے؟

• وہ کس کی مدد کرتے ہیں؟

• وہ کون سی ٹیکنالوجی سمجھتے ہیں؟

• میں ان کے کام کے ثبوت کہاں دیکھ سکتا ہوں؟

• اگر میں ان کی خدمات حاصل کرنا چاہتا ہوں تو مجھے کیا کرنا چاہیے؟

اگر آپ ان سوالات کا فوری جواب نہیں دے سکتے ہیں، تو آپ کے پورٹ فولیو کو کچھ کام کی ضرورت پڑ سکتی ہے۔

آپ کو مزید حرکت پذیری کی ضرورت نہیں ہے، اور ضروری نہیں کہ آپ کو مزید صفحات کی ضرورت ہو۔ مزید واضح ثبوت کی ضرورت ہے۔

میرے پورٹ فولیو نے مجھے کیا سکھایا

میرے پورٹ فولیو کی تعمیر نے سافٹ ویئر ڈویلپمنٹ اور تکنیکی تحریر میں میرے تجربے کو مزید تقویت بخشی۔

تکنیکی تحریر تیزی سے نفاذ پر مرکوز ہوتی جارہی ہے۔

AI وضاحتیں تیار کر سکتا ہے، لیکن ڈویلپرز کو ایسی تفصیل کی ضرورت ہوتی ہے جو کوڈ کو چھونے کے بعد برقرار رہتی ہیں۔

یہ ایک مختلف معیار ہے۔

ایک اچھا ڈویلپر تکنیکی مصنف ایک ذخیرہ کھولنے اور متجسس ہونے کے قابل ہونا چاہئے۔

• یہ خصوصیت کیا کرتی ہے؟

• یہ انحصار یہاں کیوں ہے؟

• یہ ڈیٹا کہاں سے آتا ہے؟

• اگر درخواست ناکام ہوجاتی ہے تو کیا ہوگا؟

• یہ ترتیب کیوں موجود ہے؟

• ڈویلپرز کو کیا انسٹال کرنا چاہئے؟

• اگر میں مختلف ورژن استعمال کروں تو کیا ہوگا؟

• اس ورک فلو کے کون سے حصے دستاویزی نہیں ہیں؟

یہ سوال ہی اصل کام ہے۔ لکھنا یہ ہے کہ ہم اپنے جوابات کیسے بتاتے ہیں۔

آپ کو کمرے میں بہترین ڈویلپر بننے کی ضرورت نہیں ہے۔

ایک اور غلط فہمی ہے جسے دور کرنے کی ضرورت ہے۔

ڈویلپر پر مرکوز تکنیکی مصنف ہونے کا مطلب یہ نہیں ہے کہ آپ کو سافٹ ویئر انجینئرز کے ساتھ بطور سافٹ ویئر انجینئر مقابلہ کرنا ہوگا۔

آپ کا کام الگ ہے۔

سسٹم کو سمجھنے، تحقیق کرنے، جانچنے اور واضح طور پر بات چیت کرنے کے لیے کافی تکنیکی گہرائی کی ضرورت ہے۔ سسٹم لرنر کی طرح سوچنے کی صلاحیت بھی ضروری ہے۔

وہ مجموعہ اس کے قابل ہے۔

آپ مسلسل دو نقطہ نظر کے درمیان سوئچ کر رہے ہیں.

How does the software work? 
            ↕ 
How does the developer need to learn it?

یہ ڈویلپر کی تربیت کا مرکز ہے۔

حتمی خیالات

میں نے ایک پورٹ فولیو بنایا کیونکہ میں چاہتا تھا کہ ممکنہ کلائنٹس اور آجر صرف میرے تجربے کی فہرست سے زیادہ دیکھیں۔

میں انہیں دکھانا چاہتا تھا کہ میں کیا سوچتا ہوں۔

ویب سائٹ ایک سافٹ ویئر پروجیکٹ ہے۔ پروجیکٹ انجینئرنگ کا مظاہرہ کرتا ہے۔ مضمون تکنیکی مواصلات کو ظاہر کرتا ہے۔ کوڈ نفاذ کو ظاہر کرتا ہے۔ تعیناتی ترقیاتی کام کے بہاؤ کو ظاہر کرتی ہے۔

اور دستاویزات سے پتہ چلتا ہے کہ کس طرح تکنیکی پیچیدگی کو کسی ایسی چیز میں ترجمہ کیا جا سکتا ہے جسے دوسرے ڈویلپر استعمال کر سکتے ہیں۔

اس طرح میرے خیال میں ایک تکنیکی مصنف کے پورٹ فولیو کو آج کام کرنا چاہیے۔

ایسی ویب سائٹ نہ بنائیں جو صرف یہ کہے کہ آپ تکنیکی مصنف ہیں۔ کوئی ایسی چیز بنائیں جس سے آپ کے دعووں پر شک کرنا مشکل ہو۔

• کوڈ کرنا سیکھیں۔

• اپنا پروجیکٹ بنائیں۔

• چیزیں توڑ دیں۔

• ذخیرہ پڑھیں۔

• ٹیسٹ کی مثال۔

• اپنا دستاویز لکھیں۔

• AI کے ساتھ تیزی سے آگے بڑھیں۔

پھر ہر وہ چیز چیک کریں جو اہم ہے۔

کیونکہ ڈویلپر تکنیکی تحریر کا مستقبل اس بات پر منحصر نہیں ہے کہ کون زیادہ سے زیادہ الفاظ تیار کر سکتا ہے۔ یہ اس بارے میں ہے کہ کون دوسرے ڈویلپرز کو "میں یہ نہیں سمجھتا ہوں” سے لے کر "میں اسے نافذ کر سکتا ہوں” تک جانے میں مدد کر سکتا ہے۔