Почему программисты снова становятся инженерами — вице-президент Parallels рассказал об окончании «эры айтишников»

Некоторое время назад Look at me поделился дельными мыслями одного человека по поводу того, что широта знаний вновь становится важнее узкой специализации. Мы не могли пройти мимо и подготовили для вас выжимку самого интересного.

Рассказывает Максим Кузькин, вице-президент Parallels и главный архитектор продуктов Odin — бренда, под которым реализуются решения для дата-центров от лица Parallels.

Я в своей работе никогда не пользуюсь словом «программист». Когда я обращаюсь к людям своей профессии, я всегда стараюсь называть их инженерами. Сугубо узкая формулировка «программист» — точно так же, как и «тестер», например, — плохо отражает специфику нашей профессии. И чем дальше, тем хуже эта формулировка работает.

Возьмём такой пример. В классическом понимании есть «программисты», «тестеры», «менеджеры проекта» и другие специализации. С точки зрения ролей это разделение имеет смысл, ведь исторически любое разделение труда возникало из-за того, что средства ведения труда требовали особых знаний. Грубо говоря, чтобы стать тестером, мне надо изучить определённые инструменты — как и инженеру, который разрабатывает под определённую платформу.

По мере того, как течёт время, порог входа становится ниже. Например, в Microsoft сейчас нет такой роли, как «тестер» — у них есть developer in test (Специалист, который пишет программы, тестирующие другие программы. — Прим. ред.). При этом всех людей, которые занимаются разработкой, называют инженерами программного обеспечения (software engineers), просто они задействованы в немного разных сферах. Сейчас освоить инструменты стало настолько просто, что границы между конкретными специализациями стираются. В будущем вряд ли останется разделение, скажем, на JavaScript-программиста, Python-программиста и .NET-программиста — как и разделение между фронтендом и бэкэндом.

Знать язык программирования недостаточно

Всё важнее становится понимание технологического стэка — технологий, которые лежат в основе того, что использует человек. Встречаются люди, которые программируют на JavaScript, и на вопрос, как работает протокол TCP, они отвечают, что это слишком низкоуровневое и они не хотят с таким разбираться. Вот это страшно: исходя из моего опыта, понимание базовых принципов, которые лежат под тем, что ты используешь, очень важно. До поры до времени это может не сказываться, но, как правило, зашоренность в одной технологии не позволяет делать нормальные решения по всему технологическому стэку.

Вот пример того, что я имею в виду под технологическим стэком в случае с браузером. Есть JavaScript, есть представление о том, что такое HTML, протокол HTTP. JavaScript-программисту никуда от этого не деться, он должен его понимать — как и то, откуда взялись правила изоляции и кроссдоменной безопасности, как работает протокол SSL, как работает безопасность, основанная на сертификатах. Дальше, если мы идём в бэкэнд, то человек обязательно должен понимать организацию структур данных. В любом более-менее сложном приложении, когда речь заходит о визуальном отображении сложных структур данных, объединении таблиц и организации выборок, интерфейс и бэкэнд становятся непосредственно связаны. Очень сложно сделать эффективное приложение, если люди, которые делают интерфейс, не понимают хотя бы базовых проблем, о которых нужно думать в бэкэнде: шардинг, организация данных, структура запросов. И наоборот: очень сложно сделать правильный API в бэкэнде, правильно предусмотреть возможность шардинга и горизонтального масштабирования, если человек, который пишет бэкэнд, не понимает проблем, которые есть на фронтенде.

Грань между дизайнерами и инженерами останется

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

Сейчас, если я хочу сделать хороший сайт, то, наверное, имеет смысл нанять JavaScript-программиста. С другой стороны, я могу пойти на Wix или другой билдер и сделать там сайт, близкий к тому, что мне нужно. Мне кажется, что этот тренд продолжится.

Инженерам нужны и естественные, и гуманитарные науки

Чем дальше, тем более сторонними оказываются затрагиваемые сферы. Возьмите хотя бы развитие компании Apple, которое во многом было продиктовано увлечением Стива Джобса и людей, которые его окружали, гуманитарными науками: в частности, маниакальной любовью к красивым шрифтам и иероглифам. Все запоминающиеся изменения в информационных технологиях очень часто происходят на стыке наук. Это почти всегда синтез, потому что IT — просто способ представления и обработки информации, который лишается смысла в вакууме. Так, сложно назвать «программистами» людей, которые придумали графический пользовательский интерфейс, — это как сказать, что iPhone стал успешен благодаря только «железу» или только «софту».

Ещё 10 лет назад фронтенд-разработчику казалась бы дикой мысль о том, что нужно прочитать книги о восприятии и психологии людей. Сейчас это уже само собой разумеющееся: если человек разрабатывает сайты, то он прочитал все возможные книги по UX, UI, тому, какой объём информации люди способны воспринимать, как её лучше подавать. И это ведь смежная технология, пришедшая к нам чуть ли не из медицины — и то же самое будет касаться физики, химии и биологии.

Получайте базовые знания, которые не устаревают

Что бы вы ни начинали учить сейчас, через 5—10 лет оно устареет. А потому, как бы глупо это ни звучало, нужно учиться учиться. Если есть запас времени, лучше посвятить его тому, как работает то, чем вы собираетесь пользоваться, — начиная от курса физики и математики. Без базовых знаний пресловутым умением учиться сложно воспользоваться. Фазовый переход на следующий уровень всегда намного проще для людей, которые понимают, как работают компьютеры на физическом уровне, — пускай они даже этим не пользуются и работают на гораздо более высокоуровневых языках. Они не просто пользуются автомобилем и включают передачи, а понимают, как автомобиль работает. Когда эта штука становится чем-то вроде электромобиля, им сделать этот переход намного проще.

Если мы ставим на стратегию долгосрочного развития и роста, то важнее не прикладные, а фундаментальные знания. Не банальное представление, как послать GET-запрос, а понимание HTTP-протокола: почему он был так сделан, какие идеи в него были заложены. Когда мы перейдём на условный SPDY, вы сможете понять, как произошло это изменение. Нужно общее понимание того, когда эти запросы посланы на сервер, как работает процессор, который делает эти вычисления на сервере. Слишком углубляться во всё не надо, но для широты знаний нужно понимать, как это всё работает.