If debugging is the process of removing software bugs, then programming must be the process of putting them in.
(с) Edsger Dijkstra
Дейкстра — датский учёный в области Computer Science. На его исследованиях в современном мире много чего работает. В своё время он хорошо набрасывал на технологии и вот несколько высказываний от него, которые зашли:
— Programming in Basic causes brain damage.
— Teaching COBOL ought to be regarded as a criminal act.
— Mathematicians are like managers - they want improvement without change.
Из современных мемчиков есть:
— Использование любой другой кодировки, кроме как UTF-8 нужно считать актом экстримизма и карать по всей строгости УК (это было популярно, когда было множество кодировок и UTF-8 не зашел как стандарт де-факто. где-то до 12 года) (c) Башорг, вроде как
— Node.js нужен для того, чтобы делать SSR, чтобы экономить пользователю батарейку на телефоне. Использование ноды для чего-то более сложным считать экстримизмом и карать по всей строгости УК (с) Макс Лапшин.
— Лучше вляпаться в PHP, чем в Node.js. Ну и в крестах лучше сидеть, чем кодить на них. (Это про C++. Жаргонные названия плюсы или кресты)
Вот, после посещения одной из конференций по C++ Роб Пайк со своими корешами Кеном Томпсоном и Робертом Гризмаером посидели, подумали и появился Go.
Go, как язык достаточно прост в виду синтаксиса и его хорошо использовать при написании:
- Сетевых сервисов
- Чего-то, где нужна производительность
- Там, где нужна асинхронность (все скриптовые языки курят в сторонке, потому что написать что-то асинхронное на питоне иногда ломает мозг)
Ну и закончить пост хочется несколькими дедами:
— Лесли Лампорт. Автор Paxos. У него достаточно хороший блог по распределенным системам. А еще у него есть отличный доклад Thinking above the code, одна из самых интересных мыслей для меня была “If you are thinking without writing you are only pretending to think”. Поэтому, писать спецификации и обсуждать их с рабочей группой в тексте — один из самых продуктивных для меня способов принятия решения
— Доклад дяди Боба Expecting Proffesionalism
@retired_on_fire, Андрей Минкин
(с) Edsger Dijkstra
Дейкстра — датский учёный в области Computer Science. На его исследованиях в современном мире много чего работает. В своё время он хорошо набрасывал на технологии и вот несколько высказываний от него, которые зашли:
— Programming in Basic causes brain damage.
— Teaching COBOL ought to be regarded as a criminal act.
— Mathematicians are like managers - they want improvement without change.
Из современных мемчиков есть:
— Использование любой другой кодировки, кроме как UTF-8 нужно считать актом экстримизма и карать по всей строгости УК (это было популярно, когда было множество кодировок и UTF-8 не зашел как стандарт де-факто. где-то до 12 года) (c) Башорг, вроде как
— Node.js нужен для того, чтобы делать SSR, чтобы экономить пользователю батарейку на телефоне. Использование ноды для чего-то более сложным считать экстримизмом и карать по всей строгости УК (с) Макс Лапшин.
— Лучше вляпаться в PHP, чем в Node.js. Ну и в крестах лучше сидеть, чем кодить на них. (Это про C++. Жаргонные названия плюсы или кресты)
Вот, после посещения одной из конференций по C++ Роб Пайк со своими корешами Кеном Томпсоном и Робертом Гризмаером посидели, подумали и появился Go.
Go, как язык достаточно прост в виду синтаксиса и его хорошо использовать при написании:
- Сетевых сервисов
- Чего-то, где нужна производительность
- Там, где нужна асинхронность (все скриптовые языки курят в сторонке, потому что написать что-то асинхронное на питоне иногда ломает мозг)
Ну и закончить пост хочется несколькими дедами:
— Лесли Лампорт. Автор Paxos. У него достаточно хороший блог по распределенным системам. А еще у него есть отличный доклад Thinking above the code, одна из самых интересных мыслей для меня была “If you are thinking without writing you are only pretending to think”. Поэтому, писать спецификации и обсуждать их с рабочей группой в тексте — один из самых продуктивных для меня способов принятия решения
— Доклад дяди Боба Expecting Proffesionalism
@retired_on_fire, Андрей Минкин
YouTube
Leslie Lamport: Thinking Above the Code
Architects draw detailed blueprints before a brick is laid or a nail is hammered. Programmers and software engineers seldom do. A blueprint for software is called a specification. The need for extremely rigorous specifications before coding complex or critical…
Now for the economic need. Nowadays one often encounters the opinion that in the sixties programming has been an overpaid profession, and that in the coming years programmer salaries may be expected to go down.
(c) Edsger W. Dijkstra
Вот эта цитата была написана Дейкстрой в далекий 1972й год. Так что программисты overpaid с 60х годов. Пока еще не упали и программистов как всегда не хватает. Правда мы ушли от перфокарт и нормального программирования во что-то непонятное, жрущее кучу памяти.
Например, есть занятный баг на Mac Os Monterey, где windowserver начинает отжирать много оперативы, когда ты смотришь видосики на ютюбе или сериальчики на нетфликсе. Как один из костылей решения этой неприятной досады (у меня он отжирал до 74 гигов мозгов) - это выставить Refresh Rate в 60 герц, вместо модного ProMotion. Windowserver перестал отжирать много памяти и теперь, как обычно жрут память Node.js, Chrome, Slack.
Сегодня первое число и мне нужно высылать инвойс работодателю. Приятный бонус, что мне заплатят за полный месяц по полной ставке, хотя я подписал договор 13 числа. На прошлой неделе был интродакшн кол, где наш директор делала 1-1 со мной и задавала обычные вопросы, типа не чувствую ли я себя одиноким, все ли ок, нормальные ли задачи и так далее. Фидбек поступает достаточно хорошо и я почти адаптировался к тому, чтобы работать не в жире, а в гитхабе. Вчера потратил пару часов, чтобы выбрать более менее шаблон для выставления инвойсов и остановился на одном варианте в эксельке.
Продам своего Pajero Sport 2012 года. Прошу $14500. Машина в идеальном состоянии, подробности в личке 😂
@retired_on_fire, Андрей Минкин
(c) Edsger W. Dijkstra
Вот эта цитата была написана Дейкстрой в далекий 1972й год. Так что программисты overpaid с 60х годов. Пока еще не упали и программистов как всегда не хватает. Правда мы ушли от перфокарт и нормального программирования во что-то непонятное, жрущее кучу памяти.
Например, есть занятный баг на Mac Os Monterey, где windowserver начинает отжирать много оперативы, когда ты смотришь видосики на ютюбе или сериальчики на нетфликсе. Как один из костылей решения этой неприятной досады (у меня он отжирал до 74 гигов мозгов) - это выставить Refresh Rate в 60 герц, вместо модного ProMotion. Windowserver перестал отжирать много памяти и теперь, как обычно жрут память Node.js, Chrome, Slack.
Сегодня первое число и мне нужно высылать инвойс работодателю. Приятный бонус, что мне заплатят за полный месяц по полной ставке, хотя я подписал договор 13 числа. На прошлой неделе был интродакшн кол, где наш директор делала 1-1 со мной и задавала обычные вопросы, типа не чувствую ли я себя одиноким, все ли ок, нормальные ли задачи и так далее. Фидбек поступает достаточно хорошо и я почти адаптировался к тому, чтобы работать не в жире, а в гитхабе. Вчера потратил пару часов, чтобы выбрать более менее шаблон для выставления инвойсов и остановился на одном варианте в эксельке.
Продам своего Pajero Sport 2012 года. Прошу $14500. Машина в идеальном состоянии, подробности в личке 😂
@retired_on_fire, Андрей Минкин
Reddit
From the MacOS community on Reddit
Explore this post and more from the MacOS community
Программисты рядом, они настолько рядом, что некоторые даже вы.
Неделю пробовал попользоваться джинни. Вердикт: ну такое…
Это отличная платформа, но когда поговоришь с некоторыми рекрутерами, послушаешь про их процесс найма, становится понятно, почему Макс Ищенко у себя в линкедине говорит, что всё плохо и количество вакансий превышает количество кандидатов. Специально для рекрутеров на джинни у меня завелся шаблонный ответ
Hello.
Thank you for organizing the interview. I am writing to let you know that you have not been selected to be my employer.
I recognize this may be a disappointment to you. On this occasion, I received a significant number of applications from the companies that more closely fit my requirements for the next job.
Thank you for your time. Good luck and let’s keep connected.
Этот ответ я шлю всем рекрутерам именно на джинни, по нескольким причинам:
1. Слишком сложный процесс найма. Из самых интересных вариантов: три технических интервью (3, КАРЛ!). Два — это решать алгоритмические задачи (имхо, это надо приравнивать к программированию на доске). И еще нужно будет сделать тестовое на два часа времени, за выполнение которого хотя бы заплатят $100. Я понимаю, что в FAANG и подобных компаниях это работает и достаточно хорошо. К этому даже готовятся, но в том же самом FB процесс построен куда проще и кодить алгоритмы нужно всего час.
2. Долгий ответ от рекрутера, сложности с фоллоуапами, сложности с назначением времени для интервью, нет митинг-ноутсов. Некоторых рекрутеров приходилось подпинывать, чтобы просто с ними созвониться.
3. Нет интро о проекте и компании. Некоторые просто задают интересующие их вопросы и отпадает желание вообще с ними продолжать диалог.
Конечно, это придирки, есть конечно хорошие рекрутеры, с которыми приятно общаться, но большинство на джинни явно не тем занимаются.
Воронка:
1. Заинтересованных во мне рекрутеров: 25
2. С 20 из них я решил поговорить
3. 4 написали в телеграм, остальные остались на джинни
4. 4 сделали интрокол, чтобы сделать свой обычный фаст чек
5. Только одна девушка рекрутер всё-таки сделала нормальные фоллоуапы и достаточно серьезно относится к своей работе. Остальные как-то забили на коммуникацию.
Все жалуются, что нет кандидатов, а проблема чаще всего совершенно в другом. Кандидаты просто отваливаются, потому что большинство рекрутеров не делает свою работу. С программистами тоже самое, к сожалению.
@retired_on_fire, Андрей Минкин
Неделю пробовал попользоваться джинни. Вердикт: ну такое…
Это отличная платформа, но когда поговоришь с некоторыми рекрутерами, послушаешь про их процесс найма, становится понятно, почему Макс Ищенко у себя в линкедине говорит, что всё плохо и количество вакансий превышает количество кандидатов. Специально для рекрутеров на джинни у меня завелся шаблонный ответ
Hello.
Thank you for organizing the interview. I am writing to let you know that you have not been selected to be my employer.
I recognize this may be a disappointment to you. On this occasion, I received a significant number of applications from the companies that more closely fit my requirements for the next job.
Thank you for your time. Good luck and let’s keep connected.
Этот ответ я шлю всем рекрутерам именно на джинни, по нескольким причинам:
1. Слишком сложный процесс найма. Из самых интересных вариантов: три технических интервью (3, КАРЛ!). Два — это решать алгоритмические задачи (имхо, это надо приравнивать к программированию на доске). И еще нужно будет сделать тестовое на два часа времени, за выполнение которого хотя бы заплатят $100. Я понимаю, что в FAANG и подобных компаниях это работает и достаточно хорошо. К этому даже готовятся, но в том же самом FB процесс построен куда проще и кодить алгоритмы нужно всего час.
2. Долгий ответ от рекрутера, сложности с фоллоуапами, сложности с назначением времени для интервью, нет митинг-ноутсов. Некоторых рекрутеров приходилось подпинывать, чтобы просто с ними созвониться.
3. Нет интро о проекте и компании. Некоторые просто задают интересующие их вопросы и отпадает желание вообще с ними продолжать диалог.
Конечно, это придирки, есть конечно хорошие рекрутеры, с которыми приятно общаться, но большинство на джинни явно не тем занимаются.
Воронка:
1. Заинтересованных во мне рекрутеров: 25
2. С 20 из них я решил поговорить
3. 4 написали в телеграм, остальные остались на джинни
4. 4 сделали интрокол, чтобы сделать свой обычный фаст чек
5. Только одна девушка рекрутер всё-таки сделала нормальные фоллоуапы и достаточно серьезно относится к своей работе. Остальные как-то забили на коммуникацию.
Все жалуются, что нет кандидатов, а проблема чаще всего совершенно в другом. Кандидаты просто отваливаются, потому что большинство рекрутеров не делает свою работу. С программистами тоже самое, к сожалению.
@retired_on_fire, Андрей Минкин
Не хочу на фронт
(с) мемчик из интернета
Но, видимо придется.
Работа на Developer Advocate позиции требует много ресерча. Так что скорее всего придется мне идти в сторону универсальности. План обучения на ближайшее время
1. Terraform/Cloudformation или что там сейчас трендовое для того, чтобы была Infrastructure as a Code. Благо, сейчас слак выпустил events-api и ботов стало делать куда проще и дешевле. Особенно, если они не нагружены вообще никак. Просто пишем лямбда функцию, подключаем API гейтвей и несколько ботов могут работать бесплатно в рамках AWS Free Tier.
2. EKS/K8s и прочее трендовое по облакам, благо, что я оформил подписку на acloudguru.com. Забавная, кстати ситуация. Они выкупили linux academy а теперь Cloud guru выкупили Pluralsight.
3. React/Vue/Typescript и верстку (опять).
Самое печальное — это идти в третий пункт. Вот прям вообще не хочется. Все эти модные подходы в современном фронте как-то ломают голову и вообще фиг разберешься во всем этом стеке.
Поковырял Gatsby. Может быть хорошей альтернативой для Prismic и хорошо деплоится в Netlify.
Еще, что прикольного в Developer Advocate позиции — это нужно кодить кучу мелких проектов/демок. Кругозор расширяется будь здоров. Сейчас, потихоньку расковыриваю Supabase, это опенсорсный аналог Firebase. Нужно подружить их с чем-нибудь из нашего стека. Пока первый кандидат - это Kratos. А еще в планах пощупать FerretDB и Yugabute
PS. Если есть хорошие материалы по современному фронту (Vue/React/TypeScript), Накидайте плиз в комментариях.
@retired_on_fire, Андрей Минкин
(с) мемчик из интернета
Но, видимо придется.
Работа на Developer Advocate позиции требует много ресерча. Так что скорее всего придется мне идти в сторону универсальности. План обучения на ближайшее время
1. Terraform/Cloudformation или что там сейчас трендовое для того, чтобы была Infrastructure as a Code. Благо, сейчас слак выпустил events-api и ботов стало делать куда проще и дешевле. Особенно, если они не нагружены вообще никак. Просто пишем лямбда функцию, подключаем API гейтвей и несколько ботов могут работать бесплатно в рамках AWS Free Tier.
2. EKS/K8s и прочее трендовое по облакам, благо, что я оформил подписку на acloudguru.com. Забавная, кстати ситуация. Они выкупили linux academy а теперь Cloud guru выкупили Pluralsight.
3. React/Vue/Typescript и верстку (опять).
Самое печальное — это идти в третий пункт. Вот прям вообще не хочется. Все эти модные подходы в современном фронте как-то ломают голову и вообще фиг разберешься во всем этом стеке.
Поковырял Gatsby. Может быть хорошей альтернативой для Prismic и хорошо деплоится в Netlify.
Еще, что прикольного в Developer Advocate позиции — это нужно кодить кучу мелких проектов/демок. Кругозор расширяется будь здоров. Сейчас, потихоньку расковыриваю Supabase, это опенсорсный аналог Firebase. Нужно подружить их с чем-нибудь из нашего стека. Пока первый кандидат - это Kratos. А еще в планах пощупать FerretDB и Yugabute
PS. Если есть хорошие материалы по современному фронту (Vue/React/TypeScript), Накидайте плиз в комментариях.
@retired_on_fire, Андрей Минкин
Gatsby
The Best React-Based Framework | Gatsby
Gatsby is a React-based open source framework with performance, scalability and security built-in. Collaborate, build and deploy 1000x faster on Netlify.
Friday sees more smiles than any other day of the workweek!
—Kate Summers
Традиционный пятничный пост, который больше развлекательно-познавательный.
Финансы
Технологический сектор потихоньку начинает расти, что не может радовать. Акции близзов после покупки майкрософтом пока не так быстро растут, как хотелось бы, но все же пока они в плюсе. Сами близзы пока ничего не анонсят, хотя давно пора.
Остальные компании в портфеле потихоньку тоже показывают рост. Это ROKU, NIO, SPLK.
В прошлую субботу поговорили с ребятами из DevZen на тему ранней пенсии и интересно вот что:
1. Работа в публичных компаниях и покупка акций со скидкой для сотрудника (порядка 15%). Вот это хороший бонус к плюхам компании, а не эти ваши печеньки в офис и дружный коллектив
2. Проблема с финансовой граммотностью стоит во всём мире, правда в странах с большей социальной защищенностью государство пушит вас к тому, чтобы вы ивестировали и откладывали себе на пенсию.
3. Есть отрицательная ставка по депозиту по превышению лимита
Интересный получился опыт разговора на эту тему в подкасте. Я готовился, но местами получалось сумбурно.
Что я узнал эа эту неделю
1. Если вы используете транзакции, то вы наверное знаете о связке BEGIN; COMMIT; ROLLBACK, которые предоставляют обновление данных по ACID. Иногда в тестах забавно использовать ROLLBACK, просто чтобы узнать, что твои запросы работают. Кстати, использование ORM должно идти после того, как человек напишет хоть какой-то запрос.
2. В техническом писательстве, как и в блоггерстве просто важна дисциплина. Хороший пост ‘How To Write Better Technical Content’. С русскоязычными постами у меня нет особых проблем (иногда с фантазией если только). а вот с английским всё куда сложнее.
3. Grammarly пользуются не только на СНГ. У нас половина команды пользуется этим продуктом, чтобы быть грамотнее. Но у нас команда мультикультурная и мы говорим на 13 языках. Там даже есть флаг КР.
4. Винцент нашел отличную замену граммарли, которую я попробую поюзать в ближайшее время. Она для девелоперов, консольная и наверное даже в вим можно будет затащить. Можно пробовать поюзать
Развлекаловка
1. Медитация для девопсов
2. Что нужно знать разработчику про Web3
3. Почему не нужно использовать MMAP, если вы кодите базу данных
4. Как я слушал новый релиз от Мешуги
5. Пассивно-Агрессивный фидбек о вашем пароле
До понедельника!
@retired_on_fire, Андрей Минкин
—Kate Summers
Традиционный пятничный пост, который больше развлекательно-познавательный.
Финансы
Технологический сектор потихоньку начинает расти, что не может радовать. Акции близзов после покупки майкрософтом пока не так быстро растут, как хотелось бы, но все же пока они в плюсе. Сами близзы пока ничего не анонсят, хотя давно пора.
Остальные компании в портфеле потихоньку тоже показывают рост. Это ROKU, NIO, SPLK.
В прошлую субботу поговорили с ребятами из DevZen на тему ранней пенсии и интересно вот что:
1. Работа в публичных компаниях и покупка акций со скидкой для сотрудника (порядка 15%). Вот это хороший бонус к плюхам компании, а не эти ваши печеньки в офис и дружный коллектив
2. Проблема с финансовой граммотностью стоит во всём мире, правда в странах с большей социальной защищенностью государство пушит вас к тому, чтобы вы ивестировали и откладывали себе на пенсию.
3. Есть отрицательная ставка по депозиту по превышению лимита
Интересный получился опыт разговора на эту тему в подкасте. Я готовился, но местами получалось сумбурно.
Что я узнал эа эту неделю
1. Если вы используете транзакции, то вы наверное знаете о связке BEGIN; COMMIT; ROLLBACK, которые предоставляют обновление данных по ACID. Иногда в тестах забавно использовать ROLLBACK, просто чтобы узнать, что твои запросы работают. Кстати, использование ORM должно идти после того, как человек напишет хоть какой-то запрос.
2. В техническом писательстве, как и в блоггерстве просто важна дисциплина. Хороший пост ‘How To Write Better Technical Content’. С русскоязычными постами у меня нет особых проблем (иногда с фантазией если только). а вот с английским всё куда сложнее.
3. Grammarly пользуются не только на СНГ. У нас половина команды пользуется этим продуктом, чтобы быть грамотнее. Но у нас команда мультикультурная и мы говорим на 13 языках. Там даже есть флаг КР.
4. Винцент нашел отличную замену граммарли, которую я попробую поюзать в ближайшее время. Она для девелоперов, консольная и наверное даже в вим можно будет затащить. Можно пробовать поюзать
Развлекаловка
1. Медитация для девопсов
2. Что нужно знать разработчику про Web3
3. Почему не нужно использовать MMAP, если вы кодите базу данных
4. Как я слушал новый релиз от Мешуги
5. Пассивно-Агрессивный фидбек о вашем пароле
До понедельника!
@retired_on_fire, Андрей Минкин
Wikipedia
ACID
set of properties of database transactions intended to guarantee validity even in the event of errors, power failures, etc.
Keep calm and pretend it’s not Monday
Прошлая рабочая неделя завершилась интересно. Мой блогпост смержили в мастер и пока писал блогпост, поправил пару багов. Также нашли один небольшой баг в сиайке из-за чего не проходил пайплайн.
Так как компания пилилась разработчиками, то для всех использовать mdx или md файлы кажется достаточно простой историей. Gatsby в этом плане предоставляет кучу интеграций и компонентов, которые можно вставлять в md файлы. Получается эдакая смесь из md и веб компонентов. У нас есть компонент, который делает оформление для кода и можно вставить ссылочку на файл на гитхабе и он будет постоянно обновлен.
Еще мы запустили в нашем слак сообществе поддержку на двух языках: русском и немецком.
Спустя месяц (Хотя на самом деле несколько недель всего прошло) я влился в работу, стал лучше разбираться в продукте и процессах и всё встало на свои места. Процесс оплаты достаточно простой и понятный. Попробую его в следующем месяце. Правила просты. Шаг первый — отправляешь инвойс, шаг второй получаешь деньги. Написать инвойс помогают (я потратил несколько часов, чтобы найти шаблон для инвойса, который мне понравился бы)
Разобрался в области Developer Relations и завтра расскажу какие там есть позиции. А еще, FB упал на 26% из-за отчёта (Там часть пользователей упала у продуктов, потому что ушла в тикток). Жду, когда тикток начнет выходить на IPO, чтобы прикупить чутка.
Как началась ваша рабочая неделя?
@retired_on_fire, Андрей Минкин
Прошлая рабочая неделя завершилась интересно. Мой блогпост смержили в мастер и пока писал блогпост, поправил пару багов. Также нашли один небольшой баг в сиайке из-за чего не проходил пайплайн.
Так как компания пилилась разработчиками, то для всех использовать mdx или md файлы кажется достаточно простой историей. Gatsby в этом плане предоставляет кучу интеграций и компонентов, которые можно вставлять в md файлы. Получается эдакая смесь из md и веб компонентов. У нас есть компонент, который делает оформление для кода и можно вставить ссылочку на файл на гитхабе и он будет постоянно обновлен.
Еще мы запустили в нашем слак сообществе поддержку на двух языках: русском и немецком.
Спустя месяц (Хотя на самом деле несколько недель всего прошло) я влился в работу, стал лучше разбираться в продукте и процессах и всё встало на свои места. Процесс оплаты достаточно простой и понятный. Попробую его в следующем месяце. Правила просты. Шаг первый — отправляешь инвойс, шаг второй получаешь деньги. Написать инвойс помогают (я потратил несколько часов, чтобы найти шаблон для инвойса, который мне понравился бы)
Разобрался в области Developer Relations и завтра расскажу какие там есть позиции. А еще, FB упал на 26% из-за отчёта (Там часть пользователей упала у продуктов, потому что ушла в тикток). Жду, когда тикток начнет выходить на IPO, чтобы прикупить чутка.
Как началась ваша рабочая неделя?
@retired_on_fire, Андрей Минкин
Есть что по докладам? А если найду?
Подготовить один доклад занимает до месяца времени, в зависимости от опыта и истории, которую хочет рассказать разработчик. В первый раз — это месяц. В остальные разы меньше, но в среднем подготовить хороший доклад на хорошую конференцию — это 2-3 дня работы. Опытные докладчики могут слайды сделать за 1-2 часа, но это уже после кучи выступлений.
Написать хороший блогпост — это неделя времени работы нескольких людей, если компания достаточно серьезная (тут ресерч, написание самого поста, редактирование, вычитка и потом публикация)
Любой этот контент, особенно выложенный в паблике, либо на сайте компании дает хорошее представление об уровне задач и говорит о том, что компания участвует в жизни сообщества разработчиков. У разработчика есть хотя бы демоверсия его коллег. С кем придется работать, какие процессы есть и как вообще относятся к этому внутри компании.
Но практика показывает, что компании, которая не участвует в жизни разработческого сообщества сложнее нанимать, чем компаниям, которые имеют хотя бы опенсорсные продукты.
Ну и контент, который оставлен разработчиками после себя помогает рекрутерам лучше отбивать возражения на самые популярные вопросы, потому что чаще всего на это есть ссылочки
Поэтому — хорошо, когда компании вкладываются в DevRel Активности. Плохо, когда они этого не делают. А за прошлый месяц я сделал слайды для 4х докладов на разные целевые аудитории. Самый сложный доклад, который я до сих пор делаю — это Authentication & Authorization 101. Пока покрыл тему с Аутентификацией. Буду рад рассказать в какой-нибудь для какой-нибудь аудитории.
@retired_on_fire, Андрей Минкин
Подготовить один доклад занимает до месяца времени, в зависимости от опыта и истории, которую хочет рассказать разработчик. В первый раз — это месяц. В остальные разы меньше, но в среднем подготовить хороший доклад на хорошую конференцию — это 2-3 дня работы. Опытные докладчики могут слайды сделать за 1-2 часа, но это уже после кучи выступлений.
Написать хороший блогпост — это неделя времени работы нескольких людей, если компания достаточно серьезная (тут ресерч, написание самого поста, редактирование, вычитка и потом публикация)
Любой этот контент, особенно выложенный в паблике, либо на сайте компании дает хорошее представление об уровне задач и говорит о том, что компания участвует в жизни сообщества разработчиков. У разработчика есть хотя бы демоверсия его коллег. С кем придется работать, какие процессы есть и как вообще относятся к этому внутри компании.
Но практика показывает, что компании, которая не участвует в жизни разработческого сообщества сложнее нанимать, чем компаниям, которые имеют хотя бы опенсорсные продукты.
Ну и контент, который оставлен разработчиками после себя помогает рекрутерам лучше отбивать возражения на самые популярные вопросы, потому что чаще всего на это есть ссылочки
Поэтому — хорошо, когда компании вкладываются в DevRel Активности. Плохо, когда они этого не делают. А за прошлый месяц я сделал слайды для 4х докладов на разные целевые аудитории. Самый сложный доклад, который я до сих пор делаю — это Authentication & Authorization 101. Пока покрыл тему с Аутентификацией. Буду рад рассказать в какой-нибудь для какой-нибудь аудитории.
@retired_on_fire, Андрей Минкин
Про Деврел. Деврел — это область, которая включает в себя следующие дисциплины:
— Developer Marketing
— Developer Avangelism
— Developer Advocacy
— Developer Experience
— Community Management
Developer Marketing
Мало чем отличается от традиционного цифрового маркетинга.
Основная цель — создать Go-to-developer стратегию. Почти тоже самое что и go-to-market, только для разработчиков.
Заниматься придется формированием плана коммуникации с разработчиками, координированием запуска проектов, планирование разных ивентов, спонсорств и партнерств.
Развивать придется следующие скиллы: знания о разработчиках, стеке, трендах. Умение ресерчить и писать, аналитическое и стратегическое мышление, умение планировать.
Работать придется с продуктовыми менеджерами, маркетологами в компании, Developer Evangelism.
Маркетологи, которые хотят в IT и не хотят учиться, добро пожаловать. Тут есть отдельная зона для роста для смены карьеры
Developer Evangelism
Основная цель — рассказывать о продукте.
Заниматься придется тем, что рассказывать и присуствовать на конференциях, пилить технический контент (блоги и видосы), записывать подкасты и стримить. Партнериться с разными сообществами.
Развивать придется скиллы публичных выступлений, сторителлинг, скилы писательства и нетворинга. Ну и билдить много разных демок (хотя, тут технические скиллы не очень сильно нужны чаще всего для некоторых продуктов)
Сотрудничать придется с Developer Marketing и Developer Advocacy
Developer Advocacy
Основная цель для этих ребят сделать так, чтобы разработчики пользовались продуктом компании.
Заниматься придется тем, что постоянно билдить разные демки, посещать разные конференции, также стримить. А еще разрабатывать продукт и активно продвигать идеи догфудинга продукта. Поддерживать сообщество разработчиков, писать хаутушки и документацию.
Развивать придется скиллы программирования, писательства и иногда публичных выступлений. А еще придется много ресерчить и изучать тулы для разработчиков
Сотрудничать придется с Developer Experience, Developer Evangelism, Developer Marketing и Community
Developer Experience
Основная цель — улучшать пользовательский опыт (почти тоже самое что и UX, только для разработчиков)
Заниматься придется продуктовым дизайном и UX, документацией и тренингами, билдить SDK, плагины, расширять функциональность продукта и разговаривать с кастомерами или конечными пользователями.
Развивать нужно скиллы продуктового менеджмента, юзабилити и UX. А еще изучать разные тулы для разработчика, которые присутствуют на рынке
Community Management
Основная цель взращивать сообщество разработчиков.
Заниматься придется тем, что нужно будет строить сообщество онлайновое и оффлайновое. Организовывать и фасилитировать ивенты в сообществе, постить всякое в новостях и социальных сетях. Запускать разные программы (например Hacktoberfest)
Развивать нужно будет скиллы ивент менеджмента, знания о разработчиках, текущих трендах и так далее ну и скиллы коммуникации.
Работать придется чаще всего с Developer Advocacy и Developer Experience.
Вот такая вот отрасль. Ну и для начинающих разработчиков от них достаточно много пользы, потому как ребята, которые описаны выше генерят очень много полезного и обучающего контента.
@retired_on_fire, Андрей Минкин
— Developer Marketing
— Developer Avangelism
— Developer Advocacy
— Developer Experience
— Community Management
Developer Marketing
Мало чем отличается от традиционного цифрового маркетинга.
Основная цель — создать Go-to-developer стратегию. Почти тоже самое что и go-to-market, только для разработчиков.
Заниматься придется формированием плана коммуникации с разработчиками, координированием запуска проектов, планирование разных ивентов, спонсорств и партнерств.
Развивать придется следующие скиллы: знания о разработчиках, стеке, трендах. Умение ресерчить и писать, аналитическое и стратегическое мышление, умение планировать.
Работать придется с продуктовыми менеджерами, маркетологами в компании, Developer Evangelism.
Маркетологи, которые хотят в IT и не хотят учиться, добро пожаловать. Тут есть отдельная зона для роста для смены карьеры
Developer Evangelism
Основная цель — рассказывать о продукте.
Заниматься придется тем, что рассказывать и присуствовать на конференциях, пилить технический контент (блоги и видосы), записывать подкасты и стримить. Партнериться с разными сообществами.
Развивать придется скиллы публичных выступлений, сторителлинг, скилы писательства и нетворинга. Ну и билдить много разных демок (хотя, тут технические скиллы не очень сильно нужны чаще всего для некоторых продуктов)
Сотрудничать придется с Developer Marketing и Developer Advocacy
Developer Advocacy
Основная цель для этих ребят сделать так, чтобы разработчики пользовались продуктом компании.
Заниматься придется тем, что постоянно билдить разные демки, посещать разные конференции, также стримить. А еще разрабатывать продукт и активно продвигать идеи догфудинга продукта. Поддерживать сообщество разработчиков, писать хаутушки и документацию.
Развивать придется скиллы программирования, писательства и иногда публичных выступлений. А еще придется много ресерчить и изучать тулы для разработчиков
Сотрудничать придется с Developer Experience, Developer Evangelism, Developer Marketing и Community
Developer Experience
Основная цель — улучшать пользовательский опыт (почти тоже самое что и UX, только для разработчиков)
Заниматься придется продуктовым дизайном и UX, документацией и тренингами, билдить SDK, плагины, расширять функциональность продукта и разговаривать с кастомерами или конечными пользователями.
Развивать нужно скиллы продуктового менеджмента, юзабилити и UX. А еще изучать разные тулы для разработчика, которые присутствуют на рынке
Community Management
Основная цель взращивать сообщество разработчиков.
Заниматься придется тем, что нужно будет строить сообщество онлайновое и оффлайновое. Организовывать и фасилитировать ивенты в сообществе, постить всякое в новостях и социальных сетях. Запускать разные программы (например Hacktoberfest)
Развивать нужно будет скиллы ивент менеджмента, знания о разработчиках, текущих трендах и так далее ну и скиллы коммуникации.
Работать придется чаще всего с Developer Advocacy и Developer Experience.
Вот такая вот отрасль. Ну и для начинающих разработчиков от них достаточно много пользы, потому как ребята, которые описаны выше генерят очень много полезного и обучающего контента.
@retired_on_fire, Андрей Минкин
API design is stuck in the past
Слак красавчики. С одной стороны они сначала выкатили свою RTM API (Я с нее начинал проект Comedian для сбора стендапов внутри команды). Потом они выкатили интеграцию по веб сокетам и сейчас они выкатили Events API.
Пилить ботов стало в разы проще и дешевле. В чем минусы использования их RTM API:
— Приходится держать постоянно вебсокет подключение к слаку и слушать каналы. Это не очень хорошо с экономической точки зрения. потому что если канал не активный, то мы просто держим вебсокет соединение и просто жгем деньги впустую.
— На больших объемах нужно думать о том. как менеджить кучу вебсокет соединений и как их масштабировать по одному или нескольким сервисам.
В итоге если пилим бота, то это либо дорого, либо геморно.
Events API позволяет делать простые схемы, типа API Gateway + AWS Lambda. Ну и достаточно долго можно жить в рамках Free Tier от AWS (Вообще, очень много своих пет проектов можно хостить на облаках типа гугла или AWS просто используя их сервисы).
Напилил простого бота, для нашего сообщества в слаке, чтобы частично персонализировать онбординг процесс в нашем сообществе.
Схема работы простая. Если новый человек добавился к нам в сообщество, то слак отправляет ивент на API Gateway от AWS, тот триггерит функцию, которая обрабатывает ивент и шлёт запрос в API слака. Лениво, дешево, классно.
В последнее время пилю разные интеграции с разными сервисами и supabase нравится для некоторых проектов (очень небольших с минимальной нагрузкой). Пилю Proof of concept. Из технологий:
1. gRPC
2. gRPC Gateway для предоставления рест апи для совместимости с браузерами
3. buf.build. Это прям находка. Отлично расширяет экосистему gRPC и протокол буфферов. Этот тул решает проблему километровых простыней запуска protoc для генерации кода, документации и всего остального
Пока еще не пощупал Graphql и не особо представляю для каких задач он мне потребуется. Потому как для большинства задач хватает gRPC+Rest
А вы что для апи используете и на чем их кодите?)
@retired_on_fire, Андрей Минкин
Слак красавчики. С одной стороны они сначала выкатили свою RTM API (Я с нее начинал проект Comedian для сбора стендапов внутри команды). Потом они выкатили интеграцию по веб сокетам и сейчас они выкатили Events API.
Пилить ботов стало в разы проще и дешевле. В чем минусы использования их RTM API:
— Приходится держать постоянно вебсокет подключение к слаку и слушать каналы. Это не очень хорошо с экономической точки зрения. потому что если канал не активный, то мы просто держим вебсокет соединение и просто жгем деньги впустую.
— На больших объемах нужно думать о том. как менеджить кучу вебсокет соединений и как их масштабировать по одному или нескольким сервисам.
В итоге если пилим бота, то это либо дорого, либо геморно.
Events API позволяет делать простые схемы, типа API Gateway + AWS Lambda. Ну и достаточно долго можно жить в рамках Free Tier от AWS (Вообще, очень много своих пет проектов можно хостить на облаках типа гугла или AWS просто используя их сервисы).
Напилил простого бота, для нашего сообщества в слаке, чтобы частично персонализировать онбординг процесс в нашем сообществе.
Схема работы простая. Если новый человек добавился к нам в сообщество, то слак отправляет ивент на API Gateway от AWS, тот триггерит функцию, которая обрабатывает ивент и шлёт запрос в API слака. Лениво, дешево, классно.
В последнее время пилю разные интеграции с разными сервисами и supabase нравится для некоторых проектов (очень небольших с минимальной нагрузкой). Пилю Proof of concept. Из технологий:
1. gRPC
2. gRPC Gateway для предоставления рест апи для совместимости с браузерами
3. buf.build. Это прям находка. Отлично расширяет экосистему gRPC и протокол буфферов. Этот тул решает проблему километровых простыней запуска protoc для генерации кода, документации и всего остального
Пока еще не пощупал Graphql и не особо представляю для каких задач он мне потребуется. Потому как для большинства задач хватает gRPC+Rest
А вы что для апи используете и на чем их кодите?)
@retired_on_fire, Андрей Минкин
Slack API
Events API
The Events API is a subscription-based system that sends your app HTTP requests when interesting stuff. It replaces the Real Time Messaging API.
Почему я люблю gRPC?
REST сложен. Чтобы сделать хорошую REST API нужно хотя бы осилить OpenAPI спецификацию и весь тулинг вокруг него. Помимо этого нужно разобраться в HTTP и в методах, чтобы дизайн API был достаточно понятен и идеоматичен. Zalando даже написали целый гайд для этого.
В итоге, мы приходим к тому, что RPC стиль удобнее, ведь
-
- POST /todos может как обновлять, так и создавать задачу.
До выхода HTTP/2 было несколько вариантов делать API, но REST был куда популярнее, чем SOAP, JSONRPC, XMLRPC. Использование XML в современном мире для любых задач стоит считать жестоким обращением с людьми и карать по всей строгости УК
С выходом HTTP/2, которые частично начали вытеснять вебсокеты с рынка гугл и сделал gRPC, которые работают поверх HTTP/2 и используют protocol buffers в качестве сериализатора данных. Из очевидных плюсов:
1. Protobuf куда быстрее и меньше чем JSON. (JSON — текст, парсить его по CPU куда затратнее, чем использовать бинарные протокол буффера)
2. Protobuf со статической типизацией, что доставляет удобств в разработке
3. HTTP/2 сам по себе бинарнее и быстрее
4. Все эти преимущества понижают количество трафика гоняемого между клиентом и сервером.
Из минусов — это нет поддержки в браузерах, однако для дизайна микросервисов или для мобильных приложений это выглядит куда лучше и удобнее, чем вебсокеты.
За время использования в разных сервисах единственная проблема это балансировка HTTP/2. Равномерно разбалансировать HTTP/2 сложнее, потому что балансировать приходится на L7, а не на L4, как обычно балансируется HTTP/1. Вот в этом абзаце мог обмануть, но суть такая, что если у нас есть пул серверов на нашем балансере (nginx, ingress, istio, envoy) то HTTP/1.x можно спокойно балансировать раундробином за счет того, что не держится постоянный коннект, но если мы используем gRPC стримы, то тут постоянные подключения сложнее балансировать.
Хотя, современный веб идет в социальное дистанцирование и уменьшение рукопожатий и HTTP/3 (который основан больше на QUIC, который в свою очередь работает на UDP, а не на TCP).
Но основная проблема сейчас, что люди не умеют использовать нормально HTTP/1.1, не говоря уже о HTTP/2 но хотят использовать HTTP/3.
Вспоминается тренд скучных технологий. Ну и это одна из лучших находок за последнее время, ну кроме ада тестирования БД Оракл
@retired_on_fire, Андрей Минкин
REST сложен. Чтобы сделать хорошую REST API нужно хотя бы осилить OpenAPI спецификацию и весь тулинг вокруг него. Помимо этого нужно разобраться в HTTP и в методах, чтобы дизайн API был достаточно понятен и идеоматичен. Zalando даже написали целый гайд для этого.
В итоге, мы приходим к тому, что RPC стиль удобнее, ведь
-
CreateTodo Звучит понятнее для всех (включая джунов)- POST /todos может как обновлять, так и создавать задачу.
До выхода HTTP/2 было несколько вариантов делать API, но REST был куда популярнее, чем SOAP, JSONRPC, XMLRPC. Использование XML в современном мире для любых задач стоит считать жестоким обращением с людьми и карать по всей строгости УК
С выходом HTTP/2, которые частично начали вытеснять вебсокеты с рынка гугл и сделал gRPC, которые работают поверх HTTP/2 и используют protocol buffers в качестве сериализатора данных. Из очевидных плюсов:
1. Protobuf куда быстрее и меньше чем JSON. (JSON — текст, парсить его по CPU куда затратнее, чем использовать бинарные протокол буффера)
2. Protobuf со статической типизацией, что доставляет удобств в разработке
3. HTTP/2 сам по себе бинарнее и быстрее
4. Все эти преимущества понижают количество трафика гоняемого между клиентом и сервером.
Из минусов — это нет поддержки в браузерах, однако для дизайна микросервисов или для мобильных приложений это выглядит куда лучше и удобнее, чем вебсокеты.
За время использования в разных сервисах единственная проблема это балансировка HTTP/2. Равномерно разбалансировать HTTP/2 сложнее, потому что балансировать приходится на L7, а не на L4, как обычно балансируется HTTP/1. Вот в этом абзаце мог обмануть, но суть такая, что если у нас есть пул серверов на нашем балансере (nginx, ingress, istio, envoy) то HTTP/1.x можно спокойно балансировать раундробином за счет того, что не держится постоянный коннект, но если мы используем gRPC стримы, то тут постоянные подключения сложнее балансировать.
Хотя, современный веб идет в социальное дистанцирование и уменьшение рукопожатий и HTTP/3 (который основан больше на QUIC, который в свою очередь работает на UDP, а не на TCP).
Но основная проблема сейчас, что люди не умеют использовать нормально HTTP/1.1, не говоря уже о HTTP/2 но хотят использовать HTTP/3.
Вспоминается тренд скучных технологий. Ну и это одна из лучших находок за последнее время, ну кроме ада тестирования БД Оракл
@retired_on_fire, Андрей Минкин
Очень интересно, ничерта непонятно.
Это символ моих постов на эту неделю.
Мыркосервисы. Мыркосервисы — это не очень хорошо спроектированные микросервисы. В некоторых проектах выбор технологий вызывает вопросы. Например зачем втаскивать Кафку, или асинхронный тип коммуникации между микросервисами, если сервисов всего два или три и там можно было обойтись либо rest, либо grpc, либо любой другой синхронной API.
При проектировании любой системы очень много команд руководствуются выбором технологий, потому что они их не использовали. Всегда интересно взять что-то более интересное и трендовое и попаразитировать за счет заказчика. Вот и получается, что вместо того, чтобы подойти нормально к проектированию коммуникации между сервисами втаскиваются непонятные компоненты, которые непонятно как работают.
Проектирование микросервисов:
1. Начать пилить монолит. Монолит обычно почти всегда подходит и если мы не можем определить зоны ответственности для тех или иных сервисов
2. Подумать, какие есть ограничения при проектировании, которые ну никак не обойти (требования законодательства, требования тех или иных комплайнсов, требования инженерной культуры).
3. Где мы собираемся хостить наши сервисы. На каком провайдере и какие подходы мы будем использовать
4. Какие есть скиллы в команде
5. Ресерч стека и тулов для проекта. Выбор асинхронной или синхронной коммуникации микросервисов (очень часто используют микс в больших проектах)
6. Дизайн API и взаимодействия между сервисами. Это по крайней мере поможет распаралелить работу между отделами.
7. Чем меньше зависимостей, тем лучше.
А что добавите вы?
@retired_on_fire, Андрей Минкин
Это символ моих постов на эту неделю.
Мыркосервисы. Мыркосервисы — это не очень хорошо спроектированные микросервисы. В некоторых проектах выбор технологий вызывает вопросы. Например зачем втаскивать Кафку, или асинхронный тип коммуникации между микросервисами, если сервисов всего два или три и там можно было обойтись либо rest, либо grpc, либо любой другой синхронной API.
При проектировании любой системы очень много команд руководствуются выбором технологий, потому что они их не использовали. Всегда интересно взять что-то более интересное и трендовое и попаразитировать за счет заказчика. Вот и получается, что вместо того, чтобы подойти нормально к проектированию коммуникации между сервисами втаскиваются непонятные компоненты, которые непонятно как работают.
Проектирование микросервисов:
1. Начать пилить монолит. Монолит обычно почти всегда подходит и если мы не можем определить зоны ответственности для тех или иных сервисов
2. Подумать, какие есть ограничения при проектировании, которые ну никак не обойти (требования законодательства, требования тех или иных комплайнсов, требования инженерной культуры).
3. Где мы собираемся хостить наши сервисы. На каком провайдере и какие подходы мы будем использовать
4. Какие есть скиллы в команде
5. Ресерч стека и тулов для проекта. Выбор асинхронной или синхронной коммуникации микросервисов (очень часто используют микс в больших проектах)
6. Дизайн API и взаимодействия между сервисами. Это по крайней мере поможет распаралелить работу между отделами.
7. Чем меньше зависимостей, тем лучше.
А что добавите вы?
@retired_on_fire, Андрей Минкин
А кто вообще читает лицензионные соглашения?
(с) Кайл. Саус Парк, эпизод про человекайпадоножка
Обложился техникой эппл по-максимуму. Теперь у меня есть еще айпад с эпл карандашом. Взял айпад для того, чтобы разнообразить свой контент на ютюбе, потому что текущих инструментов не хватает и очень не хватает цифровой доски на которой можно рисовать рукой. В итоге, купив айпад (Pro на 128 гигов 2021 года), эта проблема решилась.
Из дополнительных и удобных фичей:
1. Можно использовать как дополнительный монитор (скорее всего не буду этого делать, либо буду использовать как дополнение к стримам)
2. Появилась поверхность, на которой можно рисовать. ExplainEverything предоставляет вполне удобное приложение, которое эмулирует бесконечную доску
Наконец-то добил доклад на тему Аутентификация и автооризация 101, или что вас ждет с ростом сложности проекта и хотелок бизнеса. Доклад сделан как история про приключения проекта и когда нужно использовать ту или иную технологию. Доклад обзорный, получился веселым, в докладе рассматриваются:
1. Аутентификация и факторы аутентификации. OTP/TOTP и еще много разных вещей для реализации многофактороной аутентификации
2. Аутентификация без пароля. аутентификация по токенам, в чем разница токенов и сессий
3. Почему логин через социальные сети не заменяет аутентификацию полного цикла
4. Контроль доступа с разбором RBAC/ABAC
5. Zero Trust/Federation
Хочу рассказать на тестовую аудиторию в оффлайне и кому это будет интересно — пишите в личку и приглашайте. Формат гостевой лекции канает.
Еще из дополнительных девайсов жду микрофон со звуковой картой. Микрофон взял Shure SM7B и к нему звуковую карту. Думаю уйти от стримов в сторону генерации контента и монтирования его. Благо, что сейчас в эпловой экосистеме это получится сделать вполне себе просто. Пока еще не решил что использовать для монтажа видосов: Premiere или Final Cut.
@retired_on_fire, Андрей Минкин
(с) Кайл. Саус Парк, эпизод про человекайпадоножка
Обложился техникой эппл по-максимуму. Теперь у меня есть еще айпад с эпл карандашом. Взял айпад для того, чтобы разнообразить свой контент на ютюбе, потому что текущих инструментов не хватает и очень не хватает цифровой доски на которой можно рисовать рукой. В итоге, купив айпад (Pro на 128 гигов 2021 года), эта проблема решилась.
Из дополнительных и удобных фичей:
1. Можно использовать как дополнительный монитор (скорее всего не буду этого делать, либо буду использовать как дополнение к стримам)
2. Появилась поверхность, на которой можно рисовать. ExplainEverything предоставляет вполне удобное приложение, которое эмулирует бесконечную доску
Наконец-то добил доклад на тему Аутентификация и автооризация 101, или что вас ждет с ростом сложности проекта и хотелок бизнеса. Доклад сделан как история про приключения проекта и когда нужно использовать ту или иную технологию. Доклад обзорный, получился веселым, в докладе рассматриваются:
1. Аутентификация и факторы аутентификации. OTP/TOTP и еще много разных вещей для реализации многофактороной аутентификации
2. Аутентификация без пароля. аутентификация по токенам, в чем разница токенов и сессий
3. Почему логин через социальные сети не заменяет аутентификацию полного цикла
4. Контроль доступа с разбором RBAC/ABAC
5. Zero Trust/Federation
Хочу рассказать на тестовую аудиторию в оффлайне и кому это будет интересно — пишите в личку и приглашайте. Формат гостевой лекции канает.
Еще из дополнительных девайсов жду микрофон со звуковой картой. Микрофон взял Shure SM7B и к нему звуковую карту. Думаю уйти от стримов в сторону генерации контента и монтирования его. Благо, что сейчас в эпловой экосистеме это получится сделать вполне себе просто. Пока еще не решил что использовать для монтажа видосов: Premiere или Final Cut.
@retired_on_fire, Андрей Минкин
Shure
SM7B - Vocal Microphone - Shure USA
The Shure SM7B is the iconic dynamic vocal microphone you've already heard. It is perfect for professional podcasters, streamers, and vocalists alike.
Муки выбора.
Муки выбора они есть всегда. Особенно когда ты платишь за это своими деньгами. Вчера полдня полазил на стоках чтобы найти нормальный саундтрек для своих видосов. В итоге выбор пал на две композиции:
1. The fall of man в жанре мелодик дез метал. Звучит немного безлико и это прям совсем не бенгер, но можно использовать как нейтральную заглушку
2. Frostbite в хз каком жанре, но звучит интереснее и на мой взгляд жирнее.
Обе композиции хороши тем, что они Royalty free и стоят порядка 20 баксов для использования в своих целях. Это хорошо, потому что покупаешь и используешь для подкастов и прочего контента. Но обе подойдут для джинга или заставки. Ну или в титры можно поставить. В стримах можно использовать их как какой-то эффект.
Пока еще не понятно в каком жанре делать фоновую заглушку для видосов. Фоновая музыка нужна и для атмосферы и для того, чтобы когда я молчал или тупил люди не думали, что у них что-то сломалось и не отвлекались. Так что фоновая музыка нужна, но я пока еще ищу ее и гоняю по стокам.
Кстати, о стоках. Для музыки я нашел варианты типа ютюба или audiojungle. Буду рад рекомендациям стоков для видео эффектов.
PS. Спасибо за рекомендацию Davinci Resolve. Выглядит круто и интересно. Попробую что-нибудь родить в течение нескольких ближайших недель.
@retired_on_fire, Андрей Минкин
Муки выбора они есть всегда. Особенно когда ты платишь за это своими деньгами. Вчера полдня полазил на стоках чтобы найти нормальный саундтрек для своих видосов. В итоге выбор пал на две композиции:
1. The fall of man в жанре мелодик дез метал. Звучит немного безлико и это прям совсем не бенгер, но можно использовать как нейтральную заглушку
2. Frostbite в хз каком жанре, но звучит интереснее и на мой взгляд жирнее.
Обе композиции хороши тем, что они Royalty free и стоят порядка 20 баксов для использования в своих целях. Это хорошо, потому что покупаешь и используешь для подкастов и прочего контента. Но обе подойдут для джинга или заставки. Ну или в титры можно поставить. В стримах можно использовать их как какой-то эффект.
Пока еще не понятно в каком жанре делать фоновую заглушку для видосов. Фоновая музыка нужна и для атмосферы и для того, чтобы когда я молчал или тупил люди не думали, что у них что-то сломалось и не отвлекались. Так что фоновая музыка нужна, но я пока еще ищу ее и гоняю по стокам.
Кстати, о стоках. Для музыки я нашел варианты типа ютюба или audiojungle. Буду рад рекомендациям стоков для видео эффектов.
PS. Спасибо за рекомендацию Davinci Resolve. Выглядит круто и интересно. Попробую что-нибудь родить в течение нескольких ближайших недель.
@retired_on_fire, Андрей Минкин
YouTube
Royalty Free Melodic Death Metal Instrumental - THE FALL OF MAN - DOWNLOAD
Purchase the royalty free track here: https://www.darkcabin-studios.com/shop
Linktree: https://linktr.ee/thrasher726
You can purchase my song and use it in any way you want without any legal trouble. Use it as background music in your advertisements, I…
Linktree: https://linktr.ee/thrasher726
You can purchase my song and use it in any way you want without any legal trouble. Use it as background music in your advertisements, I…
Люблю дудки, люблю бас, люблю я долю слабую
Ебашу как в последний раз, а остальное похую!
(c) Пневмослон
В условиях маленьких команд, которые разношерстны сами по себе работа может быть адом. Особенно, если начальство не в курсе за адекватный менеджмент сам по себе. При этом, я не говорю еще за ворклайф баланс а больше за интересные кейсы, когда разработчика могут штрафануть на ровном месте просто так. Например, если работал из дома.
Таких компаний у нас полно, начиная от офиса в Сиерре, заканчивая чем-то около большим, где даже есть свой офис, в который даже ходят люди, но особо не представляют как строить процессы разработки.
В хорошей команде разработки, на мой взгляд должны быть следующие вещи:
1. Knowledge management. Документация должна писаться и поддерживаться. Если этот процесс есть, то уже хорошо. Если нет, то можно без него, но по крайней мере должны быть описаны основные договоренности по коммуникации между сотрудниками: больничные, когда мы созваниваемся, как ревьюим код, как вообще пишем код и какими стайлгайдами пользуемся, архитектура (это один из важных пунктов в проектах)
2. Запрещено коммитить в основную ветку напрямую
3. Есть настроенный CI/CD, что подразумевает написание тестов. Я сейчас вообще не представляю как можно что-то выкатывать в прод без хорошего тестирования.
4. У разработчиков нет доступа к проду и к данным. Это хорошо в больших компаниях, но не когда вы стартап вам к этому нужно стремиться
5. Schema First дизайн. Это когда мы сначала договариваемся о коммуникации между сервисами (если у вас раздельно работает бекенд и фронтенд)
Как менять, если нет процессов и вы рядовой разработчик? Чаще всего никак и проще найти компанию, где дела обстоят лучше и подготовить к ряд вопросов на интервью для компании. В Большинстве случаев, когда молодой и амбициозный разработчик начинает предлагать инициативы, то они очень часто блокируются из-за недалекого менеджмента.
Если же вы тимлид или менеджер, то нужно начать хотя бы с описания договоренностей внутри команды и прикрепить их в папочку ридми, но обязательно, чтобы вся команда прочитала и согласилась с тем, что написано в документе. А дальше использовать стратегию Quick win, что в кратце говорит за себя. Мы берем пункт выше и начинаем малой кровью делать изменения.
@retired_on_fire, Андрей Минкин
Ебашу как в последний раз, а остальное похую!
(c) Пневмослон
В условиях маленьких команд, которые разношерстны сами по себе работа может быть адом. Особенно, если начальство не в курсе за адекватный менеджмент сам по себе. При этом, я не говорю еще за ворклайф баланс а больше за интересные кейсы, когда разработчика могут штрафануть на ровном месте просто так. Например, если работал из дома.
Таких компаний у нас полно, начиная от офиса в Сиерре, заканчивая чем-то около большим, где даже есть свой офис, в который даже ходят люди, но особо не представляют как строить процессы разработки.
В хорошей команде разработки, на мой взгляд должны быть следующие вещи:
1. Knowledge management. Документация должна писаться и поддерживаться. Если этот процесс есть, то уже хорошо. Если нет, то можно без него, но по крайней мере должны быть описаны основные договоренности по коммуникации между сотрудниками: больничные, когда мы созваниваемся, как ревьюим код, как вообще пишем код и какими стайлгайдами пользуемся, архитектура (это один из важных пунктов в проектах)
2. Запрещено коммитить в основную ветку напрямую
3. Есть настроенный CI/CD, что подразумевает написание тестов. Я сейчас вообще не представляю как можно что-то выкатывать в прод без хорошего тестирования.
4. У разработчиков нет доступа к проду и к данным. Это хорошо в больших компаниях, но не когда вы стартап вам к этому нужно стремиться
5. Schema First дизайн. Это когда мы сначала договариваемся о коммуникации между сервисами (если у вас раздельно работает бекенд и фронтенд)
Как менять, если нет процессов и вы рядовой разработчик? Чаще всего никак и проще найти компанию, где дела обстоят лучше и подготовить к ряд вопросов на интервью для компании. В Большинстве случаев, когда молодой и амбициозный разработчик начинает предлагать инициативы, то они очень часто блокируются из-за недалекого менеджмента.
Если же вы тимлид или менеджер, то нужно начать хотя бы с описания договоренностей внутри команды и прикрепить их в папочку ридми, но обязательно, чтобы вся команда прочитала и согласилась с тем, что написано в документе. А дальше использовать стратегию Quick win, что в кратце говорит за себя. Мы берем пункт выше и начинаем малой кровью делать изменения.
@retired_on_fire, Андрей Минкин
Ебашу как в последний раз, а остальное похую
(с) Пневмослон
В продолжение предыдущего поста. К чему вообще всё приведет, если в команде нет процессов и прописанных и проговоренных договоренностей? Если кратко — к выгоранию, если вовремя не уйти из компании, либо не исправить ситуацию.
А полный список выглядит примерно так
1. Ок, не пишем документацию, фиг с ним, будем жить без нее
2. В принципе можно и тесты не писать, всё равно у нас тут говна самовар
3. Да в целом я не вижу смысла развиваться, поэтому пока посмотрю котиков на ютюбе
4. А смысл что-то предлагать, если всё равно зарубят?
В итоге, на текущем рабочем месте нет интереса, нет развития и всё ведет к стагнации и дело еще ухудшает нарушения трудовых договоренностей и это иногда распространено в “стартапах”. Справедливости ради скажу, что “стартапы” тут взяты в ковычки, потому что сейчас любую новую компанию на рынке называют стартапом. Но давайте будем реалистами, если вы делаете шавуху и продаете ее с доставкой через намбафуд, то вы не стартап, даже если каждую шавуху вы будете продавать через крипту, даже если вы придумаете новую и крутую упаковку, то максимум на что вы можете тянуть — это на “креативную экономику”. Хотя тоже сомнительно.
Стартап — это в первую очередь поиск устойчивой и масштабируемой бизнес модели. Если вы делаете конфеты или шавуху — это уже традиционный бизнес. Если вы решили сделать компанию, которая занимается дропшипингом — это традиционный бизнес. Там уже всё понятно.
Я не против работы в стартапе и сейчас работаю в стартапе. Да, мы сейчас ищем устойчивую и масштабируемую бизнес модель и у нас есть два источника, как я вижу сейчас:
— Поддержка больших компаний с понятными SLA и SLO
— Предоставление Managed сервисов, но тут еще есть множестов непонятных вещей, потому что модель монетизации еще тестируется и строятся внутри ряд гипотез.
Так вот, есть просто некомпетентная команда менеджмента, очень печально, если она не слушает обратную связь от сотрудников. А сотрудники часто ее и не будут давать, потому что они уже не верят ей.
Поэтому, если вы понимаете, что вы перестали доверять своей команде — пора либо прояснять, либо уходить. Все остальные случаи ведут к стагнации, деградированию, нарушению баланса
@retired_on_fire, Андрей Минкин
(с) Пневмослон
В продолжение предыдущего поста. К чему вообще всё приведет, если в команде нет процессов и прописанных и проговоренных договоренностей? Если кратко — к выгоранию, если вовремя не уйти из компании, либо не исправить ситуацию.
А полный список выглядит примерно так
1. Ок, не пишем документацию, фиг с ним, будем жить без нее
2. В принципе можно и тесты не писать, всё равно у нас тут говна самовар
3. Да в целом я не вижу смысла развиваться, поэтому пока посмотрю котиков на ютюбе
4. А смысл что-то предлагать, если всё равно зарубят?
В итоге, на текущем рабочем месте нет интереса, нет развития и всё ведет к стагнации и дело еще ухудшает нарушения трудовых договоренностей и это иногда распространено в “стартапах”. Справедливости ради скажу, что “стартапы” тут взяты в ковычки, потому что сейчас любую новую компанию на рынке называют стартапом. Но давайте будем реалистами, если вы делаете шавуху и продаете ее с доставкой через намбафуд, то вы не стартап, даже если каждую шавуху вы будете продавать через крипту, даже если вы придумаете новую и крутую упаковку, то максимум на что вы можете тянуть — это на “креативную экономику”. Хотя тоже сомнительно.
Стартап — это в первую очередь поиск устойчивой и масштабируемой бизнес модели. Если вы делаете конфеты или шавуху — это уже традиционный бизнес. Если вы решили сделать компанию, которая занимается дропшипингом — это традиционный бизнес. Там уже всё понятно.
Я не против работы в стартапе и сейчас работаю в стартапе. Да, мы сейчас ищем устойчивую и масштабируемую бизнес модель и у нас есть два источника, как я вижу сейчас:
— Поддержка больших компаний с понятными SLA и SLO
— Предоставление Managed сервисов, но тут еще есть множестов непонятных вещей, потому что модель монетизации еще тестируется и строятся внутри ряд гипотез.
Так вот, есть просто некомпетентная команда менеджмента, очень печально, если она не слушает обратную связь от сотрудников. А сотрудники часто ее и не будут давать, потому что они уже не верят ей.
Поэтому, если вы понимаете, что вы перестали доверять своей команде — пора либо прояснять, либо уходить. Все остальные случаи ведут к стагнации, деградированию, нарушению баланса
@retired_on_fire, Андрей Минкин
Изменения наступают естественно, без усилий, если есть обратная связь и поступает качественная информация.
(с) Джон Уитмор, “Внутренняя сила лидера”
Найти менеджера, который бы мог выдавать фидбек в качественной и конструктивной форме на територии СНГ достаточно сложно. В моем окружении они есть, но общаясь с другими разработчиками понимаю, что в целом по СНГ есть с этим проблемы. В европейской культуре этого я пока не замечал, но видимо еще мало работал и мой опыт пока не репрезентативен.
Недавно услышал интересное сравнение между европейской и СНГшной культурой общения. В европейской культуре ответственность за донесение информации лежит на говорящем. В СНГшной на слушателе. Не помню с кем было это интервью и у кого я смотрел на канале, но сейчас замечаю это по своей работе и отрефлексировав последний год работы.
Мне джуны иногда задают вопросы по тому, как пройти интервью и как понять фидбек, который они получили от работодателя. Работодатели обычно не выдают нормальный и хороший фидбек в большинстве случаев и он часто говорит о том, что “мы бы сделали по-другому”. Нет ни развивающей обратной связи ни чего другого, чтобы можно было бы использовать для своего развития.
По опыту я тепло отношусь к Яндексу, хоть я не прошел интервью к ним в 201х году, потому что нанимающие меня чуваки выдали хорошую развивающую обратную связь. Я сразу понял, что мне нужно прокачивать по навыкам, чтобы получить оффер от них.
К большинству криптостартапам я отношусь примерно также, как в этом отрывке South Park, однако, есть один, который мне понравился, потому что люди умеют нанимать людей.
По Европе за последние пять лет очень часто не выдают фидбек, но есть один лайфхак — это воспользоваться GDPR. По закону любая компания обязана предоставить все данные по вам, которые они собрали и это хорошо. По-крайней мере можно сделать так, как написано в этом треде
Так вот, пост это больше про то, чтобы нанимающие менеджеры всё-таки делали заметки и выдавали хорошую обратную связь для кандидата. Это имеет следующие бенефиты:
1. Повышается лояльность к компании
2. Компанию соискатель будет рекомендовать своим друзьям, даже если ему отказали
3. Это в целом говорит о хороших процессах внутри компании
А для менеджеров есть один маленький совет, что любые изменения начинаются не тогда, когда мы хотим куда-то придти, а с понимания, где мы есть сейчас. Поэтому, иногда важно делать рефлексию. Такие дела
@retired_on_fire, Андрей Минкин
(с) Джон Уитмор, “Внутренняя сила лидера”
Найти менеджера, который бы мог выдавать фидбек в качественной и конструктивной форме на територии СНГ достаточно сложно. В моем окружении они есть, но общаясь с другими разработчиками понимаю, что в целом по СНГ есть с этим проблемы. В европейской культуре этого я пока не замечал, но видимо еще мало работал и мой опыт пока не репрезентативен.
Недавно услышал интересное сравнение между европейской и СНГшной культурой общения. В европейской культуре ответственность за донесение информации лежит на говорящем. В СНГшной на слушателе. Не помню с кем было это интервью и у кого я смотрел на канале, но сейчас замечаю это по своей работе и отрефлексировав последний год работы.
Мне джуны иногда задают вопросы по тому, как пройти интервью и как понять фидбек, который они получили от работодателя. Работодатели обычно не выдают нормальный и хороший фидбек в большинстве случаев и он часто говорит о том, что “мы бы сделали по-другому”. Нет ни развивающей обратной связи ни чего другого, чтобы можно было бы использовать для своего развития.
По опыту я тепло отношусь к Яндексу, хоть я не прошел интервью к ним в 201х году, потому что нанимающие меня чуваки выдали хорошую развивающую обратную связь. Я сразу понял, что мне нужно прокачивать по навыкам, чтобы получить оффер от них.
К большинству криптостартапам я отношусь примерно также, как в этом отрывке South Park, однако, есть один, который мне понравился, потому что люди умеют нанимать людей.
По Европе за последние пять лет очень часто не выдают фидбек, но есть один лайфхак — это воспользоваться GDPR. По закону любая компания обязана предоставить все данные по вам, которые они собрали и это хорошо. По-крайней мере можно сделать так, как написано в этом треде
Так вот, пост это больше про то, чтобы нанимающие менеджеры всё-таки делали заметки и выдавали хорошую обратную связь для кандидата. Это имеет следующие бенефиты:
1. Повышается лояльность к компании
2. Компанию соискатель будет рекомендовать своим друзьям, даже если ему отказали
3. Это в целом говорит о хороших процессах внутри компании
А для менеджеров есть один маленький совет, что любые изменения начинаются не тогда, когда мы хотим куда-то придти, а с понимания, где мы есть сейчас. Поэтому, иногда важно делать рефлексию. Такие дела
@retired_on_fire, Андрей Минкин
YouTube
Adult Butters Sells NFTs to Stan and Kyle (South Park POST COVID - Part 2)
Adult Butters tries to sell NFTs to stan and kyle
from South Park POST COVID - Part 2, streaming on Paramount+. Start your free 30-day trial with coupon code SOUTHPARK at checkout: https://cart.mn/paramountplus
from South Park POST COVID - Part 2, streaming on Paramount+. Start your free 30-day trial with coupon code SOUTHPARK at checkout: https://cart.mn/paramountplus
На море на океане есть остров, на том острове дуб стоит, под дубом сундук зарыт, в сундуке — заяц, в зайце — утка, в утке — яйцо, в яйце — игла, — смерть Кощея
Вот с технологиями примерно тоже самое. Есть сервис, который сделан с помощью другого сервиса, который сделан с помощью другого сервиса, который в свою очередь использует еще один сервис. Как в стандартной байке, что любая сложная задача в программировании решается добавлением еще одного уровня абстракции.
На прошлой неделе активно ковырял опенсорсные проекты.
1. Kong Gateway. Это API Gateway, который работает на OpenResty, который в свою очередь работает поверх Nginx. Написан на куче Lua кода. В целом его можно использовать, если всё достаточно оптимизировать, но это добавляет еще один уровень абстракции и еще одну зависимость.
2. Ory Oathkeeper. Это тоже еще один реверс прокси сервер, но который умеет проверять аутентификацию. Если его поставить перед всеми незащищенными сервисами и написать пару правил по доступу, то можно не кодить аутентификационные механизмы внутри микросервисов, потому что эту задачу он решит сам за себя
3. Emissary. API Gateway для кубернетиса, который сделан поверх Envoy. Блин, я всё еще не дошел до энвоя, но когда-нибудь дойду обязательно и сравню его с nginx.
Сделал простой пример бекенда на Kong+Oathkeeper+Kratos для того, чтобы получить Hello World Rest API с аутентификацией пользователя по кукам. Может поможет кому-то при построении архитектуры.
@retired_on_fire, Андрей Минкин
Вот с технологиями примерно тоже самое. Есть сервис, который сделан с помощью другого сервиса, который сделан с помощью другого сервиса, который в свою очередь использует еще один сервис. Как в стандартной байке, что любая сложная задача в программировании решается добавлением еще одного уровня абстракции.
На прошлой неделе активно ковырял опенсорсные проекты.
1. Kong Gateway. Это API Gateway, который работает на OpenResty, который в свою очередь работает поверх Nginx. Написан на куче Lua кода. В целом его можно использовать, если всё достаточно оптимизировать, но это добавляет еще один уровень абстракции и еще одну зависимость.
2. Ory Oathkeeper. Это тоже еще один реверс прокси сервер, но который умеет проверять аутентификацию. Если его поставить перед всеми незащищенными сервисами и написать пару правил по доступу, то можно не кодить аутентификационные механизмы внутри микросервисов, потому что эту задачу он решит сам за себя
3. Emissary. API Gateway для кубернетиса, который сделан поверх Envoy. Блин, я всё еще не дошел до энвоя, но когда-нибудь дойду обязательно и сравню его с nginx.
Сделал простой пример бекенда на Kong+Oathkeeper+Kratos для того, чтобы получить Hello World Rest API с аутентификацией пользователя по кукам. Может поможет кому-то при построении архитектуры.
@retired_on_fire, Андрей Минкин
GitHub
GitHub - Kong/kong: 🦍 The Cloud-Native API Gateway and AI Gateway.
🦍 The Cloud-Native API Gateway and AI Gateway. Contribute to Kong/kong development by creating an account on GitHub.
А царь то ненастоящий! (с) Иван Васильевич меняет профессию.
Программисты и прочие ойтишнеги подвержены синдрому самозванца. Синдром самозванца (англ. Impostor (imposter) syndrome) — психологическое явление (синдром), при котором человек не способен приписать свои достижения собственным качествам, способностям и усилиям. И в последнее время большинство вопросов связаны именно с этой темой. А еще с темой “Где взять мотивацию на постоянное развитие”.
Вообще, эти две темы звучат как хороший запрос к психотерапевту на беседу. Под этим часто скрываются проблемы с самооценкой или с тем, что выставлены неверные ориентиры. Один чувак на прошлом митапе задал вопрос: “Вот я смотрю на код другого человека и потом смотрю на свой и вижу, что мой код ужасен”, а потом переросло в том, что “как бороться с синдромом самозванца”
Вообще, спасибо нашему воспитанию, потому что мы часто сравниваем себя с идеалами. Идеальные мужчины, идеальные женщины (спасибо семье за это), идеальные тимлиды, идеальные продажники, идеальные *вставьте сюда свой вариант*. В своей оценке мы не можем дотянуть до идеала, который сами же придумали. Смотря какой-то код или читая какой-то блог мы часто видим уже результаты большого и сложного пути, который мы не знаем.
Или прокастинация и это “где найти время на обучение, я не могу себя заставить, как мне научиться хотеть себя заставлять?” ну и подобные вопросы. Обычно, я отвечаю на вопросы мотивации в лебедевской манере: “Никак. Оставайтесь там где сейчас”.
Основная вещь, что сравнения идут не с теми людьми. Да, конечно можно использовать какие-то ориентиры, но вы не тот человек, с которым вы себя сравниваете. Вот например, у меня был пример программиста, на которого нужно равнятся. Это Брэд Фитцпатрик. Это человек, который написал memcached, gearman, livejournal и был одним из кор контрибуторов в языке Go. У нас с ним разный путь. У него лучше образование, чем у меня, он работал с другими людьми и в других компаниях. Мне его не догнать. Да и зачем? Да, кого-то всегда будут ставить в пример, но единственный человек с кем стоит себя сравнивать — это вы же сами в прошлом
Не пытайтесь быть идеальным кем-то там, вы всё равно не станете, потому что всегда есть человек, который делает что-то лучше. Да и чаще задавайте вопрос себе, а чего хотите лично вы?
В заключение, есть парадоксальная теория изменений, которая говорит, что изменения начинаются тогда, когда вы знаете, где вы сейчас, а не куда вы хотите придти.
@retired_on_fire, Андрей Минкин
Программисты и прочие ойтишнеги подвержены синдрому самозванца. Синдром самозванца (англ. Impostor (imposter) syndrome) — психологическое явление (синдром), при котором человек не способен приписать свои достижения собственным качествам, способностям и усилиям. И в последнее время большинство вопросов связаны именно с этой темой. А еще с темой “Где взять мотивацию на постоянное развитие”.
Вообще, эти две темы звучат как хороший запрос к психотерапевту на беседу. Под этим часто скрываются проблемы с самооценкой или с тем, что выставлены неверные ориентиры. Один чувак на прошлом митапе задал вопрос: “Вот я смотрю на код другого человека и потом смотрю на свой и вижу, что мой код ужасен”, а потом переросло в том, что “как бороться с синдромом самозванца”
Вообще, спасибо нашему воспитанию, потому что мы часто сравниваем себя с идеалами. Идеальные мужчины, идеальные женщины (спасибо семье за это), идеальные тимлиды, идеальные продажники, идеальные *вставьте сюда свой вариант*. В своей оценке мы не можем дотянуть до идеала, который сами же придумали. Смотря какой-то код или читая какой-то блог мы часто видим уже результаты большого и сложного пути, который мы не знаем.
Или прокастинация и это “где найти время на обучение, я не могу себя заставить, как мне научиться хотеть себя заставлять?” ну и подобные вопросы. Обычно, я отвечаю на вопросы мотивации в лебедевской манере: “Никак. Оставайтесь там где сейчас”.
Основная вещь, что сравнения идут не с теми людьми. Да, конечно можно использовать какие-то ориентиры, но вы не тот человек, с которым вы себя сравниваете. Вот например, у меня был пример программиста, на которого нужно равнятся. Это Брэд Фитцпатрик. Это человек, который написал memcached, gearman, livejournal и был одним из кор контрибуторов в языке Go. У нас с ним разный путь. У него лучше образование, чем у меня, он работал с другими людьми и в других компаниях. Мне его не догнать. Да и зачем? Да, кого-то всегда будут ставить в пример, но единственный человек с кем стоит себя сравнивать — это вы же сами в прошлом
Не пытайтесь быть идеальным кем-то там, вы всё равно не станете, потому что всегда есть человек, который делает что-то лучше. Да и чаще задавайте вопрос себе, а чего хотите лично вы?
В заключение, есть парадоксальная теория изменений, которая говорит, что изменения начинаются тогда, когда вы знаете, где вы сейчас, а не куда вы хотите придти.
@retired_on_fire, Андрей Минкин
Describe a team experience you found disappointing. What would you have done differently to prevent this?
(с) Любое программерское интервью.
С подготовкой к интервью обычно всё просто. если мы говорим про техническую часть. Поведенческое интервью (на английском behavioral) проходить иногда сложнее и у некоторых могут возникнуть сложности с тем, чтобы придумать ответ на этот вопрос.
Есть хороший видос от jeff H Sipe, который рассказывает про STAR метод, который включает в себя
Situation. Описание ситуации, в которой вы были и что вы решали. Тут важно, что описание должно быть конкретным и понятным.
Task. Какая была цель над которой вы работали?
Action. Какие дейсвия вы предпринимали
Result. К какому результату пришли
Ну и список ситуаций, которые можно обсуждать по этому фреймворку
— Отсутсвие инженерной культуры
— Люди не писали тесты
— Корп культура не позволяла говорить открыто
— были проблемы с доверием внутри команды и это влияло на перформанс общей команды (см пять пороков команды от Ленсиони)
— Не было поддержки новых идей по стеку или подходам к разработке
— Не писалась документация
— Было много созвонов, что влияло на рабочий климат в команде, хотя можно было заменить на обычный емейл
— Не было понятного фреймворка для разрешения рабочих конфликтов
— Не было понятного и девелопер френдли код ревью
— Не было код ревью в принципе
— Не было сиай сиди для поставки в прод
— Были сложные процессы поставки кода в прод с кучей бюрократии
— Было много техдолга и не уделялось время на его закрытие
— Не транслировалось понимание бизнесовой проблемы, которую нужно было решить и была излишняя технократия в проекте
— Не было развивающей обратной связи
— Не было постоянных 1-1 раз в месяц
— Не было карьерных 1-1
— Не уделялось достаточно времени на сбор требований перед оценкой проекта при оценке проекта
— Тимлид выгорел,потому что овертаймил и не было культуры ворклайф баланса
— Перед релизом ушел чувак и мы обосрались со сроками
А какую ситуацию добавите вы сами?
@retired_on_fire, Андрей Минкин
(с) Любое программерское интервью.
С подготовкой к интервью обычно всё просто. если мы говорим про техническую часть. Поведенческое интервью (на английском behavioral) проходить иногда сложнее и у некоторых могут возникнуть сложности с тем, чтобы придумать ответ на этот вопрос.
Есть хороший видос от jeff H Sipe, который рассказывает про STAR метод, который включает в себя
Situation. Описание ситуации, в которой вы были и что вы решали. Тут важно, что описание должно быть конкретным и понятным.
Task. Какая была цель над которой вы работали?
Action. Какие дейсвия вы предпринимали
Result. К какому результату пришли
Ну и список ситуаций, которые можно обсуждать по этому фреймворку
— Отсутсвие инженерной культуры
— Люди не писали тесты
— Корп культура не позволяла говорить открыто
— были проблемы с доверием внутри команды и это влияло на перформанс общей команды (см пять пороков команды от Ленсиони)
— Не было поддержки новых идей по стеку или подходам к разработке
— Не писалась документация
— Было много созвонов, что влияло на рабочий климат в команде, хотя можно было заменить на обычный емейл
— Не было понятного фреймворка для разрешения рабочих конфликтов
— Не было понятного и девелопер френдли код ревью
— Не было код ревью в принципе
— Не было сиай сиди для поставки в прод
— Были сложные процессы поставки кода в прод с кучей бюрократии
— Было много техдолга и не уделялось время на его закрытие
— Не транслировалось понимание бизнесовой проблемы, которую нужно было решить и была излишняя технократия в проекте
— Не было развивающей обратной связи
— Не было постоянных 1-1 раз в месяц
— Не было карьерных 1-1
— Не уделялось достаточно времени на сбор требований перед оценкой проекта при оценке проекта
— Тимлид выгорел,потому что овертаймил и не было культуры ворклайф баланса
— Перед релизом ушел чувак и мы обосрались со сроками
А какую ситуацию добавите вы сами?
@retired_on_fire, Андрей Минкин
YouTube
How To Answer Behavioral Interview Questions
How To Answer Behavioral Interview Questions
Original Content Videos Every Monday / Live Sessions Every Tuesday at 9am Pacific Time U.S.
Check out our Practice Interviews AI Tool -
https://app.practiceinterviews.com/
1:1 Coaching Services (Practice interview…
Original Content Videos Every Monday / Live Sessions Every Tuesday at 9am Pacific Time U.S.
Check out our Practice Interviews AI Tool -
https://app.practiceinterviews.com/
1:1 Coaching Services (Practice interview…
Никто не любит пианистов, все любят барабанщиков!
За последние семь дней было три выступления: в IT-Run, в КГЮА и в аттракторе напишу пару мыслей по этим выступлениям.
IT-RUN
Много прикольных и молодых ребят, которые задают обычные вопросы, на которые я пока еще не устал отвечать. Как устану — напилю пару бложиков и буду кидаться ссылками. Организация мероприятия была приятной, пришел заранее, посидел чуть чуть, ребята не опоздали и пришли тоже вовремя. Побеседовали и разошлись. Даже за выступление заплатили. Наконец-то я пришел к тому, что за выступления платят, хотя в обычную рутину переговоров добавился один вопрос: “Чем платите?”. В итоге, заплатили чуть чуть денег, дали кружку (Она прикольная, кстати. Спасибо большое).
В основном ребята интересовались карьерой и их интересуют всего два вопроса:
— Куда развиваться дальше после курсов
— Как найти первую работу
И я не очень люблю отвечать на эти вопросы, потому что когда я начинал мир был другим, а развиваться можно вообще в любое направление.
Attractor
Люблю обкатать свои доклады в Аттракторе. Он рядом с домом, там работают ребята, с кем мы сотрудничали или даже бухали вместе. Обкатал свой доклад Identity 101 и вышел со следующими выводами
1. Нужно высыпаться (спасибо, кэп). Так сложилось, что я поспал всего 3 часа в этот день, потому что “А давай зайду и сделаю пару квестиков на часик в WoW The Burning Crusade”. В итоге, мы зачистили пару данжей с ребятами на Firemaw реалме и я апнул аж целый уровень.
2. Нужно применять Zero Knowledge паттерн с некоторыми оговорками. В докладе нашел 4 места, где повествование обрывается. Ну и по структуре доклада он получился слабый. Не выходит рассказывать интересно с мемчиками, шутками на серьезные темы.
3. Говорить целую пару (час двадцать) сложно. Под конец доклада я уже сам думал, когда же он закончится.
Доклад нужно будет отправить на переделку и через пару недель думаю будет следующая итерация доклада, только нужно будет чуть чуть добавить интересных историй. Может быть даже за микросервисы получится поговорить.
До понедельника!
@retired_on_fire, Андрей Минкин
За последние семь дней было три выступления: в IT-Run, в КГЮА и в аттракторе напишу пару мыслей по этим выступлениям.
IT-RUN
Много прикольных и молодых ребят, которые задают обычные вопросы, на которые я пока еще не устал отвечать. Как устану — напилю пару бложиков и буду кидаться ссылками. Организация мероприятия была приятной, пришел заранее, посидел чуть чуть, ребята не опоздали и пришли тоже вовремя. Побеседовали и разошлись. Даже за выступление заплатили. Наконец-то я пришел к тому, что за выступления платят, хотя в обычную рутину переговоров добавился один вопрос: “Чем платите?”. В итоге, заплатили чуть чуть денег, дали кружку (Она прикольная, кстати. Спасибо большое).
В основном ребята интересовались карьерой и их интересуют всего два вопроса:
— Куда развиваться дальше после курсов
— Как найти первую работу
И я не очень люблю отвечать на эти вопросы, потому что когда я начинал мир был другим, а развиваться можно вообще в любое направление.
Attractor
Люблю обкатать свои доклады в Аттракторе. Он рядом с домом, там работают ребята, с кем мы сотрудничали или даже бухали вместе. Обкатал свой доклад Identity 101 и вышел со следующими выводами
1. Нужно высыпаться (спасибо, кэп). Так сложилось, что я поспал всего 3 часа в этот день, потому что “А давай зайду и сделаю пару квестиков на часик в WoW The Burning Crusade”. В итоге, мы зачистили пару данжей с ребятами на Firemaw реалме и я апнул аж целый уровень.
2. Нужно применять Zero Knowledge паттерн с некоторыми оговорками. В докладе нашел 4 места, где повествование обрывается. Ну и по структуре доклада он получился слабый. Не выходит рассказывать интересно с мемчиками, шутками на серьезные темы.
3. Говорить целую пару (час двадцать) сложно. Под конец доклада я уже сам думал, когда же он закончится.
Доклад нужно будет отправить на переделку и через пару недель думаю будет следующая итерация доклада, только нужно будет чуть чуть добавить интересных историй. Может быть даже за микросервисы получится поговорить.
До понедельника!
@retired_on_fire, Андрей Минкин