Що я хотів знати на початку своєї кар'єри розробника. Частина 1

Коли ви починаєте кар'єру де б то не було, ви, ймовірно, сподіваєтеся на багато що, але не знаєте, чого чекати. Варто чи не висовуватися і робити, що сказано або націлюватися тільки на амбітні проекти? Ось чого я навчився за час роботи як розробник ПЗ.



Дозвольте мені висловити кілька припущень, заснованих на моїх досвіді і спостереженнях. Цей список не повний, тому що не може ним бути. Ваш досвід буде унікальним.

Це переклад статті-відповіді на ресурсі Quora.com, ілюстрація з сайту LifeHacker.com.

1. Не бійтеся вчитися на роботі. На жаль, книжкові полиці більшості робочих місць стоять там для виду. Ви рідко бачите кого-небудь, читає книгу, тим більше під час основних робочих годин. Все ж, ви можете читати документації і більшість книг з комп'ютера або електронної книги. Так що займіться цим. Навряд чи ви багато чому навчитеся, якщо будете робити тільки призначене. Ви так само не просунетеся, якщо зажадаєте більше роботи і отримаєте рутину. Зупиняйтеся і робіть речі правильно і вчіть основи. Як люди стають експертами у сферах кшталт машинного навчання? Кожен день потроху.

2. Керуйте своєю кар'єрою агресивно. Беріть відповідальність за ваше навчання і прогрес. Один з десяти (в кращому випадку) знаходить наставника, який показує уторовані доріжки і смикає за ниточки, щоб їх учень отримав підвищення і хороший проект. Якщо ви серед дев'яти інших (а ви будете там більшу частину часу), змиріться з тим, що про вас не дбають. Так що подбайте про себе самі. Не просіть більше роботи, поки не будете впевнені, що ви довіряєте людині і він дасть вам кращу роботу, ніж та, яку ви отримаєте інакше. Коли це можливо, робіть якомога менше роботи, не просуває вас по кар'єрних сходах або вчить вас чого-небудь; якщо ця робота не має значення для вашої кар'єри, то швидше за все людей не турбує те, що ви робите роботу ледве-ледве, поки ви нікому не заважаєте. Після трьох років, якщо вам не дають завдань більше або важче, ніж на початку, «зовнішнє підвищення» (читайте: зміна роботи) зазвичай є хорошим виходом.

3. Навчитеся розпізнавати недопрацювання і переробку, а так само уникати їх. Є безліч ледачих розробників, що працюють роками. Це непогана стратегія, якщо ви влаштувалися, але я б не став так падати. До слова сказати, за недопрацювання зазвичай звільняють людей, які роблять так мало роботи, що створюють роботу для інших. Недоработчики, які не висовуються, зазвичай не наживають ворогів. У той же час остерігайтеся переробки. Це не вуз, в якому можна отримати п'ятірку за те, що ви аргументовано переспорили вашого професора. Переробники часто створюють роботу для їх колег і начальників і привертають непотрібну увагу (Читай: Макналті з «Прослушки»), а так само мають більше шансів бути звільненими за пунктом «продуктивність», ніж недоработчики. Я не маю на увазі, що ви не повинні старатися, робити хорошу роботу і вчитися наскільки можливо — просто це не переробка. З мого досвіду переробка — можливо, підвищена амбіційність — набагато небезпечніше недоробки, тому що приведе вас до звільнення набагато швидше. Якщо вам доведеться вибирати з двох зол, схиляйтеся до недоробку.

4. Ніколи не питайте дозволу, якщо тільки не питати небезпечно. Хочете витратити тиждень на дослідження за власною ініціативою? Не питайте дозволу. Ви його не отримаєте. Цілком імовірно, що ви не зробите послугу начальству, питаючи дозволу; з їх точки зору, ви кидаєте на них відповідальність, якщо у вас щось не вийде. До того ж, у будь-якому випадку він може відмовитися від вашої відповідальності потім, бо він вище за вас. Як бачите, немає хороших сторін у цих проханнях. Звичайно, якщо ви ризикуєте завдати серйозної шкоди бізнесу, або від вас просто потрібно запитати дозвіл, тоді ви повинні це зробити. Якщо втрати малі, а ризики відповідають вашому рівню в компанії (а на вакансію програміста, на якій вам не довіряють через тижні вашого власного часу, не варто влаштовуватися) — тоді не питайте дозволу. Просто зробіть це, і зробіть це добре.

5. Ніколи не вибачайтеся за самостійність чи використання власного часу. Ви можете визнати, що ваш проект або ваше розслідування не вийшло, як задумано. хоча краще представити це як спробу дослідження, але ви не повинні вибачатися за провалений сторонній проект. Це створює прецедент щодо вас, як підлеглого, над яким необхідно більше спостереження. Після опису чого-небудь, зробленого за вашою ініціативою, не кажіть начальнику: «Не турбуйтеся, я зробив це поза робочого часу». Якщо ваша компанія не дозволяє вам працювати над своїми проектами в години вашої роботи, то не варто заради них намагатися ні з якої причини. Шануйте свій час — інакше ніхто не буде.

6. Вивчіть CS666 (так я називаю політику розробки ПЗ). Вивчіть його і можете про нього забути. Не вчіть його, і він буде супроводжувати вас завжди. Коли ми дорослішаємо, ми починаємо бачити цінність в переносних і загальних здібностях: функціональне програмування замість Spring/Hibernate, алгоритми замість примх Java 1.4 legacy. Так, CS666 не з приємних, але він застосовується в індустрії набагато краще будь-якої мови програмування. Я не кажу, що ви повинні стати політичною твариною або стати одержимим нею, тому що це добре не закінчиться, але ви повинні бути політично свідомим, тому що політика є у всьому, чим ми займаємося. Добре почати вивчати людей та їх вчинки якомога раніше, навіть якщо ви не збираєтеся грати (а в молодості ви не повинні часто грати). Хоч вам дають кластер Hadoop вчасно для вирішення ваших завдань, або ви отримуєте ту саму можливість «заморожування фіч» (feature freeze, коли в проекті фиксят баги і не додають фічі — прим. перекладача), щоб ви змогли почистити свої борги, або за які проекти ви відповідальні — це все політика. Добре це чи погано, але це — ваш головний інструмент, і в справжньому житті вам краще використовувати його, а не потрапляти під його дію. Якщо ви вивчите CS666, ви отримаєте час віддихатися, забути про нього і просто робити хорошу роботу. Якщо ви його не вивчите, то ваша кар'єра буде формуватися тими, хто краще користується цим.

7. Не будьте ідеалістом і не намагайтеся довести, що ваше начальство не право. Коли молоді інженери відчувають, що їхні ідеї краще, ніж ті, які запропоновані начальником, але не знаходять підтримки, як правило вони різко підвищують ставку і ризики і витрачають безліч годин. «Давайте доведемо, що начальник не правий… шляхом жертвування власного часу на те, чим будуть володіти вони!» Вибач, але якщо тобі довелося викинути пару вихідних (не рахуючи рідкісних випадків на кшталт «останнього ривка»), щоб виконати проект, значить твоє начальство не сильно про нього піклується. Інакше у тебе був би час і ресурси, а так само не було терпіння для ідеалізму. Замість того, щоб робити хет-трик зламаною ключкою, просто дозволь цій грі статися. Начальник не любить, коли з нього роблять дурня люди, які в ньому сумнівалися. Ви не отримаєте підвищення або премії. Начальство знайде спосіб довести їх погане враження (і ваше щире співпереживання успіху «поганого» проекту накладе на вас слід) і, навіть якщо ви досягнете успіху, ви провалитесь. Завжди залишиться місце для: «Він зробив непогану роботу, але відволікся від призначеної роботи і я не можу йому довіряти/ми не можемо дозволити йому створити прецедент/це була моя ідея».

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.