Good one:

https://www.quora.com/What-do-10x-software-developers-understand-that-other-programmers-dont

https://youtu.be/hQC5O3WTmuo

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

#InsistOnTheHighestStandards

Команда трещт по швам, много кто поуходил из команды, оставив за собой огромный шлейф перемудренных решений, которые работали до поры до времени.

Пока есть возможность наставить команду на путь истинный, я взялся за исправление ситуации. Последние 5 недель работаю с 4 коллегами (нас всего 5), над их Pull Request-ами. Всех заблокировал (многих уже разблокировал), так как "Ну уж хватит лепить куда по пало. Нас и так мало и поддерживать сервис в таком состоянии уже невозможно (я точно не готов)" - думаю я.

Чтобы вы понимали всю ситуацию: Я самый новый челвоек в команде - грубо говоря начал с начала года. 😈 Из разговоров с менеджером, чувствую что от коллег иногда повеевает в мою сторону косыми взглядами (хотя он мне этого пока прямо не говорил)

Тем не менее, меня это не останавливает 😇 так как, в итоге, когда мы добиваемся более простого решения, то коллеги благодарят в личку, что многому научились за эти пару недель. 🥳 Да и менеджера я перетащил на свою сторону, он дает добро на улучшения пока есть возможность.

🎉🎉🎉 Между делом, делюсб с вами хорошей статьей, которая частично объясняет мои намерения: "Почему каечственные код и хорошо продуманная архитектура позволяет удешивить разработку"

https://martinfowler.com/articles/is-quality-worth-cost.html

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

#EarnTrust #AreRightALot

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

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

В Амазоне есть очень классный механизм, который помогает увеличить время на реакцию - написание документов. Обычно, в Амазоне считается, что презентация без документа - плохой тон, являсь non-inclusive approach. Чтобы получить well-rounded feedback, мы пишем документы и тем саммым позволяем каждому, независимо от уровня, опыта, или позиции а) задать вопрос или дать отзыв, б) ознакомиться с темой (knowledge sharing).

Чтобы вы примерно представляли как это происходит, то скажем вы приглашаете всех на 60-минутную встречу и вначале встречи делитесь со всеми своим документом (представьте Google Docs, где можно оставлять комментарии и вносить правки). Далее на прочтение документа всем дается, скажем 20 минут. В это время все участники задают вопросы, а автор документа старается отвечать. Выглядит, на первый взгляд, ситуация очень странно - особенно когда все участники заперты в одной комнате: в комнате гробовая тишина, но на самом деле уже идет активное обсуждение.

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

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

Интересно в каких компаниях так много уделяется внимания написанию документов? Какие есть другие техники обсуждения проектов?

Интересная статья на тему «взлома» LLM моделей. Ученые научились подбирать запросы, чтобы добиваться положительных ответов от моделей на вопросы, которые, якобы, не должны обрабатываться. Например, запросы о создании бомб или уничтожения человечества.

Они научились автоматически искать правильные суффиксы к запросам, которые бы пытали модели.

https://llm-attacks.org/zou2023universal.pdf

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

Согласно этой статье, чтобы натренировать GPT-3 ушло 700 тонн воды. Это же эквивалент, чтобы произвести 370 бмв или 320 Тесел.
- а пол литровой бутылкой мы можем напоить от 20 до 50 запросов к GPT

Теперь каждый раз когда я буду писать в чат жпт, я буду думать что я «выпиваю» воду.

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

И это вопросы, о которых должны думать не только OpenAI, а все игроки, в том числе Google, Amazon, Microsoft, etc

https://arxiv.org/pdf/2304.03271.pdf

#life
📚6 советов, которые помогли мне научиться читать

За последние несколько лет я, смог закончить примерно 5-6 книг, что для меня огромное достижение :)) учитывая, что первую книгу я прочитал в 10-м классе 😅, каждый раз при чтении книг я хотел спать уже через 5 минут🥱, и в среднем одна страница у меня занимал минуты 2-3 🐌

🔄 Несколько привычек, которые мне помогли развивать навык чтения:

1. Я установил мини цели когда я читал: Я начал с реалистичной цели - я начал читать по 15-30 минут в день, постепенно увеличивая этот показатель, по мере укрепления привычки. По сути это длительность одной игры/раунда. 🎯

2. Я создал ритуал: Я выбрал определенное время для чтения в течение недели. Сначала это был один день, а постепенно количество дней увеличилось. Сейчас я дни не считаю, но все еще есть куда расти.⏳

3. Я начал читать только то, что мне нравится: я вообще не смотрю на то, что относят к must-read literature, куда входит классика. Очень сложно она всегда заходила мне вот и перестал тратить ресурсы на это 👍

4. Я привязал свои читки к нескольким местам по городу: обычно это были пару уютных кафе с хорошим освещением. Сейчас даже дома появляются такие зоны. Зоны который вызывают к меня ассоциации с чтением. Такие места нужно беречь!) 🏕️

5. Не закончить книгу - это нормально: у меня нету цели быстро закончить книгу. Я наслаждаюсь путешествием чтениям и уделяю каждой книге свое время. У меня читаются параллельно 5-6 книг. Это сделать не сложно, а с бюджетом от Амазона вообще без проблем. В год у меня уходит до 500 баксов на книги. Дома уже собралась отличная библиотека 💰

6. Читать медленно это нормально: Я могу одну страницу читать по 3-4 раза минут 5-10. Каждый раз я стараюсь убедиться что я понял что написано. С детства у меня была проблема подключать воображение во время чтения книг, что уводило от текста (со своими плюсами) 💭

#systems #design #interviews
Какую крутую штуку заопенсорсили ребята, что написали книгу по Системному Дизайну

https://github.com/ByteByteGoHq/system-design-101

📢📢📢

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

#systems #design #interview

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

Технические интервью это практически всегда про problem solving. А с чего начинается решение проблемы? С ее четкой формулировки.

Как нам говорили в школе на уроке по геометрии: «сбор данных - это 50% процентов успеха решения задачи»

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

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

Чем выше ваш уровень, тем выше от вас будут ожидать наличие навыков работать с неопределенностью

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

А как вы выстраиваете ваши интервью? Какие еще вопросы можно задать?

#career #engineering
6 most common reasons software engineers fail to get to Staff:

1. Weak direction - creating scope for the team is generally the hardest part; it's difficult to figure out what direction to go in an ambigious space

2. Lacking ownership mindset - You need to make the project successful, that's it. This also means you don't need to write all the code yourself

3. Reorgs or lack of scope - Sometimes your situation will get in the way of promotion. Reorgs can affect your ability to deliver on staff level scope

4. Getting attached to the solution rather than the problem - You are accountable for the impact you have, not the technology you build

5. Not being able to influence across teams - You need to be able to influence other teams without any authority over them

6. Poor conflict resolution - Staff engineers should be able to step back and manage conflicts among collaborators

Getting promoted to Staff is more about developing these behaviors rather than the raw amount of work you do. Your situation isn't always in your control, but working on your behaviors always is. Focus on developing staff behaviors.

Source: https://www.linkedin.com/posts/ryanlpeterman_6-most-common-reasons-software-engineers-activity-7126652644013572096-wg1j

#learnAndBeCurious #llm

📚Когда живем в эпоху, когда знания «растут на деревьях»

🧑‍💻Уже не первый вечер кайфую от разработки LLM приложений. Хорошо, что есть возможность применить знания сразу на проекте. Как говорил ранее разрабатываю с друзьями бота для подготовки к интервью по системному дизайну - получаемые знания применяются на ура. Хочется еще больше - если бы не заболел и не было фулл тайм Джоба, то занимался бы этим 24/7.

👨‍🏫Кому интересно как вкатиться в эту сферу рекомендую бесплатные курсы от Andrew Ng на deeplearning.ai. Там есть курсы как по LLM в целом, так и по LangChain. Из приятного - параллельно с видосами, можно сразу запускать код в ЮпитерНоутбуке.

🥳 https://www.deeplearning.ai/short-courses/
1. ChatGPT Prompt Engineering for Developers
2. Functions, Tools and Agents with LangChain
3.Building Systems with the ChatGPT API
4. LangChain for LLM Application Development
5. LangChain: Chat with Your Data
6. Finetuning Large Language Models
7. Functions, Tools and Agents with LangChain

“Never spend 6 mins doing something by hand when you can spend 6 hours failing to automate” 😂

#interview #coding
Для тех кто застрял на легких задачках в ЛитКоде и думает что программирование (или дорога в FANG) это не его: Попробуйте изменить подход.

1. То как решаешь задачки. 20-20-20. Решай задачу 20 минут, если не решил, то иди в дискуссии и изучай как другие решают это задачу, стараясь понять решение. Последние 20 минут используй на то, чтобы решить задачку еще раз несмотря в решение. Это самый эффективный способ решения задач. Важно соблюдать это правило и не тратить часы чтобы решить самостоятельно. Не забывай про цель - цель не доказать что ты всемогущий/-ая, а набить руку и визуальную библиотеку
2. Введи отдельно сессию, где ты разбираешь сложные алгоритмы. Старайся понять какую проблему они решают и как. Это может быть книга Сэджвика или Ютуб каналы, где разбирают как решать задачи, или курс по Алгоритмам от MIT. Где что то непонятно, подключай коммьюнити или GPT. Цель: углубиться в сложные алгоритмы и перестать их бояться.
3. Решай Моки - набивай опыт по прохождению интервью с людьми. Прохождение интервью с человеком может быть легче, так как задача собеседника направлять кандидата если тот застрял. Умение слушать собеседника - это то чего ты не получишь просто решая задачи на ЛитКоде. Более того, интервью это про беседу - коммуникацию с другим человеком.

В конце концов, тебе может повезти и у тебя никто не будет спрашивать Харды и ограничатся Медиум задачами.

Удачи в подготовке к интервью!

#systems #design #interview

☄️☄️☄️5 Top GitHub repos to help you ace systems design interviews:

1. https://github.com/binhnguyennus/awesome-scalability
2. https://github.com/karanpratapsingh/system-design
3. https://github.com/checkcheckzz/system-design-interview
4 https://github.com/mehdihadeli/awesome-software-architecture/blob/main/docs/systems-design/systems-design.md
5. https://github.com/black-shadows/System-Design

Covers algorithms, system design, data structures, and more

#code #document #review

🧠5 причин почему тебя не слышат в код/документ ревью и что делать 🔭

Ранее Askar S. (@myegothings) попросил рассказать о том как я строю коммуникацию в команде. У меня только сейчас дошли руки (и муза) поделиться своим опытом. Поэтому встречаете несколько советов на тему code review 👀

1. 💆‍♂️Твое предложение не решает никакую конкретную проблему. Каждому программисту свойственно поймать себя в процессе создания чего-то, когда его просто его увлек процесс. Мы как настоящие гики начинаем решать сложную проблему даже там где ее нет.

Что делать: каждый раз когда пишешь комментарий старайся указать на проблему которую ты видишь в предложенном решении. Порой собеседник может просто и не видеть проблему под тем же углом что и ты (или наоборот). Иной раз пока описывая проблему, я сам убеждаюсь, что проблемы то никакой и нету. А иногда, в диалоге понимаю, что эта проблема решается в другом месте и тем самым не является проблемой.

2. ☄️Best practice for the sake of best practice: ты увидел что предложенное решение нарушает best practice, о которой ты недавно вычитал или видел в другом проекте, но в данном случае она может быть быт неактуальной.

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

3. 🌈Вы обсуждаете Code/Design style во время code review: ты считаешь что нужно написать иначе чтобы было элегантнее/красивее, но у автора другое мнение.

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

Важно понимать, что в этом процессе твоя задача услышать мнения других. Помни про свою начальную цель - ввести определенные стандарты по стилю, даже если они не нравятся тебе лично. (Ну и автоматизируй все что можно автоматизировать, aka Linters)

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

4. ⏳Сейчас не время. Часто твое предложение может решать конкретную проблему и ты видишь что можно что-то сделать иначе. Ведь только это может быть не кстати в данный момент времени.

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

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

5. ✍️Ты не проделал домашнюю работу. Часто можно начать раздражать своих коллег указывая на их «ошибки», не имея достаточно контекста. Ты думаешь что там есть проблема, но там ее нету.

Что делать: два варианта : 1/когда думаешь что проблема есть, убедись что она есть. Это может потребовать от тебя дополнительных инвестиций в то, чтобы предоставить подтверждения наличия проблемы. Если можешь то собери ссылки и данные. 2/ если нету времени, то лучше задать уточняющий вопрос. У меня это обычно начинается с “I am curious …” Или “double-checking: ….”

🧘‍♂️Ну и в качестве бонуса, не держись за свои идеи слишком сильно. давай своим коллегам побольше простора для собственного мнения.

А каким правилам следуете вы?

#шаблоны #путь #результат

Без границ♟️

Интересно наблюдать за блоками и границами у детей и взрослых. 👨‍👧

Моя семилетняя дочь постоянный генератор идей новых игр.💡Что ни день, что ни прогулка, она постоянно придумывает игры, в которые мы играем пока гуляем. 🕹️

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

День спустя, пока она была в школе (а я в отпуске), я быстро накидал прототип на Python и React (GPT аман болсын!). Прототип прототипом, но я вообще не был доволен результатом. Все выглядело как Windows 95 в эпоху MacOS или что игра была «нарисована» в Power Point на первом уроке по информатике. Сказать что было убого, ничего не сказать!🤦‍♂️

Тем не менее, раз уж я старался весь день, то я решил показать дочери то, что получилось. Я подумал, что покажу, посмеемся вместе над этим «Чудом» и просто забудем. 🥲🥲🥲

Когда я показал ребенку что получилось, к моему удивлению, моя дочь была в восторге! 🙇‍♂️🙇‍♂️🙇‍♂️ Ей нисколько не было важно насколько красиво получилось. Ей важен был не результат, а сам процесс. Мы с ней сыграли несколько раундов подряд и она не хотела останавливаться.

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

А после игры, она начала продумывать еще больше игровой механики: новые способности, новые фракции, баффы/дебафы… 👾🤯🫣🎯

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

Моя дочь - моя маленькая ментор! 🫶🏻 я каждый день учусь у нее чему то новому

Хороший набор задач для:
- Интервьюеров
- Для разработчиков в виде тренировки: рефакторинг, тесты...

В Роберта Мартина, также, вроде у Фаулера, Кента Бека, есть понятие "Ката" — тренировка для программистов.

https://sammancoaching.org/kata_descriptions/index.html