Одна из моих постоянных обязанностей, независимо от от места работы, это проведение технических собеседований с кандидатами на новые или освободившиеся вакансии в команде. И концентрация собеседований на единицу времени со временем увеличивается. Я думал, что деканство в Гикбрейнсе, где я проводил, в среднем, 3 собеседования в неделю в течение года — это предел и хуже уже не будет. Но сейчас на этапе формирования команды количество собеседований в неделю достигает 10.

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

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

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

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

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

Друзья, недавно я зарегистрировался в Твиттере, где пишу более неформальные (и, разумеется, более короткие) посты, участвую в обсуждениях. Буду рад фолловерам: https://twitter.com/_it_monk_

В мире IT, несмотря на свойственную ему инновационность, правило «Новое — это хорошо забытое старое» тоже прекрасно работает. Вот несколько примеров:

- Функциональное программирование стало трендом вместо объектно-ориентированного, которое в своё время было очень популярно и предлагалось везде в качестве альтернативы функциональному;
- Первые планшетные компьютеры появились ещё в конце 80-х, было много попыток популяризировать их, но по-настоящему популярными они стали в начале 10-х как альтернатива компьютеру, сейчас их популярность снижается, вероятно, лет через 15 мы опять увидим бум планшетных ПК, но уже в качестве более функциональной альтернативы смартфонам.

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

История клавиатур берёт своё начало в США в 19-м веке, тогда клавиатуры нужны были, разумеется, в печатных машинках. Кстати, русскую раскладку ЙЦУКЕН, которой мы пользуемся до сих пор, придумали тоже в США, когда появился спрос на поставку печатных машинок в Российскую империю. С появлением телетайпа в 20-х годах и до 80-х годов технологии клавиатуростроения развивались в направлении того, как лучше определять момент нажатия клавиши, в то время как вопрос механизма клавиатуры был несущественным — все они были с пружинным механизмом. Но с развитием и удешевлением компьютерной техники в 80-х годах вопрос удешевления производства клавиатур упёрся в механику движения кнопок.

Механические клавиатуры гораздо сложнее в производстве, нежели резиномембранные, а резиномембранные не очень хороши в плане юзабилити. Поэтому с 80-х годов по наше время производители экспериментируют с механизмами клавиатур, пытаясь разработать удобное, износостойкое, недорогое устройство ввода. Эксперименты эти не всегда удачны, стоит вспомнить хотя бы MacBook’и 2016-2019 годов с отваливающимися на второй месяц использования клавишами с механизмом «бабочка».

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

Казалось бы, все привыкли к эргономичным, лёгким и тонким клавиатурам, однако, откуда ни возьмись появляется мода на забытые механические клавиатуры, но в несколько обновлённом виде со свистелками и перделками с позаимствованной у новогодней ёлки подсветкой. А звук набора текста вновь стало слышно даже через стену. Не удивлюсь, если в обозримом будущем появится переиздание с подсветкой легендарной IBM Model M keyboard.

А какие примеры получивших второе дыхание технологий знаете вы?

Apple в этот раз как-то особо предсказуема в плане дизайнерских решений. Вчера прошла презентация, на которой показали новые MacBook Pro с процессорами M1 Pro и M1 Max. Ноутбуки технически прекрасны, но свершилось то, что должно было свершиться: вместо тачбара вернулись физические клавиши, а на экране появилась чёлка.

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

Особенно интересно получилось с клавишей Esc, специфика работы с которой подразумевает частое использование и, в некоторых критичных ситуациях, возможность как можно быстрее её нажать. Осознав ошибку, Apple в прошках 20-го года вернула физическую клавишу Esc и вопрос возвращения остальных стал делом времени. Что и произошло, причём под соусом новизны, вот цитата с сайта Apple: «На клавиатуре Magic Keyboard у MacBook Pro впервые появился ряд полноразмерных механических функциональных клавиш. Такие клавиши особенно ценят профессиональные пользователи из‑за тактильных ощущений».

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

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

На хабре вчера появилась интересная обзорная статья «Зарплаты в Python за последние 10 лет». Если коротко: популярность Python растёт вместе с зарплатами Python-разработчиков.

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

Но написать я хочу не про Python, а про рейтинг языков программирования TIOBE. Это, пожалуй, самый авторитетный рейтинг популярности языков программирования. И основан он на частоте упоминания языка в поисковых запросах в Google, Blogger, Wikipedia, YouTube, Baidu, Yahoo, Bing и Amazon.

Безусловно, есть корреляция между количеством поисковых запросов и популярностью языка, но в контексте питона смущает тот факт, что за последние годы только ленивый не начинал изучать питон. Серьёзно, я не раз слышал от знакомых, на досуге пытавшихся войти в IT, что они пробовали изучать питон по бесплатным/платным курсам. А вот, например, про JavaScript мне такое слышать не приходилось. Ну то есть я знаю людей, которые решили радикально поменять профессию и начали изучать фронтенд (кто-то из них в процессе ушёл в бэк и на другой язык), но вот именно «попробовал на досуге ради интереса, не получилось», — такого я про JavaScript не слышал, равно как и про другие языки.

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

Но, если взять такую метрику, как количество пулл-реквестов на GitHub, которая, в отличие от поисковых запросов, коррелирует с количеством уже написанного кода более-менее состоявшимися программистами, то тут в лидерах JavaScript, а Python на втором месте.

Но это неважно.

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

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

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

А ещё разработка фронта позволяет участвовать в решении задач пользовательского опыта (который ещё называют UX). И это тоже интересно. Вот, например, как лучше отобразить страницу, на загрузку всего содержимого которой уходит одна секунда? Можно показать индикатор загрузки или даже просто белый экран, дождаться загрузки всего контента и показать пользователю полностью готовую страницу. А можно за доли секунды загрузить то, что можно загрузить быстрее всего, отобразить эту информацию, продолжая загружать остальной контент, который будет появляться на странице по мере готовности.

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

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

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

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

UX/UI дизайнерам и фронтендерам тоже часто приходится прибегать к похожим техникам, когда субъективные ощущения пользователя оказываются обмануты, а скорость/качество и прочие характеристики программного продукта остаются теми же или становятся хуже.

Тут цифровые кочевники (это ребята, которые путешествуют и работают в IT удалённо) из Social Discovery Ventures организовали хакатон SDV Digital Nomad Hiring Weekend с индивидуальным участием. Кроме денежных призов лучшие участники получат оффер от компании. Регистрация до 24-го числа, сам хакатон будет проходить с 26 по 28.

А пишу я про это потому, что буду одним из экспертов хакатона. Здесь подробности.

Начинающий дизайнер Татьяна Фахуртдинова выложила на Behance историю о том, как создавался логотип «IT Монаха».

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

P.S. Вы наверняка заметили, что я последнее время почти не пишу, но это всё потому, что я занят написанием статья на хабр про мой переход с Линукса на Мак. Это необычный и неоднозначный опыт, до сих пор не могу понять нравится мне новый ноутбук или нет.

Ноутбук — главный девайс в моей жизни, я провожу за ним бо́льшую часть суток. Он должен быть лёгким, компактным и мощным. Долгое время лидером по этим параметрам был Dell XPS 13, но всё поменялось с выходом MacBook Air на процессоре M1.

Air всего на 100 граммов тяжелее XPS 13, но примерно в три раза мощнее, автономнее и не нуждается в активном охлаждении. Никогда не думал, что скажу подобное про технику Apple, но MacBook Air — самое крутое устройство в своей весовой категории на рынке, оставившее конкурентов далеко позади.

Я фанат Линукса, эта операционная система для меня больше, чем просто окружение. Это философия, новостная повестка и постоянный предмет обсуждения. Поэтому сама идея отказа от Linux в пользу другой ОС меня всегда отталкивала. Да и тот эпизодический опыт, когда приходилось что-то делать в macOS, был эмоционально неприятным.

Но появление M1 посеяло во мне зерно сомнений: мой ноутбук больше не был самым крутым и навязчивой мыслью было то, что я отказываю себе в чём-то большем. Это зерно прорастало и проросло: я купил MacBook Air с 16GB ОЗУ и 512GB SSD, с удивлением обнаружив, что он ещё и стоит дешевле моего XPS. Впереди меня ожидали настройка окружения, борьба с Docker, грусть от отсутствия привычного автодополнения в консоли и много чего ещё.

Читать продолжение на Хабре »

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

Например, недавно коллега на работе поделился со мной отличным способом поставить точку останова в JavaScript. Если до этого мне приходилось ковыряться в панели разработчика Google Chrome, пытаясь найти нужный файл (а это не всегда просто, т.к. изначальная структура исходников частенько теряется и файлы идут вперемешку), то теперь я использую выражение debugger, которое пишется прямо в коде. Это гораздо проще и я сожалею, что такой способ отладки был мне неизвестен ранее: я был бы пусть на долю процента, но эффективнее в работе.

Если подумать о причинах того, что это знание было скрыто от меня, то объясняется такая ситуация, кроме как тем, что всё знать невозможно, недостатком профессионального общения. И именно в IT профессиональное общение очень важно. Это область, в которой постоянно появляется что-то новое, а уже существующие знания имеют тенденцию быстро устаревать. Разумеется, всё необходимое изложено в документации и книгах, но даже если читать всё подряд, запомнить получится далеко не всё, а то, что получится, может уже на момент прочтения начать устаревать. И наоборот, когда коллега на работе или докладчик на конференции наглядно показывает вам что-то интересное, особенно если он это делает достаточно эмоционально, то такое знание может сохраниться надолго. Вероятно, таким образом вы откроете для себя любимый приём или инструмент в вашей работе.

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

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

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

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

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

Как известно, основной причиной этого синдрома является чувство, что ты не справляешься со своей работой и/или не справляешься с ней на должном уровне по сравнению со своими коллегами. Чтобы прийти к решению проблемы, нужно понять объективно ли испытываемое чувство или нет.

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

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

1. Поменять должность или работу, где профессиональных навыков будет достаточно для хорошей эффективности;
2. Прокачаться до необходимого уровня.

Каждый из вариантов может быть хорошим решением в зависимости от контекста. Например, вам сейчас особо не до карьеры и хочется просто привести дела/жизнь в порядок, не теряя в доходах. Или, наоборот, вы чувствуете, что вам пора двигаться вперёд в профессиональном плане и нужно совершить рывок.

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

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

Главное понимать, что качественное развитие невозможно без преодоления трудностей.

Хакатон от цифровых кочевников, про который я писал, и в котором я выступаю в качестве эксперта, перенесли на декабрь и он стартует в конце следующей недели.

Ребята предлагают два кейса:

* Создание приложения для P2P звонков с адаптивным качеством;
* Создание приложения с возможностью использования масок для видеозвонков, допускается использовать любые open-source ml-библиотеки.

Если бы я мог участвовать, то самым приятным для меня было бы то, что для разработки можно использовать React Native. Потому что ещё недавно я участвовал в разработке desktop-клиента для DonationAlerts, который пилится на стеке Electron + React Native, и у меня остался багаж знаний на тему реализации видео-стримов.

Участие в хакатоне индивидуальное, а регистрация заканчивается уже во вторник, стоит поторопиться: sdvdigitalnomad.com.

Год назад писал на Хабр статью «Насколько вкусные печеньки в Яндексе?». Где я на сравнении видео от Яндекса с видео от западных коллег из FAANG намекал, что Яндекс — это не тот работодатель, за которого они себя пытаются выдать. Пытаясь показать, насколько они крутые, насколько у них дружелюбная и здоровая атмосфера, сами же на своих же видео доказывают обратное.

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

Но, сегодня я хочу предложить к сравнению другие два видео, про отношение к людям с инвалидностью.

Вот ролик рекламной кампании Google Поиска: https://youtu.be/uwRyBfLmUps

А вот реклама «Помощь рядом» от Яндекса: https://www.youtube.com/watch?v=2wJnOvUcIiY

Цитата из первого ролика: «Это не про добро — это про равенство. Пока мы говорим про добро, пока мы говорим про благотворительность, мы всё ещё говорим про то, что вот есть глухие и бедные, и нужно им помочь.».

Во втором ролике мы слышим «помогать, помогать, помогать и помогать».

То есть, в то время как:

1. Google помогает людям с инвалидностью самым важным, чем может помочь, говоря и показывая, что у них должны быть равные со всеми возможности;

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

И вот эта вот грусть-тоска в начале ролика… Не могу не привести комментарий моего друга, который снабжает меня подобными видео: «Я бы предположил, что у Яндекса длительный контракт с творческим объединением ценителей Балабанова».

Пока Valve готовит запуск революционной портативной игровой консоли Steam Deck, на которой будет запускаться большинство игр из Steam, а мир до сих пор испытывает дефицит консолей PlayStation 5, которому не видно конца, рынок облачного гейминга продолжает расти.

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

Однако, как человек, работающий в IT довольно давно, я вижу очевидную тенденцию и убеждён, что будущее исключительно за облачными вычислениями. Более того, учитывая абзац выше, меня можно уличить в лицемерии, потому что я пользуюсь Gmail с 2007 года и был весьма рад избавиться от досаждавшего Thunderbird, выкачивавшего всю помойку писем и съедающего немало памяти, впрочем, как и любой другой почтовый клиент.

Кроме очевидных тенденций, которые можно наблюдать (облачные офисные пакеты, популярность облачных файловых хранилищ, облачная музыка в браузере), стоит обратить внимание на недавнюю новость: Google назвала Chrome OS самой быстрорастущей операционной системой в мире. Логично предположить, что если так растёт популярность операционной системы, ориентированной на облачные вычисления, то облачный гейминг будет расти ещё сильнее.

Я несколько раз пробовал пользоваться сервисами облачного гейминга и каждый раз меня хватало максимум на час. Основная проблема в качестве картинки: даже при использовании современного кодека H.265, изображение всё-равно получается достаточно замыленным (особенно заметно на тексте) для того, чтобы это заметить. Кто-то ещё жалуется на задержки отклика, это не так критично для непрофессиональных игроков, но в совокупности с качеством картинки, во время игры ощущение такое, что смотришь чей-то стрим, а не играешь сам.

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

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

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

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

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

Раньше я считал, что путешествия способны перезагрузить голову и повысить удовольствие от работы. Но мой мозг при смене деятельности и обстановки просто ставит текущее эмоциональное восприятие работы «на паузу», а по возвращении из путешествия нажимает кнопку «play». И к работе после таких отдыхов я возвращаюсь с чувством, будто работать я закончил вчера поздно вечером. То же самое с другими активностями, включая в том числе встречи с друзьями и употребление алкоголя. Это всё развлечения, которые я люблю, но которые мне не помогают восстановить ресурс. Я думаю, причина здесь в том, что нагрузка на мозг существенно не снижается, особенно в этом плане выматывают путешествия, где нужно бегать по аэропортам, изучать новые места, адаптироваться, говорить на непривычном языке и прочее. А алкоголь, как и любое другое психоактивное вещество, вообще выступает конкурентом любой деятельности, включая профессиональную.

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

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

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

Справедливости ради нужно сказать, что верстать раньше было не то чтобы трудно. Но с развитием стандартов, технологии во фронтенде становились сложнее, необходимо было реализовывать больше динамики (и тут на помощь пришёл jQuery, потому что на голом JavaScript реализовывать динамику было невыносимо). С появлением Node.js актуальной стала сборка скриптов и стилей в бандлы для уменьшения результирующего кода и ускорения загрузки страницы. Правильная настройка сборки — отдельная предметная область, в которой фронтендерам тоже нужно было разбираться. А ещё была необходимость поддержки Internet Explorer новых версий наравне со старыми, потому что каждая новая версия закрывала старые баги, но привносила новые, а заказчик требовал поддержку начиная с IE6.

Так и появилась профессия фронтенд-разработчик, для которого вёрстка была лишь частью обязанностей, в то время как основными стали написание кода на JavaScript (а теперь в основном на TypeScript), настройка сборки, гонка за скоростью отрисовки, адаптивностью и прочее.

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

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

Возвращаясь в нулевые, возьмём условного студента, который защищал диплом на тему искусственного интеллекта (тогда термин «машин-лёрнинг» был как-то не в ходу), на первой работе он писал на Borland C++ Builder, попробовал себя в разработке мобильных игр для Symbian на Java, потом перешёл в веб-разработку на PHP, занимаясь и фронтендом, в том числе. Всю свою карьеру интересовался всем, смотрел как делают другие и предпочитал всё делать сам. Поработал с MySql, Angular, Postgres, Vue, MongoDB, React, RabbitMQ, Ext.js, Memchahed, Backbone.js. Вот он кто, бэкэндер или фронтендер?

Или специалист без такого бэкграунда, но фанат, для которого IT — это не только работа, но и хобби, который всё свободное время проводит за изучением технологий и работой с ними, давая форы коллегам, соблюдающим work-life баланс… Он плохо разбирается одновременно и в базах данных и в настройке Webpack просто потому, что в его голове не способно всё уместиться?

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

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

...

...

Именно поэтому фуллстеку сложно найти фуллстековую работу: вакансий мало, и они не в те компании, в которые хотелось бы, да и платят меньше, чем бэкам и фронтам с таким же опытом. Остаётся Research&Development (неплохой вариант, кстати), да немногочисленные вакансии в стартапах и компаниях, которые умеют работать с фуллстеками.

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

Во время моей работы в GeekBrains мы с ребятами делали пилотный курс по фрилансу совместно с fl.ru. К сожалению, по нескольким причинам наш курс не зашёл.

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

А вот и второй урок по фрилансу