"Бурлаки на проде" (с) Антон Грушкин - Frontend Developer at Mad Devs

Эта история о том, как невинно брошенная фраза превращается в мем

🤘 "Mad Devs" ищет Frontend developer (React) в финтех проект, который мы разрабатываем для одного из стартапов в США.

⚙️ Что нужно будет делать:
- Разрабатывать новую архитектуру проекта;
- Покрывать код юнит и интеграционными тестами;
- Рефакторить код в legacy-проекте;
- Ревьюить работы и MR-ы других участников команды;
- Вести задачи в JIRA;
- Писать техническую документацию по продукту.

✅ Ожидаем от кандидата:
- Знание и владение нативным JS;
- Знание и умение применять адаптивную верстку;
- Отличное владение фреймвора React.

🔴 Откликнуться на вакансию
👉 Посмотреть открытые вакансии

Новый #Кибирд уже на канале! 🔥
⠀
В этом выпуске Александр Едакин (Middle Backend Developer) и Андрей "Чак" Минкин (Teamlead, CTO, co-founder Mad Devs) поговорят о тимлиде: кто это, чем занимается и какие у него цели. Приятного просмотра! 😎
⠀
Смотреть и лайкать тут: https://youtu.be/M-H1W96on9s

Тем временем в Mad Devs родился новый мем 🤘

#чтопочитать

Одобрено для прочтения нашим фронтенд разработчиком Романом.

В топе технических книг серия книг Боба Мартина - Чистый код, Чистая Архитектура, Идеальный программист. Это Must read для любого разработчика. В данный момент Роман активно читает эти книги и подчеркивает невероятное количество знаний для улучшения кода и архитектуры приложений.

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

Конечно же, You Don't Know JS. Это серия книг для углубленного изучения и понимания JavaScript. Must Read для всех, кто тесно работает с JS и хочет понимать, что творится под капотом самого беззаботного языка в мире. В нескольких небольших книгах раскрываются все тонкости Javascript.

Jira hero 🦸‍♂️

🤘 "Mad Devs" ищет Golang developer в финтех проект.

Мы рассматриваем кандидата на полную занятость и удаленную работу.

⚙️ Что нужно будет делать:
- Разрабатывать новую архитектуру проекта;
- Покрывать код юнит и интеграционными тестами;
- Рефакторить код в legacy-проекте;
- Ревьюить работы и MR-ы других участников команды;
- Вести задачи в JIRA;
- Писать техническую документацию по продукту.

✅ Ожидаем от кандидата:
- 1,5+ лет опыта в разработке и поддержке коммерческих продуктов вышедших в Production на Go;
- Опыт в разработке и поддержке HTTP API включая подготовку и создание Swagger документации;
- Хорошее знание SQL, а также работа с PostgreSQL в Go;
- Опыт написания миграций в Golang;
- Опыт в использовании Docker и применения Docker-Compose;
- Английский не ниже Intermediate.

🔴 Откликнуться на вакансию
👉 Посмотреть открытые вакансии

Немного мотивации вам в ленту! 💪

Полный выпуск Кибирд "Тупняки джунов" доступен по ссылке: https://youtu.be/xzOrS7lg-iE

Всем привет! Мы начинаем серию постов #СоветыНачинающимЛидам
Это авторская колонка Чака (Андрея Минкина) и команды СТО, с которыми мы вас познакомим позже.

Но для начала, давайте разберемся, кто такой тимлид и с чем его едят?

Тимлида не едят, ведь обычно ест он. Хотя и его едят тоже, но на самом деле там всё непонятно. 🙂

Начнём с того, что тимлид - это два слова. Team - команда и Lead - лидер.

Есть техлид, есть тимлид. Не путать! Разница между ними простая. Тимлид - это про команду. Техлид - про технические решения. Один уходит вглубь технологий, а другой уходит в people management.

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

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

Производительность команды - это основной фактор, который характеризует команду.

Поэтому мы делаем все возможное, чтобы производительность команды Mad Devs была на оптимальном уровне:

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

А что же дает такая команда клиенту и компании? 🧐 Если все организовано правильно, стейкхолдеры могут рассчитывать на значительное повышение прибыли с каждого проекта (статистика говорит, что прибыль может вырасти на прибл. 60%) и максимальную отдачу команды.

#СоветыНачинающимЛидам

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

Чем тимлиду придется заниматься:
- Ревьюить код и отвечать за техническую часть проекта;
- Работать с командой - сплочать и вести;
- Нанимать и увольнять людей;
- Коммуницировать, ставить цели, отвечать за развитие человека внутри проекта и в масштабах компании;
- Решать конфликты, искать пути достижения консенсуса и идти на трейдоффы с бизнесом или внутри команды;
- Ставить задачи и делегировать;
- Отстаивать интересы команды перед бизнесом, балансируя между хотелками и техническим долгом;
- Контролировать команду, собирать обратную связь, убирать блокеры во взаимодействии команды;
- Вести переговоры.

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

Новый #Кибирд в здании 🤘

В этом выпуске в рубрике «Тимлид и джун: Ответы на вопросы» Чак (Teamlead, CTO, co-founder Mad Devs) и Руслан (Junior Go Developer) отвечают на самые интересные вопросы наших подписчиков: Идеальный джун — это какой?
Какими софт скиллами обладают топовые разработчики в Mad Devs? И как их развивать? - в общем выпуск 👍🏻 ! Go смотреть!

Смотреть и лайкать тут:
https://youtu.be/JFyui-vHsQs

🤘 "Mad Devs" ищет AQA инженера с опытом автоматизации тестирования для digital-банкинга в Казахстане.

⚙️ Что нужно будет делать:
- Автоматизация регрессионных тестов мобильных приложений (сначала Android, потом iOS);
- Покрытие автотестами интеграционного слоя системы.

✅ Наши ожидания:
- Знание типов и методологий тестирования;
- Опыт автоматизированного тестирования от 2 лет;
- Понимание жизненного цикла ПО;
- Опыт работы с инструментами тест-менеджмента и багтрекерами, втч. TestRail и Jira);
- Знание высокоуровневого языка программирования Java;
- Опыт автоматизации тестирования, знание различных инструментов для автоматизации, втч. TestNG;
- Опыт написания и поддержки актуальности тестовой документации: тест-кейсы, тест-планы, отчёты о тестировании;
- Умение работать с Jira, Git, Confluence;
- Опыт ручного тестирования мобильных приложений iOS и Android;
- Опыт тест-дизайна, тестирования требований;
- Опыт работы с Java/Selenium/Appium.

🔴 Откликнуться на вакансию
👉 Посмотреть открытые вакансии

#СоветыНачинающимЛидам
Цели Тимлида.

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

Основные цели тимлида:
1. Обеспечивать качество в своем проекте и следовать инженерным практикам. При этом качество может быть:
- Техническое;
- Бизнесовое;
- Персональный успех.
2. Команда не блокирует свою работу событиями как внутри, так и извне.
3. Нагружать команду равномерно задачами в рамках их компетенций.

Начнем с того, что разберем: Как тимлид следит за качеством и что такое техническое качество в принципе.

А ведь действительно? Мы все и всегда говорим за качество, но при этом слово настолько высокоуровневое, что каждый может понимать его по-своему. Со стороны целей мы описали три качества, которые могут быть, но это больше все-таки про пользу или велью. А как-то качество сформировать не получилось и поэтому, наш Тимлид Андрей "Чак" Минкин пустился в ресерч.

Что таки Чак наресерчил? В книжке Metrics and Models in Software Quality Engineering, Second Edition рассматривается качество с разных сторон и популярные мнения по поводу этого сводятся к тому, что качество может быть как-то обсуждено, но не может быть измерено или взвешено. Однако, со стороны инженерии, качество должно быть определено, измеримо, должно мониториться, управлятся и улучшаться.

В книге The Economics of Software Quality авторы попытались дать следующие определения для качества:
- Элегантность(Эргономичность) или красота в глазах смотрящего;
- Пригодность к использованию во многих целях;
- Удовлетворенность пользовательским требованиям, как явно, так и скрыто;
- Свобода от дефектов, возможно Six Sigma уровни;
- Высокая эффективность убирания дефектов;
- Высокая надежность при эксплуатации;
- Просто в изучении и просто в использовании;
- Чистота документации и пользовательских мануалов;
- Простота доступа к пользовательской поддержке;
- Быстрое устранение зарепорченных проблем.

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

Разработчик, хоть и протестирует свое творение, но он никогда не задастся целью сломать его. ☝️ А вот задача QA специалиста и заключается в том, чтобы найти, или создать то сочетание условий, при которых программа перестанет работать. Более того, у QA есть специальные тулы, которые он умело использует для того, чтобы сломать программу.

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

#СоветыНачинающимЛидам

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

То есть можно вносить изменения в предсказуемые сроки.

При этом, книга Metrics and Models in Software Quality Engineering, Second Edition говорит еще о важной роли кастомера, ссылаясь еще на одну книгу 70 года "Я знаю это, когда я вижу это" следующие вещи:

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

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

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

Новый #Кибирд уже на канале 🔥

Андрей "Чак" Минкин (Teamlead, CTO, co-founder Mad Devs) и Дмитрий Кононенко (Project Manager) поговорят на темы необходимости каждой из ролей, важности работе с людьми, а не только с кодом, сроками и скоупом.

Го смотреть: https://youtu.be/WzZ7SKuruAY

4 songs to code with... 🎷

Жениш - наш Backend Developer, часто слушает музыку во время написания кода. Жениш говорит, что именно эти композиции помогают ему настроиться на работу и создают "вайб программирования", ну что ж... давайте слушать!

🎶 Avicii, Jonas Blue, Kygo, Calvin Harris, Alok, Robin Schulz
🎶 twenty one pilots - Ride
🎶 twenty one pilots: Car Radio
🎶 3 PM Coding Session - Lofi Hip Hop Mix

#СоветыНачинающимЛидам

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

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

🤘 "Mad Devs" ищет Golang developer в финтех проект, который разрабатываем для одного из стартапов в США.

⚙️ Что нужно будет делать:
- Разрабатывать новую архитектуру проекта;
- Покрывать код юнит и интеграционными тестами;
- Рефакторить код в legacy-проекте;
- Ревьюить работы и MR-ы других участников команды;
- Вести задачи в JIRA;
- Писать техническую документацию по продукту.

✅ Наши ожидания:
- 1,5+ лет опыта в разработке и поддержке - коммерческих продуктов вышедших в Production на Go;
- Опыт в разработке и поддержке HTTP API включая подготовку и создание Swagger документации;
- Хорошее знание SQL, а также работа с PostgreSQL в Go;
- Опыт написания миграций в Golang;
- Опыт в использовании Docker и применения Docker-Compose;
- Английский не ниже Intermediate.

🔴 Откликнуться на вакансию
👉 Посмотреть открытые вакансии