Я принес. Как искать работу IT-менеджеру?

Я частенько смотрю и слушаю подкаст ITBizRadio. Недавно там один из участников вышел на рынок труда ИТ-менеджеров и рассказал о своем опыте. В целом интересно послушать не в формате общих обзоров каких-нибудь рекрутеров, а вот прям на практике, что и как человек делал, с чем столкнулся, как получилось.

Ребята сделали 2 выпуска. Я уже посмотрел полтора.
1. https://www.youtube.com/watch?v=a8KLQ6PCiik
2. https://www.youtube.com/watch?v=1nMIoVsi7uM

Я искал работу в виде тимлида/тимлида тимлидов/технического менеджера/деливери менеджера 2 года назад. Опыт в чем-то был похожий.

От старта до выхода на работу прошло примерно 3 месяца. Пообщался с 5–6 компаниями, прошел всякие разные пайплайны собеседований, других посмотрел, себя показал)

Потом общался на конференциях с другими тимлидами/менеджерами, они так же примерно тратили месяца 3, если искать придирчиво, не кидаться на абы что.

Проектов много, а команда одна

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

Команда — заказчик — продукт/проект — сосредоточенная работа
За последнее время ко мне пришло несколько людей, у которых команды имеют четкие границы ответственности и приоритеты. Вот кроссфункциональная команда, вот продукт / модуль / сервис, вот продакт, генерящий идеи, или вот основной заказчик, приносящий хотелки. Там неплохо приживается классический скрам с понятным скоупом, целями спринта, демкой в результате и такой вот методичной итеративной моделью.

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

Планирование
Про планирование я отдельно писал тут https://t.me/general_it_talks/760. Спойлер: заложить часть на плановую работу, часть – на саппорт, техдолг, возгорания и часть – на человеческий фактор (отпуска, болезни, ротация и прочее).

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

Выявление приоритетов
Заказчиков много, хотелок много, каждый считает, что ему надо ну прям обязательно. Это нормально. И точно так же нормально заколебывать всех вопросами, уточняющими НАСТОЯЩИЙ приоритет. Типа «что будет, если мы не успеем сделать эту задачу?», «что именно для вас блокируется от этой задачи?» и т. д. Тогда может оказаться, что блокер не такой уж и блокер, например.

ЛЮДИ
Написал капсом, потому что нужно прямо очень хорошо понимать своих соколов (кто узнал отсылку к «Кремниевой долине», ставьте молнию). Кто-то умеет забуриться в глубь сложной задачи, вынырнуть спустя неделю со всеми нужными решениями. Кому-то трудно долго вглубь, но вширь на все проекты – легко. Кто-то любит медитативно молотить огромные объемы монотонной работы.

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

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

Скрамбан
Я писал выше, что где-то скрам работает неплохо. Вот в случае, когда 1 команда и много разного замеса со всех сторон, я эмпирическим путем пришел к некоему мутанту скрама и канбана. Я разговаривал с рядом опытных менеджеров из разных компаний от мала до велика. Обычно люди приходят на своем опыте примерно к одному и тому же 🙂

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

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

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

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

#career #novice

Как проходить собеседования на программиста

Мы сняли «ультимативный гайд» на три часа про то, как пройти собеседования на программиста совместно с Антоном Назаровым. Это самая полная инструкция в русскоязычном интернете. Мы проходимся глубоко по всем темам:

0. Какая ситуация на рынке.
1. Шиза найма и следствия из неё.
2. Какие рыночные частушки про собеседования тебе рассказывают?
3. Как прикинуться «конвенциональным айтишником», таким корпоративным дурачком, которого хотят компании.
4. Как готовиться к собеседованиям.
5. Какие роли есть при собеседовании.
6. Как проходится каждая встреча: hr-скрининг, техническое интервью, system design, алгоритмическая секция и т. д.
7. Как торговаться за оффер.

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

Я обычно слушаю такие материалы, гуляя, и на скорости 2х. Чего и вам советую.

#python #courses

Лучший курс по Python 13: print

https://www.youtube.com/watch?v=9aQ-GVlC0nY

В рамках данного видео я рассказываю про:
- Файловые дескрипторы
- Буферизацию вывода
- Устройство TextIOWrapper, BufferedWrite, FileIO
- Зачем нам _pyio?
- Что такое syscall write
- Что происходит после вызова syscall на запись

Для лучшего закрепления материала я предлагаю вам поучаствовать в переписывании print на ASM. Внутри:

static long
sys_write_call(const char *msg, Py_ssize_t size)
{
    // TODO: allow to pass `fd` as `print(file=...)` does.
    long ret;
    asm volatile (
        // TODO: convert this ugly AT&T ASM into beautiful Intel one:
        "mov $1, %%rax\n"             // sys_write call number
        "mov $1, %%rdi\n"             // stdout=1 and stderr=2
        "mov %1, %%rsi\n"             // `msg` address
        "mov %2, %%rdx\n"             // `msg_len`
        "syscall\n"
        "mov %%rax, %0\n"             // save the result
        : "=r"(ret)
        : "r"(msg), "r"(size)         // inputs
        : "rax", "rdi", "rsi", "rdx"  // changed registers
    );

    // TODO: maybe handle special cases like `EINTR`
    return ret;
}

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

Данная задача реально поможет разобраться с print в CPython на самом низком уровне. Мне было очень интересно! Надеюсь, и вам будет.

Ах да, совсем забыл: print в Python2 был ключевым словом, а не функцией. Нам приходилось писать так:

print 'Hello, world!'

Тут print - ключевое слово, а 'Hello, world!' – объект класса bytes.
Еще писали так:

print(1, 2)

Где print - все еще ключевое слово, а (1, 2) - tuple.
И вот так:

from __future__ import print_function

print(1, 2)

Тогда компилятор уже начинал использовать print как функцию. Ужас!

Если вам было полезно и интересно, не забывайте поддерживать:
- Поделиться с коллегами
- Закинуть на бусти: https://boosty.to/sobolevn

| Поддержать | YouTube | GitHub | Чат |

Памятка о цвете в датавизе

Привет! Я собрала небольшую шпаргалку о цвете в визуализации данных ⬇️

Картинка к посту взята из книги The Big Book of Dashboards

☝️У цвета есть две функции: кодировать информацию и акцентировать внимание.

Есть 3 типа палитр: последовательная, расходящаяся и категориальная.

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

2️⃣ Расходящаяся (diverging).
Используем для метрик, где надо показать переход через точку. Чаще всего это 0, но может быть медиана или другая важная отметка, например, прожиточный минимум. Центральное значение обычно присваивается светлому цвету, а чем дальше от центра, тем темнее.

3️⃣ Категориальная (categorical).
Используется для обозначения категорий (измерений), чтобы их выделить и разграничить. Это могут быть, например, города, страны, виды бытовой техники и т.п. Чем больше цветов, тем сложнее их сопоставлять. Рекомендуется использовать не более 5-6 цветов.

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

Цвета должны помогать понять то, что происходит на графике.

Для этого:

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

✔️ Цвета должны быть выбраны логично.
Для этого важно соблюдать порядок: например, светофорные цвета для шкалы «хорошо/плохо» или наращивание потемнения с увеличением значения.

✔️ Цвета должны учитывать культурные и другие паттерны восприятия и опираться на понятные и знакомые образы.
Например, можно использовать цвета логотипов при визуализации брендов как категорий.

🎨 Как подобрать цвета?
• взять готовую палитру
• подсмотреть в других датавиз-проектах, картинах или фотографиях и переиспользовать код цвета с помощью функции «пипетка» в графических редакторах.

Сайты по работе с цветами:

🔹 Сolor designer.io
Можно подобрать оттенки, связать гармоничные варианты по цветовому кругу, есть подборки готовых палитр.

🔹 Learnui.design/tools/data-color-picker
Выбираем цвет, получаем нужное количество оттенков. Можно выбрать степень яркости и интенсивности цвета.

🔹Colorscheme
Простой инструмент для подбора цветов и генерации цветовых схем.

🔹Adobe Color CC
Инструмент позволяет не только создавать свои собственные палитры, но и смотреть, что сделали другие. Можно выбирать цвет с цветового круга или прямо с изображения и применять разные правила для генерации палитры.

🔹Nightpalette
Сервис подбирает цвета для темной темы.

🔹Oddcontrast
Удобный сервис для подбора цвета и проверки контраста.

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

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

❓А вы много времени тратите на подбор цветов для дашборда?

#цвет #дашборд #подборка

Практически каждый проект в инжиниринге данных начинается с package manager (пакетный менеджер), как правило для Python.

С одной стороны у всех цель одна, а с другой стороны “кто в лес, кто по дрова”.

Мне попались 3 хорошие статьи от Dagster на эту тему (про сам Dagster там нет), в которых хорошо рассказывают как это работает и как сделать удобно и красиво.

Python Packages: a Primer for Data People (part 1 of 2)
Python Packages: a Primer for Data People (part 2 of 2)
Best Practices in Structuring Python Projects

Вообще там 11 частей, в каждом посте будут ссылки на все части, например есть и другие полезные:
High-performance Python for Data Engineering
Write-Audit-Publish in data pipelines
Breaking Packages in Python
CI/CD and Data Pipeline Automation (with Git)
Factory Patterns in Python
Type Hinting in Python
Environment Variables in Python

Если вы еще на “вы” со всеми этими менеджерами, зависимостями или не очень понимаете, что творится у вас на работе в репозитории, то будет полезно ознакомиться.

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

▫️Замечательный своей концептуальностью доклад Александра Поломодова “Архитектура в Т-Банке: вчера, сегодня, завтра”
▫️И очень практический доклад Виталия Минко “Архитектурные практики на практике”

#youtube

"All you need is Postgres" – наверняка слышали этот боевой клич

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

Репозиторий оказалася очень залипательным, можно походить по ссылочкам, узнать какие штуки бывают. Так, например, узнал про PGlite — Postgres in WASM. Просто берёшь и запускаешь базу прямо в браузере. Без всяких линуксовых виртуальных машин. Ну очень интересно!

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

#database

#llm #code

отличный туториал, как написать LLaMa 3 c нуля по шагам: https://github.com/naklecha/llama3-from-scratch

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

#dl #nlp #petproject

https://github.com/oobabooga/text-generation-webui/blob/main/requirements.txt

Например в этом файле вы можете увидеть собранные им под определенное окружение вилсы.
Самый простой и грубый способ.