Пока 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. К сожалению, по нескольким причинам наш курс не зашёл.

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

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

В любой сложной жизненной ситуации компьютер (работа с компьютером, если быть точным) всегда был для меня тихой гаванью и способом вернуть спокойствие. Во многом потому что IT — это место, где работают физика, математика, логика и здравый смысл, а эмоции и вообще всё субъективное не работают.
 
Сейчас, когда сложная жизненная ситуация наступила для всего мира, а особенно сложной она стала для людей, находящихся в центре конфликта, IT приходит на помощь всем нам. Вот лишь один, самый очевидный пример: интернет, мессенджеры и социальные сети помогают людям делиться информацией, получать и оказывать помощь, поддержку. И это лишний раз доказывает, что развитие IT, как и развитие науки — важный путь выживания человечества, выживания нашей культуры.
 
Мне не очень нравится преподавать, но я развивал факультет JavaScript с большой отдачей потому, что я уверен, что айтишников должно становиться больше. Неважно каких, любящих свою профессию или пришедших за деньгами, профессиональных или не очень, желающих развиваться или нет. Потому что IT должно развиваться, и чем быстрее, тем лучше. В этом наше спасение, я уверен.
 
Если говорить о цели ведения этого канала, то она тоже заключается в том, чтобы в IT приходили новые люди, а те, кто уже в профессии, не уходили по различным причинам. Я делюсь своим опытом и мнением для того, чтобы показывать и напоминать как всё-таки интересен мир компьютеров.
 
Если перечитать все посты, то можно заметить, что в них почти нет критики. Несмотря на то, что большинство «компьютерных» блогеров любят кого-нибудь или что-нибудь полить говном (потому что сама айтишечка токсична по своей природе, да и такие материалы интересно смотреть и читать), я стараюсь воздерживаться от критики технологий, компаний, персон просто потому, что это противоречило бы цели ведения этого канала. Хотя, конечно, у меня есть своё мнение почти на всё и я люблю высказываться жёстко. В этот раз я также обойдусь без критики.
 
Я благодарен мировому айти-сообществу, компаниям за то, что не оставили разработчиков, которые решили остаться в России или просто не хотели покидать страну, без важных сервисов и инструментов, необходимых для разработки. Вероятно, на фоне беспрецедентного «канселинга» в масштабах планеты такие решения дались с трудом.
 
Желаю всем IT-специалистам, кого ударили эти тяжёлые времена, всем, кому плохо физически или морально, выжить во всех смыслах этого слова. Будем делать свою работу и для своего блага и для того, чтобы в будущем люди смогли пережить вызовы даже более серьёзные, чем этот.
 
Мир!

Сколько мне ни приходилось работать по SCRUM, всегда было ощущение, что эта методология отнимает слишком много времени у разработчиков. Главный плюс в более предсказуемом процессе разработки, что хорошо для бизнеса и, несомненно, является пользой для него.
 
Но чем больше я работаю по скраму, тем больше ко мне приходит понимание, что вред его не только в том, что он отнимает много времени у разработчиков, но и создаёт программистам благодатную почву для того, чтобы заниматься чем угодно кроме непосредственно разработки, иными словами, прокрастинировать.
 
Начну с самого начала, со стендапов (дейли митинги, дейлики). В айти принят гибкий график работы, начало рабочего дня у всех разное и время дейли выбирается с учётом этой особенности, т.е. чтобы вся команда к этому моменту уже точно начала работать. Не раз замечал, что когда устанавливается время утреннего стендапа, это время становится негласным началом рабочего дня для большинства.
 
То есть, если без стендапа все начинали работать с 9 до 11, то с дейли митингом, который становится утренним ритуалом, начало рабочего дня смещается ближе к стендапу. И почти на каждом дейлике обнаруживается, что кого-то дейлик застал в каких-то делах, не относящихся к работе. При этом конец рабочего дня, по ощущениям, остаётся таким, каким и был.
 
Однако у стендапов есть огромный плюс, который делает его скорее полезным инструментом: можно понять кто чем занимается, на лету решить какие-то небольшие проблемы, разобраться с блокерами. Особенно полезно, когда на созвоне все включают камеры и первые пять минут обсуждают что-то не связанное с работой, это способствует тимбилдингу.
 
С другой стороны, все мы в IT ценим результат, а не время, проведённое за работой. И именно с результатом в SCRUM начинаются настоящие сложности.
 
Когда я начинал зарабатывать деньги программированием, аджайл был не в ходу, программистов не было так много, команды не были такими большими. А самым простым и эффективным способом организации разработки были постановка конкретных задач, определение сроков исполнителем, который берёт задачу в работу и соблюдение этих сроков исполнителем. Это прекрасно работает сейчас на том же фрилансе и это прекрасно работало тогда во всём IT: если у тебя проблемы с оценкой сроков и/или сложности задачи, то сиди и доделывай по ночам. Потому что, если ты будешь ошибаться в сроках постоянно, тебя уволят. Если ты будешь постоянно называть слишком большие сроки, тебя уволят. Но если ты будешь в большинстве случаев соблюдать адекватные сроки, то тебя будут ценить и поднимать тебе зарплату, любой, кто с тобой работал, всегда скажет, что на тебя можно положиться.
 
Всё поменялось с приходом SCRUM: теперь, если ты проволынил задачи, то на ретроспективе можно всегда выбрать удобную причину: блокеры (бэкэндер сделал не так или не сделал, девопс настроил не так или не настроил, менеджер описал задачу не так), недостаток коммуникации, неправильная командная оценка, недостаточная документация, отсутствие какого-то инструмента и т.п. Про каждую из этих причин можно написать отдельную заметку, но настоящая причина, в большинстве случаев и по большому счёту, всегда одна: отсутствие персональной ответственности за задачу.
 
Да и даже если просто сказать «на этой неделе было плохое настроение», то в отчёт по ретроспективе так и запишут, никто не будет ругать. Недоделанную задачу перенесут в другой спринт, расчётную производительность команды (velocity) понизят. И будут понижать до тех пор, пока оценка задач на спринт не начнёт совпадать с затратами по факту. Я своими глазами видел фронтендера, которая в течение года писала в день в среднем 12 строк кода и ничего ей за это не было. Большинство программистов любят скрам, он позволяет доминировать слову life в work-life балансе.

👇👇👇

Ну и само планирование (покер планирования, Planning Poker) тоже штука забавная: исполнитель задачи не может существенно повлиять на оценку, потому что оценка коллективная. Если ты говоришь, что сделаешь задачу за день, а другие считают, что на это уйдёт неделя (или наоборот), придётся согласиться с мнением большинства. Такая оценка слабо учитывает индивидуальные особенности разработчиков, их экспертизу.
 
В итоге на разработку какой-нибудь классической пользовательской истории Регистрация-Авторизация-Восстановление у компании, сидящей на SCRUM’е, в лёгкую может уйти 40 тысяч долларов и это не предел. Почему же компании продолжают платить? Потому что аджайл-процессы очень легко масштабировать, когда бизнес растёт. Удобство в данном случае важнее цены.
 
А ещё не приходится полагаться на конкретных людей, бизнес не любит риски.
 
Но я уверен, что как бы ни были отточены процессы, какими бы они ни были эффективными, успешность разработки продукта всё-равно будут определять конкретные люди.

Как Яндекс мог бы защититься от этого? Внимательнее относиться к найму сотрудников? Шифровать данные, которые всё равно могут быть расшифрованы любым, у кого есть ключ? Можно снизить вероятность таких событий с помощью неотвратимости ответственности, так же как общество снижает вероятность убийств, грабежей, краж и других преступлений. Но нужно понимать, что утечки данных — это неприятная, но неизбежная реальность современного цифрового мира. У цифровизации немало минусов, но есть и плюсы: например, то, что любую готовую еду вам могут вручить уже через полчаса после заказа.

Немало IT-работодателей, практикующих полную удалёнку, применяют системы учёта рабочего времени для контроля разработчиков и анализа продуктивности. Не понимаю, как добровольно можно согласиться на установку софта, который скринит твой экран, логирует то, что ты печатаешь на клавиатуре, мониторит сайты, которые ты посещаешь. С полным пониманием того, что эта информация собирается не только для статистики, но может и будет просмотрена работодателем.
 
Разумеется, про любую личную переписку, гугление по каким-то личным вопросам и про подобные вещи можно забыть. Кто-то говорит «пусть смотрят, мне скрывать нечего» и каждый имеет право на такую позицию. Но нужно понимать, что диалог в мессенджере потому и называется диалогом, что в нём два участника. И если один участник согласен сдавать свою переписку третьей стороне, то у другого может быть прямо противоположная позиция по этому вопросу и он может даже не догадываться, что его сообщения прочитает сотрудник какой-то сторонней компании. Часто необходимость установки софта для мониторинга подаётся под соусом предотвращения утечек информации, в том числе неумышленных.
 
Такой способ контроля даже хуже, чем наблюдатель, стоящий у тебя за спиной, потому что наблюдатель хотя бы не записывает все твои действия. Да и эффективность этого контроля сомнительна: куда полезнее ориентироваться на результат, а не на процесс. Одно дело стремиться к какому-то конкретному результату, другое, не отвлекаясь, писать код весь день, это несколько разные задачи. Если программист не мотивирован быстрее реализовать функционал, но от него требуют писать код 8 часов в день, то он будет стараться разнообразить и растянуть процесс, ударяясь в лишние абстракции и эксперименты.
 
Есть более «человечная» альтернатива — это ведение таймшитов. Сделал задачу — отбил время в журнале. Почитал статьи на Хабре в контексте задачи — отбил время. Я воспринимаю это как ненужную бюрократию, в условиях которой в глазах работодателя круче будет тот, кто лучше умеет составлять отчёты о проделанной работе. Тем более в «таймшит» можно вписать какое-нибудь «чтение документации», даже если на это время по факту пришёлся послеобеденный сон.
 
Я уверен, что в плане получения пользы от сотрудников (под пользой следует понимать в том числе привнесённые идеи, улучшения в продукте, вовлечённость в процесс и т.п.) получают те компании, в которых нет контроля за тем, со скольки до скольки человек занят работой. Если на работе лояльно относятся к тому, что в середине рабочего дня можно отвлечься на что-то личное, то и отношение к работе у сотрудника тоже будет лояльным. Работа начинает больше восприниматься как занятость. А занятым быть интересно. Поэтому программист может посвящать рабочим задачам даже больше времени, чем требуется. Но главное — результат, не забываем.
 
Ещё в нулевых годах популярной метрикой было количество написанных строк кода, что породило такое явление как «индусский код», когда программист старается «растянуть» текст программы на как можно большее количество строк, сделав его максимально многословным. Разумеется, такая метрика никак не характеризует ни эффективность разработчика, ни сложность решённой им задачи, наоборот, заставляя писать некачественный и неэффективный код.

Месяц прошёл с момента публикации предыдущей заметки. Друзья, не подумайте ни в коем случае, что я охладел или, уж тем более, решил забросить ведение канала. Это совершенно не так.
 
Время такое, что про IT тяжело писать, тем более тяжело писать в том формате, в котором я всегда это делал — обстоятельно разбирая тему. Коллеги по ведению каналов подсказывают мне, что проблема ещё заключается в том, что я не монетизирую канал, не рассматриваю его как коммерческое предприятие. Я никогда не хотел писать за деньги, никогда не хотел делать деньги из выражения своих мыслей, особенно когда эти мысли находят отклик в умах сотен людей. Будет ли так всегда, не знаю, но сейчас так.
 
И сейчас я рассматриваю дополнительные форматы материалов, которые я буду выкладывать на канале: аудио-подкасты, короткие заметки, особенно понравившиеся IT-мемы и видео-стримы.
 
Готовлюсь к тому, чтобы записать подкаст про ведение IT-канала, как часть IT-бренда: зачем, почему и как раскручивать эту историю.
 
Друзья, будет круто, если вы поддержите канал «IT Монаха» репостами понравившихся вам заметок в свои каналы, группы или своим друзьям и коллегам.

Отсутствие высшего образования
Rust — крутой язык программирования
Разброс зарплат программистов
Фриланс для старта карьеры
Заменит ли ИИ программистов
Переход с Linux на MacOS

...снова месяц прошёл с момента публикации предыдущей заметки 🙃

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

Итак, про личный бренд.

Записал подкаст про выгорание 🤘