Вредные советы для разработчика: Кодекс продуктивной неэффективности

Дисклеймер

Всё, что ты прочитаешь в этой статье — это стёб и сатира, чтобы показать, как не стоит работать. Не принимай всерьёз! Эти советы — абсолютная противоположность тому, как реально стоит вести себя в команде. Настоящие профессионалы знают, что работа — это про сотрудничество, помощь коллегам и постоянное развитие. Учись на чужих ошибках, и не повторяй их.

Совет №1. Сам себе на уме

Сделал, чтобы работало? Отлично! Больше сюда не возвращаемся. Никогда. Коллеги будут в восторге от твоего подхода: «Работает? Значит, не трогай!». А чтобы все вокруг восхищались твоими навыками, используй побольше строчек кода и максимально сложные конструкции для самых незамысловатых задач. Пусть код будет произведением искусства, понятным только тебе. Не понимают? Значит, они слабенькие джуниоры. Ты же опытный разработчик, а не кто попало!

Совет №2. Технологическая дискриминация: если это не мой стек, то это плохой стек!

Если ты бэкенд-разработчик, не стесняйся смело заявлять: «Фронтендеры? Какие они вообще программисты? Всё, что они делают, — это кнопки красят!» Серьезно, разве для этого нужно много ума?

А если ты фронтенд-разработчик, презирай бэкендеров так, будто они не разработчики, а грузчики данных: «Перекладывают JSON’ы с места на место и думают, что стали Software Engineers!»

Пусть каждый из вас будет уверен, что его работа важнее, а другой просто «прикалывается».

«Что? Пишешь на Vue.js… Пфф. Лучше бы на старом добром React. Vue только для мелких проектов, да и там одни джуны.»

«React? Нет спасибо, пускай они там сами хуками и редьюсерами обмазываются. Мы на Ангуляре ценим архитектуру и модульный подход. Кстати! Где мой латте на лавандовом молоке.»

«А мне больше Vue.js нравится. А чуть не забыл… Когда допьете, бутылочку не выбрасывайте…»

Совет №3. Многозадачный «Жукоробот»

Тебя должно быть очень много. Бери все задачи из бэклога, чтобы остальные видели, как ты тянешь на себе проект. Пылесосить доску в Джире — это твоя прямая обязанность. Подписывайся писать сервис в одиночку, чтобы только ты знал, как там всё устроено. Замкни на себе максимум разработки: если только ты знаешь, как устроен код, то тебя не уволят, и ты станешь живым божеством для менеджеров!

Совет №4. Переписать всё с нуля: второй шанс для кода, который этого не просил

Лень разбираться в сервисе? Ты не ленивый, просто у остальных руки кривые. Давай перепишем! Этот сервис без тебя никто нормально не сделает. Убей рабочий сервис и дай ему новую жизнь. Никакого поэтапного рефакторинга и изоляции старого кода — это для слабаков!

Совет №5. Переписать чужие методы и сделать это своей маленькой тайной

Выполняя очередную задачу, загляни в компонент другого разработчика и перепиши пару методов на свой лад. Не стоит разбираться, зачем и почему так сделано. Уведомлять автора не обязательно — ты компетентней, тебе виднее!

Совет №6. Полная власть

Настал момент вершить судьбы. Тебе предстоит поревьювить код коллеги. Его «пришлепки» теперь в твоих руках. Ты — как древнеримский император: палец вверх или вниз, и задача либо пойдет в тест, либо вернется на доработку. Цепляйся за всё: пробелы, отступы, название методов (если знаешь альтернативный вариант — сразу кидай комментарий). Включи фантазию, задача не должна пройти дальше. Релиз подождет! Если не понял концепцию — напиши: «Сделай проще». Не объясняй, как улучшить — просто брось ссылку на документацию и пусть сам ищет. Твое время — деньги. Пассивная агрессия приветствуется.

Совет №7. Дейлик — твоя сцена: говори умные вещи и все будут молчать

Как только наступила твоя очередь говорить на дейлике, сразу вспоминай все умные слова, которые слышал на Хабре или YouTube. Твоя задача — отбить все желание задавать вопросы. Ты ходячая энциклопедия, профессионал своего дела. Никто не сможет тебя осудить (как и понять), ведь твой профессиональный жаргон не досягаем для окружающих. Логика простая: не понял — не трушный.

Совет №8. Мелкая задачка: Бросаем вызов и обесцениваем

Как только кто-то берёт задачу, не упусти шанс заявить: «Это мелкая задачка на 15 минут!» Это идеальная стратегия, чтобы все увидели, что ты — тот самый опытный и быстрый разработчик. Даже если задача на самом деле требует больше времени, ты сразу обозначаешь её как «пустяковую», и теперь все, кто потратит на неё больше времени, автоматически окажутся в твоих глазах — слабее. Ведь если ты сам решишь её за 15 минут (потомки этого мифа будут склоняться перед твоей стойкостью), ты сможешь стать более синьорным в глазах команды. Всё, что требует времени и усилий у других, для тебя — дело нескольких кликов и кодинга одной левой рукой. Главное — не забывать подкрепить заявление фразой «ну это ж ерунда, не понимаю, как другие не могут».

Совет №9. Философия — Крут только если страдаешь

Запомни, настоящий профессионал — это тот, кто постоянно страдает. Без боли нет роста, и чем больше времени ты проводишь в мучениях, тем более крутым разработчиком ты становишься. Если ты не просыпаешься ночью с мыслью о баге, не проводишь дни, ломая голову над решением архитектурной задачи, значит, ты ещё не достиг уровня настоящего программиста. Будь готов демонстрировать всем, как ты сражаешься с проблемами, решаешь самые сложные вопросы и жертвуешь личным временем ради работы. Обязательно напомни всем, что раньше ты писал на плюсах и ассемблере в те самые студенческие годы, а сейчас всё такое простое, всё такое кежуал. Пишешь на JavaScript? Это не язык, то ли дело C#. Что? Питон? Я в твои годы на Java кодил. Мы тогда… [Место для истории про то, как экономили на битах и байтах, разрабатывали свою IDE и портировали её на тамагочи, и, конечно же, поднимали свой дата-центр в кладовке у кореша Сани с 4-го подъезда].

Совет №10. Книга как лычка

Не воспринимай как программистов людей, которые не читали такие книги, как: «Искусство программирования», «Чистый код», «Совершенный код» и т.п. Ведь если человек не читал минимум дважды подобные книжки, он просто не сможет пинать JSON’ы от клиента к серверу и обратно. Нам нечем разговаривать с такими людьми…