♦️Любите играть в покер? Играйте в покер на работе!

Да-да, я не шучу. Ведь лучшим инструментом для оценки задач является покер-планирование.

Как вы наверное знаете, мне очень нравится тема Agile. Я уже писал про концепцию Agile в целом, выступал в Школе 21 про Agile и писал о книге про Agile.

Но не рассказывал о том, как оцениваются задачи при работе по гибким методологиям (agile-разработка).

В чём суть метода покер-планирования?
🟡Все участники команды разработки должны оценить задачу в условных единицах.
🟡Если до этого вы ничего не оценивали, то возьмите уже готовую задачу (или первую задачу в спринте) и оцените её в 5 стори-поинтов.
🟡Новую задачу оцените относительно той оценённой.
🟡🔘Она сложнее? 🔜 поставьте оценку выше.
🟡🔘Она проще? 🔜 поставьте оценку ниже.
🟡Кто то проголосовал за задачу больше или меньше чем другие? Пусть расскажет почему он так решил и переголосуйте!

Отмечу особенности оценки задач:
🟢 В работу необходимо взять как можно больше задач, но нам нужно понимать, сколько реально мы успеем сделать. Для этого мы смотрим на velocity и capacity (скорость и объем).
🟢 Среднее количество стори поинтов решённых задач в прошлых спринтах это наша скорость (velocity). А объём (capacity) состоит из количества разработчиков и дней в спринте. Если вы решили задач на 100 стори-поинтов, но половина разработчиков ушла в отпуск, то ваш capacity теперь 50.
🟢 Оценивать задачу нужно в абстрактных величинах в сравнении с другими задачами. Используйте оценку в 1, 3, 5, 8, 13 и 20 стори поинтов.

🌟 А вы используете покер-планирование в работе?

🍰 #it #просто_о_сложном

🔠🔠🔠🔠🔠🔠🔠

Чувствуете это...? Октябрь, за окном холодает, но в Чашке кода всегда тепло и уютно ☕️

Согрейтесь горячими постами за сентябрь:

〰️Почему новичкам платят больше? Узнать
〰️Язык С падает в рейтинге! Что будет дальше?
〰️Чем капибара занимается у себя на работе? Улыбнуться
〰️Рассказываю, что такое покер-планирование. Читать

Наверное вы заметили, что в сентябре было не очень много постов. Я целых 14 дней был в отпуске, и кстати, получил несколько интересных инсайтов. А какие - расскажу в будущих постах... 🔜

🍰 #it #коджест

Стартап без роста 🔤🔤 крупная компания с возможностью роста?

Ответ прост: идите работать туда, где вы бы хотели работать!

🚀 Рост в компании - обычно лишь уловка HR и корпоративной культуры. На самом деле, гарантировать его вам никто не может. Всегда лучше считать, что роста не будет. Скорее всего повышение по должности и хорошую премию получит ваш начальник, а не вы.

🤑 Так же стоит относиться и к премиям, и к бесплатному фитнесу и другим "плюшкам". Меня скорее они будут настораживать: если они есть в компании, то возможно это означает, что там никто не хочет работать, и компании приходиться как-то удерживать, мотивировать старых сотрудников и привлекать новых.

Если вам было бы интересно работать в этой команде / компании и без всех бонусов, то однозначно вам стоит там работать! Если вам нужны бонусы, то и работать вы, вероятно, будете ради них, а это прямой путь к выгоранию 🫠

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

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

А на какой стороне вы: стартап или корпорация? ⬇️

🍰 #it #мысли

🧑‍🍳 Рецепт резюме, с котором вы сразу получите приглашения на собеседования

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

1️⃣ Ответьте на эти вопросы в своём резюме:

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

2️⃣ Напишите резюме, где будет отражен тот опыт, которого вы хотите добиться за два года. С таким резюме вы сразу получите приглашения на собеседования. Конечно, пройти само собеседование вы не сможете, но поймёте, каких знаний и навыков вам не хватает, чтобы достичь уровня, к которому вы стремитесь.

3️⃣ Такое тестовое собеседование вы можете пройти со мной, для этого пишите в личку. Хотите пройти бесплатно - кидайте резюме в комментарии, и если мне будет интересно пообщаться с вами, напишу сам!

💋 Такой же подход работает и когда у вас есть опыт. Допустим, вы хотите сменить работу, потому что сейчас у вас много DevOps задач, а вы мечтали обучать нейронки. На собеседовании вы будете рассказывать о том, что вы делаете на текущей работе. В итоге вы найдёте точно такую же работу. Говорите о том, чем бы вы хотели заниматься и подкрепляйте это реальными фактами с текущей работы.

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

🍰 #it #it_советы

📌 Spark или Pandas?

Представим, что нам нужно найти количество раз, сколько слово встречается в тексте. Стандартный подход на Python будет такой:
💋 Открываем файл
💋 Читаем строки
💋 Если в строке нашли слово, то увеличиваем счётчик

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

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

При использовании Spark, мы:
1️⃣ Создаём драйвер — приложение для координации работы и взаимодействия с кластерами.
2️⃣ Пишем инструкцию на получение данных. Поскольку Spark рассчитан на большие объёмы данных, которые не будут храниться локально, он может работать с HDFS, S3 и многими другими системами хранения данных.
3️⃣ После инструкции на получение данных мы описываем действия, что с этими нужно с данными сделать.
4️⃣ Мы можем запросить результаты, и в этот момент начнётся обработка действий. Spark разделит данные на партиции и распределит вычисления на разных кластерах.

Мы получим результат вычислений значительно быстрее обычного скрипта на Python.

🖌 Действия в Spark описываются SQL-подобным синтаксисом, прям как в Pandas. Pandas используется также, как и Spark, но не предоставляет распределения вычислений по кластерам.

Если вам интересно поработать с большими данными и изучить Spark, то стоит начать с Pandas. Вот введение в Pandas на литкоде и 30 дневный план изучения. Второй я сам прошёл без подготовки, так что могу порекомендовать даже новичкам 🤓

🍰 #it #просто_о_сложном

〰️ 3️⃣ лучшие практики коммитов в GIT

Линус Торвальдс на днях сделал заявление:

Anyway, on a completely different note: I try to make my merge commit messages be somewhat "cohesive", and so I often edit the pull request language to match a more standard layout and language. It's not a big deal, and often it's literally just about whitespace so that we don't have fifteen different indentation models and bullet syntaxes. I generally do it as I read through the text anyway, so it's not like it makes extra work for me.

But what *does* make extra work is when some maintainers use passive voice, and then I try to actively rewrite the explanation (or, admittedly, sometimes I just decide I don't care quite enough about trying to make the messages sound the same).

So I would ask maintainers to please use active voice, and preferably just imperative.

Put another way: I'd love it if people would avoid writing their descriptions as "In this pull request, the Xyzzy driver error handling was fixed to avoid a NULL pointer dereference".

Instead write it as "This fixes a NULL pointer dereference in .." or particularly if you just list bullet points, make the bullet point just be "Fix NULL pointer dereference in ..".

This is not a big deal, I realize. But I happened to try to rewrite a few of these cases the last week, and I think simple and to-the-point language is better. The imperative version of just "Fix X" is about as clear as it gets.

А если по-русски и кратко, то он обращается к разработчикам ядра Линукс и просит писать текст к изменениям более понятным языком. Показалось полезным, поэтому вот советы для хороших коммитов:

1. Пишите описание кратко, в формате продолжения фразы "Это изменение исправит ...", например "fix image description".

2. Делайте коммит только полноценных изменений. Не нужно коммитить половину работу или непротестированные изменения.

3. Следуйте одному формату во всех коммитах.

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

🍰 #it #просто_о_сложном

🔠🔠🔠: какую выбрать?

Если вы только изучаете SQL (супер-полезный пост тут), то вы точно задаётесь вопросом, какую систему для управления Базами Данных использовать. Скорее всего, вы выбираете из MySQL, PostrgeSQL и SQLite. Возможно вы смотрите на Oracle, ЯндексДБ или даже на Firebird.

〰️ А что-же стоит выбрать на самом деле? Ответ прост.

Вы можете выбрать любой инструмент, который решает вашу задачу. Особо разницы между ними нет, и скорее всего вы, как разработчик, будете использовать ORM. Если на работе вам придётся использовать другую БД, то опыт работы с любой другой будет вам только полезен. Главная проблема возникает в том случае, если вы выбираете непопулярную БД. тогда у вас точно спросят причину использования именно этой системы.

👁‍🗨 Как и в случае с другими инструментами, используйте популярные решения. Для этого читайте опросы и исследования рынка, как это делаю я (1, 2, 3, 4, 5). И самым популярным решением сейчас является PostgreSQL.

🍰 #it #мои_мысли

☠️ Проклятие знания

На днях я в очередной раз был в ГЭС-2 (и вам советую). Всё здание имеет общий, очень выразительный и аутентичный стиль, в котором сложно разобраться. В первый раз вы вряд ли поймёте, где находится столовая, гардероб и туалет (хотя в самом здании достаточно указателей, довольно понятная планировка и нет ничего лишнего).

Но посетив ГЭС-2 в третий или четвёртый раз вы будете легко ориентироваться и разметка будет выглядеть понятной и логичной. Почему так происходит?🤔

Есть такое конгитивное искажение — «проклятие знания».

Оно заключается в том, что более информированным людям сложно рассматривать какую-либо проблему с точки зрения менее информированных людей. Как и в случае с другими искажениями, мы даже часто не знаем о нём. "Проклятие знания" особенно сильно влияет на нас, когда мы делимся знаниями 🤓

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

☕️ Изучая новую тему - помните об этом. Зачастую новые знания не сложные, но из за того, что лектор столкнулся с этим искажением, вам будет ничего не понятно. Более того, коллеги лектора могут так же, как и сам лектор, воспринимать материал как очень понятный.

А вы сталкивались с таким «проклятием?» 🔽

🍰 #it #просто_о_сложном

💬 Почему решили сменить место работы?

Такой вопрос часто ставит соискателей в ступор. Разберёмся, как отвечать на него.

🔈 Для начала стоит понять, зачем этот вопрос задаётся. HR хочет понять, что вам не нравится на текущем месте работы. Ведь если такой же фактор будет на новом месте, то вряд ли вы долго проработаете. Важно, что этот фактор должен быть не только существенным, но и таким, что на него нельзя никак повлиять.

👎 В популярные ответы "не хватило роста в компании" или "нет развития" - я бы не поверил. Во-первых, вряд ли это так, во-вторых, вряд ли вы что-то делали для исправления этой ситуации. Дядя Боб отлично это дополняет своим высказыванием о том, что компания не обязана повышать ваш уровень как специалиста, это прежде всего ваша ответственность и инициатива!

➡️ Лучше всего ответить честно, но не надо говорить о том, что коллеги плохие и задачи не интересные. Подумайте, почему вы действительно хотите уволиться? Если считаете, что проблема не в вас, то подумайте ещё или перефразируйте ответ. Обязательно расскажите, что уже сообщили текущему руководству о поиске работы.

Примеры:

1. "При оформлении у нас были одни условия работы. В связи с реорганизацией компании они изменились и меня это не устраивает".

Объясните, что речь идёт, например, о обязательном посещении офиса. У нового работодателя, соответственно, это не должно быть обязательным условием работы. 🖥

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

Помните, что проблема скорее всего в вашем отношении и покажите, что вы над этим работаете. ⌛

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

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

🍰 #it #it_собесы

🥇 А вы получили медальки на литкоде в этом году? Делитесь в комментариях!

Хочу записать миникурс про решение алгоритмов, но не понятно, будет ли вам интересно. Напомню, что у меня есть сайт с самыми полезными заданиями из литкода, пост про решение алгоритмов и концепции алгоритмов: 1 и 2. 📌

🍰 #it #алгоритмы

👻 Страшные тайны ООП

Всем привет! Завтра, в московском кампусе Школы 21, я проведу лекцию "Страшные тайны ООП". Приглашаю всех!

Выступление будет состоять из двух частей:
➡️ Первая для тех, кто мало знаком с ООП: разберёмся что это такое и как его использовать. Будут даже примеры на языке C!
➡️ Во второй части мы посмотрим на проблемы, с которыми можно столкнуться, используя ООП. Или как говорит Бьёрн Страуструп, "как отстрелить себе ногу".

🎃В заметках к лекции у меня 5000 слов (!), так что это будет очень комплексное выступление с большим количеством информации. Рекомендую взять с собой блокнот и ручку.

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

Трансляция выступления будет тут

P.S: Кидайте свои любимые Хэллоуинские стикеры в комменты (я уже скинул)👇

🍰 #it #анонсы

При работе с Python мы часто используем переменные, с таким же названием, как и параметры. Вроде такого:

User(name=name, email=email)

✏️ Мы можем упростить код и написать так:

User(name, email)

👀 А как насчёт такого варианта?

User(email, name)

Такой вариант сохранит данные неверно! У пользователя в имени будет написана его почта и наоборот.

⚡️ В языке Rust используются лучшие возможности всех языков и придумываются всё новые упрощения. И в нём есть такое решение, которое позволяет не сохранять порядок, если название атрибута соответствует названию переменной. Компилятор сам сопоставит нужные параметры и вы можете быть уверены, что три этих варианта будут работать одинаково:

User(name: name, email: email);
User(name, email);
User(email, name);

Я спросил у знакомых, которые пишут на других языках и выяснил, что больше нигде нет такого решения. Интересно, разработчики Rust сами придумали его, или это из какого-то другого языка? Видели ли вы где-то ещё такой подход?🔽

🍰 #it #просто_о_сложном

📥 Пишите TODO в коде!

Совет может показаться странным, но на самом деле, это действительно полезная вещь. Когда я только начинал свой путь в IT, я считал, что наличие комментариев показывает, что код плохой. А если это ещё и комментарий TODO(нужно сделать) то это вообще нельзя допускать в продакшн. Кажется, что такие комментарии лишь показывают вашу несостоятельность как разработчика.

На самом деле, наличие комментариев, особенно TODO - признак хорошего подхода к разработке! Обязательно пишите такие комментарии, когда видите, что часть кода реализована плохо или имеет смысл её переписать. Это актуально, когда найденная проблема не связана с вашей текущей задачей.

Разрабатывая программы, нам всегда приходится выбирать: сделать быстро или качественно.

👨‍💻 Зачастую бизнесу нужно быстрое решение задачи, поэтому у вас может не быть времени для исправления проблемы. Но вы можете помочь себе и продукту тем, что отметите возможность улучшения. Если в будущем у вас будет время на рефакторинг, то вы сможете вернуться к этому коду и исправить то, что отметили.

Не написав TODO-шку ,вы забудете о проблеме уже через пару минут. Лучше иметь проблему и знать о ней, чем вообще не знать о её существовании.

А вы пишите TODO?⬇️

🍰 #it #it_мнение