«Лучшие программисты не чуть-чуть лучше хороших. Они на порядок лучше по любым меркам: концептуальное , скорость, изобразительность и способность находить решения. »
– Rendall E.Stross
Наверное эта цитата хорошо отображает понятие квалифицированный программист. Но в мире не всё так прекрасно. Количество лет работы программистом не всегда прямо пропорционально наличию соответствующего опыта и знаний.
Далее рассмотрим (с жизненными примерами), на что нужно обращать внимание, чтобы приблизиться к цели стать «лучшим» программистом.
Думаю, многие когда-нибудь сталкивались с ситуацией, что старшие руководители обладают не достаточной компетенцией, чтобы вести проект. Кого-то назначают на руководящую должность, потому что становится вопрос об увольнении, а людей и так не хватает, поэтому создается новая должность с более высокой зарплатой. Я считаю, что, закончив институт (то есть в 22-23 года), мало кто может похвастаться достаточным опытом, соответствующим программисту уровня senior. А чтобы руководить другими людьми, нужна широкая осведомленность в техническом плане, и, конечно, нужно обладать качествами лидера.
Когда попадаешь в коллектив, невольно начинаешь оценивать способности окружающих, в особенности старших коллег. Это бывает полезно, если выдастся возможность самому выбрать, в чьем проекте принять участие. Итак, получив руководящую должность (минуя этап становления хорошим разработчиком, то есть почти стазу после универа), кто-то может просто решить, что всё, от него более ничего не требуется в профессиональном росте, можно довольствоваться знаниями, полученными во время учебы в универе и опытом работы в 2 года, к тому же с неполной занятостью. Дальнейшее саморазвитие таких людей ограничивается знаниями и навыками, получаемыми по ходу необходимости для проекта и с курсов, оплачиваемых фирмой. Работать с такими людьми вообще никакого желания нет. Ведь в то время, как ты прокачиваешь свои скилы, руководитель неохотно что-то изучает, когда приходится. И это в лучшем случае, а то ведь «я руководитель», поэтому напрягу кого-нибудь другого, а мне пусть перескажут в двух словах, о чем там «Война и мир». А еще наверное почти в каждом коллективе есть люди типа «OK Google», поэтому зачем париться. Ведь мотивации для поддержания и повышения профессионального уровня почти не осталось: руководящую должность получил(а), денежной мотивации соответственно тоже нет, ну о профессиональном соответствии такие люди видимо вообще не задумываются. Да и не особо-то стремятся они обучать кого-то, что собственно является их обязанностью. Помню, когда еще училась в институте, знакомый (постарше меня ) сказал, что его повысили до начальника отдела (в его 25 лет). На вопрос, сколько человек у него в подчинении, он улыбнулся. Фактически в его отделе еще 2 человека, но они не его подчиненные. Через год у этого человека ситуация не особо изменилась.
Хотелось бы обратить внимание на несколько конкретных вещей, которые упускают из вида некомпетентные старшие программисты.
Нужно знать о программах, которыми пользуетесь
Надеюсь, что у всех в компаниях используются системы контроля версий. Мы используем SVN. Один из печальных фактов, что многие не знают в общих чертах, как работают системы контроля версий, чем отличаются распределенные от централизованных систем. В некоторых проектах у нас задействована работа с базами данных (используется Postgres). И вот однажды слышу от одного товарища, что Postgres используется именно для хранения коммитов. Человек даже и не подозревает, что в SVN своя структура хранения информации. Вот сказали ему, что есть команды add, ignore, commit, update и checkout и всё, на этом его знакомство с продуктом окончено. Когда нужно просто выкачать какую-то конкретную версию проекта (без истории всех фиксаций), некоторые даже и не подозревают, что есть export (однажды я наткнулась на сборище из четырех человек, решающих этот вопрос).
Но самая нелепая ситуация складывается, когда несколько человек изменяют одни и те же файлы. И как же теперь закоммитить !? И слышишь: «Как? ты тоже что-то менял в файле x.cpp и Y.cpp? Стой пока не коммить! Кто-то один сделает это, а недостающее другой добавит». Возникает встречный вопрос: Ну а зачем тогда создавалась возможность по разрешению конфликтов? Все равно, если кто-то сделал коммит, ты сначала выкачиваешь его, а потом вносишь свои изменения. Не надо думать, что система контроля версий – это просто свалка вносимых изменений, в которой происходит присвоение версии конкретному состоянию файла/проекта. Если при попытке сделать коммит возникает конфликтная ситуация, то это не значит, что вы сделали фиксацию и проблемные файлы сохранились в системе контроля версий. Нужно понимать, какие операции выполняются в рабочей копии, а какие в репозитории. Тупо выполнять операции и считать, что произошла «магия» не нужно.
Нужно иметь представление о модели OSI/ISO
Каждый хоть как-то пересекался с какими-то понятиями из сетевой модели. Вот реальная история, в которой неосведомленность и наличие не полного понимания о некоторых вещах играет злую шутку. Как-то возникла задача работы по интерфейсам RS-422. Ну а почему бы и не взяться за это, ведь работа будет с COM портом, осталось почитать об особенностях самого стандарта RS-422. И тут у меня спрашивает один из старших программистов: «Уже был опыт работы по RS422/485 ?» Отвечаю, что нет, всё равно уже работала с последовательными портами, так что разберусь. И тут я вижу удивленное лицо человека, который начинает почему-то впаривать (для ясности: у нас до этого никто не работал с RS422), что обмен будет не по последовательному порту. То есть у него вообще нет представления, что такое стандарт физического уровня и интерфейс, используемый для осуществления обмена.
Возможно, не все за свою карьеру программистом работали с Bluetooth, pipe, share memory, RS-422, Ethernet и др. Но программист должен понимать, что если он умеет работать по последовательному порту, то сможет выполнить обмен и по Bluetooth, и по RS422/232. Нужно различать уровни ISO/OSI. Не нужно делать проблему, когда возникает задача написать программу для обмена по UDP, а вы раньше писали только обмен по TCP протоколу.
Писать продукт без тестов плохо
То, что не хватает людей, продукт сопровождается уже несколько лет, а писать модульные тесты с нуля займет много времени и что нет у нас таких людей – просто оправдания. Можно же писать тесты для новых фич.
Если ты сходил(а) на какие-то курсы – ты не стал(а) хорошим специалистом по этому направлению
Как уже говорилось, большую часть новых знаний fake-руководители получают из курсов, оплачиваемых предприятием. И насколько же бывают неуместны их комментарии в беседах, с которыми вроде бы пытаются блеснуть знаниями, а на самом деле не подозревают, что собеседники очень даже в теме и городить полную ересь с умным видом было не обязательно.
Конечно этот список может продолжаться, а перечислять возникающие нелепые ситуации можно довольно долго, но я не об этом. Мне кажется, что очень важно быть выбранным в качестве руководителя проекта, чтобы Вас уважали как программиста и руководителя. Если выдается свободное время, не нужно по полдня тупо сидеть в телефоне/планшете, чтобы поиграть или посмотреть сериал. Всё знать нельзя, но в той или иной мере нужно быть просвещенным в технологиях, архитектуре и др. Ведь очень глупо выглядит, когда 2-3-летний опыт работы молодых заслоняет 10-летний стаж простого просиживания штанов. Я встречала разных программистов, и эта статья относится к меньшинству из них. Но тем ни менее помните, вы должны быть(или хотя бы стремиться быть) примером для более молодого поколения.
Автор: AnROm
