Good dev knows

2021-12-01 13:02:07 Про Рождественский календарь для разработчика

В Европе есть традиция Рождественского календаря. Это календарь на первые 24 дня декабря, который "помогает" дождаться Рождества. Обычно что-то с 24 дверками, на каждой написано число от 1 до 24. Каждый день вы открываете одну дверку и там вас ждет сюрприз. Насколько я знаю, в и такая традиция тоже проникает последние годы.

В общем, что такое календарь ясно, а причем тут Хороший разработчик?

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

Ниже подборка календарей на 2021 год:

Advent of Code

Самый известный. У него даже есть свой subreddit. Это календарь для всех разработчиков, технология не важна. Каждый день появляются задачки, вам нужно их решить. Можно соревноваться с другими.

Java advent

Календарь про JVM технологии. Каждый день новая статья. То что нужно любителям Kotlin или Java.

bekk christmas

В предыдущие годы эти ребята делали отдельные календари по куче технологий. А сейчас решил разместить это на одной платформе. Каждый день за каждой дверцей вы сможете выбрать интересные для себя статья по React, JavaScript, UX и не только.

Advent of GraphQL

Немного кустарный, но тоже интересный. Если вы интересуетесь GraphQL, но еще не использовали, то сможете подтянуть эту технологию, тратя на это по 5 минут в день.

Еще раз — можно провести декабрь с пользой.

Знаете еще какие-то хорошие проекты? Пишите в комментариях.

#хардскиллы Открыть/Комментировать

2021-11-29 11:52:54 Что важнее development experience или cost optimisation?

Примерно 4 года назад, я работал над проектом, который включал в одном репозитории бэк-энд и фронт-энд. Бэк-энд был на Node.js, а фронт-энд на React. Причем сервером для React фронт-энда выступало это же Node.js приложение. В итоге все собиралось вместе, запаковывалось в Docker и запускалось на настоящем железном сервере (нескольких, арендованных в OVH).

Чтобы React приложение стало готово к продакшену его надо собрать. Собиралось все на TeamCity, у которого был свой пул воркеров. И вот как-то раз я заметил, что весь процесс сборки и деплоймента занимает целых 20 минут . Для Node.js + React приложения с легким Docker контейнером это долго.

Я начал смотреть внимательнее и увидел, что сам билд React приложения и Docker контейнера занимают ~15 минут. А у меня на машине, тогдашнем Macbook Pro, это происходило за 5 минут. Почему? Я быстро предположил что дело в жестком диске. У меня был точно SSD, а что было на воркерах TeamCity? Я спросил у наших DevOps — мне ответили, что там HDD.

Окей, причина проблемы обнаружена. Я решил, что это надо исправить. Написал письмо команде наших DevOps. В письме я рассказал, что команда из 8 человек каждый день *N* раз ждет лишние 10 минут. Обычно более часа в день. И ждет не только наша команда, другие команды тоже ждут, пока собираются их приложения, просто они не жалуются. Очевидно, что если мы заменим диски на воркерах, то наша эффективность увеличится.

Кому-то очевидно, а кому-то нет. Мне пришел пространный ответ, что в целом я прав, но сделать это очень сложно, поэтому давайте лучше этого не делать. Работали ведь раньше и все было хорошо. А еще это будет стоить дороже. Давайте и дальше работать и чтобы все было хорошо .

Я решил продолжить и пошел с этим же вопросом к инженеринг менеджеру, который был и менеджером DevOps команды. Он мне тоже сказал что идея хорошая, но вот нельзя просто так взять и изменить это. Это будет стоить дороже. Нельзя просто вытащить одни жесткие диски и вставить другие, это надо просить OVH. Или менять серверы на новые. И команда DevOps тоже не виновата, у них есть другие важные задачи.

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

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

Как вы считаете, кто был прав? Пишите в комментариях.

#истории Открыть/Комментировать

2021-11-26 12:00:10 Что такое Cognitive complexity

Под термином Сognitive complexity (когнитивная сложность) обычно понимают следующее — как сложно постороннему разработчику будет интуитивно понять ваш код.

Мои "любимые" примеры такой сложности, про то время, когда люди стремились к "эффективности" кода и везде. Например, в JavaScript, использовали битовые операции. Они ведь быстрые.

Что делает код 8 >> 1? Делит 8 на 2. Понимал ли я это когда-то без дополнительного гугления? Нет. (Ну только в следующие 3 минуты после предыдущего гугления). Этот код сложный для восприятия. Обычно такой код писать не надо, нужно писать только в том случае, когда вы действительно оптимизируете на производительность.

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

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

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

Еще раз — когнитивная сложность это важно, чем ниже она, тем проще работать и поддерживать этот код или CI файл. Когда что-то делаешь, то нужно себя спрашивать — это будет сложно понять постороннему человеку?

Какова когнитивная сложность постов в этом канале? Пишите в комментариях.

#софтскиллы Открыть/Комментировать

2021-11-25 11:21:25 Перевел статью про git bisect для Хабра.

Используете такое? Делитесь опытом в комментариях. (и ставьте на Хабре )

https://habr.com/ru/post/591447/ Открыть/Комментировать

2021-11-24 11:34:28 Что такое N-tier application

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

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

Это классический 3-tier architecture. Иными словами, в нашем сервисе есть presentation tier, application tier и data tier.

Мобильное приложение это presentation tier. Это интерфейс, который предназначен для пользователя.

Бэк-энд сервисы, которые помогают мобильному приложению работать это application tier, здесь живет бизнес логика. Повторяю, это не обязательно один монолит, несколько сервисов могут относиться к одному слою.

Базы данных, с которыми работает бэк-энд и которые обеспечивают сохранение данных это data tier.

3-tier architecture не является единственным возможным вариантом архитектуры. Представим, что наше мобильное приложение все запросы шлет через API Gateway, а этот gateway распределяет их по сервисам. Теперь у нас 4-tier architecture.

Как видите, слоев может быть сколько угодно. Поэтому в целом такой подход описания архитектур называют N-tier architecture.

Еще раз — любую архитектуру можно разбить на логические слои и описать как n-tier architecture. Не факт, что большее количество слоев делают архитектуру менее эффективной, но они усложняют ее понимание.

Со сколькими слоями сталкивались вы? Пишите в комментариях.

#хардскиллы Открыть/Комментировать

2021-11-23 11:22:21 Новости

Michael Jackson (не тот) и Ryan Florence придумали и поддерживают React Router — #1 декларативный роутер для React экосистемы. Этот проект open source, зато он сделал их известными на рынке. Поэтому зарабатывали они, насколько я понимаю, с помощью компании React Training — проводя оффлайн тренинги по React.

Но тут пришла пандемия и оффлайн тренинги перестали быть популярными, а онлайн, как я понял, не имели такого же размаха. Ребята решили сделать небольшой пивот и придумали, что они смогут сделать проприетарный (т.е. платный) фулстэк фреймворк для веб разработки. С React, server rendering, улучшенным роутингом и своими фичами. Они назвали его Remix.

Мне эта идея не казалась здоровой, потому что в 2021 не должно быть платных фреймворков. Но недавно все изменилось. В октябре они анонсировали, что получили 3.000.000 инвестиций и приняли решение сделать свой фреймворк open-source.

Сегодня день релиза, можно посмотреть пощупать: https://remix.run/. В общем альтернатива Next.js.

Еще они сделали красивое промо видео, из которого я ничего не понял, кроме как то, что оно красивое.

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

Слышали об этом проекте?

#новости Открыть/Комментировать

2021-11-22 11:52:15 Про типы компаний и карьерный рост

Мнение. Ваш рост в большой продуктовой компании никак не коррелирует с вашим, возможным, рангом в FAANG компании.

Да, мы и раньше знали, что Senior в одной компании необязательно Senior в другой компании. Ты можешь быть самым умным и опытным Senior в компании из 20 разработчиков, а потом переходишь в компанию где их 200 и там ты просто Middle. Но если мы сравниваем большие компании с хорошей инженерной культурой, должно же быть иначе?

Нет. Возьмем меня, я вот рос рос и дорос до Principle Software Engineer в компании с хорошей культурой, умными и мотивированными людьми и большим количеством инженеров. Но если я решу апплаиться в Facebook, будут ли там впечатлены моими достижениями? Нет. Без предварительной подготовки меня размажут вращением деревьев, сортировкой массивов и знанием латенси между датацентрами. Да, я читал, что при собеседованиях в Amazon ожидается, что ты знаешь латенси и учитываешь это при проектировании системы.

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

В этом году вышла интересная статья, где автор рефлексирует про типы технологических компаний в Европе и где какие платят зарплаты. Там он приходит к выводу, что получать огромные деньги можно, люди это делают, компании платят, но такие позиции уникальны для общего рынка. В частности рынка, на котором играет SHARE NOW. Работа в Big Tech лишь издалека похоже на работу в Tech, а если приблизить, то очевидно, что там другие правила.

Это как плаванье и бег. Если я умею быстро плавать (SHARE NOW), то это не помогает мне быстро бегать (Netflix). Хотя и то и то — спорт.

Но есть и хорошие новости. Если будучи в Украине, в прошлом, я думал что в Google попасть сложно или невозможно. То сейчас, я понимаю что это целиком возможно и секретный соус в следующем:

1. Принять, что мой прошлый опыт для них не релевантен. Зато релевантен для меня, он поможет мне с пунктом два.
2. Нужно потратить время (много) и подготовиться. Cracking the coding interview и https://leetcode.com/ нон стоп и все будут довольны.

Что думаете? Есть среди нас люди из FAANG или другого BigTech? Интересно ваше мнение.

#истории Открыть/Комментировать

2021-11-20 11:46:20 Открыть/Комментировать

2021-11-20 11:45:44 У кого есть дети, я написал лонгрид о том как практики из IT помогают мне быть хорошим родителем. У кого нет детей — тоже может быть полезно :)

https://dou.ua/forums/topic/35409 Открыть/Комментировать

2021-11-19 12:26:06 Что такое Glue work

Когда люди не из IT представляют себе рабочий день разработчика, то, уверен, они представляют, что мы программируем 8 часов в день, потом закрываем ноутбук и идем к семье. Но мы знаем, что ежедневная жизнь современного разработчика это не только разработка и регулярные Agile ритуалы.

Есть еще:
* нерегулярные технические митинги
* пришел новичок, ему надо обо всем рассказать и включить в работу.
* команда решила как бороться с техническим долгом, надо создать тикеты
* заметили, что документация устарела — надо обновить
* отдел маркетинга долго не отвечает на вопрос про бизнес логику — надо им напомнить
* узнали про новую технологию и думаете что она пригодиться — надо подготовить презентацию
* что еще? таких мелких задачек куча

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

У таких задач есть название — Glue work, а люди, которые этим занимаются — они being a glue. Потому что они, фигурально, склеивают сложный пазл разработки программного обеспечения и с ними определенно легче, чем без них.

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

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

Еще раз — помимо разработки в IDE Хороший разработчик может делать еще кучу дел, которые делают команду эффективнее. Нужно понимать, что эти "мелкие" дела они сами по себе работа, может даже важнее программирования. Этим может заниматься каждый, не только менеджеры. Людей которые это берут на себя нужно за это благодарить (если они это делают хорошо). Glue work это классно и это тоже скилл.

Согласны? Пишите в комментариях.

#софтскиллы Открыть/Комментировать