🤠 Правило бойскаута
Мне нравится подходы в которых происходит систематические улучшения. Даже если эти улучшения настолько маленькие, что по одному незаметны. Зато прогресс в целом меня мотивирует
Правило бойскаута именно об этом. Это философия, которая говорит о том, что каждый раз после твоих изменений кодовая база должна становиться лучше. Если каждый раз код будет становиться лучше, чище и читабельнее, то с проектом станет приятнее работать.
Но вот как-то не сложилось у меня с нравилось бойскаута, как и с другими общепризнанными практиками.
Я считаю, что во время реализации фичи, нужно сконцентрироваться именно на реализации этой фичи. Я всегда стараюсь сделать новый функционал максимально независимым от существующего функционала. А в идеале и новую фичу закрыть фиче тонком.
Мой опыт подсказывает, что незапланированный рефакторинг приведет к проблемам. Правя чужой код не всегда понятен весь контекст задач, в которой он выполнялся. А самое неприятное, что тебе может казаться, что ты понимаешь, но это не так. В таких условиях пропустить какой-то случай, и наплодить ошибок очень просто.
Так же такой подход противоречит правильной работе с системой контроля версий. В одном комитете должны быть атомарные изменения. В идеале один коммит (Или ветка, если так удобнее) - одна фича. Такой подход позволяет с одной стороны переиспользовать функционал если он еще не влит в основную ветку, а с другой стороны точно понимать, какого рода изменения были в фиче, и откатить ее.
Представь себе ситуацию, когда ты добавляешь код валидирующий форму на страницу, а попутно правишь роутинг приложения. Будет весело потом искать в каком комите приложение стало неправильно перенаправлять пользователя.
Тем не менее, я не считаю, что правило бойскаута совершенно неприменимо. Как я говорил выше такая философия очень близка мне. Просто оно не работает для больших интерплайзных приложений. В которых стабильность гораздо важнее скорости разработки фичи. Все большие приложения стараются не падать, поскольку каждое падение это потеря денег и аудитории. А вот в Стартапах, где скорость разработки это скорее вопрос выживаемости правило бойскаута может в недалеком будущем принести бенефиты;
Но даже в больших и устоявшихся приложениях, правило бойскаута можно применять. Только бойскаут должен быть не таким резким, и не должен сразу бросаться в бой. В таких приложениях все нужно делать через берлог.
Например я пилю фичу, и понимаю, что было бы неплохо отрефакторить текущий функционал, и вынести переиспользуемый код в отдельный модуль. Я делю сво фичу на две интерации. В первой итерации я пишу фичу без рефакторинга, возможно даже с дублированием кода. Зато это позволяет мне не трогать существующий функционал, а так же скрыть новую фичу под фиче тонком.
После чего завожу задачу на рефакторинг и кладу ее в беклог. Во время каждого спринта у меня есть время, когда я закрываю технический долги, именно тогда, я могу сделать код лучше.
В этом случае бизнес не получит рабочую фичу быстрее. Тестировщики будут иметь тест кейсы на старый и новый функционал и им будет проще тестировать техническую задачу на рефакторинг. Ну а я как пожилой и занудный бойскаут сделаю код лучше. А еще бывают ситуации, когда после релиза новой фичи становится очевидно, что она работе и не так, должна работать по-другому, или вовсе не нужна.
И тогда мне гораздо проще удалить сепарированный код, и не оставлять в коде ненужные абстракции.
Мне нравится подходы в которых происходит систематические улучшения. Даже если эти улучшения настолько маленькие, что по одному незаметны. Зато прогресс в целом меня мотивирует
Правило бойскаута именно об этом. Это философия, которая говорит о том, что каждый раз после твоих изменений кодовая база должна становиться лучше. Если каждый раз код будет становиться лучше, чище и читабельнее, то с проектом станет приятнее работать.
Но вот как-то не сложилось у меня с нравилось бойскаута, как и с другими общепризнанными практиками.
Я считаю, что во время реализации фичи, нужно сконцентрироваться именно на реализации этой фичи. Я всегда стараюсь сделать новый функционал максимально независимым от существующего функционала. А в идеале и новую фичу закрыть фиче тонком.
Мой опыт подсказывает, что незапланированный рефакторинг приведет к проблемам. Правя чужой код не всегда понятен весь контекст задач, в которой он выполнялся. А самое неприятное, что тебе может казаться, что ты понимаешь, но это не так. В таких условиях пропустить какой-то случай, и наплодить ошибок очень просто.
Так же такой подход противоречит правильной работе с системой контроля версий. В одном комитете должны быть атомарные изменения. В идеале один коммит (Или ветка, если так удобнее) - одна фича. Такой подход позволяет с одной стороны переиспользовать функционал если он еще не влит в основную ветку, а с другой стороны точно понимать, какого рода изменения были в фиче, и откатить ее.
Представь себе ситуацию, когда ты добавляешь код валидирующий форму на страницу, а попутно правишь роутинг приложения. Будет весело потом искать в каком комите приложение стало неправильно перенаправлять пользователя.
Тем не менее, я не считаю, что правило бойскаута совершенно неприменимо. Как я говорил выше такая философия очень близка мне. Просто оно не работает для больших интерплайзных приложений. В которых стабильность гораздо важнее скорости разработки фичи. Все большие приложения стараются не падать, поскольку каждое падение это потеря денег и аудитории. А вот в Стартапах, где скорость разработки это скорее вопрос выживаемости правило бойскаута может в недалеком будущем принести бенефиты;
Но даже в больших и устоявшихся приложениях, правило бойскаута можно применять. Только бойскаут должен быть не таким резким, и не должен сразу бросаться в бой. В таких приложениях все нужно делать через берлог.
Например я пилю фичу, и понимаю, что было бы неплохо отрефакторить текущий функционал, и вынести переиспользуемый код в отдельный модуль. Я делю сво фичу на две интерации. В первой итерации я пишу фичу без рефакторинга, возможно даже с дублированием кода. Зато это позволяет мне не трогать существующий функционал, а так же скрыть новую фичу под фиче тонком.
После чего завожу задачу на рефакторинг и кладу ее в беклог. Во время каждого спринта у меня есть время, когда я закрываю технический долги, именно тогда, я могу сделать код лучше.
В этом случае бизнес не получит рабочую фичу быстрее. Тестировщики будут иметь тест кейсы на старый и новый функционал и им будет проще тестировать техническую задачу на рефакторинг. Ну а я как пожилой и занудный бойскаут сделаю код лучше. А еще бывают ситуации, когда после релиза новой фичи становится очевидно, что она работе и не так, должна работать по-другому, или вовсе не нужна.
И тогда мне гораздо проще удалить сепарированный код, и не оставлять в коде ненужные абстракции.
👍10🔥2❤1
🥱 Как уставать меньше
Весь сентябрь и часть октября чувствовал постоянную усталость. Не скажу, что сил вообще не было. В будние дни я просыпался отдохнувшим, но уже к обеду начинал ощущать себя уставшим, а к концу дня сил не остается совсем. Но самое печальное - это выходные. Бывали дли, когда я просыпался и часами лежал, не чувствуя никакого желания что-то делать.
Как всегда, столкнувшись с проблемой, начал разбираться как это работает. Чтобы понять, как выйти из этого состояния.Этим и решил поделиться.
🧑🏭 Почему мы устаем, работая за компьютером?
Для себя я выделил два основных пути потери сил.
👆 Во-первых, мозг постоянно борется с тем чтобы не отвлечься. Рабочие задачи очень часто выглядят менее заманчиво, чем котики в соц сетях, или новости. Каждый раз, когда появляется импульс на то, чтобы отвлечься, мозг тратит силы, чтобы его погасить.
✌️ Во-вторых, мы просто так устроены, что не можем долго заниматься одной деятельностью. Исторически, человеку нужно было выполнять множество параллельных задач. Найти еду, убедиться в безопасности, найти партнера, справить нужду. Человек, который увлекался одной задачей, забывая, допустим, про безопасность, быстро становился жертвой хищников. Именно поэтому усталость в какой-то мере можно воспринимать как сигнал к смене деятельности.
☕ Как меньше уставать?
Все советы, которые я выработал, прямо или косвенно следуют из двух утверждений выше.
🙃 Повышать мотивацию. Чем больше будет мотивировать работа, тем проще сопротивляться отвлечению. Про повышение мотивации можно написать еще с 10-к статей, но если коротко важно понимать, что рабочая деятельность небесполезна. Можно подумать о тех людях, которые будут пользоваться сервисом, об опыте который ты получишь когда успешно закончишь задачу, о родственных, о том, что на премию можно поехать в отпуске и так далее.
🔕 С другой стороны уменьшить количество отвлекающих факторов.
Лучше убрать со Стола любые вещи, не относящиеся к работе, убрать телефон, отключить уведомления от развлекательных сайтов. В идеале завести для работы отдельный компьютер, или хотя бы отдельный аккаунт, на котором не так просто попасть в социальные сети.
Так же стоит помнить, что навык сопротивлению отвлечению - это привычка. И чем чаще ты выбираешь работу вместо социальных сетей, тем проще тебе это будет сделать в следующий раз.
🌄 Менять виды деятельности.
Не всегда работа программиста связана с работой за компьютером. Очень часто для того, чтобы продуктивно обдумать решение, мне надо ходить. Получасовая прогулка по парку может принести поразительный инсайт. Так же отлично помогает сон (10-15 минут), или разговор с приятным коллегой.
Согласно исследованиям самые продуктивные люди работают циклами по 1,5-2 часа. Из которых 80 процентов уходит на выполнение задачи, а 20 процентов, на отвлеченную деятельность. Только не стоит отвлекаться на социальные сети.
🤸 Физическое состояние
Продуктивная умственная деятельность невозможна без хорошего физического самочувствия. Поэтому важно хорош спать, заниматься спортом и правильно питаться.
Мне очень сложно заставить идти себя в зал. Зато через 30 минут бега, я чувствую себя совершенно другим человеком. То же самое и с питанием, в моменте хочется что-то калорийное, зато потом чрезвычайно благодарен себе, за выбранный салат.
Но все эти советы, даже если безукоризненно следовать им не смогут заменить полноценный отдых. Поэтому не забывайте отдыхать, даже если смотришь на цены и думаешь, что не устал.
Весь сентябрь и часть октября чувствовал постоянную усталость. Не скажу, что сил вообще не было. В будние дни я просыпался отдохнувшим, но уже к обеду начинал ощущать себя уставшим, а к концу дня сил не остается совсем. Но самое печальное - это выходные. Бывали дли, когда я просыпался и часами лежал, не чувствуя никакого желания что-то делать.
Как всегда, столкнувшись с проблемой, начал разбираться как это работает. Чтобы понять, как выйти из этого состояния.Этим и решил поделиться.
🧑🏭 Почему мы устаем, работая за компьютером?
Для себя я выделил два основных пути потери сил.
👆 Во-первых, мозг постоянно борется с тем чтобы не отвлечься. Рабочие задачи очень часто выглядят менее заманчиво, чем котики в соц сетях, или новости. Каждый раз, когда появляется импульс на то, чтобы отвлечься, мозг тратит силы, чтобы его погасить.
✌️ Во-вторых, мы просто так устроены, что не можем долго заниматься одной деятельностью. Исторически, человеку нужно было выполнять множество параллельных задач. Найти еду, убедиться в безопасности, найти партнера, справить нужду. Человек, который увлекался одной задачей, забывая, допустим, про безопасность, быстро становился жертвой хищников. Именно поэтому усталость в какой-то мере можно воспринимать как сигнал к смене деятельности.
☕ Как меньше уставать?
Все советы, которые я выработал, прямо или косвенно следуют из двух утверждений выше.
🙃 Повышать мотивацию. Чем больше будет мотивировать работа, тем проще сопротивляться отвлечению. Про повышение мотивации можно написать еще с 10-к статей, но если коротко важно понимать, что рабочая деятельность небесполезна. Можно подумать о тех людях, которые будут пользоваться сервисом, об опыте который ты получишь когда успешно закончишь задачу, о родственных, о том, что на премию можно поехать в отпуске и так далее.
🔕 С другой стороны уменьшить количество отвлекающих факторов.
Лучше убрать со Стола любые вещи, не относящиеся к работе, убрать телефон, отключить уведомления от развлекательных сайтов. В идеале завести для работы отдельный компьютер, или хотя бы отдельный аккаунт, на котором не так просто попасть в социальные сети.
Так же стоит помнить, что навык сопротивлению отвлечению - это привычка. И чем чаще ты выбираешь работу вместо социальных сетей, тем проще тебе это будет сделать в следующий раз.
🌄 Менять виды деятельности.
Не всегда работа программиста связана с работой за компьютером. Очень часто для того, чтобы продуктивно обдумать решение, мне надо ходить. Получасовая прогулка по парку может принести поразительный инсайт. Так же отлично помогает сон (10-15 минут), или разговор с приятным коллегой.
Согласно исследованиям самые продуктивные люди работают циклами по 1,5-2 часа. Из которых 80 процентов уходит на выполнение задачи, а 20 процентов, на отвлеченную деятельность. Только не стоит отвлекаться на социальные сети.
🤸 Физическое состояние
Продуктивная умственная деятельность невозможна без хорошего физического самочувствия. Поэтому важно хорош спать, заниматься спортом и правильно питаться.
Мне очень сложно заставить идти себя в зал. Зато через 30 минут бега, я чувствую себя совершенно другим человеком. То же самое и с питанием, в моменте хочется что-то калорийное, зато потом чрезвычайно благодарен себе, за выбранный салат.
Но все эти советы, даже если безукоризненно следовать им не смогут заменить полноценный отдых. Поэтому не забывайте отдыхать, даже если смотришь на цены и думаешь, что не устал.
👍26🔥3👎1
👰 И в горе и в радости, пока другой оффер не разлучит вас...
Проходил недавно собеседование и словил инсайт. HR сказала, что они редко ищут людей, поскольку у них маленькая текучка кадров, а расти сильно они не собираются. Мне интересно послушать про такие вакансии, поскольку попасть к ним сложнее, чем в компании с активным наймом.
Немного про компанию. Ребята пишут торговых ботов для разных бирж. Никому их не продает, а торгуют сами. Зарабатывает компания на прибыли с этих торговых роботов. Компания по сути замкнута сама в себе. Заказчик разработки сидит в соседней комнате от этой самой разработки.
Это необычно само по себе, но меня зацепила система премирования. Каждые пол года компания ставит цель по выручке. Это те деньги которые нужны компании, чтобы существовать, и продолжать развиваться. И если заработать удалось больше, то излишки направляются в специальный фонд. Который после очередного ревью идет на премии сотрудника.
Логика простая: хорошо поработал - хорошую премию получил.
Очевидно, что спрогнозировать такую премию сложно. Но для примера мне озвучили премию разработчиков в прошлое ревью. Что-то около 30 тысяч долларов. Сумма интересная, но не все так просто.
Сразу эти деньги тебе не отдают. 20 тысяч выплачивают сразу, а остальное делится на 5 частей, и выплачивается дополнительно каждые пол года.
В итоге чем дольше работаешь, тем больше премия. А еще это уменьшает желание искать новую работу. Очевидно, что текучка у них меньше средней по рынку.
После собеседования я задумался, что мне импонирует подход, когда сотрудники, являясь частью компании, разделяют сверх прибыль, и разделяют неудачи компании. Очевидно, что с таким подходом в тяжелые времена часть людей отвалится. Но мне кажется такая практика выводит ответственность за то, что ты делаешь на новый уровень.
В России, я чаще сталкивался с другой философией. Когда работодатель за тебя все стараются решить, оградив рядовых сотрудников от проблем с которыми сталкивается компания. Когда-то это меня устраивало. Я считал, что мое дело код писать, а вопросами бизнеса пусть занимаются специально обученные люди. Сейчас скорее наоборот. Я считаю важным не только заглядывать в смежную техническую область, но еще и в целом разбираться как функционирует компания.
Это создает дополнительную эмоциональную связь, делая из отношений работник - работа нечто большее. Я уже год работаю в Яндексе и вижу здесь как людей, которые работают год-два, а потом уходят, так и тех, кто работает сильно дольше. Так вот последних, отличает богатая связь с их занятием. Они видят в рабочих задачах что-то больше чем просто работу. Такие люди могут очень долго рассказывать про проект или свой опыт на нем. Рассказывать истории из прошлого, и какой опыт получилось из этого извлечь.
Уверен, что если спросить про деньги, или другие плюшки, то такие люди ответят, что это совсем не главное. А главное - это ощущение причастности к тому что ты делаешь, ощущение влияния на продукт и компанию. И в тот момент, когда ты начинаешь ощущать это твое восприятие работы меняется. И самый простой способ ощутить - это разделить с компанией и успехи и поражения.
Написать мне | Поддержать: Boosty | Patreon | Крипта
А сколько лет ты работаешь на своем месте? И что тебя держит?
Проходил недавно собеседование и словил инсайт. HR сказала, что они редко ищут людей, поскольку у них маленькая текучка кадров, а расти сильно они не собираются. Мне интересно послушать про такие вакансии, поскольку попасть к ним сложнее, чем в компании с активным наймом.
Немного про компанию. Ребята пишут торговых ботов для разных бирж. Никому их не продает, а торгуют сами. Зарабатывает компания на прибыли с этих торговых роботов. Компания по сути замкнута сама в себе. Заказчик разработки сидит в соседней комнате от этой самой разработки.
Это необычно само по себе, но меня зацепила система премирования. Каждые пол года компания ставит цель по выручке. Это те деньги которые нужны компании, чтобы существовать, и продолжать развиваться. И если заработать удалось больше, то излишки направляются в специальный фонд. Который после очередного ревью идет на премии сотрудника.
Логика простая: хорошо поработал - хорошую премию получил.
Очевидно, что спрогнозировать такую премию сложно. Но для примера мне озвучили премию разработчиков в прошлое ревью. Что-то около 30 тысяч долларов. Сумма интересная, но не все так просто.
Сразу эти деньги тебе не отдают. 20 тысяч выплачивают сразу, а остальное делится на 5 частей, и выплачивается дополнительно каждые пол года.
В итоге чем дольше работаешь, тем больше премия. А еще это уменьшает желание искать новую работу. Очевидно, что текучка у них меньше средней по рынку.
После собеседования я задумался, что мне импонирует подход, когда сотрудники, являясь частью компании, разделяют сверх прибыль, и разделяют неудачи компании. Очевидно, что с таким подходом в тяжелые времена часть людей отвалится. Но мне кажется такая практика выводит ответственность за то, что ты делаешь на новый уровень.
В России, я чаще сталкивался с другой философией. Когда работодатель за тебя все стараются решить, оградив рядовых сотрудников от проблем с которыми сталкивается компания. Когда-то это меня устраивало. Я считал, что мое дело код писать, а вопросами бизнеса пусть занимаются специально обученные люди. Сейчас скорее наоборот. Я считаю важным не только заглядывать в смежную техническую область, но еще и в целом разбираться как функционирует компания.
Это создает дополнительную эмоциональную связь, делая из отношений работник - работа нечто большее. Я уже год работаю в Яндексе и вижу здесь как людей, которые работают год-два, а потом уходят, так и тех, кто работает сильно дольше. Так вот последних, отличает богатая связь с их занятием. Они видят в рабочих задачах что-то больше чем просто работу. Такие люди могут очень долго рассказывать про проект или свой опыт на нем. Рассказывать истории из прошлого, и какой опыт получилось из этого извлечь.
Уверен, что если спросить про деньги, или другие плюшки, то такие люди ответят, что это совсем не главное. А главное - это ощущение причастности к тому что ты делаешь, ощущение влияния на продукт и компанию. И в тот момент, когда ты начинаешь ощущать это твое восприятие работы меняется. И самый простой способ ощутить - это разделить с компанией и успехи и поражения.
Написать мне | Поддержать: Boosty | Patreon | Крипта
А сколько лет ты работаешь на своем месте? И что тебя держит?
👍28🔥2🤔2
Forwarded from Яндекс
Media is too big
VIEW IN TELEGRAM
А ещё YaC 2023 — это мини-сериал из четырёх эпизодов. На Кинопоиске и YouTube.
Подписывайтесь 👉 @yandex
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥4👍2
🧒 Три месяца работы со стажером...
Три месяца назад ко мне в команду вышел стажер. Я всегда считал раньше, что стажировка - крутой шанс для стажера, особенно в крупной компании. Но для компании это скорее инвестиция, а для команды - дополнительная нагрузка.
Стажер, который пришел в мою команду, назовем его Димой, ничем по технической подготовке не отличался от уверенного мидл разработчика. На собеседования ко мне иногда приходят ребята слабее.
За эти три месяца он ни разу не задал мне технический вопрос, ни разу не пришел с вопросом, что он что-то не понимает. Возможно, он спрашивал это еще у кого-то или у других стажеров. Но судя по его подготовке, таких вопросов было немного, если они были. Да, его решения были не идеальными, их было куда улучшать, но они всегда работали.
За эти три месяца он не моргнув глазом разобрал весь беклог с багами и задачами, до которых никак не доходили руки.
Тут стоит отдать должное нашему амбассадору багов - опытному разработчику из компании, который организовал работу стажеров с беклогом. Он просматривал все тикеты, дополнял, исправлял их и передавал стажерам. Мы даже устроили соревнование, целью которого было всем вместе в 5 раз снизить суммарный вес багов. И они смогли, а потом дружно отправились в бар праздновать.
Когда закончились баги, я начал давать простые продуктовые задачи. Стажер выступил настолько хорошо, что новый лидер нашей кроссфункциональной команды удивился, узнав, что Дима - стажер.
🥫 А может не нужны эти ваши синьеры-помидоры?
Признаюсь честно, смотря на то, как Дима справляется, я тоже об этом задумался. Заменить опытных, дорогих и местами несговорчивых разработчиков на молчаливых, заинтересованных и дешевых стажеров.
Но все встало на свои места, когда я заметил, как стажер начинает вязнуть в продуктовых задачах, в которых не просто надо писать код, но еще и выяснить что-то.
Наш мозг всегда выбирает самую понятную задачу. А вот как сделать из сложной задачи простую - это совершенно другой навык.
Если задача понятна, стажер будет с удовольствием решать любой, даже самый скучный баг. Ведь ему все в новинку. Но фиксить баги ему наскучит сильно раньше, чем он научится уменьшать энтропию продуктовых задач.
Больше всего я беспокоился, что стажер станет дополнительной нагрузкой. Что ему придется что-то объяснять, внимательно перепроверять за ним и возможно разгребать инциденты. Но поскольку в Яндекс попадают только лучшие стажеры, таких проблем не было. А наличие стажера помогло мне сконцентрироваться на более комплексных задачах.
Три месяца назад ко мне в команду вышел стажер. Я всегда считал раньше, что стажировка - крутой шанс для стажера, особенно в крупной компании. Но для компании это скорее инвестиция, а для команды - дополнительная нагрузка.
Стажер, который пришел в мою команду, назовем его Димой, ничем по технической подготовке не отличался от уверенного мидл разработчика. На собеседования ко мне иногда приходят ребята слабее.
За эти три месяца он ни разу не задал мне технический вопрос, ни разу не пришел с вопросом, что он что-то не понимает. Возможно, он спрашивал это еще у кого-то или у других стажеров. Но судя по его подготовке, таких вопросов было немного, если они были. Да, его решения были не идеальными, их было куда улучшать, но они всегда работали.
За эти три месяца он не моргнув глазом разобрал весь беклог с багами и задачами, до которых никак не доходили руки.
Тут стоит отдать должное нашему амбассадору багов - опытному разработчику из компании, который организовал работу стажеров с беклогом. Он просматривал все тикеты, дополнял, исправлял их и передавал стажерам. Мы даже устроили соревнование, целью которого было всем вместе в 5 раз снизить суммарный вес багов. И они смогли, а потом дружно отправились в бар праздновать.
Когда закончились баги, я начал давать простые продуктовые задачи. Стажер выступил настолько хорошо, что новый лидер нашей кроссфункциональной команды удивился, узнав, что Дима - стажер.
🥫 А может не нужны эти ваши синьеры-помидоры?
Признаюсь честно, смотря на то, как Дима справляется, я тоже об этом задумался. Заменить опытных, дорогих и местами несговорчивых разработчиков на молчаливых, заинтересованных и дешевых стажеров.
Но все встало на свои места, когда я заметил, как стажер начинает вязнуть в продуктовых задачах, в которых не просто надо писать код, но еще и выяснить что-то.
Наш мозг всегда выбирает самую понятную задачу. А вот как сделать из сложной задачи простую - это совершенно другой навык.
Если задача понятна, стажер будет с удовольствием решать любой, даже самый скучный баг. Ведь ему все в новинку. Но фиксить баги ему наскучит сильно раньше, чем он научится уменьшать энтропию продуктовых задач.
Больше всего я беспокоился, что стажер станет дополнительной нагрузкой. Что ему придется что-то объяснять, внимательно перепроверять за ним и возможно разгребать инциденты. Но поскольку в Яндекс попадают только лучшие стажеры, таких проблем не было. А наличие стажера помогло мне сконцентрироваться на более комплексных задачах.
👍30🤔13❤5
🗣️ Про отношения в команде и продуктивность
Случайно провел эксперимент. Мне для запуска фичи потребовались доработки в нативной части приложения. Оформил две одинаковые задачи на iOS и Android.
iOS был важнее, поэтому сначала пришел к ним. Разработчик оценил задачу в день-полтора работы. Меня это устраивало, поэтому я ушел и не трогал его больше.
Есть люди, с которыми отношения у меня как-то не сложились. Вроде конфликта нет, но и чувствуется какой-то холодок. Вроде ты предлагаешь здравые вещи, а с твоими словами чуть пренебрежительно и недоверчиво соглашаются. Вот с iOS разработчиком у меня именно так.
Через день разработчик приходит, говорит, что готово. Я скачал девсборку, запускаю симулятор, вижу проблему, спрашиваю, как проверял? А он не проверял. Говорит, ну она должна работать. Пока искал причину, залез в код. Там изменений на 10 строк, реально нечему ломаться. В итоге проблема была в симуляторе.
Претензий вроде как нет, но код свой тестировать надо. В общем, как в том анекдоте: "Ложки нашлись, а осадок остался".
Дальше пришел к Android разработчику. С ним мы работаем плотнее, общаемся лучше, иногда даем друг другу советы.
Созвонились, рассказал про задачу, объяснил, почему срочно и нужно все бросить и делать именно ее. Спрашиваю, во сколько оценишь?
🤷 "Часа 3".
Я говорю, ну ок, пиши, как закончишь. Через час разработчик спрашивает про целевой кейс, есть ли крайние случаи, и в результате отправляет мне скринкаст с записью работы новой фичи. Ради любопытства посмотрел в ПР и увидел, что кода там раз в 10 больше, чем на iOS.
Именно количество кода и объем потраченного времени заставили меня задуматься, почему так получилось.
Оба разработчика примерно одного уровня. Оба хорошо справляются со своими обязанностями. Только один сделал по минимуму, а другой сделал по максимуму, с душой.
Написать мне | Поддержать Канал
Случайно провел эксперимент. Мне для запуска фичи потребовались доработки в нативной части приложения. Оформил две одинаковые задачи на iOS и Android.
iOS был важнее, поэтому сначала пришел к ним. Разработчик оценил задачу в день-полтора работы. Меня это устраивало, поэтому я ушел и не трогал его больше.
Есть люди, с которыми отношения у меня как-то не сложились. Вроде конфликта нет, но и чувствуется какой-то холодок. Вроде ты предлагаешь здравые вещи, а с твоими словами чуть пренебрежительно и недоверчиво соглашаются. Вот с iOS разработчиком у меня именно так.
Через день разработчик приходит, говорит, что готово. Я скачал девсборку, запускаю симулятор, вижу проблему, спрашиваю, как проверял? А он не проверял. Говорит, ну она должна работать. Пока искал причину, залез в код. Там изменений на 10 строк, реально нечему ломаться. В итоге проблема была в симуляторе.
Претензий вроде как нет, но код свой тестировать надо. В общем, как в том анекдоте: "Ложки нашлись, а осадок остался".
Дальше пришел к Android разработчику. С ним мы работаем плотнее, общаемся лучше, иногда даем друг другу советы.
Созвонились, рассказал про задачу, объяснил, почему срочно и нужно все бросить и делать именно ее. Спрашиваю, во сколько оценишь?
🤷 "Часа 3".
Я говорю, ну ок, пиши, как закончишь. Через час разработчик спрашивает про целевой кейс, есть ли крайние случаи, и в результате отправляет мне скринкаст с записью работы новой фичи. Ради любопытства посмотрел в ПР и увидел, что кода там раз в 10 больше, чем на iOS.
Именно количество кода и объем потраченного времени заставили меня задуматься, почему так получилось.
Оба разработчика примерно одного уровня. Оба хорошо справляются со своими обязанностями. Только один сделал по минимуму, а другой сделал по максимуму, с душой.
Написать мне | Поддержать Канал
👍18😢3🤡1
🧑🏭 Про операторов технологий
Я сейчас провожу много собеседований. Перед собеседованием я читаю резюме и пытаюсь угадать, насколько сильный кандидат мне попался.
Основное, на что я обращаю внимание - это опыт. Логика простая: больше лет опыта - сильнее кандидат. Но не все так просто. Я уже как-то писал про стажеров, которые, на мой взгляд, смогут легко пройти собеседование на мидл разработчика. А сегодня будет обратный случай.
Кандидат - 10 лет опыта, три компании, и полный провал на собеседовании. После встречи мне нужно заполнить небольшую форму, в которой нужно описать, как все прошло.
Я долго думал, прежде чем отправить форму. У меня не было сомнений, пропускать его дальше или нет, интервью было провалено. Я думал, как там могло получиться, что человек 10 лет в сфере и не может ответить на базовые вопросы.
Ответ я нашел в комментариях интервьюера с предыдущей секции.
Тут замечу, что несмотря на то, что кандидат уволился с первой компании больше 6 лет назад.
Моя история в IT чем-то похожа. На первой работе я освоил популярный фреймворк и оказался востребованным на рынке. Это был период, когда порог входа был ниже, чем сейчас, а дефицит кадров гигантский. Небольшим компаниям зачастую все равно, насколько хорошо ты знаешь computer science и как хорошо пишешь алгоритмы. Для них важно, чтобы ты мог быстро влиться в работу, знал популярный фреймворк и быстро начал решать задачи бизнеса.
Какое-то время я был идеальным кандидатом для таких компаний. Задачи решал, денег просил не очень много, общаться умел. Но фреймворк, который я освоил, очень быстро потерял популярность. Тогда я понял, что быть оператором популярной технологии - это неплохо, но бесперспективно. И тогда я планомерно начал заниматься самообразованием. Впрочем, я до сих пор не считаю хард скиллы своей сильной стороной и жалею об отсутствии фундаментального образования.
Кандидату повезло больше. Он выбрал React.js - технологию, которая все еще живее всех живых. И пока это положение драматически не изменится, мотивации для обучения нет.
Я бы не хотел нагнетать и говорить, что так делать не правильно, и что в какой-то момент он может остаться без работы. Тем более ИИ всех нас собирается заменить. Я хотел сказать, что мне искренне жаль людей, которые перестают развиваться, несмотря на то, что у них для этого есть все возможности.
Написать мне | Поддержать Канал
Я сейчас провожу много собеседований. Перед собеседованием я читаю резюме и пытаюсь угадать, насколько сильный кандидат мне попался.
Основное, на что я обращаю внимание - это опыт. Логика простая: больше лет опыта - сильнее кандидат. Но не все так просто. Я уже как-то писал про стажеров, которые, на мой взгляд, смогут легко пройти собеседование на мидл разработчика. А сегодня будет обратный случай.
Кандидат - 10 лет опыта, три компании, и полный провал на собеседовании. После встречи мне нужно заполнить небольшую форму, в которой нужно описать, как все прошло.
Я долго думал, прежде чем отправить форму. У меня не было сомнений, пропускать его дальше или нет, интервью было провалено. Я думал, как там могло получиться, что человек 10 лет в сфере и не может ответить на базовые вопросы.
Ответ я нашел в комментариях интервьюера с предыдущей секции.
"Кандидат много рассказывал про свой опыт, но в основном про первую работу".
Тут замечу, что несмотря на то, что кандидат уволился с первой компании больше 6 лет назад.
Моя история в IT чем-то похожа. На первой работе я освоил популярный фреймворк и оказался востребованным на рынке. Это был период, когда порог входа был ниже, чем сейчас, а дефицит кадров гигантский. Небольшим компаниям зачастую все равно, насколько хорошо ты знаешь computer science и как хорошо пишешь алгоритмы. Для них важно, чтобы ты мог быстро влиться в работу, знал популярный фреймворк и быстро начал решать задачи бизнеса.
Какое-то время я был идеальным кандидатом для таких компаний. Задачи решал, денег просил не очень много, общаться умел. Но фреймворк, который я освоил, очень быстро потерял популярность. Тогда я понял, что быть оператором популярной технологии - это неплохо, но бесперспективно. И тогда я планомерно начал заниматься самообразованием. Впрочем, я до сих пор не считаю хард скиллы своей сильной стороной и жалею об отсутствии фундаментального образования.
Кандидату повезло больше. Он выбрал React.js - технологию, которая все еще живее всех живых. И пока это положение драматически не изменится, мотивации для обучения нет.
Я бы не хотел нагнетать и говорить, что так делать не правильно, и что в какой-то момент он может остаться без работы. Тем более ИИ всех нас собирается заменить. Я хотел сказать, что мне искренне жаль людей, которые перестают развиваться, несмотря на то, что у них для этого есть все возможности.
Написать мне | Поддержать Канал
👍18🔥5🤔1
💡 Инсайт после конференции YaTalks
Удобно хранить информацию - это важная, но сложная задача. Книги, доклады, рабочие встречи - все это информация, которую стоило бы сохранить. Что-то из этого пригодится сейчас, что-то через пару лет, а что-то никогда.
Наш мозг избавляется от всего лишнего. Если узнал что-то и это сразу не пригодилось - забывает. Если давно не повторял, тоже стоит забыть. Такой подход неплохо работает в дикой природе, но в современном мире рассчитывать на память опрометчиво. Поэтому с недавних пор я тезисно сохраняю поступающую ко мне информацию, особенно это касается докладов и книг.
На прошлой неделе Яндекс провел конференцию YaTalks. Поскольку была возможность лично присутствовать в Москве и Белграде, я не мог пропустить. Именно личное присутствие вдохновляет, заряжает и дарит инсайты. В этом году инсайт даже не был связан с докладами, хотя там было что посмотреть.
В этом году после доклада на экран выводились ключевые мысли. Работало это при помощи YandexGPT, который распознавал текст доклада и выделял основные тезисы. Помню, как стоял и читал сокращенный пересказ доклада Никиты Елагина, и меня осенило.
Во время прослушивания доклада я всегда делаю пометки. Эти пометки вместе с ссылкой на видео я переношу в свою базу знаний. Нужно это для того, чтобы потом быстро восстановить в памяти тему доклада. Но мои заметки не идеальны. Хотя бы потому, что они не позволяют быстро найти эту тему в самом докладе. Но если к ним добавить тезисы, которые генерируются суммаризатором, проблема решается.
Так я и поступил для всех докладов с конференции. Я брал свои заметки, сравнивал их с заметками от YandexGPT. После чего менял формулировку каждого тезиса, чтобы мне было понятно, и вместе с тайм-кодом вставлял в заметки.
В итоге у меня получилась заметка, которая:
- содержит ключевые моменты по докладу,
- тезисы сформулированы в понятной мне форме,
- тайм-код на каждый из тезисов.
К этому я еще обычно выписываю литературу, которую рекомендует автор. Также добавляются ссылки на другие заметки по похожей теме - это могут быть прочитанные книги, статьи или доклады.
Таким образом, у меня получилась удобная система, которая позволит мне восстановить информацию, если я что-то забуду. Я могу забыть про этот доклад, про заметки или конференцию. Но благодаря схожим заметкам, я найду этот доклад, как только тема снова станет актуальной. Из заметок я смогу вытащить ключевую мысль, а тайм-код избавит от просмотра всего доклада.
Таким же способом можно хранить не только доклады, но и лекции, обучающие уроки и статьи.
П.С. Сделать краткий пересказ можно тут.
Написать мне | Поддержать Канал
Удобно хранить информацию - это важная, но сложная задача. Книги, доклады, рабочие встречи - все это информация, которую стоило бы сохранить. Что-то из этого пригодится сейчас, что-то через пару лет, а что-то никогда.
Наш мозг избавляется от всего лишнего. Если узнал что-то и это сразу не пригодилось - забывает. Если давно не повторял, тоже стоит забыть. Такой подход неплохо работает в дикой природе, но в современном мире рассчитывать на память опрометчиво. Поэтому с недавних пор я тезисно сохраняю поступающую ко мне информацию, особенно это касается докладов и книг.
На прошлой неделе Яндекс провел конференцию YaTalks. Поскольку была возможность лично присутствовать в Москве и Белграде, я не мог пропустить. Именно личное присутствие вдохновляет, заряжает и дарит инсайты. В этом году инсайт даже не был связан с докладами, хотя там было что посмотреть.
В этом году после доклада на экран выводились ключевые мысли. Работало это при помощи YandexGPT, который распознавал текст доклада и выделял основные тезисы. Помню, как стоял и читал сокращенный пересказ доклада Никиты Елагина, и меня осенило.
Во время прослушивания доклада я всегда делаю пометки. Эти пометки вместе с ссылкой на видео я переношу в свою базу знаний. Нужно это для того, чтобы потом быстро восстановить в памяти тему доклада. Но мои заметки не идеальны. Хотя бы потому, что они не позволяют быстро найти эту тему в самом докладе. Но если к ним добавить тезисы, которые генерируются суммаризатором, проблема решается.
Так я и поступил для всех докладов с конференции. Я брал свои заметки, сравнивал их с заметками от YandexGPT. После чего менял формулировку каждого тезиса, чтобы мне было понятно, и вместе с тайм-кодом вставлял в заметки.
В итоге у меня получилась заметка, которая:
- содержит ключевые моменты по докладу,
- тезисы сформулированы в понятной мне форме,
- тайм-код на каждый из тезисов.
К этому я еще обычно выписываю литературу, которую рекомендует автор. Также добавляются ссылки на другие заметки по похожей теме - это могут быть прочитанные книги, статьи или доклады.
Таким образом, у меня получилась удобная система, которая позволит мне восстановить информацию, если я что-то забуду. Я могу забыть про этот доклад, про заметки или конференцию. Но благодаря схожим заметкам, я найду этот доклад, как только тема снова станет актуальной. Из заметок я смогу вытащить ключевую мысль, а тайм-код избавит от просмотра всего доклада.
Таким же способом можно хранить не только доклады, но и лекции, обучающие уроки и статьи.
П.С. Сделать краткий пересказ можно тут.
Написать мне | Поддержать Канал
👍25
👨👩👧👦 Главная проблема любой IT компании
Автомобилисты шутят, что главная неисправность в автомобиле - это прокладка между рулем и сиденьем. Безопасники всерьез считают человека самым слабым звеном любой системы безопасности. В обеих сферах цена "человеческого фактора" очень высока. В IT компаниях та же самая проблема. И не только в IT. Все потому, что долгое время человек считался рациональным существом. И все системы развивались с расчетом на это.
Но люди - не роботы. Мы устаем, ленимся, испытываем эмоции. Нам присущи когнитивные искажения и много всего доставшееся от древних людей. Особенно это заметно на больших числах. Что приводит продукты и целые компании к совершенно неожиданному результату.
Но это не мешает считать работников винтиками в системе. Оценивать работу в человеко-месяцах, измерять эффективность количеством написанного кода, мотивировать KPI или оценить всех по матрице компетенции... И потому мне приятно видеть другие подходы.
Недавно был на внутреннем митапе Яндекс.Маркета. Ребята рассказывали про свои наработки. Мне запомнился сервис, который решает достаточно тривиальную задачу, собирает данные из разных источников, что-то с ними делает и отдает уже готовое отображение. Интересна в нем архитектура, в основе которой она лежит закон Конвея:
Организации проектируют системы, которые копируют структуру коммуникаций в этой организации.
Другими словами, если у вас над проектом работает 4 команды, то скорее всего в нем будет 4 больших модуля. При этом взаимодействие между модулями будет тем хуже, чем хуже настроена коммуникация между командами.
Именно на этом месте появляются самые болезненные проблемы - интеграционные проблемы. Проблемы, возникающие на стыке модулей, сервисов или систем. Проблемы, которые не понятно на чьей стороне их нужно решать. Тикеты с такими багами очень часто летают от одной команды к другой и, делая полный оборот, возвращаются назад.
Так вот, в своем сервисе ребята из Яндекс.Маркета предположили, что люди, которые собирают данные, обогащают данные, создают API и в итоге потребляют данные - скорее всего это разные люди. А потому при разработке они сконцентрировались именно на связях между модулями, а не на работе с самими данными.
Модуль сбора данных может собирать данные как угодно. Он может использовать любые инструменты и технологии. Зато взаимодействие со следующим модулем максимально зарегулировано. Модуль обогащения данных также может быть реализован как угодно, но имеет жесткий контракт с модулем отображения данных. При этом разные команды имеют возможность под себя настроить работу внутри модуля.
Кажется очевидно, что закладывая то, что заложено в архитектуру, особенности потребителя сервиса сделают работу с ним производительной. Но нет, посмотрите на большую часть интернет-приложений. Они сделаны чужими для хищника, а не для людей.
При этом удивительно то, что к своим клиентам те же компании не относятся как к рациональным существам. Собственно, весь UX построен именно на том, что ребята на больших числах изучают поведение людей. Если интересно, погуглите, как ритейл пользуется человеческими особенностями, подталкивая покупать больше. Но при этом работники компании, которые такие же люди, воспринимаются как механизмы.
В целом ситуация меняется, как и в IT, так и в мире в целом. Графические представления, функциональные и объектные подходы к написанию кода, высокоуровневые языки программирования и многое другое - это шаги в торону человечности. Но самая главная проблема - это люди. Люди, которые относятся к другим людям как к винтикам.
Ну и под конец я бы хотел вспомнить про бирюзовые компании. Эти компании изначально относятся к человеку как к нерациональному существу, при этом не стараясь его изменить. Не пытаются подогнать его под свои лекала. А наоборот, стараются использовать человеческие особенности как возможность для своего развития. И для таких компаний нет такой проблемы, как человек.
Написать мне | Поддержать Канал
Автомобилисты шутят, что главная неисправность в автомобиле - это прокладка между рулем и сиденьем. Безопасники всерьез считают человека самым слабым звеном любой системы безопасности. В обеих сферах цена "человеческого фактора" очень высока. В IT компаниях та же самая проблема. И не только в IT. Все потому, что долгое время человек считался рациональным существом. И все системы развивались с расчетом на это.
Но люди - не роботы. Мы устаем, ленимся, испытываем эмоции. Нам присущи когнитивные искажения и много всего доставшееся от древних людей. Особенно это заметно на больших числах. Что приводит продукты и целые компании к совершенно неожиданному результату.
Но это не мешает считать работников винтиками в системе. Оценивать работу в человеко-месяцах, измерять эффективность количеством написанного кода, мотивировать KPI или оценить всех по матрице компетенции... И потому мне приятно видеть другие подходы.
Недавно был на внутреннем митапе Яндекс.Маркета. Ребята рассказывали про свои наработки. Мне запомнился сервис, который решает достаточно тривиальную задачу, собирает данные из разных источников, что-то с ними делает и отдает уже готовое отображение. Интересна в нем архитектура, в основе которой она лежит закон Конвея:
Организации проектируют системы, которые копируют структуру коммуникаций в этой организации.
Другими словами, если у вас над проектом работает 4 команды, то скорее всего в нем будет 4 больших модуля. При этом взаимодействие между модулями будет тем хуже, чем хуже настроена коммуникация между командами.
Именно на этом месте появляются самые болезненные проблемы - интеграционные проблемы. Проблемы, возникающие на стыке модулей, сервисов или систем. Проблемы, которые не понятно на чьей стороне их нужно решать. Тикеты с такими багами очень часто летают от одной команды к другой и, делая полный оборот, возвращаются назад.
Так вот, в своем сервисе ребята из Яндекс.Маркета предположили, что люди, которые собирают данные, обогащают данные, создают API и в итоге потребляют данные - скорее всего это разные люди. А потому при разработке они сконцентрировались именно на связях между модулями, а не на работе с самими данными.
Модуль сбора данных может собирать данные как угодно. Он может использовать любые инструменты и технологии. Зато взаимодействие со следующим модулем максимально зарегулировано. Модуль обогащения данных также может быть реализован как угодно, но имеет жесткий контракт с модулем отображения данных. При этом разные команды имеют возможность под себя настроить работу внутри модуля.
Кажется очевидно, что закладывая то, что заложено в архитектуру, особенности потребителя сервиса сделают работу с ним производительной. Но нет, посмотрите на большую часть интернет-приложений. Они сделаны чужими для хищника, а не для людей.
При этом удивительно то, что к своим клиентам те же компании не относятся как к рациональным существам. Собственно, весь UX построен именно на том, что ребята на больших числах изучают поведение людей. Если интересно, погуглите, как ритейл пользуется человеческими особенностями, подталкивая покупать больше. Но при этом работники компании, которые такие же люди, воспринимаются как механизмы.
В целом ситуация меняется, как и в IT, так и в мире в целом. Графические представления, функциональные и объектные подходы к написанию кода, высокоуровневые языки программирования и многое другое - это шаги в торону человечности. Но самая главная проблема - это люди. Люди, которые относятся к другим людям как к винтикам.
Ну и под конец я бы хотел вспомнить про бирюзовые компании. Эти компании изначально относятся к человеку как к нерациональному существу, при этом не стараясь его изменить. Не пытаются подогнать его под свои лекала. А наоборот, стараются использовать человеческие особенности как возможность для своего развития. И для таких компаний нет такой проблемы, как человек.
Написать мне | Поддержать Канал
👍9
Всем привет, на связи Алекс.
К банальным поздравлениям с Новым годом (они будут в конце), я решил добавить небольшое личное саммари. В этом году для меня ведение этого канала вышло на новый уровень.
Этот канал случайно появился. Начинался он как просто придаток к YouTube-каналу, где выходили основные материалы. А потом незаметно превратился в отдельный проект. Ну а дальше случилась осень 2022 года с тектоническими изменениями. Но я продолжал писать сюда. Я писал из трех стран, в которых жил. Я писал сюда, пока был в поездках и командировках. Да что уж греха таить, я писал сюда во время отпуска, посреди Средиземного моря. Потому что этот канал для меня нечто большее, чем место, куда я записываю свои мысли.
За последний год я стал лучше понимать себя и свою точку зрения, поскольку каждый пост - это рефлексия и формулирование своих мыслей в посты. Я стал формировать свою профессиональную философию. Благодаря каналу, я имею бесценную возможность узнать, насколько хорошо я доношу мысль и как эта мысль воспринимается. А еще благодаря каналу у меня появился моральный компас, благодаря которому мне в моменте становится понятно, какие решения стоит принимать.
Переходя к банальностям. Нас много, и у всех желания разные. Кто-то хочет реализоваться, кто-то хочет завершить проект, а кто-то просто хочет найти работу. Но я верю, что всех нас объединяет желание создавать. Создавать новую ценность в мире, создать новый продукт, который изменит жизнь многих людей к лучшему. Да хотя бы найти работу, чтобы изменить свою жизнь к лучшему.
Именно поэтому мне бы хотелось, чтобы новый год прошел под флагом созидания. Чтобы у нас у всех было это желание создавать, чтобы находились силы, и чтобы оно получалось. И даже если сейчас картина выглядит мрачной, я всегда вспоминаю, что самый темный час бывает перед рассветом.
Спасибо всем нам, что были в этом году здесь, и увидимся в следующем. С Новым Годом
К банальным поздравлениям с Новым годом (они будут в конце), я решил добавить небольшое личное саммари. В этом году для меня ведение этого канала вышло на новый уровень.
Этот канал случайно появился. Начинался он как просто придаток к YouTube-каналу, где выходили основные материалы. А потом незаметно превратился в отдельный проект. Ну а дальше случилась осень 2022 года с тектоническими изменениями. Но я продолжал писать сюда. Я писал из трех стран, в которых жил. Я писал сюда, пока был в поездках и командировках. Да что уж греха таить, я писал сюда во время отпуска, посреди Средиземного моря. Потому что этот канал для меня нечто большее, чем место, куда я записываю свои мысли.
За последний год я стал лучше понимать себя и свою точку зрения, поскольку каждый пост - это рефлексия и формулирование своих мыслей в посты. Я стал формировать свою профессиональную философию. Благодаря каналу, я имею бесценную возможность узнать, насколько хорошо я доношу мысль и как эта мысль воспринимается. А еще благодаря каналу у меня появился моральный компас, благодаря которому мне в моменте становится понятно, какие решения стоит принимать.
Переходя к банальностям. Нас много, и у всех желания разные. Кто-то хочет реализоваться, кто-то хочет завершить проект, а кто-то просто хочет найти работу. Но я верю, что всех нас объединяет желание создавать. Создавать новую ценность в мире, создать новый продукт, который изменит жизнь многих людей к лучшему. Да хотя бы найти работу, чтобы изменить свою жизнь к лучшему.
Именно поэтому мне бы хотелось, чтобы новый год прошел под флагом созидания. Чтобы у нас у всех было это желание создавать, чтобы находились силы, и чтобы оно получалось. И даже если сейчас картина выглядит мрачной, я всегда вспоминаю, что самый темный час бывает перед рассветом.
Спасибо всем нам, что были в этом году здесь, и увидимся в следующем. С Новым Годом
🔥21❤9🎄4☃3👍3🤗1
🛌 Я разучился отдыхать...
Год начался как-то странно. Я впервые словил синдром чистого листа. Когда хочется что-то написать, но ты смотришь на чистый лист (пустой документ) и ничего не пишешь.
Помимо этого, я выяснил, что не умею отдыхать. Совсем не умею. Единственный способ отдохнуть - это уехать, оставив ноутбук дома, а телефон выключить. Если этого не сделать, то свободное от работы время я либо пишу код для своих проектов, либо учусь, либо прокрастинацирую. Ничего из этого не является отдыхом.
Я всегда жил в парадигме, что любую минуту надо проводить с пользой. В итоге перегнул палку. С психологом мы пытались выяснить, как можно отдохнуть, не вгоняя себя в новый челендж. В итоге, ничего не придумав, я решил попробовать совершенно разные вещи. Поэтому мне нужна ваша помощь. Расскажите, кто и чем занимается в свободное от работы время? Что вам дарит приятные эмоции и заряжает перед новой трудовой неделей?
Если по каким-то причинам не хочется писать тут, можно написать мне в личку. Я соберу эту информацию и создам отдельный пост. Но в первую очереь это важно для меня
Год начался как-то странно. Я впервые словил синдром чистого листа. Когда хочется что-то написать, но ты смотришь на чистый лист (пустой документ) и ничего не пишешь.
Помимо этого, я выяснил, что не умею отдыхать. Совсем не умею. Единственный способ отдохнуть - это уехать, оставив ноутбук дома, а телефон выключить. Если этого не сделать, то свободное от работы время я либо пишу код для своих проектов, либо учусь, либо прокрастинацирую. Ничего из этого не является отдыхом.
Я всегда жил в парадигме, что любую минуту надо проводить с пользой. В итоге перегнул палку. С психологом мы пытались выяснить, как можно отдохнуть, не вгоняя себя в новый челендж. В итоге, ничего не придумав, я решил попробовать совершенно разные вещи. Поэтому мне нужна ваша помощь. Расскажите, кто и чем занимается в свободное от работы время? Что вам дарит приятные эмоции и заряжает перед новой трудовой неделей?
Если по каким-то причинам не хочется писать тут, можно написать мне в личку. Я соберу эту информацию и создам отдельный пост. Но в первую очереь это важно для меня
👍14
👩💻 Исчезнет ли профессия программиста?
Попалось мне видео о скором исчезновении нас, программистов. Не знаю, связано ли это с видео, но несколько человек написали мне в личку с похожим вопросом. И я понимаю, почему этот вопрос волнует. Новичкам непонятно, стоит ли идти в профессию. "Старичкам" страшно потерять хлебное место и бесплатный тыквенный рай в офисе.
👀 У страха глаза велики.
Еще Дорофеев писал, что в моменте мы увеличиваем важность проблемы. Таково свойство нашей психики. Хотя если подумать о проблеме постфактум, она может оказаться вообще не самой крупной.
Профессию программиста периодически хоронят, но после того, как апокалипсис не случился, внимание переключается на новую опасность.
☎️ Телефонистки все.
Телефонистки и кучеры - вот две профессии, которые часто приводят как пример. Да, сложно спорить с тем, что АТС автоматизировали процесс соединения. Впрочем, я как-то писал про операторов технологии, но профессия программиста куда шире. Технологии приходят и уходят, как приходят и уходят инструменты. Хороший специалист может переключаться и менять инструменты в зависимости от конкретной ситуации. Те же телефонистки, преданные работе с телефоном, наверняка имели возможность переквалифицироваться в секретарей.
💾 Ничего не проходит бесследно.
Но главный довод ко мне пришел после просмотра сериала "Кибердеревня". Вообще вся культура киберпанка построена на том, что никакие технологии и подходы не проходят бесследно. Весь киберпанк строится на том, что современные технологии неплохо уживаются с устаревшими. И это легко встретить в реальной жизни. Я легко представляю бабушку, которая на обочине продает грибочки и при этом принимает оплату со своего смартфона. Самый настоящий киберпанк в российских реалиях.
И это, видимо, просто особенность эволюции в этом мире. В других областях то же самое.
Угольная энергетика - грязная и неэффективная. Она использовалась на заре промышленной революции. А потом на смену пришли новые источники энергии, более эффективные, чистые и дешевые. Но если посмотреть на график потребления угля за 100 лет, потребление его не стало меньше. В процентах от всего потребления, конечно, доля падает, но в реальных числах она даже растет.
Да и эволюция живых организмов работает так же. Существующие системы не отмирают и не выбрасываются, они просто видоизменяются под новые задачи.
📸 Минутка профотографию.
Вообще этот Дамоклов меч кажется висит над всеми творческими профессиями. Кажется, фотографы должны пойти на биржу труда еще раньше программистов. Но там все поняли, что красивая картинка - это не все. Важнее смысл, который лежит в этом изображении, подтексты, переплетение актуальных течений. Все то, что мы передаем друг другу, общаясь. Все то, что волнует нас как людей.
Помню, когда я начинал программировать, все вокруг предупреждали, что программистам нужно постоянно учиться. C тех пор ничего не поменялось. Нам нужно постоянно учиться, осваивать не только новые технологии, но и новые инструменты. Я не исключаю, что в какой-то момент процесс программирования изменится, и мы перестанем писать код, а будем писать промпты. Но всегда останутся люди, которые будут готовы делегировать эту задачу кому-то.
Программисты исчезнут в тот момент, когда этот мир перестанет быть миром людей. А пока просто нужно быть готовыми вкладываться в свою актуальность.
Написать мне | Поддержать Канал
Попалось мне видео о скором исчезновении нас, программистов. Не знаю, связано ли это с видео, но несколько человек написали мне в личку с похожим вопросом. И я понимаю, почему этот вопрос волнует. Новичкам непонятно, стоит ли идти в профессию. "Старичкам" страшно потерять хлебное место и бесплатный тыквенный рай в офисе.
👀 У страха глаза велики.
Еще Дорофеев писал, что в моменте мы увеличиваем важность проблемы. Таково свойство нашей психики. Хотя если подумать о проблеме постфактум, она может оказаться вообще не самой крупной.
Профессию программиста периодически хоронят, но после того, как апокалипсис не случился, внимание переключается на новую опасность.
☎️ Телефонистки все.
Телефонистки и кучеры - вот две профессии, которые часто приводят как пример. Да, сложно спорить с тем, что АТС автоматизировали процесс соединения. Впрочем, я как-то писал про операторов технологии, но профессия программиста куда шире. Технологии приходят и уходят, как приходят и уходят инструменты. Хороший специалист может переключаться и менять инструменты в зависимости от конкретной ситуации. Те же телефонистки, преданные работе с телефоном, наверняка имели возможность переквалифицироваться в секретарей.
💾 Ничего не проходит бесследно.
Но главный довод ко мне пришел после просмотра сериала "Кибердеревня". Вообще вся культура киберпанка построена на том, что никакие технологии и подходы не проходят бесследно. Весь киберпанк строится на том, что современные технологии неплохо уживаются с устаревшими. И это легко встретить в реальной жизни. Я легко представляю бабушку, которая на обочине продает грибочки и при этом принимает оплату со своего смартфона. Самый настоящий киберпанк в российских реалиях.
И это, видимо, просто особенность эволюции в этом мире. В других областях то же самое.
Угольная энергетика - грязная и неэффективная. Она использовалась на заре промышленной революции. А потом на смену пришли новые источники энергии, более эффективные, чистые и дешевые. Но если посмотреть на график потребления угля за 100 лет, потребление его не стало меньше. В процентах от всего потребления, конечно, доля падает, но в реальных числах она даже растет.
Да и эволюция живых организмов работает так же. Существующие системы не отмирают и не выбрасываются, они просто видоизменяются под новые задачи.
📸 Минутка профотографию.
Вообще этот Дамоклов меч кажется висит над всеми творческими профессиями. Кажется, фотографы должны пойти на биржу труда еще раньше программистов. Но там все поняли, что красивая картинка - это не все. Важнее смысл, который лежит в этом изображении, подтексты, переплетение актуальных течений. Все то, что мы передаем друг другу, общаясь. Все то, что волнует нас как людей.
Помню, когда я начинал программировать, все вокруг предупреждали, что программистам нужно постоянно учиться. C тех пор ничего не поменялось. Нам нужно постоянно учиться, осваивать не только новые технологии, но и новые инструменты. Я не исключаю, что в какой-то момент процесс программирования изменится, и мы перестанем писать код, а будем писать промпты. Но всегда останутся люди, которые будут готовы делегировать эту задачу кому-то.
Программисты исчезнут в тот момент, когда этот мир перестанет быть миром людей. А пока просто нужно быть готовыми вкладываться в свою актуальность.
Написать мне | Поддержать Канал
👍22❤2🔥1
🎓 Права программиста
Когда-то я работал на автомойке. У этой работы было одно неоспоримое преимущество - она была понятной. Я знал, что нужно делать и чего не нужно. А еще у меня была должностная инструкция, в которой были четко прописаны не только обязанности, но и мои права.
У официально работающих IT-ников тоже есть должностные инструкции, но написаны они максимально размыто, поскольку это формальность. Но будет неверным сказать, что программисты бесправные. Значит, права есть.
🙃 Рафик не виноват...
Я видел много плохого кода. Скажу больше, я сам много писал плохого кода. И не всегда это происходило из-за отсутствия необходимых знаний. Иногда мне просто не давали написать его хорошо.
Нюанс в том, что качество реализации задачи гораздо более сложная метрика, чем попадание в сроки. Поэтому уложиться в срок для многих менеджеров важнее, чем выпустить качественный продукт. Поэтому первое право программиста, которое я бы хотел зафиксировать:
🖼️ Сделайте мне красиво
Помните короткометражку "7 красных линий"? Сейчас я улыбаюсь, пересматривая ее, но на каком-то этапе мне хотелось плакать от таких ситуаций. Но это скорее крайний случай.
Чаще команды разработки просто не получают информацию в полном объеме. Кто-то играет в шпионов и боится кражи идей, кто-то забывает сообщить команде о новых вводных или изменяющихся целях. Но факт остается фактом: команда либо изначально не вкурсе обо всех нюансах, либо не получила обновление информации, и в итоге сделала не то.
Поэтому следующее право разработчика:
🆘 SOS
Мир IT огромный, существует множество технологий, подходов и нестандартных велосипедов. Поэтому я не вижу ничего страшного в признании, что ты чего-то не знаешь, и в просьбе о помощи у коллег. Но при этом это должна быть именно просьба помочь разобраться, а не решить проблему.
Ну и конечно, помогать самому, если кто-то просит такую помощь.
☎️ Александр Павлович попросил...
Теперь о личном. Я с удовольствием беру ответственность за задачи или проекты. Я стараюсь сделать их в срок, а если не получается, переживаю и делаю все, чтобы успеть. А если меня хорошо попросить, то я возьму что-то дополнительное. А если поднажать, то возьму еще... В итоге мы впихиваем в меня задачи, пока я не начну впадать в депрессию. Именно поэтому я считаю, что любой разработчик.
🫒 И как теперь с этим жить?
В идеале обсудить эти права с командой и заказчиком. Возможно, что-то поменять, возможно, дополнить или убрать. Признать и зафиксировать где-то, что такие права теперь есть у команды. И при случае применять их.
Но всегда эти правила можно использовать как моральный ориентир при принятии решений.
Может стоит еще что-то добавить? Давай обсудим это в комментариях
Подсмотрено из книги "Чистый Agile".
Написать мне | Поддержать Канал
Когда-то я работал на автомойке. У этой работы было одно неоспоримое преимущество - она была понятной. Я знал, что нужно делать и чего не нужно. А еще у меня была должностная инструкция, в которой были четко прописаны не только обязанности, но и мои права.
У официально работающих IT-ников тоже есть должностные инструкции, но написаны они максимально размыто, поскольку это формальность. Но будет неверным сказать, что программисты бесправные. Значит, права есть.
🙃 Рафик не виноват...
Я видел много плохого кода. Скажу больше, я сам много писал плохого кода. И не всегда это происходило из-за отсутствия необходимых знаний. Иногда мне просто не давали написать его хорошо.
Нюанс в том, что качество реализации задачи гораздо более сложная метрика, чем попадание в сроки. Поэтому уложиться в срок для многих менеджеров важнее, чем выпустить качественный продукт. Поэтому первое право программиста, которое я бы хотел зафиксировать:
Право выполнять работу качественно, несмотря ни на какие обстоятельства. Задача должна быть выполнена в лучшем виде, несмотря на любые обстоятельства.
🖼️ Сделайте мне красиво
Помните короткометражку "7 красных линий"? Сейчас я улыбаюсь, пересматривая ее, но на каком-то этапе мне хотелось плакать от таких ситуаций. Но это скорее крайний случай.
Чаще команды разработки просто не получают информацию в полном объеме. Кто-то играет в шпионов и боится кражи идей, кто-то забывает сообщить команде о новых вводных или изменяющихся целях. Но факт остается фактом: команда либо изначально не вкурсе обо всех нюансах, либо не получила обновление информации, и в итоге сделала не то.
Поэтому следующее право разработчика:
Знать, что требуется от команды, а также иметь четкое представление о поставленных приоритетах.
🆘 SOS
Мир IT огромный, существует множество технологий, подходов и нестандартных велосипедов. Поэтому я не вижу ничего страшного в признании, что ты чего-то не знаешь, и в просьбе о помощи у коллег. Но при этом это должна быть именно просьба помочь разобраться, а не решить проблему.
Получать помощь от коллег, руководителей и самих клиентов.
Ну и конечно, помогать самому, если кто-то просит такую помощь.
☎️ Александр Павлович попросил...
Теперь о личном. Я с удовольствием беру ответственность за задачи или проекты. Я стараюсь сделать их в срок, а если не получается, переживаю и делаю все, чтобы успеть. А если меня хорошо попросить, то я возьму что-то дополнительное. А если поднажать, то возьму еще... В итоге мы впихиваем в меня задачи, пока я не начну впадать в депрессию. Именно поэтому я считаю, что любой разработчик.
Поэтому программист имеет право брать на себя личную ответственность и не позволять возлагать на себя лишнее.
🫒 И как теперь с этим жить?
В идеале обсудить эти права с командой и заказчиком. Возможно, что-то поменять, возможно, дополнить или убрать. Признать и зафиксировать где-то, что такие права теперь есть у команды. И при случае применять их.
Но всегда эти правила можно использовать как моральный ориентир при принятии решений.
Может стоит еще что-то добавить? Давай обсудим это в комментариях
Подсмотрено из книги "Чистый Agile".
Написать мне | Поддержать Канал
🔥21👍7👏2
🧑🚒 Стоит ли спасать своего руководителя?
Какое-то время назад я писал пост о том, что премировать сотрудника должна команда, а не руководитель. Тогда со мной многие не согласились, но есть еще один интересный пример.
Представим себе ситуацию. Руководитель, по каким-то причинам, стал хуже справляться со своими обязанностями. Возможно, по неопытности, плохому самочувствию или из-за обилия этих самых обязанностей. Сотрудник видит этот пробел и берет на себя часть функций руководителя. Никто не просит об этом сотрудника. Он просто хочет сдать проект в срок.
Естественно, что когда приходит время оценивать результаты, сотрудник хочет, чтобы это отметили. Его главный аргумент простой что он делал работу выше своей должности.
🧑🏫 Теперь пофантазируем от лица руководителя. Он понимает, что работает хуже, и ему бы не хотелось обращать на это внимание своего руководства. Но и подчиненного отметить тоже надо. Явный конфликт интересов.
Человек так устроен, что единоличная власть заставляет принимать эгоистичные решения. Этого не происходит, если решение о премировании принимается открыто и всей командой. Хорошей аналогией тут будет суд присяжных.
Коллегиальное принятие решений - это тоже не панацея. Недоверие может извратить любое хорошее начинание. Если в компании существует доверие между сотрудниками, то не так страшно признаться в проблемах с производительностью, как и не страшно признать успехи другого.
Но это долгий путь, гораздо проще одного уволить, а второго уволить попозже, когда еще пару раз обжжется и выгорит.
Написать мне | Поддержать Канал
Какое-то время назад я писал пост о том, что премировать сотрудника должна команда, а не руководитель. Тогда со мной многие не согласились, но есть еще один интересный пример.
Представим себе ситуацию. Руководитель, по каким-то причинам, стал хуже справляться со своими обязанностями. Возможно, по неопытности, плохому самочувствию или из-за обилия этих самых обязанностей. Сотрудник видит этот пробел и берет на себя часть функций руководителя. Никто не просит об этом сотрудника. Он просто хочет сдать проект в срок.
Естественно, что когда приходит время оценивать результаты, сотрудник хочет, чтобы это отметили. Его главный аргумент простой что он делал работу выше своей должности.
🧑🏫 Теперь пофантазируем от лица руководителя. Он понимает, что работает хуже, и ему бы не хотелось обращать на это внимание своего руководства. Но и подчиненного отметить тоже надо. Явный конфликт интересов.
Человек так устроен, что единоличная власть заставляет принимать эгоистичные решения. Этого не происходит, если решение о премировании принимается открыто и всей командой. Хорошей аналогией тут будет суд присяжных.
Коллегиальное принятие решений - это тоже не панацея. Недоверие может извратить любое хорошее начинание. Если в компании существует доверие между сотрудниками, то не так страшно признаться в проблемах с производительностью, как и не страшно признать успехи другого.
Но это долгий путь, гораздо проще одного уволить, а второго уволить попозже, когда еще пару раз обжжется и выгорит.
Написать мне | Поддержать Канал
👍14❤2👎1
🩼 Выученная беспомощность
На прошлой неделе делал задачу от маркетологов. У меня ушло около часа, чтобы разобраться с кодом. После чего стало понятно, что для решения нужно заменить национальный домен. Вместо .ru ставить .kz/.by и т.д.
Но поскольку задача сильно далека от зоны ответственности нашей команды, то она пролежала в беклоге почти месяц. Мне эта задача досталась только потому, что год назад я как раз таки и делал редирект на национальные домены для таких страниц.
📆 Можно ли было не ждать месяц?
Ребята регулярно приходили к нам и узнавали статус. Значит, она была у них достаточно срочной. Я подозревал, что решение может оказаться таким, поэтому спросил у ребят, знают ли они подобные страницы для других стран. На не получил внятного ответа.
Если бы я был на их месте, я бы в первую очередь поискал бы похожий функционал. После чего попробовал бы заменить национальный домен. Они потому ко мне и пришли, что я настраивал такой редирект для других страниц. Возможно, без деталей это выглядит непонятно, но, поверьте, до этого правда просто догадаться.
Можно, конечно, раскритиковать ребят, но я задался вопросом, а почему так могло получиться?
🤔 А почему бы не попробовать самому?
Часто причиной является выученная беспомощность. Это состояние, при котором человек не верит, что способен решить задачу.
За собой я тоже иногда такое замечаю. Когда прихожу к ребятам с бекенда или натива с вопросом. А когда получаю ответ - понимаю, что в целом и сам мог бы разобраться.
В чем причина такого состояния?
👆 Недостаток опыта: недостаток знаний в конкретной технологии или недостаток общего опыта работы. Молодому специалисту действительно страшно ошибиться и опозориться перед коллегами. Это может привести к тому, что появляется привычка каждый раз идти к коллеге за помощью.
✌️ Низкая самооценка: работает как недостаток знания, за исключением того, что низкую самооценку можно компенсировать атмосферой в команде и адекватной обратной связью.
🤟 Недостаток коммуникации: недостаток вводных данных приводит к неверному решению, а это в свою очередь к негативному фидбеку. Если это случается постоянно, сотрудник просто перестает проявлять инициативу.
🖖 Негативная обстановка: чаще всего характеризуется избыточным негативным фидбеком над позитивным. Это может привести как к неуверенности в себе или своих знаниях, так и недоверию к получаемой информации. А дальше все как в пунктах выше.
Самое главное, что нужно знать об этом состоянии - оно обратимо.
⬆️ Как выйти из состояния выученной беспомощности?
Половина решения проблемы - это признание, что она есть. А дальше путем рефлексии прийти к причинам такого состояния и уже работать с ними.
Дальнейшие шаги станут понятны после понимания причины такого состояния. Если это недостаток опыта или знаний - то их можно получить, сходив на курсы.
Мы привыкли списывать такое поведение на лень, менталитет или еще что-то. Но я верю, что подавляющее большинство людей хорошие и хотят хорошо делать свою работу. Если они этого не делают, не стоит их обвинять, а нужно просто помочь.
Написать мне | Поддержать Канал
На прошлой неделе делал задачу от маркетологов. У меня ушло около часа, чтобы разобраться с кодом. После чего стало понятно, что для решения нужно заменить национальный домен. Вместо .ru ставить .kz/.by и т.д.
Но поскольку задача сильно далека от зоны ответственности нашей команды, то она пролежала в беклоге почти месяц. Мне эта задача досталась только потому, что год назад я как раз таки и делал редирект на национальные домены для таких страниц.
📆 Можно ли было не ждать месяц?
Ребята регулярно приходили к нам и узнавали статус. Значит, она была у них достаточно срочной. Я подозревал, что решение может оказаться таким, поэтому спросил у ребят, знают ли они подобные страницы для других стран. На не получил внятного ответа.
Если бы я был на их месте, я бы в первую очередь поискал бы похожий функционал. После чего попробовал бы заменить национальный домен. Они потому ко мне и пришли, что я настраивал такой редирект для других страниц. Возможно, без деталей это выглядит непонятно, но, поверьте, до этого правда просто догадаться.
Можно, конечно, раскритиковать ребят, но я задался вопросом, а почему так могло получиться?
🤔 А почему бы не попробовать самому?
Часто причиной является выученная беспомощность. Это состояние, при котором человек не верит, что способен решить задачу.
За собой я тоже иногда такое замечаю. Когда прихожу к ребятам с бекенда или натива с вопросом. А когда получаю ответ - понимаю, что в целом и сам мог бы разобраться.
В чем причина такого состояния?
👆 Недостаток опыта: недостаток знаний в конкретной технологии или недостаток общего опыта работы. Молодому специалисту действительно страшно ошибиться и опозориться перед коллегами. Это может привести к тому, что появляется привычка каждый раз идти к коллеге за помощью.
✌️ Низкая самооценка: работает как недостаток знания, за исключением того, что низкую самооценку можно компенсировать атмосферой в команде и адекватной обратной связью.
🤟 Недостаток коммуникации: недостаток вводных данных приводит к неверному решению, а это в свою очередь к негативному фидбеку. Если это случается постоянно, сотрудник просто перестает проявлять инициативу.
🖖 Негативная обстановка: чаще всего характеризуется избыточным негативным фидбеком над позитивным. Это может привести как к неуверенности в себе или своих знаниях, так и недоверию к получаемой информации. А дальше все как в пунктах выше.
Самое главное, что нужно знать об этом состоянии - оно обратимо.
⬆️ Как выйти из состояния выученной беспомощности?
Половина решения проблемы - это признание, что она есть. А дальше путем рефлексии прийти к причинам такого состояния и уже работать с ними.
Дальнейшие шаги станут понятны после понимания причины такого состояния. Если это недостаток опыта или знаний - то их можно получить, сходив на курсы.
Мы привыкли списывать такое поведение на лень, менталитет или еще что-то. Но я верю, что подавляющее большинство людей хорошие и хотят хорошо делать свою работу. Если они этого не делают, не стоит их обвинять, а нужно просто помочь.
Написать мне | Поддержать Канал
👍21
🙏 Очень неловко получилось...
Решил немного поменторить студентов. Пришел к куратору от МФТИ и говорю, могу взять на попечение одного-двух студентов. Поскольку я написал не один десяток телеграм-ботов, поэтому хотел бы взять схожий проект.
Куратор обрадовался, говорит, "ну телеграм-боты - это вообще топ". Поскольку это типичная практическая задача, а студенты как раз в этом семестре изучают JavaScript.
Я заострил внимание, что хочу менторить именно по серверному JS, куратор кивал головой и соглашался.
📅 Назначаю встречу - знакомство со студентами. За 15 минут до нее куратор пишет, что не придет. Я напрягся, но подумал, что с парой студентов я справлюсь.
Созвонились, познакомились, начали обсуждать проект. Студенты уже представляют примерный план работы и начертили схему. Говорят, "вот тут у нас будет база, вот тут сделаем очередь из Kafka или RabbitMQ, а вот тут несколько микросервисов на Spring".
"На чем?" - поперхнулся я. "Вы хотите писать на Java?"
Они говорят, "ну да, мы вот ее проходим, хотелось бы закрепить".
🤦 На заре моей карьеры ко мне часто приходили рекрутеры и спрашивали про опыт работы с Java. Для не знающего человека, что Java, что JavaScript - одно непонятнее другого. Но те времена остались в прошлом, наивно думал я.
Я оказался в очень неловкой ситуации. С одной стороны, я могу c умной миной продолжать распрашивать про проект. Могу даже дать пару замечаний. С другой стороны, если ко мне придет студент с вопросом про Spring, то я, скорее всего, не отвечу.
В общем, говорю ребята, я не спец в Spring'е. Давайте мы на этом разговор закончим, я обсужу ситуацию с куратором, и если мы решим, что я смогу вам помочь как менеджер, то я накидаю вам план и обсудим более детальную реализацию.
Написал куратору, тот очень долго извинялся, говорит, "очень неловко получилось". Ну и согласился, что проект не большой - менеджер не нужен. Нужен кто-то с техническим бекграундом.
На этом и порешили.
Через неделю, лежу я с температурой, а мне пишет мне какой-то чувак и хочет обсудить план разработки. Я подумал, что он с работы, и сказал, что я на больничном, а это оказался студент. Их бедолаги, даже не предупредили, что я не смогу их вести.
😞 Очень неловко получилось...
Написать мне | Поддержать Канал
Решил немного поменторить студентов. Пришел к куратору от МФТИ и говорю, могу взять на попечение одного-двух студентов. Поскольку я написал не один десяток телеграм-ботов, поэтому хотел бы взять схожий проект.
Куратор обрадовался, говорит, "ну телеграм-боты - это вообще топ". Поскольку это типичная практическая задача, а студенты как раз в этом семестре изучают JavaScript.
Я заострил внимание, что хочу менторить именно по серверному JS, куратор кивал головой и соглашался.
📅 Назначаю встречу - знакомство со студентами. За 15 минут до нее куратор пишет, что не придет. Я напрягся, но подумал, что с парой студентов я справлюсь.
Созвонились, познакомились, начали обсуждать проект. Студенты уже представляют примерный план работы и начертили схему. Говорят, "вот тут у нас будет база, вот тут сделаем очередь из Kafka или RabbitMQ, а вот тут несколько микросервисов на Spring".
"На чем?" - поперхнулся я. "Вы хотите писать на Java?"
Они говорят, "ну да, мы вот ее проходим, хотелось бы закрепить".
🤦 На заре моей карьеры ко мне часто приходили рекрутеры и спрашивали про опыт работы с Java. Для не знающего человека, что Java, что JavaScript - одно непонятнее другого. Но те времена остались в прошлом, наивно думал я.
Я оказался в очень неловкой ситуации. С одной стороны, я могу c умной миной продолжать распрашивать про проект. Могу даже дать пару замечаний. С другой стороны, если ко мне придет студент с вопросом про Spring, то я, скорее всего, не отвечу.
В общем, говорю ребята, я не спец в Spring'е. Давайте мы на этом разговор закончим, я обсужу ситуацию с куратором, и если мы решим, что я смогу вам помочь как менеджер, то я накидаю вам план и обсудим более детальную реализацию.
Написал куратору, тот очень долго извинялся, говорит, "очень неловко получилось". Ну и согласился, что проект не большой - менеджер не нужен. Нужен кто-то с техническим бекграундом.
На этом и порешили.
Через неделю, лежу я с температурой, а мне пишет мне какой-то чувак и хочет обсудить план разработки. Я подумал, что он с работы, и сказал, что я на больничном, а это оказался студент. Их бедолаги, даже не предупредили, что я не смогу их вести.
😞 Очень неловко получилось...
Написать мне | Поддержать Канал
😁21🌚10😢9❤5💔3👍1
📌 Куда я попал?
Я заметил, что пока я отдыхал от новых постов, много людей подписалось на канал, а из последних постов едва ли понятно, о чем он.
Меня зовут Леша, и я веду этот канал. Я программист с достаточно большим опытом, и сейчас работаю в Яндексе. Этот канал появился как дополнение к моему ютуб-каналу, посвященному первым шагам в IT. Но со временем ютуб стал мне не интересен и заглох, а вот телеграм-канал превратился во что-то независимое.
Здесь я рассказываю про свой опыт в IT, поднимаю философские, иногда сложные вопросы. Иногда делаю обзоры книг, выписывая сюда ключевые моменты, которые выделил для себя. В общем, это своеобразный склад моего опыта.
Кому будет интересно:
🤘 Тем, кто интересуется, как оно тут устроено. Если ты думаешь, что здесь страна эльфов, это лучшее место, чтобы понять, что это не так. Есть вещи, которые устроены лучше, чем в других сферах, есть, которые хуже, но тут, как и везде, работают люди.
✌️ Тем, кто уже работает и хочет понять больше. Иногда полезно не просто знать про проблемы, но еще и подсмотреть, как другие их решают.
🖖 Тем, кто ушел и ностальгирует. Да, да, такие тоже есть.
Если у тебя есть вопрос, и ты хочешь мне его задать - велкам, но сэкономь мое время, и погугли. А если нагуглить не получилось, то пиши вопрос сразу в первом сообщении.
Я заметил, что пока я отдыхал от новых постов, много людей подписалось на канал, а из последних постов едва ли понятно, о чем он.
Меня зовут Леша, и я веду этот канал. Я программист с достаточно большим опытом, и сейчас работаю в Яндексе. Этот канал появился как дополнение к моему ютуб-каналу, посвященному первым шагам в IT. Но со временем ютуб стал мне не интересен и заглох, а вот телеграм-канал превратился во что-то независимое.
Здесь я рассказываю про свой опыт в IT, поднимаю философские, иногда сложные вопросы. Иногда делаю обзоры книг, выписывая сюда ключевые моменты, которые выделил для себя. В общем, это своеобразный склад моего опыта.
Кому будет интересно:
🤘 Тем, кто интересуется, как оно тут устроено. Если ты думаешь, что здесь страна эльфов, это лучшее место, чтобы понять, что это не так. Есть вещи, которые устроены лучше, чем в других сферах, есть, которые хуже, но тут, как и везде, работают люди.
✌️ Тем, кто уже работает и хочет понять больше. Иногда полезно не просто знать про проблемы, но еще и подсмотреть, как другие их решают.
🖖 Тем, кто ушел и ностальгирует. Да, да, такие тоже есть.
Если у тебя есть вопрос, и ты хочешь мне его задать - велкам, но сэкономь мое время, и погугли. А если нагуглить не получилось, то пиши вопрос сразу в первом сообщении.
🔥20👍4🤡1
😷 Дилемма анонимных опросов
В DC в конце каждого спринта мы отвечали на вопрос “Пойдешь учить 1С?” Это был наш индикатор - чем хуже проходил спринт, тем больше желание пойти писать на 1С, ане вме это.
Вообще опросы - отличный инструмент, чтобы получить текущее состояние. А если задавать один и тот же вопрос регулярно, можно получить динамику. И это, на мой взгляд, основная фишка опросов.
Почти все опросы в компании проводятся анонимно. Это дает иллюзию безопасности и помогает сказать респонденту правду. Иллюзия заключается в том, что вычислить можно кого угодно.
Поэтому анонимность в данном случае - джентльменское соглашение. Один верит, что его не будут искать, а интервьюер другие не переходят на личности.
Недавно попал в ситуацию, когда этот договор был нарушен. Разговаривал с лидом, и он сказал, что хотел бы обсудить мои ответы в анонимном опросе.
Это действительно были мои ответы, но как я уже говорил, вычислить можно кого угодно, особенно в команде из 8 человек.
В моих ответах не было ничего такого, чего бы я не мог сказать в публичном опросе или лично. Но рефлексируя, я понял, что мне неприятно само нарушение договоренности.
Справедливости ради, стоит сказать, что мои ответы выросли из-за недопонимания в команде. У меня нет ответа, как бы я сам поступил на его месте. С одной стороны, недопонимание нужно прояснить как можно раньше. С другой, такое нарушение - это маленький шаг к недоверию. Если он будет один - ничего страшного, но если подобные ситуации возникают регулярно, мое доверие к руководителю будет падать.
Может быть вообще не использовать анонимные опросы?
В DC в конце каждого спринта мы отвечали на вопрос “Пойдешь учить 1С?” Это был наш индикатор - чем хуже проходил спринт, тем больше желание пойти писать на 1С, ане вме это.
Вообще опросы - отличный инструмент, чтобы получить текущее состояние. А если задавать один и тот же вопрос регулярно, можно получить динамику. И это, на мой взгляд, основная фишка опросов.
Почти все опросы в компании проводятся анонимно. Это дает иллюзию безопасности и помогает сказать респонденту правду. Иллюзия заключается в том, что вычислить можно кого угодно.
Поэтому анонимность в данном случае - джентльменское соглашение. Один верит, что его не будут искать, а интервьюер другие не переходят на личности.
Недавно попал в ситуацию, когда этот договор был нарушен. Разговаривал с лидом, и он сказал, что хотел бы обсудить мои ответы в анонимном опросе.
Это действительно были мои ответы, но как я уже говорил, вычислить можно кого угодно, особенно в команде из 8 человек.
В моих ответах не было ничего такого, чего бы я не мог сказать в публичном опросе или лично. Но рефлексируя, я понял, что мне неприятно само нарушение договоренности.
Справедливости ради, стоит сказать, что мои ответы выросли из-за недопонимания в команде. У меня нет ответа, как бы я сам поступил на его месте. С одной стороны, недопонимание нужно прояснить как можно раньше. С другой, такое нарушение - это маленький шаг к недоверию. Если он будет один - ничего страшного, но если подобные ситуации возникают регулярно, мое доверие к руководителю будет падать.
Может быть вообще не использовать анонимные опросы?
👍16🤯7🔥2🌚1
😒 Подошёл к концу большой период в моей жизни. Я ушёл из фудтеха после 4-х лет работы в этом направлении.
Вообще, я его не выбирал. Долгое время я не задумывался о том, в какой сфере работать. Правда, на интервью я говорил, что хочется делать мир лучше, но на практике крайне редко применял эту оценку к своей работе. Но чем старше я становился, тем больше начинал ценить своё время и силы. И тем больше мне хотелось вкладывать их во что-то правильное для моего морального компаса.
Сразу хочу оговориться, что правильность в этом посте понятие сугубо субъективное. Я могу что-то считать плохим, но это совершенно не означает, что такой компании не должно существовать или люди в ней тоже плохие. Это означает только то, что я не хотел бы там работать.
Например, я бы не хотел работать в компании, разрабатывающей социальные сети. Бизнес-модель базируется на том, что сначала они вовлекают пользователя, а потом продают его внимание. Как человек, периодически "зависающий", я страдаю от этого. Но при этом я рад, что существует YouTube или ВК, на одном куча роликов про программирование, во втором удобно следить за релизами малоизвестных групп.
Фудтех для меня начался с Delivery Club. Когда я устраивался, мне очень понравился интервьюер, и процессы найма, которые проходили очень быстро. В процессе работы меня скорее волновала репутация головной компании, чем морально-этическая составляющая бизнеса.
Помню, что весь шум от бунтов курьеров прошёл мимо меня. Я понимал, что работа не простая, поскольку сам "курьерил". Но я разрабатывал приложение для ресторанов, я мог позволить не думать об этической стороне всего бизнеса.
Когда Delivery Club был поглощён Яндексом, проблема репутации головной компании исчезла. И я с головой погрузился в новые задачи.
Мне повезло, я попал в международный бизнес Яндекс.Еды. Мы называли межнар стартапом внутри Еды. И задачи у нас были очень амбициозными. Вчера ещё ничего не было, а сегодня город наполнили курьеры с желтыми или красными сумками. Я был в Ереване, когда Еда там запускалась. Видел процесс изнутри и снаружи. Очень приятно осознавать своё участие в этом.
Как и в любом стартапе, у нас была возможность побывать себя в разных ролях, ну или хотя бы познакомиться с соседними.
Так у меня окончательно сложилась картина, как устроен бизнес, из чего складывается юнит-экономика, и на чем компания зарабатывает, а на что уходят основные ресурсы. И так бизнес доставки еды оказался в серой зоне моего морального комплекса.
С одной стороны, на рынке появляется полезная услуга, которой раньше не было. С другой, такие сервисы всеми силами пытаются мотивировать пользователя потреблять больше. С одной стороны, это новые рабочие места, с другой, зарплаты курьеров — это наибольшие траты, и логично их оптимизировать.
Справедливости ради, многие сферы, если капнуть, окажутся в серой зоне. Например, интернет можно использовать для совершенно разных целей. Атомную энергию можно использовать в мирных или военных целях. Пищевая индустрия избавила нас от голода, но сделала продукты менее здоровыми. И многое другое.
Сам по себе этот вопрос не подтолкнул бы меня к увольнению. Я обдумывал его иногда, но он меня не сильно беспокоил. Но моральные вопросы становятся острыми в сложные моменты.
🏃 Мы очень быстро бежали.
Как и в любом стартапе в межнаре Еды было много задач, разных, сложных и интересных. Мы постоянно сталкивались с культурными и юридическими особенностями стран, в которых работали. Я с удовольствием погружался в контекст, брал дополнительные задачи и искал неординарные решения. Но в какой-то момент, я перестал справляться.
Часто я не мог отключиться, и даже в выходные думал о том, как лучше решить ту или иную задачу. А иногда задачи шли одна за другой, и я вроде закончил с первой, и начал вторую, но пришли доработки по первой. В итоге я часто просто не мог сконцентрироваться.
И в итоге я оказался в ситуации, когда силы кончились, а бежать все ещё нужно. Тогда в моём блоге начали появляться посты про отдых, а сами посты стали реже. И вот тут моральная составляющая вопроса вышла на сцену.
Вообще, я его не выбирал. Долгое время я не задумывался о том, в какой сфере работать. Правда, на интервью я говорил, что хочется делать мир лучше, но на практике крайне редко применял эту оценку к своей работе. Но чем старше я становился, тем больше начинал ценить своё время и силы. И тем больше мне хотелось вкладывать их во что-то правильное для моего морального компаса.
Сразу хочу оговориться, что правильность в этом посте понятие сугубо субъективное. Я могу что-то считать плохим, но это совершенно не означает, что такой компании не должно существовать или люди в ней тоже плохие. Это означает только то, что я не хотел бы там работать.
Например, я бы не хотел работать в компании, разрабатывающей социальные сети. Бизнес-модель базируется на том, что сначала они вовлекают пользователя, а потом продают его внимание. Как человек, периодически "зависающий", я страдаю от этого. Но при этом я рад, что существует YouTube или ВК, на одном куча роликов про программирование, во втором удобно следить за релизами малоизвестных групп.
Фудтех для меня начался с Delivery Club. Когда я устраивался, мне очень понравился интервьюер, и процессы найма, которые проходили очень быстро. В процессе работы меня скорее волновала репутация головной компании, чем морально-этическая составляющая бизнеса.
Помню, что весь шум от бунтов курьеров прошёл мимо меня. Я понимал, что работа не простая, поскольку сам "курьерил". Но я разрабатывал приложение для ресторанов, я мог позволить не думать об этической стороне всего бизнеса.
Когда Delivery Club был поглощён Яндексом, проблема репутации головной компании исчезла. И я с головой погрузился в новые задачи.
Мне повезло, я попал в международный бизнес Яндекс.Еды. Мы называли межнар стартапом внутри Еды. И задачи у нас были очень амбициозными. Вчера ещё ничего не было, а сегодня город наполнили курьеры с желтыми или красными сумками. Я был в Ереване, когда Еда там запускалась. Видел процесс изнутри и снаружи. Очень приятно осознавать своё участие в этом.
Как и в любом стартапе, у нас была возможность побывать себя в разных ролях, ну или хотя бы познакомиться с соседними.
Так у меня окончательно сложилась картина, как устроен бизнес, из чего складывается юнит-экономика, и на чем компания зарабатывает, а на что уходят основные ресурсы. И так бизнес доставки еды оказался в серой зоне моего морального комплекса.
С одной стороны, на рынке появляется полезная услуга, которой раньше не было. С другой, такие сервисы всеми силами пытаются мотивировать пользователя потреблять больше. С одной стороны, это новые рабочие места, с другой, зарплаты курьеров — это наибольшие траты, и логично их оптимизировать.
Справедливости ради, многие сферы, если капнуть, окажутся в серой зоне. Например, интернет можно использовать для совершенно разных целей. Атомную энергию можно использовать в мирных или военных целях. Пищевая индустрия избавила нас от голода, но сделала продукты менее здоровыми. И многое другое.
Сам по себе этот вопрос не подтолкнул бы меня к увольнению. Я обдумывал его иногда, но он меня не сильно беспокоил. Но моральные вопросы становятся острыми в сложные моменты.
🏃 Мы очень быстро бежали.
Как и в любом стартапе в межнаре Еды было много задач, разных, сложных и интересных. Мы постоянно сталкивались с культурными и юридическими особенностями стран, в которых работали. Я с удовольствием погружался в контекст, брал дополнительные задачи и искал неординарные решения. Но в какой-то момент, я перестал справляться.
Часто я не мог отключиться, и даже в выходные думал о том, как лучше решить ту или иную задачу. А иногда задачи шли одна за другой, и я вроде закончил с первой, и начал вторую, но пришли доработки по первой. В итоге я часто просто не мог сконцентрироваться.
И в итоге я оказался в ситуации, когда силы кончились, а бежать все ещё нужно. Тогда в моём блоге начали появляться посты про отдых, а сами посты стали реже. И вот тут моральная составляющая вопроса вышла на сцену.
❤21👍9