Сьогодні обговорюємо речі, які повинен знати і вміти кожен розробник.
- Базові технічні знання
Ви очікували, що я почну з чогось іншого? Ні. Кожному програмісту треба мати базові технічні знання у своїй професії, а бажано – ще й в суміжних. Тому що це необхідно, без цього ви взагалі не розробник.
- Здатність і бажання швидко вчитися
Зараз без цього нікуди, не тільки в розробці. Все дуже швидко змінюється. Навіть якщо ви працюєте в якійсь консервативній галузі типу Java або SAP, там теж відбувається багато цікавого. На кожному новому проекті ви виявите масу речей, яких ви не знали і які треба доучувати. Це частина нашої професії. Ми доучуємось.
- Уміння налагоджувати код
Це теж базовий технічний навик. Уміння знайти баг, місце, де в коді накосячили, де програма дає збої і чому.
Програмісти отримують таку зарплату через те, що вони не говорять: «Я не знаю, як це виправити. Це не вирішується». Хороший програміст каже: «Так, я буду працювати і придумаю, як це вирішити».
Іноді замовник відмовляється від налагодження коду, це занадто довго і дорого. Але це вже не ваша відповідальність. А в більшості випадків замовнику вигідно, щоб хоч рік виправляли баг в програмі, але виправили. Уміння впертися рогом, довбати в одну точку, щоб виправити код – необхідно. До необхідних відносяться і уміння користуватися інструментарієм, який підтримує трасування, і дебаггінг. Це можна і не згадувати, але новачкам це корисно пам’ятати.
- Уміння правильно будувати work-life balance
Для хорошої роботи треба навчитися розслаблятися. Багато хто говорить: «Треба бути готовим до переробок». Але до переробок готова будь-яка людина. Якщо ви пішли в програмування по любові, вас доведеться за вуха відтягувати від консолі і просити зробити паузу.
На кар’єрних консультаціях я часто зустрічаюся з людьми, у яких робота – це робота, і хобі – це робота, і відпочинок – це теж робота, в результаті чого вони жорстко вигоріли. Так бути не повинно. Потрібно джерело отримання радості, щоб отримувати радість не тільки від роботи.
Якщо у вас не так, ви на першому етапі вигоряння. Не підходите до нього, а вже на першому етапі. Ви неодмінно вигорите, якщо ваше єдине джерело радості – це робота. Треба мати хобі і захоплення, чим ви займаєтеся постійно і що приносить вам радість, щоб ви могли перемикатися з роботи. В ідеалі це має бути діяльність, не пов’язана з комп’ютером. Якщо для вас відпочинок – це переключитися в сусіднє вікно, це не діло.
Пошукайте інше заняття. Спробуйте будь-який спорт, моделювання, походи… Для програміста дуже корисно мати хобі, пов’язане з фізичним навантаженням, тому що робота фізичного навантаження не дає. А людському тілу воно необхідно. Хоча б фітнес-тренування, якийсь спорт. До речі, підійде гра на музичних інструментах.
- Бачити загальну картину
Що відбувається в проекті, з яким ви працюєте. Я називаю це вміння business value, хоча правильніше було б його назвати big picture – розуміння того, що відбувається. Це важливо, щоб не почати займатися фігньою. Щоб, коли ви щось пишете, ви розуміли, для чого ви це пишете, яку роль цей код виконує в спільному проекті.
Часто виявляється: те, чим переймається програміст, для проекту не треба. Важливіше проста і примітивна річ, якою ніхто не займається, але яка критично необхідна для проекту. При цьому всі зайняті якоюсь складною заморочкою, яка для успіху проекту не грає ролі.
Для програміста вміння бачити всю картину дуже важливо. У багатьох ПМ-ів немає технічної освіти, і вони не можуть зрозуміти, наскільки потрібно те, що ви робите. А тімлід може просто за вами не встежити, особливо якщо ви сам тімлід. Ви можете направити своїх розробників вирішувати завдання, яке цікаве, замість того, яке потрібне для проекту. Не треба так.
- Взяти максимум від мінімуму
Досить часто в розробці трапляється ситуація, коли ви працювали-працювали, і раптом зрозуміли, що пішли не туди. Потрібно набратися сміливості і видалити результат декількох днів вашої роботи, щоб піти правильним шляхом. Це часто дуже боляче, ви думаєте про те, скільки ж часу було витрачено, але так працювати не буде.
Професіоналізм полягає в тому, щоб сказати – окей, видаляємо, це не працює. Відкотилися до попередньої версії і забули. Це боляче, це погано, але вкладати купу часу і сил в непрацююче рішення ще гірше.
Залишати закоментованним неробочий код, який захаращує проект – теж не варіант. Простіше визнати, що не вийшло, зафіксувати збитки і піти іншою дорогою. Але до цього потрібно себе готувати.
Багатьом програмістам важко визнати, що вони пішли не туди. Хоча з іншого боку, стільки ж програмістів кидають роботу при першій же складності, і метушаться між ста п’ятдесятьма варіантами рішення. Це інша сторона тієї ж проблеми, але не менш ідіотська. Накидано кілька рішень, але вони не просунуті, і незрозуміло, яке з них працює. Треба пройти по кожному з них, перевірити і переконатися – ні, це не працює. Кінь здох, значить, злізь з нього. Але і кидати рішення при першій же складності теж не варіант. Не треба так.
- Здатність працювати в команді
Минув той час, коли можна було сидіти в гаражі, щось робити самому і бути гіперспеціалістом, потрібним всьому світу. Якщо вас звуть не Лінус Торвальдс, хрону вам лисого. У будь-якому випадку ви повинні працювати в команді. Навіть якщо ви мобільний розробник, у вас є команда з дизайнера, тестувальника, може бути, ПМ-а – коротше, є люди, з якими ви працюєте.
Від вашого вміння працювати з людьми, правильно побудувати комунікацію, донести свою думку, декомпозувати завдання залежить багато більше, ніж від уміння швидко друкувати. Від цього, до речі, взагалі нічого не залежить. Ви можете декомпозувати не ту задачу. Або пояснити завдання не так. ПМ вас не зрозуміє, невірно перекаже проблему замовнику, зворотна відповідь теж буде неправильною, і проект просто розвалиться через неправильну комунікацію. Розвивайте софт скіли – це теж важливо.
Завжди ваш Сергій Немчинській.
