Саббатикал

Я ходил в оплачиваемый саббатикл на 3 месяца и просто уходил отдыхать за свой счет на полгода. У меня возникает пачка вопросов

1) Зачем сотруднику вообще нужен НЕ оплачиваемый саббатикл?

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

2) Зачем отпускать сотрудника из ИТ компании на год?

За год/полтора меняется все — стек, коллектив, проекты, подходы; По сути ты берешь нового человека, которому надо будет еще восстанавливаться и в рабочем настроении и в организационном плане. В большинстве мест где я работал озвучивали всегда довольно прямо и честно — если команда может без тебя больше 2-х недель, то зачем ты нужен на своем месте?

Саббатикал (контекст)

Пролистал я тут видео, где сотрудник Яндекса ушел с работы в неоплачиваемый саббатикл на полтора года; Нахрен такие саббатиклы и сотруднику и компании?

После 5 лет работы просто дайте денег на 2-3 месяца отдыха, я хоть перезагружусь нормально, пройду Ведьмака, пересмотрю Супернатуралов, выпью весь виски из соседнего магазина и выйду с новыми силами работать. Какие полтора года неоплачиваемого отдыха? Вы о чем вообще? Что за дичь?

Я художник, я так вижу и причем тут программисты

Публикую порою заказы на фрилансе. То презентацию оформить, то картинку нарисовать, то лендинг.

Откликаются люди с опытом 10 лет. В портфолио портреты с кривыми лицами, но идеальные шарики со светотенью. Натюрморты в стиле масляного холста 30-х годов супер, но кнопку на сайт нарисовать не могут.

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

Вот у программистов часто так же. Мне зарплату платят, а откуда там деньги возьмутся — мне не интересно. Я буду индексы на БД вешать, а то, что это не приносит клиенту ничего — не важно. Главное быстро. А зачем быстро?! Хрен его знает.

5-10 лет опыта. Шары со свето тенью идеальные. Выборка из БД очень быстрая. А клиент афишу не получил, товар с сайта не продал. Свою бизнес задачу не решил.

Не надо так.

Саббатикал (рефлексия)

Ну, я же живой человек. Меня может немного побомбить по ситуации.

Послушал я тут видео доклад сотрудиника Яндекса, который сходил в так называемый Саббатикал аж на полтора года.

За человека я рад. Он хорошо спланировал, хорошо организовал выход в длительный отпуск и вообще умничка. Но по ситуации у меня неприятие.

1) Я привык воспринимать саббатикал как долгосрочный ОПЛАЧЕЫВАЕМЫЙ отпуск, который дается за выслугу лет. Отработал 5 лет в компании — получи бонус — 3 месяца оплачиваемого отпуска. Отдохни от всего без потери качества жизни. Перезагрузись. Приходи — без тебя будет сложно, но мы справимся. Очень ждем! Но если найдешь новое место работы — верни, пожалуйста, выплаченные деньги.

2) Человек отработал в компании 15 лет и, если я правильно понял, ушел на год, а потом еще и на полгода НЕОПЛАЧИВАЕМОГО отпуска с сохранением места. ЧЕГО!? За 15 лет ему не дали даже полгода бонусного отдыха? Я возмущен!

Саббатикал (Рефлексия 2)

3) У меня не бьются числа. Человек ушел на 1.5 года в неоплачиваемый отпуск. Это Москва или подмосковье. По моим подсчетам, не теряя качества жизни, это миллионов 5 русских денег; Даже если ты имеешь накопления просто сжечь, или недополучить 5 миллионов. Ну, это такое себе. Даже если он все это время жил на проценты с депозитов; Зачем тогда называть это отпуском? Уволься — поживи в свое удовольствие, вернись в компанию на повышенную ставку. Возвращаться всегда выгоднее, чем морозить место.

4) Я по прежнему не понимаю какая выгода компании отпускать сотрудника на 1.5 года. Это уже совсем другой человек. Возможно, расслабленный и во вне рабочем состоянии. Очень невыгодно. Я возвращался в компании через пару лет — но я приходил с новым опытом и сразу на старшие позиции для работы напрямую с топ менеджментом, а не как рядовой разработчик. Новые идеи, опыт с прошлых мест работы — все это ценно, все это выгодно всем сторонам.

В общем по итогу доклада, я вижу только минусы для всех.

Я, наверное, что то не понимаю в художественных работах.

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

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

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

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

Архитектура

У архитектуры зданий, web приложений, архитектуры музыкальных произведений, и у любых других художественных и творческих работ очень много общего.

Невозможно создать сложную компьютерную систему, не обдумав общий ее вид и устройство, не расставив все нужные компоненты по местам.

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

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

Невозможно написать музыкальную композицию не придумав мелодию.

Невозможно приготовить борщ не зная из каких основных ингредиентов он состоит и не приготовив их заранее.

Куда не плюнь везде система, отработанные процессы, схемы, концепты.

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

Система, процесс, схема, концепт.
Simple as hell.

Смотрел сегодня смешной ролик известного разработчика, где он утверждал, что его ребята деплоят по 50.000 строк в месяц.

Зрители интерпретировали это как 50.000 строк кода от 1 разработчика. Хотя я не видел, где это утверждается напрямую. В общем, автор немного хайпанул. Молодец! Для продвижения это полезно.

Но я смотрю на них как на младенцев. Ха! Жалкие 50.000 строк в месяц! Я за 2 часа в одном пулл реквесте затронул 20.000+ строк.

Ну и кто тут батя? 🤣😂😅

Миграции и новое партнерство (часть 1)

1) В Ruby on Rails есть так называемые миграции. Файлы такие с определенным функционалом. В проекте в котором я сейчас работаю за 12 лет накопилось их очень много. Я решил разгрести этот бардак.

Первая идея смертельно простая — сгруппировать миграции по каталогам по годам. Делается это 3-я строчками Bash скрипта. Вместо 1000 файлов получается 12 каталогов в которые эти файлы просто переносятся. Ничего по сути не меняется и не ломается.

Ребята мои решили пойти еще дальше и использовать гем squasher. Ну, решение другое, но конечный результат очень похож. Так мы заменили 1000 файлов на один. Тоже не дурно, но пришлось повозиться. Я думаю, что мое решение было проще. Но сравнивать решения не приходится — принцип совсем разный.

В общем удачно почистили проект от хлама за 12 лет. Дышать стало легче.

Миграции и новое партнерство (часть 2)

2) В очередной раз я сломал людям мозги и таки заставил их придерживаться системного подхода в их работе. А что делать. Не я такой — ну кто-то же должен ласково объяснить чего и как хочет заказчик.

В итоге нашел 2 художников-кандидатов с которыми есть шанс продуктивно поработать над небольшим проектом.

Созрела идея сделать из них команду и попробовать запустить совместную деятельность.

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

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

Это как в программировании, сперва ты делаешь абстрактный класс, а потом прорабатываешь реализацию, и в самом конце инстанцируешь готовый результат.

В общем попробуем

TDD как стиль работы

И вот вчера мне прилетает задача. Надо модифицировать существующий функционал в приложении.

Функционал скрыт в сервис-классе.

Сервис класс элементарно протестирован. Хотя может и хорошо протестирован. Я пока не погрузился. Но тесты работают.

Первое что я делаю — начинаю менять код сервисного класса. Прогоняю тесты постоянно. Упрощаю код. Делю его на меньшие блоки, на методы;

При этом ничего не ломается — я точно знаю, что код как работал, так и работает. Тестами же покрыт!

Из приложения этот сервисный класс вызвать не реально — надо слишком много процессов эмулировать руками. Тесты — единственный шанс менять сервис и не потратить при этом неделю на воспроизведение кейсов.

параллельно согласую с коллегой мой стиль кода и подход к упрощению — коллега хвалит — получается хорошо; Это важно — тестировать не только код но и подход.

Потом добавлю тестов и улучшу сервис. При этом как воспроизвести реальный кейс в проекте — понятия не имею; Только тесты — только разработка через них.

Докер

На заре разработки, чтобы запустить проект требовалось на компьютер поставить кучу программ.

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

Приходилось либо ситуативно лечить и смиряться, что теперь система черт знает в каком состоянии, либо начинать все заново. И тратить тонну времени.

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

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

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

Что думаете?