برنامه نویسی فقط نوشتن کد نیست. این یک سفر رشد مداوم و یادگیری است. چه یک علاقه‌مند جوان باشید، چه یک توسعه‌دهنده متوسط یا یک senior با تجربه، مسیر موفقیت شامل مراحل استراتژیک است. بیایید بررسی کنیم که چگونه می توانید این سفر را طی کنید و حرفه برنامه نویسی خود را ارتقا دهید.
من روی بازنویسی نقشه‌های راه کار می‌کنم، مجموعه مهارت‌ها را بر اساس سطوح ارشدیت تقسیم می‌کنم تا دنبال کردن آنها آسان‌تر شود و توسعه‌دهندگان جدید نترسانند. از آنجایی که نقشه‌های راه فقط در مورد دانش فنی است، فکر می‌کنم ایده خوبی است که تکرار کنم و مقاله‌ای در مورد نظرم درباره نقش‌های ارشدیت مختلف داشته باشم.
سازمان‌های بسیاری را دیده‌ام که با اهمیت دادن بیشتر از آنچه باید به سال‌ها تجربه، در مورد ارشدیت توسعه‌دهندگان تصمیم می‌گیرند. من توسعه دهندگانی با برچسب "جوان" را دیده ام که کار توسعه دهندگان ارشد را انجام می دهند و من توسعه دهندگان "lead" را دیده ام که حتی صلاحیت نامیدن " ارشد" را نداشتند. ارشدیت یک توسعه دهنده را نمی توان فقط با سن، سال ها تجربه یا دانش فنی که دارند تعیین کرد. عوامل دیگری نیز در اینجا نقش دارند. درک آنها از کار، نحوه تعامل آنها با همسالان خود و نحوه برخورد آنها با مشکلات. ما این سه عامل کلیدی را به تفصیل برای هر یک از سطوح ارشد در زیر مورد بحث قرار می دهیم.
عناوین مختلف ارشدیت
سازمان‌های مختلف ممکن است عناوین ارشدیت متفاوتی داشته باشند، اما عمدتاً به سه دسته تقسیم می‌شوند:
- توسعه دهنده جوان یا Junior
- توسعه دهنده سطح متوسط یا Mid Level
- توسعه دهنده ارشد یا Senior
چگونه به عنوان یک برنامه نویس جوان، متوسط یا یک توسعه دهنده ارشد قدم برداریم؟
توسعه دهنده جوان Junior
توسعه دهندگان Junior معمولاً فارغ التحصیلان تازه وارد هستند و یا ندارند یا تجربه حداقلی در صنعت دارند. آنها نه تنها مهارت های کدنویسی ضعیفی دارند، بلکه چند چیز دیگر نیز وجود دارد که توسعه دهندگان جوان را از دست می دهند:
- شعار اصلی آنها "به کار انداختن آن" بدون توجه زیاد به چگونگی دستیابی به راه حل است. برای آنها یک نرم افزار کارآمد و یک نرم افزار خوب معادل هم است.
- آنها معمولاً برای دستیابی به چیزی نیاز به دستورالعمل های بسیار مشخص و ساختار یافته دارند. آنها از دید تونلی رنج می برند، نیاز به نظارت و راهنمایی مستمر دارند تا یک اعضای تیم موثر باشند.
- اکثر توسعه دهندگان Junior فقط سعی می کنند به نقش خود عمل کنند و در صورت گیر افتادن، ممکن است به جای اینکه حداقل تلاش کنند به چیزی ضربه بزنند، کار را به یک توسعه دهنده ارشد بدهند.
- آنها از جنبه تجاری شرکت اطلاعی ندارند و متوجه نمی شوند که مدیریت/فروش/بازاریابی/غیره چگونه فکر می کنند و متوجه نمی شوند که چقدر از کار مجدد، تلاش بیهوده و تشدید کاربر نهایی می تواند با رسیدن به آن صرفه جویی کند. حوزه کسب و کار را بشناسید!
- مهندسی بیش از حد یک مشکل بزرگ است که اغلب منجر به شکست خوردن و باگ می شود.
- هنگامی که مشکلی به آنها داده می شود، اغلب سعی می کنند به جای رفع مشکل ریشه ای، فقط مشکل فعلی را برطرف کنند.
- ممکن است متوجه رفتار "مشکل شخص دیگری" از آنها شوید.
- آنها به لطف اثر دانینگ-کروگر نمی دانند چه چیزی یا چقدر نمی دانند.
- آنها ابتکار عمل نمی کنند و ممکن است از کار بر روی یک پایگاه کد ناآشنا بترسند.
- آنها در بحث های تیمی شرکت نمی کنند.
یک توسعه دهنده جونیور بودن در تیم لزوما چیز بدی نیست. از آنجایی که شما به تازگی شروع به کار کرده اید، از شما انتظار نمی رود که فردی با تجربه بالا باشید. با این حال، این مسئولیت شماست که یاد بگیرید، تجربه کسب کنید، در عنوان "جونیور" گیر نکنید و خود را بهبود بخشید. در اینجا چند نکته برای توسعه دهندگان جوان برای کمک به ارتقاء حرفه ارشدیت وجود دارد:
همه انواع مشکلات را می توان حل کرد اگر به اندازه کافی روی آنها کار کنید. اگر Stack Overflow یا مشکلی در GitHub پاسخی نداشت، تسلیم نشوید. گفتن "من گیر کرده ام، اما X، Y و Z را امتحان کرده ام. آیا شما راهنما دارید؟" به lead خودتان بسیار بهتر از گفتن "این فراتر از من است."
کدهای زیادی را بخوانید، نه فقط کدهای پروژه هایی که روی آنها کار می کنید، بلکه کد منبع مرجع/چارچوب، منبع باز. از توسعه دهندگان همکار خود، شاید در گیت هاب نیز، در مورد نمونه های منبع باز خوب برای زبان/ابزارهای انتخابی خود بپرسید.
پروژه های جانبی شخصی انجام دهید، آنها را با مردم به اشتراک بگذارید، به جامعه منبع باز کمک کنید. برای کمک با مردم تماس بگیرید. شما تعجب خواهید کرد که چقدر می توانید از طرف جامعه حمایت کنید. من هنوز اولین پروژه خود را حدود 5 سال پیش در GitHub به یاد دارم که یک پروژه نیمه شکسته خورده بود با آن شروع کردم و چیزهای زیادی را یاد گرفتم از نحوه commit کردن تا pull و خیلی چیز های دیگر.
از رفتاری که به عنوان «این مشکل برای شخص دیگری است» شناخته می شود، اجتناب کنید.
هنگامی که مشکلی را حل می کنید، سعی کنید به جای رفع علائم، علت اصلی را شناسایی کرده و آن را برطرف کنید. و به یاد داشته باشید، عدم توانایی در تولید مثل حل نشدن است. زمانی حل می شود که بفهمید چرا این اتفاق افتاده و چرا دیگر اینطور نیست.
به کدی که قبل از شما نوشته شده است احترام بگذارید. هنگام قضاوت در مورد معماری یا تصمیمات طراحی گرفته شده در پایگاه کد، سخاوتمند باشید. درک کنید که کد اغلب به دلیلی غیر از بی کفایتی زشت و عجیب است. یادگیری زندگی با کدهای قدیمی و پیشرفت با کدهای قدیمی یک مهارت عالی است. هرگز کسی را احمق فرض نکنید. در عوض، دریابید که چگونه این افراد باهوش، خوش نیت و با تجربه به تصمیمی رسیده اند که اکنون احمقانه است. به جای شکایت، با "فکر فرصت" به ارث بردن کدهای میراثی نزدیک شوید.
اشکالی ندارد که یک سری چیزها را ندانیم. نیازی نیست از اینکه از قبل یک سری چیزها را نمی دانید خجالت بکشید. هیچ سوال احمقانه ای وجود ندارد، هر چند سوال بپرسید که به شما امکان می دهد به طور موثر کار کنید.
اجازه ندهید با عنوان شغلی که دارید محدود شوید. به کار بر روی بهبود خود ادامه دهید.
یادداشت ها را بنویس. پیش بینی کنید چه چیزی از قرار است اتفاق بیفتید. در بحث های تیمی شرکت کنید. حتی اگر اشتباه کنید، چیزی یاد خواهید گرفت.
در مورد دامنه ای که با آن کار می کنید اطلاعات کسب کنید. محصول را به عنوان یک کاربر نهایی درک کنید. مسائل را فرض نکنید، سؤال بپرسید و در صورت شک و تردید، همه چیز را روشن کنید.
یاد بگیرید که به طور موثر ارتباط برقرار کنید. مهارت های نرم مهم است. یاد بگیرید که چگونه ایمیل های خوبی بنویسید، چگونه کار خود را ارائه دهید، چگونه سوالات خود را به شیوه ای متفکرانه بیان کنید.
با توسعه دهندگان ارشد بنشینید، کار آنها را تماشا کنید، یک مربی پیدا کنید. هیچ کس دوست ندارد همه چیز را بداند. نفس خود را در دست بگیرید و آنقدر متواضع باشید که از افراد با تجربه درس بگیرید.
فقط کورکورانه توصیه های "متخصصان" را دنبال نکنید، آن را با یک دانه نمک مصرف کنید.
اگر از شما خواسته شد که برای برخی از کارها تخمینی ارائه کنید، جواب ندهید مگر اینکه تمام جزئیات را برای برآورد معقول داشته باشید. اگر مجبور به انجام این کار هستید، بسته به اینکه چقدر از کارهایی که باید انجام دهید تا کار علامت «انجام شد» را نمی‌دانید، آن را 2 برابر یا بیشتر اضافه کنید.
برای یادگیری نحوه استفاده از دیباگر کمی وقت بگذارید. دیباگرها هنگام پیمایش پایگاه کد جدید، غیرمستند یا ضعیف، یا باگ زدایی مسائل عجیب و غریب بسیار سودمند هستند.
از گفتن «روی دستگاه من کار می‌کند» اجتناب کنید. بله، این را زیاد شنیده‌ام.
سعی کنید هر گونه احساس بی کفایتی یا سندرم فریبنده را به انرژی تبدیل کنید تا خود را به جلو سوق دهید و مهارت ها و دانش خود را افزایش دهید.
توسعه دهندگان سطح متوسط Mid Level
سطح بعدی بعد از توسعه دهندگان Junior، توسعه دهندگان سطح متوسط است. آنها از نظر فنی قوی تر از توسعه دهندگان Junior هستند و می توانند با حداقل نظارت کار کنند. آنها هنوز برای پرش به سطح ارشد مسائلی برای رسیدگی دارند.
توسعه دهندگان متوسط صلاحیت بیشتری نسبت به توسعه دهندگان جوان دارند. آنها شروع به دیدن نقص در پایگاه کد قدیمی خود می کنند. آنها دانش را به دست می آورند، اما در زنجیره بعدی به دام می افتند، یعنی کارها را به هم می ریزند، در حالی که سعی می کنند آنها را به "راه درست" انجام دهند، به عنوان مثال. Abstract های عجولانه، استفاده بیش از حد یا استفاده غیرضروری از الگوهای طراحی، ممکن است بتوانند راه حل را سریعتر از توسعه دهندگان Junior ارائه دهند، اما این راه حل ممکن است شما را در درازمدت به چاله دیگری وارد کند. بدون نظارت، ممکن است اجرا را به تعویق بیندازند در حالی که سعی می کنند کارها را به درستی انجام دهند. آنها نمی دانند چه زمانی باید معامله کنند و هنوز نمی دانند چه زمانی جزم گرا و چه زمانی عمل گرا باشند. آنها می توانند به راحتی به راه حل خود وابسته شوند، نزدیک بینی شوند و قادر به گرفتن بازخورد نباشند.
توسعه دهندگان سطح متوسط بسیار رایج هستند. بسیاری از سازمان ها به اشتباه آنها را به عنوان "توسعه دهندگان ارشد" برچسب گذاری می کنند. با این حال، آنها برای تبدیل شدن به توسعه دهندگان ارشد نیاز به راهنمایی بیشتر دارند. بخش بعدی مسئولیت های یک توسعه دهنده ارشد و چگونگی تبدیل شدن به آن را شرح می دهد.
توسعه دهندگان ارشد Senior
توسعه دهندگان ارشد در سطح بعدی بعد از توسعه دهندگان سطح متوسط قرار دارند. آنها افرادی هستند که می توانند کارها را به تنهایی بدون هیچ نظارتی و بدون ایجاد هیچ مشکلی در مسیر انجام دهند. آنها بالغ‌تر هستند، با ارائه نرم‌افزار خوب و بد در گذشته تجربه کسب کرده‌اند و از آن درس گرفته‌اند، آنها می‌دانند که چگونه عملگرا باشند. در اینجا لیستی از مواردی است که معمولاً از یک برنامه نویس ارشد انتظار می رود:
آنها با تجربیات گذشته خود، اشتباهات مرتکب شده، مشکلاتی که نرم افزارهای بیش از حد طراحی شده یا طراحی نشده با آن مواجه هستند، می توانند مشکلات را پیش بینی کرده و جهت پایگاه کد یا معماری را متقاعد کنند.
آنها سندرم "اسباب بازی براق" ندارند. که یعنی این هیچ تمایلی به داشتن و استفاده از جدیدترین و ظاهراً بزرگترین، اغلب صرف نظر از نیاز عملی به آن است ندارند. آنها در اجرا عملگرا هستند. آنها می توانند در صورت لزوم، معاوضه را انجام دهند و می دانند چرا. آنها می دانند کجا جزم گرا و کجا عمل گرا باشند.
آنها تصویر خوبی از این رشته دارند، می دانند که در بیشتر موارد بهترین ابزار برای کار چیست (حتی اگر ابزار را نشناسند). آنها این توانایی ذاتی را دارند که ابزار/زبان/پارادایم/غیره جدیدی را انتخاب کنند تا مشکلی را که به آن نیاز دارد حل کنند.
آنها می دانند که در یک تیم هستند. آنها به آن به عنوان بخشی از مسئولیت خود برای راهنمایی دیگران نگاه می کنند. این می تواند از برنامه نویسی جفتی با توسعه دهندگان جوان گرفته تا انجام کارهای غیرقابل شکوه نوشتن داکیومنت یا تست ها یا هر کار دیگری که باید انجام شود، متغیر باشد.
آنها درک عمیقی از دامنه دارند - آنها در مورد جنبه تجاری شرکت می دانند و متوجه می شوند که مدیریت/فروش/بازاریابی/غیره چگونه فکر می کنند و از دانش خود از حوزه تجاری در طول توسعه بهره می برند.
آنها شکایت های توخالی نمی کنند، آنها بر اساس شواهد تجربی قضاوت می کنند و پیشنهاداتی برای راه حل دارند.
آنها خیلی بیشتر از فقط کد فکر می کنند، آنها می دانند که وظیفه آنها ارائه راه حل برای مشکلات است نه فقط نوشتن کد.
آنها توانایی مقابله با مشکلات بزرگ بد تعریف شده، تعریف آنها، شکستن آنها و اجرای قطعات را دارند. یک توسعه دهنده ارشد می تواند چیزی بزرگ و انتزاعی را بگیرد و با آن اجرا کند. آنها چند گزینه را مطرح می کنند، آنها را با تیم مورد بحث قرار می دهند و آنها را اجرا می کنند.
آنها به کدی که قبل از آنها نوشته شده است احترام می گذارند. آنها هنگام قضاوت در مورد معماری یا تصمیمات طراحی گرفته شده در پایگاه کد سخاوتمند هستند. آنها به ارث بردن کد میراث با "ذهنیت فرصت" به جای شکایت نزدیک می شوند.
آنها می دانند چگونه بدون آسیب رساندن به کسی بازخورد بدهند.
نتیجه
همه تیم ها از ترکیبی از همه این نقش های ارشدیت تشکیل شده اند. راضی بودن از نقش خود چیز بدی است و همیشه باید برای پیشرفت خود برای قدم بعدی تلاش کنید. این مقاله بر اساس اعتقادات و مشاهدات من در شرکت ها است. بسیاری از شرکت‌ها بیشتر به سال‌ها تجربه برای تصمیم‌گیری در مورد ارشدیت اهمیت می‌دهند که یک معیار نامرتب است، شما فقط با صرف سال‌ها تجربه کسب نمی‌کنید. شما آن را با حل مستمر انواع مختلف مشکلات، صرف نظر از تعداد سال هایی که در حرفه خود سپری می کنید، به دست می آورید. من فارغ التحصیلان تازه واردی را دیده ام که هیچ تجربه ای در حرفه خود نداشته اند و به سرعت به کار یک مهندس ارشد می پردازند و توسعه دهندگان ارشد را دیده ام که صرفاً به دلیل سن و سال ها تجربه به خود برچسب " ارشد" داده اند.
مهم‌ترین ویژگی‌هایی که برای ارتقای شغلی خود باید داشته باشید عبارتند از: نپذیرفتن با متوسط بودن، داشتن ذهنیت باز، فروتنی، درس گرفتن از اشتباهات خود، کار کردن بر روی مشکلات چالش برانگیز و داشتن ذهنیت فرصت به جای شکایت کردن.
نظر شما در مورد سطوح ارشدیت توسعه دهندگان چیست؟ با ما همراه باشید!