Programmer’s Apprentice Season 2: Future Directions in AI-assisted Coding • Erik Meijer • YOW! 2023
Интересное выступление про будущее разработки, в котором Erik Meijer, Director of Engineering at Facebook, делает утверждение, что мы - последнее поколение, что будет писать код руками:) И это не печалит автора доклада, скорее он рад и вдохновлен этой возможностью. Для начала автор вспоминает про то, как развивались языки программирования и про 5th generation, а потом как он ушел в создание языков программирования, а в районе 2017 года на фоне развития neural networks перешел в AI (вовремя переобулся). Дальше он говорит про
- Non-monothonic logic (как ранний подход к AI)
- Virtuous cycle между железом и программным обеспечением (отсылка к закону Мура)
- Vicious cycle между бизнесом и программным обеспечением, где сложность бизнеса приводит к усложнению софта (что может съедать весь прирост от virtuous cycle). Для этого обычно разрабатываются software engineering tools. Но автор предлагает заменить software + software engineering tools на AI:)
- Дальше автор рассказывает про whitepaper 2021 года "AI in Software Engineering at Facebook", где он выступал в качестве соавтора. Где авторы говорили про: code search using natural language, но это не очень понравилось пользователям. Дальше автор говорит про code recommendations, automated bug fixes. Для 2021 года это была крутая статья, но в 2022 году с приходом к власти LLMs она мгновенно устарела и автор показывает как эти сценарии легко выполняются с chatGPT
- Дальше автор переходит к описанию того, как можно автоматизировать самих себя:
-- AI-powerd typing (copilot)
-- AI-powered search (chatGPT)
-- AI-powered "workflows" (autoGPT)
- И дальше Eric показывает как это может выглядеть для написания программ в виде взаимодействия агентов: testrun agent, bugfix agent, refactor agent. Плюс дальше идет prompt engineering
- Дальше автор иронизирует над фреймворком React для фронта, а дальше рассказывает про новый React, который приведен в whitepaper "ReAct: Synergizing Reasoning and Acting in Language Models" и дальше автор вспоминает свою whitepaper из 20 века "Client-side Web Scripting with HaskellScript"
- Ну и под конец автор рассказывает про видение LLM как noscripting client
- Финальным слайдом идет утверждение, что llm-based software is very powerful, but error-prone, brittle, insecure, hard to write, impossible to debug, expensive, privacy sensitive
- И это все стоит поправить для того, чтобы перейти в новый светлый мир (где код писать будут LLMs), а для этого надо еще будет поработать инженерам:)
#Management #Software #SoftwareDevelopment #LLM #AI #ML #Engineering #SystemEngineering #Architecture
Интересное выступление про будущее разработки, в котором Erik Meijer, Director of Engineering at Facebook, делает утверждение, что мы - последнее поколение, что будет писать код руками:) И это не печалит автора доклада, скорее он рад и вдохновлен этой возможностью. Для начала автор вспоминает про то, как развивались языки программирования и про 5th generation, а потом как он ушел в создание языков программирования, а в районе 2017 года на фоне развития neural networks перешел в AI (вовремя переобулся). Дальше он говорит про
- Non-monothonic logic (как ранний подход к AI)
- Virtuous cycle между железом и программным обеспечением (отсылка к закону Мура)
- Vicious cycle между бизнесом и программным обеспечением, где сложность бизнеса приводит к усложнению софта (что может съедать весь прирост от virtuous cycle). Для этого обычно разрабатываются software engineering tools. Но автор предлагает заменить software + software engineering tools на AI:)
- Дальше автор рассказывает про whitepaper 2021 года "AI in Software Engineering at Facebook", где он выступал в качестве соавтора. Где авторы говорили про: code search using natural language, но это не очень понравилось пользователям. Дальше автор говорит про code recommendations, automated bug fixes. Для 2021 года это была крутая статья, но в 2022 году с приходом к власти LLMs она мгновенно устарела и автор показывает как эти сценарии легко выполняются с chatGPT
- Дальше автор переходит к описанию того, как можно автоматизировать самих себя:
-- AI-powerd typing (copilot)
-- AI-powered search (chatGPT)
-- AI-powered "workflows" (autoGPT)
- И дальше Eric показывает как это может выглядеть для написания программ в виде взаимодействия агентов: testrun agent, bugfix agent, refactor agent. Плюс дальше идет prompt engineering
- Дальше автор иронизирует над фреймворком React для фронта, а дальше рассказывает про новый React, который приведен в whitepaper "ReAct: Synergizing Reasoning and Acting in Language Models" и дальше автор вспоминает свою whitepaper из 20 века "Client-side Web Scripting with HaskellScript"
- Ну и под конец автор рассказывает про видение LLM как noscripting client
- Финальным слайдом идет утверждение, что llm-based software is very powerful, but error-prone, brittle, insecure, hard to write, impossible to debug, expensive, privacy sensitive
- И это все стоит поправить для того, чтобы перейти в новый светлый мир (где код писать будут LLMs), а для этого надо еще будет поработать инженерам:)
#Management #Software #SoftwareDevelopment #LLM #AI #ML #Engineering #SystemEngineering #Architecture
YouTube
Programmer’s Apprentice Season 2: Future Directions in AI-assisted Coding • Erik Meijer • YOW! 2023
This presentation was recorded at YOW! Australia 2023. #GOTOcon #YOW
https://yowcon.com
Erik Meijer - Director of Engineering at Facebook; "Think Like A Fundamentalist, Code Like A Hacker"
ORIGINAL TALK TITLE
The Programmer’s Apprentice Season 2: Advancements…
https://yowcon.com
Erik Meijer - Director of Engineering at Facebook; "Think Like A Fundamentalist, Code Like A Hacker"
ORIGINAL TALK TITLE
The Programmer’s Apprentice Season 2: Advancements…
👍8🔥5❤3😁1
Java Weekend Offer @ Tinkoff
Мы в Тинькофф периодически проводим мероприятия, на которых устроиться на работу к нам можно за выходные. Очередное такое мероприятие пройдет в эти выходные (3-4 февраля) и 17-18 февраля. В рамках таких мероприятий обычно несколько команд приносят свои вакансии и преимущественно проводят интервью. В этот раз там есть ребята из моего юнита, что развивают Маркетинговую платформу. Эта платформа представляет из себя набор продуктов, с помощью которых мы связываемся с клиентами по множеству маркетинговых каналов. Каждый клиент банка — наш пользователь. Платформа работает по сценариям, которые создают контент-менеджеры. Она совершает более 100 млн действий ежедневно: рассылает пользователям пуш-уведомления и СМС, начисляет бонусы, запускает многоходовые маркетинговые акции и геймификацию.
Для того, чтобы дойти до фит-интервью с командами (и выбрать вакансию маркетинговой платформы) надо пройти 3 секции интервью
- Языковая секция, где будет обсуждаться платформа, фреймворки, с которыми вы работали, и теоретические вопросы, а также будет ревью кода
- Алгоритмы и структуры данных, где будет пара алгоритмических задач, чтобы оценить навык написания кода (эти навыки можно тренировать на leetcode, который и я использую, чтобы поддерживать себя в форме)
- System Design (для уровня senior), где надо будет спроектировать распределенную систему (вот мой пост про это интервью)
В общем, если вам интересно прийти работать к нам, то регистрируйтесь на лендинге и с вами свяжутся.
#SoftwareDevelopment #Software #Vacancy #Engineering
Мы в Тинькофф периодически проводим мероприятия, на которых устроиться на работу к нам можно за выходные. Очередное такое мероприятие пройдет в эти выходные (3-4 февраля) и 17-18 февраля. В рамках таких мероприятий обычно несколько команд приносят свои вакансии и преимущественно проводят интервью. В этот раз там есть ребята из моего юнита, что развивают Маркетинговую платформу. Эта платформа представляет из себя набор продуктов, с помощью которых мы связываемся с клиентами по множеству маркетинговых каналов. Каждый клиент банка — наш пользователь. Платформа работает по сценариям, которые создают контент-менеджеры. Она совершает более 100 млн действий ежедневно: рассылает пользователям пуш-уведомления и СМС, начисляет бонусы, запускает многоходовые маркетинговые акции и геймификацию.
Для того, чтобы дойти до фит-интервью с командами (и выбрать вакансию маркетинговой платформы) надо пройти 3 секции интервью
- Языковая секция, где будет обсуждаться платформа, фреймворки, с которыми вы работали, и теоретические вопросы, а также будет ревью кода
- Алгоритмы и структуры данных, где будет пара алгоритмических задач, чтобы оценить навык написания кода (эти навыки можно тренировать на leetcode, который и я использую, чтобы поддерживать себя в форме)
- System Design (для уровня senior), где надо будет спроектировать распределенную систему (вот мой пост про это интервью)
В общем, если вам интересно прийти работать к нам, то регистрируйтесь на лендинге и с вами свяжутся.
#SoftwareDevelopment #Software #Vacancy #Engineering
Т‑Банк Карьера
Познакомьтесь с Т-Банком
Собрали мероприятия, которые помогут узнать о нас больше и стать частью команды
❤5👍5🔥4💩1
Профсообщества в больших компаниях
Появилась запись встречи канала "безвотэтоговсего" про профессиональные сообщества в Росбанке, где я дискутировал на прошлой неделе. Во встрече помимо меня участвовали следующие замечательные люди:
- Сергей Щербинин, автор канала "безвотэтоговсего" и организатор встречи
- Паша Соломин, лидер разработки и сопровождения СБОЛ
- Саша Денисов, Директор департамента ит поддержки пользователей и клиентов цифровых сервисов Росбанка
- Макс Морозов, СЕО Астон
В дискуссии мы обсуждали много вопросов и вот несколько из них
- Как и зачем корпорации строят профсообщества и как они измеряют их эффективность?
- Как выстраивать лидеронезависимые сообщества?
- Как вовлекать в них людей, пробуждая интерес, а не выставляя ненужные KPI?
Если суммировать мою точку зрения на основе опыта Тинькофф, то у нас проффсообщества логично называются профессиями и выстроены примерно так
- У профессий есть свои лидеры, что исполняют эту роль, совмещая с участием в продуктах/проектах
- Професии являются точкой синхронизации людей, объединенных вокруг чего-то общего: профессии (продакт менеджер, системный аналитик, qa-инженер, разработчик), языка разработки в случае разработчиков(golang, kotlin/java/.net, etc), функции (архитектура, процессы разработки) и так далее
- У каждой профессии есть ее лидеры, которые ее развивают как во всей организации, так и внутри крупных подразделений
- Лидеры профессий помогают определять ожидания от специалистов, которые входят в определенную профессию - это так называемые матрицы компетенций
- Лидеры профессий участвуют в рассмотрении заявок на повышение, что идут через наш процесс Т-Рост, про который я рассказывал в своей статье
- Лидеры профессий помогают улучшать найм сотрудников в рамках своей профессии (это наши стримы найма, например я когда-то курировал и рассказывал про system design и troubleshooting)
- В рамках профессии вырабатываются стандарты и часто реализовывается общий инструментарий, который помогает всем в рамках профессии быть эффективным
- Также лидеры профессий часто ведут публичную деятельность по освещению своей профессии как внутри, так и снаружи компании (aka devrel)
Для меня концепция профессии звучит классно и позитивно, но возникает вопрос а почему не выделить это в отдельную должность?
Ответ в том, что при выделении сотрудников на fulltime мы получаем сломанную ситуацию, когда крутой представитель профессии постепенно теряет
- Экспертизу в ней, так как перестает работать руками
- Связь с землей и уходит в абстракции, так как перестает работать руками
В итоге, лидер профессии вынужден сидеть на двух стульях.
Но тогда возникает вопрос, а зачем ему это делать?
Ответ в том, что это улучшает карму сотрудника и повышает вероятность успешного повышения в рамках процесса Т-Рост, причем для высоких грейдов это становится необходимым, но недостаточным критерием:)
#Management #Leadership #Engineering #Staff #Software #Devrel
Появилась запись встречи канала "безвотэтоговсего" про профессиональные сообщества в Росбанке, где я дискутировал на прошлой неделе. Во встрече помимо меня участвовали следующие замечательные люди:
- Сергей Щербинин, автор канала "безвотэтоговсего" и организатор встречи
- Паша Соломин, лидер разработки и сопровождения СБОЛ
- Саша Денисов, Директор департамента ит поддержки пользователей и клиентов цифровых сервисов Росбанка
- Макс Морозов, СЕО Астон
В дискуссии мы обсуждали много вопросов и вот несколько из них
- Как и зачем корпорации строят профсообщества и как они измеряют их эффективность?
- Как выстраивать лидеронезависимые сообщества?
- Как вовлекать в них людей, пробуждая интерес, а не выставляя ненужные KPI?
Если суммировать мою точку зрения на основе опыта Тинькофф, то у нас проффсообщества логично называются профессиями и выстроены примерно так
- У профессий есть свои лидеры, что исполняют эту роль, совмещая с участием в продуктах/проектах
- Професии являются точкой синхронизации людей, объединенных вокруг чего-то общего: профессии (продакт менеджер, системный аналитик, qa-инженер, разработчик), языка разработки в случае разработчиков(golang, kotlin/java/.net, etc), функции (архитектура, процессы разработки) и так далее
- У каждой профессии есть ее лидеры, которые ее развивают как во всей организации, так и внутри крупных подразделений
- Лидеры профессий помогают определять ожидания от специалистов, которые входят в определенную профессию - это так называемые матрицы компетенций
- Лидеры профессий участвуют в рассмотрении заявок на повышение, что идут через наш процесс Т-Рост, про который я рассказывал в своей статье
- Лидеры профессий помогают улучшать найм сотрудников в рамках своей профессии (это наши стримы найма, например я когда-то курировал и рассказывал про system design и troubleshooting)
- В рамках профессии вырабатываются стандарты и часто реализовывается общий инструментарий, который помогает всем в рамках профессии быть эффективным
- Также лидеры профессий часто ведут публичную деятельность по освещению своей профессии как внутри, так и снаружи компании (aka devrel)
Для меня концепция профессии звучит классно и позитивно, но возникает вопрос а почему не выделить это в отдельную должность?
Ответ в том, что при выделении сотрудников на fulltime мы получаем сломанную ситуацию, когда крутой представитель профессии постепенно теряет
- Экспертизу в ней, так как перестает работать руками
- Связь с землей и уходит в абстракции, так как перестает работать руками
В итоге, лидер профессии вынужден сидеть на двух стульях.
Но тогда возникает вопрос, а зачем ему это делать?
Ответ в том, что это улучшает карму сотрудника и повышает вероятность успешного повышения в рамках процесса Т-Рост, причем для высоких грейдов это становится необходимым, но недостаточным критерием:)
#Management #Leadership #Engineering #Staff #Software #Devrel
YouTube
Оффлайн встреча №3 канала #безвотэтоговотвсего. Профсообщества в корпорациях
Запись прекрасной панельной дискуссии с нашей третьей оффлайн встречи, с нами были:
- Саша Поломодов, техдир Тинькофф
- Паша Соломин, лидер разработки и сопровождения СБОЛ
- Саша Денисов, Директор департамента ит поддержки пользователей и клиентов цифровых…
- Саша Поломодов, техдир Тинькофф
- Паша Соломин, лидер разработки и сопровождения СБОЛ
- Саша Денисов, Директор департамента ит поддержки пользователей и клиентов цифровых…
❤7🔥6👍3
Leetcode - прогресс за первый месяц
Я уже рассказывал как купил себе Premium подписку на LeetCode на день рождения (3 января ) и парочку курсов оттуда ("Data Structures and Algorithms" и "System Design for Interviews and Beyond"). А теперь пришло время отчитаться за этот месяц:
- Оказалось, что руки забыли примерно одинаково как писать на всех языках, поэтому я решил вспоминать Python для алгоритмических задач
- После того, как я вспомнил синтаксис python и чуток набил руку, то easy задачки я стал решать где-то за 5-10 минут, а вот задачки уровня medium идут у меня с переменным успехом (и пока они скорее побеждают)
- У нас в компании есть чатик любителей leetcode, которые решают Daily Challenge вместе и обсуждают задачки - я туда тоже записался, но отрешал только около половины ежедневных задачек
- Зато SQL у меня как будто не забывался - тут в среднем easy задачки идут за пару минут, medium обычно минут 5 и даже hard задачки решаются относительно просто (правда, сегодня ночью решал порядка часа последнюю hard задачку из набора "Advanced SQL 50")
В общем, leetcode пока мне нравится - я системно им занимаюсь каждый день утром как проснусь и вечером перед сном и кажется, что руки и голова потихоньку вспоминает про алгоритмы:) Теперь я могу не только про них рассказывать, но и даже что-то написать:) Ну и для иллюстрации добавлю скриншот с визуализацией из своего личного кабинета, по которому я оцениваю свой прогресс.
P.S.
Купленные курсы я пока не прошел (и даже особо не начинал), но планирую в феврале их заботать. Особенно интересно будет изучить system design курс.
#SelfDevelopment #Algorithm #Software #SoftwareDevelopment
Я уже рассказывал как купил себе Premium подписку на LeetCode на день рождения (3 января ) и парочку курсов оттуда ("Data Structures and Algorithms" и "System Design for Interviews and Beyond"). А теперь пришло время отчитаться за этот месяц:
- Оказалось, что руки забыли примерно одинаково как писать на всех языках, поэтому я решил вспоминать Python для алгоритмических задач
- После того, как я вспомнил синтаксис python и чуток набил руку, то easy задачки я стал решать где-то за 5-10 минут, а вот задачки уровня medium идут у меня с переменным успехом (и пока они скорее побеждают)
- У нас в компании есть чатик любителей leetcode, которые решают Daily Challenge вместе и обсуждают задачки - я туда тоже записался, но отрешал только около половины ежедневных задачек
- Зато SQL у меня как будто не забывался - тут в среднем easy задачки идут за пару минут, medium обычно минут 5 и даже hard задачки решаются относительно просто (правда, сегодня ночью решал порядка часа последнюю hard задачку из набора "Advanced SQL 50")
В общем, leetcode пока мне нравится - я системно им занимаюсь каждый день утром как проснусь и вечером перед сном и кажется, что руки и голова потихоньку вспоминает про алгоритмы:) Теперь я могу не только про них рассказывать, но и даже что-то написать:) Ну и для иллюстрации добавлю скриншот с визуализацией из своего личного кабинета, по которому я оцениваю свой прогресс.
P.S.
Купленные курсы я пока не прошел (и даже особо не начинал), но планирую в феврале их заботать. Особенно интересно будет изучить system design курс.
#SelfDevelopment #Algorithm #Software #SoftwareDevelopment
🔥49👍18❤7🤡2🥴2
Code of Leadership - Episode ? - Антихрупкость в IT от Саши Бындю
Я подумал, что в рамках моего подкаста было бы интересно не просто звать гостей и обсуждать их любимые книги. Круто иногда звать и самих авторов книг и обсуждать их творчество вместе с ними. Именно такую серию мы запишем с Сашей Бындю на следующей неделе по книге "Антихрупкость в IT". Договориться получилось достаточно легко
- Мы с Сашей уже были знакомы где-то с 2019 года, когда он выступал на ArchDays 2019 года с докладом про Inner source (я в ПК этой конференции с самого начала)
- Саша с большим интересом делится своим подходом к антихрупкости (он рассказывал про это на Codefest 2023)
- Я недавно прочитал его книгу и уже рассказл про нее раньше
- Когда я предложил Саше прийти в гости, то он легко согласился, а также написал небольшой ответ на мой обзор
- Когда мы обсуждали план на выпуск, то поняли, что интересно будет поговорить про "карты гипотез", продуктовый и проектный подход, работу в модели заказчик/исполнитель или внутри организации, архитектурные вопросы и так далее
В общем, думаю, что выпуск будет интересным и мы сможем круто погрузиться в мысли Саши, что он изложил в своих книгах.
#Management #Software #Architecture #Processes #Project #ProductManagement #Engineering #Processes #Consulting
Я подумал, что в рамках моего подкаста было бы интересно не просто звать гостей и обсуждать их любимые книги. Круто иногда звать и самих авторов книг и обсуждать их творчество вместе с ними. Именно такую серию мы запишем с Сашей Бындю на следующей неделе по книге "Антихрупкость в IT". Договориться получилось достаточно легко
- Мы с Сашей уже были знакомы где-то с 2019 года, когда он выступал на ArchDays 2019 года с докладом про Inner source (я в ПК этой конференции с самого начала)
- Саша с большим интересом делится своим подходом к антихрупкости (он рассказывал про это на Codefest 2023)
- Я недавно прочитал его книгу и уже рассказл про нее раньше
- Когда я предложил Саше прийти в гости, то он легко согласился, а также написал небольшой ответ на мой обзор
- Когда мы обсуждали план на выпуск, то поняли, что интересно будет поговорить про "карты гипотез", продуктовый и проектный подход, работу в модели заказчик/исполнитель или внутри организации, архитектурные вопросы и так далее
В общем, думаю, что выпуск будет интересным и мы сможем круто погрузиться в мысли Саши, что он изложил в своих книгах.
#Management #Software #Architecture #Processes #Project #ProductManagement #Engineering #Processes #Consulting
👍20🔥7❤4🤡2
Тренды геймификации - эфир South HUB
Меня достаточно часто зовут пообщаться и что-то пообсуждать. И я особенно люблю, когда я могу прийти не сам, а посоветовать кого-то более релевантного из моих коллег. И с этим эфиром на South Hub про геймификацию так и получилось - я порекомендовал позвать моего коллегу, Вадима Гончарова, который руководит разработкой игр и спецпроектов. Кстати, Вадим недавно на YaTalks рассказывал про то, как ребята делали игру "Ряд наград". Кстати, отдел Вадима теперь входит в управление разработки соцплатформ, про чью вакансию SRE лида я писал недавно.
В эфире будут участвовать
- Кирилл Буртный - СТО Х5 Tech, модератор дискуссии и январский соведущий канала South Hub.
- Вадим Гончаров, руководитель разработки спецпроектов и игр в Тинькофф.
- Антон Лямин, руководитель продукта опыта покупателей Авито.
- Олег Афанасьев, CPO RuStore | VK.
Обсуждать эти замечательные люди будут следующие вопросы
- Совместимы ли игры и большие корпорации?
- Что такое игровые механики, где сейчас их применяют и для чего?
- Какие выгоды они приносят при работе с клиентами и сотрудниками?
- Стоит ли вкладывать в геймификацию и к каким эффектам она приводит?
- Какое будущее у геймификации: чего хочет рынок?
#Software #GameDesign #Engineering
Меня достаточно часто зовут пообщаться и что-то пообсуждать. И я особенно люблю, когда я могу прийти не сам, а посоветовать кого-то более релевантного из моих коллег. И с этим эфиром на South Hub про геймификацию так и получилось - я порекомендовал позвать моего коллегу, Вадима Гончарова, который руководит разработкой игр и спецпроектов. Кстати, Вадим недавно на YaTalks рассказывал про то, как ребята делали игру "Ряд наград". Кстати, отдел Вадима теперь входит в управление разработки соцплатформ, про чью вакансию SRE лида я писал недавно.
В эфире будут участвовать
- Кирилл Буртный - СТО Х5 Tech, модератор дискуссии и январский соведущий канала South Hub.
- Вадим Гончаров, руководитель разработки спецпроектов и игр в Тинькофф.
- Антон Лямин, руководитель продукта опыта покупателей Авито.
- Олег Афанасьев, CPO RuStore | VK.
Обсуждать эти замечательные люди будут следующие вопросы
- Совместимы ли игры и большие корпорации?
- Что такое игровые механики, где сейчас их применяют и для чего?
- Какие выгоды они приносят при работе с клиентами и сотрудниками?
- Стоит ли вкладывать в геймификацию и к каким эффектам она приводит?
- Какое будущее у геймификации: чего хочет рынок?
#Software #GameDesign #Engineering
Telegram
South HUB
⏺ South HUB on Air: ждём на прямом эфире 1 февраля.
Тема: тренды геймификации.
19:00
🔘 Порассуждайте, совместимы ли игры и большие корпорации?
🔘 Узнайте, что такое игровые механики, где сейчас их применяют и для чего?
🔘 Выясните, какие выгоды они приносят…
Тема: тренды геймификации.
19:00
🔘 Порассуждайте, совместимы ли игры и большие корпорации?
🔘 Узнайте, что такое игровые механики, где сейчас их применяют и для чего?
🔘 Выясните, какие выгоды они приносят…
❤7👍7🔥3
GraphQL: The Documentary
Полтора года назад я посмотрел эту документалку в рамках изучения whitepaper "Continuous Deployment of Mobile Software at Fb (Showcase)", на которую я написал краткое саммари в своем блоге. Если кратко суммировать, то где-то до 2012 компания, что создала GraphQL шла в сторону веба в мобилке, но стало ясно, что HTML5 в мобиле тогда не работал. Дальше они решили переобуться на нативную разработку и стало ясно, что старые APIшки не очень помогают в разработке нативных приложений. Дальше вместо проектирования API ребята изобрели свой способ через выставление query language прямо в потребителей и назвали это GraphQL. Несмотря на мое отношение к GraphQL рекомендую глянуть эту документалку и понять откуда растут ноги у этого подхода.
Кстати, я уже рассказывал про другие документалки
- How A Small Team of Developers Created React at Facebook | React.js: The Documentary
- Ruby on Rails: The Documentary
- Inside Envoy: The Proxy for the Future [OFFICIAL FILM]
- eBPF Documentary: eBPF’s Creation Story – Unlocking The Kernel
- AlphaGo - The Movie
- Kubernetes: The Documentary
#Software #Documentary #Engineering #Architecture #Management #SoftwareDevelopment
Полтора года назад я посмотрел эту документалку в рамках изучения whitepaper "Continuous Deployment of Mobile Software at Fb (Showcase)", на которую я написал краткое саммари в своем блоге. Если кратко суммировать, то где-то до 2012 компания, что создала GraphQL шла в сторону веба в мобилке, но стало ясно, что HTML5 в мобиле тогда не работал. Дальше они решили переобуться на нативную разработку и стало ясно, что старые APIшки не очень помогают в разработке нативных приложений. Дальше вместо проектирования API ребята изобрели свой способ через выставление query language прямо в потребителей и назвали это GraphQL. Несмотря на мое отношение к GraphQL рекомендую глянуть эту документалку и понять откуда растут ноги у этого подхода.
Кстати, я уже рассказывал про другие документалки
- How A Small Team of Developers Created React at Facebook | React.js: The Documentary
- Ruby on Rails: The Documentary
- Inside Envoy: The Proxy for the Future [OFFICIAL FILM]
- eBPF Documentary: eBPF’s Creation Story – Unlocking The Kernel
- AlphaGo - The Movie
- Kubernetes: The Documentary
#Software #Documentary #Engineering #Architecture #Management #SoftwareDevelopment
YouTube
GraphQL: The Documentary
The GraphQL Documentary 🚀🚀🚀 Starring Lee Byron, Dan Schafer and Nick Schrock (co-creators of GraphQL) and other big names from the #GraphQL community, "GraphQL: The Documentary" explores the story of why and how GraphQL came to be and the impact it's having…
👍10🔥4❤3
Алгоритмы: построение и анализ (Introduction to Algorithms)
Я купил этот кирпич за авторством Кормена, Лейзерсона и Ривеста еще в 2002 году, когда думал, что смогу стать мастером в алгоритмах. Это было еще первое издание книги с белой обложкой и тогда соавторов было еще трое. Мне тогда нравилось изучать эту книгу, но на первых курсах университета у меня еще не было личного компьютера, поэтому приходилось писать псевдокод на листочке и дебажить в голове. Такая схема работы не слишком помогала в изучении computer science, но основы вроде бы я тогда уловил (заодно понял, что в этой области я звезд с неба не хватаю:) иначе бы и в голове мог все это отрешивать без компа).
А когда я на третьем курсе уже пошел работать, то времени и желания ботать дальше алгоритмы уже не было - я был занят изучением самих языков и инструментов, что помогали мне решать практические задачи из области веб разработки.
Прошло много лет и теперь можно вернуться к книге, а алгозадачи решать не в голове, а на leetcode:)
Структура книги достаточно логичная и состоит из следующих частей
1) Математические основы анализа алгоритмов - скорость роста функций (нотация O(n)), рекурентные соотношения, множества, комбинаторика и вероятность
2) Сортировка и порядковые статистики - сортировка с помощью кучи, quick sort, медианы и порядковые статистики
3) Структуры данных - стеки, очереди, связанные списки, хеш-таблицы, деревья
4) Методы построения и анализа алгоритмов - динамическое программирование, жадные алгоритмы
5) Более сложные структуры данных - b-tree, биномиальные кучи, фиобаначчиевы кучи, системы непересекающихся множеств
6) Алгоритмы на графах - поиск в ширину и глубину, минимальные покрывающие деревья, кратчайшие пути, максимальный поток
7) Дополнительные главы - матрицы, быстрое преобразование Фурье, NP-полнота и многое другое
В общем, фундаментальная книга с крутыми темами и устрашающими размерами:)
Кстати, а стоит заказывать четвертое издание книги, если у меня уже есть первое?
#Software #Algorithm #Engineering #SelfDevelopment
Я купил этот кирпич за авторством Кормена, Лейзерсона и Ривеста еще в 2002 году, когда думал, что смогу стать мастером в алгоритмах. Это было еще первое издание книги с белой обложкой и тогда соавторов было еще трое. Мне тогда нравилось изучать эту книгу, но на первых курсах университета у меня еще не было личного компьютера, поэтому приходилось писать псевдокод на листочке и дебажить в голове. Такая схема работы не слишком помогала в изучении computer science, но основы вроде бы я тогда уловил (заодно понял, что в этой области я звезд с неба не хватаю:) иначе бы и в голове мог все это отрешивать без компа).
А когда я на третьем курсе уже пошел работать, то времени и желания ботать дальше алгоритмы уже не было - я был занят изучением самих языков и инструментов, что помогали мне решать практические задачи из области веб разработки.
Прошло много лет и теперь можно вернуться к книге, а алгозадачи решать не в голове, а на leetcode:)
Структура книги достаточно логичная и состоит из следующих частей
1) Математические основы анализа алгоритмов - скорость роста функций (нотация O(n)), рекурентные соотношения, множества, комбинаторика и вероятность
2) Сортировка и порядковые статистики - сортировка с помощью кучи, quick sort, медианы и порядковые статистики
3) Структуры данных - стеки, очереди, связанные списки, хеш-таблицы, деревья
4) Методы построения и анализа алгоритмов - динамическое программирование, жадные алгоритмы
5) Более сложные структуры данных - b-tree, биномиальные кучи, фиобаначчиевы кучи, системы непересекающихся множеств
6) Алгоритмы на графах - поиск в ширину и глубину, минимальные покрывающие деревья, кратчайшие пути, максимальный поток
7) Дополнительные главы - матрицы, быстрое преобразование Фурье, NP-полнота и многое другое
В общем, фундаментальная книга с крутыми темами и устрашающими размерами:)
Кстати, а стоит заказывать четвертое издание книги, если у меня уже есть первое?
#Software #Algorithm #Engineering #SelfDevelopment
❤16👍10🔥1
Живая раскраска Смешарики. Развиваем интеллект
В этой книге от Devar авторы взяли мотивы фильма "Трон" 1982 года выпуска и перенесли их в мир Смешариков. В самом начале книги Кар-Карыч забыл пароль от свеого компьютера, но ему на помощь приходит Ежик. Ежик вводит пароль, а дальше его засасывает в компьютерную игру с кучей задачек в дополненной реальности. Детям предстоит помочь Ежику разгадать загадки, победить в логических играх и не только. Антураж меняется на каждой страничке - Смешарики то превращаются в пиратов, то в космонатов, то футболистов, то в ведьм и колдунов.
Я купил эту игру достаточно давно, но теперь моей трехлетний Кирюша с большим удовольствием решает эти задачки и играет в игрушки. Но вот раскрашивать Смешариков он не стал, поэтому все персонажи преимущественно черно-белые.
#ForKids #ForParents
В этой книге от Devar авторы взяли мотивы фильма "Трон" 1982 года выпуска и перенесли их в мир Смешариков. В самом начале книги Кар-Карыч забыл пароль от свеого компьютера, но ему на помощь приходит Ежик. Ежик вводит пароль, а дальше его засасывает в компьютерную игру с кучей задачек в дополненной реальности. Детям предстоит помочь Ежику разгадать загадки, победить в логических играх и не только. Антураж меняется на каждой страничке - Смешарики то превращаются в пиратов, то в космонатов, то футболистов, то в ведьм и колдунов.
Я купил эту игру достаточно давно, но теперь моей трехлетний Кирюша с большим удовольствием решает эти задачки и играет в игрушки. Но вот раскрашивать Смешариков он не стал, поэтому все персонажи преимущественно черно-белые.
#ForKids #ForParents
❤13👍10🔥2
The Most Powerful Software Development Process Is The Easiest • Dave Farley • GOTO 2024
Это короткое видео Дэйва Фарли посвящено дизайну идеального процесса разработки софта. Интересно, что сам Дейв - тертый калач, который в давние времена написал книгу Continuous Delivery (я про нее рассказывал), а недавно - "Modern Software Engineering: Doing What Works to Build Better Software Faster", которая стоит у меня на полке и ждет своего часа. В этом видео Дэйв предлагает отринуть текущие практики и попробовать придумать процесс разработки софта from the first principle. В конце он предлагает модель идеального процесса, как видится ему. Интересно, что этот процесс позволяет размышлять не просто про идеал, а про вашу конкретную ситуацию и понять что не так с вашим процессом или вспоминая Льва Толстого понять в чем ваше несчастье:)
Ну а теперь кратко про мысли Дэйва
- Фиксирует цели разработки софта как решение проблем других при помощи софта. Для этого надо:
-- Понять проблему - отсюда появляются requirements
-- Решить проблему - тут мы пока пишем код, но некоторые говорят, что скоро будет писать только промпты
-- Проверить, что она решена - отсюда появляются тесты
- Так как мир вокруг изменчив, то нам надо уметь меняться - меняются требования и нам надо уметь делать изменения - отсюда появляется желание двигаться вперед маленькими шагами
- Нам надо понимать, что мы двигаемся в нужную сторону, поэтому нам надо верифицировать результаты и разрабатывать софт инкрементально
- Одновременно нам нужно, чтобы наша система работала с первой версии и на протяжении всех инкрементальных изменений - она же решает задачи пользователей, как мы определились в самом начале (а для этого она должна быть up & running)
Дальше автор показывает процесс:
- Смутное желание от бизнеса
- User story, где важно выразить потребности пользователя, а не конкретное решение
- Тут же важно привести примеры (из которых можно сделать test cases)
- А дальше уже идет design & implement часть, которую автор описывает подробнее
-- Про commit stage, упоминая continuous integration - на этой фазе проверяется техническая корректность изменений
-- Про acceptance stage - на этой стадии идут проверки, а можно ли релизить это изменение: acceptance test, security, performance, etc
Ну и заканчивает автор на высокой ноте, говоря, что такой процесс используется во многих tech компаниях по всему миру и дает хорошие результаты. Собственно это финальное утверждение коррелирует с кликбейтной обложкой, которая хорошо привлекает внимание, но почти не упоминается по всему видео:)
P.S.
В общем, в этом видео нет ничего нового, но оно краткое, понятное и дает хорошую базовую модель процессов разработки.
#Management #Software #Engineering #SoftwareDevelopment #Processes #Devops #SRE
Это короткое видео Дэйва Фарли посвящено дизайну идеального процесса разработки софта. Интересно, что сам Дейв - тертый калач, который в давние времена написал книгу Continuous Delivery (я про нее рассказывал), а недавно - "Modern Software Engineering: Doing What Works to Build Better Software Faster", которая стоит у меня на полке и ждет своего часа. В этом видео Дэйв предлагает отринуть текущие практики и попробовать придумать процесс разработки софта from the first principle. В конце он предлагает модель идеального процесса, как видится ему. Интересно, что этот процесс позволяет размышлять не просто про идеал, а про вашу конкретную ситуацию и понять что не так с вашим процессом или вспоминая Льва Толстого понять в чем ваше несчастье:)
Все счастливые семьи похожи друг на друга, каждая несчастливая семья несчастлива по своему
Ну а теперь кратко про мысли Дэйва
- Фиксирует цели разработки софта как решение проблем других при помощи софта. Для этого надо:
-- Понять проблему - отсюда появляются requirements
-- Решить проблему - тут мы пока пишем код, но некоторые говорят, что скоро будет писать только промпты
-- Проверить, что она решена - отсюда появляются тесты
- Так как мир вокруг изменчив, то нам надо уметь меняться - меняются требования и нам надо уметь делать изменения - отсюда появляется желание двигаться вперед маленькими шагами
- Нам надо понимать, что мы двигаемся в нужную сторону, поэтому нам надо верифицировать результаты и разрабатывать софт инкрементально
- Одновременно нам нужно, чтобы наша система работала с первой версии и на протяжении всех инкрементальных изменений - она же решает задачи пользователей, как мы определились в самом начале (а для этого она должна быть up & running)
Дальше автор показывает процесс:
- Смутное желание от бизнеса
- User story, где важно выразить потребности пользователя, а не конкретное решение
- Тут же важно привести примеры (из которых можно сделать test cases)
- А дальше уже идет design & implement часть, которую автор описывает подробнее
-- Про commit stage, упоминая continuous integration - на этой фазе проверяется техническая корректность изменений
-- Про acceptance stage - на этой стадии идут проверки, а можно ли релизить это изменение: acceptance test, security, performance, etc
Ну и заканчивает автор на высокой ноте, говоря, что такой процесс используется во многих tech компаниях по всему миру и дает хорошие результаты. Собственно это финальное утверждение коррелирует с кликбейтной обложкой, которая хорошо привлекает внимание, но почти не упоминается по всему видео:)
P.S.
В общем, в этом видео нет ничего нового, но оно краткое, понятное и дает хорошую базовую модель процессов разработки.
#Management #Software #Engineering #SoftwareDevelopment #Processes #Devops #SRE
YouTube
The Most Powerful Software Development Process Is The Easiest • Dave Farley • GOTO 2024
We’re so pleased to having teamed up with Dave Farley, author of “Continuous Delivery” and frequent GOTO Conferences speaker, for a monthly video series featuring ideas about continuous delivery, DevOps, test-driven development, BDD, software engineering…
👍11❤4🔥2
Become an Effective Software Engineering Manager • James Stanier & Gergely Orosz • GOTO 2023
Интересное интервью с James Stanier, автором книги "Become an Effective Software Engineering Manager" и отдельно расшифровка.
Интересные моменты
- The real stories behind the book - каждая глава начинается с истории, которая легко позволяет представить себя на месте главного персонажа (пример с менеджером команды, что не поставялет нужный результат). Эти части написаны по мотивам реальных историй:)
- Journey to become an engineering manager - про треки развития внутри разработки, а также как легко расти естественно вместе с компанией на растущем рынке:)
- Prenoscriptions vs tools: Why this book is different - в этой книге нет описания как нужно поступать в каждой конкретной ситуации. Вместо этого тут описываются ситуации и возможное поведение в их рамках. А дальше читатели уже сами могут решать как им поступать:) Ну кроме гигиенических правил бытия менеджером, что идут в начале книги
- Getting into management: How to make it happen - тут обсуждается как можно дорасти до engineering manager в рамках растущей компании ... и как сейчас это сложно сделать в текущем контексте, где часть компаний скорее не растут, а сжимаются. Плюс тут обсуждается как сделать так, чтобы попытка стать менеджером была безопасной (чтобы можно было вернуться на роль individual contributor, если роль менеджера не подошла)
- Trends in engineering management - история про удаленную работу, про волны сокращений в tech компаниях, а также как часть engineering managers могут возвращаться в разработку по причинам уменьшения штата. Ну и про увольнения
- Must-have tools in management - тут ребята говорят про делегирование/контроль, а также про стоицизм
- Book recommendations - рассказ про другие книги - "Effective Remote Work" и "The Software Engineer's Guidebook", где первая книга гостя, а вторая - интервьюера.
#Management #Leadership #Software #Engineering #SoftwareDevelopment #Career
Интересное интервью с James Stanier, автором книги "Become an Effective Software Engineering Manager" и отдельно расшифровка.
Интересные моменты
- The real stories behind the book - каждая глава начинается с истории, которая легко позволяет представить себя на месте главного персонажа (пример с менеджером команды, что не поставялет нужный результат). Эти части написаны по мотивам реальных историй:)
- Journey to become an engineering manager - про треки развития внутри разработки, а также как легко расти естественно вместе с компанией на растущем рынке:)
- Prenoscriptions vs tools: Why this book is different - в этой книге нет описания как нужно поступать в каждой конкретной ситуации. Вместо этого тут описываются ситуации и возможное поведение в их рамках. А дальше читатели уже сами могут решать как им поступать:) Ну кроме гигиенических правил бытия менеджером, что идут в начале книги
- Getting into management: How to make it happen - тут обсуждается как можно дорасти до engineering manager в рамках растущей компании ... и как сейчас это сложно сделать в текущем контексте, где часть компаний скорее не растут, а сжимаются. Плюс тут обсуждается как сделать так, чтобы попытка стать менеджером была безопасной (чтобы можно было вернуться на роль individual contributor, если роль менеджера не подошла)
- Trends in engineering management - история про удаленную работу, про волны сокращений в tech компаниях, а также как часть engineering managers могут возвращаться в разработку по причинам уменьшения штата. Ну и про увольнения
- Must-have tools in management - тут ребята говорят про делегирование/контроль, а также про стоицизм
- Book recommendations - рассказ про другие книги - "Effective Remote Work" и "The Software Engineer's Guidebook", где первая книга гостя, а вторая - интервьюера.
#Management #Leadership #Software #Engineering #SoftwareDevelopment #Career
YouTube
Become an Effective Software Engineering Manager • James Stanier & Gergely Orosz • GOTO 2023
This interview was recorded for the GOTO Book Club. #GOTOcon #GOTObookclub
http://gotopia.tech/bookclub
Read the full trannoscription of the interview here:
https://gotopia.tech/episodes/289
James Stanier - Director of Engineering at Shopify & Author of "Become…
http://gotopia.tech/bookclub
Read the full trannoscription of the interview here:
https://gotopia.tech/episodes/289
James Stanier - Director of Engineering at Shopify & Author of "Become…
👍9🔥8❤1
Канбан Метод. Базовая практика
Дочитал ночью эту книгу Леши Пименова, которая посвящена оптимизации процессов нематериального производства. Сразу, начиная с обложки, Алексей опрокидывает все базовые представление о Канбане
И дальше идет отстройка от старого канбана к новому, который придумал David J Anderson и превратил это в Kanban Univerysity (с курсами и сертификациями). Оставим в стороне сам подход к выбору уже используемого слова, а дальше объяснению всем, что это слово теперь значит что-то другое на совести David J Anderson. А рассмотрим саму книгу, которая состоит из четырех разделов.
1. Нематериальное производство
В этой части дается краткая отсылка к истории, когда производство было материальным и можно было видеть как материалы и незаконченное производство двигается по стадиям процесса (как в "Тойота"). А вот в условной разработке мы это движение уже не видим и нам нужно делать приседания для визуализации (откуда и растут ногу у знаменитых досок с тикетами)
2. Введение в Канбан Метод
Здесь все начинается с разбора принципов управления изменениями
- Начните с того, что есть сейчас (если задуматься над фразой, то сложно начать с чего-то другого)
- Договоритесь об эволюционном развитии (нет революциям и да постепенным улучшениям)
- Поощряйте проявление лидерства на всех уровнях
Дальше автор переходит к рассмотрению принципов поставки ценности
- Начиная с определения, что такое сервис поставки ценности
- Продолжая развитием правил для улушения показателей
- Отмечая важность понимания и фокуса на ожиданиях заказчика
- Говоря про важность управления работой, а не людьми
Завершает автор разбором базовых практик
- Визуализация
- WIP лимиты
- Управление потоком
- Явные правила
- Использование петель обратной связи
- Совместное развитие на основе моделей и научного подхода
3. Начиннаем использовать канбан
Здесь автор рассказывает про то, как изучать и улучшать процессы на практике, а точнее про
- Метрики производственного процеса
- Жизненные циклы
- Классы обслуживания
- Как строить канбан систему: про обязательства в такой системе, ее составные части, как дизайнить тикеты и саму доску.
Отдельно разбирается STATIK (System Thinking Approach To Introducing Kanban)
4. Улучшение канбан-системы
В этом разделе предполагается, что у нас уже есть канбан-система и мы дальше начинаем ее файн-тюнить, используя
- Накопительную диаграмму потока (cumulative flow diagram)
- Работу с узкими звеньями (как их выявить и что с ними делать)
- Работу с ресурсами непостоянной доступности (что это такое и как с ними быть)
- Что делать с вариативностью и как использовать теорию вероятности и массового обслуживаня (очень интересна часть про работу с рисками)
- Отдельно разбираются типы встреч и их ритмичность в канбан системе
Если подводить итоги, то вот мое мнение относительно книги
- Название книги не обмануло - в ней действительно собраны базовые практики по управлению процессами
- Эти практики являются полезными и хорошо бы руководителю про них знать и уметь применять
- Сама книга отлично подходит для начинающих руководителей, так как описывает эти практики и показывает буквально на пальцах как их стоит использовать себе во благо
- Для опытных руководителей книга может показаться скучной - в ней обсуждаются очень базовые вещи, ну и большое количество диаграмм в некоторых частях хоть и полезно новичкам, но у опытных людей вызывает мысли "да и так уже все ясно, а дальше-то что"
В общем, я эту книгу очень рекомендую руководителям и тем, кто планирует ими стать
- Если вы все поняли и вам описанное в ней кажется очевидным, то это очень хорошо и вы можете копать глубже
- Если вы поняли не все, то книга поможет подтянуть вам свой уровень
- В общем, эта книга примерно тянет на уровень тимлида разработки
Про улучшение процессов разработки софта я тоже как-то уже рассказывал и про kanban я там говорил по книге "Making Work Visible", на которую я как-то написал краткое саммари.
#Processes #Management #Leadership #Software #Kanban
Дочитал ночью эту книгу Леши Пименова, которая посвящена оптимизации процессов нематериального производства. Сразу, начиная с обложки, Алексей опрокидывает все базовые представление о Канбане
- его изобрели на "Тойоте"
- в нем есть доски и стикеры
- там ограничивают количество незавршенной работы
И дальше идет отстройка от старого канбана к новому, который придумал David J Anderson и превратил это в Kanban Univerysity (с курсами и сертификациями). Оставим в стороне сам подход к выбору уже используемого слова, а дальше объяснению всем, что это слово теперь значит что-то другое на совести David J Anderson. А рассмотрим саму книгу, которая состоит из четырех разделов.
1. Нематериальное производство
В этой части дается краткая отсылка к истории, когда производство было материальным и можно было видеть как материалы и незаконченное производство двигается по стадиям процесса (как в "Тойота"). А вот в условной разработке мы это движение уже не видим и нам нужно делать приседания для визуализации (откуда и растут ногу у знаменитых досок с тикетами)
2. Введение в Канбан Метод
Здесь все начинается с разбора принципов управления изменениями
- Начните с того, что есть сейчас (если задуматься над фразой, то сложно начать с чего-то другого)
- Договоритесь об эволюционном развитии (нет революциям и да постепенным улучшениям)
- Поощряйте проявление лидерства на всех уровнях
Дальше автор переходит к рассмотрению принципов поставки ценности
- Начиная с определения, что такое сервис поставки ценности
- Продолжая развитием правил для улушения показателей
- Отмечая важность понимания и фокуса на ожиданиях заказчика
- Говоря про важность управления работой, а не людьми
Завершает автор разбором базовых практик
- Визуализация
- WIP лимиты
- Управление потоком
- Явные правила
- Использование петель обратной связи
- Совместное развитие на основе моделей и научного подхода
3. Начиннаем использовать канбан
Здесь автор рассказывает про то, как изучать и улучшать процессы на практике, а точнее про
- Метрики производственного процеса
- Жизненные циклы
- Классы обслуживания
- Как строить канбан систему: про обязательства в такой системе, ее составные части, как дизайнить тикеты и саму доску.
Отдельно разбирается STATIK (System Thinking Approach To Introducing Kanban)
4. Улучшение канбан-системы
В этом разделе предполагается, что у нас уже есть канбан-система и мы дальше начинаем ее файн-тюнить, используя
- Накопительную диаграмму потока (cumulative flow diagram)
- Работу с узкими звеньями (как их выявить и что с ними делать)
- Работу с ресурсами непостоянной доступности (что это такое и как с ними быть)
- Что делать с вариативностью и как использовать теорию вероятности и массового обслуживаня (очень интересна часть про работу с рисками)
- Отдельно разбираются типы встреч и их ритмичность в канбан системе
Если подводить итоги, то вот мое мнение относительно книги
- Название книги не обмануло - в ней действительно собраны базовые практики по управлению процессами
- Эти практики являются полезными и хорошо бы руководителю про них знать и уметь применять
- Сама книга отлично подходит для начинающих руководителей, так как описывает эти практики и показывает буквально на пальцах как их стоит использовать себе во благо
- Для опытных руководителей книга может показаться скучной - в ней обсуждаются очень базовые вещи, ну и большое количество диаграмм в некоторых частях хоть и полезно новичкам, но у опытных людей вызывает мысли "да и так уже все ясно, а дальше-то что"
В общем, я эту книгу очень рекомендую руководителям и тем, кто планирует ими стать
- Если вы все поняли и вам описанное в ней кажется очевидным, то это очень хорошо и вы можете копать глубже
- Если вы поняли не все, то книга поможет подтянуть вам свой уровень
- В общем, эта книга примерно тянет на уровень тимлида разработки
Про улучшение процессов разработки софта я тоже как-то уже рассказывал и про kanban я там говорил по книге "Making Work Visible", на которую я как-то написал краткое саммари.
#Processes #Management #Leadership #Software #Kanban
❤13👍10🔥5🤡1
Вакансия TPM (technical product manager) в IDP (internal developer platform) @ Tinkoff
Большие технологические компании в какой-то момент времени приходят к созданию своих платформ разработки, которые должны консолидировать общие инструменты и предоставить их консистентно всем продуктовым командам. За счет этого компании стремятся к упрощению разработки продуктовых вещей, сокращению time-to-market, а также к экономии на масштабе. В Тинькофф это произошло 4 года назад с приходом в компанию Игоря Маслова, вокруг которого стала собираться core-команда, которая потом превратилась в coretech. На заре становления к этой команде присоединился и Дима Гаевский, который когда-то начинал работать у меня, потом руководил несколькими командами в coretech, а теперь исполняет роль CPO (chief product officer) нашей внутренней платформы. И сейчас Дима ищет себе технического продакта на направление "Code & Build" (Version Control + CI домен).
Вот как Дима сам описывает то, чем занимаются ребята в IDP
Если вам понравилась эта позиция, то вы можете написать Диме (@drwatsno)
P.S.
Работа с Димой очень хорошо прокачивает навыки - он глубоко шарит во многих комплексных вещах, поэтому это хороший вариант для тех, кто готов ботать новое и разбираться глубоко:)
#Vacancy #Software #ProductManagement
Большие технологические компании в какой-то момент времени приходят к созданию своих платформ разработки, которые должны консолидировать общие инструменты и предоставить их консистентно всем продуктовым командам. За счет этого компании стремятся к упрощению разработки продуктовых вещей, сокращению time-to-market, а также к экономии на масштабе. В Тинькофф это произошло 4 года назад с приходом в компанию Игоря Маслова, вокруг которого стала собираться core-команда, которая потом превратилась в coretech. На заре становления к этой команде присоединился и Дима Гаевский, который когда-то начинал работать у меня, потом руководил несколькими командами в coretech, а теперь исполняет роль CPO (chief product officer) нашей внутренней платформы. И сейчас Дима ищет себе технического продакта на направление "Code & Build" (Version Control + CI домен).
Вот как Дима сам описывает то, чем занимаются ребята в IDP
Что мы делаем:
- Собираем воедино все сценарии разработки, тестирования и сопровождения приложений в Tinkoff, создавая централизованную application-centric PaaS платформу Spirit.
- Платформа представляет собой консоль в стиле gcp/aws, построенную вокруг SSO с тесной интеграцией в общие сценарии инфраструктурных сервисов (БД), систем непрерывного запуска нагрузочных тестов, DevSecOps, VCS (Gitlab CE), движок квот, браузерные и мобильные фермы, хранилище артефактов, и multi-cloud runtime платформу.
- Продукт включает более 15 систем, объединенных вокруг различных этапов производственного цикла, с постоянным расширением числа систем.
Spirit включает в себя продуктовые направления:
- Discover - Inner Source, поиск, маркетплейс решений
- Code & Build - VCS (сейчас форк community Gitlab), CI, Artifact management (свое registry)
- Configure & Deliver & Operate - централизованная система конфигурации и деплоя приложений, а также рантайм платформа
Наша глобальная цель:
- Создать экосистему глубоко интегрированных инжиниринговых продуктов для разработчиков закрывающих все потребности на всем цикле производства. Экосистема объединяет в себе платформу для разработки Spirit, управления инцидентами FineDog и Observability - SAGE.
- Мы - часть Core Technologies, подразделения, созданного для повышения продуктивности разработки в Tinkoff, в IT которого трудится уже более 10 тысяч инженеров.
Мы придерживаемся идеологии you build it - you run it, пишем качественный код, самостоятельно покрываем все unit и интеграционными тестами. Задачи в команде варьируются от решения багов до написания сложных RFC по продуктовым требованиям и декомпозиции на задачи.
Если вам понравилась эта позиция, то вы можете написать Диме (@drwatsno)
P.S.
Работа с Димой очень хорошо прокачивает навыки - он глубоко шарит во многих комплексных вещах, поэтому это хороший вариант для тех, кто готов ботать новое и разбираться глубоко:)
#Vacancy #Software #ProductManagement
❤15👍8🔥4