كان بقالي فترة عايز أكتب ثريد عن أهمية الكتابة خاصة design docs و proposals في كارير السوفتوير. الثريد هيبقى عن نصايح اتقالتلي او حاجات اتعلمتها من document reviews اللي عديت بيها. مهم أقول إن كل شركة ليه طبيعتها والحاجات اللي بتركز عليها فهحاول اخلي الكلام عام لأغلب الحالات
ممكن الكلام يكون بديهي بس ليه الكتابة مهمة؟ عشان هي وسيلة من وسائل التواصل ولو ركزت ف شغلنا هتلاقي اغلب الوقت انت بتحاول توصل للي حواليك حاجة سواء بترد على ايميل او سلاك. انك تعمل pull request ده محتاج تشرح انت بتعمل كده ليه وعملته ازاي. حتى ال comments في الكود
أنا هنا هركز أكتر على design docs أو docs ف العموم ودي بتيجي ف كذا مرحلة زي انك تعمل ديزاين لمشروع أو تحاول تقنع التيم بفكرة أوتلخص اللي عملتوه للمدراء فوقك وحتى الملفات اللي بتتكتب بعد المشروع يخلص عشان تلخص اللي اتعمل او تشرح حتى فيها. مش القصد هنا library tech docs مثلا
وهلخص هنا النصايح اللي كنت عايز اقولها ١. اعرف كويس جداً الدوك ده هيتكتب لمين! التفاصيل واللغة بتختلف لو هتكتب لزمايلك ف التيم عن لو هتكتب ل sales عن head of engineering مثلا. مهم تحط ف المقدمة الدوك ده بيخاطب مين. أو لو موجه لكذا حد، ممكن تنصح لو يعدوا أجزاء مش مهمة ليهم
٢. حاول تستخدم template اللي التيم بيستخدمها ولو مفيش ممكن تكون دي فرصة ليك/ي إنك تساهم بحاجة زي كده. سكاشن زي introduction, overview, high level design, Recommendation, Appendix كلها مهمة ومش شرط تكون ف كل دوك وفيه تاني ممكن تضاف على حسب طبيعة التيم زي مثلا تيم يحط سكشن testing
٣. من النصائح المهمة اللي جاتلي فكرة انك بعد ماتكتب تقرأ تاني بكذا طريقة عشان تتأكد ان مفيش حاجة ناقصة او غلط. بيسموها proof reading زي انك تقرأ عشان تركز ع غلطات املائية أو تقرأ عشان تراجع الارقام والتكنكال اللي ف الدوك وهكذا. Grammerly و google docs بيساعدوا
٤. نيجي بقى لمرحلة الريفيو. مديري القديم كان دايما يقولي build allies وده مهم لما تكون هتراجع حاجة مع عدد كبير أو تيم تاني. لو مع التيم بتاعك مهم توري الدوك لواحد او تنين شغالين معاك خاصة لو سنيور يقولوا رايهم وتتجنب اي غلطات سهلة ف الاول او حاجة فاتتك. ممكن تستخدم المدير برده
لو هتروح لتيم تاني عشان مثلا هتعدل حاجة عندهم او هتعمل ديزاين عندهم مهم جدا جدا تجيب واحد او اتنين من هناك يبصوا على الكلام الاول عشان: يتاكدوا ان فكرتك صح لانك ف الاخر مش اكيد فاهم السيستم زيهم، والنقطة التانية انك لما تدخل الريفيو مع التيم هما يدافعوا عنك لو فيه اختلاف
وده بسبب انهم شافوا الدوك قبل كده وساهموا ف تعديله فهما دلوقتي ف موقف الشريك مش المُراجع. وحاجة كمان إنك تدي credit when credit is due فلو حد عنده فكرة او ساهم على الاقل تشكره ف الميتينج قدام الناس
٥.لو هتعمل ميتينج مع اي حد يبص على الدوك ابعت لينك ليه ف ال invitation ووضح هل مطلوب منهم يقروه قبل المتينيج ولالا. بالنسبة ليا انا بفضل طريقة امازون (واعتقد كتير بيعمل كده دلوقتي) ان قراية الدوك جزء من الميتينج.عادة اول تلت ساعة، لو حد تطوع وقرأ قبل كده دي منه بس مش كله عنده وقت
٦. ف ميتينج الريفيو بعد مالناس ماتقرأ عدي على الأسئلة واحد واحد ورد عليهم. متقرأش الدوك او تحاول تشرحه لان ده مفروض حصل. لو سؤال هياخد وقت كتير او حاجة متحلتش ممكن تاخد السؤال اوفلاين وترد بعدين. لو السؤال جوهري ف الفكرة قول انك هتتأكد بس ممكن نفترض دلوقتي ونرد على بقية الاسئلة
٧. لخص ف أخر الريفيو كل action items وخليك/ي واضح ف فكرة هل فيه alignment وهنشتغل على كده ولا فيه حاجات محتاجة تتعدل ولا محتاجين نعمل ريفيو تاني.
٨. أتاكد ان الدوك التيم/الشركة ليها access عليه بعد الريفيو عشان لو حد عايز يرجعله عشان فيه ناس بتنسى تحط الدوك ف فولدر التيم مثلاً
٨. أتاكد ان الدوك التيم/الشركة ليها access عليه بعد الريفيو عشان لو حد عايز يرجعله عشان فيه ناس بتنسى تحط الدوك ف فولدر التيم مثلاً
دي كل الأفكار اللي في دماغي بناء على الكام سنة اللي فاتت وأكيد فيه ناس عندها خبرة اكتر ونصايح أكتر بس ال comm مهمة جدا جدا وبتفرق ف الكارير بشكل رهيب.
الكورس ده من الكورسات اللي ساعدتني جدا developers.google.com
والكتاب ده مديري نصحني بيه وكان كويس عن فكرة ان ازاي تشيل الكلام اللي ملوش لازمة عشان الكلام يبقى واضح و to the point
amazon.com
amazon.com
فيه نصيحة مهمة كانت ف دماغي ونسيت اكتبها وهي إن مهم ف ديزاين دوك تحط alternative options/designs وليه الديزاين اللي فوق هو أحسن اوبشن. عشان غالباً ده سؤال هتتسأله ف مينينج الريفيو
جاري تحميل الاقتراحات...