بقالك كتير بتقدم على وظايف و انترفيوهات كتير و اخيرا ربنا وفقك و جالك ال job offer اللي كان نفسك فيه. في معظم الشركات بيبقي في فتره تجريبيه و دايما الناس بتبقي متوترة ازاي تعدي الفتره دي علي خير. خليني بس اقولك انك طالما عديت الانترفيوهات (بالذات لو كانت ال hiring process طويله) ف انت بنسبه كبيره عندك كل ال skills اللي هما بيدوروا عليها و اطمن انت ان شاء الله هتعدي من الفتره دي. هما بس بيبقو عايزين يتأكدوا أن اختيارهم كان في محله و يشوفو فعلا خبرتك العملية. في النقط اللي جايه هقولك بناء على خبرتي ازاي كنت بعدي الفتره دي و بكمل مع الشركة بنجاح.

اعرف بالظبط ايه المتوقع منك و انت جاي هنا تعمل ايه

دي اول حاجه تحاول تعرفها في اول كام يوم ليك. هل هتكون مسؤول عن جزء معين من service? ولا هتكون شغال مع team مسؤول عن مجموعة من ال features. و ايه هو ال business domain اللي هتكون شغال فيه و حاول تفهمه كويس. يعني مثلا هتكون شغال في ال search team ولا ordering ولا payment و حاول تفهم ال business بتاع الجزء ده علي قد ما تقدر.

مثلا أنهم ال product بيكبر و عندهم مشاكل في ال scalability? او كان عندهم نقص في ال software engineers المسولين عن ال monitoring؟ او عايزين ناس اكتر عشان بيزود features اكتر؟
اعرف انت ايه اللي متوقع منك بالظبط انك تعرف دا هيساعدك مش ف انك بس تعدي ال probation ولكن انك تكبر في ال role اللي انت فيه و في الشركه عامة.

وأهم نصيحة ليك حاول تفهم كويس كل كبيرة وصغيرة عن ال business اللي انت هتشتغل عليه.

اسأل كل اللي نفسك فيه في ال onboarding

دا احسن وقت تسأل فيه عن اي حاجه مبهمة او مش واضحه ليك. متتكسفيش ولا تحس ان اسئلتك غبيه. لأن انت لسه جديد ف دا طبيعي جدا. حاول تطلب من مديرك أن يكون كل اسبوع عندك on boarding buddy. يعني كل اسبوع يكون في حد من ال team هوا اللي بترجع له لو عايز تسال في حاجه. ومفيد لسببين

• انك متعطلش ال team او تشتتهم بأسألتك

• كل فرد في الـ team بيبقي شاطر اوي في جزء ما في ال project ف تبقي جمعت معلومات من كل الخبرات في كل اجزاء ال project علي قد ما تقدر.

اكتب كل حاجه جديده عرفتها او سمعت عنها

كمية المعلومات اللي هتوصلك في اول فتره ليك هتكون كبيره جدا و دا طبيعي. وطبيعي أن حجم المعلومات ممكن يكون اكبر من استيعابك في اوقات كتير. عشان متنساش المعلومات دي اعمل document على جنب اكتب فيه اي حاجه حد يقولهالك. حتى لو كانت link ل حاجه في ال system. اكتب برضه الاسئلة و الاجابات اللي كنت بتسألها طول فتره ال onboarding عشان لو نسيت حاجه منهم متروحش تسألها تاني.

شخصيا انا عندي document زي دا من اول يوم بروح فيه اي شركه. في الغالب مش بيبقي منظم اوي بس بعد شويه بقسم الحاجات دي. المعلومات اللي كاتبها مثلا كانت عبارة عن

• Commands معينه عشان اعمل حاجه معينه

• شخص معين انا عرفت انا مسؤول عن حاجه معينه ف عايز افتكر اني لو احتاجت اسأل عن حاجه تاني ارجعله

• شرح لحاجة حد قالي عليها واحنا بندردش

• Links ل slack threads فيها كلام مهم

• حاجه اتشرحتلي و مفهمتهاش و عايز ارجع لها تاني

• Dashboards لحاجات معينة في ال projects

حاول تحسن ال existing documents

دايما اي team لو عنده documentation هتكون في تفاصيل ناقصة هما مش واخدين بالهم منها عشان أيديهم دائما في الشغل. ممكن قرارات كتير تكون مش مكتوب هما قرروها ليه لانهم عارفين هما عملو دا ليه. ف دايما ال fresh eye او الحد الجديد هوا اللي ممكن ياخد باله من النقص دا. ف دا احسن حاجه تعملها انك تحاول ت contribute لل documentation بالحاجات اللي انت شايفها ناقصه و دي هتبقي حاجة كبيرة تتحسب ليك انك بتحاول تحسن شغلك حتى من اول يوم

اعمل لنفسك brag document

يعني ايه الاول brag document هو مكان تكتب فيه كل انجازاتك اللي عملتها سواء كبيره او صغيره. عشان كل مره تقعد مع مديرك مش هتكون ولا انت ولا هو فاكرين كل تفاصيل الحاجات اللي عملتها. دائما حاول تقول ايه ال impact بتاع كل حاجة انت عملتها

لو عايز مثال علي ازاي تعمل brag document كويس دا مقال بيتكلم بالتفصيل عن ازاي تعمل كدا https://jvns.ca/blog/brag-docuenter code herements/

بس لو عايز رأيي الشخصي مش لازم تمشي على مثال ولا standard. اكتب بالطريقه اللي تريحك و مع الوقت اقرا و اتعلم و حسن مع الوقت عشان متصعبش الموضوع على نفسك. Always start simple

اعمل 1o1 meetings مع مديرك باستمرار

من اهم الحاجات اللي هتخلي ان ميحصلش اي مفاجئات وقت ال review اللي بيحصل بعد اول ٦ شهور انك دايما تعمل اجتماع دوري مع مديرك تتكلمو فيه عن ال progress بتاعك. عشان دايما تبقي عارف ايه ال review او الانطباع اللي هوا واخده عن شغلك.

خلي دايما ال meeting دي يبقي ليها meeting minutes مكتوبة في مكان ما انتو الاتنين شايفينه (ممكن share google doc). لازم برضه تكتب action plan واضحه و صريحه ليكو انتو الاتنين. لو مديرك طلب منك اي action لازم ال action دا يكون tangible values واضحه و صريحه. يعني مثلا مينفعش ال action يكون انه يقولك اقرا كتاب او خد كورس او حسن كودك. لا لازم يكون في results واضحة.

زي مثلا اقرا كتاب كذا. دي نتائجها ممكن تكوت

• اعملنا session تشرح فيها النتايج

• او اللي اتعلمته

• و ايه من الكتاب دا استفدت منه

• و ايه ممكن نطبقه في الـ team عندنا

مثلا لو قالك improve your code quality ممكن مثلا يظبطلك pair programming session كل فتره مع حد معين او كورس تاخده او كتاب تقراه و نتايج دا ان ال code review changes اللي بتتحط ليك تبقى non-trivial شويه.

الخلاصة لازم اي action يبقي ليها خطوات واضحه و صريحه و نتايج برضه واضحه و صريحه عشان ما تتفاجئش في الاخر ان مش هوا دا اللي هوا عايزه.

حاول تكون علاقات كويسه مع ال knowledge share holders و مع زمايلك

زمايلك الجداد هما بالنسبالك showledge shareholders هما اللي ممكن يسهلو عليك اي حاجه انت شغال عليها او يفهموك اي حاجه انت شغال عليها او يفهموك حاجه انت لسه مش فاهمها كويس. و هتلاقي كل واحد منهم فاهم كويس اوي في جزء معين في ال system. فحاول انك تخلي علاقتك كويسه بيهم كلهم عشان يبقي عندك credit انت تطلب مساعدتهم بعد كدا. و في نفس الوقت انت اعرض عليهم المساعدة في اي حاجه تقدر تساعدهم فيها حتى من قبل ما يطلبو منك.

متشتغلش على حاجه انت مش فاهمها كويس

اول ما هتروح اي team جديد هتلاقيهم مجهزين list بال tickets اللي ممكن تكون هتشتغل فيها. نصيحتي ابدا بابسط ticket تقدر عليها علشان اول ticket انت هتكون متوتر و عشان نفسيا تلاقي نتيجه بسرعه و تحس انك بتطلع شغل. خد بالك ان كمان هتاخد شوية وقت عقبال ما تعرف تشغل الـ project لاول مره علي جهازك. نصيحه كمان لو عندهم guideline ازاي تشغل ال project علي جهازك امشي وراه و في الغالب بيبقي في نقط ناسينها او ال document نفسه outdated لان بقالهم كتير شغالين على نفس ال project ف مش واخدين بالهم انهم يعدلو علي ال document. ف هتكون فرصه حلوه انك تساعدهم في انك تعمل update لل document دا.

نصيحه كمان اوعي تبدأ ب critical ticket أو ticket بتعدل علي core feature عشان لو حصل مشكله مش بس ممكن دا ياثر علي تقييمك. لا انت كمان ممكن ثقتك في نفسك تقل. و دا حصل معايا كتير.

طيب خلصت اول ticket ازاي اختار ال tickets. ساعات هتلاقي مديرك بيقولك خد ال ticket دي. ساعتها لازم تاخد وقتك انت تقراها كويس لوحدك و تحاول تجمع معلومات عن الجزء اللي هتعدل عليه او ال feature اللي هتكون مسؤول عنها. و حاول في الاول تاخد ال tickets اللى ليها علاقه ب feature محدد و صريحه. بلاش ال tickets اللي تخليك تلف علي ال project كله.

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

المرحله اللى جايه بنقول عليها ال refinement. و هنا بتبدا تفتح ال code تمسك ورقه و قلم و ترسم كروكي كدا الدنيا شغاله ازاي و تعرف انت هتعدل على ايه. مش لازم تمشي على اي standard وانت بترسم. مش لازم uml او اي حاجه مشهوره. ارسم حاجه اللي يشوفها يفهم منين بيودي علي فين.

اكيد هيكون عندك كم كبير من الأسئلة و هنا ممكن ترجع ال onboarding duddy بتاعك او تسال ال team عامة. جمع كل أسئلتك مرة واحدة و ابدا اسالهم. و في الوقت دا متتكسفش حتي لو شايف السؤال دا غبي اسال براحتك. اصلا الفتره اللي في الاول هما متوقعين انك تسأل حتى اساله بدائيه جدا. ف نصيحتي بلاش كسوف و متحسش نفسك انك غبي. اسال كل اللي نفسك فيه. اسال كتير.

خلاص جمعت كل الاسئله اللي في دماغك. ابدأ ارسم الحل بتاعك او التعديلات دي كروكي او حتي اكتب pseudo code. حاجه بس توضح انت هتعمل ايه. و بدا وريهم الحل اللي انت فكرت فيه و خد رأي زملائك فيه واسمع منهم ال feedback. متتوترش لو لقيت عندهم تعليقات كتي. عادي جدا انت لسه جديد على الـ project و اكيد هما خبرتهم في ال project دا اكبر منك.

بعدها ابدا اعمل update لل ticket بالتفاصيل دي و يا سلام لو عملت document بيشرح اللي انت هتعمله.

خلصت؟ اقعد مع حد زميلك خليه يبص بصه سريعه و يجرب الحل النهائي. ممكن برضه تطلب من الـ QA يساعدك ف انك تعمل test. بعدها ابدا افتح pull request و خد رأي الناس في ال code. وبكده نقدر نقول مبروك اول contribution

اهم نصيحة هيا انك تسال كل اللي نفسك فيه. اسال كتير و متتكسفش…

متحاولش تحل نفس المشاكل بنفس الحلول اللي استخدمتها في شغلك القديم

دي من اكتر الحاجات الغلط اللي ممكن تعملها. خليك دايما عارف ان نفس المشكله ممكن تتحل باكتر من طريقه و لكن الحل اللي هتختاره هيختلف بناء علي ال context و الموقف. يعني مثلا ممكن مشكله ليها علاقه بال scalability او مثلا انك عايز ت handle requests per minute اكتر تكون انت حليتها في شغلك القديم بانك زودت شويه resources. لكن الحل دا ممكن ميكونش احسن حل في شغلك الجديد. مثلا في شغلك القديم حليتو مشاكل ال database بانك زودت ال instance size لكن في شغلك الجديد دا مش هيكون احسن حل مناسب.

متلومش علي اي code مش مكتوب بطريقه كويسه او اي قرار technical قديم حتى لو كان غلط

خلينا متفقين ان مفيش code مفيهوش مشاكل. و مفيش code مفيهوش bugs. و انت متعرفش ايه الظروف اللي اتكتب فيها ال code دا. ولا الـ deadline كان عامل ازاي. و ممكن ان دي كانت feature اصلا معموله بالشكل دا عشان proof of concept. ف كونك تنتقد code انت مكنتش عارف ظروفه ف هيا حاجه مش هتفيد ف اي حاجه. و عامه هيا عاده مش كويسه. لو شايف حاجة غلط اقترح حلول و لو الحلول دي تنفع اكيد الناس هتسمع لك.

قبل ما تروح تشتكي دور علي حلول

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

أي قرار تاخده ليه علاقه بالشغل لازم يكون مكتوب في مكان ما

ببساطة الناس ممكن تنسي احنا اخدنا القرار دا ليه او امتي. دا غير انك ممكن متكونش فاهم الموضوع بتفاصيله اوي ف لما تحاول ت document القرار او المناقشه دي تكتشف ان في شوية نقاط كانت واقعة منك. انك ت document كل القرارات اللي بتاخدها دا هيساعد ان كلكوا تبقوا on the same page.

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