Мысли вслух про технологии и подходы к разработке

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

Представили? Звучит ужасно, да?

Но вот если заменить менеджера на разработчика, а подходы к работе — способом организовывать код, то картинка начинает играть новыми красками.

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

Но мы почему-то в этом процессе совершенно забыли о том, что у кода всегда есть цель, и она самое важное.

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

Мы организовали себе конференции, взрастили селебрити — тем самым огородились от реального мира.

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

Только ситхи возводят все в абсолют, но мы с вами уже это сделали.

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

Значит ли это, что развиваться в технологии не надо? Нет.

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

Стоит ли учить [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) ты говоришь?

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

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

#английский

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

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

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

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

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

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

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

Такие дела ?

#резюме

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

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