что делает программный инженер
Кто ты по професии: Разница между «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 на Хабре:
«Я думала переехать и работать за рубежом»: сколько зарабатывает инженер-программист
В Санкт-Петербурге
Героиня этого выпуска стала инженером-программистом вслед за братом и отцом. Она начинала в компании, которая создает системы управления авиационными двигателями, и получала 7500 Р в месяц. А сейчас работает в иностранной компании, которая занимается автомобилями нового поколения, и зарабатывает в 25 раз больше.
Выбор профессии
Я хотела поступить на факультет прикладной математики и программирования СПбГУ еще в старших классах. На меня повлияли отец и брат: они оба инженеры-программисты. До этого отец был моряком-подводником, но в 45 лет вышел на пенсию и устроился в ту же контору, где работал мой брат. Они создавали системы управления авиационными двигателями.
Когда слышишь, как люди с жаром и блеском в глазах обсуждают работу, проникаешься. Правда, слушая их тогда, я почти ничего не понимала: там было полно терминов и аббревиатур типа САУ или БАРК. Авиацию в принципе окутывает ореол романтики, и это была возможность к ней прикоснуться.
После третьего курса я начала искать работу по специальности. Поговорила с отцом, он помог устроиться на то же предприятие, где работали они с братом. Не знаю, вышло бы это без посторонней помощи или нет: просто так узнать о вакансиях очень сложно. За работу на половину ставки мне платили 7500 Р в месяц. Полный день я не могла позволить себе из-за учебы. Я и так до последнего семестра носилась как белка в колесе. С режимного предприятия не так просто уйти в середине дня, чтобы попасть на пары.
С братом я почти не общалась по работе, он был очень занят. Отца иногда спрашивала, как устроен двигатель или контроллер. Сначала меня отдали под начало коллеге, он рассказал основные принципы и почти сразу же поручил часть работы. Главное, что я получила на этом предприятии, — опыт. Все, о чем рассказывали в университете, было полезно: нереально самостоятельно освоить математику, физику, теорию управления, разделы механики и электротехники. Но одно дело изучить законы и формулы, другое — видеть их реальное применение. Без практики цена этим знаниям — ноль.
В университете мы изучали среду Matlab, это мощный инструмент для моделирования и вычислений, с тех пор моя карьера связана с ней. В этой среде можно делать математические модели — своего рода программы. Например, я делала модели газотурбинного двигателя, который создает реактивную струю и приводит в движение самолет.
Наше конструкторское бюро писало софт для систем управления двигателем. Сразу устанавливать софт на реальный двигатель нельзя — сначала его проверяют на модели, иначе первое же включение может привести к поломке. Этим занималась моя команда: мы делали модель двигателя на основе данных испытания и проверяли, будет ли имитация работать, не сломается ли что-нибудь.
На вход программе приходят данные вроде температуры и давления воздуха, положения рычага управления двигателем. А на выходе рассчитываются обороты, температура в камере сгорания, тяга. На такой модели мы отлаживали систему управления, которая потом работает на реальном двигателе. Конечно, модель никогда не будет такой же, как сам объект, но это хороший старт для тестов.
Кстати, когда твоя работа связана с самолетами — летать гораздо спокойнее.
Весь страх и волнение — от непонимания того, как устроен и работает самолет. Например, я люблю турбулентность: она никак не влияет на безопасность полета, ничем не грозит стабильности самолета. Единственное проявление — потряхивает в салоне. Конечно, нужно пристегнуться, но так даже веселее: есть ощущение полета.
Через несколько лет я устроилась инженером-программистом в компанию, которая занимается разработкой авиационных тренажеров. Ушла с первой работы, поскольку было подозрение, что после окончания университета меня не повысят в должности. Стала искать запасные варианты, нашла в Гугле список всех авиационных предприятий Питера, обошла все сайты в поисках вакансий. Отправила резюме — и мне перезвонили в течение часа. Я увольнялась первый раз в жизни, переговоры длились неделю: меня не хотели отпускать, спрашивали, что не так и как это исправить. Мне становилось жаль уходить, я звонила на новое место работы, а там меня окутывали розовым туманом перспектив. И все начиналось заново.
Там я занималась тренажерами, которые имитируют работу всех систем самолетов и вертолетов, например полет при разной погоде и даже тряску от турбулентности. Наша команда создавала софт для тренажера, его сердце — от модели турбулентности до индикаторов в кабине, которые должны меняться в зависимости от условий полета.
Чтобы имитировать полет, на тренажер устанавливают систему подвижности — сложное устройство, которое может поднимать и опускать, вращать и трясти кабину. Эту модель мы сначала тестируем на адекватность сами — не слишком ли сильно трясет, например, а потом приглашаем пилота, который может оценить, насколько ощущения похожи на настоящие. Пилоты очень любят эти эффекты и смеются, когда чувствуют происходящее с самолетом попой, а не видят на экранах.
Место работы
Я пришла сюда с некоторым понижением в должности: на предыдущем месте выполняла скорее менеджерские обязанности, а здесь снова разработчик. Но я не жалею. Компания молодая, энергичная, работать интересно. У нас хороший социальный пакет: ДМС, обеды, компенсация занятий языками и спортом. К твоему мнению всегда прислушиваются, чего бы оно ни касалось — организации рабочего процесса или того, какой кофе лучше закупить.
У нас несколько офисов в разных уголках мира, но почти вся софтовая команда находится в России, потому что российские программисты лучшие в мире по соотношению цены и качества.
По работе часто приходится общаться с иностранцами, это не всегда легко. Не только из-за возможного языкового барьера, но и из-за разного менталитета. Например, для нас абсолютно нормально задержаться на работе, чтобы закончить какую-то задачу. Иностранцы это не всегда понимают. Разница во времени тоже добавляет головной боли: бывали дни, когда я начинала работать по Питеру, а заканчивала — по Лондону.
Чтобы тестировать автомобили, у нас есть небольшой гараж в Санкт-Петербурге и большое предприятие в Великобритании. Тестировать на дорогах общего пользования без особого допуска нельзя, так что обычно это происходит на специальном полигоне или на территории, принадлежащей компании. Мы занимаемся несложными тестами, где надо убедиться, что все системы работают правильно, попереключать передачи, немного поездить.
Мой отдел отвечает за разработку систем управления. Современная жизнь напичкана электроникой, контроллерами, которые управляют всем — начиная от микроволновки и заканчивая ракетой. Наша команда создает системы, которые измеряют положение педалей тормоза и газа, ручки переключения передач, включают все системы в автомобиле и управляют оборудованием — тяговым мотором, вспомогательными насосами, преобразователями энергии.
Все проекты сложные и интересные, но мои любимые — это те, где результат виден лучше всего. Например, система управления автоматическими дверями. Со стороны выглядит очень просто: человек нажимает на кнопку, дверь открывается. На самом деле в этом задействовано огромное число механизмов и контроллеров.
Еще сейчас в моде экологичный транспорт. Самое интересное для меня — это автомобили на водородных ячейках.
Программист VS Инженер
Привет, Хабр. Я достаточно давно наблюдаю за ИТ рынком, но никогда ничего не писал. Это первая часть моей первой пасты, а посему прошу сильно не хейтить.
Таков путь
В своих статьях я хочу поделиться опытом поиска, обучения и интеграции интернов или джунов в продуктовую команду (не путать с фриланс-командами или типа того).
В первую очередь, нужно понимать, что всё написанное ниже сугубо моё личное, субъективное мнение. Оно основано на многолетних наблюдениях и опыте, в частности, опыте и наблюдениях последних пяти лет. Разумеется, не претендую на исключительность и не утверждаю, что оно является истиной в последней инстанции.
В первой части мы рассмотрим разницу между двумя гранями одной и той же сущности. А это, в свою очередь, поможет вам определиться с тем, кого вы хотите видеть в своей команде.
Рассмотрим два базовых варианта:
Программист
На самом деле, разницы между рядовым программистом нашего времени (вы ведь тоже видите эти бессовестно врущие рекламы «стань Java разработчиком за 3 месяца!»?) и аккаунт-менеджером Светой — не так уж и много. Разумеется, я не говорю обо всех-всех аккаунт-менеджерах или обо всех программистах. Я беру основную «массу», которая, судя по всему, будет хейтить этот пост (первая версия была намного жёстче). Поехали.
Программист — просто исполнитель
Для большинства в наше время программирование стало просто работой. Да, самой, что ни на есть, простой работой, что, впрочем, и неудивительно; и объявления про курсы «Java за 3 месяца» тому прямое доказательство.
Программист может писать, а может не писать.
Он будет делать ваши фичи, задавать минимум вопросов, или напротив, максимум (про таких я расскажу в следующей части).
Программист редко задумывается о трендах, новшествах. Он пишет так, как рекомендуют топы (зачастую) или как советуют топовые дев-блоггеры. Я, к примеру, совсем не понимаю, почему у Facebook столь отвратная, нелогичная и запутанная организация фронта, и почему это модно. Вот, хоть карму мне уроните, но не понимаю.
Программистом может стать каждый!
К сожалению, это горькие реалии нашего времени.
С одной стороны, это круто! Прогресс не стоит на месте, человечество развивается. А с другой (девочки из HR агенств меня поймут), рынок перенасыщен некомпетентными или низкоквалифицированными кадрами!
Да, он в принципе перенасыщен, ценники стали выравниваться. Безумных вакансий, где компании ищут джунов за ₽100к, не осталось. По крайней мере, я таких давно не наблюдаю. Лиды всё чаще стоят до ₽250к, ну и т.д.
Найти программиста просто
Это действительно так, но, нужен ли вам «такой программист»? Сейчас если взять среднестатистического frontend разработчика, он безусловно пройдёт собеседование, так как каналы типа WebDev публикуют вопросы с собесов разных компаний и, разумеется, ответы на них, а на ютьюбе шарят гайды по всяким штукам типа замыканий, промисов, коллбеков и прочих «нужных» штук.
На выходе мы получим фронтендера, который за месяц научился всему тому, чему обычно учат на курсах до полугода, а что на самом деле?
На самом деле получается картина маслом: разраб не понимает базовых принципов веб-разработки (DOM, CSS Flow Layout, HTML 5 API, es6+, immutability, etc), он делает так «как показывали в том видосике». Или делает по принципу «я вам тут по доке писал…норм же?»
Кому нужен программист?
Безусловно, такие кадры тоже имеют определённую ценность.
Кому они могут быть полезны в первую очередь?
Инженер
Как правило, бóльшую часть жизни посвящают саморазвитию и учению.
Глубокий анализ
Инженеры разберут ваше легаси на атомы, найдут узкие места, предложат пути решения, если инженер с большим опытом, то он и команду в состоянии подобрать при наличии HR агенства или вообще в одиночку.
Ему не нужно ТЗ, так как знает, что это бесполезная трата времени, а декомпозицию и постановку тасок проще проводить непосредственно знакомясь с требованиями по входу в проект.
Сперва анализ требований, потом проектирование, уже в конце разработка. Да, именно так и в таком порядке. По большому счёту, соотношение потраченного времени распределяется подобным образом: 40/40/20, ну, само собой ±.
Применение мощных практик
Применение сложных практик тоже является ключевой фишкой, ведь если спросить рядового разработчика, что он знает про *DD, с бóльшей долей вероятности дать внятного ответа он не сможет, с инженерами иначе. Код зачастую пишется через TDD, планирование флоу работы над продуктом из клиента посредством набора практик из BDD, проектирование продукта через DDD.
Качество кода зачастую на порядок выше, чем у программистов. Пока не стало модно использовать линтеры и тайпчекеры всем было плевать как писать и для чего писать, сейчас конечно всё стало несколько иначе, но тенденции не сильно изменились: чистота, читабельность, масштабируемость, модульность кода наёмных разработчиков по-прежнему оставляет желать лучшего.
Кому нужен инженер?
И что теперь?
В следующей части мы рассмотрим несколько вариантов привлечения людей в вашу команду, в зависимости от вашего выбора (программист или инженер). Рассмотрим весь процесс поиска. Варианты автоматизации процесса. Что делать если откликов очень мало или наоборот очень много. А самое главное — каким должно быть эффективное тестовое задание для ваших будущих товарищей по клавиатуре.
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 мудрых пунктов. Если согласны или не согласны с мыслями в статье, или если есть, что добавить и чем поделиться — пишите в комментариях.