Никита Крижановский
699 subscribers
33 links
Download Telegram
Топ 3: что думают о крипте люди, которые работают в ней, как устроены браузеры изнутри и список ресурсов по тестированию распределенных систем.

1. Ask HN: Does Anyone else working in a crypto company feel this is all a scam?

TLDR: Вечное обсуждение на тему “крипта это скам или нет”.

Часто такие обсуждения – это куча бесполезного мусора. Кому интересно мнение среднестатистического Джо, у которого мир разделен на полярности – плохо и хорошо?

Но тут немного иначе.

Обсуждают те, кто работают в крипте. Так что тут можно посмотреть изнутри. Это полезней и интересней. Особенно для тех, кто хочет присоединиться к крипта проектам как разработчик.

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

Еще на тему крипты, скама и NFT понравилось вот это расследование – NFT и теории заговоров: Кто на самом деле стоит за продажей джипегов по $300k. Очень круто. На хабре иногда такие самородки можно встретить, прям ух.

2. Web Browser Engineering

TLDR: Книга, которая рассказывает, как работают веб-браузеры, на примере создания одного из них с помощью Python.

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

3. Testing Distributed Systems

TLDR: Огромный список ресурсов по тестированию распределенных систем.

🔥 Открытие Недели

Gut microbe linked to depression in large health study.

Вместе с этим, пару дней назад популярный биолог Dr. Rhonda Patrick рассказала про то, что 50% молекул, обнаруженных в крови человека, происходят от бактерий в кишечнике.

Так что все, что мы едим, напрямую влияет на наше состояние. Как на физическое, так и на эмоциональное.

Пойду закажу кефир и пробиотики.

Хорошей недели 🌞
Топ 3: поиск Google умирает, 20 паттернов поведения инженеров и когнитивные искажения которые использует Amazon

1. Поиск Google умирает

TL;DR: Почему гугл часто показывает не релевантный шлак и почему Reddit – это новый гугл.

Классная статья, особенно начало:

“Сегодня самый популярный поисковый движок — это Reddit. Единственные, кто этого не знает — команда Reddit, которая не может отвлечься на создание приличного интерфейса поиска. Поэтому вместо этого нам приходится прибегать к Google и добавлять в строку запроса слово «reddit».”

После нее, кстати, я понял, что не я один пользуюсь гугл как: запрос + “site:reddit.com” или запрос + “site:github.com” или запрос + “site:stackoverflow.com”. Особенно когда это касается поиска отзывов о каком-то продукте или поиска ошибки, которая вывалилась мне в консоль.

2. 20 patterns to watch for in your engineering team (pdf)

TL;DR: 20 шаблонных поведений команд и людей, как их заметить и что с ними делать.

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

К примеру, там описан Hoarding the Code [когда кто-то комитит огромными кусками кода, которые невозможно ревьюить], и рассказано, как это отловить и как исправить.

3. The Psychology of Purchasing Something on Amazon 🔥

TL;DR: Когнитивные искажения, которые использует Amazon на флоу покупки товара.

И так, что использует Amazon:

1. Dark pattern [куда ж без него] – когда заходишь на страницу товара, автоматически выбрана подписка вместо одноразовой покупки.

2. Anchoring – когда мы используем не релевантную информацию для принятия решения. К примеру, амазон показывает, что одна банка омеги 3 стоит $21.97, а рядом пишет “$0.12/за одну капсулу” – смотря на это, можно подумать “оу, это вроде очень дешево” хотя мы не знаем, сколько стоит одна капсула омеги от других брендов.

3. Social proof – когда люди копируют действия других в новой для себя ситуации. К примеру, амазон дописывает “most common” к кнопке покупки большой банки омеги.

На самом деле все обычно и ничего криминального.

Ребята с Growth Design, которые разобрали флоу покупки амазона, всегда делают вкусно и интересно. Кто еще не знает про них, зайдите на их сайт и пощелкайте по другим UX разборам популярных сервисов. Тем, кому интересно создание продуктов, кайфанут и найдут новые идеи.

На этом все, хорошей недели ❤️‍🔥
Всем привет. То, что происходит на протяжении недели, страшно. Сам я этот страх вижу только в новостных группах, но очень хорошо слышу в голосе родственников из Киева, а особенно из Харькова. Надеюсь, этот пиздец скоро закончится.

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

- “Что делать когда чувствуешь страх и бессилие” (вебинар психотерапевта)
- Душевный госпиталь
- Как и зачем написать депутату
- Техники по уменьшению тревоги и приходу в эффективное состояние
- Гайд по тому как жить айтишнику в 2022 году
- Подробный гайд по Казахстану
- Подробный гайд по Армении
- Канал про релокацию в Армению
- Как защитить свои активы с помощью крипты (crypto 101)
- Роберт Сапольски с точки зрения науки о своих, чужих и вооруженных конфликтах

Если есть что добавить — пожалуйста, напишите в комментариях. Всех обнял 💛
Топ 3: почему технический долг это плохо, гайд для Rust и распорядок дня Элизабет Холмс.

1. We sound like idiots when we talk about technical debt

TL;DR: Как объяснить бизнесу, почему технический долг – это плохо.

Для начала надо ответить самому себе на вопрос, почему это плохо (ответ в духе “нуу это же плохо” не принимается)

Как этот сделать?

Есть одно веселое упражнение 5 whys, в которое играют все дети мира. Суть в том, что ты задаешь себе вопрос почему до тех пор, пока не найдешь ответ. Его мы и применим.

Итак, берем первый вопрос и поехали:

- Почему тех долг это плохо?

- Потому что код становиться сложным

- Почему это плохо?

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

- Почему это плохо?

- ...ответ...

- ...почему...

- ...ответ...

- Это плохо для компании, потому что она не дополучает X% от возможной выручки в год

А вот и ответ! Всем спасибо за участие.

2. Writing an OS in Rust

TL;DR: Обучение языку Rust с помощью написания небольшой операционной системы на нем.

Для тех, кто хочет прыгнуть в веб 3.0 и получать $10K+ (или какая там сейчас вилка на rust разработчиков) будет полезно.

3. Things that used to be hard and are now easy

TL;DR: Штуки которые раньше были трудными, а теперь стали простыми.

Вот боль, которую я лично помню:

- центрирование до flexbox
- SSL сертифиаты до Let’s Encrypt
- создание кроссплатформенных приложений до Electron
- настройка среды разработки до Docker
- настройка облачной инфраструктуры до Terraform
- поддержка IE до того, как он умер (спасибо гуглу за хром, а капитализму за конкуренцию 🤝)

🐦 Твит недели

Распорядок дня Элизабет Холмс.

Чисто расписание главного героя Американского Психопата.

Кто не знает, это CEO стартапа Theranos, которая заявляла, что они изобрели революционную технологию для быстрого, дешевого и подробного анализа крови. Насобирала столько денег, что на пике стартап оценивали в $10 лярдов. А по итогу оказалось, что никакой заявленной технологии нет и никогда не существовало. За такую красивую аферу Элизабет сейчас кстати судят.

Берегите себя и хорошего всем дня!
Топ 3: от чего отказываются инженеры, становясь менеджерами; как FAANG компании работают с документацией; гайд о том, как валить и совет от Илона Маска

1. What you give up when moving into engineering management

TL;DR: От чего отказываются инженеры, становясь менеджерами:

1. Время на сфокусированное решение задач, из-за частой смены контекста
2. Короткие циклы обратной связи, из-за того, что результат твоей работы не виден так быстро, как при нажатии cmd + s
3. Принятие технических решений (obviously)

2. Инструкция для тех, кто решил, что уже пора

TL;DR: Гайд о том, как и куда валить.

В комментариях вы найдете много полезной инфы по разным странам.

3. How Google, Twitter, and Spotify built a culture of documentation

TL;DR: Как Google, Twitter и Spotify эффективно работают с документацией.

Статья для тех, кого бесит их Confluence с кучей беспорядочно лежащих доков.

Основные выводы:

• Писать документацию всем лень, многие считают, что это не их работа, и нет готовых инструментов, чтобы это делать.

• Чтобы люди начали писать документацию надо (1) уменьшить когнитивную нагрузку, чтобы было проще начать, (2) стандартизировать процесс написания с помощью шаблонов и (3) привить культуру написания документации внутри компании.

Твит недели

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

В построении деревьев, кстати, очень хорош Miro.

Хорошей недели 🌞
Топ 3: почему больше нет гениев, как принимать сложные решения и тулза для генерации документации как у Stripe

1. Why we stopped making Einsteins

TL;DR: Интересная теория о том, почему сейчас мы не видим такое количество гениев, как в прошлых веках.

И так, почему же?

• Про это мало кто знает, но с детства ко многим будущим гениям были приставлены лучшие репетиторы в своих сферах. К примеру, у Марка Аврелия их было 17: 4 по грамматике, 4 по риторике, 1 по юриспруденции и 8 по философии. Неплохо.

• В то время детей не обучали с целью “набрать наибольшее количество баллов для поступления в заведение Х”. О чем это говорит? Что учили всему и учили без спешки. Сейчас же родители нанимают репетиторов, чтобы детей научили только тем знаниям, которые нужны для сдачи теста, при том нанимает за 1-2 года до самого теста, что ограничивает количество времени и следственно количество знаний.

• Как выяснилось, доступ к информации практически не влияет на появление гениев.

Вот такие выводы из статьи.

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

Другим ключевым фактором, я думаю, стала скука.

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

Так вот, если мы возьмем 18 век, когда у тебя выбор особо не большой, пойти в реку камни покидать или начать читать книги (если ты умел конечно), то через какое-то время кидать камни надоест.

Кто помнит, когда он скучал в последний раз?

2. Tools for making difficult decisions

TL;DR: Ментальные модели для принятия сложных решений.

3. Generate Stripe-Like API Docs

TL;DR: Тулза для генерации доков в стиле Stripe – таких же красивых.

Хорошей недели ❤️‍🔥
Топ 3: технический долг это не плохо, пирамида тестирования и список репозиториев с чистым кодом.

1. Technical Debt – Good or Evil?

TL;DR: Что такое на самом деле технический долг, и почему это не плохо и не хорошо.

Мои заметки:

• Технический долг – это не плохо и не хорошо, это инструмент для достижения определенных целей: сократить время выхода на рынок, расходы на разработку и экономия ресурсов.

• Плохо написанный код или неправильно выбранная библиотека – это не технический долг, это неправильно выбранное решение задачи.

• Технический долг надо брать осмысленно, с четким планом по его выплате.

• Если не платить технический долг, произойдет обратное от того, зачем его брали – увеличится время выхода на рынок, расходы на разработку и количество необходимых ресурсов (время и деньги) на разработку

2. The Code Review Pyramid

TL;DR: Интересная ментальная модель в виде пирамиды о том, как проводить код ревью.

Слишком сложная, чтобы применить на практике, но вынести что-то для себя можно.

3. Ask HN: Codebases with great, easy to read code?

TL;DR: Список репозиториев с чистым кодом, чтобы посмотреть на “хороший” код.

И забавный твит недели от одного из создателей CSS:

“!important был добавлен только по одной причине: законы США требуют, чтобы определенный текст был в заданном размере шрифта. !important останавливает каскад от его изменения”

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

Хорошей недели 🌞
Топ 3: что нового в React v18, рефлексия о позиции СТО и визулизированные SQL запросы.

1. React v18

TL;DR: Что изменилось в React v18.

Из интересного:

- Появился параллелизм (concurrency). Как я понял, это внутренняя механика, с помощью которой реакт может прерывать рендеринг на середине, выполнять какие-то задачи а затем возвращаться обратно к рендерингу (раньше рендеринг был синхронный). Это позволит мгновенно реагировать на пользовательский ввод, даже если компонента находится в процессе большой задачи по рендерингу. Видимо, теперь приложения будут выглядеть “плавнее” для пользователей.

- Добавили автоматический батчинг во все места, где раньше он не поддерживался: промисы, setTimeout, встроенные обработчики событий итд.

- Появились transitions. Новая фича, с помощью которой мы можем устанавливать срочные и несрочные обновления состояния компонентов.

- Добавили новые хуки: useId, useTransition, useDeferredValue, useSyncExternalStore и useInsertionEffect.

Если резюмировать, что нового в React 18 – улучшение UX для пользователей.

2. CTO last day: reflections, mistakes, and some learnings

TL;DR: Рефлексия СТО о позиции СТО.

Из интересных вынесенных уроков:

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

- Технологии – всего лишь инструмент для решения бизнес задач.

- Любой процесс – это система. Если есть проблема в процессе, то рассмотри его с точки зрения системы. У системы всегда есть input, output и узкое горлышко.

3. SQL Visualizer

TL;DR: Визуализированное объяснение того, как работают SQL запросы.

И напоследок интересный твит – 20 уроков из 120+ интервью с легендарными инвесторами, основателями и руководителями.

Неделя была херовой, надеюсь следущая будет лучше. Берегите себя 💛
Топ 3: как найти классных разработчиков, список современных команд для терминала и какие ошибки допустил СЕО умных часов Pebble.

1. How to Freaking Find Great Developers By Having Them Read Code 🔥

TL;DR: Как находить классных разработчиков.

Как их пытаются найти сейчас:

- “напиши функцию которая делает Х”
- “а чему равно O большое?”
- “а давай это улучшим”

Проблема такого подхода в том, что такие интервью чаще проходят те кандидаты, которые прорешали кучу подобных задач и запомнили решение, а это мало говорит о способности кандидатов в реальной разработке (если только ваша разработка на прямую не связана с алгоритмами)

Кандидаты, которые таких задач не решали, в лучшем случае решат их самым не оптимальным способом. И когда их попросят оптимизировать решение до какого-нибудь O(log n), то они вряд ли смогут. Ведь обычно для оптимизации такого рода задач должен произойти “a-ha” момент, после которого ты понимаешь, как это сделать. А в рамках часа и под стрессом интервью это почти никогда не происходит.

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

Что предлагает автор:

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

Почему это эффективней:

- Чтение кода составляет 90% того, что разработчик делает в рамках своей работы. Не важно, пишет ли он новый код, исправляет баги или пишет документацию – при этом всем, он чаще всего считывает и анализирует то, что написано.

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

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

Думаю, такой способ также хорош, как и дать решить реальную задачу (по типу написания простенького чата с готовым бэкендом, которая занимает обычно под час)

Хотя, он может быть, даже более эффективным. За счет того, что кандидат испытывает меньше стресса + чтение быстрее чем запись = больше проблем можно рассмотреть и больше навыков протестировать = лучше узнать, перед тобой классный разработчик или нет.

О том, какой код давать и как выстроить весь процесс вы найдете в статье.

2. A list of new(ish) command line tools

TL;DR: Список современных команд для командной строки.

Вот так выглядит современная замена:

- ls → exa
- grep → ripgrep
- find → fd

Вот еще один список с альтернативами общим командам unix: тык.

3. Success and Failure at Pebble

TL;DR: История успехов и неудач умных часов Pebble от бывшего СЕО компании.

Если одним предложением:

“The underlying problem was that we shifted from making something we knew people wanted, to making an ill-defined product that we hoped people wanted.”

Судя по количеству разборов полетов, которые я видел и слышал, это одна из главных и очень частых ошибок. Сам ее часто делал пока меня не укусил product manager и сказал прочитать The Mom Test.

Хорошей недели ❤️‍🔥
Топ 3: гайд по работе с терминалом, GitLab handbook и какое будущее нас ждет с DALLE2

1. The Front-End Developer's Guide to the Terminal

TL;DR: Базовый, но очень хорошо написанный гайд по работе с терминалом.

Кроме описания основных команд как cd, внутри можно найти новые инструменты для разработки, к примеру автокомплит Fig (сам пользуюсь, огонь) и модный терминал Warp.

2. GitLab Handbook

TL;DR: Handbook о том, как устроена и управляется компания GitLab.

Там расписано буквально все: миссия, ценности, культура, финансы, маркетинг, продажи, как выглядят и устроены инженерные команды, шаблоны писем, да там даже расписаны OKR для каждого направления и показано, на сколько они их достигли в этом году. Там вся компания.

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

Думаю, будет ценно для компаний и команд которые сейчас выстраивают свои внутренние процессы.

3. DALL·E 2 and The Origin of Vibe Shifts

TL;DR: Какое будущее нас ждет после того, как мы увидели возможности DALLE2.

Кто не в курсе, неделю назад компания OpenAI показала миру новый AI под названием DALLE2.

Что он может?

Из любого текста сгенерировать картинку. К примеру, если ему скормить текст “астронавт верхом на единароге в фотореалистичном стиле” он выдаст вот такую картинку. Круто? Еще бы.

И тут встает вопрос: “А к чему это может привести?”. Ведь теперь, создать уникальный контент может кто угодно. И автор эссе тоже задался этим вопрос и решил поразмышлять о том, что же нас ждет.

Статья очень хороша и не хочется ее выжимать в tldr по выводам, но намекну, что случится первым. Помните, как где-то в 2015 круто было иметь стоковые фото на лендингах. А затем, когда появился Unsplash и другие, кто сделал студийные фото доступными для масс, все перешли на рисованные иллюстрации. Так вот, DALLE2 сделал доступными рисованные иллюстрацию для масс.

А мне так нравился лендинг Notion, эх.

Хорошей недели ❤️‍🔥
Топ 3: четыре эры JavaScript фреймворков, как работает DALL-E 2, энтропия и смысл жизни.

1. Four Eras of JavaScript Frameworks

TL;DR: Краткая история JavaScript фреймворков.

Будет интересно для тех, кто хочет узнать, какой была веб-разработка до того, какой мы ее привыкли видеть сегодня. Как все начиналось с Backbone.js и развилось до Remix, NextJS и NestJS.

2. How DALL-E 2 Actually Works

TL;DR: Детальный разбор того, как работает DALL-E 2.

3. It Took Me 10 Years to Understand Entropy, Here is What I Learned

TL;DR: Что такое энтропия, большой взрыв и тепловая смерть Вселенной.

Ох, энтропия.

Энтропия – одна из самых интересных концепций, потому что в ней может быть заложен ответ на вопрос “в чем смысл жизни”.

Это одна из немногих физических величин, напрямую связанная с направлением течении времени: в прошлом энтропия была ниже, в будущем энтропия будет выше. И есть гипотеза, что вселенная – это система, цель которой увеличивать энтропию, а жизнь – это ее агент, который помогает в этом. А любая система работает одним образом – максимально даёт ресурсы элементам, которые ей полезны и уничтожает элементы, которые ей вредны. Так что, если понять, какие действия приводят к увеличению энтропии, то можно получить кучу различных ресурсов – энергия, деньги, мотивация и так далее (а может и нет, ведь это всего лишь гипотеза) Но кому интересно углубиться в нее, советую прочитать ссылки выше, а дальше находить ответы в этой книге, этой книге и вот в этой книге.

Твит недели: “90% of the software engineering being done today is integrating poorly documented API A with poorly documented API B.”

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

Хорошей недели ❤️‍🔥
Топ 3: GraphQL это ловушка, тест на мудака от IBM и гайд по миграции БД без даунтаймов.

1. GraphQL is a trap + GraphQL is a Trap?

TL;DR: Твитер тред на тему минусов GraphQL и ответ автору от GraphQL энтузиаста из Netflix.

Как же полярно разделились мнения на тему GraphQL, если почитать комментарии к твиту. Половина хвалят, половина ругают. Трудно найти взвешенные мнения, но вот три вещи, которые я вынес из этой баталии:

- GraphQL – это дополнительная сложность. Любая сложность должна быть оправдана – количество эффективность которые она приносит, должно быть больше количество эффективности, которую она забирает.

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

- Гибкость получения данных с помощью GraphQL – это преимущество, за которое расплачиваешься перфомансом.

2. Changing Tires at 100mph: A Guide to Zero Downtime Migrations

TL;DR: Гайд по миграции БД без даунтаймов.

Как это выглядит высокоуровнево:

1. Create the new empty table
2. Write to both old and new table
3. Copy data (in chunks) from old to new
4. Validate consistency
5. Switch reads to new table
6. Stop writes to the old table
7. Cleanup old table

В статье будет пример с пошаговым процессом с SQL запросами по миграции базы в PostgreSQL.

3. Как мотивировать разработчиков

TL;DR: Как мотивировать разработчиков от Александра Поломодова (технический директор в Тинькофф)

Мои заметки:

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

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

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

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

Все красиво, все здраво.

И в конце, тест IBM на мудака.

Хорошей недели ❤️‍🔥
Топ 3: 31 урок из 10,000 часов программирования, Футурама и обзор десяти разных организационных структур.

1. Reflections on 10,000 Hours of Programming

TL;DR: 31 урок из 10,000 часов программирования.

Вот самые интересные:

- Simple is hard.
- Browsing the source is almost always faster than finding an answer on StackOverflow.
- Delete as much code as you can.
- Syntactic sugar is usually bad.
- If it looks ugly, it is most likely a terrible mistake.
- Good APIs are easy to use and hard to misuse.

Заметил, что почти во всех таких “X уроков после Y лет” присутствуют советы про уменьшение сложности. И сам много раз уже убеждался как “сложный код”, “сложное название переменных”, “сложная логика” напрочь убивали эффективность.

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

Сложные вещи это все, которые требуют много времени для их понимания:

- большие кодовые конструкции
- большие и плохо выделенные в ответственности абстракции
- плохо названные переменные, в которых нужно отсмотреть десятки строк кода, чтобы понять что они в себе хранят

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

2. 10 Progressive Organizational Structures Developed By Real Companies

TL;DR: Обзор десяти разных организационных структур.

Самое интересное, что почти все организационные структуры отличные от традиционной, иерархической, умерли. Разве что Spotify model до сих пор работает, хотя не ясно, насколько она эффективна и как это измерить.

3. If Programming Languages Were Futurama Characters

TL;DR: Как выглядели бы языки программирования, если бы они были персонажами из Футурамы.

“Bender Bending Rodríguez is... Shell

Lacks a backup unit, but able to self-assemble. Surprisingly versatile, but does not give a single fuck. Will take you to the suicide booth and steal your money. Needs alcohol to run, and largely avoids doing any real work, but can be used to bend anything.”

И твит недели: “The greatest skill one can develop is decreasing the time between idea and execution.”

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

Хорошей недели ❤️‍🔥
Топ 3: пять инсайтов о Facebook, CSS в 2022 и что разработчики Spotify поняли о инцидентах.

1. 5 interesting things about how Facebook works

TL;DR: Пять инсайтов о инженерной культуре в Фейсбук.

1. Разработчики автономны в выборе команд, над чем работать и как работать. Если менеджер скажет “работай над Х!”, а разработчик посчитает, что это плохая идея, то он может сказать нет.

2. Перемещение разработчиков между командами случается часто и происходит намного проще чем в схожих компаниях.

3. Фейсбук оценивает инженеров по четырем критериям: impact, direction, people and engineering excellence. Impact – бизнес результаты (как я понял, достижение бизнес метрик). Direction – твой инфлюенс на вектор развития команды, компании или индустрии. People – не технический импакт на организацию, как менторинг, онборадинг, интервьюинг. Engineering excellence – качество кода, качество архитектурных решений, улучшение инженерных практик. У всех этих критериев есть определенные метрики измерения. Интересно было бы посмотреть как ставиться direction и people.

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

5. Фейсбук почти не использует вендоров. У них есть свои внутренние продукты на все привычные нам тулзы, как свой github, jira, slack итд. Ну вы это и так знали.

2. State of CSS 2022

TL;DR: Обзор текущих и будущих возможностей CSS.

Что интересного нас ждет в 2022 и дальше:

- cascade layers – позволит задавать важность применения группы стилей.

- container queries ❤️ – элементы cмогут реагировать на размер или стиль родительского контейнера, та же механика, что и у media query (скажем, если родительский div стал меньше 200px, то сделать padding 10px)

- accent-color – можно будет добавить brand color, который поменяет дефолтный цвет “активности” элементов (сейчас это синий) на выбранный вами.

- вложенность селекторов.

Это из интересного, по ссылке можно посмотреть еще больше изменений.

3. How We Grow from Incidents (Spotify)

TL;DR: Что разработчики Spotify поняли о инцидентах.

- Spotify бросает много сил на исследование того, что произошло. Как минимум один разработчик тратит большую часть дня на это. Они называются это – “trade productivity now for productivity later”

- 60%+ инцидентов можно было предотвратить с помощью лучшего покрытия тестами и алертами.

- Иногда ломать свою же систему это хорошо (еще бы)

И в конце твит недели – разбор сторителинг фреймворка, который Стив Джобс использовал для презентации первого айфона.

Пересмотрел эту презентацию пока писал пост и вот ну насколько же она крутая! Заново ощутил все те же эмоции предвкушения и инноваций как и в первый раз. What a man.

Хорошей недели ❤️‍🔥
Топ 3: сравнили React библиотеки для стейт менеджмента, список вопросов для рефлексии и малоизвестные CSS фичи.

1. React state management libraries in 2022

TL;DR: Сравнение всех библиотек для стейт менеджмента.

Сравнили все – React Context, mobx, react-tracked, redux, zustand, jotai, recoil, xstate. И сравнили очень хорошо – показны плюсы, минусы, нюансы и размышления автора.

Какая библиотека оказалось лучшей?

Для автора – redux-toolkit и zustand.

Вообще “лучшей” библиотеки нет, есть лучшая библиотека для чего-то. Для определенной проблемы, команды, целей, продуктов, скорости и тд. Это также как прийти в магазин стройматериалов и сказать «дайте мне лучший инструмент». Вас спросят «для чего?»

2. Question Bank for Managers

TL;DR: Список вопросов для рефлексии.

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

3. Lesser-Known And Underused CSS Features In 2022

TL;DR: Малоизвестные способности CSS.

Рассказывают про:

- all
- currentColor
- custom property fallback
- counters (не знал, прикольно)
- interaction media queries
- :where & :is
- scroll-padding (тоже не знал, отличная штука!)

И в конце твит недели:

“Every time I have a programming question and I rly need help, I post it on Reddit and then log into another account and reply to it with an obscenely incorrect answer. Ppl don’t care about helping others but they LOVE correcting others. Works 100% of the time”

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

Хорошей недели ❤️‍🔥
Топ 3: 16 инсайтов после 5 лет тех аудита стартапов, как будет выглядеть программирование в 2050 и почему так много devops вакансий, если есть kubernetes?

1. Learnings from 5 years of tech startup code audits

TL;DR: 16 инсайтов о продуктах и технологиях после 5 лет тех аудита стартапов.

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

• Стартапы, которые по итогу стали очень успешными, сверх нагло использовали подход KISS (Keep It Simple Stupid). Их технические решения были до примитивности простыми. С другой стороны, стартапы, где код был написан так, что хотелось сказать: “Вау, это очень умно”, почти все умерли. И конкретная вещь, которая у них у всех была общая, это преждевременный переход на микросервисы и распределенные вычисления.

Вот это оочень интересная информация.

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

Я знаком с таким подходом – только “агностик” решения, кучу абстракций, чтобы не “зависеть” от определенных технологий, “я сделал X, потому что в будущем может быть случится Y, и тогда мы сможем быстрее сделать Z”.

Как правило, все перечисленное не оправдывает себя: технологии и фреймворки не меняются, абстракции становятся не поддерживающимся сложным “легаси кодом”, а будущее, которое “может быть наступит” не наступает. В итоге мы получаем систему, которую строили (1) дольше чем могли бы, и которая (2) сложная, что уменьшает эффективность разработки в целом.

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

• Иногда, самые большие продукты с огромным набором фичей создавались маленькими, но очень сильными командами (выходит, 10х инженеры это не миф)

• Фаззинг (техника тестирования, когда на вход подаются данные, которые могут привести систему к аварийному или неопределённому поведению) оказался очень эффективным с точки зрения потраченных часов на него к количеству выявленных уязвимостей, особенно на большых кодовых базах.

• Практически у всех были секьюрные проблемы с JWT токенами и вебхуками. С вебхуками люди часто забывали аутентифицировать входящие запросы. С JWT токенами не правильно могли проверять подлинность токена или просто могли доверять ему по умолчанию.

2. Programming in the Apocalypse

TL;DR: 3 инженера решили хорошо провести время ночью в парке Дании и поразмышлять, как будет выглядеть разработка в 2050 году, когда глобальное потепление окажет существенное влияние на привычный нам мир.

Статья очень крутая. Где еще можно прочитать о влиянии высокого уровня моря на контейнеризацию приложений или о влиянии пожаров на цену за CPU?

Как итог: интересно читать как фантастику и всгрустнуть, если представить, что хоть половина от того, что там написано окажется правдой.

3. Ask HN: If Kubernetes is the solution, why are there so many DevOps jobs?

TL;DR: Обсуждение вопроса на HN “Если Kubernetes вроде как создан упростить работу связанную с инфраструктурой, почему тогда существует такое большое количество вакансий devops инженеров?”

Твит недели номер раз – DALLE2 + Kermit The Frog в разных фильмах (возможности этой штуки поражают, скоро производство контента станет настолько дешевым, что его количество превысит скорость потребления)

Твит недели номер два – If you feel Stuck, Read this.

Хорошей недели ❤️‍🔥
Топ 3: разбор 20-ти архитектур алгоритмов рекомендации, как оценивают уровень разработчиков и как померить перфоманс React приложения.

1. System Design And Recommendation Algorithm Of 20 Big Companies 🔥

TL;DR: Разбор архитектуры алгоритма рекомендации в 20 крупных компаний как Google, YouTube, Netflix, Spotify и других.

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

2. Engineering Levels at Honeycomb: Avoiding the Scope Trap

TL;DR: Как оценивают уровень разработчиков в Honeycomb.

В Honeycomb есть семь уровней разработчиков: H1 Intern, H2 Entry, H3 Engineer, H4 Engineer, H5 Senior, H6 Staff и H7 Principle.

И они оценивают только два критерия, чтобы понять, на каком уровне находится человек:

1. Scope – масштаб выполняемых задач (tasks → features → projects → products → company)

2. Ownership – уровень ответственности (execution → process → solution discovery → problem discovery)

Как high level способ разделения разработчиков на уровни выглядит интересно.

3. Get Fast, Stay Fast: How To Monitor React Render Performance

TL;DR: Как померить перфоманс React приложения.

В статье много полезных снипетов и инструментов по типу afterframe, а также расписано, как мониторить перфоманс с помощью Sentry. Ваня молодец!

Твит недели – это объяснение на пальцах, как инфляция влияет на бизнес, от одного из самых интересных аккаунтов в твиттере – 10-K.

И в конце давайте отпразднуем смерть IE11 и наконец-то поставим target: es2015 в tsconfig.

Хорошей недели ❤️‍🔥
Топ 3: StackOverflow опросил 70,000 разработчиков и они высказались о Angular, как работают индексы и транзакции в бд простыми словами и вымышленное интервью с философом Сенека.

1. 2022 Developer Survey

TL;DR: Ежегодный опрос 70,000 разработчиков от StackOverflow.

Из интересного:

- JavaScript самый популярный язык, TypeScript на 5-ом месте
- Rust самый обожаемый язык, TypeScript на 4-ом месте
- NodeJS самая популярная технология, React на 2-ом месте, Next на 11-ом
- Postgres самая обожаемая БД, MongoDB на 3-ем месте
- npm используется в два раза больше чем yarn
- VS Code используют 75% опрошенных, IntelliJ только 28%
- JIRA использует 50% опрошенных (🥲), Notion 20%, Clickup 6%
- Соотношение Loved vs. Dreaded у React – 68% vs 32%, у Vue – 63% vs 37% и у всеми “любимого” Angular – 21% vs 79%

Эх, Angular.

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

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

- Slack > Microsoft Teams
- Notion > Jira (на маленьких/средних проектах)
- React > Angular

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

2. Things You Should Know About Databases

TL;DR: Очень просто и понятно о том, как работают индексы и транзакции в базах данных.

3. Life Is Not Short

TL;DR: Вымышленное интервью с римским философом Seneca, основанное на его эссе "О краткости жизни"

Отличная книга. Отличное интервью. Гениальный формат.

“The part of life we really live is small. All the rest is not life, but merely time.”

Твит недели – это разница между healthy engineering teams vs unhealthy engineering teams.

Healthy это когда:

- Доверие и открытая коммуникация.
- Всем понятны цели и как их достигнуть.
- Мало конфликтов.

Я еще добавлю сюда чувство безопасности. Это когда каждый участник команды не боится высказывать свое мнение. Все же были на этих созвонах по 10+ человек, где всего говорят 2-3? Это из-за недостатка безопасности.

И напоследок, находка недели – Spotify для звуков природы – earth.fm

Хорошей недели ❤️‍🔥
Топ 3: какая проблема у DRY, как эффективно строить продукты и как UBER к успеху шел

1. Why DRY is the most over-rated programming principle

TL;DR: Как люди неправильно используют концепцию DRY, а потом не понимают, почему кодовая база такая сложная.

DRY – самая неправильно понятая концепция в мире. Если ее использовать как формулировку и выносить повторяющиеся строчки кода в отдельный файл, то через пару месяцев сложность проекта будет так велика, что онбординг новых людей будет занимать недели. Сроки выхода продукта будут переноситься. Писать в такой проект станет не в кайф и кто-то на мите скажет: “блин, нам бы отрефачить код как-нибудь”

Почему так?

Многие думают, что приложение – это строчки кода. Когда на самом деле приложение – это система.

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

Плохая абстракция это увеличение зацепления модулей системы.

Увеличение зацепления это усложнение кодовой базы.

Усложнение кодовой базы это долгая разработка, увеличение сроков выхода продукта и работа не в кайф.

“Окей, а что делать?”

Простой вариант – прочитать “Duplication is far cheaper than the wrong abstraction”, не создавать абстракций и дублировать код до той поры, пока вы не будете уверены, что создаваемая абстракция правильная, ласковая и эффективная.

Сложный вариант – понять зацепление и связанность, прочитать про баланс DRY и WET, взять самое лучшее из SOLID и GRASP, спроектировать пару ужасных проектов. А затем понять, что каждая из этих концепций была придумана разными людьми в разное время под разные проблемы, что истины в них нет, что все они всего лишь абстракции, которые пытаются описать одно и тоже под разным углом, но они никогда это не опишут потому что думают только в рамках программирования. На этом месте замедлиться, посмотреть вокруг, подышать, сварить кофе, понять, что ни одна область в мире не может существовать в отдельности от других и чтобы лучше понять свою надо изучать другие, и наконец, почитать про системы.

Любимая часть из статьи:

“We are talking about all kinds of fancy programming stuff to try to solve problems that only exist because we don't want to repeat the same 6 line snippet in a handful of different places because DRY tells us that's bad. What's happening, is our adherence to DRY is leading us down a garden path to building an unnecessarily complex application that could be written very simply.”

2. Operating Well: What I Learned at Stripe

TL;DR: Бывший Product Manager из Stripe рассказывает, как быть эффективным и эффективно строить продукты.

Что запомнилось:

- At a high level, there seem to be two ways to operate large systems. (1) Micro-manage everything (meh) (2) Build trust systems.

- Changing strategy feels like progress but it usually isn’t.

- Often, changing your frame will let you find a solution that solves a much larger problem or eliminates the problem altogether.

- Create psychological safety in a team to make it effective.

3. Uber broke laws, duped police and secretly lobbied governments, leak reveals

TL;DR: Как Travis Kalanick (founder Uber) к успеху шел.

Если хотите посмотреть на события из статьи вживую, то вам сюда – The Battle for Uber.

И в конце, что бывает если возвести в абсолют абсурда одну из популярных дилемм – neal.fun

Хорошей недели ❤️‍🔥
Топ 3: что будет с рынком техов в ближайшие годы, как Flo создал эффективную систему найма и одно интересное исследование.

1. Startup Markets, Summer 2022 Edition

TL;DR: Что будет с рынком техов в 2022-2023 году

• Оценка компаний упадет (”series B/Cs have dropped 30-70%”, “Series A valuations have dropped maybe 20-30% but likely should drop 50%+ from highs”)

• Скорость подъема раундов откинется на пару лет назад (”As money leaves the market fundraises are likely to slow from 2021's a company raising a new round every 6-9 months back to the historical norms of a company raising a round every 12-24 months”)

• Будут сокращения

• Будет больше поглощений и слияний

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

Кстати, статья заканчивается очень классной фразой – “It is still a great time to build.”

2. Flo Health’s path to the hiring strategy in engineering

TL;DR: Как Flo создал эффективную систему найма.

Из интересного:

• Они для каждой позиции унифицировали пайплайн найма

• Приставили менеджера к каждому пайплайну и дали ему метрики – улучшить time-to-hire и качество интервью

• Начали собирать фидбек в процессе найма с интервьюеров и кандидатов

Я думаю, второй и третий пункт и дал такой отличный результат.

Только представьте:

1. Вы даете человеку конкретную и очень грамотную цель – уменьшить время найма и при этом улучшить качество найма
2. Вы оцениваете и награждаете человека по достижению этой цели
3. Человек проводит кастдевы с каждым, кто задействован в процессе найма – инженеры, менеджеры и кандидаты
4. Человек итерируется на основе полученного фидбека и улучшает процесс

Как тут не создать эффективную систему найма.

3. Not interacting with people reduces cognitive function over time

TL;DR: Мало общения снижает когнитивные способности.

Исследование, где участвовало 32,000 человек, показало, что у тех, кто находился в социальной изоляции, снижался уровень когнитивных способностей, включая память и время реакции, а также становилось меньше серого вещества в некоторых областях мозга.

Даже интересно, насколько язык и общение сказались на нашей эволюции.

Твит недели – это небольшой разбор маркетинга Tesla. Илон говорит, что на маркетинг они тратят ровно ноль долларов, но это не совсем так.

Мем недели – вот это чудо, простите.

На этом все, хорошей вам недели ❤️‍🔥