Для початку обговоримо причини, через які ви можете не розвиватися у професійній галузі, і що з цим взагалі робити.
Перескакування з теми на тему
Це головний злочин амбітних розробників. Наприклад, коли ви скачете з теми на тему проходячи курси, особливо коли ви новачок. Я стикаюся з таким дуже часто, навіть на наших власних стартових курсах. Відео людина дивиться, поки їсть, а завдання гортає, оскільки вони здаються їй легкими. Потім така людина стикається з складнішою проблемою, але оскільки немає досвіду вирішення простих завдань, людині така проблема здається такою, яку вирішити неможливо, і вона кидає навчання. Таке ставлення не просто не дозволить вирости, воно в принципі не дасть вам стати програмістом.
Те саме стосується й досвідченіших програмістів, які хочуть освоїти новий фреймворк, бібліотеку чи ще щось. Подивилися щось по верхівках і побігли далі вивчати щось нове. Але ні, так не працює. Для того, щоб вирости як розробник, потрібно посидіти якийсь час (залежить від того, наскільки складна тема, наскільки вона для вас нова і який у вас вже є досвід) і розібратися з нею, пошукати приклади використання, почитати документацію та ін.
Важливо шукати золоту середину, вбиватись об вивчення кожної деталі теж не потрібно. Насправді вміння знайти баланс – це дуже важлива навичка програміста. Знати, де потрібно довше поколупатися, а де можна швидко переглянути і йти далі. На жаль, немає правила, завдяки якому ви точно знатимете, що можна пропусти, а з чим потрібно розбиратися уважно. Вам доведеться орієнтуватися виключно на власну інтуїцію, а інтуїція – це результат набитих шишок.
Слабкі основи
Особливо часто ця проблема зустрічається у розробників, які навчались самостійно. Досить часто людина, яка навчалася не на курсах та за книгами, яка пропустила всю теорію і відразу полізла писати програми, може не знати базових основ програмування. В результаті ми отримуємо програміста, який начебто щось вміє, але при цьому відчувається, що йому чогось не вистачає. До базових знань відносяться знання з ООП, паттерни, архітектури. Це також все можна вивчити самостійно. Такі знання є фундаментом, який зміцнить ваші практичні навички.
Відсутність мети та напрямку в кар’єрі
Цей пункт можна використати абсолютно до всіх сфер та спеціальностей. Вибачте за це банальне питання, але все ж таки: ким ви себе бачите через 5 років? Не дарма це питання досі ставлять рекрутери на співбесідах. А ви, найімовірніше, дратуєтесь саме тому, що не можете на нього відповісти навіть собі. Вам дійсно важливо знати (насамперед для себе), ким ви хочете бути через 5 років. І якщо ви як розробник не розумієте, чим ви хочете займатися через 5 років, ви намагатиметеся охопити відразу все.
Вам потрібно розуміти, чи йдете ви у бік менеджменту, архітектурних знань, вивчення предметної галузі чи чогось іншого. Бігти одночасно на всі боки неможливо, тому ви і залишаєтеся на одному місці.
Дуже багато розробників, які приходять до мене на кар’єрні консультації, опиняються у ситуації, коли вони не знають, ким вони хочуть бути, розпорошуються і тому стоять на місці. Найсмішніше, що в цю ситуацію потрапляють найтямущіші, мега проактивні люди. Тому що вони хочуть усе. А так неможливо. Потрібно вибрати, куди ви йдете, вибрати пріоритет.
Погані звички
Ще один важливий аспект, який не стосується ІТ-сфери, але дуже гальмує вас. Під поганими звичками я маю на увазі неправильний спосіб життя: пізно лягати спати, не приділяти час спорту, не виділяти час на відпочинок і життя поза роботою, відкладати завдання на останній момент тощо. Досить скоро ви виявите проблеми зі здоров’ям, а з цим приходить і інертність в роботі.
У професійній діяльності також є погані звички: забивати на документування, забивати на роботу зі списком завдань, писати односкладні коментарі до комітів у гіт і т.д. Повірте, все це дуже псує вам життя. Наприклад, досвідчений розробник розуміє, де була помилка і що для її усунення потрібно повернутися до комміту, який було зроблено тиждень-два тому. Потім розробник відкриває свій список коммітів, а там абстрактні коментарі чи їх взагалі нема. У результаті на пошук потрібного комміта піде півдня, а то й день, а якби була звичка писати осмислені коментарі, на це пішло б кілька хвилин. Особливо весело, коли розбираєшся не зі своїми комітами, а з чужими. Неправильні звички можуть сильно зіпсувати ваше життя.
Невпевненість у собі та низька самооцінка
Дуже часто я чую, мовляв “Я зірок з неба не хопаю, працюю розробником, начебто щось виходить, а може мене просто з жалю тримають, не ставте мені складних завдань – я не впораюся …” і все в такому дусі. Така самооцінка ніколи не призведе до успіху. Якщо до кожного завдання, де потрібно щось освоїти, вивчити, полагодити підходити з думками, що у вас все одно нічого не вийде, то у вас дійсно не вийде. Я можу вам сказати: вірте у себе і у вас все вийде. Насправді це не працює. Але якщо ви не вірите у себе, то у вас гарантовано нічого не вийде.
У цьому світі немає гарантованих способів щось зробити, але у світі повно гарантованих способів щось НЕ зробити.
Віримо у себе. Реально оцінюємо свої переваги та недоліки. Абсолютно у кожної людини, яким би фахівцем, вона не була, є свої сильні та слабкі сторони. Більше того, хорошого фахівця від поганого відрізняє не те, які має знання, а те, наскільки добре він вміє ними користуватися. Хороший фахівець знає про свої сильні сторони і робить ставку на них, він також знає про свої слабкі сторони та обходить їх. Поганий фахівець намагається перемогти слабкі сторони та не приділяє уваги сильним якостям.
Наприклад, ви добре спілкуєтеся з людьми, але вважаєте, що у програмуванні це нікому не потрібно, зате потрібно писати-писати-писати код. При цьому ви можете використовувати свої сильні сторони: розширити нетворкінг, завести натовп друзів-програмістів, які час від часу будуть підкидати вам круті ідеї. Цілком можливо, що це приведе вас до кращого рішення, ніж якби ви медитували над кодом годинами в очікуванні осяяння і пиляючи себе за те, що у вас не все виходить. Чи навпаки. Вам важко спілкуватися з людьми, зате крутячи і розглядаючи проблему під різними кутами ви знаходите найоптимальніші рішення. Або ви можете добре шукати інформацію. Або ви дуже посидючі і можете годинами зосереджено працювати. Так що шукайте свої сильні сторони і намагайтеся оминати слабкі.
Чомусь низька самооцінка та синдром самозванця найчастіше вражає саме жінок. Вони погоджуються на нижчу зарплату або не просять про підвищення вважаючи, що більше не заслуговують. Але зрозумійте, що середня по ринку – це середня по ринку для обох статей.
Мислення «кодера»
Більшість програмістів ніколи не відмовляються від мислення кодера, вони постійно живуть у коробці, де все про код. Така людина думає про код, навіть коли з ним говориш про бізнес чи життя. Або коли стоїть питання, чи варто йти в архітектуру чи в керівництві, він починає сипати назвою фреймворків. Але це завдання зовсім іншого рівня.
Потрібно вчитися виходити за межі кодера. Ви ніколи не станете архітектором, якщо думатимете на рівні кодера. Архітектура взагалі не про код, а про те, як усе взаємодіятиме. Ось коли ви вже розумієте, як це все разом взаємодіє, коли ви розумієте, для чого ваша система, як вона використовуватиметься, які у неї обмеження, тільки тоді ви доходите до вибору мови програмування. Коли ви є архітектором, любов чи не любов до якоїсь мови чи інструменту не має жодного значення. Якщо нелюбима вами мова програмування/фреймворк для цієї ситуації підходить краще, потрібно вибрати саме її.
Чим раніше ви вийдете за рамки мислення кодера, тим швидше ви виростете до сеньйора і вище. Тому що той же синьйор розробник більше думає про завдання бізнесу. Найкращий код, це ненаписаний код. Якщо якесь завдання можна вирішити не використовуючи код, це буде найкращим програмістським рішенням. Тому хоч би яке завдання вам не ставили, перше, про що ви повинні подумати — чи можна його вирішити взагалі без програмування. Наприклад, використовувати вже написаний код, придумати, як щось із чимось з’єднати методом налаштування, і так далі. Люди-кодери відразу ж починають думати, як написати код для вирішення поставленого завдання і часто упускають найоптимальніші рішення. Вони витрачають багато часу, щоб написати те, що не потрібно було писати, а просто налаштувати.
До коду ми приходимо лише тоді, коли ви точно розумієте, що й навіщо потрібно зробити. І навіть коли ви починаєте працювати з кодом, потрібно подивитися, чи можливо достатньо зробити якісь невеликі зміни в існуючому коді, а не писати все заново.
Професійний імідж
Це не настільки критичний аспект, як усі вищезгадані, однак і він робить свій внесок. Люди — соціальні істоти і вони звикли оцінювати інших людей за одягом, за зовнішнім виглядом. Так, є топові професіонали, які ніяк не стежать за собою і своїм зовнішнім виглядом випромінюють асоціальність. Вони не виглядають як експерти та мало хто захоче їх бачити начальником відділу. Я не говорю про те, що ви повинні ходити на роботу в костюмі трійці. Але подивіться на Цукерберга та Джобса – вони не носять костюми, але виглядають адекватно.
Крім того, одяг дуже сильно впливає на настрій самої людини. Коли ви одягаєте гарний одяг, то самі до себе починаєте ставитись по-іншому. Можете сказати, що це тема жіноча. Нічого подібного мужики також критично оцінюють свій зовнішній вигляд. Вкладення грошей, щоб купити той одяг, який вам подобається, в якому ви добре виглядаєте – це дуже корисне вкладення грошей. Це дає вам правильний настрій, правильне самовідчуття та додаткову впевненість у собі.
Те саме стосується і манери спілкування з іншими людьми. Якщо люди сахаються від вас, подумайте, з ким можна обговорити це питання. Можливо, поговорити з психологом, можливо, сходити до коуча чи тренера особистісного зростання. Я, наприклад, навчався манері спілкування, дивлячись на тих людей, поведінка яких мені імпонувала.
Надмірна консервативність
Останнє, але не менш важливе. Незважаючи на те, що розробники завжди навчаються та вдосконалюються, програмісти дуже сильно опираються змінам. І цей опір призводить до самовдоволення. Розумієте, що я? Якщо програміст звик щось вирішувати за допомогою якогось інструменту чи якогось конкретного способу, він чинитиме опір новим рішенням. Навіть якщо колеги йому кажуть, що це не найвдаліший інструмент/спосіб. Наприклад, звик програміст не заповнювати гіт камміти адекватними описами, він знайде десяток аргументів і плюватиметься піною з рота, щоб довести іншим, що це все марення і він цього робити не буде.
Чи не будьте такими. Вживайте зміни. Не будь-яка зміна якоюсь мірою можна бути консерватором — якщо щось добре працює, то хай далі працює.
Але якщо те, що вам запропонували, працюватиме краще, то має сенс це спробувати. Не треба розповідати, що ви завжди так робили і продовжуватимете робити саме так. Навіть якщо у вас 15-20 років стажу, вас все одно можуть багато чого навчити молодші колеги.
Завжди ваш Сергій Немчинський
