👨🏫 Как думают профессионалы?
Чтобы быть профессионалом, надо думать как профессионал. А как думает профессионал? Для примера возьмем шахматистов.
На разных уровнях своего развития шахматисты думают по-разному. Герберт Саймон провел исследование. Он несколько секунд показывал доску с фигурами. После чего предлагал повторить расстановку на пустой доске по памяти. Если нужно, исходную расстановку показывали еще раз.
Очевидно, что опытные шахматисты делали меньше ошибок, и зачастую делали это с первой попытки. Интересно тут другое - как они это делали. Исследователи фиксировали не только правильность результата, но и порядок в котором были расставлены фигуры.
Все шахматисты разделяли фигуры на группы (чанки). После чего чанки расставлялись на доске. Ключевое отличие новичков от профессионалов было в количестве таких чанков. Новички оперировали всего несколькими сотнями чанков, а иногда фигуры выстраивались и вовсе по одной. Профессионалы использовали до 50 тысяч таких схем, и никогда не используя фигуры по отдельности.
Похожим вопросом задалась группа ученых под руководством Мишлен Ши. Они предложили студентам и преподавателям физики классифицировать задачи, которые они никогда не решали.
Опять же очевидно, что профессора справились лучше. Интересен тут принцип классификации. Студенты использовали разные принципы, и иногда было непонятно, почему задачу отнесли к той или иной группе. Профессора же все использовали одну классификация - по физическому закону, заложенному в задаче. . Условно, это задача на 3-й закон ньютона, а это задача на закон сохранения энергии и т. д. Это автоматически давало решение для задачи, оставалось только произвести расчеты. А классификация задач была однозначной.
Человеческий мозг всегда работает самым экономичным образом. Оперировать маленькими единицами по отдельности дорого, будь то шахматные фигуры или отдельные задачи. Поэтому он находит закономерности и оперирует ими.
В заключении хочу снова вернуться к шахматистам. Мир шахмат сильно изменился, после появления программ способных обыграть человека. Такие программы стали незаменимыми инструментом для анализа и обучения. Они могут анализировать игры, предлагать оптимальные ходы и стратегии. А результатом уже пользуются люди для обучения.
Сейчас огромное количество профессионалов делятся своим опытом. Смотря на них можно понять как решать задачи своей сферы эффективнее, не проходя многолетний этап обучения.
Чтобы быть профессионалом, надо думать как профессионал. А как думает профессионал? Для примера возьмем шахматистов.
На разных уровнях своего развития шахматисты думают по-разному. Герберт Саймон провел исследование. Он несколько секунд показывал доску с фигурами. После чего предлагал повторить расстановку на пустой доске по памяти. Если нужно, исходную расстановку показывали еще раз.
Очевидно, что опытные шахматисты делали меньше ошибок, и зачастую делали это с первой попытки. Интересно тут другое - как они это делали. Исследователи фиксировали не только правильность результата, но и порядок в котором были расставлены фигуры.
Все шахматисты разделяли фигуры на группы (чанки). После чего чанки расставлялись на доске. Ключевое отличие новичков от профессионалов было в количестве таких чанков. Новички оперировали всего несколькими сотнями чанков, а иногда фигуры выстраивались и вовсе по одной. Профессионалы использовали до 50 тысяч таких схем, и никогда не используя фигуры по отдельности.
Похожим вопросом задалась группа ученых под руководством Мишлен Ши. Они предложили студентам и преподавателям физики классифицировать задачи, которые они никогда не решали.
Опять же очевидно, что профессора справились лучше. Интересен тут принцип классификации. Студенты использовали разные принципы, и иногда было непонятно, почему задачу отнесли к той или иной группе. Профессора же все использовали одну классификация - по физическому закону, заложенному в задаче. . Условно, это задача на 3-й закон ньютона, а это задача на закон сохранения энергии и т. д. Это автоматически давало решение для задачи, оставалось только произвести расчеты. А классификация задач была однозначной.
Человеческий мозг всегда работает самым экономичным образом. Оперировать маленькими единицами по отдельности дорого, будь то шахматные фигуры или отдельные задачи. Поэтому он находит закономерности и оперирует ими.
В заключении хочу снова вернуться к шахматистам. Мир шахмат сильно изменился, после появления программ способных обыграть человека. Такие программы стали незаменимыми инструментом для анализа и обучения. Они могут анализировать игры, предлагать оптимальные ходы и стратегии. А результатом уже пользуются люди для обучения.
Сейчас огромное количество профессионалов делятся своим опытом. Смотря на них можно понять как решать задачи своей сферы эффективнее, не проходя многолетний этап обучения.
🏝️ Иногда приходится отдыхать через силу
Я часто встречаю людей, которые не умеют отдыхать. Я и сам достаточно часто замечаю за собой желание поработать в свой выходной.
Когда я узнал про практику детокс дня - то подумал, что это будет не сложно. Оказалось, что нет. Целый день не трогать телефон, не думать о работе сложно. А если при это не потреблять никакой новой информации то практически невозможно.
В такие моменты я не только чувствую уныние. И физически ощущаю бесполезность проходящего времени. И тогда приходится заставлять себя отдыхать.
Я давно усвоил важность выходных, но не всегда отдыхал. Мыль о не дописанном коде было как заноза. Чтобы унять зуд, я договаривался с собой, мол поправлю за час, а потом отдыхать. Восемь часов спустя я находил себя в конце выходных, совершенно вымотанным, и без желания с понедельника начинать новую трудовую неделю.
Тогда я решил, что один день в неделю будет неприкасаемым. В этот день я не открываю код, не захожу в социальные сети, и не смотрю в телеграм.
Но иногда мысли о рабочих задачах не дают мне покоя. Особенно часто это происходит утром. В такие моменты я применяю гвоздодер. Кажется я вычитал эту практику у Дорофеева. 10 минут я сижу и записываю в блокнот все мысли, которые приходят в голову. Иногда 10 минут не хватает, и я делаю это до тех пор, пока мысли не приобретают ситуативный характер. Например, пролетела птица и я подумал о том, что неплохо хо бы сходить в магазин за курицей... В общем, когда я просто начинаю реагировать.
Таким образом я избавляясь от всех мыслей которые не были решения моим мозгом за предыдущие дни. Особо въедливые мысли приходится записывать по несколько раз.
Но среди них иногда бывают интересные, а иногда я неожиданно для самого себя пишу решение проблемы. Чтобы их не потерять, в конце практики я перечитываю все мысли, важные оформляю в виде задач и выписываю в свой список дел, а остальные вычеркиваю.
Практика одного детокс дня позволяет мне разорвать порочный круг: когда на работе я думаю о том, что устал и неплохо бы отдохнуть, а во время отдыха думаю о работе.
Я часто встречаю людей, которые не умеют отдыхать. Я и сам достаточно часто замечаю за собой желание поработать в свой выходной.
Когда я узнал про практику детокс дня - то подумал, что это будет не сложно. Оказалось, что нет. Целый день не трогать телефон, не думать о работе сложно. А если при это не потреблять никакой новой информации то практически невозможно.
В такие моменты я не только чувствую уныние. И физически ощущаю бесполезность проходящего времени. И тогда приходится заставлять себя отдыхать.
Я давно усвоил важность выходных, но не всегда отдыхал. Мыль о не дописанном коде было как заноза. Чтобы унять зуд, я договаривался с собой, мол поправлю за час, а потом отдыхать. Восемь часов спустя я находил себя в конце выходных, совершенно вымотанным, и без желания с понедельника начинать новую трудовую неделю.
Тогда я решил, что один день в неделю будет неприкасаемым. В этот день я не открываю код, не захожу в социальные сети, и не смотрю в телеграм.
Но иногда мысли о рабочих задачах не дают мне покоя. Особенно часто это происходит утром. В такие моменты я применяю гвоздодер. Кажется я вычитал эту практику у Дорофеева. 10 минут я сижу и записываю в блокнот все мысли, которые приходят в голову. Иногда 10 минут не хватает, и я делаю это до тех пор, пока мысли не приобретают ситуативный характер. Например, пролетела птица и я подумал о том, что неплохо хо бы сходить в магазин за курицей... В общем, когда я просто начинаю реагировать.
Таким образом я избавляясь от всех мыслей которые не были решения моим мозгом за предыдущие дни. Особо въедливые мысли приходится записывать по несколько раз.
Но среди них иногда бывают интересные, а иногда я неожиданно для самого себя пишу решение проблемы. Чтобы их не потерять, в конце практики я перечитываю все мысли, важные оформляю в виде задач и выписываю в свой список дел, а остальные вычеркиваю.
Практика одного детокс дня позволяет мне разорвать порочный круг: когда на работе я думаю о том, что устал и неплохо бы отдохнуть, а во время отдыха думаю о работе.
🤠 Правило бойскаута
Мне нравится подходы в которых происходит систематические улучшения. Даже если эти улучшения настолько маленькие, что по одному незаметны. Зато прогресс в целом меня мотивирует
Правило бойскаута именно об этом. Это философия, которая говорит о том, что каждый раз после твоих изменений кодовая база должна становиться лучше. Если каждый раз код будет становиться лучше, чище и читабельнее, то с проектом станет приятнее работать.
Но вот как-то не сложилось у меня с нравилось бойскаута, как и с другими общепризнанными практиками.
Я считаю, что во время реализации фичи, нужно сконцентрироваться именно на реализации этой фичи. Я всегда стараюсь сделать новый функционал максимально независимым от существующего функционала. А в идеале и новую фичу закрыть фиче тонком.
Мой опыт подсказывает, что незапланированный рефакторинг приведет к проблемам. Правя чужой код не всегда понятен весь контекст задач, в которой он выполнялся. А самое неприятное, что тебе может казаться, что ты понимаешь, но это не так. В таких условиях пропустить какой-то случай, и наплодить ошибок очень просто.
Так же такой подход противоречит правильной работе с системой контроля версий. В одном комитете должны быть атомарные изменения. В идеале один коммит (Или ветка, если так удобнее) - одна фича. Такой подход позволяет с одной стороны переиспользовать функционал если он еще не влит в основную ветку, а с другой стороны точно понимать, какого рода изменения были в фиче, и откатить ее.
Представь себе ситуацию, когда ты добавляешь код валидирующий форму на страницу, а попутно правишь роутинг приложения. Будет весело потом искать в каком комите приложение стало неправильно перенаправлять пользователя.
Тем не менее, я не считаю, что правило бойскаута совершенно неприменимо. Как я говорил выше такая философия очень близка мне. Просто оно не работает для больших интерплайзных приложений. В которых стабильность гораздо важнее скорости разработки фичи. Все большие приложения стараются не падать, поскольку каждое падение это потеря денег и аудитории. А вот в Стартапах, где скорость разработки это скорее вопрос выживаемости правило бойскаута может в недалеком будущем принести бенефиты;
Но даже в больших и устоявшихся приложениях, правило бойскаута можно применять. Только бойскаут должен быть не таким резким, и не должен сразу бросаться в бой. В таких приложениях все нужно делать через берлог.
Например я пилю фичу, и понимаю, что было бы неплохо отрефакторить текущий функционал, и вынести переиспользуемый код в отдельный модуль. Я делю сво фичу на две интерации. В первой итерации я пишу фичу без рефакторинга, возможно даже с дублированием кода. Зато это позволяет мне не трогать существующий функционал, а так же скрыть новую фичу под фиче тонком.
После чего завожу задачу на рефакторинг и кладу ее в беклог. Во время каждого спринта у меня есть время, когда я закрываю технический долги, именно тогда, я могу сделать код лучше.
В этом случае бизнес не получит рабочую фичу быстрее. Тестировщики будут иметь тест кейсы на старый и новый функционал и им будет проще тестировать техническую задачу на рефакторинг. Ну а я как пожилой и занудный бойскаут сделаю код лучше. А еще бывают ситуации, когда после релиза новой фичи становится очевидно, что она работе и не так, должна работать по-другому, или вовсе не нужна.
И тогда мне гораздо проще удалить сепарированный код, и не оставлять в коде ненужные абстракции.
Мне нравится подходы в которых происходит систематические улучшения. Даже если эти улучшения настолько маленькие, что по одному незаметны. Зато прогресс в целом меня мотивирует
Правило бойскаута именно об этом. Это философия, которая говорит о том, что каждый раз после твоих изменений кодовая база должна становиться лучше. Если каждый раз код будет становиться лучше, чище и читабельнее, то с проектом станет приятнее работать.
Но вот как-то не сложилось у меня с нравилось бойскаута, как и с другими общепризнанными практиками.
Я считаю, что во время реализации фичи, нужно сконцентрироваться именно на реализации этой фичи. Я всегда стараюсь сделать новый функционал максимально независимым от существующего функционала. А в идеале и новую фичу закрыть фиче тонком.
Мой опыт подсказывает, что незапланированный рефакторинг приведет к проблемам. Правя чужой код не всегда понятен весь контекст задач, в которой он выполнялся. А самое неприятное, что тебе может казаться, что ты понимаешь, но это не так. В таких условиях пропустить какой-то случай, и наплодить ошибок очень просто.
Так же такой подход противоречит правильной работе с системой контроля версий. В одном комитете должны быть атомарные изменения. В идеале один коммит (Или ветка, если так удобнее) - одна фича. Такой подход позволяет с одной стороны переиспользовать функционал если он еще не влит в основную ветку, а с другой стороны точно понимать, какого рода изменения были в фиче, и откатить ее.
Представь себе ситуацию, когда ты добавляешь код валидирующий форму на страницу, а попутно правишь роутинг приложения. Будет весело потом искать в каком комите приложение стало неправильно перенаправлять пользователя.
Тем не менее, я не считаю, что правило бойскаута совершенно неприменимо. Как я говорил выше такая философия очень близка мне. Просто оно не работает для больших интерплайзных приложений. В которых стабильность гораздо важнее скорости разработки фичи. Все большие приложения стараются не падать, поскольку каждое падение это потеря денег и аудитории. А вот в Стартапах, где скорость разработки это скорее вопрос выживаемости правило бойскаута может в недалеком будущем принести бенефиты;
Но даже в больших и устоявшихся приложениях, правило бойскаута можно применять. Только бойскаут должен быть не таким резким, и не должен сразу бросаться в бой. В таких приложениях все нужно делать через берлог.
Например я пилю фичу, и понимаю, что было бы неплохо отрефакторить текущий функционал, и вынести переиспользуемый код в отдельный модуль. Я делю сво фичу на две интерации. В первой итерации я пишу фичу без рефакторинга, возможно даже с дублированием кода. Зато это позволяет мне не трогать существующий функционал, а так же скрыть новую фичу под фиче тонком.
После чего завожу задачу на рефакторинг и кладу ее в беклог. Во время каждого спринта у меня есть время, когда я закрываю технический долги, именно тогда, я могу сделать код лучше.
В этом случае бизнес не получит рабочую фичу быстрее. Тестировщики будут иметь тест кейсы на старый и новый функционал и им будет проще тестировать техническую задачу на рефакторинг. Ну а я как пожилой и занудный бойскаут сделаю код лучше. А еще бывают ситуации, когда после релиза новой фичи становится очевидно, что она работе и не так, должна работать по-другому, или вовсе не нужна.
И тогда мне гораздо проще удалить сепарированный код, и не оставлять в коде ненужные абстракции.
🥱 Как уставать меньше
Весь сентябрь и часть октября чувствовал постоянную усталость. Не скажу, что сил вообще не было. В будние дни я просыпался отдохнувшим, но уже к обеду начинал ощущать себя уставшим, а к концу дня сил не остается совсем. Но самое печальное - это выходные. Бывали дли, когда я просыпался и часами лежал, не чувствуя никакого желания что-то делать.
Как всегда, столкнувшись с проблемой, начал разбираться как это работает. Чтобы понять, как выйти из этого состояния.Этим и решил поделиться.
🧑🏭 Почему мы устаем, работая за компьютером?
Для себя я выделил два основных пути потери сил.
👆 Во-первых, мозг постоянно борется с тем чтобы не отвлечься. Рабочие задачи очень часто выглядят менее заманчиво, чем котики в соц сетях, или новости. Каждый раз, когда появляется импульс на то, чтобы отвлечься, мозг тратит силы, чтобы его погасить.
✌️ Во-вторых, мы просто так устроены, что не можем долго заниматься одной деятельностью. Исторически, человеку нужно было выполнять множество параллельных задач. Найти еду, убедиться в безопасности, найти партнера, справить нужду. Человек, который увлекался одной задачей, забывая, допустим, про безопасность, быстро становился жертвой хищников. Именно поэтому усталость в какой-то мере можно воспринимать как сигнал к смене деятельности.
☕ Как меньше уставать?
Все советы, которые я выработал, прямо или косвенно следуют из двух утверждений выше.
🙃 Повышать мотивацию. Чем больше будет мотивировать работа, тем проще сопротивляться отвлечению. Про повышение мотивации можно написать еще с 10-к статей, но если коротко важно понимать, что рабочая деятельность небесполезна. Можно подумать о тех людях, которые будут пользоваться сервисом, об опыте который ты получишь когда успешно закончишь задачу, о родственных, о том, что на премию можно поехать в отпуске и так далее.
🔕 С другой стороны уменьшить количество отвлекающих факторов.
Лучше убрать со Стола любые вещи, не относящиеся к работе, убрать телефон, отключить уведомления от развлекательных сайтов. В идеале завести для работы отдельный компьютер, или хотя бы отдельный аккаунт, на котором не так просто попасть в социальные сети.
Так же стоит помнить, что навык сопротивлению отвлечению - это привычка. И чем чаще ты выбираешь работу вместо социальных сетей, тем проще тебе это будет сделать в следующий раз.
🌄 Менять виды деятельности.
Не всегда работа программиста связана с работой за компьютером. Очень часто для того, чтобы продуктивно обдумать решение, мне надо ходить. Получасовая прогулка по парку может принести поразительный инсайт. Так же отлично помогает сон (10-15 минут), или разговор с приятным коллегой.
Согласно исследованиям самые продуктивные люди работают циклами по 1,5-2 часа. Из которых 80 процентов уходит на выполнение задачи, а 20 процентов, на отвлеченную деятельность. Только не стоит отвлекаться на социальные сети.
🤸 Физическое состояние
Продуктивная умственная деятельность невозможна без хорошего физического самочувствия. Поэтому важно хорош спать, заниматься спортом и правильно питаться.
Мне очень сложно заставить идти себя в зал. Зато через 30 минут бега, я чувствую себя совершенно другим человеком. То же самое и с питанием, в моменте хочется что-то калорийное, зато потом чрезвычайно благодарен себе, за выбранный салат.
Но все эти советы, даже если безукоризненно следовать им не смогут заменить полноценный отдых. Поэтому не забывайте отдыхать, даже если смотришь на цены и думаешь, что не устал.
Весь сентябрь и часть октября чувствовал постоянную усталость. Не скажу, что сил вообще не было. В будние дни я просыпался отдохнувшим, но уже к обеду начинал ощущать себя уставшим, а к концу дня сил не остается совсем. Но самое печальное - это выходные. Бывали дли, когда я просыпался и часами лежал, не чувствуя никакого желания что-то делать.
Как всегда, столкнувшись с проблемой, начал разбираться как это работает. Чтобы понять, как выйти из этого состояния.Этим и решил поделиться.
🧑🏭 Почему мы устаем, работая за компьютером?
Для себя я выделил два основных пути потери сил.
👆 Во-первых, мозг постоянно борется с тем чтобы не отвлечься. Рабочие задачи очень часто выглядят менее заманчиво, чем котики в соц сетях, или новости. Каждый раз, когда появляется импульс на то, чтобы отвлечься, мозг тратит силы, чтобы его погасить.
✌️ Во-вторых, мы просто так устроены, что не можем долго заниматься одной деятельностью. Исторически, человеку нужно было выполнять множество параллельных задач. Найти еду, убедиться в безопасности, найти партнера, справить нужду. Человек, который увлекался одной задачей, забывая, допустим, про безопасность, быстро становился жертвой хищников. Именно поэтому усталость в какой-то мере можно воспринимать как сигнал к смене деятельности.
☕ Как меньше уставать?
Все советы, которые я выработал, прямо или косвенно следуют из двух утверждений выше.
🙃 Повышать мотивацию. Чем больше будет мотивировать работа, тем проще сопротивляться отвлечению. Про повышение мотивации можно написать еще с 10-к статей, но если коротко важно понимать, что рабочая деятельность небесполезна. Можно подумать о тех людях, которые будут пользоваться сервисом, об опыте который ты получишь когда успешно закончишь задачу, о родственных, о том, что на премию можно поехать в отпуске и так далее.
🔕 С другой стороны уменьшить количество отвлекающих факторов.
Лучше убрать со Стола любые вещи, не относящиеся к работе, убрать телефон, отключить уведомления от развлекательных сайтов. В идеале завести для работы отдельный компьютер, или хотя бы отдельный аккаунт, на котором не так просто попасть в социальные сети.
Так же стоит помнить, что навык сопротивлению отвлечению - это привычка. И чем чаще ты выбираешь работу вместо социальных сетей, тем проще тебе это будет сделать в следующий раз.
🌄 Менять виды деятельности.
Не всегда работа программиста связана с работой за компьютером. Очень часто для того, чтобы продуктивно обдумать решение, мне надо ходить. Получасовая прогулка по парку может принести поразительный инсайт. Так же отлично помогает сон (10-15 минут), или разговор с приятным коллегой.
Согласно исследованиям самые продуктивные люди работают циклами по 1,5-2 часа. Из которых 80 процентов уходит на выполнение задачи, а 20 процентов, на отвлеченную деятельность. Только не стоит отвлекаться на социальные сети.
🤸 Физическое состояние
Продуктивная умственная деятельность невозможна без хорошего физического самочувствия. Поэтому важно хорош спать, заниматься спортом и правильно питаться.
Мне очень сложно заставить идти себя в зал. Зато через 30 минут бега, я чувствую себя совершенно другим человеком. То же самое и с питанием, в моменте хочется что-то калорийное, зато потом чрезвычайно благодарен себе, за выбранный салат.
Но все эти советы, даже если безукоризненно следовать им не смогут заменить полноценный отдых. Поэтому не забывайте отдыхать, даже если смотришь на цены и думаешь, что не устал.
👰 И в горе и в радости, пока другой оффер не разлучит вас...
Проходил недавно собеседование и словил инсайт. HR сказала, что они редко ищут людей, поскольку у них маленькая текучка кадров, а расти сильно они не собираются. Мне интересно послушать про такие вакансии, поскольку попасть к ним сложнее, чем в компании с активным наймом.
Немного про компанию. Ребята пишут торговых ботов для разных бирж. Никому их не продает, а торгуют сами. Зарабатывает компания на прибыли с этих торговых роботов. Компания по сути замкнута сама в себе. Заказчик разработки сидит в соседней комнате от этой самой разработки.
Это необычно само по себе, но меня зацепила система премирования. Каждые пол года компания ставит цель по выручке. Это те деньги которые нужны компании, чтобы существовать, и продолжать развиваться. И если заработать удалось больше, то излишки направляются в специальный фонд. Который после очередного ревью идет на премии сотрудника.
Логика простая: хорошо поработал - хорошую премию получил.
Очевидно, что спрогнозировать такую премию сложно. Но для примера мне озвучили премию разработчиков в прошлое ревью. Что-то около 30 тысяч долларов. Сумма интересная, но не все так просто.
Сразу эти деньги тебе не отдают. 20 тысяч выплачивают сразу, а остальное делится на 5 частей, и выплачивается дополнительно каждые пол года.
В итоге чем дольше работаешь, тем больше премия. А еще это уменьшает желание искать новую работу. Очевидно, что текучка у них меньше средней по рынку.
После собеседования я задумался, что мне импонирует подход, когда сотрудники, являясь частью компании, разделяют сверх прибыль, и разделяют неудачи компании. Очевидно, что с таким подходом в тяжелые времена часть людей отвалится. Но мне кажется такая практика выводит ответственность за то, что ты делаешь на новый уровень.
В России, я чаще сталкивался с другой философией. Когда работодатель за тебя все стараются решить, оградив рядовых сотрудников от проблем с которыми сталкивается компания. Когда-то это меня устраивало. Я считал, что мое дело код писать, а вопросами бизнеса пусть занимаются специально обученные люди. Сейчас скорее наоборот. Я считаю важным не только заглядывать в смежную техническую область, но еще и в целом разбираться как функционирует компания.
Это создает дополнительную эмоциональную связь, делая из отношений работник - работа нечто большее. Я уже год работаю в Яндексе и вижу здесь как людей, которые работают год-два, а потом уходят, так и тех, кто работает сильно дольше. Так вот последних, отличает богатая связь с их занятием. Они видят в рабочих задачах что-то больше чем просто работу. Такие люди могут очень долго рассказывать про проект или свой опыт на нем. Рассказывать истории из прошлого, и какой опыт получилось из этого извлечь.
Уверен, что если спросить про деньги, или другие плюшки, то такие люди ответят, что это совсем не главное. А главное - это ощущение причастности к тому что ты делаешь, ощущение влияния на продукт и компанию. И в тот момент, когда ты начинаешь ощущать это твое восприятие работы меняется. И самый простой способ ощутить - это разделить с компанией и успехи и поражения.
Написать мне | Поддержать: Boosty | Patreon | Крипта
А сколько лет ты работаешь на своем месте? И что тебя держит?
Проходил недавно собеседование и словил инсайт. HR сказала, что они редко ищут людей, поскольку у них маленькая текучка кадров, а расти сильно они не собираются. Мне интересно послушать про такие вакансии, поскольку попасть к ним сложнее, чем в компании с активным наймом.
Немного про компанию. Ребята пишут торговых ботов для разных бирж. Никому их не продает, а торгуют сами. Зарабатывает компания на прибыли с этих торговых роботов. Компания по сути замкнута сама в себе. Заказчик разработки сидит в соседней комнате от этой самой разработки.
Это необычно само по себе, но меня зацепила система премирования. Каждые пол года компания ставит цель по выручке. Это те деньги которые нужны компании, чтобы существовать, и продолжать развиваться. И если заработать удалось больше, то излишки направляются в специальный фонд. Который после очередного ревью идет на премии сотрудника.
Логика простая: хорошо поработал - хорошую премию получил.
Очевидно, что спрогнозировать такую премию сложно. Но для примера мне озвучили премию разработчиков в прошлое ревью. Что-то около 30 тысяч долларов. Сумма интересная, но не все так просто.
Сразу эти деньги тебе не отдают. 20 тысяч выплачивают сразу, а остальное делится на 5 частей, и выплачивается дополнительно каждые пол года.
В итоге чем дольше работаешь, тем больше премия. А еще это уменьшает желание искать новую работу. Очевидно, что текучка у них меньше средней по рынку.
После собеседования я задумался, что мне импонирует подход, когда сотрудники, являясь частью компании, разделяют сверх прибыль, и разделяют неудачи компании. Очевидно, что с таким подходом в тяжелые времена часть людей отвалится. Но мне кажется такая практика выводит ответственность за то, что ты делаешь на новый уровень.
В России, я чаще сталкивался с другой философией. Когда работодатель за тебя все стараются решить, оградив рядовых сотрудников от проблем с которыми сталкивается компания. Когда-то это меня устраивало. Я считал, что мое дело код писать, а вопросами бизнеса пусть занимаются специально обученные люди. Сейчас скорее наоборот. Я считаю важным не только заглядывать в смежную техническую область, но еще и в целом разбираться как функционирует компания.
Это создает дополнительную эмоциональную связь, делая из отношений работник - работа нечто большее. Я уже год работаю в Яндексе и вижу здесь как людей, которые работают год-два, а потом уходят, так и тех, кто работает сильно дольше. Так вот последних, отличает богатая связь с их занятием. Они видят в рабочих задачах что-то больше чем просто работу. Такие люди могут очень долго рассказывать про проект или свой опыт на нем. Рассказывать истории из прошлого, и какой опыт получилось из этого извлечь.
Уверен, что если спросить про деньги, или другие плюшки, то такие люди ответят, что это совсем не главное. А главное - это ощущение причастности к тому что ты делаешь, ощущение влияния на продукт и компанию. И в тот момент, когда ты начинаешь ощущать это твое восприятие работы меняется. И самый простой способ ощутить - это разделить с компанией и успехи и поражения.
Написать мне | Поддержать: Boosty | Patreon | Крипта
А сколько лет ты работаешь на своем месте? И что тебя держит?
Forwarded from Яндекс
Media is too big
VIEW IN TELEGRAM
А ещё YaC 2023 — это мини-сериал из четырёх эпизодов. На Кинопоиске и YouTube.
Подписывайтесь 👉 @yandex
Please open Telegram to view this post
VIEW IN TELEGRAM
🧒 Три месяца работы со стажером...
Три месяца назад ко мне в команду вышел стажер. Я всегда считал раньше, что стажировка - крутой шанс для стажера, особенно в крупной компании. Но для компании это скорее инвестиция, а для команды - дополнительная нагрузка.
Стажер, который пришел в мою команду, назовем его Димой, ничем по технической подготовке не отличался от уверенного мидл разработчика. На собеседования ко мне иногда приходят ребята слабее.
За эти три месяца он ни разу не задал мне технический вопрос, ни разу не пришел с вопросом, что он что-то не понимает. Возможно, он спрашивал это еще у кого-то или у других стажеров. Но судя по его подготовке, таких вопросов было немного, если они были. Да, его решения были не идеальными, их было куда улучшать, но они всегда работали.
За эти три месяца он не моргнув глазом разобрал весь беклог с багами и задачами, до которых никак не доходили руки.
Тут стоит отдать должное нашему амбассадору багов - опытному разработчику из компании, который организовал работу стажеров с беклогом. Он просматривал все тикеты, дополнял, исправлял их и передавал стажерам. Мы даже устроили соревнование, целью которого было всем вместе в 5 раз снизить суммарный вес багов. И они смогли, а потом дружно отправились в бар праздновать.
Когда закончились баги, я начал давать простые продуктовые задачи. Стажер выступил настолько хорошо, что новый лидер нашей кроссфункциональной команды удивился, узнав, что Дима - стажер.
🥫 А может не нужны эти ваши синьеры-помидоры?
Признаюсь честно, смотря на то, как Дима справляется, я тоже об этом задумался. Заменить опытных, дорогих и местами несговорчивых разработчиков на молчаливых, заинтересованных и дешевых стажеров.
Но все встало на свои места, когда я заметил, как стажер начинает вязнуть в продуктовых задачах, в которых не просто надо писать код, но еще и выяснить что-то.
Наш мозг всегда выбирает самую понятную задачу. А вот как сделать из сложной задачи простую - это совершенно другой навык.
Если задача понятна, стажер будет с удовольствием решать любой, даже самый скучный баг. Ведь ему все в новинку. Но фиксить баги ему наскучит сильно раньше, чем он научится уменьшать энтропию продуктовых задач.
Больше всего я беспокоился, что стажер станет дополнительной нагрузкой. Что ему придется что-то объяснять, внимательно перепроверять за ним и возможно разгребать инциденты. Но поскольку в Яндекс попадают только лучшие стажеры, таких проблем не было. А наличие стажера помогло мне сконцентрироваться на более комплексных задачах.
Три месяца назад ко мне в команду вышел стажер. Я всегда считал раньше, что стажировка - крутой шанс для стажера, особенно в крупной компании. Но для компании это скорее инвестиция, а для команды - дополнительная нагрузка.
Стажер, который пришел в мою команду, назовем его Димой, ничем по технической подготовке не отличался от уверенного мидл разработчика. На собеседования ко мне иногда приходят ребята слабее.
За эти три месяца он ни разу не задал мне технический вопрос, ни разу не пришел с вопросом, что он что-то не понимает. Возможно, он спрашивал это еще у кого-то или у других стажеров. Но судя по его подготовке, таких вопросов было немного, если они были. Да, его решения были не идеальными, их было куда улучшать, но они всегда работали.
За эти три месяца он не моргнув глазом разобрал весь беклог с багами и задачами, до которых никак не доходили руки.
Тут стоит отдать должное нашему амбассадору багов - опытному разработчику из компании, который организовал работу стажеров с беклогом. Он просматривал все тикеты, дополнял, исправлял их и передавал стажерам. Мы даже устроили соревнование, целью которого было всем вместе в 5 раз снизить суммарный вес багов. И они смогли, а потом дружно отправились в бар праздновать.
Когда закончились баги, я начал давать простые продуктовые задачи. Стажер выступил настолько хорошо, что новый лидер нашей кроссфункциональной команды удивился, узнав, что Дима - стажер.
🥫 А может не нужны эти ваши синьеры-помидоры?
Признаюсь честно, смотря на то, как Дима справляется, я тоже об этом задумался. Заменить опытных, дорогих и местами несговорчивых разработчиков на молчаливых, заинтересованных и дешевых стажеров.
Но все встало на свои места, когда я заметил, как стажер начинает вязнуть в продуктовых задачах, в которых не просто надо писать код, но еще и выяснить что-то.
Наш мозг всегда выбирает самую понятную задачу. А вот как сделать из сложной задачи простую - это совершенно другой навык.
Если задача понятна, стажер будет с удовольствием решать любой, даже самый скучный баг. Ведь ему все в новинку. Но фиксить баги ему наскучит сильно раньше, чем он научится уменьшать энтропию продуктовых задач.
Больше всего я беспокоился, что стажер станет дополнительной нагрузкой. Что ему придется что-то объяснять, внимательно перепроверять за ним и возможно разгребать инциденты. Но поскольку в Яндекс попадают только лучшие стажеры, таких проблем не было. А наличие стажера помогло мне сконцентрироваться на более комплексных задачах.
🗣️ Про отношения в команде и продуктивность
Случайно провел эксперимент. Мне для запуска фичи потребовались доработки в нативной части приложения. Оформил две одинаковые задачи на iOS и Android.
iOS был важнее, поэтому сначала пришел к ним. Разработчик оценил задачу в день-полтора работы. Меня это устраивало, поэтому я ушел и не трогал его больше.
Есть люди, с которыми отношения у меня как-то не сложились. Вроде конфликта нет, но и чувствуется какой-то холодок. Вроде ты предлагаешь здравые вещи, а с твоими словами чуть пренебрежительно и недоверчиво соглашаются. Вот с iOS разработчиком у меня именно так.
Через день разработчик приходит, говорит, что готово. Я скачал девсборку, запускаю симулятор, вижу проблему, спрашиваю, как проверял? А он не проверял. Говорит, ну она должна работать. Пока искал причину, залез в код. Там изменений на 10 строк, реально нечему ломаться. В итоге проблема была в симуляторе.
Претензий вроде как нет, но код свой тестировать надо. В общем, как в том анекдоте: "Ложки нашлись, а осадок остался".
Дальше пришел к Android разработчику. С ним мы работаем плотнее, общаемся лучше, иногда даем друг другу советы.
Созвонились, рассказал про задачу, объяснил, почему срочно и нужно все бросить и делать именно ее. Спрашиваю, во сколько оценишь?
🤷 "Часа 3".
Я говорю, ну ок, пиши, как закончишь. Через час разработчик спрашивает про целевой кейс, есть ли крайние случаи, и в результате отправляет мне скринкаст с записью работы новой фичи. Ради любопытства посмотрел в ПР и увидел, что кода там раз в 10 больше, чем на iOS.
Именно количество кода и объем потраченного времени заставили меня задуматься, почему так получилось.
Оба разработчика примерно одного уровня. Оба хорошо справляются со своими обязанностями. Только один сделал по минимуму, а другой сделал по максимуму, с душой.
Написать мне | Поддержать Канал
Случайно провел эксперимент. Мне для запуска фичи потребовались доработки в нативной части приложения. Оформил две одинаковые задачи на iOS и Android.
iOS был важнее, поэтому сначала пришел к ним. Разработчик оценил задачу в день-полтора работы. Меня это устраивало, поэтому я ушел и не трогал его больше.
Есть люди, с которыми отношения у меня как-то не сложились. Вроде конфликта нет, но и чувствуется какой-то холодок. Вроде ты предлагаешь здравые вещи, а с твоими словами чуть пренебрежительно и недоверчиво соглашаются. Вот с iOS разработчиком у меня именно так.
Через день разработчик приходит, говорит, что готово. Я скачал девсборку, запускаю симулятор, вижу проблему, спрашиваю, как проверял? А он не проверял. Говорит, ну она должна работать. Пока искал причину, залез в код. Там изменений на 10 строк, реально нечему ломаться. В итоге проблема была в симуляторе.
Претензий вроде как нет, но код свой тестировать надо. В общем, как в том анекдоте: "Ложки нашлись, а осадок остался".
Дальше пришел к Android разработчику. С ним мы работаем плотнее, общаемся лучше, иногда даем друг другу советы.
Созвонились, рассказал про задачу, объяснил, почему срочно и нужно все бросить и делать именно ее. Спрашиваю, во сколько оценишь?
🤷 "Часа 3".
Я говорю, ну ок, пиши, как закончишь. Через час разработчик спрашивает про целевой кейс, есть ли крайние случаи, и в результате отправляет мне скринкаст с записью работы новой фичи. Ради любопытства посмотрел в ПР и увидел, что кода там раз в 10 больше, чем на iOS.
Именно количество кода и объем потраченного времени заставили меня задуматься, почему так получилось.
Оба разработчика примерно одного уровня. Оба хорошо справляются со своими обязанностями. Только один сделал по минимуму, а другой сделал по максимуму, с душой.
Написать мне | Поддержать Канал
Please open Telegram to view this post
VIEW IN TELEGRAM
💡 Инсайт после конференции YaTalks
Удобно хранить информацию - это важная, но сложная задача. Книги, доклады, рабочие встречи - все это информация, которую стоило бы сохранить. Что-то из этого пригодится сейчас, что-то через пару лет, а что-то никогда.
Наш мозг избавляется от всего лишнего. Если узнал что-то и это сразу не пригодилось - забывает. Если давно не повторял, тоже стоит забыть. Такой подход неплохо работает в дикой природе, но в современном мире рассчитывать на память опрометчиво. Поэтому с недавних пор я тезисно сохраняю поступающую ко мне информацию, особенно это касается докладов и книг.
На прошлой неделе Яндекс провел конференцию YaTalks. Поскольку была возможность лично присутствовать в Москве и Белграде, я не мог пропустить. Именно личное присутствие вдохновляет, заряжает и дарит инсайты. В этом году инсайт даже не был связан с докладами, хотя там было что посмотреть.
В этом году после доклада на экран выводились ключевые мысли. Работало это при помощи YandexGPT, который распознавал текст доклада и выделял основные тезисы. Помню, как стоял и читал сокращенный пересказ доклада Никиты Елагина, и меня осенило.
Во время прослушивания доклада я всегда делаю пометки. Эти пометки вместе с ссылкой на видео я переношу в свою базу знаний. Нужно это для того, чтобы потом быстро восстановить в памяти тему доклада. Но мои заметки не идеальны. Хотя бы потому, что они не позволяют быстро найти эту тему в самом докладе. Но если к ним добавить тезисы, которые генерируются суммаризатором, проблема решается.
Так я и поступил для всех докладов с конференции. Я брал свои заметки, сравнивал их с заметками от YandexGPT. После чего менял формулировку каждого тезиса, чтобы мне было понятно, и вместе с тайм-кодом вставлял в заметки.
В итоге у меня получилась заметка, которая:
- содержит ключевые моменты по докладу,
- тезисы сформулированы в понятной мне форме,
- тайм-код на каждый из тезисов.
К этому я еще обычно выписываю литературу, которую рекомендует автор. Также добавляются ссылки на другие заметки по похожей теме - это могут быть прочитанные книги, статьи или доклады.
Таким образом, у меня получилась удобная система, которая позволит мне восстановить информацию, если я что-то забуду. Я могу забыть про этот доклад, про заметки или конференцию. Но благодаря схожим заметкам, я найду этот доклад, как только тема снова станет актуальной. Из заметок я смогу вытащить ключевую мысль, а тайм-код избавит от просмотра всего доклада.
Таким же способом можно хранить не только доклады, но и лекции, обучающие уроки и статьи.
П.С. Сделать краткий пересказ можно тут.
Написать мне | Поддержать Канал
Удобно хранить информацию - это важная, но сложная задача. Книги, доклады, рабочие встречи - все это информация, которую стоило бы сохранить. Что-то из этого пригодится сейчас, что-то через пару лет, а что-то никогда.
Наш мозг избавляется от всего лишнего. Если узнал что-то и это сразу не пригодилось - забывает. Если давно не повторял, тоже стоит забыть. Такой подход неплохо работает в дикой природе, но в современном мире рассчитывать на память опрометчиво. Поэтому с недавних пор я тезисно сохраняю поступающую ко мне информацию, особенно это касается докладов и книг.
На прошлой неделе Яндекс провел конференцию YaTalks. Поскольку была возможность лично присутствовать в Москве и Белграде, я не мог пропустить. Именно личное присутствие вдохновляет, заряжает и дарит инсайты. В этом году инсайт даже не был связан с докладами, хотя там было что посмотреть.
В этом году после доклада на экран выводились ключевые мысли. Работало это при помощи YandexGPT, который распознавал текст доклада и выделял основные тезисы. Помню, как стоял и читал сокращенный пересказ доклада Никиты Елагина, и меня осенило.
Во время прослушивания доклада я всегда делаю пометки. Эти пометки вместе с ссылкой на видео я переношу в свою базу знаний. Нужно это для того, чтобы потом быстро восстановить в памяти тему доклада. Но мои заметки не идеальны. Хотя бы потому, что они не позволяют быстро найти эту тему в самом докладе. Но если к ним добавить тезисы, которые генерируются суммаризатором, проблема решается.
Так я и поступил для всех докладов с конференции. Я брал свои заметки, сравнивал их с заметками от YandexGPT. После чего менял формулировку каждого тезиса, чтобы мне было понятно, и вместе с тайм-кодом вставлял в заметки.
В итоге у меня получилась заметка, которая:
- содержит ключевые моменты по докладу,
- тезисы сформулированы в понятной мне форме,
- тайм-код на каждый из тезисов.
К этому я еще обычно выписываю литературу, которую рекомендует автор. Также добавляются ссылки на другие заметки по похожей теме - это могут быть прочитанные книги, статьи или доклады.
Таким образом, у меня получилась удобная система, которая позволит мне восстановить информацию, если я что-то забуду. Я могу забыть про этот доклад, про заметки или конференцию. Но благодаря схожим заметкам, я найду этот доклад, как только тема снова станет актуальной. Из заметок я смогу вытащить ключевую мысль, а тайм-код избавит от просмотра всего доклада.
Таким же способом можно хранить не только доклады, но и лекции, обучающие уроки и статьи.
П.С. Сделать краткий пересказ можно тут.
Написать мне | Поддержать Канал
👨👩👧👦 Главная проблема любой IT компании
Автомобилисты шутят, что главная неисправность в автомобиле - это прокладка между рулем и сиденьем. Безопасники всерьез считают человека самым слабым звеном любой системы безопасности. В обеих сферах цена "человеческого фактора" очень высока. В IT компаниях та же самая проблема. И не только в IT. Все потому, что долгое время человек считался рациональным существом. И все системы развивались с расчетом на это.
Но люди - не роботы. Мы устаем, ленимся, испытываем эмоции. Нам присущи когнитивные искажения и много всего доставшееся от древних людей. Особенно это заметно на больших числах. Что приводит продукты и целые компании к совершенно неожиданному результату.
Но это не мешает считать работников винтиками в системе. Оценивать работу в человеко-месяцах, измерять эффективность количеством написанного кода, мотивировать KPI или оценить всех по матрице компетенции... И потому мне приятно видеть другие подходы.
Недавно был на внутреннем митапе Яндекс.Маркета. Ребята рассказывали про свои наработки. Мне запомнился сервис, который решает достаточно тривиальную задачу, собирает данные из разных источников, что-то с ними делает и отдает уже готовое отображение. Интересна в нем архитектура, в основе которой она лежит закон Конвея:
Организации проектируют системы, которые копируют структуру коммуникаций в этой организации.
Другими словами, если у вас над проектом работает 4 команды, то скорее всего в нем будет 4 больших модуля. При этом взаимодействие между модулями будет тем хуже, чем хуже настроена коммуникация между командами.
Именно на этом месте появляются самые болезненные проблемы - интеграционные проблемы. Проблемы, возникающие на стыке модулей, сервисов или систем. Проблемы, которые не понятно на чьей стороне их нужно решать. Тикеты с такими багами очень часто летают от одной команды к другой и, делая полный оборот, возвращаются назад.
Так вот, в своем сервисе ребята из Яндекс.Маркета предположили, что люди, которые собирают данные, обогащают данные, создают API и в итоге потребляют данные - скорее всего это разные люди. А потому при разработке они сконцентрировались именно на связях между модулями, а не на работе с самими данными.
Модуль сбора данных может собирать данные как угодно. Он может использовать любые инструменты и технологии. Зато взаимодействие со следующим модулем максимально зарегулировано. Модуль обогащения данных также может быть реализован как угодно, но имеет жесткий контракт с модулем отображения данных. При этом разные команды имеют возможность под себя настроить работу внутри модуля.
Кажется очевидно, что закладывая то, что заложено в архитектуру, особенности потребителя сервиса сделают работу с ним производительной. Но нет, посмотрите на большую часть интернет-приложений. Они сделаны чужими для хищника, а не для людей.
При этом удивительно то, что к своим клиентам те же компании не относятся как к рациональным существам. Собственно, весь UX построен именно на том, что ребята на больших числах изучают поведение людей. Если интересно, погуглите, как ритейл пользуется человеческими особенностями, подталкивая покупать больше. Но при этом работники компании, которые такие же люди, воспринимаются как механизмы.
В целом ситуация меняется, как и в IT, так и в мире в целом. Графические представления, функциональные и объектные подходы к написанию кода, высокоуровневые языки программирования и многое другое - это шаги в торону человечности. Но самая главная проблема - это люди. Люди, которые относятся к другим людям как к винтикам.
Ну и под конец я бы хотел вспомнить про бирюзовые компании. Эти компании изначально относятся к человеку как к нерациональному существу, при этом не стараясь его изменить. Не пытаются подогнать его под свои лекала. А наоборот, стараются использовать человеческие особенности как возможность для своего развития. И для таких компаний нет такой проблемы, как человек.
Написать мне | Поддержать Канал
Автомобилисты шутят, что главная неисправность в автомобиле - это прокладка между рулем и сиденьем. Безопасники всерьез считают человека самым слабым звеном любой системы безопасности. В обеих сферах цена "человеческого фактора" очень высока. В IT компаниях та же самая проблема. И не только в IT. Все потому, что долгое время человек считался рациональным существом. И все системы развивались с расчетом на это.
Но люди - не роботы. Мы устаем, ленимся, испытываем эмоции. Нам присущи когнитивные искажения и много всего доставшееся от древних людей. Особенно это заметно на больших числах. Что приводит продукты и целые компании к совершенно неожиданному результату.
Но это не мешает считать работников винтиками в системе. Оценивать работу в человеко-месяцах, измерять эффективность количеством написанного кода, мотивировать KPI или оценить всех по матрице компетенции... И потому мне приятно видеть другие подходы.
Недавно был на внутреннем митапе Яндекс.Маркета. Ребята рассказывали про свои наработки. Мне запомнился сервис, который решает достаточно тривиальную задачу, собирает данные из разных источников, что-то с ними делает и отдает уже готовое отображение. Интересна в нем архитектура, в основе которой она лежит закон Конвея:
Организации проектируют системы, которые копируют структуру коммуникаций в этой организации.
Другими словами, если у вас над проектом работает 4 команды, то скорее всего в нем будет 4 больших модуля. При этом взаимодействие между модулями будет тем хуже, чем хуже настроена коммуникация между командами.
Именно на этом месте появляются самые болезненные проблемы - интеграционные проблемы. Проблемы, возникающие на стыке модулей, сервисов или систем. Проблемы, которые не понятно на чьей стороне их нужно решать. Тикеты с такими багами очень часто летают от одной команды к другой и, делая полный оборот, возвращаются назад.
Так вот, в своем сервисе ребята из Яндекс.Маркета предположили, что люди, которые собирают данные, обогащают данные, создают API и в итоге потребляют данные - скорее всего это разные люди. А потому при разработке они сконцентрировались именно на связях между модулями, а не на работе с самими данными.
Модуль сбора данных может собирать данные как угодно. Он может использовать любые инструменты и технологии. Зато взаимодействие со следующим модулем максимально зарегулировано. Модуль обогащения данных также может быть реализован как угодно, но имеет жесткий контракт с модулем отображения данных. При этом разные команды имеют возможность под себя настроить работу внутри модуля.
Кажется очевидно, что закладывая то, что заложено в архитектуру, особенности потребителя сервиса сделают работу с ним производительной. Но нет, посмотрите на большую часть интернет-приложений. Они сделаны чужими для хищника, а не для людей.
При этом удивительно то, что к своим клиентам те же компании не относятся как к рациональным существам. Собственно, весь UX построен именно на том, что ребята на больших числах изучают поведение людей. Если интересно, погуглите, как ритейл пользуется человеческими особенностями, подталкивая покупать больше. Но при этом работники компании, которые такие же люди, воспринимаются как механизмы.
В целом ситуация меняется, как и в IT, так и в мире в целом. Графические представления, функциональные и объектные подходы к написанию кода, высокоуровневые языки программирования и многое другое - это шаги в торону человечности. Но самая главная проблема - это люди. Люди, которые относятся к другим людям как к винтикам.
Ну и под конец я бы хотел вспомнить про бирюзовые компании. Эти компании изначально относятся к человеку как к нерациональному существу, при этом не стараясь его изменить. Не пытаются подогнать его под свои лекала. А наоборот, стараются использовать человеческие особенности как возможность для своего развития. И для таких компаний нет такой проблемы, как человек.
Написать мне | Поддержать Канал
Всем привет, на связи Алекс.
К банальным поздравлениям с Новым годом (они будут в конце), я решил добавить небольшое личное саммари. В этом году для меня ведение этого канала вышло на новый уровень.
Этот канал случайно появился. Начинался он как просто придаток к YouTube-каналу, где выходили основные материалы. А потом незаметно превратился в отдельный проект. Ну а дальше случилась осень 2022 года с тектоническими изменениями. Но я продолжал писать сюда. Я писал из трех стран, в которых жил. Я писал сюда, пока был в поездках и командировках. Да что уж греха таить, я писал сюда во время отпуска, посреди Средиземного моря. Потому что этот канал для меня нечто большее, чем место, куда я записываю свои мысли.
За последний год я стал лучше понимать себя и свою точку зрения, поскольку каждый пост - это рефлексия и формулирование своих мыслей в посты. Я стал формировать свою профессиональную философию. Благодаря каналу, я имею бесценную возможность узнать, насколько хорошо я доношу мысль и как эта мысль воспринимается. А еще благодаря каналу у меня появился моральный компас, благодаря которому мне в моменте становится понятно, какие решения стоит принимать.
Переходя к банальностям. Нас много, и у всех желания разные. Кто-то хочет реализоваться, кто-то хочет завершить проект, а кто-то просто хочет найти работу. Но я верю, что всех нас объединяет желание создавать. Создавать новую ценность в мире, создать новый продукт, который изменит жизнь многих людей к лучшему. Да хотя бы найти работу, чтобы изменить свою жизнь к лучшему.
Именно поэтому мне бы хотелось, чтобы новый год прошел под флагом созидания. Чтобы у нас у всех было это желание создавать, чтобы находились силы, и чтобы оно получалось. И даже если сейчас картина выглядит мрачной, я всегда вспоминаю, что самый темный час бывает перед рассветом.
Спасибо всем нам, что были в этом году здесь, и увидимся в следующем. С Новым Годом
К банальным поздравлениям с Новым годом (они будут в конце), я решил добавить небольшое личное саммари. В этом году для меня ведение этого канала вышло на новый уровень.
Этот канал случайно появился. Начинался он как просто придаток к YouTube-каналу, где выходили основные материалы. А потом незаметно превратился в отдельный проект. Ну а дальше случилась осень 2022 года с тектоническими изменениями. Но я продолжал писать сюда. Я писал из трех стран, в которых жил. Я писал сюда, пока был в поездках и командировках. Да что уж греха таить, я писал сюда во время отпуска, посреди Средиземного моря. Потому что этот канал для меня нечто большее, чем место, куда я записываю свои мысли.
За последний год я стал лучше понимать себя и свою точку зрения, поскольку каждый пост - это рефлексия и формулирование своих мыслей в посты. Я стал формировать свою профессиональную философию. Благодаря каналу, я имею бесценную возможность узнать, насколько хорошо я доношу мысль и как эта мысль воспринимается. А еще благодаря каналу у меня появился моральный компас, благодаря которому мне в моменте становится понятно, какие решения стоит принимать.
Переходя к банальностям. Нас много, и у всех желания разные. Кто-то хочет реализоваться, кто-то хочет завершить проект, а кто-то просто хочет найти работу. Но я верю, что всех нас объединяет желание создавать. Создавать новую ценность в мире, создать новый продукт, который изменит жизнь многих людей к лучшему. Да хотя бы найти работу, чтобы изменить свою жизнь к лучшему.
Именно поэтому мне бы хотелось, чтобы новый год прошел под флагом созидания. Чтобы у нас у всех было это желание создавать, чтобы находились силы, и чтобы оно получалось. И даже если сейчас картина выглядит мрачной, я всегда вспоминаю, что самый темный час бывает перед рассветом.
Спасибо всем нам, что были в этом году здесь, и увидимся в следующем. С Новым Годом
🛌 Я разучился отдыхать...
Год начался как-то странно. Я впервые словил синдром чистого листа. Когда хочется что-то написать, но ты смотришь на чистый лист (пустой документ) и ничего не пишешь.
Помимо этого, я выяснил, что не умею отдыхать. Совсем не умею. Единственный способ отдохнуть - это уехать, оставив ноутбук дома, а телефон выключить. Если этого не сделать, то свободное от работы время я либо пишу код для своих проектов, либо учусь, либо прокрастинацирую. Ничего из этого не является отдыхом.
Я всегда жил в парадигме, что любую минуту надо проводить с пользой. В итоге перегнул палку. С психологом мы пытались выяснить, как можно отдохнуть, не вгоняя себя в новый челендж. В итоге, ничего не придумав, я решил попробовать совершенно разные вещи. Поэтому мне нужна ваша помощь. Расскажите, кто и чем занимается в свободное от работы время? Что вам дарит приятные эмоции и заряжает перед новой трудовой неделей?
Если по каким-то причинам не хочется писать тут, можно написать мне в личку. Я соберу эту информацию и создам отдельный пост. Но в первую очереь это важно для меня
Год начался как-то странно. Я впервые словил синдром чистого листа. Когда хочется что-то написать, но ты смотришь на чистый лист (пустой документ) и ничего не пишешь.
Помимо этого, я выяснил, что не умею отдыхать. Совсем не умею. Единственный способ отдохнуть - это уехать, оставив ноутбук дома, а телефон выключить. Если этого не сделать, то свободное от работы время я либо пишу код для своих проектов, либо учусь, либо прокрастинацирую. Ничего из этого не является отдыхом.
Я всегда жил в парадигме, что любую минуту надо проводить с пользой. В итоге перегнул палку. С психологом мы пытались выяснить, как можно отдохнуть, не вгоняя себя в новый челендж. В итоге, ничего не придумав, я решил попробовать совершенно разные вещи. Поэтому мне нужна ваша помощь. Расскажите, кто и чем занимается в свободное от работы время? Что вам дарит приятные эмоции и заряжает перед новой трудовой неделей?
Если по каким-то причинам не хочется писать тут, можно написать мне в личку. Я соберу эту информацию и создам отдельный пост. Но в первую очереь это важно для меня
👩💻 Исчезнет ли профессия программиста?
Попалось мне видео о скором исчезновении нас, программистов. Не знаю, связано ли это с видео, но несколько человек написали мне в личку с похожим вопросом. И я понимаю, почему этот вопрос волнует. Новичкам непонятно, стоит ли идти в профессию. "Старичкам" страшно потерять хлебное место и бесплатный тыквенный рай в офисе.
👀 У страха глаза велики.
Еще Дорофеев писал, что в моменте мы увеличиваем важность проблемы. Таково свойство нашей психики. Хотя если подумать о проблеме постфактум, она может оказаться вообще не самой крупной.
Профессию программиста периодически хоронят, но после того, как апокалипсис не случился, внимание переключается на новую опасность.
☎️ Телефонистки все.
Телефонистки и кучеры - вот две профессии, которые часто приводят как пример. Да, сложно спорить с тем, что АТС автоматизировали процесс соединения. Впрочем, я как-то писал про операторов технологии, но профессия программиста куда шире. Технологии приходят и уходят, как приходят и уходят инструменты. Хороший специалист может переключаться и менять инструменты в зависимости от конкретной ситуации. Те же телефонистки, преданные работе с телефоном, наверняка имели возможность переквалифицироваться в секретарей.
💾 Ничего не проходит бесследно.
Но главный довод ко мне пришел после просмотра сериала "Кибердеревня". Вообще вся культура киберпанка построена на том, что никакие технологии и подходы не проходят бесследно. Весь киберпанк строится на том, что современные технологии неплохо уживаются с устаревшими. И это легко встретить в реальной жизни. Я легко представляю бабушку, которая на обочине продает грибочки и при этом принимает оплату со своего смартфона. Самый настоящий киберпанк в российских реалиях.
И это, видимо, просто особенность эволюции в этом мире. В других областях то же самое.
Угольная энергетика - грязная и неэффективная. Она использовалась на заре промышленной революции. А потом на смену пришли новые источники энергии, более эффективные, чистые и дешевые. Но если посмотреть на график потребления угля за 100 лет, потребление его не стало меньше. В процентах от всего потребления, конечно, доля падает, но в реальных числах она даже растет.
Да и эволюция живых организмов работает так же. Существующие системы не отмирают и не выбрасываются, они просто видоизменяются под новые задачи.
📸 Минутка профотографию.
Вообще этот Дамоклов меч кажется висит над всеми творческими профессиями. Кажется, фотографы должны пойти на биржу труда еще раньше программистов. Но там все поняли, что красивая картинка - это не все. Важнее смысл, который лежит в этом изображении, подтексты, переплетение актуальных течений. Все то, что мы передаем друг другу, общаясь. Все то, что волнует нас как людей.
Помню, когда я начинал программировать, все вокруг предупреждали, что программистам нужно постоянно учиться. C тех пор ничего не поменялось. Нам нужно постоянно учиться, осваивать не только новые технологии, но и новые инструменты. Я не исключаю, что в какой-то момент процесс программирования изменится, и мы перестанем писать код, а будем писать промпты. Но всегда останутся люди, которые будут готовы делегировать эту задачу кому-то.
Программисты исчезнут в тот момент, когда этот мир перестанет быть миром людей. А пока просто нужно быть готовыми вкладываться в свою актуальность.
Написать мне | Поддержать Канал
Попалось мне видео о скором исчезновении нас, программистов. Не знаю, связано ли это с видео, но несколько человек написали мне в личку с похожим вопросом. И я понимаю, почему этот вопрос волнует. Новичкам непонятно, стоит ли идти в профессию. "Старичкам" страшно потерять хлебное место и бесплатный тыквенный рай в офисе.
👀 У страха глаза велики.
Еще Дорофеев писал, что в моменте мы увеличиваем важность проблемы. Таково свойство нашей психики. Хотя если подумать о проблеме постфактум, она может оказаться вообще не самой крупной.
Профессию программиста периодически хоронят, но после того, как апокалипсис не случился, внимание переключается на новую опасность.
☎️ Телефонистки все.
Телефонистки и кучеры - вот две профессии, которые часто приводят как пример. Да, сложно спорить с тем, что АТС автоматизировали процесс соединения. Впрочем, я как-то писал про операторов технологии, но профессия программиста куда шире. Технологии приходят и уходят, как приходят и уходят инструменты. Хороший специалист может переключаться и менять инструменты в зависимости от конкретной ситуации. Те же телефонистки, преданные работе с телефоном, наверняка имели возможность переквалифицироваться в секретарей.
💾 Ничего не проходит бесследно.
Но главный довод ко мне пришел после просмотра сериала "Кибердеревня". Вообще вся культура киберпанка построена на том, что никакие технологии и подходы не проходят бесследно. Весь киберпанк строится на том, что современные технологии неплохо уживаются с устаревшими. И это легко встретить в реальной жизни. Я легко представляю бабушку, которая на обочине продает грибочки и при этом принимает оплату со своего смартфона. Самый настоящий киберпанк в российских реалиях.
И это, видимо, просто особенность эволюции в этом мире. В других областях то же самое.
Угольная энергетика - грязная и неэффективная. Она использовалась на заре промышленной революции. А потом на смену пришли новые источники энергии, более эффективные, чистые и дешевые. Но если посмотреть на график потребления угля за 100 лет, потребление его не стало меньше. В процентах от всего потребления, конечно, доля падает, но в реальных числах она даже растет.
Да и эволюция живых организмов работает так же. Существующие системы не отмирают и не выбрасываются, они просто видоизменяются под новые задачи.
📸 Минутка профотографию.
Вообще этот Дамоклов меч кажется висит над всеми творческими профессиями. Кажется, фотографы должны пойти на биржу труда еще раньше программистов. Но там все поняли, что красивая картинка - это не все. Важнее смысл, который лежит в этом изображении, подтексты, переплетение актуальных течений. Все то, что мы передаем друг другу, общаясь. Все то, что волнует нас как людей.
Помню, когда я начинал программировать, все вокруг предупреждали, что программистам нужно постоянно учиться. C тех пор ничего не поменялось. Нам нужно постоянно учиться, осваивать не только новые технологии, но и новые инструменты. Я не исключаю, что в какой-то момент процесс программирования изменится, и мы перестанем писать код, а будем писать промпты. Но всегда останутся люди, которые будут готовы делегировать эту задачу кому-то.
Программисты исчезнут в тот момент, когда этот мир перестанет быть миром людей. А пока просто нужно быть готовыми вкладываться в свою актуальность.
Написать мне | Поддержать Канал
Please open Telegram to view this post
VIEW IN TELEGRAM
🧑🚒 Стоит ли спасать своего руководителя?
Какое-то время назад я писал пост о том, что премировать сотрудника должна команда, а не руководитель. Тогда со мной многие не согласились, но есть еще один интересный пример.
Представим себе ситуацию. Руководитель, по каким-то причинам, стал хуже справляться со своими обязанностями. Возможно, по неопытности, плохому самочувствию или из-за обилия этих самых обязанностей. Сотрудник видит этот пробел и берет на себя часть функций руководителя. Никто не просит об этом сотрудника. Он просто хочет сдать проект в срок.
Естественно, что когда приходит время оценивать результаты, сотрудник хочет, чтобы это отметили. Его главный аргумент простой что он делал работу выше своей должности.
🧑🏫 Теперь пофантазируем от лица руководителя. Он понимает, что работает хуже, и ему бы не хотелось обращать на это внимание своего руководства. Но и подчиненного отметить тоже надо. Явный конфликт интересов.
Человек так устроен, что единоличная власть заставляет принимать эгоистичные решения. Этого не происходит, если решение о премировании принимается открыто и всей командой. Хорошей аналогией тут будет суд присяжных.
Коллегиальное принятие решений - это тоже не панацея. Недоверие может извратить любое хорошее начинание. Если в компании существует доверие между сотрудниками, то не так страшно признаться в проблемах с производительностью, как и не страшно признать успехи другого.
Но это долгий путь, гораздо проще одного уволить, а второго уволить попозже, когда еще пару раз обжжется и выгорит.
Написать мне | Поддержать Канал
Какое-то время назад я писал пост о том, что премировать сотрудника должна команда, а не руководитель. Тогда со мной многие не согласились, но есть еще один интересный пример.
Представим себе ситуацию. Руководитель, по каким-то причинам, стал хуже справляться со своими обязанностями. Возможно, по неопытности, плохому самочувствию или из-за обилия этих самых обязанностей. Сотрудник видит этот пробел и берет на себя часть функций руководителя. Никто не просит об этом сотрудника. Он просто хочет сдать проект в срок.
Естественно, что когда приходит время оценивать результаты, сотрудник хочет, чтобы это отметили. Его главный аргумент простой что он делал работу выше своей должности.
🧑🏫 Теперь пофантазируем от лица руководителя. Он понимает, что работает хуже, и ему бы не хотелось обращать на это внимание своего руководства. Но и подчиненного отметить тоже надо. Явный конфликт интересов.
Человек так устроен, что единоличная власть заставляет принимать эгоистичные решения. Этого не происходит, если решение о премировании принимается открыто и всей командой. Хорошей аналогией тут будет суд присяжных.
Коллегиальное принятие решений - это тоже не панацея. Недоверие может извратить любое хорошее начинание. Если в компании существует доверие между сотрудниками, то не так страшно признаться в проблемах с производительностью, как и не страшно признать успехи другого.
Но это долгий путь, гораздо проще одного уволить, а второго уволить попозже, когда еще пару раз обжжется и выгорит.
Написать мне | Поддержать Канал
🩼 Выученная беспомощность
На прошлой неделе делал задачу от маркетологов. У меня ушло около часа, чтобы разобраться с кодом. После чего стало понятно, что для решения нужно заменить национальный домен. Вместо .ru ставить .kz/.by и т.д.
Но поскольку задача сильно далека от зоны ответственности нашей команды, то она пролежала в беклоге почти месяц. Мне эта задача досталась только потому, что год назад я как раз таки и делал редирект на национальные домены для таких страниц.
📆 Можно ли было не ждать месяц?
Ребята регулярно приходили к нам и узнавали статус. Значит, она была у них достаточно срочной. Я подозревал, что решение может оказаться таким, поэтому спросил у ребят, знают ли они подобные страницы для других стран. На не получил внятного ответа.
Если бы я был на их месте, я бы в первую очередь поискал бы похожий функционал. После чего попробовал бы заменить национальный домен. Они потому ко мне и пришли, что я настраивал такой редирект для других страниц. Возможно, без деталей это выглядит непонятно, но, поверьте, до этого правда просто догадаться.
Можно, конечно, раскритиковать ребят, но я задался вопросом, а почему так могло получиться?
🤔 А почему бы не попробовать самому?
Часто причиной является выученная беспомощность. Это состояние, при котором человек не верит, что способен решить задачу.
За собой я тоже иногда такое замечаю. Когда прихожу к ребятам с бекенда или натива с вопросом. А когда получаю ответ - понимаю, что в целом и сам мог бы разобраться.
В чем причина такого состояния?
👆 Недостаток опыта: недостаток знаний в конкретной технологии или недостаток общего опыта работы. Молодому специалисту действительно страшно ошибиться и опозориться перед коллегами. Это может привести к тому, что появляется привычка каждый раз идти к коллеге за помощью.
✌️ Низкая самооценка: работает как недостаток знания, за исключением того, что низкую самооценку можно компенсировать атмосферой в команде и адекватной обратной связью.
🤟 Недостаток коммуникации: недостаток вводных данных приводит к неверному решению, а это в свою очередь к негативному фидбеку. Если это случается постоянно, сотрудник просто перестает проявлять инициативу.
🖖 Негативная обстановка: чаще всего характеризуется избыточным негативным фидбеком над позитивным. Это может привести как к неуверенности в себе или своих знаниях, так и недоверию к получаемой информации. А дальше все как в пунктах выше.
Самое главное, что нужно знать об этом состоянии - оно обратимо.
⬆️ Как выйти из состояния выученной беспомощности?
Половина решения проблемы - это признание, что она есть. А дальше путем рефлексии прийти к причинам такого состояния и уже работать с ними.
Дальнейшие шаги станут понятны после понимания причины такого состояния. Если это недостаток опыта или знаний - то их можно получить, сходив на курсы.
Мы привыкли списывать такое поведение на лень, менталитет или еще что-то. Но я верю, что подавляющее большинство людей хорошие и хотят хорошо делать свою работу. Если они этого не делают, не стоит их обвинять, а нужно просто помочь.
Написать мне | Поддержать Канал
На прошлой неделе делал задачу от маркетологов. У меня ушло около часа, чтобы разобраться с кодом. После чего стало понятно, что для решения нужно заменить национальный домен. Вместо .ru ставить .kz/.by и т.д.
Но поскольку задача сильно далека от зоны ответственности нашей команды, то она пролежала в беклоге почти месяц. Мне эта задача досталась только потому, что год назад я как раз таки и делал редирект на национальные домены для таких страниц.
📆 Можно ли было не ждать месяц?
Ребята регулярно приходили к нам и узнавали статус. Значит, она была у них достаточно срочной. Я подозревал, что решение может оказаться таким, поэтому спросил у ребят, знают ли они подобные страницы для других стран. На не получил внятного ответа.
Если бы я был на их месте, я бы в первую очередь поискал бы похожий функционал. После чего попробовал бы заменить национальный домен. Они потому ко мне и пришли, что я настраивал такой редирект для других страниц. Возможно, без деталей это выглядит непонятно, но, поверьте, до этого правда просто догадаться.
Можно, конечно, раскритиковать ребят, но я задался вопросом, а почему так могло получиться?
🤔 А почему бы не попробовать самому?
Часто причиной является выученная беспомощность. Это состояние, при котором человек не верит, что способен решить задачу.
За собой я тоже иногда такое замечаю. Когда прихожу к ребятам с бекенда или натива с вопросом. А когда получаю ответ - понимаю, что в целом и сам мог бы разобраться.
В чем причина такого состояния?
👆 Недостаток опыта: недостаток знаний в конкретной технологии или недостаток общего опыта работы. Молодому специалисту действительно страшно ошибиться и опозориться перед коллегами. Это может привести к тому, что появляется привычка каждый раз идти к коллеге за помощью.
✌️ Низкая самооценка: работает как недостаток знания, за исключением того, что низкую самооценку можно компенсировать атмосферой в команде и адекватной обратной связью.
🤟 Недостаток коммуникации: недостаток вводных данных приводит к неверному решению, а это в свою очередь к негативному фидбеку. Если это случается постоянно, сотрудник просто перестает проявлять инициативу.
🖖 Негативная обстановка: чаще всего характеризуется избыточным негативным фидбеком над позитивным. Это может привести как к неуверенности в себе или своих знаниях, так и недоверию к получаемой информации. А дальше все как в пунктах выше.
Самое главное, что нужно знать об этом состоянии - оно обратимо.
⬆️ Как выйти из состояния выученной беспомощности?
Половина решения проблемы - это признание, что она есть. А дальше путем рефлексии прийти к причинам такого состояния и уже работать с ними.
Дальнейшие шаги станут понятны после понимания причины такого состояния. Если это недостаток опыта или знаний - то их можно получить, сходив на курсы.
Мы привыкли списывать такое поведение на лень, менталитет или еще что-то. Но я верю, что подавляющее большинство людей хорошие и хотят хорошо делать свою работу. Если они этого не делают, не стоит их обвинять, а нужно просто помочь.
Написать мне | Поддержать Канал
🙏 Очень неловко получилось...
Решил немного поменторить студентов. Пришел к куратору от МФТИ и говорю, могу взять на попечение одного-двух студентов. Поскольку я написал не один десяток телеграм-ботов, поэтому хотел бы взять схожий проект.
Куратор обрадовался, говорит, "ну телеграм-боты - это вообще топ". Поскольку это типичная практическая задача, а студенты как раз в этом семестре изучают 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'е. Давайте мы на этом разговор закончим, я обсужу ситуацию с куратором, и если мы решим, что я смогу вам помочь как менеджер, то я накидаю вам план и обсудим более детальную реализацию.
Написал куратору, тот очень долго извинялся, говорит, "очень неловко получилось". Ну и согласился, что проект не большой - менеджер не нужен. Нужен кто-то с техническим бекграундом.
На этом и порешили.
Через неделю, лежу я с температурой, а мне пишет мне какой-то чувак и хочет обсудить план разработки. Я подумал, что он с работы, и сказал, что я на больничном, а это оказался студент. Их бедолаги, даже не предупредили, что я не смогу их вести.
😞 Очень неловко получилось...
Написать мне | Поддержать Канал
📌 Куда я попал?
Я заметил, что пока я отдыхал от новых постов, много людей подписалось на канал, а из последних постов едва ли понятно, о чем он.
Меня зовут Леша, и я веду этот канал. Я программист с достаточно большим опытом, и сейчас работаю в Яндексе. Этот канал появился как дополнение к моему ютуб-каналу, посвященному первым шагам в IT. Но со временем ютуб стал мне не интересен и заглох, а вот телеграм-канал превратился во что-то независимое.
Здесь я рассказываю про свой опыт в IT, поднимаю философские, иногда сложные вопросы. Иногда делаю обзоры книг, выписывая сюда ключевые моменты, которые выделил для себя. В общем, это своеобразный склад моего опыта.
Кому будет интересно:
🤘 Тем, кто интересуется, как оно тут устроено. Если ты думаешь, что здесь страна эльфов, это лучшее место, чтобы понять, что это не так. Есть вещи, которые устроены лучше, чем в других сферах, есть, которые хуже, но тут, как и везде, работают люди.
✌️ Тем, кто уже работает и хочет понять больше. Иногда полезно не просто знать про проблемы, но еще и подсмотреть, как другие их решают.
🖖 Тем, кто ушел и ностальгирует. Да, да, такие тоже есть.
Если у тебя есть вопрос, и ты хочешь мне его задать - велкам, но сэкономь мое время, и погугли. А если нагуглить не получилось, то пиши вопрос сразу в первом сообщении.
Я заметил, что пока я отдыхал от новых постов, много людей подписалось на канал, а из последних постов едва ли понятно, о чем он.
Меня зовут Леша, и я веду этот канал. Я программист с достаточно большим опытом, и сейчас работаю в Яндексе. Этот канал появился как дополнение к моему ютуб-каналу, посвященному первым шагам в IT. Но со временем ютуб стал мне не интересен и заглох, а вот телеграм-канал превратился во что-то независимое.
Здесь я рассказываю про свой опыт в IT, поднимаю философские, иногда сложные вопросы. Иногда делаю обзоры книг, выписывая сюда ключевые моменты, которые выделил для себя. В общем, это своеобразный склад моего опыта.
Кому будет интересно:
🤘 Тем, кто интересуется, как оно тут устроено. Если ты думаешь, что здесь страна эльфов, это лучшее место, чтобы понять, что это не так. Есть вещи, которые устроены лучше, чем в других сферах, есть, которые хуже, но тут, как и везде, работают люди.
✌️ Тем, кто уже работает и хочет понять больше. Иногда полезно не просто знать про проблемы, но еще и подсмотреть, как другие их решают.
🖖 Тем, кто ушел и ностальгирует. Да, да, такие тоже есть.
Если у тебя есть вопрос, и ты хочешь мне его задать - велкам, но сэкономь мое время, и погугли. А если нагуглить не получилось, то пиши вопрос сразу в первом сообщении.