Сооснователь Alef Development Стас Гольденшлюгер рассказал, почему программисты теряют работу и дал советы, как этого избежать.
Если вы новичок в программировании, вам эта статья может показаться шутливой. Матерый тимлид во время прочтения вряд ли даже улыбнется — тут все серьезно.
Способ №1. Сделать не так, как просил менеджер
Почему так неправильно. Часто менеджер знает о проекте больше, чем программисты. Кроме того, в машине должен быть один водитель: если левыми и правыми колесами управляют разные люди — машина не приедет в назначенную точку в нужное время.
Пример. Менеджер просит сделать комнату с дверью. Но по ТЗ в двери нет ручки, вместо нее педаль. Программист видел в жизни тысячи дверей и решает, что менеджер сошел с ума. Он пытается спорить, а потом делает «правильно». Его увольняют.
Программиста уволили, потому что:
- это дверь для склада, куда люди заходят с коробками в руках — ножная педаль была главной идеей;
- клиент — фирма, производящая ножные педали для дверей;
- дверную ручку продали клиенту за огромные деньги — она должна была войти во вторую версию проекта, не в первую.
Мораль. Читай ТЗ, делай по ТЗ. Если не понимаешь — обсуждай. Если не согласен — спорь. Нельзя молча делать не то, что требуется.
Способ 2. Не тестировать свой код
Почему так неправильно. Уважайте труд тестировщиков. Это показатель элементарной вежливости, как почистить зубы перед походом к стоматологу.
Пример. Программисту нужно в окошке регистрации заменить слово «Ок» на «Зарегистрироваться». Он находит это слово в коде, заменяет его и, не глядя, отправляет на проверку. По проекту пару часов бегают автоматические тесты. Его смотрят тестировщики. Оказывается, новое слово не влезло в кнопку и испортило верстку. Задачу отправляют на доработку. На проверку в сумме ушел целый день.
В программировании есть понятие, пришедшее из радиоэлектроники — «smoke test». Ты запускаешь свой прибор и смотришь, а не пошел ли из него дым. Это самая простецкая проверка. Понятно, что тестирование — дело тестировщиков. Но если программист регулярно допускает «баги невнимательности», то коллектив его уважать не будет.
Мораль. Когда твои 5 минут, могут сэкономить другому человеку целый день — не ленись. Программирование — профессия педантов, которые готовы проверить и перепроверить.
Способ 3. Заниматься посторонними делами в рабочее время
Почему так неправильно. Ты получаешь деньги в обмен на то, что продаешь свое время. Если ты присваиваешь время себе — это воровство.
Пример. Программист работает одновременно на двух удаленных работах и вроде неплохо справляется. Его начальники не подозревают друг о друге. Вдруг на обеих работах — аврал. Тестировщики шлют новые задачи каждые 15 минут и требуют мгновенной реакции. Он медленно отвечает, путается в коде — в итоге подставляет обе команды.
Мораль. Если ты договорился работать на полную ставку — работай на полную ставку. Если есть свободное время — попроси у начальства больше задач и больше денег.
Способ 4. Использовать любимую библиотеку/фреймворк, не посоветовавшись с менеджером
Почему так неправильно. Программист — профессия, подразумевающая умение подчиняться правилам команды. Если ты любишь react, а твой коллега любит программировать на «сочетании чистого JS и личной самоотверженности», то вы все равно должны делать проект на той платформе, которую выбрал менеджер.
Пример. Программист получает задачу: приделать функцию к сайту. И он понимает, что ее можно быстро решить на ReactJS — и не отказывает себе в этом маленьком удовольствии.
Через неделю происходит code review, и программиста увольняют, потому что:
а) он забыл заглянуть в соседнюю папку, а там 10 гигабайт кода на Angular;
б) в компании кроме него нет программистов на React — если он заболеет, то некому будет поддерживать;
в) Angular был требованием клиента.
Мораль. Архитектурные решения, выбор платформ, технологий, фреймворков, библиотек — задача технического менеджера. Если у тебя есть идея — предложи ее. Если решил устроить молчаливое самоуправство — начинай мониторить биржу труда. Не после первого раза, конечно, но если проделать такой фокус два раза, то почти наверняка.
- Научим программировать на JavaScript и PHP
- 11 готовых проектов в портфолио по итогам обучения
- станьте junior-разработчиком, даже если никогда не программировали
- 450+ часов практики и интенсивного общения с ведущими разработчиками
Способ 5. Просить повышение за несколько недель до сдачи большого проекта
Почему так неправильно. Это шантаж.
Пример. Программист в рамках большого проекта сделал библиотеку «для распознавания голоса» — она почти готова, но еще сыровата. Сдача через 3 недели. Другому программисту потребуется месяц, только чтобы разобраться в коде. Программист решает, что сейчас подходящий момент попросить повышение.
У менеджера в этой ситуации поджимается все, что может поджаться. Он повышает программисту зарплату. После сдачи проекта программиста увольняют или больше не дают большие и важные задачи. Он потерял доверие начальства.
Если бы программист попросил повышение уже после сдачи проекта, отношение к нему было бы другим. «Мы повышаем, потому что он молодец и сдал проект» — мотивация получше, чем «мы повышаем, потому что он выкрутил нам руки».
Мораль. «Предложения, от которых нельзя отказаться» больше подходят итальянским мафиози, чем программистам.
Хотите написать колонку для «Нетологии»? Читайте наши условия публикации. Чтобы быть в курсе всех новостей и читать новые статьи, присоединяйтесь к Телеграм-каналу Нетологии.