چرا فقط ارتقاء کد نویسی شما را به یک توسعه دهنده بهتر تبدیل نمی کند

Techlead Skyeng Kirill Rogovoy (فلش هه) در کنفرانس ها ارائه می دهد و در آن در مورد مهارت هایی صحبت می کند که هر توسعه دهنده خوب باید برای تبدیل شدن به بهترین آن را توسعه دهد. از او خواستم این داستان را با خوانندگان هابرا به اشتراک بگذارد، من حرف را به کریل می دهم.

افسانه در مورد یک توسعه دهنده خوب این است که او:

1. کد تمیز می نویسد
2. فناوری های زیادی را می شناسد
3. کدنویسی وظایف سریعتر
4. مجموعه ای از الگوریتم ها و الگوهای طراحی را می داند
5. می تواند هر کدی را با استفاده از Clean Code بازسازی کند
6. زمان را برای کارهای غیر برنامه نویسی تلف نمی کند
7. 100٪ بر فناوری مورد علاقه خود مسلط هستید

این گونه است که منابع انسانی نامزدهای ایده‌آل را می‌بیند و بر این اساس، جای خالی نیز به این شکل است.

اما تجربه من می گوید که این خیلی درست نیست.

اول، دو سلب مسئولیت مهم:
1) تجربه من تیم های محصول است، یعنی. شرکت هایی با محصول خود، نه برون سپاری؛ در برون سپاری همه چیز می تواند بسیار متفاوت باشد.
2) اگر شما یک جوان هستید، پس همه توصیه ها قابل اجرا نخواهد بود، و اگر من جای شما بودم، فعلا روی برنامه نویسی تمرکز می کردم.

توسعه دهنده خوب: واقعیت

1: کد بهتر از حد متوسط

یک توسعه دهنده خوب می داند که چگونه معماری جالبی ایجاد کند، کد جالب بنویسد و باگ های زیادی ایجاد نکند. در کل بهتر از حد متوسط ​​عمل می کند اما جزو 1 درصد متخصصان برتر نیست. بسیاری از جذاب ترین توسعه دهندگانی که من می شناسم، کدنویسان خوبی نیستند: آنها در کاری که انجام می دهند عالی هستند، اما نمی توانند کار فوق العاده ای انجام دهند.

2: مشکلات را به جای ایجاد آنها حل می کند

بیایید تصور کنیم که باید یک سرویس خارجی را در پروژه ادغام کنیم. ما مشخصات فنی را دریافت می کنیم، به مستندات نگاه می کنیم، می بینیم که چیزی در آنجا قدیمی است، می فهمیم که باید پارامترهای اضافی را پاس کنیم، برخی تنظیمات را انجام دهیم، سعی می کنیم همه آن را به نحوی اجرا کنیم و برخی از روش های کج را به درستی کار کنیم، در نهایت، پس از یک زوج چند روزه می فهمیم که نمی توانیم اینطور ادامه دهیم. رفتار استاندارد یک توسعه دهنده در این شرایط این است که به تجارت بازگردد و بگوید: «من این کار را کردم و آن را انجام دادم، این یکی آنطور کار نمی کند و آن یکی اصلاً کار نمی کند، پس خودتان بروید آن را کشف کنید. ” یک کسب و کار مشکلی دارد: شما باید در مورد آنچه اتفاق افتاده است تحقیق کنید، با کسی ارتباط برقرار کنید و سعی کنید به نحوی آن را حل کنید. تلفن شکسته شروع می شود: "تو به او بگو، من به او پیام می دهم، ببین چه جوابی دادند."

یک توسعه دهنده خوب، در مواجهه با چنین موقعیتی، خودش مخاطبینی را پیدا می کند، تلفنی با او تماس می گیرد، مشکل را با او در میان می گذارد، و اگر چیزی درست نشد، افراد مناسب را جمع می کند، همه چیز را توضیح می دهد و جایگزین هایی را ارائه می دهد (به احتمال زیاد، دیگری وجود دارد. خدمات خارجی با پشتیبانی بهتر). چنین توسعه دهنده ای یک مشکل تجاری را می بیند و آن را حل می کند. تکلیف او زمانی بسته می شود که یک مشکل تجاری را حل کند، نه زمانی که به چیزی برخورد کند.

3: سعی می کند حداقل تلاش را صرف کند تا حداکثر نتیجه را بگیرد، حتی اگر به معنای نوشتن عصا باشد

توسعه نرم‌افزار در شرکت‌های تولیدکننده تقریباً همیشه بزرگترین هزینه است: توسعه‌دهندگان گران هستند. و یک توسعه‌دهنده خوب می‌داند که یک کسب‌وکار می‌خواهد با صرف حداقل‌ها، حداکثر پول را به دست آورد. برای کمک به او، یک توسعه دهنده خوب می خواهد حداقل زمان گران خود را صرف کند تا حداکثر سود را برای کارفرما به دست آورد.

در اینجا دو افراط وجود دارد. یکی این است که شما به طور کلی می توانید تمام مشکلات را با چوب زیر بغل حل کنید، بدون اینکه در مورد معماری، بدون بازسازی و غیره زحمت بکشید. همه ما می دانیم که این معمولاً چگونه به پایان می رسد: هیچ چیز کار نمی کند، ما پروژه را از ابتدا بازنویسی می کنیم. مورد دیگر زمانی است که یک فرد سعی می کند برای هر دکمه یک معماری ایده آل ارائه دهد و یک ساعت را برای کار و چهار ساعت را برای بازسازی مجدد صرف کند. نتیجه چنین کاری عالی به نظر می رسد، اما مشکل اینجاست که در بخش تجاری، به دلایل مختلف، در هر دو مورد اول و دوم، ده ساعت طول می کشد تا یک دکمه کامل شود.

یک توسعه دهنده خوب می داند که چگونه بین این افراط ها تعادل برقرار کند. او زمینه را درک می کند و تصمیم بهینه را می گیرد: در این مشکل من یک عصا را می برم، زیرا این کدی است که هر شش ماه یک بار لمس می شود. اما در این یکی، من زحمت می کشم و همه چیز را تا حد امکان به درستی انجام می دهم، زیرا صد ویژگی جدید که هنوز توسعه نیافته اند به موفقیت من بستگی دارد.

4. سیستم مدیریت کسب و کار خود را دارد و قادر به کار بر روی پروژه های هر پیچیدگی در آن است.

کار بر روی اصول انجام کارها - وقتی همه وظایف خود را در نوعی سیستم متنی یادداشت می کنید، هیچ توافقی را فراموش نکنید، همه را تحت فشار قرار دهید، به موقع در همه جا حاضر شوید، بدانید چه چیزی در حال حاضر مهم است و چه چیزی مهم نیست، هرگز وظایف را از دست نمی دهید. خصوصیت عمومی چنین افرادی این است که وقتی در موردی با آنها توافق می کنید، هرگز نگران نمی شوید که فراموش کنند. و شما همچنین می دانید که آنها همه چیز را یادداشت می کنند و سپس هزار سوال نخواهند پرسید که پاسخ آنها قبلاً بحث شده است.

5. هرگونه شرط و مقدمه را سؤال می کند و توضیح می دهد

در اینجا نیز دو افراط وجود دارد. از یک طرف، شما می توانید در مورد تمام اطلاعات مقدماتی شک داشته باشید. مردم قبل از اینکه شما راه حل هایی را ارائه دهید، اما فکر می کنید که می توانید بهتر عمل کنید و شروع به بحث مجدد در مورد همه چیزهایی که پیش از شما بود کنید: طراحی، راه حل های تجاری، معماری و غیره. این امر زمان زیادی را هم برای توسعه‌دهنده و هم برای اطرافیانش تلف می‌کند و بر اعتماد درون شرکت تأثیر منفی می‌گذارد: افراد دیگر نمی‌خواهند تصمیم بگیرند، زیرا می‌دانند که آن شخص برمی‌گردد و همه چیز را خواهد شکست. حالت افراطی دیگر زمانی است که یک توسعه‌دهنده هرگونه مقدمه، مشخصات فنی و خواسته‌های تجاری را به عنوان چیزی حک شده در سنگ درک می‌کند و تنها زمانی که با مشکلی حل‌ناپذیر مواجه می‌شود شروع به فکر کردن به این می‌کند که آیا اصلاً کاری را انجام می‌دهد یا خیر. یک توسعه‌دهنده خوب در اینجا یک راه میانه پیدا می‌کند: او سعی می‌کند قبل از اینکه کار به سمت توسعه برود، تصمیمات قبل یا بدون او گرفته شده را درک کند. کسب و کار چه می خواهد؟ آیا ما مشکلات او را حل می کنیم؟ طراح محصول راه حلی ارائه کرد، اما آیا می دانم که چرا این راه حل جواب می دهد؟ چرا رهبر تیم این معماری خاص را ارائه کرد؟ اگر چیزی روشن نیست، پس باید برید بپرسید. در فرآیند این شفاف سازی، یک توسعه دهنده خوب ممکن است راه حل جایگزینی را ببیند که قبلاً به ذهن کسی خطور نکرده بود.

6. فرآیندها و افراد اطراف شما را بهبود می بخشد

فرآیندهای زیادی در اطراف ما در حال انجام است - جلسات روزانه، ملاقات ها، اسکرام ها، بررسی های فنی، بررسی کد و غیره. یک توسعه‌دهنده خوب بلند می‌شود و می‌گوید: ببینید، ما دور هم جمع می‌شویم و هر هفته درباره یک موضوع بحث می‌کنیم، من نمی‌دانم چرا، ممکن است این ساعت را صرف Contra کنیم. یا: برای سومین کار متوالی نمی توانم وارد کد شوم، هیچ چیز مشخص نیست، معماری پر از سوراخ است. شاید کد بازبینی ما لنگ باشد و ما نیاز به اصلاح مجدد داشته باشیم، بیایید هر دو هفته یکبار جلسه را دوباره تنظیم کنیم. یا در حین بررسی کد، شخصی می بیند که یکی از همکارانش از ابزار خاصی به اندازه کافی استفاده نمی کند، به این معنی که باید بعداً مطرح شود و توصیه هایی ارائه کند. یک توسعه دهنده خوب این غریزه را دارد؛ او چنین کارهایی را به صورت خودکار انجام می دهد.

7. در مدیریت دیگران، حتی اگر مدیر نباشد، عالی است

این مهارت به خوبی با موضوع «حل به جای ایجاد مشکلات» ارتباط دارد. غالباً در متن شغلی که ما درخواست می کنیم، چیزی در مورد مدیریت نوشته نشده است، اما پس از آن، زمانی که با مشکلی خارج از کنترل شما روبرو می شوید، باز هم باید دیگران را به هر طریقی مدیریت کنید، اگر از آنها چیزی به دست آورید. فراموش کرد - فشار دهید، مطمئن شوید که آنها همه چیز را فهمیده اند. یک توسعه‌دهنده خوب می‌داند چه کسی به چه چیزی علاقه دارد، می‌تواند با این افراد جلسه بگذارد، توافق‌نامه‌ها را بنویسد، آن‌ها را شلخته بفرستد، در روز مناسب به آنها یادآوری کند، مطمئن شود که همه چیز آماده است، حتی اگر شخصاً مستقیماً مسئول آن نباشد. این وظیفه، اما نتیجه او به اجرای آن بستگی دارد.

8. دانش خود را جزم نمی داند، دائما در معرض انتقاد است

همه می توانند یک همکار را از شغل قبلی خود به یاد بیاورند که قادر به مصالحه با فناوری خود نیست و فریاد می زند که همه به خاطر برخی جهش های اشتباه در جهنم خواهند سوخت. یک توسعه دهنده خوب، اگر 5، 10، 20 سال در صنعت کار کند، می فهمد که نیمی از دانشش پوسیده است و در نیمه باقی مانده، ده برابر بیشتر از آنچه می داند، نمی داند. و هر بار که کسی با او مخالف است و جایگزینی ارائه می دهد، حمله به نفس او نیست، بلکه فرصتی برای یادگیری چیزی است. این به او اجازه می دهد خیلی سریعتر از اطرافیانش رشد کند.

بیایید ایده من در مورد یک توسعه دهنده ایده آل را با یک توسعه دهنده عمومی مقایسه کنیم:

این تصویر نشان می دهد که چه تعداد از نقاطی که در بالا توضیح داده شد مربوط به کد هستند و چه تعداد از آنها نه. توسعه در یک شرکت محصول تنها یک سوم برنامه نویسی است، 2/3 باقی مانده ربطی به کد ندارد. و اگرچه ما کدهای زیادی می نویسیم، اثربخشی ما تا حد زیادی به این دو سوم "بی ربط" بستگی دارد.

تخصص، کلی گرایی و قانون 80-20

وقتی فردی حل برخی از مشکلات تنگ را یاد می گیرد، طولانی و سخت مطالعه می کند، اما بعد به راحتی و به سادگی آنها را حل می کند، اما در زمینه های مرتبط تخصص ندارد، این تخصص است. کلی گرایی زمانی است که نیمی از زمان آموزش در حوزه صلاحیت خود و نیمی دیگر در حوزه های مرتبط سرمایه گذاری شود. بر این اساس در حالت اول یک کار را عالی و بقیه را ضعیف انجام می دهم و در حالت دوم همه چیز را کم و بیش خوب انجام می دهم.

قانون 80-20 به ما می گوید که 80 درصد نتیجه حاصل از 20 درصد تلاش است. 80 درصد درآمد از 20 درصد مشتریان، 80 درصد سود از 20 درصد کارمندان و غیره حاصل می شود. در آموزش، این بدان معناست که 80 درصد دانش را در 20 درصد اول زمان صرف می کنیم.

یک ایده وجود دارد: کدنویس ها فقط باید کدنویسی کنند، طراحان فقط باید طراحی کنند، تحلیلگران باید تجزیه و تحلیل کنند و مدیران فقط باید مدیریت کنند. به نظر من این ایده سمی است و خیلی خوب کار نمی کند. این درباره این نیست که همه باید یک سرباز جهانی باشند، بلکه صرفه جویی در منابع است. اگر یک توسعه دهنده حداقل کمی در مورد مدیریت، طراحی و تجزیه و تحلیل درک کند، می تواند بسیاری از مشکلات را بدون دخالت افراد دیگر حل کند. اگر نیاز به ایجاد نوعی ویژگی دارید و سپس بررسی کنید که کاربران چگونه با آن در یک زمینه خاص کار می کنند، که به دو پرس و جوی SQL نیاز دارد، خوب است که بتوانید با این کار حواس تحلیلگر را پرت نکنید. اگر نیاز به تعبیه یک دکمه با قیاس با دکمه‌های موجود دارید، و اصول کلی را درک می‌کنید، می‌توانید بدون دخالت طراح این کار را انجام دهید و شرکت از شما بابت آن تشکر خواهد کرد.

مجموع: شما می توانید 100٪ از زمان خود را صرف مطالعه یک مهارت تا حد مجاز کنید، یا می توانید همان زمان را در پنج زمینه صرف کنید و در هر یک تا 80٪ سطح کنید. با پیروی از این ریاضی ساده لوحانه، می‌توانیم در همان زمان چهار برابر بیشتر مهارت کسب کنیم. این یک اغراق است، اما این ایده را نشان می دهد.

مهارت های مرتبط را می توان نه با 80٪، بلکه 30-50٪ آموزش داد. پس از گذراندن 10-20 ساعت، به طور قابل توجهی در زمینه های مرتبط پیشرفت خواهید کرد، درک زیادی از فرآیندهای رخ داده در آنها به دست خواهید آورد و بسیار خودمختارتر خواهید شد.

در اکوسیستم فناوری اطلاعات امروزی، بهتر است تا حد امکان مهارت داشته باشیم و در هیچ یک از آنها متخصص نباشیم. زیرا اولاً همه این مهارت ها به سرعت محو می شوند، به خصوص در مورد برنامه نویسی، و ثانیاً به این دلیل که 99٪ مواقع ما نه تنها از مهارت های اولیه، بلکه مطمئناً از پیچیده ترین مهارت ها استفاده نمی کنیم و این حتی در برنامه نویسی حتی در برنامه نویسی نیز کافی است. شرکت های باحال

و در نهایت، آموزش یک سرمایه گذاری است و تنوع بخشی در سرمایه گذاری مهم است.

چه چیزی را آموزش دهیم

پس چه چیزی و چگونه آموزش دهیم؟ یک توسعه دهنده معمولی در یک شرکت قوی به طور مرتب از موارد زیر استفاده می کند:

• ارتباطات
• خود سازماندهی
• برنامه ریزی
• طراحی (معمولا کد)
• و گاهی اوقات مدیریت، رهبری، تجزیه و تحلیل داده ها، نوشتن، استخدام، مربیگری و بسیاری از مهارت های دیگر

و عملا هیچ یک از این مهارت ها با خود کد تلاقی نمی کنند. آنها نیاز به آموزش و ارتقاء جداگانه دارند و اگر این کار انجام نشود در سطح بسیار پایینی باقی می مانند که اجازه استفاده موثر از آنها را نمی دهد.

در چه زمینه هایی ارزش توسعه دارد؟

1. مهارت های نرم هر چیزی است که به فشار دادن دکمه ها در ویرایشگر مربوط نمی شود. اینگونه است که ما پیام می نویسیم، چگونه در جلسات رفتار می کنیم، چگونه با همکاران ارتباط برقرار می کنیم. همه اینها چیزهای بدیهی به نظر می رسند، اما اغلب دست کم گرفته می شوند.

2. سیستم خود سازماندهی برای من شخصا، این موضوع در طول یک سال گذشته به یک موضوع بسیار مهم تبدیل شده است. در میان همه کارمندان باحال IT که من می شناسم، این یکی از پیشرفته ترین مهارت هاست: آنها فوق العاده سازماندهی شده اند، همیشه آنچه را که می گویند انجام می دهند، دقیقاً می دانند فردا، یک هفته، یک ماه دیگر چه خواهند کرد. لازم است سیستمی در اطراف خود بسازید که در آن همه مسائل و همه سؤالات ثبت شود؛ این امر خود کار را بسیار آسان می کند و به تعامل با افراد دیگر کمک زیادی می کند. من احساس می کنم که در طول یک سال گذشته، توسعه در این جهت، من را بسیار بیشتر از بهبود مهارت های فنی خود بهبود بخشیده است؛ من شروع به انجام کارهای بسیار بیشتری در واحد زمان کردم.

3. فعال، با دید باز و برنامه ریزی. موضوعات بسیار کلی و حیاتی هستند و مختص آی تی نیستند و همه باید آن ها را توسعه دهند. کنشگری به این معناست که منتظر علامتی برای انجام عمل نباشیم. شما منبع وقایع هستید، نه واکنش به آنها. ذهن باز توانایی برخورد عینی با هر اطلاعات جدید، ارزیابی وضعیت جدا از جهان بینی و عادات قدیمی خود است. برنامه ریزی چشم انداز روشنی است از اینکه چگونه کار امروز مشکل را برای هفته، ماه، سال حل می کند. اگر آینده را فراتر از یک کار خاص می بینید، انجام کاری که به آن نیاز دارید بسیار آسان تر است و بعد از مدتی نترسید که متوجه شوید این کار هدر رفته است. این مهارت به ویژه برای یک حرفه مهم است: شما می توانید سال ها با موفقیت به نتایجی دست پیدا کنید، اما در مکان اشتباه، و در نهایت وقتی مشخص شد که در مسیر اشتباهی حرکت می کنید، تمام چمدان های انباشته شده را از دست می دهید.

4. تمام حوزه های مرتبط به سطح پایه. هر کس زمینه های خاص خود را دارد، اما درک این نکته مهم است که با صرف 10 تا 20 ساعت زمان برای ارتقاء برخی مهارت های "خارجی"، می توانید فرصت ها و نقاط تماس جدیدی را در کار روزانه خود کشف کنید و این ساعات ممکن است تا پایان کار کافی باشد

چه بخوانیم

کتاب‌های زیادی درباره خود سازمان‌دهی وجود دارد؛ این یک صنعت کامل است که در آن برخی از افراد عجیب و غریب مجموعه‌هایی از توصیه‌ها را می‌نویسند و آموزش‌هایی را جمع‌آوری می‌کنند. در عین حال معلوم نیست که خودشان چه دستاوردهایی در زندگی داشته اند. بنابراین، مهم است که بر روی نویسندگان فیلتر قرار دهید، ببینید چه کسانی هستند و چه چیزی پشت سر خود دارند. رشد و دیدگاه من بیش از همه تحت تأثیر چهار کتاب قرار گرفت که همه آنها به نوعی به بهبود مهارت هایی که در بالا توضیح داده شد مربوط می شوند.

1. دیل کارنگی «چگونه دوستان به دست آوریم و بر مردم تأثیر بگذاریم». یک کتاب مذهبی در مورد مهارت های نرم، اگر نمی دانید از کجا شروع کنید، انتخاب آن یک گزینه برد-برد است. بر اساس مثال ها ساخته شده است، خواندن آن آسان است، برای درک آنچه می خوانید به تلاش زیادی نیاز ندارد و مهارت های به دست آمده را می توان بلافاصله به کار برد. به طور کلی، کتاب موضوع ارتباط با مردم را پوشش می دهد.

2. استیون آر کاوی "7 عادت افراد بسیار موثر". ترکیبی از مهارت‌های مختلف، از فعال بودن تا مهارت‌های نرم، با تأکید بر دستیابی به هم افزایی زمانی که نیاز دارید یک تیم کوچک را به یک نیروی عظیم تبدیل کنید. خواندن آن نیز آسان است.

3. ری دالیو "اصول". بر اساس تاریخچه شرکتی که نویسنده آن را ساخته است و به مدت 40 سال آن را مدیریت کرده است، مضامین روشن فکری و فعال بودن را آشکار می کند. بسیاری از نمونه های به دست آمده از زندگی نشان می دهد که یک فرد چقدر می تواند متعصب و وابسته باشد و چگونه می توان از شر آن خلاص شد.

4. دیوید آلن، "انجام کارها". خواندن اجباری برای یادگیری خودسازماندهی. خواندن آن چندان آسان نیست، اما مجموعه ای جامع از ابزارها را برای سازماندهی زندگی و امور فراهم می کند، همه جوانب را با جزئیات بررسی می کند و به شما کمک می کند تصمیم بگیرید دقیقا به چه چیزی نیاز دارید. با کمک او، سیستم خودم را ساختم که به من امکان می دهد همیشه مهم ترین کارها را بدون فراموش کردن بقیه انجام دهم.

باید درک کنید که فقط خواندن کافی نیست. شما می توانید حداقل یک کتاب در هفته قورت دهید، اما اثر آن چند روز باقی می ماند و سپس همه چیز به جای خود باز می گردد. کتاب ها باید به عنوان یک منبع توصیه مورد استفاده قرار گیرند که بلافاصله در عمل مورد آزمایش قرار می گیرند. اگر این کار را انجام ندهید، آنگاه تنها چیزی که آنها به شما خواهند داد گسترش افق دید شماست.

منبع: www.habr.com