О кабанах. Рефлексия о старом.
Во времена моей работы в NC одной из главных головных болей в разработке была производительность. Приложение, которое мы делали, ворочало монстроузными деревьями данных, хранящихся в EAV виде в оракле. Помимо деревьев, сложных самих по себе (хотя если ты 5 лет ворочаешь одну и ту же структуру — то она уже и не кажется особо сложной), там еще было навернуто сотни слоев бизнес логики с возможностью расширения и кастомизации под каждого отдельно взятого заказчика. В целом, продукт был сделан некачественно и неудобно.
Как же так получилось? А очень просто — сам продукт вырос из сейлз-демки для одного из заказчиков, дальше несколько раз мутировал на других демках, в итоге продался, и мы вынуждены были срочно его допиливать до продакшн-состояния. Он выстрелил, дальше было больше проектов и технический долг нарастал снежным комом. Многие базовые архитектурные решения были сделаны под первого заказчика и переносились из версии в версию, чтобы не ломать обратную совместимость, а со временем на вопросы "почему тут так?" проще было ответить "так сложилось исторически" чем вспоминать логику решения.
Естественно, все это работало неспеша и по ходу дела производило кучу багов, на которые сверху накладывались баги UI фреймворка, а снизу — платформы, на которой это все стояло. В силу инертности большой корпорации и отсутствия мощных драйверов изменений снизу, никто не знал что с этим делать и не хотел брать на себя ответственнсть.
В то время я был уверен, что нам просто не хватает скилловых программстов, что проблема была в том, что нанимали в основном джунов (в свой отдел я так и не смог нанять ни одного сеньера помидора с рынка, только растил своих), что вот если бы нам щас дали хороших разработчиков, то все бы заколосилось и взлетело. Таких разработчиков действительно наняли, в тогда свежеоткрытых офисах в Нижнем Новгороде и СПб. Один из тимлидов оттуда в разговорах употреблял слово "кабаны" как синоним хорошего, годного, сеньерного разработчика, и мы с ним сходились в мнении, что просто нужно больше "кабанов" на проект и все будет хорошо.
Увы, сильно лучше не стало, по крайней мере на моем проекте. На проекте того парня не знаю как все было, я уволился до того, как они вышли в продакшн, но походу как-то все работает.
После этого я понял что на одних кабанах не выедешь, даже если собрать талантливых и умных людей в одной комнате, то без правильного видения продукта, хорошо поставленных процессов и отсутствия компромиссов получится то же самое, что и раньше. Может быть, немножко лучше. Совсем чуть-чуть. Для вящего эффекта кабаны нужны еще и в продукт и проджект менеджменте 🐖. Тогда будет норм. Может быть. Но это не точно.
А если вам вдруг предложат порулить легаси проектом, допилить или перепилить — не соглашайтесь ни за какие коврижки. Лучше начать с нуля, все равно через год у вас будет уже свой собственный набор свежеиспеченного легаси и костылей с подпорками.
Во времена моей работы в NC одной из главных головных болей в разработке была производительность. Приложение, которое мы делали, ворочало монстроузными деревьями данных, хранящихся в EAV виде в оракле. Помимо деревьев, сложных самих по себе (хотя если ты 5 лет ворочаешь одну и ту же структуру — то она уже и не кажется особо сложной), там еще было навернуто сотни слоев бизнес логики с возможностью расширения и кастомизации под каждого отдельно взятого заказчика. В целом, продукт был сделан некачественно и неудобно.
Как же так получилось? А очень просто — сам продукт вырос из сейлз-демки для одного из заказчиков, дальше несколько раз мутировал на других демках, в итоге продался, и мы вынуждены были срочно его допиливать до продакшн-состояния. Он выстрелил, дальше было больше проектов и технический долг нарастал снежным комом. Многие базовые архитектурные решения были сделаны под первого заказчика и переносились из версии в версию, чтобы не ломать обратную совместимость, а со временем на вопросы "почему тут так?" проще было ответить "так сложилось исторически" чем вспоминать логику решения.
Естественно, все это работало неспеша и по ходу дела производило кучу багов, на которые сверху накладывались баги UI фреймворка, а снизу — платформы, на которой это все стояло. В силу инертности большой корпорации и отсутствия мощных драйверов изменений снизу, никто не знал что с этим делать и не хотел брать на себя ответственнсть.
В то время я был уверен, что нам просто не хватает скилловых программстов, что проблема была в том, что нанимали в основном джунов (в свой отдел я так и не смог нанять ни одного сеньера помидора с рынка, только растил своих), что вот если бы нам щас дали хороших разработчиков, то все бы заколосилось и взлетело. Таких разработчиков действительно наняли, в тогда свежеоткрытых офисах в Нижнем Новгороде и СПб. Один из тимлидов оттуда в разговорах употреблял слово "кабаны" как синоним хорошего, годного, сеньерного разработчика, и мы с ним сходились в мнении, что просто нужно больше "кабанов" на проект и все будет хорошо.
Увы, сильно лучше не стало, по крайней мере на моем проекте. На проекте того парня не знаю как все было, я уволился до того, как они вышли в продакшн, но походу как-то все работает.
После этого я понял что на одних кабанах не выедешь, даже если собрать талантливых и умных людей в одной комнате, то без правильного видения продукта, хорошо поставленных процессов и отсутствия компромиссов получится то же самое, что и раньше. Может быть, немножко лучше. Совсем чуть-чуть. Для вящего эффекта кабаны нужны еще и в продукт и проджект менеджменте 🐖. Тогда будет норм. Может быть. Но это не точно.
А если вам вдруг предложат порулить легаси проектом, допилить или перепилить — не соглашайтесь ни за какие коврижки. Лучше начать с нуля, все равно через год у вас будет уже свой собственный набор свежеиспеченного легаси и костылей с подпорками.
Фуллстек. Фронтенд для бекендеров 1.
С html, css и js у меня как-то не особо складывалось по жизни, хотя большую её часть я занимался разработкой именно веб-приложений. В 2010 помню была у меня задача рисовать на экране что-то вроде диффа между двумя деревьями, в виде таблицы. Сам дифф я изобразил довольно быстро, но никак не получалось сделать так, чтобы высота пустых ячеек в таблицах была такой же, как и для заполненных. Для рисования таблицы я пользовался не table/tr/td а нашим внутренним фреймворком для рендеринга в html, который добавлял кучу вложенных элементов. Я долго возился со стилями, но все никак не получалось — пустые ячейки не хотели разжиматься на полную высоту.
Возле меня не было шарящего человека, а к UIщикам, которые и делали тот фреймворк, обратиться я постеснялся. Или не догадался. В общем я решил пойти простейшим путем — если с заполненными ячейками все ок, то значит нужно просто заполнить все пустые ячейки каким-то текстом и покрасить его в цвет фона. Так и сделал, лол. Бага закрыта, все красиво, все довольны.
Угадайте, что было дальше? Через пару дней мне пришло гневно-вопросительное письмо: оказывается, BA со стороны заказчика, который тестировал эту функциональность, решил выделить и скопировать таблицу с диффом, типа, так пользователи будут делать чтобы отправлять письма с этими таблицами. Естественно, при копировании, стили потерялись и наружу вылезли те элементы, которые я старательно закрасил в цвет фона, что и вызвало disappointment у BA. А еще — поставило под вопрос компетенцию специалистов, которые делают такие решения. На том проекте одновременно работали люди заказчика, мы (основной подрядчик) и еще одни ребята, которые были нашими конкурентами, и все только и ждали удобного повода, чтобы улучить "коллег" в фейле и заработать себе политический капитал для последующего захвата территории.
В общем возник маленький скандальчик, который, правда, удалось замять — более сообразительный сеньер помидор из нашей команды быстро сделал нормальные стили и все заколосилось.
К сожалению, урока тогда я не усвоил, и дальше продолжал аутировать в своем уютном мире абстрактных фасолин, спихивая всю неугодную и непонятную мне работу со стилями и внешним видом на других людей.
С html, css и js у меня как-то не особо складывалось по жизни, хотя большую её часть я занимался разработкой именно веб-приложений. В 2010 помню была у меня задача рисовать на экране что-то вроде диффа между двумя деревьями, в виде таблицы. Сам дифф я изобразил довольно быстро, но никак не получалось сделать так, чтобы высота пустых ячеек в таблицах была такой же, как и для заполненных. Для рисования таблицы я пользовался не table/tr/td а нашим внутренним фреймворком для рендеринга в html, который добавлял кучу вложенных элементов. Я долго возился со стилями, но все никак не получалось — пустые ячейки не хотели разжиматься на полную высоту.
Возле меня не было шарящего человека, а к UIщикам, которые и делали тот фреймворк, обратиться я постеснялся. Или не догадался. В общем я решил пойти простейшим путем — если с заполненными ячейками все ок, то значит нужно просто заполнить все пустые ячейки каким-то текстом и покрасить его в цвет фона. Так и сделал, лол. Бага закрыта, все красиво, все довольны.
Угадайте, что было дальше? Через пару дней мне пришло гневно-вопросительное письмо: оказывается, BA со стороны заказчика, который тестировал эту функциональность, решил выделить и скопировать таблицу с диффом, типа, так пользователи будут делать чтобы отправлять письма с этими таблицами. Естественно, при копировании, стили потерялись и наружу вылезли те элементы, которые я старательно закрасил в цвет фона, что и вызвало disappointment у BA. А еще — поставило под вопрос компетенцию специалистов, которые делают такие решения. На том проекте одновременно работали люди заказчика, мы (основной подрядчик) и еще одни ребята, которые были нашими конкурентами, и все только и ждали удобного повода, чтобы улучить "коллег" в фейле и заработать себе политический капитал для последующего захвата территории.
В общем возник маленький скандальчик, который, правда, удалось замять — более сообразительный сеньер помидор из нашей команды быстро сделал нормальные стили и все заколосилось.
К сожалению, урока тогда я не усвоил, и дальше продолжал аутировать в своем уютном мире абстрактных фасолин, спихивая всю неугодную и непонятную мне работу со стилями и внешним видом на других людей.
Фуллстек. Фронтенд для бекендеров 2.
Тройку лет назад я задауншифтился (из молодого и перспективного менеджера с процентной ставкой томагавком торчащей из головы) и устроился в стартапчик, бэкендером пилить микросервисы на джаве. Кроме девелоперов в команде были дата саенс ребята, которые делали чё-то непонятное — искали источники данных, сваливали их в постгрес, и ковыряли питоном. Задачи у нас особо не пересекались, поэтому я не особо вникал, что там происходило.
Каждый месяц у нас была маленькая обще-корпоративная презентация, на которой все хвастались своими достижениями. И вот, очередь доходит до дата саенс парней и они показывают, что они делали все это время — а сделали они визуализацию тех данных, которые все это время собирали и обрабатывали. Выглядело это как страничка (на самом деле целый сайт с кучей разделов), на котором есть карта, можно ткнуть в любое место и получить все данные по точке — почтовый адрес, наличие рядом парков (с отрисовкой полигонов!), школ, магазинов, остановок общественного транспорта, цены на недвижимость (если были транзакции) и так далее. По суммарному ощущаемому уровню сделанной функциональности это казалось продуктом, в несколько раз более сложным нежели то, что успели напилить мы, бекендеры (регистрацию, логин, месседжинг для пользователей, еще что-то).
Сейчас это все уже доступно для массового пользователя, вот, можете покликать, если живете в Лондоне (или UK) — https://www.onedome.com/locality-reality/explore/21f92f7f-854e-589f-8153-19e15ca6747f. Естественно — это уже customer-facing страничка сделанная настоящими фронтендщиками и далекая по внешнему виду, сложности и функциональности от того внутреннего инструмента, который презентовали дата саентисты, но примерное представление о количестве деталей дает.
Выглядит вроде несложно, но тогда это произвело на меня сильное впечатление — как так — вроде обычные девелоперы без особых фронтенд скиллов (на первый взгляд), а сделали такую красоту, да еще и так быстро? Под этим впечатлением я ходил еще долго, но и дальше продолжал аутировать в микросервисах и облаках, потому что не было явно видных рабочих задач, которые бы стимулировали изучение фронтенда. Вместо этого я писал горы баш скриптов для деплоймента.
Ну а в команде сформировался внутренний мем "за месяц сделаем на питоне (фласке) и постгресе", которым датасаентисты троллили медленных бекендеров (меня).
Тройку лет назад я задауншифтился (из молодого и перспективного менеджера с процентной ставкой томагавком торчащей из головы) и устроился в стартапчик, бэкендером пилить микросервисы на джаве. Кроме девелоперов в команде были дата саенс ребята, которые делали чё-то непонятное — искали источники данных, сваливали их в постгрес, и ковыряли питоном. Задачи у нас особо не пересекались, поэтому я не особо вникал, что там происходило.
Каждый месяц у нас была маленькая обще-корпоративная презентация, на которой все хвастались своими достижениями. И вот, очередь доходит до дата саенс парней и они показывают, что они делали все это время — а сделали они визуализацию тех данных, которые все это время собирали и обрабатывали. Выглядело это как страничка (на самом деле целый сайт с кучей разделов), на котором есть карта, можно ткнуть в любое место и получить все данные по точке — почтовый адрес, наличие рядом парков (с отрисовкой полигонов!), школ, магазинов, остановок общественного транспорта, цены на недвижимость (если были транзакции) и так далее. По суммарному ощущаемому уровню сделанной функциональности это казалось продуктом, в несколько раз более сложным нежели то, что успели напилить мы, бекендеры (регистрацию, логин, месседжинг для пользователей, еще что-то).
Сейчас это все уже доступно для массового пользователя, вот, можете покликать, если живете в Лондоне (или UK) — https://www.onedome.com/locality-reality/explore/21f92f7f-854e-589f-8153-19e15ca6747f. Естественно — это уже customer-facing страничка сделанная настоящими фронтендщиками и далекая по внешнему виду, сложности и функциональности от того внутреннего инструмента, который презентовали дата саентисты, но примерное представление о количестве деталей дает.
Выглядит вроде несложно, но тогда это произвело на меня сильное впечатление — как так — вроде обычные девелоперы без особых фронтенд скиллов (на первый взгляд), а сделали такую красоту, да еще и так быстро? Под этим впечатлением я ходил еще долго, но и дальше продолжал аутировать в микросервисах и облаках, потому что не было явно видных рабочих задач, которые бы стимулировали изучение фронтенда. Вместо этого я писал горы баш скриптов для деплоймента.
Ну а в команде сформировался внутренний мем "за месяц сделаем на питоне (фласке) и постгресе", которым датасаентисты троллили медленных бекендеров (меня).
Инженеры vs программисты vs кодеры.
Люто бесит когда вылазит какой-нибудь олдовый PhD совецкой закалки (не в обиду PhD и советскому образованию) и начинает делить нас на "инженеров" и "кодеров" (иногда "программистов"). Дескать, инженеры, в белых халатах, они решают инженерные задачи, проектируют (с подругою в НИИ) значит всякие штуки, а кодеры — обезьяны для набора текста, сидят в подвалах и забивают перфокарты мудростью, спущенной с верхних этажей.
Алё, дядя! Ты когда последний раз "кодеру" давал алгоритм в виде блок-схемы на реализацию? Чо? Работаем по скраму, нет времени рисовать блок-схемы, конец спринта близко? Яснопонятно.
Нигде не видел, чтобы работников реально вот так делили. Везде программисты решают задачи. Тикеты. Бизнес-потребности. Фиксят баги.
Можешь решать сложную задачу самостоятельно — отлично, помидор. Можешь, но с помощью коллег? Миддл. Можешь только простую, а сложную еще сложнааа? Джун. Можешь расписать сложную на кусочки и отдать джунам? Красава, тимлид. Можешь весь проект с нуля засетапить, описать технологии, базовые блоки, нарисовать это и объяснить всем остальным, в т.ч. бизнесу и защитить решение? Солюшон архитект, ёпта.
Даже самая простая задача, типа "после логина юзера проверить его день рождения и показать плашку с поздравлением" подразумевает понимание вообще того, что такое последовательность действий ("алгоритм", лол) и как эту последовательность перевести с человеческого языка на компьютерный. Люди конечно отличаются способностями в построении и придумывании сложных абстракций, но сводить это к "инженерам" и "обезьянам" это уж как-то совсем черно-бело и недальновидно. Да и вообще зачем это обсуждать, только если троллинга ради. Или чтобы триггернуть кодерков типа меня, да.
Конечно, сейчас такое время пошло, что кнопка
А тайтл мне больше всего нравится FAANGовский — Software Development Engineer.
Люто бесит когда вылазит какой-нибудь олдовый PhD совецкой закалки (не в обиду PhD и советскому образованию) и начинает делить нас на "инженеров" и "кодеров" (иногда "программистов"). Дескать, инженеры, в белых халатах, они решают инженерные задачи, проектируют (с подругою в НИИ) значит всякие штуки, а кодеры — обезьяны для набора текста, сидят в подвалах и забивают перфокарты мудростью, спущенной с верхних этажей.
Алё, дядя! Ты когда последний раз "кодеру" давал алгоритм в виде блок-схемы на реализацию? Чо? Работаем по скраму, нет времени рисовать блок-схемы, конец спринта близко? Яснопонятно.
Нигде не видел, чтобы работников реально вот так делили. Везде программисты решают задачи. Тикеты. Бизнес-потребности. Фиксят баги.
Можешь решать сложную задачу самостоятельно — отлично, помидор. Можешь, но с помощью коллег? Миддл. Можешь только простую, а сложную еще сложнааа? Джун. Можешь расписать сложную на кусочки и отдать джунам? Красава, тимлид. Можешь весь проект с нуля засетапить, описать технологии, базовые блоки, нарисовать это и объяснить всем остальным, в т.ч. бизнесу и защитить решение? Солюшон архитект, ёпта.
Даже самая простая задача, типа "после логина юзера проверить его день рождения и показать плашку с поздравлением" подразумевает понимание вообще того, что такое последовательность действий ("алгоритм", лол) и как эту последовательность перевести с человеческого языка на компьютерный. Люди конечно отличаются способностями в построении и придумывании сложных абстракций, но сводить это к "инженерам" и "обезьянам" это уж как-то совсем черно-бело и недальновидно. Да и вообще зачем это обсуждать, только если троллинга ради. Или чтобы триггернуть кодерков типа меня, да.
Конечно, сейчас такое время пошло, что кнопка
<MyButton/> рисуется стокилобайтовыми библиотеками и потом выполняется с монстроузном браузерном рантайме, понимание которого есть далеко не у каждого, кто эту кнопку рисует, но это все только потому, что у нас есть возможность городить эти абстракции. 20 лет назад сидели бы все на Delphi рисовали такие же точно кнопки, только более низкоуровневые и называли бы их myBtn. 30 лет назад кодили бы формочки в FoxPro почитывая томики документации. По сравнению с текущими раскладами Delphi и FoxPro это конечно тот еще рокет саенс, но это явно не означает что современное поколение более глупое, нежели предыдущие. Просто у нас интернет есть и инструменты чуть получше. Но ненамного.А тайтл мне больше всего нравится FAANGовский — Software Development Engineer.
Фуллстек. Фронтенд для бекендеров 3.
И немного про стартапы.
В 10-11 году мы с женой вложили 10k в зоомагазин (физический) и стали партнёрами в мелком бизнесе (спойлер — партнёрство не зарегистрировали должным образом, бизнес не взлетел, точки закрылись, деньги сгорели). Параллельно с этим планировалось запустить еще и интернет-магазин, и я, как человек, что-то понимающий в разработке, взялся за это дело.
Естественно, вместо того, чтобы взять опенкарт/shopify/мадженту/что там еще есть, я решил что б-гомерзким PHP связываться не стоит и нужно потрайхардить. В то время был моден Rails, за год до этого я уже делал попытку выучить Rails, но она не увенчалась успехом и я решил попробовать еще раз. Взяв тогда самый популярный фреймворк для екоммерса Spree я засучил рукава и начал его прикручивать. С горем пополам убрал такие вещи как "billing address", сделал нормальную локализацию, и еще какие-то мелкие изменения, а вот дальше оказалось что "продукт овнер" хочет видеть красивый дизайн, потому что без дизайна магазин продавать не будет, а дефолтный минимализм нам не подходит. Конечно же дизайнера у нас не было, поэтому решили содрать дизайн у магазина-конкурента. Еще какое-то время я пострадал над css-ом, но, увы, и в этот раз у меня ничего не вышло — магазин мы так и не открыли. Полный провал.
Буквально в то же время мой коллега на работе показал мне интернет-магазин, который он сделал для своей девушки (продажа хендмейда) на престашопе с купленным шаблоном и выглядело это все очень круто. Но даже это не убедило меня, и в итоге я забил. Екоммерс вообще не сильно интересная для девелопмента тема, там главное это грамотное управление товарами, эти задачи уже давно решены и нужно только настроить плагины, базы, синхронизацию, рассылки, промо и прочее.
Если бы меня щас вернуть назад, я бы вместо ковыряний с рельсами заплатил бы тыщу баксов агенству "сайт за 777 гривен" чтобы они сделали нам магазин на опенкарте, с импортом товаров из 1С и быстрой покупкой. Тогда это почему-то никому в голову не пришло.
Посыл "продукт овнера" был таким — магазин должен быть красивым и точка. А на самом деле в екоммерсе важен не дизайн, а цены, ассортимент, реклама и цвет кнопки "КУПИТЬ" чтобы конверсия была повыше. У лидера рынка с 2005 года вообще сайт не менялся, и ничего, это им совсем не мешает.
Короче, лучше бы запустились хоть как-то, может быть я бы сейчас был магнатом, сколотившем состояние на собачьих кормах. Не сложилось.
И немного про стартапы.
В 10-11 году мы с женой вложили 10k в зоомагазин (физический) и стали партнёрами в мелком бизнесе (спойлер — партнёрство не зарегистрировали должным образом, бизнес не взлетел, точки закрылись, деньги сгорели). Параллельно с этим планировалось запустить еще и интернет-магазин, и я, как человек, что-то понимающий в разработке, взялся за это дело.
Естественно, вместо того, чтобы взять опенкарт/shopify/мадженту/что там еще есть, я решил что б-гомерзким PHP связываться не стоит и нужно потрайхардить. В то время был моден Rails, за год до этого я уже делал попытку выучить Rails, но она не увенчалась успехом и я решил попробовать еще раз. Взяв тогда самый популярный фреймворк для екоммерса Spree я засучил рукава и начал его прикручивать. С горем пополам убрал такие вещи как "billing address", сделал нормальную локализацию, и еще какие-то мелкие изменения, а вот дальше оказалось что "продукт овнер" хочет видеть красивый дизайн, потому что без дизайна магазин продавать не будет, а дефолтный минимализм нам не подходит. Конечно же дизайнера у нас не было, поэтому решили содрать дизайн у магазина-конкурента. Еще какое-то время я пострадал над css-ом, но, увы, и в этот раз у меня ничего не вышло — магазин мы так и не открыли. Полный провал.
Буквально в то же время мой коллега на работе показал мне интернет-магазин, который он сделал для своей девушки (продажа хендмейда) на престашопе с купленным шаблоном и выглядело это все очень круто. Но даже это не убедило меня, и в итоге я забил. Екоммерс вообще не сильно интересная для девелопмента тема, там главное это грамотное управление товарами, эти задачи уже давно решены и нужно только настроить плагины, базы, синхронизацию, рассылки, промо и прочее.
Если бы меня щас вернуть назад, я бы вместо ковыряний с рельсами заплатил бы тыщу баксов агенству "сайт за 777 гривен" чтобы они сделали нам магазин на опенкарте, с импортом товаров из 1С и быстрой покупкой. Тогда это почему-то никому в голову не пришло.
Посыл "продукт овнера" был таким — магазин должен быть красивым и точка. А на самом деле в екоммерсе важен не дизайн, а цены, ассортимент, реклама и цвет кнопки "КУПИТЬ" чтобы конверсия была повыше. У лидера рынка с 2005 года вообще сайт не менялся, и ничего, это им совсем не мешает.
Короче, лучше бы запустились хоть как-то, может быть я бы сейчас был магнатом, сколотившем состояние на собачьих кормах. Не сложилось.
Про "планы карьерного развития", 365 degree review и прочие способы платить меньше.
Не верю ни в какие планы развития, грейды, схемы повышения и прочие штуки которые менеджерье впаривает гребцам. Конечно же я демонстрирую искажение выборки — так как могу говорить только о тех местах, где я работал (или работали мои знакомые) и не знаю о тех местах, где схемы действительно работают, а ведь они наверняка существуют. Тем не менее.
Все такие схемы — мучение и для менеджера и для сотрудника. Менеджеру сверху дают указку не повышать зп просто так. Менеджер извергает из себя планы развития для сотрудников, но при этом он вынужден действовать в быстро изменяющейся среде. Сегодня ты поставил как КРІ девелоперу "выучить aws" а начиная с завтра весь месяц приходится заниматься багофиксом и на обучающие активности совершенно нет времени. Сорян братишка, рынок такой, давай поменяем планы. Ну вот ты баги фиксил, за что тебе больше платить? А почему так думаешь? А если найду? А ну попрыгай?
Как мерять производительность если она напрямую не привязана к бизнес-показателям? Никак. Кто во что горазд.
Сотрудник мучается потому что получает мало бабла, вот на соседней улице вроде как дают на двести баксов больше, но лояльность к компании, людям, проекту не дает просто так взять и уйти. Приходится терпеть унижения в виде всяких evaluation форм, пытаться как-то доказать всем что ты не верблюд и в итоге все равно оставаться с носом. Или с +100 вместо +500. Или не сразу а через пол-года. И вообще непонятно за что.
Все качественные карьерные сдвиги происходили со мной спонтанно а не запланированно (наверное это говорит о том, какой из меня стратег, лол) — внезапно выстреливал проект, внезапно уходили или приходили какие-то люди, которые занимали мое место и давали двигаться дальше, или чье место занимал я и двигался дальше.
Вместо игр в перформенс планы и оценки лучше сходить на собес. Там или согласятся с твоей оценкой, или честно скажут твою стоимость. Почему мне должны платить больше? Да потому что рынок такой, вот тут мне могут платить больше. Какие peer review, какие обзоры, алё ребята! Собрал вещи и ушел, джаст бузинесс носинг персонал.
Фидбек нужен чтобы вовремя выявлять мудаков и катапультировать их с проекта, без этого конечно же никак. Но зп к нему не привяжешь — даже в рамках одной команды люди на одинаковых позициях и с более-менее одинаковой производительностью могут иметь разницу в тыщу баксов легко. Надо просто честно признать что мы хотим платить по-меньше, и для оценки использовать рынок. Тогда всем будет хорошо.
Не верю ни в какие планы развития, грейды, схемы повышения и прочие штуки которые менеджерье впаривает гребцам. Конечно же я демонстрирую искажение выборки — так как могу говорить только о тех местах, где я работал (или работали мои знакомые) и не знаю о тех местах, где схемы действительно работают, а ведь они наверняка существуют. Тем не менее.
Все такие схемы — мучение и для менеджера и для сотрудника. Менеджеру сверху дают указку не повышать зп просто так. Менеджер извергает из себя планы развития для сотрудников, но при этом он вынужден действовать в быстро изменяющейся среде. Сегодня ты поставил как КРІ девелоперу "выучить aws" а начиная с завтра весь месяц приходится заниматься багофиксом и на обучающие активности совершенно нет времени. Сорян братишка, рынок такой, давай поменяем планы. Ну вот ты баги фиксил, за что тебе больше платить? А почему так думаешь? А если найду? А ну попрыгай?
Как мерять производительность если она напрямую не привязана к бизнес-показателям? Никак. Кто во что горазд.
Сотрудник мучается потому что получает мало бабла, вот на соседней улице вроде как дают на двести баксов больше, но лояльность к компании, людям, проекту не дает просто так взять и уйти. Приходится терпеть унижения в виде всяких evaluation форм, пытаться как-то доказать всем что ты не верблюд и в итоге все равно оставаться с носом. Или с +100 вместо +500. Или не сразу а через пол-года. И вообще непонятно за что.
Все качественные карьерные сдвиги происходили со мной спонтанно а не запланированно (наверное это говорит о том, какой из меня стратег, лол) — внезапно выстреливал проект, внезапно уходили или приходили какие-то люди, которые занимали мое место и давали двигаться дальше, или чье место занимал я и двигался дальше.
Вместо игр в перформенс планы и оценки лучше сходить на собес. Там или согласятся с твоей оценкой, или честно скажут твою стоимость. Почему мне должны платить больше? Да потому что рынок такой, вот тут мне могут платить больше. Какие peer review, какие обзоры, алё ребята! Собрал вещи и ушел, джаст бузинесс носинг персонал.
Фидбек нужен чтобы вовремя выявлять мудаков и катапультировать их с проекта, без этого конечно же никак. Но зп к нему не привяжешь — даже в рамках одной команды люди на одинаковых позициях и с более-менее одинаковой производительностью могут иметь разницу в тыщу баксов легко. Надо просто честно признать что мы хотим платить по-меньше, и для оценки использовать рынок. Тогда всем будет хорошо.
Фуллстек. Фронтенд для бекендеров 4.
Следующий подход к фуллстечности состоялся аж в 2017 году. Я тогда был уже ко-фаундером аутсорс шлюпки, у нас были фронтендеры, бекендеры, мобильщики и дизайнеры, в общем полный набор.
В Киеве почти каждый год проводится благотворительный оффлайн ивент под названием "Кубок Барбоса" — выставка беспородных собак, а моя жена состоит в оргкомитете этого самого кубка. Long story short, в предыдущие года люди (и собаки) регались через гуглоформу, это было неудобно и куча времени тратилась в оффлайне на то чтобы заматчить конкретного человека со строкой в гуглотаблице. Никому это не нравилось, и было решено силами нашей конторы сделать сайт с контентом, регой, оплатой, и каким-то образом еще и привязать это к оффлайну (людям после реги выдавался QR код, с которым они приходили на мероприятие, наши волонтеры сканили код на телефонах и им отображалась вся инфа об участнике, в общем там куча всего было). Архитектурно все решение состояло из сайта для людей, админки для оргов, мобильных приложений для android/ios и API для них. "Вот он, шанс выучить rails!", подумал я и решил сделать всю не-мобильную часть в виде монолита на Rails.
В этот раз расклады были чуть лучше и у нас были и дизайнерка и фронтендщица, так что процесс пошел более плавно. Я смог сосредоточиться на разработке апишечки не задумываясь, как это все будет выглядеть. Чтобы еще сильнее упростить себе жизнь, я поставил фронтендщице на компьютер ruby/rails, научил запускать приложение чтобы она сразу верстала/фронтендила куда надо, без необходимости мне переносить шаблоны вручную. Сам дизайн был тоже сделан по-науке в Zeplin, так что ни у кого не возникало вообще никаких вопросов. Проект был благотворительным, поэтому разработку мы оплачивали из своего кармана. Всю эту деятельность я совмещал с фулл-тайм работой java-обезьяной в стартапе.
После некоторого периода тупинга (примерно пары недель) кривая обучения резко пошла вверх и в итоге мы почти в срок выдали вполне рабочее решение, которым даже пользовались настоящие люди. От "кастомера" пришел положительный фидбек, все счастливы, все довольны. CSS я так и не выучил, но уже сделал серьезный шаг к тому, чтобы самостоятельно фигачить полноценные сайты, а не только рест апишечки. Особенно хорошо получилось с админкой/дашбордами — для этих дел есть множество гемов (ruby пакетов) которые автоматом генерят сносный UI на основании ваших таблиц/деклараций. То есть у меня получился относительно красивый интерфейс без применения фронтенд-скиллов вообще. До работы дата саенс парней, которой я вдохновлялся в прошлой части, было еще далеко, но уже намного понятнее, как туда попасть.
Самый лучший способ выучить что-нибудь, любую технологию — это сразу сделать на этом реальный проект, который кому-то нужен.
Следующий подход к фуллстечности состоялся аж в 2017 году. Я тогда был уже ко-фаундером аутсорс шлюпки, у нас были фронтендеры, бекендеры, мобильщики и дизайнеры, в общем полный набор.
В Киеве почти каждый год проводится благотворительный оффлайн ивент под названием "Кубок Барбоса" — выставка беспородных собак, а моя жена состоит в оргкомитете этого самого кубка. Long story short, в предыдущие года люди (и собаки) регались через гуглоформу, это было неудобно и куча времени тратилась в оффлайне на то чтобы заматчить конкретного человека со строкой в гуглотаблице. Никому это не нравилось, и было решено силами нашей конторы сделать сайт с контентом, регой, оплатой, и каким-то образом еще и привязать это к оффлайну (людям после реги выдавался QR код, с которым они приходили на мероприятие, наши волонтеры сканили код на телефонах и им отображалась вся инфа об участнике, в общем там куча всего было). Архитектурно все решение состояло из сайта для людей, админки для оргов, мобильных приложений для android/ios и API для них. "Вот он, шанс выучить rails!", подумал я и решил сделать всю не-мобильную часть в виде монолита на Rails.
В этот раз расклады были чуть лучше и у нас были и дизайнерка и фронтендщица, так что процесс пошел более плавно. Я смог сосредоточиться на разработке апишечки не задумываясь, как это все будет выглядеть. Чтобы еще сильнее упростить себе жизнь, я поставил фронтендщице на компьютер ruby/rails, научил запускать приложение чтобы она сразу верстала/фронтендила куда надо, без необходимости мне переносить шаблоны вручную. Сам дизайн был тоже сделан по-науке в Zeplin, так что ни у кого не возникало вообще никаких вопросов. Проект был благотворительным, поэтому разработку мы оплачивали из своего кармана. Всю эту деятельность я совмещал с фулл-тайм работой java-обезьяной в стартапе.
После некоторого периода тупинга (примерно пары недель) кривая обучения резко пошла вверх и в итоге мы почти в срок выдали вполне рабочее решение, которым даже пользовались настоящие люди. От "кастомера" пришел положительный фидбек, все счастливы, все довольны. CSS я так и не выучил, но уже сделал серьезный шаг к тому, чтобы самостоятельно фигачить полноценные сайты, а не только рест апишечки. Особенно хорошо получилось с админкой/дашбордами — для этих дел есть множество гемов (ruby пакетов) которые автоматом генерят сносный UI на основании ваших таблиц/деклараций. То есть у меня получился относительно красивый интерфейс без применения фронтенд-скиллов вообще. До работы дата саенс парней, которой я вдохновлялся в прошлой части, было еще далеко, но уже намного понятнее, как туда попасть.
Самый лучший способ выучить что-нибудь, любую технологию — это сразу сделать на этом реальный проект, который кому-то нужен.
Релизы в пятницу.
Многие склонны привязывать активности к рабочей неделе. Например — часто выходят на новую работу с понедельника а увольняются в пятницу. Агиле спринт часто принято начинать с понедельника и заканчивать в пятницу (через 2 недели или больше — неважно). И еще почему-то очень любят делать релиз в пятницу. Типа всю неделю работали-готовились и вот, как раз к пятнице все готово, отполировано и можно релизиться.
Я и сам множество раз делал релизы в пятницу. И всегда, всегда это сопровождалось какими-то проблемами. Вылез важный баг. Продакшн окружение чуть чуть отличается от тестового и что-то ведет себя не так, как нужно. Люди склонны делать хотфиксы побыстрее потому что пятница же, охота побыстрее свалить, в итоге проблемы нарастают снежным комом, хотфикс не проверяет должным образом и становится только хуже. И самое ужасное что нельзя просто сказать — ок, на сегодня все, завтра утром придём и починим. Нет! Завтра — суббота и никто работать не будет, давай чини. Особенно плохо, если нельзя просто так откатиться назад, например прогнали миграцию на проде и восстанавливаться из бэкапа дольше чем исправить ошибки. Кто-то взял себе тайм-офф на вторую половину дня, у кого-то поезд вечером, у всех могут быть свои дела, каждое из которых уж точно важнее нежели релиз очередного куска функциональности.
Поэтому я злостный противник пятничных релизов и выкаток. Да, нужно делать софт надежным, чтобы он не падал, чтобы откат был простым, тестировать все до посинения и так далее. Конечно же я только за качественное производство, а не за чик-чик и в продакшн (хотя и это дело я тоже люблю :)). Но, пока вы не работаете в конторе где продукт уже стабильный и процессы налажены годами, то я бы советовал релизиться в понедельник. А еще лучше делать релизы каждый день, но мне к сожалению, не удалось поработать в таком месте (на своих проектах всякие фиксы и мелкие фичи я каждый день почти выпускаю, но это немного другое), где ежедневный или ежечасный релиз был бы рутиной. Но такие конторы точно есть! Вообще, тема релиз-менеджмента очень интересная, потому что серебряной пули до сих пор нет, каждый городит свои методики, но все они, как по мне, все равно чрезмерно сложны.
Так что не релизьтесь в пятницу (или в четверг, если из страны где чтят субботу). Лучше пойти с друганами в кабак, провести время з близкими и не думать о том, что на выходных что-то может отвалиться. Работа должна оставаться на работе.
Многие склонны привязывать активности к рабочей неделе. Например — часто выходят на новую работу с понедельника а увольняются в пятницу. Агиле спринт часто принято начинать с понедельника и заканчивать в пятницу (через 2 недели или больше — неважно). И еще почему-то очень любят делать релиз в пятницу. Типа всю неделю работали-готовились и вот, как раз к пятнице все готово, отполировано и можно релизиться.
Я и сам множество раз делал релизы в пятницу. И всегда, всегда это сопровождалось какими-то проблемами. Вылез важный баг. Продакшн окружение чуть чуть отличается от тестового и что-то ведет себя не так, как нужно. Люди склонны делать хотфиксы побыстрее потому что пятница же, охота побыстрее свалить, в итоге проблемы нарастают снежным комом, хотфикс не проверяет должным образом и становится только хуже. И самое ужасное что нельзя просто сказать — ок, на сегодня все, завтра утром придём и починим. Нет! Завтра — суббота и никто работать не будет, давай чини. Особенно плохо, если нельзя просто так откатиться назад, например прогнали миграцию на проде и восстанавливаться из бэкапа дольше чем исправить ошибки. Кто-то взял себе тайм-офф на вторую половину дня, у кого-то поезд вечером, у всех могут быть свои дела, каждое из которых уж точно важнее нежели релиз очередного куска функциональности.
Поэтому я злостный противник пятничных релизов и выкаток. Да, нужно делать софт надежным, чтобы он не падал, чтобы откат был простым, тестировать все до посинения и так далее. Конечно же я только за качественное производство, а не за чик-чик и в продакшн (хотя и это дело я тоже люблю :)). Но, пока вы не работаете в конторе где продукт уже стабильный и процессы налажены годами, то я бы советовал релизиться в понедельник. А еще лучше делать релизы каждый день, но мне к сожалению, не удалось поработать в таком месте (на своих проектах всякие фиксы и мелкие фичи я каждый день почти выпускаю, но это немного другое), где ежедневный или ежечасный релиз был бы рутиной. Но такие конторы точно есть! Вообще, тема релиз-менеджмента очень интересная, потому что серебряной пули до сих пор нет, каждый городит свои методики, но все они, как по мне, все равно чрезмерно сложны.
Так что не релизьтесь в пятницу (или в четверг, если из страны где чтят субботу). Лучше пойти с друганами в кабак, провести время з близкими и не думать о том, что на выходных что-то может отвалиться. Работа должна оставаться на работе.
Фуллстек на минималках. Фронтенд для бекендеров 5.
Одним из партнёров в нашей аутсорс шлюпке был крутой фуллстек парень. Кодил он на js, был большим любителем ноды и к тому же отлично знал PHP. К нам тогда по наследству приехал среднего размера проект как раз написанный на PHP, к счастью, на Laravel (это такой аналог Rails в мире PHP, в целом довольно годный), и он ним занимался. Сам проект (который кстати живет и здравствует до сих пор, только поддерживаю его уже я) состоит из бекенда для мобил и SPA и админки для управления контентом и прочим.
Короче, там была админка, которой постоянно пользовались люди. И она выглядела круто! Там был сайдбар, хидер, всякие кнопочки-формочки и так далее, и чтобы писать все это, нужно было совсем немного кода. Я решил разузнать поподробнее как это так получается, так как всегда думал, что кто-то разрабатывал все это с нуля, а реальность оказалась намного прозаичнее — существует полно HTML-шаблонов для админок и прочих штук, и нужно всего лишь добавить себе в ассеты css-ину, js-ину ну и дальше верстать формочки так, чтобы там были нужные стили. В нашем случае таким шаблоном был AdminLTE (https://adminlte.io/themes/AdminLTE/index2.html) — это один из самых популярных, но их есть много разных. Для Laravel даже есть библиотека, которая позволяет интегрировать эти шаблоны в приложение без необходимости верстать всякие сайдбары самому.
Тут до меня потихоньку начало доходить — для того, чтобы делать сносные приложения, совсем необязательно хорошо шарить верстку — достаточно где-то найти подходящий шаблон, а дальше через копипаст переносить себе компоненты и собирать из этого, как из конструктора, рабочее решение. Конечно, для уникальных сайтов это не подойдет, но всякий околоадминский инструментарий, дашборды, аналитика и тд пишутся на ура. Нет, я конечно знал про всякие бутстрапы и прочие "фреймворки", но мне они казались чем-то типа молотка и отвертки которые еще нужно применить, а не экскаватора, которым ты после непродолжительного обучения сможешь рыть ямы со скоростью 300кк/cек. А сайты типа TemplateMonster (кстати один из людей, который стоял у истоков этой компании когда-то был моим боссом в NC) я почему-то всегда воспринимал как наблон шаблонов для екоммерса и джумлы с вротпрессом.
В таких шаблонах практически всегда есть все, что нужно — сайдбар/хидер/футер, колонки, кнопки, формы, таблицы, алерты, модалки, и даже респонсивнесс, все! Там даже есть шаблон чата! Я все думал, зачем это нужно, но (забегая вперед) настал день когда и эта функциональность мне понадобилась (я разрабатывал чатбота и нужно было дать возможность саппорту общаться с людьми без необходимости переключаться между мессенджерами).
Как раз в то время у нас стояла задача сделать админку для нового проекта. Сам проект вначале был запилен на PHP силами одного джуна, потом под моим присмотром перепилен силами другого джуна на Java но в процессе перепиливания мы потеряли админку. Я некоторое время колебался, но, после успешного небольшого проекта решил сделать ставку на Rails, кроме того, у java-джуна был кореш который как раз искал работу на rails. Я решил нанять парня и не прогадал.
Одним из партнёров в нашей аутсорс шлюпке был крутой фуллстек парень. Кодил он на js, был большим любителем ноды и к тому же отлично знал PHP. К нам тогда по наследству приехал среднего размера проект как раз написанный на PHP, к счастью, на Laravel (это такой аналог Rails в мире PHP, в целом довольно годный), и он ним занимался. Сам проект (который кстати живет и здравствует до сих пор, только поддерживаю его уже я) состоит из бекенда для мобил и SPA и админки для управления контентом и прочим.
Короче, там была админка, которой постоянно пользовались люди. И она выглядела круто! Там был сайдбар, хидер, всякие кнопочки-формочки и так далее, и чтобы писать все это, нужно было совсем немного кода. Я решил разузнать поподробнее как это так получается, так как всегда думал, что кто-то разрабатывал все это с нуля, а реальность оказалась намного прозаичнее — существует полно HTML-шаблонов для админок и прочих штук, и нужно всего лишь добавить себе в ассеты css-ину, js-ину ну и дальше верстать формочки так, чтобы там были нужные стили. В нашем случае таким шаблоном был AdminLTE (https://adminlte.io/themes/AdminLTE/index2.html) — это один из самых популярных, но их есть много разных. Для Laravel даже есть библиотека, которая позволяет интегрировать эти шаблоны в приложение без необходимости верстать всякие сайдбары самому.
Тут до меня потихоньку начало доходить — для того, чтобы делать сносные приложения, совсем необязательно хорошо шарить верстку — достаточно где-то найти подходящий шаблон, а дальше через копипаст переносить себе компоненты и собирать из этого, как из конструктора, рабочее решение. Конечно, для уникальных сайтов это не подойдет, но всякий околоадминский инструментарий, дашборды, аналитика и тд пишутся на ура. Нет, я конечно знал про всякие бутстрапы и прочие "фреймворки", но мне они казались чем-то типа молотка и отвертки которые еще нужно применить, а не экскаватора, которым ты после непродолжительного обучения сможешь рыть ямы со скоростью 300кк/cек. А сайты типа TemplateMonster (кстати один из людей, который стоял у истоков этой компании когда-то был моим боссом в NC) я почему-то всегда воспринимал как наблон шаблонов для екоммерса и джумлы с вротпрессом.
В таких шаблонах практически всегда есть все, что нужно — сайдбар/хидер/футер, колонки, кнопки, формы, таблицы, алерты, модалки, и даже респонсивнесс, все! Там даже есть шаблон чата! Я все думал, зачем это нужно, но (забегая вперед) настал день когда и эта функциональность мне понадобилась (я разрабатывал чатбота и нужно было дать возможность саппорту общаться с людьми без необходимости переключаться между мессенджерами).
Как раз в то время у нас стояла задача сделать админку для нового проекта. Сам проект вначале был запилен на PHP силами одного джуна, потом под моим присмотром перепилен силами другого джуна на Java но в процессе перепиливания мы потеряли админку. Я некоторое время колебался, но, после успешного небольшого проекта решил сделать ставку на Rails, кроме того, у java-джуна был кореш который как раз искал работу на rails. Я решил нанять парня и не прогадал.
👍1
Еда.
Люто бесит необходимость есть чтобы поддерживать бренное тело в этом мире.
Не менее люто бесит отсутствие хоть сколько-нибудь вменяемых и доступных инноваций в сфере питания, которые бы упростили жизнь людям. Производители конечно же производят продукты более эффективно, нежели сто лет назад, у них всё хорошо, мощно возрастаєт дєнь ото дня процент жиров у маслє, но людям от этого кардинально проще жить не становится — по-большому счету, за столетие изменились только скорость и удобство приготовления, и то, в ущерб качеству.
Единственный продукт, который хоть как-то можно считать инновационным — это сойлент и прочие порошки. Но и это не полноценная замена еде, потому что кишкам нужно что-то более твердое и волокнистое. Непонятно, как длительный постоянный прием сойлента скажется на здоровье пациентов и люди вынуждены ставить эксперименты на себе. Как только решат все проблемы с сойлентом — перейду на него. Надеюсь, это случится еще на моем веку. Но даже и его нужно будет потреблять внутрь, вместо того, например, чтобы ставиться каждый день смесью из необходимых организму элементов и вообще забайпассить ЖКТ. Но так не работает, увы — потому что человек — невероятно сложная система которая, если копнуть поглубже, вообще чудом как ходит на двух ногах, все наши потроха выполняют свои функции в удивительной синергии, и попытка подхачить один орган незамедлительно скажется на других. Самый дефолтный пример — плохой прикус/кривые зубы —> хуже пережевывается пища —> хуже переваривается —> хуже работает жкт, меньше производится серотонина —> человек ходит грустный и бонусом получает еще кучу мелких проблем.
Неимоверно раздражает отсутствие в научном мире консенсуса по поводу диеты и того, что хорошо, а что плохо, отсутствие вменяемых длительных(!) исследований на тему влияния тех или иных продуктов на здоровье. Расходятся мнения по поводу того, сколько раз в день нужно есть — один, два, три, десять? На диетах вообще состояния делают — палео, кето, детокс и прочее и прочее — только успевай записывать, что хорошо, а что — плохо. Туда же бады. Люди вообще очень любят волшебные пилюли которые сделают хорошо, и не любят долго и упорно трудиться для достижения результата.
Крайне огорчает лоббирование производителями своих интересов и вообще попытки всячески обмануть человека а так же обилие вредной дряни (вредность которой тоже вызывает дискуссии) в еде. Перед тем как купить любой продукт, нужно внимательно читать, из чего же он состоит, иначе есть риск взять не то — самые очевидные примеры это сок который на самом деле "нектар", масло которое на самом деле "растительный спред" и так далее.
Бесит отсутствие инноваций в приготовлении еды. Максимум на который мы можем рассчитывать — это всякие дрянные полуфабрикаты или мультиварки с хлебопечками. Прогресс застрял на микроволновках с холодильниками.
Все это мне напоминает ежедневный ручной деплой своего барахла на bare-metal инстансы без установленной операционной системы. Каждый день одно и то же, и нельзя написать баш-скрипты, докера шмокера нет, оркестраторы не изборели, каждый день ручками. По три раза.
Я хотел молекулярный конструктор, который будет собирать любую еду из куска угля, щепотки соли и воды, а получил Uber Eats и сотню стартапов по доставке еды, приложения для трекинга калорий, куда нужно вбивать их вручную и смузи по подписке с qr-кодом и выжималкой пакетиков за 300 баксов. Вот и все инновации, куда вливают бабло венчурные капиталисты.
Грустно это все, 2019 год а я до сих пор варю себе гречку. Еда же касается всех и каждого, и бедняка, и богача, так почему же прогресса нет?
Люто бесит необходимость есть чтобы поддерживать бренное тело в этом мире.
Не менее люто бесит отсутствие хоть сколько-нибудь вменяемых и доступных инноваций в сфере питания, которые бы упростили жизнь людям. Производители конечно же производят продукты более эффективно, нежели сто лет назад, у них всё хорошо, мощно возрастаєт дєнь ото дня процент жиров у маслє, но людям от этого кардинально проще жить не становится — по-большому счету, за столетие изменились только скорость и удобство приготовления, и то, в ущерб качеству.
Единственный продукт, который хоть как-то можно считать инновационным — это сойлент и прочие порошки. Но и это не полноценная замена еде, потому что кишкам нужно что-то более твердое и волокнистое. Непонятно, как длительный постоянный прием сойлента скажется на здоровье пациентов и люди вынуждены ставить эксперименты на себе. Как только решат все проблемы с сойлентом — перейду на него. Надеюсь, это случится еще на моем веку. Но даже и его нужно будет потреблять внутрь, вместо того, например, чтобы ставиться каждый день смесью из необходимых организму элементов и вообще забайпассить ЖКТ. Но так не работает, увы — потому что человек — невероятно сложная система которая, если копнуть поглубже, вообще чудом как ходит на двух ногах, все наши потроха выполняют свои функции в удивительной синергии, и попытка подхачить один орган незамедлительно скажется на других. Самый дефолтный пример — плохой прикус/кривые зубы —> хуже пережевывается пища —> хуже переваривается —> хуже работает жкт, меньше производится серотонина —> человек ходит грустный и бонусом получает еще кучу мелких проблем.
Неимоверно раздражает отсутствие в научном мире консенсуса по поводу диеты и того, что хорошо, а что плохо, отсутствие вменяемых длительных(!) исследований на тему влияния тех или иных продуктов на здоровье. Расходятся мнения по поводу того, сколько раз в день нужно есть — один, два, три, десять? На диетах вообще состояния делают — палео, кето, детокс и прочее и прочее — только успевай записывать, что хорошо, а что — плохо. Туда же бады. Люди вообще очень любят волшебные пилюли которые сделают хорошо, и не любят долго и упорно трудиться для достижения результата.
Крайне огорчает лоббирование производителями своих интересов и вообще попытки всячески обмануть человека а так же обилие вредной дряни (вредность которой тоже вызывает дискуссии) в еде. Перед тем как купить любой продукт, нужно внимательно читать, из чего же он состоит, иначе есть риск взять не то — самые очевидные примеры это сок который на самом деле "нектар", масло которое на самом деле "растительный спред" и так далее.
Бесит отсутствие инноваций в приготовлении еды. Максимум на который мы можем рассчитывать — это всякие дрянные полуфабрикаты или мультиварки с хлебопечками. Прогресс застрял на микроволновках с холодильниками.
Все это мне напоминает ежедневный ручной деплой своего барахла на bare-metal инстансы без установленной операционной системы. Каждый день одно и то же, и нельзя написать баш-скрипты, докера шмокера нет, оркестраторы не изборели, каждый день ручками. По три раза.
Я хотел молекулярный конструктор, который будет собирать любую еду из куска угля, щепотки соли и воды, а получил Uber Eats и сотню стартапов по доставке еды, приложения для трекинга калорий, куда нужно вбивать их вручную и смузи по подписке с qr-кодом и выжималкой пакетиков за 300 баксов. Вот и все инновации, куда вливают бабло венчурные капиталисты.
Грустно это все, 2019 год а я до сих пор варю себе гречку. Еда же касается всех и каждого, и бедняка, и богача, так почему же прогресса нет?
О неработающем скраме.
Никогда не работал в командах, где бы скрам или какой-то другой сорт аджайла реально приносил пользу а не был карго-культом. Не утверждаю, что таких команд нет, но мне вот как-то не везло, так что это не критика скрама а анекдтодическое нытье про его плохие имплементации.
Все постоянно опаздывают на стендапы, постоянно, хоть один человек но да и будет отсутствовать! Причина этого проста — стендап никому не нужен, ценности никакой для команды не несет поэтому люди подсознательно не понимают, зачем им туда ходить, и позволяют себе забивать.
В полной мере согласен с бесполезностью стендапов. Вместо них куда проще и надежнее использовать автоматические чек-ины во всяких слаках типа "вчера я работал над Х, сегодня над Y".
Короче стендапы есть, но толку от них нет.
Демы для продукт овнера — ну такое, вначале когда все горят энтузиазмом то что-то показывают, но потом эта практика как-то сходила на нет. Тут проблема возможно была глубже — по скраму у тебя в конце итерации должен быть работающий продукт, а у нас его часто не было ) или бекенд был, но его не особо покажешь, правильно? Все это создает фрустрацию и ощущение того, что ты делаешь бесполезную работу.
Ретроспективы — ваще не знаю зачем это, зря потраченное время. Ни разу ничего толкового из них не извлекли. А даже если и извлекали, то ничего не делали и ретро превращалось в формальность.
Планирование, покер планниг — ну вы понели, давайте за 5 минут оценим фичу. В оценках часто ошибались, но тут коллега который работал по настоящему скраму подсказывает что на планнинг надо тратить целый день. Бесполезняк. За день можно не языками молоть а сделать прототипы каждой из фич. Короче планнинг тоже становился формальностью и игрой в шопопало.
Но самое ужасное что преследовало меня всегда — это невыполненные до конца спринты. Так или иначе, фичи продалбывались и burndown chart не сходился. Не знаю как у других, а у меня от этого горело постоянно. Как так — работаем полгода и каждые две недели мы не выполняем план? Ретро не помогают, стендапы не помогают, оценка не помогает, ничего не помогает, все равно в конце спринта поинтов сделано вполовину. А продукт овнер не хочет ставить цели ниже, вот и получается перманентная фрустрация. Лучше уж работать как-нибудь и выдавать что-нибудь, нежели постоянно быть под давлением дедлайна, грустно смотреть друг на друга на закрытии спринта и на график в виде буквы Г наоброт, а не на красивую линию "\".
Кстати я на собесах всегда спрашиваю "как часто вы продалбываете спринты" и в своем прошлом вояже минимум половина ответила "всегда". Зачем так жить, котаны?
В итоге весь скрам скатывался вот в такое нечто-итеративное с внешними ритуалами скрама но без внутреннего огня благодаря которому стартап бы делался за два месяца а не за два года.
С одной стороны я понимаю, что без планирования и дедлайнов нельзя, а с другой — что задача всегда займет все отведенное на неё время. И даже больше. Не придумал ничего, что с этим можно сделать, кроме как работать самому, не зависеть ни от кого, не подписываться на жёсткие дедлайны и бить все на совсем уж мелкие задачи.
Никогда не работал в командах, где бы скрам или какой-то другой сорт аджайла реально приносил пользу а не был карго-культом. Не утверждаю, что таких команд нет, но мне вот как-то не везло, так что это не критика скрама а анекдтодическое нытье про его плохие имплементации.
Все постоянно опаздывают на стендапы, постоянно, хоть один человек но да и будет отсутствовать! Причина этого проста — стендап никому не нужен, ценности никакой для команды не несет поэтому люди подсознательно не понимают, зачем им туда ходить, и позволяют себе забивать.
В полной мере согласен с бесполезностью стендапов. Вместо них куда проще и надежнее использовать автоматические чек-ины во всяких слаках типа "вчера я работал над Х, сегодня над Y".
Короче стендапы есть, но толку от них нет.
Демы для продукт овнера — ну такое, вначале когда все горят энтузиазмом то что-то показывают, но потом эта практика как-то сходила на нет. Тут проблема возможно была глубже — по скраму у тебя в конце итерации должен быть работающий продукт, а у нас его часто не было ) или бекенд был, но его не особо покажешь, правильно? Все это создает фрустрацию и ощущение того, что ты делаешь бесполезную работу.
Ретроспективы — ваще не знаю зачем это, зря потраченное время. Ни разу ничего толкового из них не извлекли. А даже если и извлекали, то ничего не делали и ретро превращалось в формальность.
Планирование, покер планниг — ну вы понели, давайте за 5 минут оценим фичу. В оценках часто ошибались, но тут коллега который работал по настоящему скраму подсказывает что на планнинг надо тратить целый день. Бесполезняк. За день можно не языками молоть а сделать прототипы каждой из фич. Короче планнинг тоже становился формальностью и игрой в шопопало.
Но самое ужасное что преследовало меня всегда — это невыполненные до конца спринты. Так или иначе, фичи продалбывались и burndown chart не сходился. Не знаю как у других, а у меня от этого горело постоянно. Как так — работаем полгода и каждые две недели мы не выполняем план? Ретро не помогают, стендапы не помогают, оценка не помогает, ничего не помогает, все равно в конце спринта поинтов сделано вполовину. А продукт овнер не хочет ставить цели ниже, вот и получается перманентная фрустрация. Лучше уж работать как-нибудь и выдавать что-нибудь, нежели постоянно быть под давлением дедлайна, грустно смотреть друг на друга на закрытии спринта и на график в виде буквы Г наоброт, а не на красивую линию "\".
Кстати я на собесах всегда спрашиваю "как часто вы продалбываете спринты" и в своем прошлом вояже минимум половина ответила "всегда". Зачем так жить, котаны?
В итоге весь скрам скатывался вот в такое нечто-итеративное с внешними ритуалами скрама но без внутреннего огня благодаря которому стартап бы делался за два месяца а не за два года.
С одной стороны я понимаю, что без планирования и дедлайнов нельзя, а с другой — что задача всегда займет все отведенное на неё время. И даже больше. Не придумал ничего, что с этим можно сделать, кроме как работать самому, не зависеть ни от кого, не подписываться на жёсткие дедлайны и бить все на совсем уж мелкие задачи.
О сломанных авто/интеграционных тестах.
Люблю тесты. Особенно интеграционные или авто (те которые в браузере кликают). Запустил — и сидишь смотришь как у тебя все красиво и все работает.
Одна проблема.
Такие тесты всегда сломаны. Всегда, просто всегда. Конечно, поначалу, пока сценариев мало, то все красивое и зелененькое. Но как только продукт становится чуть более сложным чем сайт-визитка с формой контакта, то моментально наступает коллапс. Длительность прохождения сценариев увеличивается экспоненциально, количество мест отказа в распределенной системе и комбинаций сбоев разных подсистем так же растет, в итоге мы имеем по факту тесты которые могут сказать только "не работает вообще ничего" (логин отвалился) или требуют квалифицированного QA для анализа того, что же действительно упало. В 99% случаев падает из-за таймаута/редеплоя/устаревшего сценария/умершего селениума/съеденной памяти на CI-сервере.
Со временем команда привыкает к перманентно сломанным тестам, это становится обычным делом, и никто уже не реагирует на возгласы умирающего дженкинса в слак-канале
И снова, мне как-то не везло работать в командах, где тесты работали бы надежно и где успешно пройденный e2e тест был бы ежечасной реальностью а не еженедельным исключением. При этом не писать тесты себе дороже — даже в сломанном виде они позволяют хоть как-то гарантировать, что на выпуск идет хоть работающий продукт а не пятисотая на главной. За качество тестов всеми силами борются автоматизаторы и QA но и они проигрывают это сражение и с опущеными знамёнами идут тестировать вручную. А учитывая количество времени, требуемое на поддержку инфраструктуры тестов, менеджмент имеет все меньше желания отдавать половину команды на эти активности и пускает все на самотёк.
В общем как-то все плохо и что с этим делать непонятно. В этом свете забавно выглядят продукты, которые предлагают вам просто писать скрипты на человеческом языке, а дальше этот скрипт будет выполняться ротой бравых ребят из Бангалора, в любых браузерах и на любых окружениях. С детальными отчетами, отличной параллелизацией и почти неограниченным пулом "вычислительных мощностей" 🙂 Осталось только изобрести нейроинтерфейс чтобы скрипты закачивались прямо в мозг.
Люблю тесты. Особенно интеграционные или авто (те которые в браузере кликают). Запустил — и сидишь смотришь как у тебя все красиво и все работает.
Одна проблема.
Такие тесты всегда сломаны. Всегда, просто всегда. Конечно, поначалу, пока сценариев мало, то все красивое и зелененькое. Но как только продукт становится чуть более сложным чем сайт-визитка с формой контакта, то моментально наступает коллапс. Длительность прохождения сценариев увеличивается экспоненциально, количество мест отказа в распределенной системе и комбинаций сбоев разных подсистем так же растет, в итоге мы имеем по факту тесты которые могут сказать только "не работает вообще ничего" (логин отвалился) или требуют квалифицированного QA для анализа того, что же действительно упало. В 99% случаев падает из-за таймаута/редеплоя/устаревшего сценария/умершего селениума/съеденной памяти на CI-сервере.
Со временем команда привыкает к перманентно сломанным тестам, это становится обычным делом, и никто уже не реагирует на возгласы умирающего дженкинса в слак-канале
#tests. И снова, мне как-то не везло работать в командах, где тесты работали бы надежно и где успешно пройденный e2e тест был бы ежечасной реальностью а не еженедельным исключением. При этом не писать тесты себе дороже — даже в сломанном виде они позволяют хоть как-то гарантировать, что на выпуск идет хоть работающий продукт а не пятисотая на главной. За качество тестов всеми силами борются автоматизаторы и QA но и они проигрывают это сражение и с опущеными знамёнами идут тестировать вручную. А учитывая количество времени, требуемое на поддержку инфраструктуры тестов, менеджмент имеет все меньше желания отдавать половину команды на эти активности и пускает все на самотёк.
В общем как-то все плохо и что с этим делать непонятно. В этом свете забавно выглядят продукты, которые предлагают вам просто писать скрипты на человеческом языке, а дальше этот скрипт будет выполняться ротой бравых ребят из Бангалора, в любых браузерах и на любых окружениях. С детальными отчетами, отличной параллелизацией и почти неограниченным пулом "вычислительных мощностей" 🙂 Осталось только изобрести нейроинтерфейс чтобы скрипты закачивались прямо в мозг.
👍1
VR для нищих
Ходили сегодня в VR-"салон" (не знаю как это правильно назвать). Короче такое место в трц, там сделаны такие "клетки" из дерева 2х2 метра, висят окулусы/htc на подвеске сверху, чтобы провода не путались (на вайфай не хватило денег или не рентабельно), дают в руки контроллеры и вперед.
Перед этим я был в VR год назад в квест комнате. Там был сидячий вариант (садишься в кресло и не двигаешься, только вертишь головой и руками), зато с трекингом рук, но даже этот простой квест (чё-то там в космосе, надо короче ядерный реактор спасать от взрыва), оказал на меня неизгладимое впечатление. Смотришь руку а она оцифрована, можно нажимать кнопки в воздухе и все это почти без задержки! Настоящий киберпанк, как в моём любимом джонни мнемонике (ставь лайк если ты пересматривал сцену с киберпространством)! В общем очень круто. Я тогда еще подумал что скоро вся индустрия квест-комнат из забавного шоу с бутафорскими антуражами превратится в пыльные бетонные подвалы с четырьмя креслами, окулусами и скучающим оператором. По идее разработка новых комнат и их масштабирование должно быть намного проще чем воплощение всего в натуре.
Год прошел а VR-комнаты походу так и не набрали большой популярности. Странно.
Сегодня же был стоячий вариант (можно ходить!), но с контроллерами вместо рук. Играли в какой-то тавер дефенс, где надо было отстреливать орков из лука, зомби апокалипсис, где нужно отстреливать уже зомби, хождение по доске над небоскрёбом и super hot — адовый шутан с интересной механикой и кровь-кишки-осколки.
VR меня люто вштырил. Мозги обманываются на ура и это очень впечатляет. Если выбирать игорь с физической активностью (например в тавер дефенсе нужно натягивать тетитву, в super hot уклоняться) то можно нехило так вспотеть. Очень круто, даже несмотря на полное отсутствие физической обратной связи. 15 лет назад когда я фанател от Лабиринтов Отражений и Фальшивых Зеркал такая штука наверное вообще бы мозг вынесла, хе-хе.
Самое главное ограничение всех VR-штук — нельзя ходить, лишь в пределах условной безопасной зоны 2х2. Разные игры обходят это ограничение по разному, делают костыли кто во то горазд, но в целом это несколько портит впечатление. В остальном — очень даже покатит. Более детальный твитор тред с разборами недостатков текущей технологии и объяснениями почему уже 10 год прошло а мы до сих пор ходим на работу в офис, вместо того чтобы валяться в креслах подключенными в VR — https://twitter.com/oulasvirta/status/1103298711382380545.
Если вы еще не пробовали VR — обязательно попробуйте. Щас по идее даже в небольших городах должны быть салоны, и это удовольствие, тебе, дорогой читатель, уж точно по карману.
Ходили сегодня в VR-"салон" (не знаю как это правильно назвать). Короче такое место в трц, там сделаны такие "клетки" из дерева 2х2 метра, висят окулусы/htc на подвеске сверху, чтобы провода не путались (на вайфай не хватило денег или не рентабельно), дают в руки контроллеры и вперед.
Перед этим я был в VR год назад в квест комнате. Там был сидячий вариант (садишься в кресло и не двигаешься, только вертишь головой и руками), зато с трекингом рук, но даже этот простой квест (чё-то там в космосе, надо короче ядерный реактор спасать от взрыва), оказал на меня неизгладимое впечатление. Смотришь руку а она оцифрована, можно нажимать кнопки в воздухе и все это почти без задержки! Настоящий киберпанк, как в моём любимом джонни мнемонике (ставь лайк если ты пересматривал сцену с киберпространством)! В общем очень круто. Я тогда еще подумал что скоро вся индустрия квест-комнат из забавного шоу с бутафорскими антуражами превратится в пыльные бетонные подвалы с четырьмя креслами, окулусами и скучающим оператором. По идее разработка новых комнат и их масштабирование должно быть намного проще чем воплощение всего в натуре.
Год прошел а VR-комнаты походу так и не набрали большой популярности. Странно.
Сегодня же был стоячий вариант (можно ходить!), но с контроллерами вместо рук. Играли в какой-то тавер дефенс, где надо было отстреливать орков из лука, зомби апокалипсис, где нужно отстреливать уже зомби, хождение по доске над небоскрёбом и super hot — адовый шутан с интересной механикой и кровь-кишки-осколки.
VR меня люто вштырил. Мозги обманываются на ура и это очень впечатляет. Если выбирать игорь с физической активностью (например в тавер дефенсе нужно натягивать тетитву, в super hot уклоняться) то можно нехило так вспотеть. Очень круто, даже несмотря на полное отсутствие физической обратной связи. 15 лет назад когда я фанател от Лабиринтов Отражений и Фальшивых Зеркал такая штука наверное вообще бы мозг вынесла, хе-хе.
Самое главное ограничение всех VR-штук — нельзя ходить, лишь в пределах условной безопасной зоны 2х2. Разные игры обходят это ограничение по разному, делают костыли кто во то горазд, но в целом это несколько портит впечатление. В остальном — очень даже покатит. Более детальный твитор тред с разборами недостатков текущей технологии и объяснениями почему уже 10 год прошло а мы до сих пор ходим на работу в офис, вместо того чтобы валяться в креслах подключенными в VR — https://twitter.com/oulasvirta/status/1103298711382380545.
Если вы еще не пробовали VR — обязательно попробуйте. Щас по идее даже в небольших городах должны быть салоны, и это удовольствие, тебе, дорогой читатель, уж точно по карману.
О работе с мудаками 1
Некоторое время назад читал текст о том, нужно ли работать с мудаками. Рассуждения автора были примерно такими — работа с профессионалами, в здоровом коллективе без внутренних конфликтов — это конечно хорошо, но это тепличные условия. В них ты не научишься разруливать сложные ситуации, которые будут у тебя возникать потом как в профессиональной деятельности, так и по жизни вообще. Поэтому работать с мудаками полезно, прокачиваешь всякие разные скиллы, обрастаешь каменной кожей и закаляешь внутренний стержень. А для борьбы с непременно возникающим от такого превозмогания стрессом нам предлагают медитации, осознанность и почие нью-эйджевские приколы.
Определенный смысл безусловно в этом есть. Это как истории про мамаш, которые детей специально отправляют поваляться в грязи чтобы иммунитет норм был vs родители которые оберегают любимое чадо от любых внешних воздействий гадкого внешнего мира.
Как и в любом деле здесь важен баланс. Я довольно долго проработал в среде, которую нельзя назвать прям ваще токсичной, но которая явно препятствовала развитию в интересном мне направлении. Любая большая корпорация — это такая среда. Если ты не добрался достаточно высоко, или не работаешь в каком-нибудь около-RnD отделе, где ты можешь быть себе хозяином, то везде будешь натыкаться на стены бюрократического взаимодействия. Хочешь внедрить новую технологию? Докажи главному инженеру компании что эта штука нужна. И позови на защиту своего решения еще десяток людей со смежных отделов, им ведь тоже интересно! Хочешь разработать новый продукт? Изволь составить подробный план и презентацию (и пофиг что план станет бесполезным уже через месяц после работы), выбей откуда-то людей, подожди пол-года чтобы решить все бюрократические проволочки, а потом начнется пожар на другом проекте, и до твоего уже никому не будет дела. Корпорации защищают себя от изменений, и это происходит естественным путём. То ли дело мелкий стартап, где ты и жнец и швец и кузнец, и волен делать всё, что хочешь.
Из места, где нужно тратить условную половину времени на решение бюрократически-политических вопросов, нужно валить, если только тебе это не приносит удовольствия (есть люди которые тащатся от политики, я даже сам немного таким был). Нужно фокусироваться на решении производственных задач, а не на борьбе за власть принимать решения. Вот потрачу я пол-года на подготовку и защиту проекта перед топ-менеджерами, которые чихать на это хотели — безусловно, задача достойная, но не лучше ли было бы все это время потратить более продуктивно — сделав одну-две итерации и проверив ключевые гипотезы? Что лучше — получить навык работы в высокобюрократизированной среде, или навык быстрого запуска продуктов?
Однако чем дальше в лес, тем больше я понимаю, что силами одного человека можно сделать многое (привет, фуллстек на минималках!), а закалка своей шкуры в неравных боях с корпоративной машиной однозначно того не стоит. Видишь, что вокруг тебя работают люди, которым интересно оставаться там, где они есть и делать то, что они сейчас делают, а любые инновации и изменения вызывают в них моментальное отторжение? Ну что ж, можно попробовать переубедить их, но не стоит тратить на это много усилий. Лучше свалить туда, где можно будет оттачивать реальные навыки работы с рынком, с пользователями, быстро тестировать решения и выводить их в продакшн, быть в окружении людей которые думают схожим образом, открыты к инновациям и не страдают синдромом вахтёра.
Сам свалил и ни дня не пожалел об этом.
Некоторое время назад читал текст о том, нужно ли работать с мудаками. Рассуждения автора были примерно такими — работа с профессионалами, в здоровом коллективе без внутренних конфликтов — это конечно хорошо, но это тепличные условия. В них ты не научишься разруливать сложные ситуации, которые будут у тебя возникать потом как в профессиональной деятельности, так и по жизни вообще. Поэтому работать с мудаками полезно, прокачиваешь всякие разные скиллы, обрастаешь каменной кожей и закаляешь внутренний стержень. А для борьбы с непременно возникающим от такого превозмогания стрессом нам предлагают медитации, осознанность и почие нью-эйджевские приколы.
Определенный смысл безусловно в этом есть. Это как истории про мамаш, которые детей специально отправляют поваляться в грязи чтобы иммунитет норм был vs родители которые оберегают любимое чадо от любых внешних воздействий гадкого внешнего мира.
Как и в любом деле здесь важен баланс. Я довольно долго проработал в среде, которую нельзя назвать прям ваще токсичной, но которая явно препятствовала развитию в интересном мне направлении. Любая большая корпорация — это такая среда. Если ты не добрался достаточно высоко, или не работаешь в каком-нибудь около-RnD отделе, где ты можешь быть себе хозяином, то везде будешь натыкаться на стены бюрократического взаимодействия. Хочешь внедрить новую технологию? Докажи главному инженеру компании что эта штука нужна. И позови на защиту своего решения еще десяток людей со смежных отделов, им ведь тоже интересно! Хочешь разработать новый продукт? Изволь составить подробный план и презентацию (и пофиг что план станет бесполезным уже через месяц после работы), выбей откуда-то людей, подожди пол-года чтобы решить все бюрократические проволочки, а потом начнется пожар на другом проекте, и до твоего уже никому не будет дела. Корпорации защищают себя от изменений, и это происходит естественным путём. То ли дело мелкий стартап, где ты и жнец и швец и кузнец, и волен делать всё, что хочешь.
Из места, где нужно тратить условную половину времени на решение бюрократически-политических вопросов, нужно валить, если только тебе это не приносит удовольствия (есть люди которые тащатся от политики, я даже сам немного таким был). Нужно фокусироваться на решении производственных задач, а не на борьбе за власть принимать решения. Вот потрачу я пол-года на подготовку и защиту проекта перед топ-менеджерами, которые чихать на это хотели — безусловно, задача достойная, но не лучше ли было бы все это время потратить более продуктивно — сделав одну-две итерации и проверив ключевые гипотезы? Что лучше — получить навык работы в высокобюрократизированной среде, или навык быстрого запуска продуктов?
Однако чем дальше в лес, тем больше я понимаю, что силами одного человека можно сделать многое (привет, фуллстек на минималках!), а закалка своей шкуры в неравных боях с корпоративной машиной однозначно того не стоит. Видишь, что вокруг тебя работают люди, которым интересно оставаться там, где они есть и делать то, что они сейчас делают, а любые инновации и изменения вызывают в них моментальное отторжение? Ну что ж, можно попробовать переубедить их, но не стоит тратить на это много усилий. Лучше свалить туда, где можно будет оттачивать реальные навыки работы с рынком, с пользователями, быстро тестировать решения и выводить их в продакшн, быть в окружении людей которые думают схожим образом, открыты к инновациям и не страдают синдромом вахтёра.
Сам свалил и ни дня не пожалел об этом.
Фуллстек на минималках. Фронтенд для бекендеров 6
Предыдущие серии: 1 (t.me/full_of_hatred/85), 2 (t.me/full_of_hatred/86), 3 (t.me/full_of_hatred/88), 4 (t.me/full_of_hatred/90), 5 (t.me/full_of_hatred/92)
Итак, нам нужно было сделать админку. Для этого мною был прособеседован и нанят Rails джун, и мы приступили. Для Rails есть много разных админок, но все они проигрывают по красоте AdminLTE (adminlte.io), поэтому, после пары дней исследований было решено велосипедить свое решение, без хитрых генераторов, а для стилей взять вышеупомянутый AdminLTE.
Буквально через неделю у нас уже была вполне работающее приложение с базовыми функциями. К таблицам были прикручены сортировки и стили, пагинация, формочки и так далее. Если нужно было добавить еще какую-то сущность ("заказы" например) то все таблицы и формы просто копипастились, менялись названия контроллеров, полей и прочего и все это выкатывалось. Копипаст конечно не очень хорошо, но в нашем случае пришлось бы изобретать свой генератор, который так или иначе упирался в граничные кейсы (таблицы и формы иногда были разными). Все это выглядело довольно красиво и было несложным в доработке и поддержке. Заказчик доволен, пользователям все удобно, все счастливы. Приложение до сих пор живет в продакшене и активно используется.
После такого успеха я уверовал в шаблоны и на протяжении следующего года мы сделали еще два похожих проекта. Во всех случаях на фронтенд мы не тратили времени вообще — просто собирали страницы из готовых компонент и фокусировались на реализации бизнес-логики.
Есть конечно у такого подхода своя обратная сторона — когда нужно сделать сложную форму, или валидацию, или взаимосвязь между элементами на странице то на сцену выходит б-гомерзкий jQuery со своими низкоуровневыми манипуляциями DOM деревом, и тут уже надо немного думать, как все это дело грамотно организовать.
Поэтому, для следующего проекта я решил немного заморочиться и сделать фронтенд на реакте. Для реакта есть не так много вменяемых шаблонов админок (а те, которые есть, часто идут с jQuery впридачу), поэтому после трех дней изысканий я купил за 20 баксов чисто CSS-ный шаблон основанный на Bulma (bulma.io) и пошел учить реакт, благо основы постигаются буквально за полчаса, а дальше только успевай строгать компоненты.
Итог повествования такой — если вы норм бекенд чувак и еще не фуллстечите на минималках — то советую попробовать поделать вот такие простые штуки для внутренних нужд (настроек всяких микросервисов, аналитики/мониторинга, админок для саппорта и т.д.). Реально развязывает руки и позволяет сделать приложение от начала до конца в одиночку, без необходимости бегать за просьбами сделать верстку к ребятам обсуждающим всякие стрёмные вещи типа флексбоксов и новых реакт хуков.
Ну а со временем и практикой уже появится понимание, что к чему в стилях, и обучение html/css будет происходить естественным путём.
Предыдущие серии: 1 (t.me/full_of_hatred/85), 2 (t.me/full_of_hatred/86), 3 (t.me/full_of_hatred/88), 4 (t.me/full_of_hatred/90), 5 (t.me/full_of_hatred/92)
Итак, нам нужно было сделать админку. Для этого мною был прособеседован и нанят Rails джун, и мы приступили. Для Rails есть много разных админок, но все они проигрывают по красоте AdminLTE (adminlte.io), поэтому, после пары дней исследований было решено велосипедить свое решение, без хитрых генераторов, а для стилей взять вышеупомянутый AdminLTE.
Буквально через неделю у нас уже была вполне работающее приложение с базовыми функциями. К таблицам были прикручены сортировки и стили, пагинация, формочки и так далее. Если нужно было добавить еще какую-то сущность ("заказы" например) то все таблицы и формы просто копипастились, менялись названия контроллеров, полей и прочего и все это выкатывалось. Копипаст конечно не очень хорошо, но в нашем случае пришлось бы изобретать свой генератор, который так или иначе упирался в граничные кейсы (таблицы и формы иногда были разными). Все это выглядело довольно красиво и было несложным в доработке и поддержке. Заказчик доволен, пользователям все удобно, все счастливы. Приложение до сих пор живет в продакшене и активно используется.
После такого успеха я уверовал в шаблоны и на протяжении следующего года мы сделали еще два похожих проекта. Во всех случаях на фронтенд мы не тратили времени вообще — просто собирали страницы из готовых компонент и фокусировались на реализации бизнес-логики.
Есть конечно у такого подхода своя обратная сторона — когда нужно сделать сложную форму, или валидацию, или взаимосвязь между элементами на странице то на сцену выходит б-гомерзкий jQuery со своими низкоуровневыми манипуляциями DOM деревом, и тут уже надо немного думать, как все это дело грамотно организовать.
Поэтому, для следующего проекта я решил немного заморочиться и сделать фронтенд на реакте. Для реакта есть не так много вменяемых шаблонов админок (а те, которые есть, часто идут с jQuery впридачу), поэтому после трех дней изысканий я купил за 20 баксов чисто CSS-ный шаблон основанный на Bulma (bulma.io) и пошел учить реакт, благо основы постигаются буквально за полчаса, а дальше только успевай строгать компоненты.
Итог повествования такой — если вы норм бекенд чувак и еще не фуллстечите на минималках — то советую попробовать поделать вот такие простые штуки для внутренних нужд (настроек всяких микросервисов, аналитики/мониторинга, админок для саппорта и т.д.). Реально развязывает руки и позволяет сделать приложение от начала до конца в одиночку, без необходимости бегать за просьбами сделать верстку к ребятам обсуждающим всякие стрёмные вещи типа флексбоксов и новых реакт хуков.
Ну а со временем и практикой уже появится понимание, что к чему в стилях, и обучение html/css будет происходить естественным путём.
Переключение раскладки клавиатуры 1
Нам ужасно не повезло — в наших странах используются кириллические шрифты, в то время как в огромной части остального мира — латинница. Приходится держать две раскладки, но мне (и многим другим) не повезло еще больше — половина всего, что я выстукиваю кириллицей — на украинском, поэтому добавляется еще и третья раскладка.
Дефолтный вариант с
В какой-то момент мне это все надоело, и я назначил каждой раскладке свою комбинацию клавиш —
Особые отношения у меня были с кнопкой Caps Lock. За все года, проведенные за компьютером, эта кнопка мне не пригодилась ни разу. Многим другим скорее всего, тоже, но производители уперто продолжают засовывать её во все без исключения клавиатуры. Вот она — сила инерции! Так как мне не нравилось ошибаться и нажимать на эту кнопку, то я просто доставал или выламывал её из всех своих клавиатур. Нет кнопки — нет проблем 🙂
На маке, к сожалению, из коробки нет возможности назначать отдельную комбинацию на каждый язык, и еще хуже, что дефолтная комбинация
Нам ужасно не повезло — в наших странах используются кириллические шрифты, в то время как в огромной части остального мира — латинница. Приходится держать две раскладки, но мне (и многим другим) не повезло еще больше — половина всего, что я выстукиваю кириллицей — на украинском, поэтому добавляется еще и третья раскладка.
Дефолтный вариант с
ctrl+shift который нам предлагает Шиндовс, неустойчив к ошибкам. За многие года я так и не научился запоминать, сколько раз мне нужно нажать комбинацию, чтобы переключить раскладку — нужно постоянно смотреть на иконку в трее, это сбивает фокус и снижает скорость печати, особенно если в речь нужно вставлять всякие технические термины на английском. Сложность алгоритма — O(n).В какой-то момент мне это все надоело, и я назначил каждой раскладке свою комбинацию клавиш —
alt+shit+1/2/3 для английской, русской и украинской. Таким образом я всегда точно знал какую одну комбинацию мне нужно нажать, для того, чтобы выбрать нужную раскладку. Сложность понизилась до O(1), но появились ошибки, вызванные не одновременным нажатием на клавиши — в некоторых программах на alt+1/2/3 повешены какие-то действия и иногда это приводило к неожиданным эффектам. Тем не менее, я довольно долго жил на такой конфигурации, и был вполне доволен, пока не переехал на мак.Особые отношения у меня были с кнопкой Caps Lock. За все года, проведенные за компьютером, эта кнопка мне не пригодилась ни разу. Многим другим скорее всего, тоже, но производители уперто продолжают засовывать её во все без исключения клавиатуры. Вот она — сила инерции! Так как мне не нравилось ошибаться и нажимать на эту кнопку, то я просто доставал или выламывал её из всех своих клавиатур. Нет кнопки — нет проблем 🙂
На маке, к сожалению, из коробки нет возможности назначать отдельную комбинацию на каждый язык, и еще хуже, что дефолтная комбинация
cmd+space используется в IDE, в которой я работаю, для автокомплита. Поэтому я перебил смену раскладки на комбинацию cmd+shift+2. В перспективе это решение оказалось большой ошибкой, потому что я постоянно нажимал эту комбинацию не одновременно и часто ошибался, вызывая забавные эффекты (например выход из программы или вызов каких-то настроек). Я промучился примерно два года, прежде чем попал на статью Никиты Прокопова про раскладки и не прочитал в камментах о том, что можно забить переключение раскладки на Caps Lock. Был быстро проведен гуглеж, установлен карабинер и еще какие-то штуки и теперь у меня переключение раскладки происходит одной кнопкой, прямо как РУС-ЛАТ на древних клавиатурах. Думаю что на винде тоже можно сделать такой трюк. Достоинства очевидны — вместо комбинации надо нажимать одну кнопку, Caps Lock наконец-то получает значимую роль, снижается количество ошибок при наборе, в общем одни профиты. Ура! Осталось решить проблему трех раскладок.Переключение раскладки клавиатуры 2
На маках есть еще одна проблема — дефолтные кириллические раскладки отличаются от тех, что на винде. В процессе гугления стандартной раскладки я попал на знаменитую типографскую раскладку Ильи Бирмана. Там помимо возврата знака вопроса на его законное место, добавлено еще куча всяких полезных штук, самой часто используемой из которых у меня есть длинное тире —. Искушённый читатель наверняка это заметил: разница между - – — очевидна, а я всегда использую длинное тире 🙂
Всякие типографские символы там забиты на комбинации
Никита же пошёл еще дальше, и модифицировал раскладку полностью — убрав необходимость использовать нажатие
Тупо, что многие вещи были сделаны как попало, никто не хочет/не может их заменить и огромное количество людей страдает, совершая каждый день неэффективные действия, а забота об эргономике своего места — это почему-то удел задротов (тех самых, которые покупают себе девайсы вроде Truly Ergonomic (https://trulyergonomic.com/store/index.php), или Kinesis (https://kinesis-ergo.com/products/#keyboards).
Ультимативным решением проблемы раскладок был бы переход на латинницу, но, при всех достоинствах этого решения, mne ono sovsem ne po dushe. Надо было переходить еще при союзе, тогда бы бы ок 🙂
На маках есть еще одна проблема — дефолтные кириллические раскладки отличаются от тех, что на винде. В процессе гугления стандартной раскладки я попал на знаменитую типографскую раскладку Ильи Бирмана. Там помимо возврата знака вопроса на его законное место, добавлено еще куча всяких полезных штук, самой часто используемой из которых у меня есть длинное тире —. Искушённый читатель наверняка это заметил: разница между - – — очевидна, а я всегда использую длинное тире 🙂
Всякие типографские символы там забиты на комбинации
alt+символ и тут мне пришла в голову другая мысль — наверняка ведь можно забить в одну раскладку дополнительные символы — і, ї, ґ, є, чтобы не держать две кириллических раскладки. Оказалось что эту задачу до меня же решили, и я каким-то образом нагуглил раскладку Бирмана с добавленными нужными символами на хабре (https://habr.com/ru/post/130471/) установил и был таков! Наверняка есть похожие решения для винды, так что если вы вдруг страдаете от трёхъязычности срочно избавляйтесь.Никита же пошёл еще дальше, и модифицировал раскладку полностью — убрав необходимость использовать нажатие
shift для печати запятой и точки (https://tonsky.livejournal.com/318571.html). Это следующий этап, я до него пока не добрался, потому что привычка очень сильна, но обязательно буду пробовать.Тупо, что многие вещи были сделаны как попало, никто не хочет/не может их заменить и огромное количество людей страдает, совершая каждый день неэффективные действия, а забота об эргономике своего места — это почему-то удел задротов (тех самых, которые покупают себе девайсы вроде Truly Ergonomic (https://trulyergonomic.com/store/index.php), или Kinesis (https://kinesis-ergo.com/products/#keyboards).
Ультимативным решением проблемы раскладок был бы переход на латинницу, но, при всех достоинствах этого решения, mne ono sovsem ne po dushe. Надо было переходить еще при союзе, тогда бы бы ок 🙂
Вакансии в поверпоинте
Время вот времени получаю от рекрутёров предложения в виде ссылки на документ с вакансией.
Часто это гугл-док на страничку — удобно для рекрутёра и для нанимателя, они могут одновременно редактировать вакансию и не нужно перекидываться друг в друга правками в мессенджерах и почте — сам так делал. Неудобно для кандидата — открывать ссылку, читать чё-то там, что за дичь?
Абсолютно все(!) требования к любым вакансиям легко умещаются в абзац-другой неформатированного текста и могут быть озвучены еще в первом сообщении от рекрутёра, но это же слишком просто для такой тонкой вещи как найм околотехнарей и мозг начинает работать в стремлении раскатать потенциальных кандидатов оригинальностью подачи.
Особенно меня радуют такие порождения корпоративного мира как презентации. Духота переговорки, человек с лазерной указкой монотонно вещающий что-то, люди втыкающие в телефоны, постоянно обрывающаяся телеконференция, "коллеги мы все on the same page?", бессмысленные графики и обязательный фирменный стиль на презентации мутным потоком выплескиваются на меня прямо из монитора и погружают сознание в кошмар где 4 таких митинга в день с интервалом в час, на всех нужно обязательно быть, а на некоторые нужно готовить презентацию самому.
Итак, что же нас ждет в этой славной отрыжке корпоративного червя ловко владеющего основным инструментом убеждения окружающих в собственной ценности?
- прикольная картинка и название компании. Работать в нашей компании — большая честь!
- фотки руководителей/основателей этой славной конторы с краткими биографиями каждого. Очень важная информация.
- традиционный безликий булщит про миссию компании, революционный продукт, дизраптив технолоджи. Иногда фоточки офиса.
- три слова о проекте и пять буллитов про компетитив салари и медстраховку с залом
- требования к вакансии! Ура!
- слайд Thank You и контакты. Спасибо, что доехал до этого слайда и живой! Стресс-тест кандидата прямо во время чтения вакансии.
Все это сопровождается стильными иконками, большим количеством буллитов, отсутствием хоть какой-то консистентности в форматировании текста, мелким шрифтом и традиционными иллюстрациями улыбающихся людей из фотостоков.
Не уверен, как такой способ подачи материала влияет на конверсию, но я бы на вашем месте задумался о том, нужно ли идти работать в компанию, которая даже кучку требований не может оформить без поверпоинта.
Время вот времени получаю от рекрутёров предложения в виде ссылки на документ с вакансией.
Часто это гугл-док на страничку — удобно для рекрутёра и для нанимателя, они могут одновременно редактировать вакансию и не нужно перекидываться друг в друга правками в мессенджерах и почте — сам так делал. Неудобно для кандидата — открывать ссылку, читать чё-то там, что за дичь?
Абсолютно все(!) требования к любым вакансиям легко умещаются в абзац-другой неформатированного текста и могут быть озвучены еще в первом сообщении от рекрутёра, но это же слишком просто для такой тонкой вещи как найм околотехнарей и мозг начинает работать в стремлении раскатать потенциальных кандидатов оригинальностью подачи.
Особенно меня радуют такие порождения корпоративного мира как презентации. Духота переговорки, человек с лазерной указкой монотонно вещающий что-то, люди втыкающие в телефоны, постоянно обрывающаяся телеконференция, "коллеги мы все on the same page?", бессмысленные графики и обязательный фирменный стиль на презентации мутным потоком выплескиваются на меня прямо из монитора и погружают сознание в кошмар где 4 таких митинга в день с интервалом в час, на всех нужно обязательно быть, а на некоторые нужно готовить презентацию самому.
Итак, что же нас ждет в этой славной отрыжке корпоративного червя ловко владеющего основным инструментом убеждения окружающих в собственной ценности?
- прикольная картинка и название компании. Работать в нашей компании — большая честь!
- фотки руководителей/основателей этой славной конторы с краткими биографиями каждого. Очень важная информация.
- традиционный безликий булщит про миссию компании, революционный продукт, дизраптив технолоджи. Иногда фоточки офиса.
- три слова о проекте и пять буллитов про компетитив салари и медстраховку с залом
- требования к вакансии! Ура!
- слайд Thank You и контакты. Спасибо, что доехал до этого слайда и живой! Стресс-тест кандидата прямо во время чтения вакансии.
Все это сопровождается стильными иконками, большим количеством буллитов, отсутствием хоть какой-то консистентности в форматировании текста, мелким шрифтом и традиционными иллюстрациями улыбающихся людей из фотостоков.
Не уверен, как такой способ подачи материала влияет на конверсию, но я бы на вашем месте задумался о том, нужно ли идти работать в компанию, которая даже кучку требований не может оформить без поверпоинта.
Зарплата джуна
Сколько денег платить джуну? Сколько денег просить джуну?
Я был (и являюсь, лол) сооснователем небольшой аутсорс шлюпки на 10 гребцов (в пике, сейчас уже почти никого не осталось). Большинство из них были джунами, которых я брал вообще без опыта работы.
Сколько же платить таким ребятам?
Джун — в первую очередь затраты для компании. Наиболее ценный ресурс, который они отъедают — это время более квалифицированных специалистов. Первые несколько месяцев любой джун работает в минус, потому что задачи которые раньше делались быстро и качественно теперь делаются медленно и не очень (требуют правок) или не делаются вообще. Что джун получает взамен? А взамен он получает ценнейший опыт работы над реальным, нужным бизнесу проектом, опыт работы в команде и самое главное — заветную строчку в резюме и возможность рассказать следующему работодателю, над чем и как работал, без необходимости врать.
Человек получает путёвку в мир больших возможностей. Ведь если удастся закрепиться, то даже плохонький программист рано или поздно будет иметь свои полторы-две тысячи и сможет вести вполне нормальное существование без необходимости тяжело горбатиться.
Я убежден, что когда беру на работу людей без опыта, то оказываю им значительно большую услугу, нежели они — мне, но, даже несмотря на это, всякий труд должен оплачиваться. Ни в коем случае не работайте бесплатно и не нанимайте людей на проекты бесплатно. Всем надо платить, пусть даже немного.
И именно поэтому я считаю что денег джун должен получать ровно столько, чтобы не помереть с голоду. В киевских реалиях это примерно 300-400$. Взамен я не требую лояльности и чётко понимаю, что ушлый парень/девушка уже через полгода озаботится вопросом повышения зарплаты и есть риск, что он от меня уйдет, если я не соглашусь с его аппетитами, или не буду достаточно убедительным, чтобы он продолжал работать за мелкий прайс.
Через год джун должен как-то выходить на планку в 1000$. Если для меня он будет ценным — ок, я буду платить такие деньги. Если нет — ну что ж, бизнес есть бизнес, рынок есть рынок, вперед, я только порадуюсь за человека.
Сколько просить денег джуну? Вот минимум 300-400$ и просите. А вообще, как правило на таких позициях особо не торгуются и в компании уже есть фиксированная планка, с которой начинают все. Через пол-года в любом случае пора начинать ходить по собесам и присматриваться в другим конторам. У меня есть знакомый который за 3 года поднялся до 3 с хвостиком тысяч, при этом парень вовсе не экстраординарная личность. Просто хороший разработчик, вовремя менял конторы и умело торговался.
Не стыдно работать за мелкий прайс. Стыдно продолжать получать мелкий прайс через год.
Сколько денег платить джуну? Сколько денег просить джуну?
Я был (и являюсь, лол) сооснователем небольшой аутсорс шлюпки на 10 гребцов (в пике, сейчас уже почти никого не осталось). Большинство из них были джунами, которых я брал вообще без опыта работы.
Сколько же платить таким ребятам?
Джун — в первую очередь затраты для компании. Наиболее ценный ресурс, который они отъедают — это время более квалифицированных специалистов. Первые несколько месяцев любой джун работает в минус, потому что задачи которые раньше делались быстро и качественно теперь делаются медленно и не очень (требуют правок) или не делаются вообще. Что джун получает взамен? А взамен он получает ценнейший опыт работы над реальным, нужным бизнесу проектом, опыт работы в команде и самое главное — заветную строчку в резюме и возможность рассказать следующему работодателю, над чем и как работал, без необходимости врать.
Человек получает путёвку в мир больших возможностей. Ведь если удастся закрепиться, то даже плохонький программист рано или поздно будет иметь свои полторы-две тысячи и сможет вести вполне нормальное существование без необходимости тяжело горбатиться.
Я убежден, что когда беру на работу людей без опыта, то оказываю им значительно большую услугу, нежели они — мне, но, даже несмотря на это, всякий труд должен оплачиваться. Ни в коем случае не работайте бесплатно и не нанимайте людей на проекты бесплатно. Всем надо платить, пусть даже немного.
И именно поэтому я считаю что денег джун должен получать ровно столько, чтобы не помереть с голоду. В киевских реалиях это примерно 300-400$. Взамен я не требую лояльности и чётко понимаю, что ушлый парень/девушка уже через полгода озаботится вопросом повышения зарплаты и есть риск, что он от меня уйдет, если я не соглашусь с его аппетитами, или не буду достаточно убедительным, чтобы он продолжал работать за мелкий прайс.
Через год джун должен как-то выходить на планку в 1000$. Если для меня он будет ценным — ок, я буду платить такие деньги. Если нет — ну что ж, бизнес есть бизнес, рынок есть рынок, вперед, я только порадуюсь за человека.
Сколько просить денег джуну? Вот минимум 300-400$ и просите. А вообще, как правило на таких позициях особо не торгуются и в компании уже есть фиксированная планка, с которой начинают все. Через пол-года в любом случае пора начинать ходить по собесам и присматриваться в другим конторам. У меня есть знакомый который за 3 года поднялся до 3 с хвостиком тысяч, при этом парень вовсе не экстраординарная личность. Просто хороший разработчик, вовремя менял конторы и умело торговался.
Не стыдно работать за мелкий прайс. Стыдно продолжать получать мелкий прайс через год.
Идеальный джун
За свою карьеру я нанял большое количество нулячих джунов (без предыдущего опыта). Человек 20 точно будет, не меньше, а то и все 30. Соответственно просмотрел я далеко за сотню разных людей. Довольно давно я сформировал как говорят на западе highly opinionated профиль кандидата согласно которому я автоматически дискриминирую и отсекаю целую толпу народа. Кто же это?
— Обязательно студент/ка 3-5 очного курса профильного технического факультета. Разнообразные АСУ, ВТ, АУТС, кибернетики, автоматики, безопасность и прочие компьютерные науки. В принципе дальше можно не продолжать 🙂 но разберем по полочкам:
- Раз студент, значит парттаймщик. Это очень важно. Кто-то может думать что парттаймщик будет меньше работать, но на самом деле это не так. Человек который работает пол-дня будет эти пол-дня проводить сфокусированно над нужными задачами, а не смотреть мемасы. Чем меньше времени — тем более эффективно оно расходуется, тем проще отслеживать и контролировать прогресс. Непредсказуемость посещений делает ваш процесс более устойчивым, такой себе chaos engineering. Важно чтобы человек мог работать не меньше 20 часов в неделю — это необходимый минимум, из моей практики.
- Второй плюс парттайма — человек гарантированно задержится на подольше. Минимум на год, а это значит, что за это время он уже успеет нанести пользу и может быть даже выйдет на самоокупаемость.
- Раз студент, значит живет в общаге или с родителями. Соответственно, его будут меньше волновать деньги и больше — знания и опыт. Нет, есть конечно и меркантильные люди, но это не сравнить с взрослым человеком, у которого семья и дети, и которому вышеупомянутых 300 баксов явно будет маловато. С олдовыми дядями не связываемся.
- Профильный факультет гарантирует наличие хоть каких-то базовых знаний алгоритмов и адекватное знание одного, а то и двух языков программирования. Согласно моему опыту, все технари на старте просто на голову выше гуманитариев. Как правило у человека не возникает проблем повертеть деревьями или связными списками с рекурсиями, а значит и с вашими формочками он тоже справится. Бывают конечно и гуманитарии-самородки, но среди технарей таких больше.
- Идеальный джун уже с горем пополам знает парочку фреймворков/библиотек — spring/rails/react/angular/express/etc.
- Правильные друзья и одногруппники, мотивирующее окружение. Нетворкинг — это всегда хорошо. Наш джун может как привести своих друзей, так и уйти к ним 🙂
За свою карьеру я нанял большое количество нулячих джунов (без предыдущего опыта). Человек 20 точно будет, не меньше, а то и все 30. Соответственно просмотрел я далеко за сотню разных людей. Довольно давно я сформировал как говорят на западе highly opinionated профиль кандидата согласно которому я автоматически дискриминирую и отсекаю целую толпу народа. Кто же это?
— Обязательно студент/ка 3-5 очного курса профильного технического факультета. Разнообразные АСУ, ВТ, АУТС, кибернетики, автоматики, безопасность и прочие компьютерные науки. В принципе дальше можно не продолжать 🙂 но разберем по полочкам:
- Раз студент, значит парттаймщик. Это очень важно. Кто-то может думать что парттаймщик будет меньше работать, но на самом деле это не так. Человек который работает пол-дня будет эти пол-дня проводить сфокусированно над нужными задачами, а не смотреть мемасы. Чем меньше времени — тем более эффективно оно расходуется, тем проще отслеживать и контролировать прогресс. Непредсказуемость посещений делает ваш процесс более устойчивым, такой себе chaos engineering. Важно чтобы человек мог работать не меньше 20 часов в неделю — это необходимый минимум, из моей практики.
- Второй плюс парттайма — человек гарантированно задержится на подольше. Минимум на год, а это значит, что за это время он уже успеет нанести пользу и может быть даже выйдет на самоокупаемость.
- Раз студент, значит живет в общаге или с родителями. Соответственно, его будут меньше волновать деньги и больше — знания и опыт. Нет, есть конечно и меркантильные люди, но это не сравнить с взрослым человеком, у которого семья и дети, и которому вышеупомянутых 300 баксов явно будет маловато. С олдовыми дядями не связываемся.
- Профильный факультет гарантирует наличие хоть каких-то базовых знаний алгоритмов и адекватное знание одного, а то и двух языков программирования. Согласно моему опыту, все технари на старте просто на голову выше гуманитариев. Как правило у человека не возникает проблем повертеть деревьями или связными списками с рекурсиями, а значит и с вашими формочками он тоже справится. Бывают конечно и гуманитарии-самородки, но среди технарей таких больше.
- Идеальный джун уже с горем пополам знает парочку фреймворков/библиотек — spring/rails/react/angular/express/etc.
- Правильные друзья и одногруппники, мотивирующее окружение. Нетворкинг — это всегда хорошо. Наш джун может как привести своих друзей, так и уйти к ним 🙂
Почему нужно нанимать джунов
Я горячий сторонник найма джунов. Нанимал кучу джунов когда работал в большой корпорации, а потом нанимал уже к себе в компанию и платил им из своего кармана. Сейчас не нанимаю, потому что работаю практически сам, да и карманы опустели 😄
Убежден, что любая контора, которая зарабатывает хоть какое-то бабло просто обязана нанимать джунов, и вот почему.
- Улучшение и формализация процессов. Когда у вас на борту не самые опытные бойцы, такие вещи как CI/CD, статические анализаторы кода, тесты, код ревью и автодеплой становятся просто обязательными. Чем больше препятствий на пути к продакшн серверу — тем лучше.
- Делегация рутинных задач и тех долга. Через пару месяцев обучения джун уже легко должен щелкать простые задачи до которых не доходили руки и разнообразный мелких тех долг. Понятное дело что переписать все с нуля никто не даст, но разгрузить инженеров от всякой мелкой ерунды и сделать множество несложных, но полезных для пользователей фич — изи.
- Улучшение качества документации, скорости введения нового человека в проект и прочих инфраструктурных вещей. Каждый новый джун будет повторять одни и те же шаги по первичной настройке окружения. Если первый раз еще можно объяснить на пальцах, то дальше грамотный специалист просто напишет доку/скрипты/внедрит билдсистему и так далее. А можно вообще посадить писать эту доку самого джуна.
- Далеко не последняя по значимости в этом списке — социальная миссия. Да, я лично готов терпеть (и терпел) убытки просто потому, что считаю важным давать путёвку в безбедную жизнь людям. Приятно видеть толкового специалиста, который вырастает на твоих глазах.
- Прокачивание менторских и лидерских скиллов внутри команды. Первый шаг как сделать из человека сеньера помидора — выдать ему пару джунов на обучение. А там глядишь уже и до тимлида недалеко.
Главное в этом всём счастье — сохранять правильные пропорции джунов к не-джунам, иначе глиняный колосс рискует развалиться под собственным весом 🙂
Я горячий сторонник найма джунов. Нанимал кучу джунов когда работал в большой корпорации, а потом нанимал уже к себе в компанию и платил им из своего кармана. Сейчас не нанимаю, потому что работаю практически сам, да и карманы опустели 😄
Убежден, что любая контора, которая зарабатывает хоть какое-то бабло просто обязана нанимать джунов, и вот почему.
- Улучшение и формализация процессов. Когда у вас на борту не самые опытные бойцы, такие вещи как CI/CD, статические анализаторы кода, тесты, код ревью и автодеплой становятся просто обязательными. Чем больше препятствий на пути к продакшн серверу — тем лучше.
- Делегация рутинных задач и тех долга. Через пару месяцев обучения джун уже легко должен щелкать простые задачи до которых не доходили руки и разнообразный мелких тех долг. Понятное дело что переписать все с нуля никто не даст, но разгрузить инженеров от всякой мелкой ерунды и сделать множество несложных, но полезных для пользователей фич — изи.
- Улучшение качества документации, скорости введения нового человека в проект и прочих инфраструктурных вещей. Каждый новый джун будет повторять одни и те же шаги по первичной настройке окружения. Если первый раз еще можно объяснить на пальцах, то дальше грамотный специалист просто напишет доку/скрипты/внедрит билдсистему и так далее. А можно вообще посадить писать эту доку самого джуна.
- Далеко не последняя по значимости в этом списке — социальная миссия. Да, я лично готов терпеть (и терпел) убытки просто потому, что считаю важным давать путёвку в безбедную жизнь людям. Приятно видеть толкового специалиста, который вырастает на твоих глазах.
- Прокачивание менторских и лидерских скиллов внутри команды. Первый шаг как сделать из человека сеньера помидора — выдать ему пару джунов на обучение. А там глядишь уже и до тимлида недалеко.
Главное в этом всём счастье — сохранять правильные пропорции джунов к не-джунам, иначе глиняный колосс рискует развалиться под собственным весом 🙂