В продолжение предыдущего поста ☝️

Ни для кого не секрет, что в веб-разработку и другие IT-профессии манит немало людей, которых компьютеры волнуют просто как средство заработка. А IT-индустрия — это как завод (или офис), но где вместо условных гаечного ключа и гаек (или документов и принтера) есть клавиатура и средства разработки.

И правда, современный IT — это как завод, на котором сейчас очень, как говорится, «не хватает рук». Чтобы насытить рынок нужными специалистами, технологии стремятся к тому, чтобы создавать приложения можно было бы так же, как собирать корпусную мебель. И я говорю не про сложность труда, потому что трудиться всегда сложно, а про сам процесс: можно не заморачиваться, собирать мебель из готовых мебельных щитов чётко по инструкции.

В процессе сборки мебели в фоновом режиме можно думать о чём-нибудь отвлечённом. То есть, рутина не так сильно донимает. В процессе разработки обычного фронтенд-приложения на React, не смотря на то, что субъективно 90% задач — самая что ни на есть рутина, думать о чём-то постороннем «в фоне» не получится: пока ещё разработка требует мыслительной деятельности, а думать о двух вещах одновременно мы не умеем. Соответственно, в рабочее время нужно посвящать всю мозговую активность задаче. Часто даже музыка на фоне отвлекает.

Но что если разработка или сборка чего-либо перестали быть интересными? Чему психика будет сопротивляться сильнее?

а) Неинтересное занятие, во время которого можно подумать о чём-то более приятном и интересном;
б) Неинтересное занятие, во время которого можно думать только об этом неинтересном занятии.

Даже если work-life баланс прекрасно выстроен, долгие вечера проходят с семьёй и/или за любимым хобби, а в выходные у вас сплошные сноуборды и купание в море, вариант «а» всегда будет более комфортным для психики, чем вариант «б». Если вы не любите IT, вы всегда будете тяготеть к какому-то другому занятию, в котором будет больше времени для приятных мыслей. Отсутствие интереса к IT так же замедляет обучение и профессиональный рост, таким сотрудникам не достаётся интересных задач, где есть место исследованию и постижению чего-то нового, потому что они достаются тем, кто хочет погружаться в IT всё больше и больше. В поиске интересных задач может начаться частая смена работодателей/проектов. Но интересных задач всё меньше и меньше. И очень не хочется, чтобы заканчивались выходные и начинался понедельник. Потому что в понедельник придётся либо 8 часов заставлять себя думать о неинтересных вещах, либо прокрастинировать, уделяя работе пару часов в день, а потом ловить на себе не самые приятные взгляды коллег. Да, в IT рады и таким работникам, поскольку «не хватает рук». Но сами работники оказываются заложниками высокого спроса и, соответственно, высоких зарплат.

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

Когда я только начал работать в Linux, в настройках переключения раскладки клавиатуры я увидел опцию «Переключать по Caps Lock». Для меня, как для пользователя Windows, это показалось необычным, и раз уж я решил перейти на Linux, то начал пробовать всё необычное. С той поры 10 лет я переключал раскладку нажатием Caps Lock, что гораздо проще, чем нажатие любого сочетания клавиш. Когда мне приходилось работать не за своим компьютером, где был настроен другой способ переключения раскладки, мне было ощутимо неудобно.

10 лет у меня оставалась ещё одна проблема: я часто начинал набирать текст не на том языке, на котором хотел. Для того, чтобы «предсказать» на каком языке сейчас будет набран текст, необходимо было смотреть на индикатор Caps Lock на клавиатуре (да, в Линуксе можно настроить, чтобы он светился, например, тогда, когда включена русская раскладка) или на соответствующий значок в интерфейсе окружения рабочего стола. Это делать лень и это отнимает время.

Год назад я пожаловался на эту проблему своему коллеге-девопсу, который много работает в Линуксе. Он посоветовал мне использовать следующую комбинацию сочетаний клавиш:

— Caps Lock — для переключения на английскую раскладку;
— Shift + Caps Lock — для переключения на русскую (в моём случае) раскладку.

Принцип в том, что больше не нужно смотреть на то, какая раскладка сейчас активна: если вам нужно печатать на русском, вы нажимаете Shift + Caps Lock, если нужно на английском — просто Caps Lock.

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

UPD1: в случае, если раксладок больше двух, это методика бесполезна.
UPD2: конечно, какое-то время уйдёт на привыкание, у меня оно заняло чуть больше месяца, но я не пожалел.

Чем мне нравятся новогодние выходные, так это отсутствием тонны всевозможной рабочей переписки. Даже когда я работал на фрилансе, где выходные и праздники не повод не писать по рабочим вопросам, в новогодние выходные меня никто не тревожил. Такой «новогодний» уровень свободы от кучи рабочих чатов и email'ов труднодостижим даже в период отпуска.

Единственное исключение — рекрутеры, занимающиеся хантингом через LinkedIn, они никогда не дремлют. Про LinkedIn ходит шутка, что это соцсеть, где девушки первыми пишут парням, а те их игнорят. У меня там в статусе стоит «НЕ ищу работу», но даже это не всех останавливает, прямо так и начинают сообщение: «видела, что вы не в поиске, но...». Ответив сегодня отказом на очередное предложение рассмотреть вакансию (да, стараюсь не игнорить), задумался: а зачем мне вообще нужен там аккаунт?

Лет 10 назад в русскоговорящем интернете среди людей, чья работа связана с IT и интернетом, стало модным быть зарегистрированным в этой соцсети. Потому что это была серьёзная площадка для «профессионалов». Но из-за слабой ориентированности на русскоговорящего пользователя там совершенно нечем было заняться, кроме как, добавлять друг друга в друзья. Непосредственно профессиональное общение шло в других местах. В этом плане преуспел Фейсбук, где стало уместно и нужно говорить о работе.

После того как Роскомнадзор «заблокировал» LinkedIn на территории РФ, пользоваться соцсетью стало ещё бессмысленнее: часть пользователей ушла и не вернулась. Смотрю сейчас ленту в LinkedIn и понимаю, что её невозможно читать: унылые мемы вперемешку с объявлениями о вакансиях и неинтересной корпоративной повесткой. В этом плане мне нравится Telegram: много качественных каналов с интересной, иногда просто уникальной информацией, читаешь только то, что хочешь, в нужном объёме и в хронологическом порядке.

Начал думать о том, чтобы закрыть аккаунт в LinkedIn и задаюсь вопросом: вдруг он мне ещё понадобится? Трудно представить для чего, если честно. Даже прямое своё назначение он не выполняет: все свои работы и занятости я находил где угодно, кроме LinkedIn. Всё что мне даёт эта соцсеть — это поток предложений о работе, которые мне не нужны. А когда они мне нужны, я просто переключаю видимость резюме на hh.ru.

В 2008 году, когда я перешёл из десктоп-разработки в веб-разработку, вопросом выбора языка для бэкэнда задаваться не пришлось: судя по вакансиям и проектам на фрилансе, абсолютным лидером был PHP.

В 2018 году я перестал использовать PHP, когда увидел, что Node.js и TypeScript стали достаточно хороши для того, чтобы в моём инструментарии заменить PHP, потому что писать и бэкэнд и фронтенд на одном языке очень удобно, а я за удобство и скорость разработки.

С теплотой вспоминаю время, когда я прогал на пыхе. У этого языка хватает недостатков, но у него есть немало достоинств, и главное из них в том, что он вдохновляет создавать свои проекты, фреймворки, CMS. Почему-то на этом языке очень интересно делать что-то своё и для себя. Кроме того, что я периодически пилил на PHP стартапы, последние два года разработки на этом языке я увлекался разработкой собственного фреймворка.

Почти всё своё свободное время я проводил за допиливанием и перепиливанием этого фреймворка, я сделал свою реализацию Dependency injection, ORM, контроллеров, в общем, делал полноценный свой велосипед. Но самое важное заключается в том, что мотивировала меня не какая-то материальная потребность, не жажда признания, мотивировал меня исключительно исследовательский интерес. И это прекрасно!

Я уверен, что схожие чувства испытывали создатели многочисленных крутых фреймворков и CMS. Благодаря этим инструментам и самому PHP стала возможна разработка огромного числа сайтов и сервисов, которые мы знаем, которые не появились, если бы их разработка оказалась сложнее и дороже.

В прошлом посте ☝️ я упомянул момент, когда перестал использовать на бэке PHP и перешёл на Node.js. Переключаться с одной технологии на другую — обычная практика, не вызывающая сложностей у разработчиков. Однако в карьерном плане такой переход может быть болезненным, поскольку работодатель настороженно относится к недостатку опыта работы с конкретной технологией, отказывая в высокой зарплате даже опытным программистам. Например, если у вас опыт разработки на Ruby 10 лет и вы привыкли получать N рублей, то при переходе на Go, в котором у вас опыта без году неделя, вы сможете рассчитывать в лучшем случае на мидловую зарплату N/2.

Расскажу о своём опыте, позволившем избежать просадки по зарплате. Моё предыдущее место работы было в компании, предоставляющей облачные услуги корпоративным клиентам. Им нужна была панель управления, позволяющая отображать услуги (виртуальные машины, хранилки, сети и т.п.), считать сколько услуг каким клиентом было потреблено, генерировать отчёты, в том числе сводные, и счета. Стороннее коробочное решение не подходило из-за тонкостей расчётов для разных клиентов. Когда я был на собеседовании, я понял, что в организации я буду первым и пока единственным программистом. Это несколько расходилось с моими ожиданиями: я хотел работать в компании, которая привыкла работать с разработчиками (фреш-бары, печеньки, плейстейшины и вот это вот всё), и хотел вариться среди других программистов, чтобы перенимать опыт. Но на другой чаше весов была амбициозная задача, решение которой, включая архитектурные вопросы, полностью доверялось мне. И вторая чаша весов перевесила просто потому, что сулила мне много опыта.

После восьми месяцев разработки закончились первоочередные задачи и у меня появилось время выплатить техдолг, которого накопилось немало, поскольку я торопился реализовать основной функционал системы, чтобы скорее показать её пользу для бизнеса.

Я решил начать с бэкэнда-монолита, который был написан на PHP. Ознакомившись с обновлёнными стандартами JavaScript, новой версией Node.js, npm-библиотеками, я понял, что на этом стеке можно будет реализовать бэкэнд архитектурно схожий с имеющейся реализацией на PHP. Поскольку переписать весь монолит разом задача трудоёмкая и в процессе её решения нужно будет делать двойную работу: все фиксы и фичи нужно будет писать и на PHP и на JS, я решил применить другой подход. Я сделал список всех роутов, которые обрабатывал бэкэнд, и в рамках выплаты техдолга, но по большей части в своё свободное время брал наиболее интересный мне роут и переписывал его на Node.js. Я больше не вносил изменения в PHP-код, если правки нужно было делать для роута, который ещё не был реализован на Node.js, я его реализовывал вместе с правками. На проде nginx был настроен таким образом, чтобы старые роуты обрабатывалась PHP, а новые Node.js. Процесс такого переписывания бэка занял меньше месяца.

Немного позднее я переписал фронт с jQuery на Vue.js, а спустя полтора года, в рамках крупного обновления UI, мы уже использовали React. До этого я не имел значимого опыта разработки с использованием реактивных фреймворков и библиотек для фронта.

Таким образом, я безболезненно, с пользой для себя и для работодателя получил коммерческий опыт разработки на новом стэке, включая Vue.js и React, что позволило мне на следующем месте работы не потерять в зарплате, а существенно её увеличить.

Написал статью для блога Гикбрейнс, в которой постарался максимально доступным языком описать принцип работы блокчейна: https://geekbrains.ru/posts/kak-rabotaet-tekhnologiya-blokchejn-prostymi-slovami

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

Очевидно, что эту фразу можно применить почти к любому ремеслу и профессии, и очень уж хорошо она ложится на программирование. Но вот чего точно не может быть в разработке в самом начале, так это «просто», поэтому я бы убрал первый пункт: «Сначала программист пишет сложно и плохо. Потом сложно и хорошо. И только потом просто и хорошо».

В таком виде фраза гармонично ложится на общепринятое деление специалистов в IT по уровню развития джун-мидл-сеньор.

Когда мне было 8 лет и я учился во втором классе школы, нам выдали абонементы в детскую библиотеку. К чтению художественной литературы я относился с интересом, но больше всего меня интересовали детский научпоп и техническая литература. Особенно я любил компьютерные журналы, открывавшие удивительный мир, к которому я относился с больши́м любопытством и придыханием.

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

Если я о чём-то в жизни всерьёз мечтал, то это была детская мечта о ноутбуке, на котором я бы постоянно что-то делал. Но в 1996 году компьютер был не настолько доступен, чтобы родители могли купить его просто потому, что ребёнок захотел свой комп.

Читайте продолжение на Хабре: https://habr.com/ru/post/537048/#habracut

Сейчас, когда прошёл уже год с момента перехода большинства трудящихся в IT-отрасли на удалёнку, народ начинает делать какие-то серьёзные выводы о том, как удалёнка повлияла на бизнес, на людей, кому она зашла, а кому нет. Я же просто поделюсь своим мнением и наблюдениями.

Сам я ветеран удалёнки, проработал в таком формате примерно 7 лет и, вероятно, поэтому не люблю её. Одной из причин, по которой я 5 лет назад переехал в Москву, было как раз желание работать в офисе. Я воспринимаю работу как самую важную часть своей жизни, поэтому стремлюсь совмещать полезное с приятным. Приятным в данном случае является живое общение с коллегами, эмоции, шутки, истории, совместный отдых, вот это всё. Если я не буду иметь возможности ходить в офис, я буду месяцами безвылазно сидеть дома, отчего у меня начинаются проблемы с социализацией и я буквально засыпаю и просыпаюсь с компьютером в обнимку.

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

От руководителя одной известной ed-tech компании я услышал интересное сравнение. Онлайн-работа — это как онлайн-жена, с которой можно общаться, ругаться, смотреть вместе фильмы, делить бюджет и даже заниматься сексом (но виртуальным). Я склонен согласиться с этим, потому что офисная работа в эмоциональном плане качественно отличается от удалённой работы. На удалёнке даже заговорить трудно с кем-то, потому что перед любым созвоном принято спрашивать «я позвоню?», в то время как в офисе всегда кто-то с кем-то общается, часто непринуждённо, и не обязательно по рабочим вопросам.

Понятно что офисная жизнь уже не будет прежней, большинство компаний, если и не продолжат удалённый формат работы, то сделают что-то гибридное, где в офис можно будет приходить по желанию или нужно будет приходить в определённые дни. Но я уверен, что офисы IT-компаний не опустеют, потому что за последний год в те дни, когда мне счастливилось работать в офисе, я там был не один и далеко не один: всегда были десятки человек, которые так же как и я приходили в офис, чтобы получить удовольствие от живого общения со своими коллегами, чтобы напомнить себе, что приятели и друзья с работы — это не пиксели на экране, а живые люди.

Из трёх популярных реактивных решений для разработки фронтенда, Angular, Vue.js и React, последний мне нравится больше всего, этой мой любимый инструмент. Формально, в отличие от ангуляра и вью, реакт является библиотекой, а не фреймворком, потому что его базовая поставка не содержит решения для роутинга и управления состоянием, а также не предлагает разработчику какую-то определённую структуру проекта. Из-за этого при сравнении реакта с конкурентами приходится для их общего обозначения придумывать замысловатые словосочетания, как в начале этого абзаца, вместо того, чтобы просто говорить «по сравнению с другими фреймворками...»

Так вот, «по сравнению с другими фреймворками», React является самым популярным (посмотрите после этого поста статистику Google Trends за последние три года 👇). Полагаю популярность его изначально обоснована простотой и предсказуемостью поведения.

Для справки: первая версия AngularJS была выпущена в 2010 году, в 2013 году появился React, а в 2014 Vue.js.

Если говорить только про простоту разработки и порог входа, то Vue.js в этом плане лидирует. Помню как за один рабочий день, не имея опыта разработки на реактивных фреймворках, выбрав вью по отзывам за его низкий порог входа, запилил фронтенд для простой админки. Позже, когда я знакомился с React, мне понадобилось больше времени для того, чтобы «влиться». Но если говорить про предсказуемость поведения, то Vue.js показывает не лучшую игру. Из-за того, что он предоставляет разработчику много удобных инструментов (например, v-model, watchers и т.п.) с ростом проекта растёт вероятность «выстрелить себе в ногу» и потратить часы, если не целый день, наткнувшись на очередное цикличное обновление состояния или наоборот отсутствие обновления там, где оно ожидалось. Признаюсь, после полутора лет разработки на вью, я так и не научился чувствовать полную уверенность в том, что я знаю, как на самом деле работает моё приложение. Потому я и перешёл на React.

При этом я с интересом отношусь ко второй версии Angular. По предсказуемости поведения ангуляр однозначный лидер. Код, написанный для него, выглядит фундаментально и архитектурно красиво, а я ценитель хорошей архитектуры. Тем не менее по сложности разработки Angular перегибает палку, и то, что на вью можно сделать за полчаса, на реакте за час, на ангуляре потребует два часа. Я за скорость разработки, поэтому не выбираю ангуляр. Но всегда говорю спасибо Angular за популяризацию TypeScript.

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

Но настоящая киллер-фича React'а, которой он обзавёлся не так давно, это хуки. Когда я, приверженец ООП, узнал, что разработчики реакта в новых проектах предлагают использовать функциональные компоненты, а компоненты, основанные на классах, больше не будут развиваться, я расстроился. Понимая, что специалист, из какой бы профессии он ни был, не может позволить себе закрывать глаза на новые веяния (иначе он рискует потерять ликвидность на рынке труда и получить репутацию чувака, который когда-то был крут), я решил переписать один из своих pet-проектов на хуки и обнаружил, что кодовая база сократилась в полтора раза при сохранении функционала. «Круто», — подумал я и стал писать на hooks на работе. А вторым открытием стало то, что разработка стала быстрее.

Однако, использование хуков увеличивает вероятность «выстрелить себе в ногу», заставляя порой использовать неочивидные решения для проблем, которые на классах решались просто. Тем не менее я нахожу разработку с использованием hooks более творческой и не раз слышал такое же мнение от коллег.

Один из самых больших разбросов зарплат программистов в России (полагаю, и в странах СНГ тоже) я наблюдаю в C++ разработке. На первый взгляд это должно показаться странным, потому что это далеко не самый простой язык, не только сама возможность использования, но и грамотное применение которого требует наличия фундаментальных знаний в информатике. И такое требование подразумевает, что нижний порог зарплат никак не может начинаться с 600 долларов.

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

Однако, как видно на первом скриншоте, за 75 тысяч рублей в месяц предлагается стать разработчиком бортовых систем космических аппаратов. Это очень интересная работа, на которой я бы работал с большим удовольствием. Но и сама по себе разработка приложений на плюсах весьма интересна, независимо от задачи. В инженерном плане управление памятью, разработка и оптимизация сложных алгоритмов — задачи очень интересные, в решении которых можно найти большой простор для творчества. Это гораздо интереснее того, чем занимается большинство современных разработчиков: клепанием веб-форм на фронте и перекладыванием JSON-ов на бэке.

Потому мы и наблюдаем такой разброс в зарплатах специалистов по C++: программировать на крестах (так ещё называет плюсы) само по себе интересно, а ещё есть крутые задачи, над которыми программеры согласны работать даже за маленькие деньги. Разве станет работодатель платить много, если итак найдутся желающие? Я лично знаю гениального программиста, который хорошо знает английский и, потратив время на прокачку своего резюме, мог бы зарабатывать 10 тысяч евро, решая повседневные задачи бизнеса, но вместо этого пишет на Си++ и работает только над тем, что ему интересно. Хорошо если получает при этом хотя бы 100 тысяч рублей.

Разумеется, российская специфика финансирования науки и ряда отраслей ещё больше способствует появлению вакансий с низкими для рынка зарплатами, но интереснейшими задачами. А некоторая отстранёность от материальных вопросов бытия, свойственная гениальным программистам, только усугубляет ситуацию, делая такие вакансии востребованными на рынке труда.

В одном из развлекательных пабликов айтишной тематики увидел такой пост:

Всегда работайте над двумя проектами одновременно. Таким образом, занимаясь проектом А, вы сможете прокрастинировать, переключаясь на проект Б. А когда устанете от проекта Б, сможете прокрастинировать, работая над проектом А. В результате вы сможете прокрастинировать всё время, а производительность увеличится в два раза.

Несмотря на то, что в этом высказывании есть ирония, в моей профессиональной деятельности такой подход действительно помогает. С той лишь разницей, что поскольку у меня постоянная, а не попроектная работа, к основной работе я люблю добавлять несколько смежных активностей. Сейчас это деканство в GeekBrains.

Переключение на другую, менее объёмную и несложную задачу помогает расслабиться и отдохнуть, в результате увеличивается производительность. Опять же, когда одно занятие утомляет и хочется отвлечься, выручает возможность переключиться на что-то другое, а не заниматься бесполезной для себя и собственного кошелька прокрастинацией.

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

Есть такое понятие «Принцип Питера», звучит этот принцип так: «В иерархической системе каждый индивидуум имеет тенденцию подняться до уровня своей некомпетентности». Человек, работающий в компании, будет стараться повышаться в должности до тех пор, пока не займёт место, на котором он окажется не в состоянии так же эффективно выполнять свои обязанности, как он делал до этого. Не сможет развиваться, рост остановится, и на этом месте он, вероятно, досидит до пенсии.

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

В начале своей трудовой деятельности я планировал, что непосредственно программированием буду зарабатывать лет до 30, а потом уйду в руководители. В моей профессиональной карьере мне предоставлялась возможность примерить на себя роль руководителя, и каждый раз я понимал, что это явно не то, чем хотелось бы заниматься. Окончательно в этом убедиться пришлось два года назад, став начальником небольшого отдела разработки. Я понял, что плохо управляюсь с людьми, мне сложно делегировать задачи, я слишком требователен, не умею нивелировать недостатки сотрудников и извлекать пользу из достоинств. Кроме того, я обнаружил, что обязанности по написанию кода меня радовали и вдохновляли, а необходимость выполнять управленческие функции демотивировала.

Тогда я наконец-то понял, что мой путь — это путь инженера, а не руководителя. Быть крутым разработчиком лучше, чем быть посредственным начальником. Лучше для всех, не только для меня. Тем более, вступив на путь руководителя, нужно будет идти дальше, а дальше уровень некомпетентности будет только расти.

Да, карьерный рост — это самый эффективный способ увеличить свой доход. Но стоит ли ради денег отказывать себе в такой роскоши, как любимая работа? Я знаю немало успешных в карьере и бизнесе людей. Но тех, кто очень любит свою профессию, я знаю единицы. Очевидно, любовь к профессии бо́льшая ценность, чем доход от неё.

Может показаться, что я успокаиваю и оправдываю себя, но это не так: мне хватает денег на текущие нужды и остаётся для того, чтобы откладывать, но моё начальство, разумеется, всегда получало и получает больше. Я просто хочу сказать, что быть хорошим специалистом гораздо лучше, чем быть посредственным. И для этого приходится принимать подчас непростые решения, оказывающие большое влияние на собственную судьбу.

В коммерческой разработке важен баланс между скоростью выпуска релиза и сильной, масштабируемой архитектурой продукта. Соответственно, есть два противоборствующих лагеря: менеджмент, который хочет «быстро» и разработчики, которые хотят «качественно».

В этом вопросе я тяготею к позиции менеджмента. Но не потому, что меня интересуют показатели эффективности разработки, а потому что я прекрасно понимаю, что смысл работы инженера в том, чтобы создавать что-то, что приносит пользу людям. А не в том, чтобы это было архитектурно красиво и технологически круто. И чем раньше пользователь получит продукт, тем ценнее будет труд программиста, который над ним работал.

Сам я обожаю городить абстракции, пилить велосипеды, да и вообще программирование для меня — это вещь сама в себе, где мне важен процесс, а не результат. Но я позволяю себе это делать, только когда работаю над своими проектами, что является основной причиной того, почему до публикации моего очередного проекта дело просто не доходит 🙂

Когда я работаю на компанию или выполняю заказ, я понимаю, что главным становится не моё удовольствие от разработки, а соблюдение интересов заказчика и конечного пользователя. И вот это понимание, судя по моим наблюдениям, доступно не всем товарищам по профессии. В моей практике есть один очень показательный пример:

Необходимо было разработать минимально жизнеспособное приложение для удобной работы с заявками. С примитивнейшим механизмом авторизации, потому что приложение всё-равно пока будет работать в локальной сети. По сути нужен функционал выборки из базы, настройки колонок, фильтрации по произвольным полям. Если приложение зайдёт заказчику, можно будет дальше работать над развитием. Самая большая сложность в том, что в таблице около сотни колонок с различными типами данных, соответственно, нужна какая-то универсализация.

Вместо того чтобы реализовать минимум абстракций и сделать MVP за несколько дней, разработчик работает над защитой авторизации от перебора, CSRF, архитектурой бэкэнда, универсальными механизмами построения запросов, отображения данных, которые способны решить задачу выборки, сортировки и фильтрации каких угодно данных из каких угодно баз данных. На попытки объяснить, что на данном этапе это не нужно, что заказчику может попросту не понадобиться этот продукт, программист говорит, что плохие решения и костыли он не делает в принципе. По прошествии месяца активнейшей разработки, когда разработчик чуть ли не ночевал на работе, кодовая база проекта насчитывает больше 15 тысяч строк отличного кода, который никому не нужен, кроме автора, потому что заказчик за это время потерял интерес к продукту, так его и не увидев.

Хорошая архитектура — это синоним качества программного продукта. Чем лучше код, чем качественнее абстракции, тем проще автоматическое тестирование и тем меньше костылей нужно внедрять для реализации нового функционала. Поэтому если сосредоточиться исключительно на скорости выпуска, то качество кода может стать настолько плохим, что продукт не взлетит из-за забагованности и низкой производительности. Чтобы такого не допустить, нужно тоже руководствоваться пользой для пользователя: в конце концов, какой смысл в раннем выпуске приложения, если им невозможно пользоваться по назначению? Но зачастую даже продукт с косяками предпочтительнее, чем никакой.

Лучшее всегда враг хорошего.

На этой неделе на Хабре появился перевод статьи «Programming is hard». Хороший перевод, рекомендую прочитать. Но если говорить кратко, лейтмотив статьи такой: слишком часто популяризаторы IT стали говорить, что программирование — это просто, хотя в действительности оно простое только в начале. И что не стоит завлекать людей в профессию этим обманом.

Скажу очевидную вещь: большинство профессий кажутся простыми вначале. Скажем, научиться сносно играть одной рукой токкату Баха на пианино, не имея никакого музыкального бэкграунда, можно за месяц. На понимание нот в связке с клавиатурой уйдёт ещё месяц. Через полгода занятий, в глазах людей, не умеющих играть ни на чём, вы будете выглядеть музыкантом-любителем. И это просто! Но в глазах профессиональных пианистов вы будете оставаться новичком ещё очень долго, а если не будете стараться, то всегда.

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

Но с одной поправкой: в IT можно зарабатывать хорошие деньги, имея весьма слабые навыки и отсутствие понимания некоторых базовых вещей. И в этом действительно помогает «Stack Overflow». Но если не прилагать усилий для роста, не стараться понять суть вещей, с которыми работаешь, не тратить ночи напролёт на изучение языка, библиотек, фреймворков, то придётся нон-стопом страдать от синдрома самозванца, боясь разоблачения, и даже не надеяться на финансовый успех в профессии. А работа превратится в каторгу, как и любая другая нелюбимая работа, выполняемая за деньги, а не по любви. Сайт ebanoe.it (в РФ почему-то заблокирован РКН) процентов на 80 забит такими историями.

Тем не менее я не согласен с автором статьи и вот почему: на рынке настолько большая потребность в разработчиках, что нужны даже плохие программисты, причём в больших количествах. И если мы говорим про пользу для индустрии, то неважно, что люди приходят в профессию из-за того, что их обманули лёгкими деньгами, главное, что они приходят. Кроме того, их присутствие положительно сказывается на зарплате уже состоявшихся хороших специалистов — их становится меньше относительно общей массы разработчиков, соответственно растёт их ценность. А если учитывать, что из 100 человек, попавшихся на крючок маркетологов и популяризаторов, 10 человек действительно заинтересуются и полюбят профессию, а один станет программистом-звездой, игра тем более стоит свеч.

Недавно, создав очередной репозиторий на github.com, сделав первый коммит и попытавшись запушить ветку master, я обнаружил такое вот сообщение об ошибке 👇🏿

shibaon@shibaon-xps13:~/www/my/game01$ git push origin master
error: src refspec master does not match any
error: failed to push some refs to '[email protected]:otkiso/game01.git'

Я пользуюсь git с 2010-го года и эти действия делаю на автомате. Да и ветка master в новом репозитории есть всегда, если только её специально по какой-то загадочной причине не удалили. Так что «ошибки быть не может», — думал я.

Посидев пару минут в ступоре, я начал вспоминать давнишние уже новости о том, что в исходниках open-source проектов переименовывают master/slave на server/client, primary/secondary, primary/replica, main/secondary и т.д. Потом я вспомнил, что когда-то читал о том, что в git ветку master собираются переименовать в main. Команда git push origin main отработала без ошибок.

Вчера, читая на Википедии статью о Mozilla, я заметил, что слово gay там встречается три раза в контексте должности CEO, которую занимал Брендан Эйх (создатель JavaScript, на минуту). Брендан в 2008-м году выступал против легализации однополых браков и его за это шеймили, даже было создано движение по бойкотированию браузера Firefox. Но мне странно натыкаться на слова, относящиеся к сексуальным предпочтениям, в статье про IT компанию, не имеющую отношения ни к порноиндустрии, ни к дейтингам, ни даже к интернет-магазинам и продаже интимных товаров.

Недавно на Хабре читал статью «В защиту Ричарда Столлмана». Ричард посвятил свою жизнь популяризации и продвижению свободного программного обеспечения, в частности, Linux. Но за какое-то неосторожное высказывание его начали шеймить рад-феминистки и SJW-сообщество в целом.

Потом мне вспомнилась история о том, что Линус Торвалдс чуть не бросил руководство разработкой ядра Linux из-за того, что его обвинили в жёстком стиле общения. Этот человек внёс огромный вклад в создание той технологической цивилизации, в которой мы живём. Его программами, в частности, тем же git, пользуется буквально каждый программист на планете.

Можно долго приводить примеры того, как миллионы «борцов за социальную справедливость», которым просто нечем заняться, донимают людей, занятых развитием технологий и нашей цивилизации. Людей, которые и дали этим борцам главный их инструмент — интернет. Настораживает то, что эти примеры стали появляться чаще. Раньше я думал, что эта вся движуха где-то далеко за океаном и мне не мешает. Оказывается, начинает мешать: привычные команды в терминале перестают работать.

Я за то, чтобы все люди жили счастливо, никто никого не обижал. Мне жаль, что из-за нетерпимости и заблуждений пострадало очень много людей, в том числе выдающихся. Я считаю, что трансгуманизм, к которому мы обязательно придём через развитие технологий, позволит нам создать социально справедливое общество, в котором не будет насилия, физических и нравственных страданий. Но я не понимаю, как помогают этого достичь переименование master в main, и шейминг людей, создающих технологии. Тут кстати такая фраза: если не можете помочь, то хотя бы не мешайте.