Архив недели @inemiro1ПонедельникВторникСредаЧетвергПятницаСубботаВоскресеньеПонедельникВторникСредаПятницаСубботаСсылки
Архив недели @inemiro1
Понедельник
Привет! Меня зовут Немиро Илья (@inemiro1).
В IT 15+ лет, 10+ в коммерческом. Ещё несколько месяцев назад был системным архитектором и руководителем фронтэнд отдела в Российской компании, но с июня перешел на новую позицию в Американскую (@toptal).
Не претендую на роль топ разработчика, самого начитанного слэш самого умного, но уверен, что найду чем с вами поделиться. Очень хочу обсудить влияние окружения на ваши скилы, поговорить о том, что такое успех, как искал заграничную работу и пара интересностей ещё чуть позже.
Очень люблю задавать вопросы. В 2018м году это так понравилось моему руководству, что они мне дали полный карт-бланш на проведение собеседований.
В 2019м году провел 150+ собеседований для 10+ компаний, в 2020м темп чуть снизил, чтобы посвятить время другим проектам и семье.
Но всё ещё продолжаю собеседовать фронтэнд разработчиков.
В 2020м начал задавать вопросы компаниям о работе их IT отделов и запустил youtube канал об этом (@huntITru).
Сам был на куче собеседований, чтобы смотреть кто и как их проводит, как и какие вопросы задают. Ни разу не принимал оффер, так как никогда за ним не шел. Из компании в компанию меня хантили интересным проектом с интересными инженерно-техническими и финансовыми возможностями.
А ещё у меня есть мечта максимально релевантно связывать опыт разработчиков и запросы компаний, давать лучшим разработчикам лучшие возможности, но это долгий длинный путь и сейчас не об этом :)
Что повышает шансы быть сханченым? Развитие софт скилов. Тут можно начать неплохой холивар (и почему бы и нет).
Я на стороне тех, кто софт скилы считает счастливым билетом и гораздо более приоритетными для этого. Каким бы ты не был скилованным (в хард плане) разработчиком, всё-равно все сферы не охватишь и всегда найдется более квалифицированный разработчик.
Плюс сюда же неумение объективно оценить уровень разработчика работодателем, всё-равно при приеме на работу (считай на собеседовании) оценка будет субъективная.
Ну и раз оценка субъективна, то проще и эффективнее на неё повлиять именно субъект факторами - речью, голосом, языками, эмоциями, знаниями окружающих тем, расширенным кругозором, охватом не только специфической области, но и даже, например, общими интересами с интервьюверами.
Софт скилы, которые 100% годны каждому во всех сферах жизни: Ораторские навыки, навыки нетворкинга, коммуникации, языки, резолвинг конфликтов, менеджерские навыки, командное мышление, шэринг знаний, проактивность, работа над окружение, правильная постановка целей, планирование.
Кстати в плане ораторства круто помогает вокал и битбокс.
Софт навыки которые мне помогают эффективнее и быстрее решать задачи во фронтэнде: знание бэкэнда, как он работает, что стоит за процессами, базы данных и как они работают. Знание архитектуры приложения и инфраструктуры, изучение лучших практик ...
А ещё решение инженерных и алгоритмических задач. Навыки тестирования. Или вот умение работать с графикой: фото, графика, каллиграфия, видео (от энкодинга, до монтажа). Понимание бизнес-механизмов, целей бизнеса, BPM.
Конечно это очень вкраце, но всё же попытался вспомнить всё самое важное. Какие навыки помогали не единожды вам? Что упустил? Уверен есть довольно очевидные и не очевидные навыки, которые не упомянул, но которые точно вам помогли и помогают по жизни и в работе.
Тред (Николай Говоров)
Одним из важнейших для меня навыков является работа с окружением. Есть гораздо более прокаченные ребята в этом плане, но это и не соревнование, это делается для самого себя и для того, чтобы самому открывать для себя всё более новые и новые возможности. Это многие упускают.
Три недели назад я выпустил часовой фильм-интервью об окружении на моем ютуб канале, от этой тему меня всё ещё бомбит, поэтому хочу с неё и начать.
Давайте начнем с вопроса, который мне задал @bunopus, в ответ на вопрос о нём, так как само слово “окружение” все могут понимать по-разному. Что это для вас? Что такое Окружение?
Самоизоляция в этом плане сильно повлияла, она позволила по-новому взглянуть и на окружающих людей и на окружающие вещи. Так как мы говорим об окружении в рамках @jsunderhood и хочется немного IT специфики, я немного поделюсь мыслями из части интервью с @twenty
В том числе мысли, которые не вошли в финальный фильм. @twenty вообще в этом плане огромный молодец. Павел автор тг-канала Winterview (5k подписчиков) и подкаста для фронтэдеров Frontoweek (2k подписчиков, недельные дайжесты о фронтэнде).
Вы задумывались о том, что создать канал, чат, группу - это создать для кого-то окружение? Ближайшее окружение уже давно вышло за рамки друзей во дворе, в современном миру окружение стало гораздо обширнее.
Лучшим другом даже может быть человек живущий на другом конце света и с которым ни разу не виделся лично, а командой мечты может стать распределенная команда общаясь, например, в дискорде. Думали в таком ключе?
Для того чтобы создать такое цифровое окружение, нужно очень мало - просто пара кликов и большое желание. Хотите общаться с разработчиками? Создайте канал о разработке. С художниками? Создайте чат посвященный художественному направлению. Не останавливайтесь, если такие уже есть.
Единственное условие: Создавая канал и развивая его, вы должны хотеть это делать независимо от результата, делать для себя. Иначе если у вас через месяц в окружении не появятся те, о ком вы мечтали, вы просто сдуетесь. А когда это делаешь “в любом случае”, то всё получится.
А ну ещё, чтобы создать окружение, понадобится некая ценность такого окружения, это может быть ваш бэкграунд как профессионала, или, как вариант, информация, которую вы находите и делитесь.
И если возникает много НО, то иногда легче начать с того, что просто найти такое “готовое” окружение. Не нужно за плечами иметь каких-то спец. школ, обладать багажом каких-то уникальных навыков, нужно быть просто собой.
Есть очень много людей, которые готовы и хотят делиться информацией, они просто не могут в какой-то момент держать это в себе, они видят как люди вокруг совершают какие-то ошибки, или задают одни и те же вопросы, это начинает подбешивать.
Часто после общения с экспертами меняешь взгляды на те или иные вещи.
Я и сам пришел к ютуб каналу, потому-что видел, что многие ребята просто хотят знать больше о компаниях, но не знают, что спросить, захотелось поделиться собственными открытиями.
А сейчас благодаря каналу уже сильно много новых людей узнал, расширил окружение, например познакомился с руководителями крупный компаний, по-другому взглянул на то как функционируют департаменты. Это так и работает.
Или кто-нибудь начинает не просто за кружечкой пива в баре делиться своим опытом 1 на 1, а, например, выступает с докладами на конференциях, митапах. Окружение нам дает знания, опыт, возможность не наступать на грабли, на которые наступили другие.
Так или иначе, когда ты вступаешь на любой путь, ты так или иначе обрастаешь окружением.
Довольно очевидные вещи, и уже по фидбеку о просмотре фильма-интервью могу сказать, что сердечко ёкнет в основном только у тех, кто сам сейчас сталкивается с подобным ресерчом и ревизией своего собственного окружения.
Не удивляйтесь, если сейчас нет отклика - он будет, когда рано или поздно придете к этому. Рано, конечно лучше.
Ещё одна важная функция окружения - мотивация и критика. Вы не видите себя со стороны - окружение видит. Вам могут дать совет, могут сказать где и в чем зашкварились, это лучший трамплин для роста.
Но заметить, что что-то не так может только окружение, которое круче вас (в конкретных скилах), поэтому всегда нужно стремиться если не менять, то обновлять окружение, чтобы рядом с вами были люди, которые круче вас.
Мотивация - это когда кто-то круче тебя что-то делает или что-то лучше знает, и ты хочешь повторить, хочешь прокачаться. Друг купил машину новую, сразу тоже новую захотелось и хоп, нашел мотивацию. Друг стартап организовал, тоже что-то захотелось свой стартап.
Может показаться, что, “если все круче меня, то что я могу дать такому окружению”? И это величайший страх многих, из-за которых, например, они боятся знакомиться. Каждый человек уникальная единица, с уникальными навыками.
Нет цели зазнакомиться со всеми, вы будете интересны тем, кому интересны ваши навыки и ваш опыт. Развивайтесь сами, прокачивайте софт и хард скилы, делитесь, приобретайте опыт и рано или поздно вы будете приобретать что-то полезное, что будет интересно другим.
Конечно можно достичь всё самому, но чаще всего это будет гораздо гораздо дольше. Время очень важный, ценный и не восполняемый ресурс. Не вижу ни одной причины делать что-то долго, если можно быстро, и скорее всего ещё и интересно.
Не нужно прыгать через голову и пытаться играть роль профессионала. Это нормально чего-то не знать. И, повторюсь, всё-равно прокачивая навыки, рано или поздно вырастишь и окружение подтянешь или окружение тебя подтянет.
Нормально выходить из старого окружения, из которого ты уже вырос. Часто это больно и сложно, не хочется обидеть ребят, но кэмон, не нужно никого посылать, если прекращаешь общаться, оно само рано или поздно отваливается. Просто не форсишь общение и постепенно само всё разрулится
Один из универсальных рецептов, который я часто слышу - свалить в другой город (это конечно шутка, но с долей правды). Ну, а когда свалил в другой город, все карты открыты - тут или онлайн комьюнити, или, местные мероприятия.
Можно классно прокачать фронтэнд окружение на местных тусовках с пивом, конференциях, митапах, завтраках. Нужно искать людей, частью окружения которых ты хочешь быть и всячески стараться туда попасть.
Если есть сомнения, и нет уверенности, хочешь ли быть частью какого-то окружения, ну так попробуй, сходи, если не понравится, быстро поймешь и просто больше не пойдешь :)
Нужно почувствовать, отзывается ли оно внутри тебя.
Периодически делайте ревизию своего окружения, загоняться не надо, но подумать кто рядом и почему - стоит. Не держитесь рядом с людьми, которые тянут вас назад или вниз, гоните токсиков из своего окружения, а если всё окружение токсичное, сами валите из него, не сомневайтесь.
Ищите возможности у людей, которые уже чего-то достигли. Идеальное окружение постоянно дает инсайты и постоянно дает какой-то невообразимый прилив энергии.
Как окружение влияет на ваши успехи? Как вы видите себе свое идеально окружение? Поделитесь личными, возможно “универсальными” советами по работе со своим окружением для остальных.
Если читать этот твит вне контекста, то может показаться, что я задал Жене вопрос о самом Жене.
Тред (Николай Говоров)
Вторник
3 года назад я закрыл коворкинг на 20 рабочих мест (сначала на 8, но потом увеличил), который просуществовал 3 года.
В пике у меня было три зала, который были собственноручно отремонтированы с любовью и полным погружением, выверял даже высоту столов и стульев для комфортной посадки, или, например, количество люмен на рабочее место, угол падения света и даже температуру и скорость мерцания ламп
Основной зал был 36кв. м., он просуществовал дольше всего и он был самый классный. Вложений в коворинг вышло около 1 млн. руб. распределенных во времени, по мере поступления денег постепенно делал ремонт и докупал оборудование.
Основная цель создания коворкинга была .... окружение! На тот момент я уже больше 10 лет занимался IT и честно говоря, как это, наверное, в какой-то момент у каждого бывает, думаешь такой “как же всё это задолбало, наверное нужно что-то другое”.
Жил я в пригороде, работал удаленно, и решил, что если создать “место силы” недалеко от дома, то туда подтянуться нужные мне люди. Забегу вперед – всё получилось.
Начинал я так: Искал место с потолками 3+ метра и огромными окнами. В моем пригороде оказалось всего два таких места, одно - в какой-то дыре на промзоне, второе - в отдельно стоящем здании, рядом с важным транспортным узлом города и магазинами, конечно выбрал его.
С собственником не повезло, он думал только о деньгах, развивать помещение никак не хотел, по крайней мере любое решение приходилось через него продавливать с огромными усилиями.
Коворкинг был для самостоятельных предпринимателей, ребят, которые ещё не доросли до собственного офиса, но уже активно занимаются бизнесом. За 3 года я так даже и не повесил вывеску и даже ни разу не дал рекламу, люди сами постепенно приходили.
Параллельно я продолжал работать по 8 часов в день на основной работе и ещё по несколько часов в день на различных мелких IT проектах и в качестве консультанта.
Именно в коворкинге я увидел как можно делать бизнес, как можно общаться, как люди работают с продажами, как работают с клиентами и как общаются и на каком языке с другими бизнесменами.
Именно там я получил самые ценные контакты, которые у меня есть на данный момент. Это реально стало местом силы. И параллельно я сразу же всё это на самом коворкинге и применял.
Почему же закрыл? Всё это время я продолжал работать руководителем отдела разработки и уже стал системным архитектором. Те деньги, которые я получал просто окладом разработчика, некоторые из бизнесменов, работавших в коворкинге, получали с очень большим трудом.
Некоторые другие же получали в 10 раз больше, работая по несколько часов в день. Коворкинг в пике приносил мне 30-40 тыс рублей в месяц чистой прибыли, что вроде и не плохо. Но..
Но он полностью держался на мне и расходовал много энергии. Люди приходили не сколько поработать, сколько обсудить что-то со мной или другими ребятами о делах, решить какой-нибудь сложный вопрос, сформировать например стратегию переговоров по сделке или придумать креативный ход.
Я просто не смог найти администратора, который был достаточно интересен, чтобы мотивировать людей тут работать, и как только меня пригласили в проект с многомиллиоными инвестициями - я стал ему уделять меньше времени, и он просто начал "скукоживаться".
В итоге некоторые ребята расширились, бизнес рос, они сняли себе собственные офисы уже для команд, а новые коворкеры не приходили, потому-что я никогда не бывал на месте, просто занимался другими более интересными мне проектами.
Итого: Коворкинг дал мне окружение, которое я искал, дал мне необходимый опыт, но просто это стало не интересно развивать - сил и времени уходит много, а прибыль 30-40 тыс в месяц - столько рядовой IT’шник зарабатывает плюс-минус за неделю не напрягаясь.
Но самое главное, из-за чего я решил стартануть этот тред и рассказать вообще об этом – подтвержденное эмпирическим путем открытие о недостаточности теории.
Т.е., да, чтобы создать окружение, можно найти более простые способы, например, хочешь общаться с предпринимателями, ходи на митапы для предпринимателей, ну или создай митапы, люди подтянутся, если делаешь это с душой.
Но, к сожалению, теория без практики не прокатит. Просто если ходишь на тусовки танцоров поговорить - танцевать не научишься.
Чтобы стать танцором, нужно учиться танцевать, чтобы стать предпринимателем нужно что-то предпринимать, чтобы стать разработчиком, нужно разрабатывать. Тусовки и митапы дадут окружение, но разговоры не сделают из тебя классного специалиста.
Можно даже провести параллель - собственный коворкинг был оффлайн стартапом. Если реально хочешь создать собственный стартап, то недостаточно о нем разговаривать с другими стартаперами в стартап тусовке. Нужно его делать.
И не разрабатывать годами MVP, а именно сделать полный цикл, с попыткой получения инвестиций, попыткой продать разработку и так далее. Это даст бешеный рост и развитие.
Нужно действовать, пробовать, только пробы и собственные ошибки дадут возможность изменить собственное мышление, начать думать по-другому, в других плоскостях, другими ценностями и масштабами.
Тред (Николай Говоров)
Бывает спрашиваю про какую-нибудь технологию, вполне очевидную, (если видишь, что разработчику она интересна), вот, например, один из возможных вариантов: “async-await, использовал\знаешь?” Разработчик отвечает: “Давно хочу, уже года два, но всё руки не доходят”. Ваша реакция?
Как изменится реакция, если дальше добавляет: “наш тимлид любит промисы, ну я и не смотрел поэтому” ?
Среда
Я успешный фронтэндер. Я успешный семьянин. Я успешный человек.
Что такое успех и как понять успешный ли ты человек, можно ли вставая утром говорить себе такое в зеркало и не сомневаться?
Вы считаете себя успешными?
Что такое успех?
Успех – достижение поставленных целей. Вы успешны, если у вас получается задуманное, вы чувствуете от этого прилив сил. Бывает, чувствуешь себя неудачником, всё валится из рук, ничего не выходит. Что это? Черная полоса? Бывает и такое, но чаще всего это просто завышенные ожидания
Вы попытались трудоустроиться в несколько компаний, но завалили собеседования. Вы сделали стартап, а он провалился. Провели переговоры, но завалили сделку. Работали не покладая рук, но не получили повышения. Или написали программу, а она не принесла должного профита.
Давайте разбирать. Какие цели вы перед собой ставили?
Цели должны быть достижимы. Ставьте достижимые цели, не нужны заоблачные планы, ставьте то, что будет 100% сделано, даже если метеорит упадет. Ставьте планку на 1мм выше предыдущего раза.
Не получилось? Попробуйте поставить планку на 1мм ниже, попробуйте ещё раз. Наблюдайте за результатом: было ли тяжело? или было слишком легко? Вы готовы повторить ещё раз с удовольствием? Ну и кстати старайтесь делать всё с удовольствием.
Соответственно успех у всех разный. Для кого-то успех утром проснуться по будильнику, для кого-то неудача пробежать марафон на минуту дольше, а для кого-то успех пробежать и 5 км. Прекратите загоняться, если не можете сделать что-то, что у других легко получается.
Хватит думать, что если другой разработчик разбирается в какой-то области или областях лучше чем вы, то вы “хуже”, ох уж этот синдром самозванца. Качайте охват, или выберите специализацию - не важно, главное ставьте достижимые цели и кайфуйте от их достижения - это и есть успех.
Интересно бывает с целями зависящими не от вас. С целями зависящими от людей на самом деле всё проще. Вот, например, цель “провести успешно переговоры”. Вы хотите снижения арендной ставки за квартиру, потому-что из-за пандемии ваш фронтэнд отдел сократили..
Проведенные переговоры - это успех. Вы провели переговоры, не каждый вообще решится их провести.
Если не убедили оппонента, не беду, вы получили опыт. Впитывайте, что шло так, что не так, что влияло. Раз не убедили, значит цель была поставлена завышенная, качайте значит навыки убеждения, решения конфликтов, переговоров, продажи.
В следующий раз уже на новой квартире всё получится, а навыки ещё 100 раз пригодятся по жизни.
А вот с целями зависящими от природы - сложнее. Поставили вы значит цель поехать в Италию в апреле. А тут корона. Или посерфить сегодня утром, а волн нет. Что это? Снова черная полоса? Кэмон, это природа, перенесите цель.
Переносить цели - нормально. Не удалось сделать сегодня? Нечего страдать, берем календарь, переносим дело на завтра, пробуем повторить завтра. Цель достижима только сегодня? Значит поставили слишком мощную цель, снизьте планку.
Классно, когда удача сопутствует успеху, а она сопутствует, когда вы контролируете успех.
Тред (Николай Говоров)
Моя реакция: пробить окружающие области, понять какие задачи какими способами решает, дать кейсы, как решает кейсы асинхронности, параллелизацию процессов. Если чего-то не использует, не значит, что не сможет решить кейс, но вполне может значить, что в опыте таких кейсов не было
Четверг
К вам прибегает менеджер и говорит “Срочно, нам нужно это вчера!”. Тут есть соблазн быстро сделать лажу. В этот момент конечно надо взять себя в руки.
Знаете, я слышал “это нужно срочно”, “ещё сегодня утром” или “через час” сотни раз. И ни разу задержка не означала проблему. В 9 из 10 случаях это проблема планирования, иногда реальная необходимость, но срыв сроков по которой на деле не вызовет образование схлопывания вселенной.
Речь конечно же не о багах на продакшене, а о фичерсах.
Когда вы услышали такой запрос, ваш путь может разделиться на путь энтузиаста или путь профессионала. Энтузиаст бросается с удовольствием в работу и пытается выжать максимум возможного. Стремится он конечно же к “правильному” варианту и скорее всего не спит всю ночь.
Профессионал понимает, что за такие сроки можно сделать только лажу. И понимая, что сделать идеально в любом случае не выйдет, выбирает оптимальный вариант, компромисс между идеальной картиной и каким-нибудь откровенно хреновым вариантом.
Сколько может работать энтузиаст зависит от длины мотивации. Но как только мотивация закончится, продуктивность упадет кардинально. Профессионал обычно работает на опыте и не сильно зависит от мотивации, мотивация лишь катализатор.
Можно ещё выделить частный случай профессионала. Настоящего профи. Он умеет выбрать наименее хреновый вариант из хреновых, правильно их сравнить.
В контексте ограниченных сроков всегда нужно оценить все проблемы сейчас и возможные проблемы в будущем, взвесить, что нам даст выигрыш сейчас, и в чём проиграем.
Снимите ответственность за лажу с себя (потому-что не вы эту канитель придумали): предложите несколько альтернативных вариантов, обозначьте их плюсы и минусы сейчас и (важно) в будущем, сроки, конечный путь нужно будет в любом случае выбрать менеджеру.
Смиритесь, успокойтесь, эмоции в стиле “какого хрена вообще” отставьте - вы же профессионал. В такой момент главное рационально всё расставить для себя.
В любом случае поймите, чего-то путного у вас не выйдет и сейчас задача сделать так, чтобы формально прикрыть требования насколько это возможно и при этом сделать решение, которое не будет полностью выкинуто в корзину завтра.
Точно нет особого смысла работать всю ночь, на самом деле все готовы к задержкам. Все надеются, что их не будет, но поверьте, я просто не встречал людей, которые выстрелили бы себе в голову, если то, что они “ждут через час”, на самом деле появится только завтра.
Плюс - это порочная практика. Постоянно работать в таком режиме невозможно, но именно это и происходит, если вы несколько раз срочно сделали (неважно какого качества) со сроком “вчера”. Вероятно к вам вернутся ещё десятки раз, и потом сроки появятся и “позавчера” и “неделю назад”
Мотиватор в голове часто говорит, что “всё возможно”, "всё успею". Но опыт окружающих компаний, разработчиков и менеджеров говорит об обратном.
Причем часто для менеджеров это может являться частью ресурсного плана: тут подкрутим, тут дожмем, тут поработаем помощнее. И хоть и разработчик в этом случае всего-лишь винтик в системе - без него никуда ничего всё-равно не поедет.
Реальное срочно (как раз в случае багов) бывает не когда задачу уже не сделать после дедлайна, а когда потери от несделанной задачи настолько высоки, что нужно сделать кровь из носу. Это редкость.
А ещё у менеджеров бывает любовь называть срочными задачами все подряд. В этом случае перестает работать система приоритетов – все задачи становятся одинаковыми.
Классно, когда вы видите, что задачи повторяются, будучи ленивым профессионалом, скорее всего вы быстро заметите процессы, которые могут быть оптимизированы. И надо стараться их замечать. Что можно сделать один раз подольше так, чтобы в следующий раз не пришлось делать тоже самое
Например, вы каждый день настраивается какой-то json руками, может есть инструменты его генерации или такой можно написать? Или вы хардкодите сотни полей ввода в формах на сайте, а может можно генерить формы из того же json? Ну, а json уже сгенерен ранее :)
Либо в визуальном конструкторе собирать руками менеджеров\аналитиков.
К слову, тут давайте похоливарим. Имхо то, что может быть сделано более дешевой рабочей силой, должно быть сделано ей. Всегда есть консультанты\аналитики\менеджеры, которые получают меньше разработчиков.
Есть смысл делать в те же ограниченные сроки инструменты для аналитиков, нежели каждый раз руками собирать формы, даже если задача от менеджера изначально звучала именно так.
Как только звучит фраза “давайте сделаем хоть как-то, а через год посмотрим”, вы должны понимать, что менеджер идёт путём закрывания дырок в тонущей лодке. И эта лодка проплывет ещё какое-то время, но когда накопится критическая масса таких дырок, лодка просто резко утонет.
И утонет такая лодка очень быстро и резко. Продукт\проект просто схлопнется из-за нежизнеспособности. Чтобы такого не было, нужно сформировать общую парадигму делать оптимальные профессиональные решения, а не быстрые костыли, думать на несколько шагов вперед, как развивать это
Иногда упираемся в бюджеты, мол “хорошо не сделать руками такого маленького отдела разработки” или “у нас нет бюджета на разработчиков”.
Дело в том, что шаг за шагом, по крупицам, если не бросаться в реализацию костылей каждый раз, а каждый раз по чуть чуть добавлять оптимальных решений, они будут выливаться в жизнеспособные инструменты.
И эти инструменты, как мы уже определили выше, позволят работать более дешевой рабочей силе, а не разработчикам, и тогда проблемы с отсутствием бюджета на разработчиков не будет вообще.
Домашнее задание! Самая дешевая рабочая сила это роботы - программы. Если что-то можно оптимизировать с помощью автоматизированных решений, где участие разработчиков и менеджеров\аналитиков не требуется, нужно автоматизировать. В каких процессах у вас можно было бы это сделать?
Как вы поступаете в условиях "всё нужно вчера", "нет бюджета на разработчиков" и "давайте сделаем хоть как-то, а через год посмотрим"?
Какие выходы видите? Самый простой - уйти из компании. Сложнее - поговорить и перестать брать такие задачи (но есть большая вероятность, что вас посчитают лодырем, который расслабился и больше не хочет работать). Ещё?
Тред (Николай Говоров)
Пятница
Пятница, время охуительных фронтэнд историй. Так, а в коллективном аккаунте можно материться?
Anyway, рассказываю!
Сейчас я (@inemiro1) работаю фронтэнд разработчиком в Американской компании @toptal, разрабатывающей сеть для топ фрилансеров мира. Пришел к этому случайно, попал по приглашению, которое было даже не мне. Сам путь не спонтанный, шел по нему долго и осознанно, сейчас расскажу как.
Для начала уровень английского, сразу отмечу, что английский в школе у меня был на уровне “It’s a table”, я не знал ни времен, ни грамматики, ни общаться нормально не мог. Понимал на уровне чтения и слуха не плохо, потому-что играл в компьютерные игры на английском
В какой-то момент, пришел к тому, что не хочу привязываться к стране. В России происходят иногда не самые приятные события и хочется иметь запасные варианты, особенно учитывая, что я как разработчик могу работать откуда угодно, главное интернет, зачем привязываться.
Поставил себе цель поработать с англоговорящими заказчиками, заключить несколько сделок, посмотреть как это вообще “работать на международном уровне”. Позанимался английским в группе, т.к. сразу зашел в группу с опытными студентами, резко стартанул вперед, узнал много нового
Мешали словарный запас и восприятие на слух.
Четких сроков пока не было, это было больше как фоновое понимание того, что рано или поздно надо будет куда-то двигаться, и знать английский может пригодиться в будущем.
Тут пригодился ororo.tv . Сейчас есть много аналогов, и тогда собственно были наверное, но мне учитель по английскому дал именно этот сервис, там и остался, всё устраивает. Суть в том, что я начал смотреть все сериалы и фильмы только на английском, с субтитрами.
Смотрел fastforward, т.е. перематывал чисто по фразам, останавливался на каждом не понятном мне слове или выражении и переводил (в ororo.tv есть встроенный переводчик прямо в субтитрах). Основная суть и основной прокач заключался именно в сериалах.
Больше всего смотрел все сериалы Marvel, DC, а хорошо зашел Silicon Valley. Зашел в плане слов. Вот в чем основной профит сериалов: герои обычно говорят очень схожими словами и фразами, часто повторяются из серии в серию.
Переводя каждый раз все неизвестные слова ты рано или поздно их запоминаешь и начинаешь уже понимать отдельных героев без субтитров. А ещё ты привыкаешь к тому как герои говорят, и это тоже помогает их понимать.
Сериалы очень помогли. Начал смотреть их в 2017м, смотрел много, стабильно хотя бы одну серию каждый день, в хорошие дни в перемотке просматривал целые сезоны. К 2018 свободно без субтитров смотрел англ видео на ютубе, фильмы и сериалы с хорошим произношением и простыми терминами
В 2018 провел много собеседований + помогал как тех консультант в трудоустройстве разработчиков в несколько компаний. Пришла мысль, что если изменить идею “поработать с англоговорящими заказчиками” и начать давать тех консультации и проводить собеседования теперь на английском
Понимал, что уровень мой недостаточен, но и времени особо ездить заниматься английским нет. В этот момент я начал искать онлайн школу и остановился на @SchoolSkyeng
Сторонние отзывы о SkyEng были честно, прям не очень, у меня несколько знакомых близких пробовали, и не увидели вообще прогресса особо, или не получали кайф от занятий. Нашел буквально 1 хороший отзыв из 10.
Но я решил попробовать, потому-что искал быстрый и простой способ начать делать хоть что-то уже сегодня, а скорректировать самолет в полете всегда можно.
Понимал, что для эффективной работы нужна цель - поставил цель TOEFL.
TOEFL это именно американский английский и с учетом IT специфики это более рационально, всё IT движение сейчас так или иначе связано с США.
Попробовал несколько преподавателей, попадались вообще не заинтересованные ребята, был разочарован, дал последний шанс … иии .. неожиданный эффект. До сих пор занимаюсь с этим преподавателем, очень комфортно и продуктивно. Считаю, что это как раз 1 случай из 10.
После этого пробовал параллельно на втором аккаунте найти ещё преподавателей, перебрал человек 5, отзывы друзей могу подтвердить - нет вообще погружения, нет кайфа, прогресса либо нет, либо очень медленный, может просто вайб не поймать.
Получается, что в Skyeng всё сильно зависит от преподавателя, а т.к. поиск преподавателя за ваш счёт, то реально всё зависит от удачи и ваших финансов.
Занятия с носителями английского оказались жутко не продуктивным, т.к. когда дело доходит до трансформации мысли из русской культуры в американскую, американцы просто не понимают о чем речь, в итоге пол занятия уходит на объяснение.
Тут посетила мысль, что знаковой точкой может стать интервью на англ о какой-нибудь известной компании. К этому моменту, я уже занялся видео-блогом @huntITru и эта мысль смотивировала меня не только изучать как работают российские компании, но и как работают в Европе и Америке
Я изучал отзывы о различных компаниях, искал самые известные или с самым большим количеством отзывов, изучал, где работают разработчики, с какими заграничными компаниями чаще всего взаимодействуют русскоязычные разработчики.
Мне недостаточно знать пару моментов о компании или её стэк, я стараюсь копаться в деталях функционирования компании, её позиции на рынке, её миссии и того комьюнити разработчиков, которое она создает.
Так или иначе я начал натыкаться на ребят, которые работали с @toptal. К слову говоря, это далеко не единственная компания, на которую я натыкался. Я даже делал видео, где перечислял некоторые способы поиска заграничных компаний youtube.com/watch?v=32Pxiw…
И вот в момент выхода видео, практически одновременно, пишут в одном из фронтэнд чатов Питера, что оказывается есть позиции не только в плане фриланса, но и есть пул разработчиков, которые разрабатывают непосредственно саму платформу (Core team), фактически приглашают попробовать
Меня всё больше и больше начала цеплять мысль. А ведь и правда: это американская компания, это полностью отвечает моим целям и в плане языка и в плане работы из любой точки мира.
Самое главное, что ребята разрабатывают платформу для квалифицированных разработчиков со всего мира, а это именно та миссия, которую преследую я сам - находить компании для разработчиков релевантно их опыту.
Я понимал, что даже и близко ещё не подошел к TOEFL по грамматике, но уровень понимания речи по тестам у меня уже стал C1 (максимальный C2). Это был знак, надо пробовать. Это был уже апрель 2020.
Связался с парнем, который упоминал о позициях в core. Параллельно, чтобы потренить навыки прошел отбор на фриланс платформу @toptal. Там жесткий отбор в несколько этапов, пришлось сильно напрячься и вспомнить инженерно-алгоритмические навыки.
Параллельно, опять же, чтобы потренить, прошел отборы в Remotemore, Remotesome и другие подобные конторы, посмотрел как они проводят собеседования, что они могут предложить.
Вообще все слились на моменте обсуждения рейта, таких цифр как Toptal предложить никто не может, просто потому-что у других платформ нет заказчиков, готовых столько платить.
Отбор в Toptal core стоял на паузе из-за пандемии и неожиданно в мае его снова открыли. Связались, побеседовали, провели несколько интервью, нашли общие точки, подумали как эффективно использовать мой опыт, чтобы соединить его с уже сформированной сильной командой разработчиков.
В итоге с 1 июня работаю полностью удаленно и полностью на английском языке. TOEFL мне теперь как цель не нужна, не вижу смысла, и выходит нужна то она была больше для мотивации и целеустремленности.
Цели которые оставил перед собой и реализацию и точно исполню в будущем - полноценные интервью на английском с разработчиками и компаниями. Параллельно продолжаю учить английский на Skyeng, и теперь ещё подключил Udemy.
А ещё хочу презентации и выступлнния.
True story bro.
Тред (Николай Говоров)
Суббота
Как я и говорил, припас тему напоследок, когда голова уже загружена рабочей неделей и можно пописать треды подлиннее и свободнее поотвечать на вопросы.
Последние четыре года так или иначе двигаюсь в сторону микро-фронтэндов. Тема сейчас в тренде, но при этом до сих пор много вопросов по корректному использованию и корректным подходам, нет best pratice, нет устоявшихся решений, кто хочет, так и пляшет.
Самый упоминаемый блог micro-frontends.org на тему микро-фронтов, автор @naltatis
Все микрофрноты асинхронно запускаются в рамках одного ядра, некой супер-легкой SPA, которая умеет роутинг и динамически загружать компоненты. Может содержать логику авторизации (какой-нибудь oidc клиент); получения списка страниц и настройки запуска микрофронтов и т.д.
Микрофронты могут дать возможность каждой команде разрабатывать их решение, на привычном для них стеке: хоть самописном, хоть react, angular, vue или svelte, или что-то другое. Самое главное, что абсолютно независимо от других команд.
Хотя вот с angular были, например, проблемы. Не уверен, что его (по крайней мере до 6й версии точно) нормально можно использовать как микрофронт. Всё из-за zone.js. Т.е. В рамках одного окна несколько angular приложений конфликтуют друг с другом. Поправьте, если это изменилось.
Но чаще всего всё-равно в компании команды используют один и тот же стек, и разделения происходит в рамках бизнес-логики, а не технологических подходов + сами по себе микро-фронты лучше делать на одной исходной и понятной всем разработчикам компании базе
С упаковкой микрофронтов в веб-компоненты не игрался пока, но возможно, например, @v_hadoocken сможет об этом рассказать подробнее.
Должен быть сильный скачок, когда Webpack module federation полностью все повсеместно внедрят, но технология пока сырая, какие там проблемы будут тоже пока не ясно.
Для общения микрофронтов друг с другом вам понадобится shared шина, т.е. некая шина передачи данных и событий между клиентами, которые запускаются в рамках одного ядра. Эта шина может иметь доступ к какому-нибудь store на уровне ядра, чтобы сохранять состояние.
У меня готового рецепта в виде репозитория с кодом, к сожалению нет, есть проприетарные решения, которые я разрабатывал для проектов и компаний, они все за все эти годы сильно развивались, но так и не приобрели какого-то статуса “готового решения”.
Микро-фронты конечно не панацея. Почти все решения, которые я могу себе вообразить, можно сделать без них, даже если над решением работают много команд. Но есть определенные ситуации, когда это решение сэкономит много сил и нервов, а ещё сильно упростит CI/CD.
Первое на что мы попадаем в случае использования микрофронтов - инфраструктура. Теперь нам нужно разворачивать не одно приложение, а по сервису на каждое. А если ещё и dev/test/demo окружения + автодеплой веток для PR, так вообще где-то закрывается в шкафу один маленький devops
Вторая вещь - версионирование. Определенные версии одних сервисов работают с определенными версиями других сервисов и не всегда они обратно совместимы. Тут возникает соблазнм деплоить их все одновременно, но тогда пропадает часть профита от использования раздельных фронтов.
Третья - SSR (серный пре-рендеринг страниц). Тут вообще всё супер неоднозначно: тут и различный рендер в зависимости от роли пользователя и возможность предподгрузки при SSR основной SPA и ещё куча другого гемороя.
В 2020м при использовании микрофронтов нормальный SSR сделать врядли получится не подставив компанию на финансовые потери в виде трат на оплату времени разработчикам на R&D.
Интересный момент в закреплении решения “должен ли микро-фронт работать как standalone приложение или нет”. Плюсы есть у обоих решений, но я после опыта с различными подходами всё же за вариант, когда - да, должен работать как standalone.
Т.е. микро-фронт это не просто dumbless компонент, это полноценное приложение, которое может работать самостоятельно выполняя одну мелкую функцию или в рамках большого клиента, принимая от него настройки.
Тестироваться микрофронт соответсвенно должен изолированными тестами, покрывающими этот микрофронт. Т.е. команда поставляя свой микрофронт в качестве готового приложения, должна быть уверена в правильности его работы.
Важно покрыть не только внутренние сценарии, но и сценарии отработки на входящие данные и события (данные и события которые будут поступать от верхнеуровнего ядра).
Одна из проблем с которой столкнулись и так и не выработали однозначного решения - это back-for-frontend паттерн, т.е. обязательное использование api gateway, или другими словами использование единого эндпоинта для всех запросов для каждого микрофронта или всего приложения.
При использовании BFF мы упрощаем жизнь фронт разработчикам, вся логика работы с микросервисами хранится в отдельном гейте. Но мы получаем узкое место, если сотни клиентов начнут бомбить запросами гейтвей, он начнет тормозить или ляжет - получаем бутылочное горлышко
Ещё становится весело, когда каждый микросервис работает со своим протоколом. Т.е. представим: у нас есть переиспользуемые компоненты, например компонент “таблица”. Но данные от всех микросервисов приходят в абсолютно разном виде.
А бывает даже не только в разном виде, но и в разной спецификации: rest, jsoapi, graphql и т.п. Т.е. мы должны на клиенте получить данные, обработать, привести к единому виду и скормить в компонент. Тут, чтобы не перегружать клиент, поможет BFF, который отдаст всё в готовом виде.
Но если же отказываемся от BFF и все запросы от фронтов шлем напрямую в микросервисы, то перекладываем всю обработку данных на клиент, и как следствие замедляем работы самого фронта.
Самый очевидный пример, который у нас был: Два приложения, одно с BFF, другое без. У первого рендер на больших объемах данных на 0,5 сек быстрее, потому-что парсить данные не нужно, приходят от гейтвея в готом виде.
Вроде бы всего 0,5 сек, а глаз это видит, и в итоге заказчик выбирает решение, которое отрисовывает форму визуально быстрее, не понимая, что за этой быстрой отрисовкой идёт просадка, когда пользователей становится 100k+.
Поэтому вроде бы в back-for-frontend есть смысл, когда количество клиентов такое огромное, что инфраструктура подводит. С другой стороны при таком кол-ве клиентов уже можно и кластеризацию нормально сделать и поднимать несколько BFF.
Ещё один плюс back-for-frontend - отсутсвия гемора с проксированием. Проксирование в таком случае можно даже в риалтайме регулировать, просто обновляя гейтвей, пользователи ничего не заметят.
Когда же проксирование сделано прямо на клиенте, то при изменении адресов сервисов (что в целом редкость), пользователю придется обязательно как минимум обновить страницу.
Для бизнеса микрофронты не понятны. Т.е. вот мы делали монолит, зачем нужны микросервисы на бэке мы поняли, а зачем нам иметь несколько фронт приложений, если можно иметь одну SPA собирающуюся из npm модулей, “зачем нам это всё?”.
“А ещё и нет best practies, значит подход сырой, значит точно нам это не нужно”, - так отвечают почти все. При всех плюсах и минусах микрофронтов, действительно нельзя сделать однозначного решения в одну или другую сторону, по крайней мере на проектах с DAU меньше 100k человек.
Тред (Николай Говоров)
@jsunderhood чот напомнило о фрилансерской разработке типа галлерею делает один калькулятор - другой каталог товаров - третий никто друг друга не знает, все тащат свои библиотеки и версии В итоге страница открывается полминуты Должен быть какой-то общий архитектор, нет?
В точку. Общий системный архитектор - обязательно. twitter.com/Cherepanov206/…
Если вы frontend, как попали во фронт?
Если были, почему ушли?
Воскресенье
Умеете питчить? Когда-нибудь питчинг помогал вам с трудоустройством? Как должен выглядеть идеальный питчинг фронтэнд разработчика?
В азиатской культуре рассказывать о себе в таком «продающем» ключе - не вежливо. Собираетесь работать, например, с китаем, не рассказывайте о себе, пока не спросят.
В американской культуре - обратная ситуация. Если вы просто молча делаете своё дело, то это не всё. Нужно уметь ответить на вопрос «А в чём ты хорош?»
В Европе и России, по-разному, по ощущению зависит от корней компании и даже основателей. Чаще воспринимается как «говоришь много, ты лучше покажи дело».
Но при этом просто скромно молчать - тоже плохо, нужно как минимум уметь рассказать о своем опыте и технических достижениях. Основное влияние производит как раз американская культура компаний
Тред (Николай Говоров)
На днях придумывали как отменять повторяющиеся gql query при использовании apollo batching. Основная засада когда надо отменить один query в реквесте.
Пока варианта два: Либо такие запросы не батчить (отстой); либо отменять, только если весь пакет запросов не актуален (можно жить, но тоже так себе). Как живете с этим ? :) А ну или вариант не отменять протухшие запросы, но тогда будет страдать и пользователь и сервер
Назовите вашего кумира мира фронтэнд разработки
Ну, что, ребятушки! Неделя у руля @jsunderhood пролетела молниеносно, прогнали несколько околофронтовых тем, которые сам копаю в последнее время, поделились фронтэнд кумирами и как попали во фронт область.
Я начал с темы окружения, и расскажу, почему вписался в движ jsunderhood. Знаете, этот вечный момент, когда ты вроде бы полностью уверен в пути, но наступает транквилизирующая очевидность, когда ты так привык ко многим вещам, что они тебя уже не удивляют, не дают инсайтов.
И вот ты начинаешь искать новые способы взорвать себе мозг, добавить ко своим рецептам чужое виденье, чужую точку зрения, чтобы мыслить чище, эффективнее и рациональнее. И вот именно так всё мутишь новые и новые проекты и пробуешь всё новое и новое.
Кому-то такие треды зашли, кому-то нет, я как всегда рад, даже если хоть одному человеку я дам какой-то инсайт, правило шести рукопожатий никто не отменял и уверен, что в будущем нам всем это будет полезно.
Ещё, кстати, напоминаю, что если вам интересно как работают отделы разработки крутых компаний, то на канале @huntITru я болтаю с руководителями IT департаментов компаний.
Так вот, jsunderhood позволяет обогатить своё окружение, ведь если кто-то на одной волне со мной, он всегда теперь может написать мне @inemiro1 и поболтать, всегда открыт к предложениям и новому. Спасибо за эту возможность.
Каждому посылаю луч добра за каждый лайк, который вы поставили и три луча добра за каждый репост, который вы сделали. Передаю руль.
Тред (Николай Говоров)
Понедельник
Привет! Так сложилось, что с вами @govorov_n. Я фронтендер в департаменте автоматизации BIOCAD -- биотехнологической компании полного цикла.
Буду рассказывать, как мы делаем фронтенд продукта для производства и лабораторий, бок о бок с АСУ ТП.
P.S. А земля круглая.
Основная тема — разработка под производство, но если хочется другого — спрашивайте.
План:
- АСУТП, лабораторные и производственные установки, их софт;
- датчики, установки, ПЛК mqtt/modbus;
- процессы, GMP и валидация софта;
- специфичное в архитектуре.
Надеюсь на фидбек зала.
Стоит отметить, что в работе в фарме есть свой шарм.
В первый день, когда мне делали экскурсию по производству, инженер сказал: «если видишь как научный сотрудник бежит по коридору — беги в ту же сторону, разберёшься после».
А, ну и тред безумных фан-фактов в пятницу, разумеется.
Если кому-нибудь станет интересно, то напишу мотивационное, почему я тут а не в большом и привычном IT.
Вторник
Конечная цель — создать пайплайн, в котором можно отследить полный путь продукта, от первых измерений реактивов в исследовательской лаборатории, и температуры в комнате в этот момент, до упаковки ампулы в коробку.
С другой стороны, мы стараемся избавлять коллег от ненужной бумажной работы — зачем писать измерение с весов в бумажный журнал, если можно было бы собрать его сразу с прибора и тут же связать с данными о исследовании?
Соответственно, мы работаем с двумя основными блоками оборудования: лабораторным (весы, поляриметры, иономеры, жидкостные хроматографы, etc) и производственным оборудование (холодильники, биореакторы, etc), и это два совсем разных кейса.
Лабораторное оборудование, можно условно разделить на обычные приборы, и те у которые есть встроенные комп со своей ОС.
Ключевым отличием именно лабораторных железок, в том что они, во-первых, не всегда имеют програмный интерфейс, а во-вторых их много и они разных.
Например, в лабах сотни весов, десятка производителей которые постепенно закупаются 20 лет.
На самых новых уже есть какой-то API, на более старых COM порт на принтер чеков.
В некоторых есть дополнительный функционал вроде авто-калибровки или измерения влажности, а в других нет.
Среда
Другая проблема — не все устройства достаточно производительны чтобы резолвить DNS и могут только открыть TCP-сокет по прямому IP.
Другими словами, универсально мы можем гарантировать, что любая железка может записать буфер текста с чеком по IP.
Дальше, следите за руками
На каждое устройство написан парсер, который преобразует буфер в текста в универсальную структуру.
Берём виртуалку, на ней стартует сервер который занимает промежуток портов, скажет 10000-15000.
Порт это id устройства, по порту на каждый тип.
Сервер смотрит на какой порт приехал запрос, выбирает парсер, пробует разобрать чек.
Если получилось, то отправляет структуру в очередь на дальнейшую обработку, иначе записывает сырой чек в базу и алертит.
Универсальное правило — хранится вообще всё, битые чеки тоже.
Дальше данные будут слинкованы со всем что мы знаем — пользователь который делал измерение, эксперимент, раствор (для весов) пластина (для поляриметра), температура/влажность в помещении.
Запись уезжает в базу и с этого момента её менять нельзя.
С этого шага данные доступны на фронте.
Базовая задача — построить по ним отчёт, показать кто что и когда.
Вроде такого:
С производственным оборудованием интереснее — установка одинаковые, и часто сделаны нашими конструкторами.
С другой стороны, с ними нужно быть осторожнее — будет обидно по глупости испортить 2000 литров клеточной массы созревающую вторую неделю из-за ошибки.
Пятница
Сердце каждой установки — ПЛК, программируемый логический контроллер. Это промышленный стандартизированный контроллер в который заведены все датчики, механика, он же подключен к сети.
ПЛК может удалённо управляться по протоколу mqtt
Контроллер работает просто — с заданной частотой, он полностью выполняет всю свою программу от и до.
На каждом шаге берёт данные из оперативной памяти и использует их как параметры — нужно ли открыть заслонку, или, может поднять температуру.
Для каждого датчика в системе задаётся 4 параметра:
hh — верхний аварийный
h — верхний предупредительный
l — нижний предупредительный
ll — нижний аварийный.
Соответсвенно, предупредительный означает что что-то идёт не так, аварийный что всё сломалось.
Примерно каждую секунду мы собираем данные с установок и архивируем в Click House. Если есть предупреждения/аварии то рассылаем в алерты инженерам, чтобы бежали чинили.
Дальше вступает веб и позволяет отслеживать данные с этих установок
Тред (Николай Говоров)
@jsunderhood Оп материал дизайн. На чём фронт? Ангуляр?
TS, Angular, Nest, Go, k8s twitter.com/seminioni/stat…
Суббота
@govorov_n у вас ходят шаттлы?) pic.twitter.com/OGF5yE5KiI
