Я знаю их, потому что использовал их

Признаюсь: я был и остаюсь разработчиком.

Быть разработчиком - это больше, чем работа, это состояние души. Вы не можете просто бросить это.

Это немного похоже на то, как люди продолжают думать о сигаретах, даже когда бросили курить много лет назад. Развитие для тех, кто увлеченно занимается этой профессией, может быть зависимостью.

За свою карьеру разработчика я боролся с множеством ошибок и сложных ситуаций. Я взял на себя роль руководителя группы, а позже - технического директора. Эти акции изменили мою точку зрения, и вскоре я начал видеть себя, когда наблюдал за людьми, которые работают в моих командах.

Интересно, как я доказал, что могу предотвращать ошибки и направлять людей к правильному решению, избегая ловушек. Это было не из-за какой-то сверхдержавы - просто я сделал больше ошибок, чем они. В этой статье я столкнусь с небольшой ложью, которую каждый разработчик невольно говорит другим (но в первую очередь себе). Чтобы вы лучше понимали, о чем я говорю, просто продолжайте читать и просмотрите наиболее распространенную ситуацию.

Отказ от ответственности: я не пытаюсь никого осуждать здесь. Развитие - одна из самых сложных профессий в мире, особенно когда вы младший или работаете в менее структурированной команде. Маленькая ложь, которую рассказывают разработчики, проистекает из сложности выполнения этой работы.

"Это сработало"

Есть много вариантов этого оправдания, но они приводят к одной и той же ситуации: что-то протестированное не работает, когда его использует кто-то другой. Это может быть из-за неточного тестирования. Это также может быть связано с поляризацией во время тестирования, когда человек, создающий функцию, использует ее только одним прямым способом, оставляя конечному пользователю импровизировать. Проблема не в том, почему что-то, что должно работать, сломано. Разработчик не может поверить в это - он протестировал, все заработало, почему сейчас остановилось? Итак, первое, невинное объяснение просто «сработало на моем локальном» или «сработало вчера». Что ж, никто не отрицает, что эта функция в какой-то момент работала, но факт в том, что есть ошибка, которую нужно решить.

Программное обеспечение - это решение вашей проблемы

Мы живем в мире, где все можно сделать с помощью программного обеспечения. Программное обеспечение - это наше лекарство. Нужен график? Используйте программное обеспечение. Открыто слишком много вкладок? Используйте программное обеспечение. Мы стараемся решить любой аспект нашей жизни с помощью приложения или программного обеспечения. Этот процесс является частью цифровой трансформации, но программное обеспечение - всего лишь инструмент. По словам Дейкстры, просить программное обеспечение для решения корпоративной проблемы - все равно что просить подводную лодку плыть по воде. Молодые разработчики видят силу программного обеспечения, такого как CRM или любое решение SaaS, и думают, что они решат все ваши проблемы. Это может быть сложнее, чем они думают.

Дело не в инструментах. Самое коммерческое решение предлагает намного больше, чем вам обычно нужно. Речь идет о компании. Прежде чем внедрять инструмент, вы должны адаптировать процессы и поддержать это изменение обучением и воспитанием.

Нет никаких решений для электронной коммерции, которые увеличили бы ваши продажи, если ваш продукт плохой или бренд слишком слаб. Не существует CRM, которая поможет процессу продаж, если ваш отдел продаж не знает, какой продукт продается. Программные решения - это толчок, поэтому, когда разработчик предлагает такое, подумайте, какие усилия нужно приложить, чтобы сделать этот перебор эффективным.

«Мы можем все, это всего лишь вопрос времени»

Этот ответ обычно приходит после сложного запроса. Время - решающий момент, когда нам нужно разработать сложные решения. Очевидно, что для создания Facebook нужно больше времени, чем, например, простого веб-сайта. Проблема в том, что время - не единственное, что имеет значение. Вероятно, правильным ответом должно быть: «Мы могли бы это сделать, если бы у нас было время, знания и опыт». Но часто слишком сложно признать, что что-то слишком велико для нас.

«Не волнуйся»

«Не волнуйся» или «поверь мне» всегда должны вызывать тревогу.

Мы всегда думаем о причинно-следственной логике. Вы думаете, что чего-то не будет, неужели вы думаете, что не было никаких последствий?

Дело в том, что ваша точка зрения ограничена вашим личным опытом и знаниями. В сложных ситуациях сложно найти более широкий. Решение требует более подробных объяснений.

Это помогает всем глубже погрузиться в детали и выявить реальные проблемы. Вопрос не в доверии, и мы должны доверять каждому коллеге, от самого младшего до того, кто близок к пенсионному. Проблема заключается в быстрых ответах или минимизированных проблемах.

"Это чище"

Этим материалом часто пользуются, когда хотят убедить выбрать вариант длины или комплекс. Без лучшей аргументации мотивация состоит в том, что она чище.

Программное обеспечение не бывает чистым или грязным. Существуют стабильные, надежные решения, реализованные с использованием правильного кода, или нестабильное сложное программное обеспечение, которое подвергает вас риску нестабильности.

Чтобы убедить кого-то идти по одному пути, а не по другому, потому что это лучше, даже если это дольше для реализации, вам нужно дать ему мотивацию сделать это.

«Ответственность несет другая команда / лицо / вещь»

Сколько раз я слышал что-то вроде: «Это сделал кто-то другой», или «Это проблема с оборудованием», или «Это внутреннее дело».

Это совершенно неправильный подход к разработке программного обеспечения. Когда мы работаем над проектами, состоящими из нескольких команд, наша общая миссия - это рабочее программное обеспечение. Рабочий софт всегда будет платным. Своевременное завершение проекта и получение надежных результатов - это общий интерес. Вот почему просто перенос ответственности в другой раздел - не решение. В краткосрочной перспективе это может показаться решением, но оно вернется бумерангом.

Старший разработчик не просто пристрастие к другим по вине, но помогает им быстро понять, в чем проблема.

Эта ситуация широко распространена, поскольку большая часть проекта реализуется с использованием двух отдельных команд (фронтенд и бэкэнд). В этом сценарии я столько раз слышал «это их вина», что это был мой ночной кошмар. Когда вы говорите: «Я не виноват», я вам доверяю. Но нам нужен шаг вперед. Вам необходимо передать полученную информацию другой команде, чтобы она была доступна для совместного тестирования. Это не вопрос ответственности, это вопрос приверженности. Совершенно то же самое, когда вы не уверены, в чем проблема, и просто указываете на оборудование. Но как Sysadming может помочь вам без правильной информации? И как вы уверены, что проблемы связаны с разрешением экрана клиента, а не с ошибкой? Более того, как насчет управления этим сложным разрешением экрана? Возможно, приложив немного усилий, мы сможем решить проблему для небольшого набора устройств.

Главное правило: никогда не доверяйте разработчику, доверяйте рабочему коду

Как разработчик, я могу посоветовать вам никогда не доверять разработчику!

Дело не в честности. Это просто сложность работы, которую они делают. Все может случиться между теорией и практикой, особенно когда это младший разработчик.

В больших проектах никто не может полностью охватить все, что нужно знать. Часто разработчик может делать что-то на основе того, что написано в задаче, потому что он ничего не знает о бизнес-логике. Это означает, что недоразумение каждый раз приводит к ошибкам. Лучший способ доверять разработчику и эффективно работать с ним - это понимать его работу, играть вместе, объяснять вещи, объясняя, почему ему нужно что-то делать. Подход, ориентированный на задачу (сделайте это сейчас), может работать в очень структурированном проекте с безошибочным описанием задач. Но в реальном мире лучше работать вместе.

Доверяйте коду!

Спасибо за прочтение.