Стоит ли учить [framework name]?

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

По этому поводу у меня есть радикальная идея: не нужно “учить” фреймворк. Все, что нужно выучить, вернее, освоить - это навык программировать. Навык программировать заключается в том, чтобы отображать объекты реального мира в виде абстракций, а также оперировать ими. Фреймворки, библиотеки и паттерны представляют собой лишь очередной способ делать это удобно. Возможно, для кого-то эта идея будет слишком радикальной, но на самом деле фреймворки, паттерны, библиотеки не рождаются из полного хаоса, они рождаются из удобных и практичных способов оперировать данными.

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

Люблю когда на английском нахожу не очевидные моменты для себя и мы из разбираем
Сегодня споткнулся об фразу: Who did you buy the present for?

Пытаясь перевести как: Кто тебе ... ты купил подарок? Понимая при этом что что-то тут не так.
Должно быть:
- Для кого ты покупала подарок?

А оказывается: Кому и для кого, может быть спокойно разнесено по разным частям предложения ?
- who (1) did you go to the party with (2)?
- С (2) кем (1) ты ходил на вечеринку

Ну и так же не обязательно who, может быть и другие:
- What (1) are you talking about (2)?
- О (2) чем (1) ты говоришь?

Забавно, и в целом логично, что-то в этом даже есть

Люблю когда выходит уходить от мышления через перевод к пониманию.

#английский

Забавный факт о резюме:
▸ На основании резюме не принимают решение взять вас на работу, для этого есть собеседование.
▸ На основании вашего резюме принимают решение не звать вас на собеседование.

❗️ Получается, что вам не нужно добавлять в резюме информацию, которая поможет вас нанять, а нужно убирать то, что помешает вас пригласить на собеседование. ?

Это не очевидно, но если вы сами об этом подумаете, вы придёте к тем же выводам.

Сами подумайте:
▸ Этот документ читают буквально за пару секунд.
▸ Из него невозможно понять, насколько вы хороший специалист.
▸ Но этого документа хватает, чтобы зацепиться за что-то взглядом и решить: «Нет, его не приглашаем».

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

❗️Но, похоже, это не то место, где нужно это рассказывать.

Если вы ищете работу, посмотрите на своё резюме ещё раз:
А есть ли в нём что-то, что непонятно и могло бы стать причиной отказа?

Такие дела ?

#резюме

Вышёл новый выпуск подкаста про гостей наших конф! Записались с Серёгой Андреевым из нашего казахстанского сообщества, потрещали про нелёгкую судьбинушку мужа и отца в эмиграции, посравнивали Тай с Казахстаном, подумали, чё и как дальше жить

Посмотрите и поддержите!

https://youtu.be/isRSeMKzCaA?si=307BwDH_MC4TKgUa

YouTube

Эмиграция, родительство, IT / Фил Ранжин, Сергей Андреев / Peredelanoconf podcast

Обсуждаем, как жить в чужой стране, если ты отец, сравниваем Таиланд и Казахстан, разбираемся, как жить и развиваться в этом сложном мире Присоединяйтесь к нашим сообществам по всему миру — приходите на конфы в вашем городе! https://www.peredelanoconf.com/…

Секреты промт-инженеринга для менеджеров №2:

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

Что можно почитать на тему управления требованиями к проектам/системам?

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

По этому подготовил себе следующий список на изучение
- Тони Демарко "Deadline"
- User Story Mapping
- Карл Вигерс. Разработка требований к программному обеспечению
- babok
- IEEE 830

#книги #требования

Секреты промт-инженеринга для менеджеров:

А вы знали что если хвалить свою it команду за сделанную работу, то она работает лучше?

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

Это я перенял у Федора Овчинникова, основателя Додо Пиццы, когда увидел, как могу наблюдать за приготовлением моей пиццы через мобильное приложение. Подумал, что это супер дисциплинирует всю команду.

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

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

Развивая тему в подкасте, понял, что мы сделали много для открытого позиционирования ReLife. Всё началось с того, что мы не боялись критики и всегда шли на диалог с пользователями, даже провоцировали критику. Сейчас у нас небольшая команда и более 15 000 пользователей, которые поверили в нас. Мы готовы показать наш потенциал в рамках первой маркетинговой кампании.

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

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

@dima_relife