Инженер VS Программист. Или куда уходят инженеры
За последнюю неделю на Хабре появилось как минимум три поста о том, как люди разного возраста, пола и полученной специальности становились программистами. Успешными программистами. Эти истории отвечали на вопрос «как», но почти упускали вопрос «почему».
Сейчас я еще работаю инженером, причем по моей вузовской специальности «Радиофизика и электроника», и по профилю кафедры Антенн и Радиопередающих устройств. Но уже активно шагаю в сторону переквалификации.
Почему же я, инженер с 14 годами стажа, решил перейти в программисты?
Востребованость
В России сейчас инженер СВЧ не нужен. Новых разработок очень мало. Интересных проектов почти нет. Есть ВПК, где еще что-то разрабатывают, но там сидят деды, которые не дадут дергаться сильно. Секретный допуск и документация для передатчиков начинается от «совершенно секретно», что лишит вас радости путешествия за пределы России и повесит дамоклов меч службы Гостайны у вас над головой. Разработки только из элементов, доступных в перечне импортозамещения. Новые технологии? Слышали, но не можем. Ах, да, слышать и читать вы их не будете, интернет на работе запрещен.*
*данная информация является личным опытом автора поста
В частном секторе все еще хуже и печальнее. Если считать, что СВЧ в нынешнем его понимании начинается от 10ГГц и не включает сотовую связь, то мест, где вы найдете работу для разработчика, да еще по специальности, да еще за деньги — почти нет.
Оплата труда
Из причины выше можно увидеть, как работают законы рынка. Спрос на работу превышает предложения, поэтому зарплаты идут вниз. Оно и раньше инженер получал меньше рабочего.
Сейчас кажется, что всё осталось также. Средняя зарплата инженера-разработчика в Петербурге — 40 000 рублей. Данная цифра соответствует действительности. Причем разброс небольшой — от 23 до 60. Не нравится – иди работай в другом месте, на твое место есть очередь. Хотя в последнее время ситуация стала меняться еще в том, что на 30 000 руб приходят свеженькие выпускники вузов.
Поэтому я могу точно сказать – уровень образования технических вузов стремительно пикирует вниз. Потому что те, кто понимает на этапе обучения, что высоких зарплат не будет, сразу уходят в программисты.
Одна среда
Опять логический переход. Отличия инженера от программиста у нас небольшое. Системный подход, аналитическое мышление, умения решать поставленные задачи. Даже привычка делать код с костылями выросла из волшебного свойства синей изоленты. Более того, инженер-разработчик в нынешнее время — это в любом случае программист, потому что от микроконтроллеров, обработки сигналов и прочей алгоритмов никуда не деться. От инженера в программисты — всего пара шагов.
Перспективы
Опять выигрывает программист. Инженеры нужны все меньше и меньше. Все более узконаправленные и узконаправленные. В программировании все иначе, это как пучок технологий, где тренды меняются каждый год. «Нам нужно больше программистов». Этот рефрен можно услышать даже из чайника, по WiFi. Я боюсь, что станет, когда инженеров станет слишком мало, но радуюсь, что до этого не доживу. Пока что еще слишком много инженеров и слишком мало программистов.
Вывод напрашивается один. Идти в программисты. Почему я не сделал этого раньше? Одна единственная причина – я создаю устройства. Готовые, технологичные и полезные в пределах целого мира. За небольшую зарплату, с переработками и мыслями по ночам о том, как сделать лучше. Я могу подержать их в руках, я могу вспомнить, как они выглядели, каков был их нелегкий путь от идей к воплощению. Но, наверняка они будут продолжать создаваться и без меня…
Чем отличается программист и инженер-программист?
Простой 1 комментарий
Единый квалификационный справочник. Имеет смысл только в организациях с гос. участием, где по разработанной тарифной сетке идёт начисление зарплаты. В коммерции свободы больше, могут обзывать почти как попало (думаю).
bizlog.ru/eks/eks-1/172.htm
Требования к квалификации:
Техник-программист I категории: среднее профессиональное образование и стаж работы в должности техника-программиста II категории не менее 2 лет.
Техник-программист II категории: среднее профессиональное образование и стаж работы в должности техника-программиста не менее 2 лет.
Техник-программист: среднее профессиональное образование без предъявления требований к стажу работы.
bizlog.ru/eks/eks-1/131.htm
Требования к квалификации:
Инженер-программист I категории: высшее профессиональное (техническое или инженерно-экономическое) образование и стаж работы в должности инженера-программиста II категории не менее 3 лет.
Инженер-программист II категории: высшее профессиональное (техническое или инженерно-экономическое) образование и стаж работы в должности инженера-программиста III категории или других инженерно-технических должностях, замещаемых специалистами с высшим профессиональным образованием, не менее 3 лет.
Инженер-программист III категории: высшее профессиональное (техническое или инженерно-экономическое) образование и опыт работы по специальности, приобретенный в период обучения, или стаж работы на инженерно-технических должностях без квалификационной категории.
Инженер-программист: высшее профессиональное (техническое или инженерно-экономическое) образование без предъявления требований к стажу работы или среднее профессиональное (техническое или инженерно-экономическое) образование и стаж работы в должности техника I категории не менее 3 лет либо других должностях, замещаемых специалистами со средним профессиональным образованием, не менее 5 лет.
Мой путь из инженера в программисты
Краткое содержание
Автор поныл, как тяжело живется инженерам на Руси и решил уходить в программисты. У него получилось. Пост о том, как именно.
Зачем я все это пишу
Благодарность
Ради этого пост задумывался. С этого и стоит начать.
Мой пост «Инженер VS Программист. Или куда уходят инженеры» принес множество комментариев, несколько личных сообщений, пару собеседований. Самое главное — он принес мне волну поддержки, позитива и мотивации.
Большое спасибо всему сообществу Хабра! Именно поддержка сообщества дала вдохновляющий пинок, вперед, к моей цели, и привела меня в программисты.
Отдельное спасибо хочу сказать serenityfx, который специально зарегистрировался, чтобы оставить комментарий с предложением поделиться своим опытом, нашел время побеседовать со мной лично, ответить на мои вопросы. Он дал мне направление и помог составить некое понимание, как и куда идти дальше.
Спасибо, Хабр! Ты крутой!
Краткое содержание прошлого поста
Проработав 14 лет инженером, в том числе инженером-разработчиком, я решил перейти в программисты, потому что инженер-программист — востребованная специальность с более высокой оплатой труда, широкими перспективами и возможностями.
Мой путь
Благодаря фидбеку от Хабра, я смог четко сформулировать два пути развития дальше.
Первый — еще раз попытаться найти себя как инженера-разработчика, как в России, так и за ее пределами. Благо, прямо из комментариев пришло несколько личных контактов, которые позволили сделать несколько попыток.
Второй путь, который тоже прорисовался достаточно четко – качать навыки программиста микроконтроллеров и встроенных систем и искать начальные позиции (джун-мидл) в этой сфере.
Как «умная и красивая обезьяна», у которой было время, я попытался идти одновременно по двум направлениям. Активно занялся поиском работы, в том числе за рубежом, и стал качать свои навыки в контроллерах.
Через полгода стало понятно, что первый путь все же тупиковый. Надо идти в программисты. Стечение обстоятельств подтолкнуло меня к увольнению. Я сосредоточился на контроллерах и поиске работы, но уже в качестве программиста.
Неожиданно для себя я получил предложение поработать в качестве фрилансера на проекте, который одновременно использовал меня и как программиста контроллеров, и как инженера-разработчика. Моя жизнь фрилансера продлилась 8 месяцев и закончилась вместе с платежами по заказам. Но мои навыки программирования за это время сильно подросли, поэтому я вернулся к рынку труда и поиску вакансии инженера-программиста.
По результатам одного из собеседований меня пригласили сначала на стажировку, потом на испытательный срок, который плавно перетек в постоянный контракт. Так я стал инженером-программистом встроенных систем.
Но давайте чуть подробнее о каждом из этапов.
Стартовая позиция
Начинается с инженера-разработчика. На самом деле, моя работа на половину состояла из разработки и тестирования алгоритмов, железа, на четверть из организационных вопросов — управлением командой, закупками и документацией, и на четверть из программирования разработанных устройств.
Как у инженера старой школы, у меня была склонность к теоретическим знаниям, поэтому к моменту увольнения за спиной у меня уже было несколько пройденных курсов разной степени полезности:
Кроме того были интересные, но бесполезные курсы от HTML Академии ИТМО (HTML/CSS/JS),
«Управления проектами» от ВШЭ и «Теория графов» от ИТМО. А также половина пройденного курса на JavaRush, который был заброшен после решения идти в embedded.
На практике у меня был опыт моделирования и обработки сигналов, связанных с моими устройствами. Опыт написания прошивок для контроллеров серии C8051 от SiliconLabs, младших контроллеров Atmel и немного опыта разработки для FPGA от Altera.
Также за спиной был опыт управления командой и мелкосерийным производством, но я считал его нерелевантным.
В поисках вакансии
Тема собеседований достойна отдельного поста. Их было много, они проходили волнами.
На собеседованиях был много странностей. Когда я приходил собеседоваться на позицию программиста, меня спрашивали, почему с таким опытом я не хочу работать инженером. На собеседованиях на позицию инженера меня пытали на предмет опыта программирования.
Были короткие встречи, на которых я говорил «Стоп, вам нужен не я». В противовес этому на одну из позиций был марафон собеседований из пяти двухчасовых собеседований на английском по скайпу. Были замаскированные военные, идти к которым я не хотел принципиально. Была фирма, которая по сути представляла собой кооператив фрилансеров во главе с менеджером.
Главным же итогом большинства моих собеседований было отсутствие предложений о работе там, где я хотел, и наличие предложений там, где мне не хотелось бы работать.
Жизнь во фрилансе
Здесь я с головой окунулся во все плюсы и минусы фриланса, которые многократно обсуждались на Хабре. Для меня огромным плюсом стало время. Я жил в своем таунхаусе на природе и не тратил время на дорогу. Зато я легко отдавал проекту по 12 часов в день, имея возможности учиться и закрывать те пробелы в знаниях, которые у меня были в программировании. Я окунулся в мир STM32 и, в том числе, FreeRTOS. Сначала смакетировал на Дискавери нужный мне проект, потом сделал плату и повторил его на 10х серии. Параллельно разобрался в Git и проектировании на UML в рамках нужных задач. К сожалению, уезжать далеко от дома я не мог, потому что осциллограф, паяльник, блок питания пришлось бы таскать с собой.
Одновременно пробегали проекты, связанные с антеннами и радарами. Но основной доход приносил один заказчик. К слову, этот доход был в полтора раза выше мой зарплаты инженера-разработчика.
Однако сначала заказчик стал задерживать оплату этапов, но я терпел. Когда же совсем перестал платить и исчез с горизонта, то пришлось затянуть пояс и идти искать работу снова.
Да, банальность известная всем — заключайте договор. Я обменял деньги на опыт работы во фрилансе и программировании.
Испытание боем
В эту фирму я попал со второго раза. Первая попытка решить тестовое задание (небольшая задачка для микроконтроллера) не привела к собеседованию. Отзвонился, узнал чем именно не понравилось мое решение (мало комментариев, предложен всего один вариант решения). Вторая попытка спустя полгода была более удачной.
Собеседование с представителем HR, с небольшими тестами. Разговор с будущим коллегой, долгий и обстоятельный. Суммарно более 2 часов. Предложение об оплачиваемой «стажировке» на несколько дней.
За время «стажировки» закрыл пару-тройку багов. Деньги получил на руки вместе с предложением испытательного срока на три месяца.
Можно сказать, что с этого времени началось настоящее погружение, длиной в полгода. Вкратце за это время:
Первые полгода были очень активным временем. Работаешь положенные 8 часов. Потом приезжаешь домой и все оставшееся время пытаешься быстро подтянуть свои знания и навыки, чтобы решить задачи, поставленные днем. На следующий день приходишь на работу и с новыми знаниями пытаешься решить задачу.
Очень сильно помогали коллеги. Где практическими советами, где просто идеями.
Когда работаешь в режиме: есть задача — нужно срочно решать, то обучение движется существенно быстрее. Главное не забывать смотреть чуть шире, и успевать понимать, что именно ты делаешь.
Сейчас я чуть снизил обороты, тем более что зимой я впадаю в состояние, близкое к спячке, но я уже не только работаю программистом, но и ощущаю себя им. Легаси код, спринты, проектирование, тесты, CI/CD в полный рост. И мне это чертовски нравится!
Зарплата по сравнению с инженером-разработчиком выросла более чем в два раза. Никаких переработок и непонятных требований. Это даже больше, чем я ожидал, когда собирался уходить в программисты.
Что дальше.
Не останавливаться. Это не сложно, потому что программирование имеет свойство затягивать в процесс. Начав, очень сложно остановиться.
Учиться. Потому что белых пятен в моих знаниях еще очень много, в том числе теоретических. А уж как не хватает практических.
Очень хочу заниматься своим проектом, тем более что у меня в голове есть парочка идей, а на руках две интересные платки.
Записался на пару курсов. Алгоритмы и базы данных.
Хочу дойти в той же сфере до сеньора, а там посмотрим.
Заключение
Самый главный посыл этого текста – я смог стать из инженера-разработчика программистом встроенных систем за два года. Если бы не терял время в тщетных надеждах и топтании на месте – в полтора года точно бы уложился.
Что было важно и нужно – знание теории. Базовые понятия, железо, Линукс, контроллеры.
Чего явно не хватило – практики. Любой свой проект, с обязательным красивым кодом и комментариями – очень не хватало при поиске работы.
Уверенность в том, что все получится. У меня были вдохновляющие комментарии на Хабре и «крепкий тыл», который в меня верил.
Кто ты по професии: Разница между «Programmer», «Software Engineer» и «Computer Scientist»
Как только сегодня ни называют программистов, особенно в зарубежных СМИ. Да и у нас, в частности, при поиске работы, можно встретить абсолютно разные описания должностных обязанностей.
Меняется ли от этого суть работы? Мы в 1cloud попробовали разобраться в том, какую работу подразумевают такие специализации как «Programmer», «Software Engineer» и «Computer Scientist».
Терминология
Изучение сути вопроса логично начать с понимания терминов. Самым понятным является «Programmer», который в Оксфордском словаре определяется как человек, ответственный за написание программы. И с переводом все просто: программист – он и в Африке программист. И даже в России. Сложности начинаются дальше.
«Software Engineer» (SE) (согласно статье в webopedia) — это дипломированный профессиональный инженер, имеющий достаточно знаний и навыков для применения инженерных дисциплин при создании программного обеспечения. Главное отличие — SE занимается разработкой, руководством проектов, а программист их реализует путем написания кода. На русский название должности переводится как «инженер-программист» или просто «программист».
Теперь разберемся с тем, кто такой «Computer Scientist» (CS). Если верить словарю, то речь идет о работе в области теории вычислений и проектирования компьютеров. Разные словари дают разный перевод на русский: «учёный, работающий в области теории вычислительных машин и систем (в области ВТ, в области компьютерных наук)» или «программист».
Итого, имеем три очень разных определения в английском и три «программиста» в русском.
Как сами программисты понимают эту разницу
Западный подход довольно четко разграничивает все три должности. Но у нас часто возникает путаница, и все три понятия используются как взаимозаменяемые. Поэтому лучше обратиться к мнению самих программистов и посмотреть, как они описывают свою деятельность.
Для обеспечения полноценной разработки ПО/кода программист должен быть сконцентрирован на своей работе и обеспечить последующее использование и интеграцию программных компонентов друг с другом. Энтони Щерба (Anthony Scherba), президент и основатель студии разработки Yeti, сравнивает этот процесс с решением сложной алгебраической задачи.
Так, по мнению эксперта, в обязанности программиста входит создание, упрощение, документирование кода и написание тестов. Поскольку он занимается практической реализацией поставленных задач, программист должен разбираться в особенностях языка (языков) программирования, с которыми работает, а также в теории алгоритмов.
Необязательные компетенции: математический анализ, коммуникативные навыки и умение работать в команде — подробнее в блоге Алана Скоркина (Alan Skorkin).
Работа «Software Engineer» подразумевает комплексный подход и иногда ее можно сравнить даже с процессом создания произведения искусства, которое программист старается постоянно усовершенствовать. Так считает и Дэниел Каплан (Daniel Kaplan), опытный программист и сотрудник Pivotal Labs.
Инженер должен видеть всю картину с двух сторон: проект в соответствии с общим планом и отдельные задачи, необходимые для его осуществления. Он должен уметь находить верные комплексные решения, понимать требования клиентов, прогнозировать возможные последствия и распределять задачи по программированию (в команде).
Его работа особенно важна во время разработки новых версий или функциональных возможностей продукта или, например, когда клиент меняет свои требования. Таким образом, инженер-программист отвечает не просто за написание кода, а за весь проект.
«Computer Scientist» — математик и технический специалист в равной степени. Он обладает математическими знаниями и объясняет, как и почему работает тот или иной инструмент, решение или алгоритм. Его работа имеет большое значение для развития программирования в целом. Также CS свойственна специализация в одной или нескольких сферах — ИИ, нейронные сети, теория языков программирования, базы данных.
Представления профессионалов в принципе соотносятся со словарными статьями, что естественно: на то они и профессионалы, чтобы разбираться в своей работе. Сбой в коммуникации и подмена понятий явно происходит на каком-то другом уровне, но на каком?
Какую разницу видят учебные заведения и работодатели
Начнем опять с «программиста». Еще одно его важное отличие от всех остальных: как правило, отучившись в профильном ВУЗе, вчерашний студент становится не просто «программистом», а «инженером/бакалавром/магистром по специальности/направлению…».
Для западной образовательной системы это тоже характерно — взгляните, к примеру, на разнообразие специальностей в направлении «Software Development and Programming» Сиднейского Технологического Университета. Ни одна из них не содержит в своем названии слова «programmer» или «programming».
Нет, конечно, многие университеты предлагают курсы по программированию (даже бесплатные), но редко когда в дипломе написано просто «программист». А что хотят видеть работодатели?
Помимо знания разных языков и/или опыта работы на разных мобильных платформах/ опыта веб-программирования/ администрирования, программисту нельзя обойтись без коммуникативных навыков (примеры тут и тут). В приведенных примерах вакансий требуется навык работы в команде, предполагается общение с вендорами, сотрудничество с другими отделами компании и техническим директором. Ну и организаторские и управленческие способности будут нелишними. А в ряде случаев нужны еще и достаточно глубокие знания математики.
Требования на российском рынке отличаются не сильно и включают разработку проектов, работу в команде, понимание принципов информационной безопасности (и всё те же навыки, отмеченные в абзаце выше). Таким образом, работодатели хотят видеть в программисте универсального (и творчески мыслящего) специалиста, а не просто человека, который пишет и тестирует код на определенном языке, решая кем-то поставленную задачу. Получается, что работодатель (как на Западе, так и у нас) под «программистом» очень часто понимает то, что словари обозначают как минимум как «Software Engineer».
Образовательные программы по профилю «Software Engineering» подразумевают, подход к разработке ПО с научной и инженерной точки зрения, разработку собственных проектов, аналитическую и управленческую деятельность. Помните, в предыдущем разделе эксперты говорили, что SE должен уметь реагировать на изменяющиеся требования? На магистерской программе помимо этого объясняют, как укладываться в бюджет и сроки.
В университете Глазго учат определять технические характеристики, проектировать, создавать и верифицировать крупные программные системы. При этом список предметов включает программирование на разных языках, проектирование баз данных, изучение алгоритмов, то есть все те знания, которые необходимы и для работы «классического программиста».
Что касается точки зрения работодателей, то по их мнению в обязанности инженера-программиста входит написание кода, проверка технической реализации UI/UX, оптимизация работы приложений, разработка внутренней методологии и стандартов, контроль и управление требованиями. Кроме того, соискатель должен обладать лидерскими качествами. Технические требования не сильно отличаются от требований к «обычным» программистам: их примеры можно посмотреть тут: 1, 2 и 3.
Университетские программы по направлению «Computer Science» включают больше математических предметов, изучение теории алгоритмов, а также такие темы как машинное обучение, нейронные сети и облачные вычисления. Студенты изучают больше теории, но должны успешно применять на практике полученные математические знания, выявлять, формулировать и решать инженерные проблемы. Таким образом, у этого типа специалистов формируется наибольшая «широта взглядов» — в теории он может работать и программистом, и SE, и непосредственно по специальности.
Это не означает, что полученных знаний ему «за глаза» хватит для успешного старта карьеры в любой из областей и больше ничему учиться не придется. Например, чтобы построить успешную карьеру разработчика, такому выпускнику явно понадобится «подтянуть» практические навыки по написанию кода — но не придется изучать программирование «с нуля».
Идеальный соискатель на должность «Computer Scientist» должен обладать знаниями по теоретической информатике, теории алгоритмов, проектированию баз данных, компьютерному моделированию, при необходимости выполнять задачи аналитика и проводить исследования, знать весь процесс от проектирования до внедрения ПО… Список можно продолжать долго (подробнее читайте тут и тут).
Работодатели хотят видеть профессионала, который не ограничен применением навыков в сугубо научной сфере. Кстати, русскоязычные работодатели тоже ищут таких специалистов и предлагают свои названия профессии: ведущий алгоритмист и инженер-исследователь. На этих примерах прослеживается та самая специализация, о которой мы упоминали в прошлом разделе.
Что в итоге
Да, действительно программисты, SE и CS — специальности близкие, но не одинаковые, и готовят таких профессионалов на разных университетских специальностях. Наибольшую путаницу в трактовке терминов вносят работодатели – для них, например, разница между «программистом» и Software Engineer может быть совершенно не очевидна.
Судя по требованиям работодателей, от «просто программиста» ждут творческого подхода, универсальных знаний и soft skills, а «computer scientist» может решать важные, но при этом сугубо прикладные, узконаправленные задачи — говорить о том, что одна специальность «по умолчанию» лучше или «сильнее» другой тут не приходится.
О чем еще мы пишем в блоге 1cloud на Хабре:
20 вещей, которые я узнал за 20 лет работы инженером-программистом
Наткнулся на любопытный материал, в котором автор систематизировал и записал свой опыт инженера-программиста в 20 тезисов. Я работаю в коммерческой разработке ПО больше 25 лет, и этот текст отозвался во мне практически каждой буквой — большинство советов я тоже регулярно практикую, не облекая их в формат ёмких афоризмов. В общем, решил сделать перевод.
Особенно отзываются пункты «стройте компактные системы» и «лучший код — это отсутствие кода». Последний совет я превращаю в цитату из какого-то второсортного фильма про самураев: «Лучшая победа — та, которую ты одержал, не доставая меч из ножен» (думаю, сослуживцы за моей спиной уже закатывают глаза). И, конечно, бесконечные разговоры про легендарных 10x-программистов постоянно хочется прервать советом не связываться с 0,1x-программистами (которые реально существуют, в отличие от 10x).
Дисклеймер от автора оригинальной статьи
Учиться на чужом опыте и ошибках очень важно, но мы часто забываем, что большинство советов имеют контекст, который далеко не всегда учитывается.
«Вам просто нужно повысить цены» — говорит компания, которая 20 лет работала в бизнесе, выставляя поначалу низкие цены для привлечения клиентов.
«Вам нужно внедрять микросервисы» — говорит компания, которая построила монолит, набрала тысячи клиентов и перешла на микросервисы, когда столкнулась с проблемами масштабирования.
Без понимания контекста советы бессмысленны или, что ещё хуже, вредны. Если бы эти компании последовали собственным рекомендациям в начале пути, они, скорее всего, навредили бы сами себе.
Для понимания контекста расскажу, откуда берутся советы в этой статье. Первую половину карьеры я работал инженером-программистом в небольших компаниях и стартапах, потом перешёл в консалтинг и работал в нескольких действительно крупных компаниях. Затем основал Simple Thread, которая выросла из команды 2 человек до 25. 10 лет назад мы работали в основном с малым и средним бизнесом, сейчас — со средним и большим.
Советы в этой статье от человека, который:
почти всегда работал в небольших командах, где приходится делать много, имея очень мало;
ценит работающие решения выше конкретных инструментов;
постоянно начинает новые проекты, но поддерживает ряд систем;
ценит производительность инженера выше большинства других критериев.
Мой опыт за последние 20 лет сформировал отношение к разработке и убедил меня в некоторых утверждениях, которые я оформил в виде списка. Надеюсь, он вам будет полезен.
1. Я все ещё многого не знаю
«Как ты можешь не знать, что такое BGP?» или «Ты никогда не слышал о Rust?» — некоторые из нас не раз слышали подобное.
Причина, по которой многие любят разработку, заключается в том, что мы учимся всю жизнь. И в создании софта есть огромные области новых знаний, которые с каждым днём только растут. Можно десяток лет работать программистом и всё равно иметь огромный пробел в знаниях по сравнению с кем-то, кто также провёл десятилетия в, казалось бы, аналогичной роли.
Чем раньше вы это поймёте, тем быстрее сможете избавиться от синдрома самозванца и с удовольствием учиться у других.
2. Самое сложное в разработке — сделать продукт, который действительно нужен
Знаю, что это уже стало клише, но многие инженеры скептически относятся к данному пункту, поскольку считают, что он обесценивает их труд. Чушь, на мой взгляд. Напротив, этот момент помогает подчеркнуть, в насколько сложной и иррациональной среде нам приходится работать, ведь именно эти аспекты так усложняют нашу деятельность.
Можно разработать самую технически впечатляющую вещь в мире, а потом никто не захочет её использовать. Такое случается постоянно. Проектирование софта часто связано со слушанием — нам приходится быть сразу инженером-программистом, экстрасенсом и антропологом.
Инвестиции в процесс проектирования (с помощью UX-специалистов или путём самообразования) принесут огромные дивиденды. Ведь как реально подсчитать стоимость разработки неправильного ПО? Это гораздо больше, чем просто потерянное время инженера.
3. Лучшие инженеры-программисты думают как дизайнеры
Великие инженеры-программисты глубоко задумываются о пользовательском опыте. Они могут не думать об этом в терминах вроде внешнего или программного API, UI, протокола или любого другого интерфейса. Великие инженеры думают о том, кто будет его использовать, почему он будет использоваться, как он будет использоваться и что важно для пользователей. Учет потребностей конечного потребителя — это залог хорошего пользовательского опыта.
4. Лучший код — это отсутствие кода или код, который не нужно поддерживать
Всё, что нужно сказать: кодеры будут кодить. Если спросить человека любой профессии, как решить ту или иную проблему, он выберет то, что у него хорошо получается. Это просто человеческая природа. Большинство инженеров-программистов всегда будут склоняться к написанию кода, особенно когда нетехническое решение не очевидно.
То же самое относится к коду, который не нужно поддерживать. Инженерные команды часто хотят изобрести колесо, когда оно уже существует. Здесь нужно соблюдать баланс, есть много причин для развития собственных разработок, но остерегайтесь токсичного синдрома «изобретено не здесь».
5. Программное обеспечение — это средство достижения цели
Основная работа любого инженера-программиста — предоставление ценности. Немногие разработчики понимают это, ещё меньше тех, кто это осознает. А ведь осознание приводит к другому способу решения проблем и другому взгляду на инструменты.
Если вы действительно верите, что выбор ПО зависит от цели, то будьте готовы найти «правильный инструмент для работы», который может и не являться софтом.
6. Иногда нужно перестать точить пилу и просто начать пилить
Некоторые сразу бросаются в проблему и начинают писать код. Другие — начинают исследовать и попадают в аналитический паралич. В таких случаях установите дедлайн и начните изучать решения. Вы гораздо быстрее узнаете что-то, когда непосредственно станете решать задачу.
7. Если у вас нет представления о границах возможного, вы не сможете спроектировать хорошую систему
С этим я часто сталкиваюсь, поскольку мои обязанности уводят меня все дальше и дальше от повседневной разработки ПО. Следить за командой разработчиков — огромный объём работы. И если вы не понимаете, на что способна ваша команда, то сможете разрабатывать решения только для самых простых проблем. И опасайтесь тех, кто давно не писал никакого кода.
8. Каждая система в конечном счёте отстой, смиритесь с этим
У Бьерна Страуструпа есть цитата: «Есть только два вида языков: те, на которые все жалуются, и те, которыми никто не пользуется». Это можно распространить и на большие системы. Не существует «правильной» архитектуры, вы никогда не закроете весь техдолг, не разработаете идеальный интерфейс, ваши тесты всегда будут слишком медленными.
Это не оправдание тому, чтобы не делать что-то лучше, а наоборот, способ дать вам перспективу. Меньше беспокойтесь об элегантности и совершенстве, стремитесь к постоянному улучшению и созданию пригодной для жизни системы, в которой вашей команде нравится работать и которая стабильно приносит пользу.
9. Никто не спрашивает «почему» в достаточной степени
Используйте любую возможность поставить под сомнение предположения и подходы, которые «всегда делались так, как надо». В команде появился новый сотрудник? Обратите внимание, где он запутался и какие вопросы задаёт. Поступила заявка на новую функцию, которая не имеет смысла? Убедитесь, что вы понимаете цель и то, что требует эту функциональность. Если не получаете чёткого ответа, продолжайте спрашивать, пока не поймёте.
10. Сосредоточьтесь на том, чтобы избежать 0,1х-программистов, а не найти 10х-программистов
10x-программист — это глупый миф. Идея о том, что кто-то может сделать за 1 день то, что не менее компетентный, трудолюбивый, и такой же опытный программист может сделать за 2 недели, глупа.
Я видел программистов, которые пишут в 10 раз больше кода, а потом вам приходится исправлять его в 10 раз дольше. Кто-то может быть 10х-программистом только в том случае, если вы сравниваете его с 0,1x-программистом — тот, кто тратит время, не просит обратной связи, не тестирует свой код, не рассматривает крайние случаи и так далее. Нужно заботиться, чтобы не допустить 0,1x-программистов в команду, а не искать мифического 10x-программиста.
11. Одно из главных отличий между сеньором и джуном — свое мнение о том, как все должно быть
Ничто не беспокоит меня больше, чем сеньор, не имеющий никакого мнения о рабочих инструментах или о том, как подходить к созданию программного обеспечения. Лучше высказать мнение, с которым я буду категорически не согласен, чем не иметь мнения вообще.
Если вы используете инструменты, но ненавидите их, вам нужно изучить больше. Попробуйте другие языки, библиотеки и парадигмы. Существует мало способов повысить уровень своих навыков быстрее, чем активный поиск того, как другие решают задачи с помощью инструментов и методов, отличных от ваших.
12. Людям не нужны инновации
Люди много говорят об инновациях, но обычно они ищут дешёвые преимущества и новизну.
Если вы действительно привносите новшества и меняете то, что людям привычно — ждите отрицательных отзывов. Но если верите в то, что делаете, и знаете, что это действительно улучшит ситуацию, приготовьтесь к долгой битве.
13. Ваши данные — самая важная часть системы
Я видел много систем, в которых целостность данных держалась в основном на надежде. Любое отклонение от идеального сценария в такой системе, и мы получаем частичные или грязные данные, а работа с такими данными в перспективе превратится в кошмар.
Важно помнить, что данные скорее всего сильно переживут вашу кодовую базу. Приложите усилия, чтобы всё хранилось в порядке, и это окупится.
14. Ищите технологических акул
Старые технологии, которые остались на плаву, — это акулы, а не динозавры. Они настолько хороши, что пережили быстрые изменения, которые постоянно происходят в мире технологий. Заменяйте их только в том случае, если у вас есть очень веская причина. Эти инструменты не будут модными и современными, но позволят выполнить работу без множества бессонных ночей.
15. Не путайте скромность с невежеством
Есть много программистов, которые не высказывают мнения, если их прямо не спросить. Если кто-то не высказывает своё мнение вам в лицо, это не значит, что ему нечего добавить. Иногда самых громких хочется слушать меньше всего.
Поговорите с окружающими, запросите фидбек и советы.
16. Программисты должны регулярно писать
Инженеры-программисты должны регулярно вести блог или дневник, писать документацию и вообще делать всё, что требует от них высокого уровня навыков письменного общения. Письмо помогает думать о проблемах и более эффективно общаться с командой. Это один из важнейших навыков, которым должен овладеть любой программист.
17. Рабочие процессы должны быть минимально энергозатратными
Сейчас все хотят быть agile, но «agile» — это создание вещей небольшими порциями, обучение, а затем итерация. Если кто-то пытается вложить в это гораздо больше, значит, он что-то продаёт. Для этого необязательно переставать помогать сотрудникам или отказываться от отчётности, но вы когда-нибудь слышали, чтобы люди из ваших любимых IT-компаний и масштабных опенсорс-проектов хвалились тем, какой у них клёвый Scrum? Процессы должны оставаться лёгкими и гибкими до тех пор, пока не появится потребность в большем. Доверьтесь своей команде, они всё сделают.
18. Инженеры-программисты, как и все люди, должны чувствовать ответственность
Если вы отвлечёте кого-то от результатов его работы, то он будет меньше заботиться о ней. Это почти тавтология и основная причина, почему кросс-функциональные команды работают хорошо, и почему DevOps стал таким популярным. Дело не только в передаче обслуживания и неэффективности, а в том, чтобы управлять всем процессом от начала до конца и нести прямую ответственность за предоставление ценности.
Дайте группе увлечённых людей полную ответственность за проектирование, создание и выпуск софта (или чего-то ещё) — произойдут удивительные вещи.
19. Собеседования не помогут определить, насколько хорошим членом команды будет человек
Собеседования лучше проводить, чтобы понять, кто такой человек и насколько он заинтересован в нужной области знаний. Пытаться выяснить, насколько хорошим членом команды он будет, — бесполезное занятие.
То, насколько человек умён или осведомлён, также не является хорошим показателем, каким членом команды он станет. Никто не скажет вам на собеседовании, что он будет ненадёжным, жёстким, напыщенным или никогда не будет приходить на собрания вовремя. Некоторые ищут «сигналы» для таких вещей, вроде «Если они спрашивают об отгулах на первом собеседовании, значит, они точно не будут ходить на миты!», но это все ерунда. Если вы опираетесь на подобное, то просто гадаете и отбрасываете хороших кандидатов.
20. Стремитесь к созданию более компактной системы
Есть много факторов, которые будут подталкивать вас к созданию большой системы. Распределение бюджета, невозможность решить, какие функции следует сократить, желание создать «лучшую версию». Все эти вещи очень сильно подталкивают к тому, чтобы сделать слишком много. Нужно бороться с этим.
В процессе разработки вы узнаете так много нового, что в результате итераций получите гораздо более крутой результат. Для многих это крайне трудно.
Ваша история
Вот и всё: 20 лет разработки программного обеспечения превратились в 20 мудрых пунктов. Если согласны или не согласны с мыслями в статье, или если есть, что добавить и чем поделиться — пишите в комментариях.