В наши дни, когда каждая область, о которой мы знаем, связана с программным обеспечением, это создало массу рабочих мест в индустрии программного обеспечения. Этот растущий спрос, безусловно, удовлетворяется большим количеством ИТ-инженеров, которые только что из колледжей поступают в компании.
Поскольку мы наблюдаем рост числа инженеров, мы сталкиваемся с некоторыми разработчиками, с которыми трудно работать, потому что они слишком лично воспринимают свой код. Они очень недружелюбно относятся к любым предлагаемым им улучшениям кода. Это создает очень негативную среду, особенно если эти разработчики опытные, потому что они играют важную роль в команде.
ИМХО, одна вещь, которая была глубоко подорвана как основы хорошего разработчика, - это обучение этике разработчика. Кажется, все говорят о новых технологиях, но очень немногие говорят об этических ценностях инженеров-программистов.
Когда я вижу, как новичков обучают определенным технологиям, им часто говорят:
- Код - это отражение мыслительного процесса человека.
- Нам говорят, что плохой код - это зло, и как он создает накладные расходы и плохую базу кода для обслуживания.
- Нас учат временной сложности алгоритма
- Нас учат нескольким шаблонам проектирования, которые следует применять в зависимости от варианта использования.
Когда мы просто проводим занятия, посвященные вышеуказанным навыкам, мы, безусловно, питаем представления о том, что код, который они пишут, очень личный и отражает их интеллект. Он косвенно отправляет сообщение, например:
- Ваш код определял ваш мыслительный процесс, поэтому, когда кто-то находит какой-либо изъян в вашем коде, они доказывают, что ваш мыслительный процесс ошибочен.
- Если структура вашего кода неправильно спроектирована, и кто-то указывает на некоторые проблемы. Они косвенно ставят под сомнение ваши знания и опыт.
- Если кто-то напишет код лучше вашего, он лучше вас.
Обучая всему этому, мы когда-нибудь учим их тому, что делать ошибки - это нормально. Мы все люди, и мы обязаны совершать ошибки, но мы всегда должны извлекать уроки из этого и следить за тем, чтобы это не повторилось.
- Вполне нормально писать неэффективный код по сравнению с младшим инженером-программистом, даже если у вас 6–7 лет опыта. Вы можете учиться у них.
- Это нормально не знать всего и не принимать это. Не стесняйтесь обращаться к соответствующему эксперту по технологиям для обсуждения. Не отвергайте и не откладывайте предложение новой технологии, о котором вы не знаете, и вам стыдно признаться, что вы в этом не эксперт.
- Это нормально - прислушиваться к отзывам о вашем коде и не принимать их на свой счет. Это возможность улучшить свой код и стать лучшим разработчиком.
- Это нормально, если в вашей функции есть ошибки. Не игнорируйте их, добавляя некоторую неоднозначную логику для устранения ошибки.
- Вы всегда должны поощрять членов вашей команды исправлять свои ошибки и решать их как команда, а не как отдельная личность.
- В этом мире всегда есть кто-то умнее вас. Итак, когда вы кого-то найдете, работайте с ним и развивайтесь.
- Атмосфера страха и обвинений может быть худшим, что может случиться с любой командой. Это резко снижает продуктивность и инновационность команды.
- Когда вы старший разработчик, ваш моральный долг - помогать и воспитывать младших разработчиков.
Это может показаться мелочью или несущественными моментами, но, если их не отметить, они могут нанести вред самой компании. Команда, построенная на этих убеждениях, может создать очень позитивную среду, в которой все постоянно улучшают друг друга.
Такие книги, как Книга с объяснениями экстремального программирования Кента Бека и Справочник по DevOps Джина Кима, Джеза Хамбла и Патрика Дебуа, на самом деле являются одними из великих книг, в которых делается упор на эти аспекты индустрии программного обеспечения, которые часто упускаются из виду.
Надеюсь, вам понравилась эта статья, и вы распространите эти слова среди своих сообществ разработчиков.
Не стесняйтесь хлопать несколько раз, если согласны!
