🎂 А нужно ли поздравлять?
Я всегда считал поздравление с Днем рождение от коллег как должное. Вроде так принято, хотя я никогда не забуду эту неловкую ситуацию, когда руководитель поздравляет тебя и не знает что сказать, и сам ты чувствуешь себя неуютно. И после такого невольно задумаешься, а нужно ли вообще поздравлять?
🥂 Как это было устроено в разных компаниях?
Кажется лучше всего было устроено в IPONWEB. Там на день рождения компания компенсировала любой чек до 3000 рублей. На эти деньги ты мог купить подарок себе, или купить пиццу и угостить коллег. Мой первый день рождения случился через 3 недели как я устроился в эту компанию, я там никого не знал, и купил себе мультиварку. Я тогда только переехал в Москву, и это было очень кстати. Так же на почту приходили оповещения, и коллеги имели возможность поздравить.
✨ Очень странно это было организованно в mail.ru. От компании на почту приходило поздравление и подарок в виде одного койна. Койны - это была такая внутренняя валюта, за нее можно было купить различный мерч. Проблема в том, один койн это очень мало, для примера блокнот стоил 60 койнов... Короче, этот секрет я так и не распознал, почему именно 1? Чем это было мотивированно? Была ли это шутка, или недосмотр... Непонятно...
Но поскольку DC - была отдельной компанией, помимо мэйловских поздравления были еще ежедневные рассылки в телграм с поздравлениями от наших HR, но тут все стандартно.
🍒 На текущем месте.
Когда на текущем месте я не получил никаких поздравлений, я обиделся и решил через время написать об этом, и рассказать о бездушных корпорациях.
В моменте - это неприятно, буду честным, когда ты новичок в компании и твоих коллег поздравляют, а тебя пропускают - это наталкивает на неприятные мысли. Но если немного подумать, то для большой корпорации - это вполне себе выход.
Если сотрудников больше какого-то количества, то дни рождения будут происходить каждый день, и подарок каждому выльется в круглую сумму. Помимо этого, в большой компании теряется то человеческое, что есть когда знакомые люди искренне желают чего-то светлого. Я не думаю, что если бы мне на почту пришло стандартное письмо мне было бы проще в тот день. И вот, готовясь к написанию этого поста, я наткнулся на статистику от супер джоб, из которой оказалось, что чем больше компании, тем чаще они игнорируют дни рождения каждого сотрудника.
И это логично, ценность поздравления сильно варьируется от того, кто тебя поздравил. Поздравление тем ценнее, чем ближе теплее отношения между вами.
И, если честно, у меня нет однозначного ответа, стоит ли организованно поздравлять коллег или нет. Для себя я старюсь руководствоваться правилом, молчи, если тебе нечего сказать.
ПС поздравлять меня не надо, день рождения был давно)
Я всегда считал поздравление с Днем рождение от коллег как должное. Вроде так принято, хотя я никогда не забуду эту неловкую ситуацию, когда руководитель поздравляет тебя и не знает что сказать, и сам ты чувствуешь себя неуютно. И после такого невольно задумаешься, а нужно ли вообще поздравлять?
🥂 Как это было устроено в разных компаниях?
Кажется лучше всего было устроено в IPONWEB. Там на день рождения компания компенсировала любой чек до 3000 рублей. На эти деньги ты мог купить подарок себе, или купить пиццу и угостить коллег. Мой первый день рождения случился через 3 недели как я устроился в эту компанию, я там никого не знал, и купил себе мультиварку. Я тогда только переехал в Москву, и это было очень кстати. Так же на почту приходили оповещения, и коллеги имели возможность поздравить.
✨ Очень странно это было организованно в mail.ru. От компании на почту приходило поздравление и подарок в виде одного койна. Койны - это была такая внутренняя валюта, за нее можно было купить различный мерч. Проблема в том, один койн это очень мало, для примера блокнот стоил 60 койнов... Короче, этот секрет я так и не распознал, почему именно 1? Чем это было мотивированно? Была ли это шутка, или недосмотр... Непонятно...
Но поскольку DC - была отдельной компанией, помимо мэйловских поздравления были еще ежедневные рассылки в телграм с поздравлениями от наших HR, но тут все стандартно.
🍒 На текущем месте.
Когда на текущем месте я не получил никаких поздравлений, я обиделся и решил через время написать об этом, и рассказать о бездушных корпорациях.
В моменте - это неприятно, буду честным, когда ты новичок в компании и твоих коллег поздравляют, а тебя пропускают - это наталкивает на неприятные мысли. Но если немного подумать, то для большой корпорации - это вполне себе выход.
Если сотрудников больше какого-то количества, то дни рождения будут происходить каждый день, и подарок каждому выльется в круглую сумму. Помимо этого, в большой компании теряется то человеческое, что есть когда знакомые люди искренне желают чего-то светлого. Я не думаю, что если бы мне на почту пришло стандартное письмо мне было бы проще в тот день. И вот, готовясь к написанию этого поста, я наткнулся на статистику от супер джоб, из которой оказалось, что чем больше компании, тем чаще они игнорируют дни рождения каждого сотрудника.
И это логично, ценность поздравления сильно варьируется от того, кто тебя поздравил. Поздравление тем ценнее, чем ближе теплее отношения между вами.
И, если честно, у меня нет однозначного ответа, стоит ли организованно поздравлять коллег или нет. Для себя я старюсь руководствоваться правилом, молчи, если тебе нечего сказать.
ПС поздравлять меня не надо, день рождения был давно)
🦵🦶 Иногда я программирую голым
Современный программист обвешан всякими линтерами, проверками, помощниками, подсказками, и так далее.
Недавно мне потребовалось начать разрабатывать новый модуль. Я понял, что не знаю, куда его положить, а не знаю я этого, потому что не представляю файловую структуру проекта.
За пол года я так и не разобрался в ней, потому что есть замечательнейший поиск который позволяет прыгать по зависимостям, попадая в нужный файл, по части названия, без необходимости вводить полный путь.
С одной стороны это упрощает разработку, сохраняя время, а с другой глубина понимания проекта снижается. Поэтому иногда я запрещаю себе пользоваться какой-то тулзой, упрощающей жизнь.
Это я называю работать "голым". Я как бы снимаю с себя часть защиты, которая обычно прикрывает меня. Наш мозг достаточно пластичная штука, поэтому небольшие неудобства он нивелирует достаточно быстро.
Но тут важно не переборщить. Помню, когда только узнал про такую практику я был настолько воодушевлен, что отказался от IDE и перешел на VIM.
Это было мучение. Простейшая задача растягивалась на часы гугления того или иного функционала и в итоге вгоняла в прокрастинацию. Помню, что меня хватило не на долго. Зато с тех пор VIM стал моим вторым редактором, и многие вещи мне гораздо проще сделать в нем, чем в более тяжелом редакторе.
Но этот опыт я больше не хочу повторять. Я пришел к выводу, что можно усложнить себе задачу, чтобы она стала интересной, но не стоит перебарщивать, иначе она будет казаться невозможной.
Другой отличный пример "голой" разработки - это проверка кода в уме.
Я сейчас провожу собеседования, и основная особенность моей секции, что мы вообще не запускаем код. Пишем, тестируем и проверяем результат в уме. Особенность фронтенд разработки, что интерпретатор языка JavaScript всегда под рукой. И я вижу, как невозможность запустить код ломает привычный флоу мышления большинство собеседуемых.
Почти все они привыкли не думать, как код работает, а написать что-то, увидеть результат, потом добавить, снова проверить результат... Это нормальный подход для обучения, поскольку чем короче петля обучения, тем проще учиться, но в жизни такой подход сжирает сильно больше времени.
В своих пэт проектах, где я хорошо понимаю структуру кода, я могу несколько часов писать код, вообще его не запуская. После чего, запустить проверить и поправить ошибки.
А ты пробовал сознательно усложнять себе задачи?
Современный программист обвешан всякими линтерами, проверками, помощниками, подсказками, и так далее.
Недавно мне потребовалось начать разрабатывать новый модуль. Я понял, что не знаю, куда его положить, а не знаю я этого, потому что не представляю файловую структуру проекта.
За пол года я так и не разобрался в ней, потому что есть замечательнейший поиск который позволяет прыгать по зависимостям, попадая в нужный файл, по части названия, без необходимости вводить полный путь.
С одной стороны это упрощает разработку, сохраняя время, а с другой глубина понимания проекта снижается. Поэтому иногда я запрещаю себе пользоваться какой-то тулзой, упрощающей жизнь.
Это я называю работать "голым". Я как бы снимаю с себя часть защиты, которая обычно прикрывает меня. Наш мозг достаточно пластичная штука, поэтому небольшие неудобства он нивелирует достаточно быстро.
Но тут важно не переборщить. Помню, когда только узнал про такую практику я был настолько воодушевлен, что отказался от IDE и перешел на VIM.
Это было мучение. Простейшая задача растягивалась на часы гугления того или иного функционала и в итоге вгоняла в прокрастинацию. Помню, что меня хватило не на долго. Зато с тех пор VIM стал моим вторым редактором, и многие вещи мне гораздо проще сделать в нем, чем в более тяжелом редакторе.
Но этот опыт я больше не хочу повторять. Я пришел к выводу, что можно усложнить себе задачу, чтобы она стала интересной, но не стоит перебарщивать, иначе она будет казаться невозможной.
Другой отличный пример "голой" разработки - это проверка кода в уме.
Я сейчас провожу собеседования, и основная особенность моей секции, что мы вообще не запускаем код. Пишем, тестируем и проверяем результат в уме. Особенность фронтенд разработки, что интерпретатор языка JavaScript всегда под рукой. И я вижу, как невозможность запустить код ломает привычный флоу мышления большинство собеседуемых.
Почти все они привыкли не думать, как код работает, а написать что-то, увидеть результат, потом добавить, снова проверить результат... Это нормальный подход для обучения, поскольку чем короче петля обучения, тем проще учиться, но в жизни такой подход сжирает сильно больше времени.
В своих пэт проектах, где я хорошо понимаю структуру кода, я могу несколько часов писать код, вообще его не запуская. После чего, запустить проверить и поправить ошибки.
А ты пробовал сознательно усложнять себе задачи?
🥤 Я начинал этот канал скорее как дополнение к моему youtube каналу. Однако со временем телеграмм стал для меня соверщенно отдельным видом деятельности. А выпуск видео я из-за различных перипетий временно приостановил.
Занимаясь ютубом, я познакомился с некоторыми активными участниками русскоговорящего IT ютуба, участвовал в колабах, мы даже вместе снимали выпуск в Иннополисe.
Многие, как и я, стали делать для телеграмм отдельный контент и за многими я продолжаю следить.
Если вдруг хочется еще почитать из русскоговорящих ютуберов, то вот ссылка на них https://www.tg-me.com/addlist/qdWM4kBvKZllZmEy
Занимаясь ютубом, я познакомился с некоторыми активными участниками русскоговорящего IT ютуба, участвовал в колабах, мы даже вместе снимали выпуск в Иннополисe.
Многие, как и я, стали делать для телеграмм отдельный контент и за многими я продолжаю следить.
Если вдруг хочется еще почитать из русскоговорящих ютуберов, то вот ссылка на них https://www.tg-me.com/addlist/qdWM4kBvKZllZmEy
Telegram
IT YouTubers
Дима Рожков invites you to add the folder “IT YouTubers”, which includes 56 chats.
🎓 О важности хорошего преподавателя
Решил я освоить новую для себя деятельность. Купил минимально необходимый набор вещей. Посмотрел пару уроков на ютубе.
Через две недели решил, чуть ускорить первый этап обучения и обратиться к специалисту. Нашел на всем известyом сайте по поиску профессионалов опытного педагога с хорошими отзывами, и пошел к нему на занятие.
Сказать, что это было разочарование - ничего не сказать.
😵 преподаватель не поинтересовался моим текущим уровнем ни целями
😷 не было никакой подготовки к уроку с моей стороны, просто в назначенное время он позвонил в телеграме
😭 судя по отзывам преподаватель проводил много онлайн занятий, но технически все было организовано очень плохо. Он меня не почти не слыша, а поэтому больше было похоже на одностороннюю связь
🥱 информация которую он пытался до меня донести было очень много и не было структуры
В итоге после занятия желания заниматься у меня сильно поубавилось, и вообще было ощущение, что меня просто поимели на полторы тысячи рублей.
Хорошо, тогда я пошел к другому специалисту, результат оказался лучше, но совсем немного. После занятия у меня осталось тягостное ощущение, что я никогда это не освою даже основы.
Большую часть умений, которыми я сейчас владею, я освоил самостоятельно. Да на некоторых этапах я спрашивал совета экспертов, но это чаще всего были разовые сессии.
Мне всегда казалось, что самостоятельный метод изучения - это достаточно длинный и тяжелый путь. И я всегда думал, что если хочется его сократить, то можно взять преподавателя. Но оказалось, что все совсем не так просто.
Самостоятельное изучение - это сложный путь, но сложность предсказуема и ожидаема. Но вот занятие с преподавателем стоит начинать с того, что нужно освоить умение выбора хорошего преподавателя, и это неожиданно.
На таких низкосортных специалистах не только теряется время и деньги, но еще и мотивация учиться дальше.
Поэтому хочется пожелать хороших преподавателей после уроков с которыми, хочется сразу же записаться на следующий!
Решил я освоить новую для себя деятельность. Купил минимально необходимый набор вещей. Посмотрел пару уроков на ютубе.
Через две недели решил, чуть ускорить первый этап обучения и обратиться к специалисту. Нашел на всем известyом сайте по поиску профессионалов опытного педагога с хорошими отзывами, и пошел к нему на занятие.
Сказать, что это было разочарование - ничего не сказать.
😵 преподаватель не поинтересовался моим текущим уровнем ни целями
😷 не было никакой подготовки к уроку с моей стороны, просто в назначенное время он позвонил в телеграме
😭 судя по отзывам преподаватель проводил много онлайн занятий, но технически все было организовано очень плохо. Он меня не почти не слыша, а поэтому больше было похоже на одностороннюю связь
🥱 информация которую он пытался до меня донести было очень много и не было структуры
В итоге после занятия желания заниматься у меня сильно поубавилось, и вообще было ощущение, что меня просто поимели на полторы тысячи рублей.
Хорошо, тогда я пошел к другому специалисту, результат оказался лучше, но совсем немного. После занятия у меня осталось тягостное ощущение, что я никогда это не освою даже основы.
Большую часть умений, которыми я сейчас владею, я освоил самостоятельно. Да на некоторых этапах я спрашивал совета экспертов, но это чаще всего были разовые сессии.
Мне всегда казалось, что самостоятельный метод изучения - это достаточно длинный и тяжелый путь. И я всегда думал, что если хочется его сократить, то можно взять преподавателя. Но оказалось, что все совсем не так просто.
Самостоятельное изучение - это сложный путь, но сложность предсказуема и ожидаема. Но вот занятие с преподавателем стоит начинать с того, что нужно освоить умение выбора хорошего преподавателя, и это неожиданно.
На таких низкосортных специалистах не только теряется время и деньги, но еще и мотивация учиться дальше.
Поэтому хочется пожелать хороших преподавателей после уроков с которыми, хочется сразу же записаться на следующий!
👁️ Откуда берутся жуткие интерфейсы?
Так вышло, что большая часть моего опыта работы прошла в B2B продуктах. А особенность B2B разработки в том, что качественный user experience значительно меньше влияет на выбор каким продуктом пользоваться. Другими словами, в клиентских продуктах у пользователя есть возможность голосовать ногами в B2B ее сильно меньше.
В B2B важнее умеет ли твой продукт решать задачи бизнеса, и насколько эффективно он это делает. Зачастую человек, который принимает решение об использовании того или иного продукта вообще никогда не будет им пользоваться.
Например, директор предприятия решает, что на его предприятии сотрудники будут пользоваться CRM системой от разработчика Х, потому что она заточена под конкретные задачи этой области, ну и разработчик Х предложил большую скидку, чем разработчик Y.
При этом сам директор эту CRM может никогда и не откроет, ее будут открывать сотрудники, которые в выборе продукта не участвовал
Но в случае с CRM всегда можно найти альтернативу, а иногда бывает, что альтернатив на рынке попросту нет. И ты либо пользуешься продуктом и зарабатываешь, либо не зарабатываешь.
Рядовые сотрудники, которые всем этим пользуются, страдают, нервничают, ругаются, но как в том анекдоте, продолжают жрать кактус.
Разработчики подобных систем либо не получают обратной связи, либо получают ее искаженную.
Например, если ты сделал кривой интерфейс, а продукт один на рынке, и в прошлом году принес еще больше прибыли - это пример искаженной обратной связи.
И поэтому у разработчиков складывается определенно мышление. Зачем делать очень хорошо, если можно проще. В итоге результат становится не таким идеальным, если не сказать больше.
Менеджеры проекта тоже не заинтересованы в доведении таких продуктов до идеала, поскольку очень часто решают сроки запуска, нежели выписанность интерфесов.
Вот и получается, что все хотят сделать хорошо, а денежные потоки все порешают.
Так вышло, что большая часть моего опыта работы прошла в B2B продуктах. А особенность B2B разработки в том, что качественный user experience значительно меньше влияет на выбор каким продуктом пользоваться. Другими словами, в клиентских продуктах у пользователя есть возможность голосовать ногами в B2B ее сильно меньше.
В B2B важнее умеет ли твой продукт решать задачи бизнеса, и насколько эффективно он это делает. Зачастую человек, который принимает решение об использовании того или иного продукта вообще никогда не будет им пользоваться.
Например, директор предприятия решает, что на его предприятии сотрудники будут пользоваться CRM системой от разработчика Х, потому что она заточена под конкретные задачи этой области, ну и разработчик Х предложил большую скидку, чем разработчик Y.
При этом сам директор эту CRM может никогда и не откроет, ее будут открывать сотрудники, которые в выборе продукта не участвовал
Но в случае с CRM всегда можно найти альтернативу, а иногда бывает, что альтернатив на рынке попросту нет. И ты либо пользуешься продуктом и зарабатываешь, либо не зарабатываешь.
Рядовые сотрудники, которые всем этим пользуются, страдают, нервничают, ругаются, но как в том анекдоте, продолжают жрать кактус.
Разработчики подобных систем либо не получают обратной связи, либо получают ее искаженную.
Например, если ты сделал кривой интерфейс, а продукт один на рынке, и в прошлом году принес еще больше прибыли - это пример искаженной обратной связи.
И поэтому у разработчиков складывается определенно мышление. Зачем делать очень хорошо, если можно проще. В итоге результат становится не таким идеальным, если не сказать больше.
Менеджеры проекта тоже не заинтересованы в доведении таких продуктов до идеала, поскольку очень часто решают сроки запуска, нежели выписанность интерфесов.
Вот и получается, что все хотят сделать хорошо, а денежные потоки все порешают.
🤠 О клиентской разработке интерфейсов
В отличие от b2b проектов, в клиентских приложениях user experience крайне важен, особенно если у продукта есть прямой конкурент. Если пользователь испытывает дискомфорт при работе приложения он уйдет, к конкуренту или просто. А если размер аудитории один миллион, то даже уход одного процента пользователей - это огромная потеря.
Сейчас я впервые за последние лет 5 работаю над клиентским продуктом. И, у нас все серьезно. С одной стороны у нас очень конкурентный рынок. В какой стране не посмотри, всегда присутствует несколько доставщиков еды. А помимо этого, наш клиент еще и голодный (сытые люди редко заказывают еду почему-то), а значит он острее воспринимает непредвиденные сложности с работой приложения.
Работа в b2b меня обленила. Я научился мастерски доказывать, что делать это не нужно, вместо того, чтобы учиться делать идеально. И я совсем отвык "вылизывать" интерфейс.
Недавно я сидел и мучительно доводил до ума новую фичу, и вдруг осознал, что тот код который я пишу, будет видеть 3 миллиона человек в сутки. В книге Патрика Ленсиони "Почему не все любят ходить на работу" - описывается насколько важно понимать, чью жизнь ты делаешь лучше.
3 миллиона человек - это астрономическое количество, но сама сумма ни о чем не говорит. Но я представил, что наверняка из этих 3 миллионов кто-то будет из моего родного города. Кто-то может кто-то кого я знаю лично. Обязательно будут люди из африки, обязательно будут темнокожие и азиаты, будут те, кто не говорит ни на русском, ни на английском. И все эти люди увидят, тот интерфейс, который я сейчас делаю.
И признаюсь, мне стало немного стыдно, что вот я, такой умный сижу, и совсем не хочу сделать свою работу действительно хорошо.
Оказалось, что если подумать о тех, кто будет пользоваться твоей работой, можно найти мотивацию сделать работу еще лучше, тем самым прокачать себя, и сделать жизнь других людей чуточку лучше. Такой win-win.
Я знал, что это работает на длинной перспективе, именно поэтому есть продукты, в которые я никогда не пойду работать. Но это, пожалуй, первый раз, когда я немного сознательно посмотрел на то, что я делаю под другим углом, и получил немедленный профит.
А ты замечал как на тебя влияет проект над которым ты работаешь?
В отличие от b2b проектов, в клиентских приложениях user experience крайне важен, особенно если у продукта есть прямой конкурент. Если пользователь испытывает дискомфорт при работе приложения он уйдет, к конкуренту или просто. А если размер аудитории один миллион, то даже уход одного процента пользователей - это огромная потеря.
Сейчас я впервые за последние лет 5 работаю над клиентским продуктом. И, у нас все серьезно. С одной стороны у нас очень конкурентный рынок. В какой стране не посмотри, всегда присутствует несколько доставщиков еды. А помимо этого, наш клиент еще и голодный (сытые люди редко заказывают еду почему-то), а значит он острее воспринимает непредвиденные сложности с работой приложения.
Работа в b2b меня обленила. Я научился мастерски доказывать, что делать это не нужно, вместо того, чтобы учиться делать идеально. И я совсем отвык "вылизывать" интерфейс.
Недавно я сидел и мучительно доводил до ума новую фичу, и вдруг осознал, что тот код который я пишу, будет видеть 3 миллиона человек в сутки. В книге Патрика Ленсиони "Почему не все любят ходить на работу" - описывается насколько важно понимать, чью жизнь ты делаешь лучше.
3 миллиона человек - это астрономическое количество, но сама сумма ни о чем не говорит. Но я представил, что наверняка из этих 3 миллионов кто-то будет из моего родного города. Кто-то может кто-то кого я знаю лично. Обязательно будут люди из африки, обязательно будут темнокожие и азиаты, будут те, кто не говорит ни на русском, ни на английском. И все эти люди увидят, тот интерфейс, который я сейчас делаю.
И признаюсь, мне стало немного стыдно, что вот я, такой умный сижу, и совсем не хочу сделать свою работу действительно хорошо.
Оказалось, что если подумать о тех, кто будет пользоваться твоей работой, можно найти мотивацию сделать работу еще лучше, тем самым прокачать себя, и сделать жизнь других людей чуточку лучше. Такой win-win.
Я знал, что это работает на длинной перспективе, именно поэтому есть продукты, в которые я никогда не пойду работать. Но это, пожалуй, первый раз, когда я немного сознательно посмотрел на то, что я делаю под другим углом, и получил немедленный профит.
А ты замечал как на тебя влияет проект над которым ты работаешь?
Не потеряли?
Завтра возвращаюсь из отпуска и будет новый пост😉
Завтра возвращаюсь из отпуска и будет новый пост😉
🚪 Когда наступит хорошее время для входа в IT?
Знакомая рассказывала мне про свою подругу, а потом грустно добавила, что не может с ней увидеться, потому что она живет в России. А потом с долей шутки добавила: "Сейчас ее парень закончит обучение, найдет хорошую работу фронтендером, и можно будет релоцироваться".
Я не согласился, потому что сейчас не самое удачное время для входа в IT. И если ждать от первой работы возможности переехать, то можно сильно обломаться.
А сам задумался, а будет ли более удачное время для входа в IT?
Компании сокращают сотрудников, в том числе высококлассных IT специалистов, по всему миру. Мне пока не понятно, временно ли это, или это новый тренд. Возможно, биг техи набрали специалистов про запас, пользуясь сверх доходами, полученными во время пандемии. А может быть, это просто новый тренд, и программисты больше не нужны в таком количестве.
В любом случае, много крутых специалистов на рынке в моменте увеличивают конкуренцию.
Ситуация нагревается маркетологами, раскрутившими маховик рекламы. О смене профессии на более IT-ную, начали задумывать не только мамочки в декрете, но и пенсионеры. Периодически мне пишут люди старшего возраста с просьбой помочь. Поэтому поверьте мне, я знаю о чем говорю.
Я помню, как аналогичная ситуация произошла с юристами. Стать юристом было можно, престижно и очень перспективно. А потом, вал страждущих обрести эту профессию разбился об резко усложнившийся порог входа.
Хорошие юристы по-прежнему очень востребованы, но вход в профессию сильно усложнился.
Рынок IT РФ другой, но не совсем. Специалистов не хватает - это факт. Поэтому IT-ники превращаются в привилегированное сословие: большие зарплаты, лоббисты в правительстве, зарплаты, отсрочки. И все равно специалистов не хватает.
Выглядит как идеальный момент для входа в профессию? Маркетологи думаю так же, поэтому о прелестях смены профессии рассказали уже все блогеры (кроме меня 😛).
Маркетологи настолько разошлись, что запустили другой нарротив. "Зачем нужно нанимать человека с опытом, если можно нанять джунов?", но это я отвлекся.
В итоге в России момент для входа, тоже получается не удачный, поскольку конкуренция новичков приводит к усложнению порога для входа.
А будет ли более удачное время для входа?
На мировом рынке, возможно. Особенно, если текущие увольнения просто компенсация панического найма во время пандемии.
А в России вообще что-то планировать сложно...
Но, как и раньше, я считаю, что если ты действительно хочешь писать код. Лучший момент для входа именно сейчас!
Знакомая рассказывала мне про свою подругу, а потом грустно добавила, что не может с ней увидеться, потому что она живет в России. А потом с долей шутки добавила: "Сейчас ее парень закончит обучение, найдет хорошую работу фронтендером, и можно будет релоцироваться".
Я не согласился, потому что сейчас не самое удачное время для входа в IT. И если ждать от первой работы возможности переехать, то можно сильно обломаться.
А сам задумался, а будет ли более удачное время для входа в IT?
Компании сокращают сотрудников, в том числе высококлассных IT специалистов, по всему миру. Мне пока не понятно, временно ли это, или это новый тренд. Возможно, биг техи набрали специалистов про запас, пользуясь сверх доходами, полученными во время пандемии. А может быть, это просто новый тренд, и программисты больше не нужны в таком количестве.
В любом случае, много крутых специалистов на рынке в моменте увеличивают конкуренцию.
Ситуация нагревается маркетологами, раскрутившими маховик рекламы. О смене профессии на более IT-ную, начали задумывать не только мамочки в декрете, но и пенсионеры. Периодически мне пишут люди старшего возраста с просьбой помочь. Поэтому поверьте мне, я знаю о чем говорю.
Я помню, как аналогичная ситуация произошла с юристами. Стать юристом было можно, престижно и очень перспективно. А потом, вал страждущих обрести эту профессию разбился об резко усложнившийся порог входа.
Хорошие юристы по-прежнему очень востребованы, но вход в профессию сильно усложнился.
Рынок IT РФ другой, но не совсем. Специалистов не хватает - это факт. Поэтому IT-ники превращаются в привилегированное сословие: большие зарплаты, лоббисты в правительстве, зарплаты, отсрочки. И все равно специалистов не хватает.
Выглядит как идеальный момент для входа в профессию? Маркетологи думаю так же, поэтому о прелестях смены профессии рассказали уже все блогеры (кроме меня 😛).
Маркетологи настолько разошлись, что запустили другой нарротив. "Зачем нужно нанимать человека с опытом, если можно нанять джунов?", но это я отвлекся.
В итоге в России момент для входа, тоже получается не удачный, поскольку конкуренция новичков приводит к усложнению порога для входа.
А будет ли более удачное время для входа?
На мировом рынке, возможно. Особенно, если текущие увольнения просто компенсация панического найма во время пандемии.
А в России вообще что-то планировать сложно...
Но, как и раньше, я считаю, что если ты действительно хочешь писать код. Лучший момент для входа именно сейчас!
Дефицит айтишников все?
Anonymous Poll
57%
Не, просто набрали лишнего в пандемию
16%
Да, программисты больше не нужны
27%
ChatGPT нас всех заменит
👨💻 Чем отличается программист от разработчика?
Очень часто эти понятия используются как синонимы. Но у этих понятий все-таки есть разница, и ее незнание иногда это может привести к непониманию.
Программист - это человек, работающий с кодом. Тут все просто, он знает как писать код, знает хорошие практики. Возможно, знает несколько языков программирования. В общем хороший программист - это человек, который ответит на большую часть технических вопросов.
Разработчик определение более широкое нежели программист. Если грубо, то разработчик - это программист на стероидах. Причем стероиды из смежных областей (предметная область бизнеса, менеджмент, тестирование, аналитика и тд).
Хороший разработчик знает не только техническую часть, но еще и понимает как работает проект с точки зрения бизнеса, и понимает как технические изменения помогут бизнесу вырасти.
Такие люди не только отвечают на вопрос "Как сделать", но еще и активно участвуют в обсуждении "Что сделать".
Но и на этом функции разработчика не ограничиваются. Если разработчик работает в большой компании, то он еще и понимает как функционируют различные отделы между собой, и что нужно сделать, чтобы добиться поставленной цели.
В отличие от программиста, разработчик получает в качестве задания неясное пожелание от бизнеса. Участвует в процессе его уточнения, узнает нужную информацию у соседних отделов/команд, и технически отписывает задачу, для того чтобы ее можно было реализовать с предсказуемым результатом по времени и качеству.
Разработчик, как Кот Шрёдингера, иногда есть, а иногда он просто программист. Именно поэтому неискушенные маркетологи и HR-ы очень редко разделяют эти понятия.
К нам в компанию, мы стараемся набирать только разработчиков. Так сложилась культура разработки, что на ревью приветствуется если сотрудник проактивно интересуется смежными областями.
Именно поэтому во время собеседования никто не будет спрашивать про особенности работы фреймворков. Зато вопросы на оценку кругозора будут.
Вот именно об этом недопонимании я говорил в самом начале. Некоторым компаниям нужны react-программисты или html-архитекторы. Им нежны люди для выполнения узкоспециализированной задачи.
Очень часто на собеседовании вижу, недовольство, когда я начинаю задавать общие вопросы. Понимаю, сам таким был, читал, что нечего спрашивать всякие глупости, про замыкания, если я могу без этого всего решить задачу бизнеса.
Оказалось не могу. Оказалось, что интервьюеру интересны не просто знание технических тонкостей. Ему хочется понять интересуюсь ли я еще чем-то, вне моей зоны ответственности. Потому что если интересуюсь, у меня есть шансы стать хорошим разработчиком.
Очень часто эти понятия используются как синонимы. Но у этих понятий все-таки есть разница, и ее незнание иногда это может привести к непониманию.
Программист - это человек, работающий с кодом. Тут все просто, он знает как писать код, знает хорошие практики. Возможно, знает несколько языков программирования. В общем хороший программист - это человек, который ответит на большую часть технических вопросов.
Разработчик определение более широкое нежели программист. Если грубо, то разработчик - это программист на стероидах. Причем стероиды из смежных областей (предметная область бизнеса, менеджмент, тестирование, аналитика и тд).
Хороший разработчик знает не только техническую часть, но еще и понимает как работает проект с точки зрения бизнеса, и понимает как технические изменения помогут бизнесу вырасти.
Такие люди не только отвечают на вопрос "Как сделать", но еще и активно участвуют в обсуждении "Что сделать".
Но и на этом функции разработчика не ограничиваются. Если разработчик работает в большой компании, то он еще и понимает как функционируют различные отделы между собой, и что нужно сделать, чтобы добиться поставленной цели.
В отличие от программиста, разработчик получает в качестве задания неясное пожелание от бизнеса. Участвует в процессе его уточнения, узнает нужную информацию у соседних отделов/команд, и технически отписывает задачу, для того чтобы ее можно было реализовать с предсказуемым результатом по времени и качеству.
Разработчик, как Кот Шрёдингера, иногда есть, а иногда он просто программист. Именно поэтому неискушенные маркетологи и HR-ы очень редко разделяют эти понятия.
К нам в компанию, мы стараемся набирать только разработчиков. Так сложилась культура разработки, что на ревью приветствуется если сотрудник проактивно интересуется смежными областями.
Именно поэтому во время собеседования никто не будет спрашивать про особенности работы фреймворков. Зато вопросы на оценку кругозора будут.
Вот именно об этом недопонимании я говорил в самом начале. Некоторым компаниям нужны react-программисты или html-архитекторы. Им нежны люди для выполнения узкоспециализированной задачи.
Очень часто на собеседовании вижу, недовольство, когда я начинаю задавать общие вопросы. Понимаю, сам таким был, читал, что нечего спрашивать всякие глупости, про замыкания, если я могу без этого всего решить задачу бизнеса.
Оказалось не могу. Оказалось, что интервьюеру интересны не просто знание технических тонкостей. Ему хочется понять интересуюсь ли я еще чем-то, вне моей зоны ответственности. Потому что если интересуюсь, у меня есть шансы стать хорошим разработчиком.
🦾 А что на это скажет ChatGPT?
Я сейчас много вопросов задаю ChatGPT, чтобы понять, в каких сферах его можно применить. Поэтому решил спросить у него вопрос, ответ на который был в предыдущем посте.
И вот что я получил:
Как искусственный интеллект, я могу ответить на этот вопрос.
Термины "программист" и "разработчик" часто используются взаимозаменяемо, но между ними есть небольшая разница в смысле.
Программист - это человек, который занимается написанием кода для программного обеспечения. Он может работать над отдельными компонентами или функциями программы, но его основная задача - написание кода на определенном языке программирования.
Разработчик - это человек, который занимается созданием программного обеспечения в целом. Это включает в себя проектирование архитектуры программы, разработку и тестирование ее компонентов, написание кода и т.д. Разработчик может также управлять проектом, работать с клиентами и определять требования к программному обеспечению.
Таким образом, программист - это часть разработчика, который занимается написанием кода, в то время как разработчик выполняет более широкий спектр задач, включая проектирование и управление проектом.
Все по делу, если честно, поэтому решил оставить тут как дополнительный материал)
Всем хорошей пятницы😃
Я сейчас много вопросов задаю ChatGPT, чтобы понять, в каких сферах его можно применить. Поэтому решил спросить у него вопрос, ответ на который был в предыдущем посте.
И вот что я получил:
Как искусственный интеллект, я могу ответить на этот вопрос.
Термины "программист" и "разработчик" часто используются взаимозаменяемо, но между ними есть небольшая разница в смысле.
Программист - это человек, который занимается написанием кода для программного обеспечения. Он может работать над отдельными компонентами или функциями программы, но его основная задача - написание кода на определенном языке программирования.
Разработчик - это человек, который занимается созданием программного обеспечения в целом. Это включает в себя проектирование архитектуры программы, разработку и тестирование ее компонентов, написание кода и т.д. Разработчик может также управлять проектом, работать с клиентами и определять требования к программному обеспечению.
Таким образом, программист - это часть разработчика, который занимается написанием кода, в то время как разработчик выполняет более широкий спектр задач, включая проектирование и управление проектом.
Все по делу, если честно, поэтому решил оставить тут как дополнительный материал)
Всем хорошей пятницы😃
🔴 Этим людям противопоказано идти в IT
Существуют люди, которым противопоказано идти в IT. Эти противопоказания никак не связаны с физическими или психическими особенностями. Нет, единственное противопоказание - это желание идти в IT. А точнее, откуда оно взялось.
Я все свои желания делю на три категории, безусловно мои желания, условно мои желания, и навязанные желания. В моменте все они кажутся собственными, но разница между ними в том, что первые два скорее всего принесут положительные эмоции, а последнее нет.
Может показаться, сложно, но на примере все станет яснее.
Осенью прошлого года, я снимал квартиру с парнем, который по всем известным причинам тоже оказался в Ереване. У него был небольшой бизнес в России, на доход с которого он и жил.
Прошлой осенью, все вдруг поняли, что It-ка это не только хороший заработок, но и средство передвижения. В общем решил мой сосед стать аналитиком.
Следующие три месяца я наблюдал, как он заставлял себя смотреть различные курсы. Мне кажется, наблюдая за ним, я мог бы написать книгу, 1000 способов закончить учиться и начать прокрастинирова. Большая часть из этих способов была мне знакома, но кое-что оказалось в новинку даже для меня.
Проблема была в том, что последние 18 лет, он вел свой бизнес, продавал, покупал, любил это и у него это получалось.
В итоге под новый год, он решил купить машину.в Грузии и перепродать ее в России. И если честно, я считаю, это лучшее его решение! (совершенно без сарказма)
Я не думаю, что он, как и я грезил быть IT-ком. Просто в тот момент оказалось, что быть аналитиком сильно выгоднее, чем быть предпринимателем. Именно поэтому, я считаю, что его желание войти в IT - это навязанное желание.
Но тут мой сосед потерял всего несколько месяцев на обучение, которое возможно ему даже чем-то поможет.
Второй пример куда более неприятный.
Лет 6 назад я уехал из Челябинска в Москву, мой знакомый тоже заинтересовался программированием. Для него вдруг оказалось, что программирование - это чрезвычайно перспективно.
Помню, как рассказывал ему основы фронтенда, что стоит учить, а что нет, как искать работу и как ходить по собеседованиям.
Его первая попытка обучения закончилась ничем через пол года. Он тогда уже перебрался в Петербург, и оказалось, что не так просто, работать и учиться одновременно.
Года через два, он снова мне набрал, расспрашивал, как у меня складывается работа, как я развиваюсь в профессиональном плане. А потом очень аккуратно сказал, что снова задумался о том, что хочет стать фронтендером, и могу ли я дать пару советов.
Советы, я конечно дал, мне нежалко, но уже тогда, понял, что ничего нового я сказать не могу.
Потом были попытки еще и еще, а последняя была в сентябре прошлого года, и тут хочется спросить "А шо случилось?"
Такое упорство длинной в 5 лет, конечно, похвально, но назвать мотивацию собственной у меня язык не поворачивается.
Как и в примере с соседом это внешняя мотивация, навязанная отчасти успешным кейсом знакомых, отчасти агрессивной рекламой онлайн школ.
Несмотря на все выше сказанное, я считаю, что пробовать однозначно нужно. Потому что, пока не попробуешь, не узнаешь, насколько это было действительно твое желание. Но в какой-то момент, стоит честно себе признаться, что это была ошибка. И пойти заниматься чем-то другом. Потому что заниматься надо любимым делом.
Существуют люди, которым противопоказано идти в IT. Эти противопоказания никак не связаны с физическими или психическими особенностями. Нет, единственное противопоказание - это желание идти в IT. А точнее, откуда оно взялось.
Я все свои желания делю на три категории, безусловно мои желания, условно мои желания, и навязанные желания. В моменте все они кажутся собственными, но разница между ними в том, что первые два скорее всего принесут положительные эмоции, а последнее нет.
Может показаться, сложно, но на примере все станет яснее.
Осенью прошлого года, я снимал квартиру с парнем, который по всем известным причинам тоже оказался в Ереване. У него был небольшой бизнес в России, на доход с которого он и жил.
Прошлой осенью, все вдруг поняли, что It-ка это не только хороший заработок, но и средство передвижения. В общем решил мой сосед стать аналитиком.
Следующие три месяца я наблюдал, как он заставлял себя смотреть различные курсы. Мне кажется, наблюдая за ним, я мог бы написать книгу, 1000 способов закончить учиться и начать прокрастинирова. Большая часть из этих способов была мне знакома, но кое-что оказалось в новинку даже для меня.
Проблема была в том, что последние 18 лет, он вел свой бизнес, продавал, покупал, любил это и у него это получалось.
В итоге под новый год, он решил купить машину.в Грузии и перепродать ее в России. И если честно, я считаю, это лучшее его решение! (совершенно без сарказма)
Я не думаю, что он, как и я грезил быть IT-ком. Просто в тот момент оказалось, что быть аналитиком сильно выгоднее, чем быть предпринимателем. Именно поэтому, я считаю, что его желание войти в IT - это навязанное желание.
Но тут мой сосед потерял всего несколько месяцев на обучение, которое возможно ему даже чем-то поможет.
Второй пример куда более неприятный.
Лет 6 назад я уехал из Челябинска в Москву, мой знакомый тоже заинтересовался программированием. Для него вдруг оказалось, что программирование - это чрезвычайно перспективно.
Помню, как рассказывал ему основы фронтенда, что стоит учить, а что нет, как искать работу и как ходить по собеседованиям.
Его первая попытка обучения закончилась ничем через пол года. Он тогда уже перебрался в Петербург, и оказалось, что не так просто, работать и учиться одновременно.
Года через два, он снова мне набрал, расспрашивал, как у меня складывается работа, как я развиваюсь в профессиональном плане. А потом очень аккуратно сказал, что снова задумался о том, что хочет стать фронтендером, и могу ли я дать пару советов.
Советы, я конечно дал, мне нежалко, но уже тогда, понял, что ничего нового я сказать не могу.
Потом были попытки еще и еще, а последняя была в сентябре прошлого года, и тут хочется спросить "А шо случилось?"
Такое упорство длинной в 5 лет, конечно, похвально, но назвать мотивацию собственной у меня язык не поворачивается.
Как и в примере с соседом это внешняя мотивация, навязанная отчасти успешным кейсом знакомых, отчасти агрессивной рекламой онлайн школ.
Несмотря на все выше сказанное, я считаю, что пробовать однозначно нужно. Потому что, пока не попробуешь, не узнаешь, насколько это было действительно твое желание. Но в какой-то момент, стоит честно себе признаться, что это была ошибка. И пойти заниматься чем-то другом. Потому что заниматься надо любимым делом.
🗨️🫥🗯️ Собственные или навязанные желания
В продолжении темы предыдущего поста...
У каждого человека есть желания, с этим сложно спорить. У голодного человека есть желание поесть, у бедного стать богатым, у тебя, надеюсь, прочитать этот пост до конца. Но всегда ли человек поступает так, как ему хочется? И как быть с желаниями, которые хочется, но не хочется для этого ничего делать?
Я, все свои желания делю на три категории
✋ собственные желания
🖐️ условно собственные желания
🖖 навязанные или внешние желания
В продолжении темы предыдущего поста...
У каждого человека есть желания, с этим сложно спорить. У голодного человека есть желание поесть, у бедного стать богатым, у тебя, надеюсь, прочитать этот пост до конца. Но всегда ли человек поступает так, как ему хочется? И как быть с желаниями, которые хочется, но не хочется для этого ничего делать?
Я, все свои желания делю на три категории
✋ собственные желания
🖐️ условно собственные желания
🖖 навязанные или внешние желания
Собственные желания - это желания, которые безусловно хочет сам человек. По большей части - это физические желания. Например, если человек бежит в туалет после несвежей шаурмы, не пропаганде его туда отправила.
Так же сюда можно отнести базовые желания/поребности, вроде безопасности.
Условно собственные желания - это желания, которые возникают в самом человеке, но это неточно. Например, давайте возьмем Тони Хоука (очень известный скейтер). Он катался с самого детства, с того возраста, когда человеку еще несвойственно скрывать свои желания.
Кажется, что скейтборд - это собственное желание Тони, но даже в википедии написано, что первый скейтборд ему подарил старший брат. Наверняка желание кататься не взялось само по себе, а появилось из желания быть крутым среди парней, которые тоже катались.
Если бы Тони родился в одном из племен Южного Судана, он был бы первоклассно пас бы коров, а не думал бы о скейте.
Значит это общество повлияло на Тони, что он встал на скейтборд, тем не менее, это желание в нем настолько глубоко, что принято называть желания собственными.
Понимаете теперь почему такие желания я называю условно собственные?
Навязанные желания (внешние желания) - это желания, которые навязаны нам обществом, но на самом деле чужды самому индивиду. Очень часто такие желания воспринимаются как собственными, и в этом их самая большая проблема.
В историях про неуспешный вход в IT герои хотели стать IT-ками из-за внешних причин. Хотя никто их к этому не принуждал и с пистолетом не стоял.
В чем проблема навязанных желаний? Как минимум, их не хочется делать 😂😂😂
Ребятам не хотелось учиться, но они себя заставляли. Именно поэтому сейчас они находятся именно там, где они находятся. Но есть еще одна проблема.
Если постараться, и добиться таки желаемого, то можно разочароваться. Так например, я очень часто разочаровывался от дорогих покупок, поскольку желание купить их мне было навязано.
А можно ли навязанное желание сделать своим?
Когда я вспоминаю, свои первые шаги в программировании, то меня восхищали любые мелочи, которые я узнавал. Я помню, что когда я разобрался, как работает обычный цикл, я был в таком восторге, что несколько часов, присал разные циклы, выводил значения в консоль. А потом на следующий день, делал это снова, и снова радовался.
Цикл получения удовольствия от обучения был очень короткий. Я что-то делал и это на маленький шаг приближало меня к образу который я себе рисовал и я откровенно кайфовал от этого.
В общем я в какой-то момент я подсел, но этого запала мне хватило, для того чтобы учиться несколько лет.
У меня это получилось несознательно, поскольку образ IT-ника очень глубоко засел во мне. Но, я думаю, если постараться, то это можно провернуть и искусственно.
Просто приложить больше осознанности к обучению, подмечая и радуясь любой мелочи, с которой удалось разобраться.
Когда-то я ненавидел решать алгоритмические задачи, и я решил что каждое утро я буду решать по одной задачи с codewars. И через какое-то время, переборов себя, я заметил, что получаю удовольствие, когда задача решается.
Но такой подход стоит применять острожно, это идти по лезвию. Качнешься в одну сторону мотивации не хватит, чтобы продолжить учиться, качнешься в другую, переусердствуешь и пожалеешь.
В общем неблагодарное занятие заставлять себя что-то делать, особенно когда делать этого не хочется. И самое главное, чем дольше заставляешь тем сложнее держать себя в форме.
Именно поэтому, я всегда стараюсь идти от того, что нравится.
Так же сюда можно отнести базовые желания/поребности, вроде безопасности.
Условно собственные желания - это желания, которые возникают в самом человеке, но это неточно. Например, давайте возьмем Тони Хоука (очень известный скейтер). Он катался с самого детства, с того возраста, когда человеку еще несвойственно скрывать свои желания.
Кажется, что скейтборд - это собственное желание Тони, но даже в википедии написано, что первый скейтборд ему подарил старший брат. Наверняка желание кататься не взялось само по себе, а появилось из желания быть крутым среди парней, которые тоже катались.
Если бы Тони родился в одном из племен Южного Судана, он был бы первоклассно пас бы коров, а не думал бы о скейте.
Значит это общество повлияло на Тони, что он встал на скейтборд, тем не менее, это желание в нем настолько глубоко, что принято называть желания собственными.
Понимаете теперь почему такие желания я называю условно собственные?
Навязанные желания (внешние желания) - это желания, которые навязаны нам обществом, но на самом деле чужды самому индивиду. Очень часто такие желания воспринимаются как собственными, и в этом их самая большая проблема.
В историях про неуспешный вход в IT герои хотели стать IT-ками из-за внешних причин. Хотя никто их к этому не принуждал и с пистолетом не стоял.
В чем проблема навязанных желаний? Как минимум, их не хочется делать 😂😂😂
Ребятам не хотелось учиться, но они себя заставляли. Именно поэтому сейчас они находятся именно там, где они находятся. Но есть еще одна проблема.
Если постараться, и добиться таки желаемого, то можно разочароваться. Так например, я очень часто разочаровывался от дорогих покупок, поскольку желание купить их мне было навязано.
А можно ли навязанное желание сделать своим?
Когда я вспоминаю, свои первые шаги в программировании, то меня восхищали любые мелочи, которые я узнавал. Я помню, что когда я разобрался, как работает обычный цикл, я был в таком восторге, что несколько часов, присал разные циклы, выводил значения в консоль. А потом на следующий день, делал это снова, и снова радовался.
Цикл получения удовольствия от обучения был очень короткий. Я что-то делал и это на маленький шаг приближало меня к образу который я себе рисовал и я откровенно кайфовал от этого.
В общем я в какой-то момент я подсел, но этого запала мне хватило, для того чтобы учиться несколько лет.
У меня это получилось несознательно, поскольку образ IT-ника очень глубоко засел во мне. Но, я думаю, если постараться, то это можно провернуть и искусственно.
Просто приложить больше осознанности к обучению, подмечая и радуясь любой мелочи, с которой удалось разобраться.
Когда-то я ненавидел решать алгоритмические задачи, и я решил что каждое утро я буду решать по одной задачи с codewars. И через какое-то время, переборов себя, я заметил, что получаю удовольствие, когда задача решается.
Но такой подход стоит применять острожно, это идти по лезвию. Качнешься в одну сторону мотивации не хватит, чтобы продолжить учиться, качнешься в другую, переусердствуешь и пожалеешь.
В общем неблагодарное занятие заставлять себя что-то делать, особенно когда делать этого не хочется. И самое главное, чем дольше заставляешь тем сложнее держать себя в форме.
Именно поэтому, я всегда стараюсь идти от того, что нравится.
👥 🏃♀️Мы очень быстро поделились на своих и чужих...
Когда в команде 20 человек договорится очень сложно. Банально на утренних стендапах не всем хватает времени высказаться. Поэтому логично, что нас решили разделить.
Делились на стримы, основываясь на бизнес необходимости. Первый спринт был переходный, и, к сожалению, факапный. Кто-то должен был доделать задачи для другой команды, кто-то не понял, что ему делать, а кто-то просто не смог нормально договориться.
И вот сидим мы на ретро после этого спринта и обсуждаем, почему все пошло не так гладко, как хотелось.
С удивлением я обнаружил, что уже на первом ретро мы начали делиться на своих и чужих, обвиняя другую команду в некоторых провалах.
Еще раз, полторы недели назад мы были одной командой, а сейчас появились "мы" и "они".
Вообще в корпоративной культуре не принято кого-то персонально обвинять. Говорить, это Вася накосячил, или это виновата команда Пети - считается моветоном.
Именно поэтому такие обвинения, в адрес своих же ребят мне показалось странным. Поэтому я решил подмечать такие моменты в дальнейшем, и задумался "а как я к этому отношусь?"
Если вы слышали про теорию "кругов общения", то произошедшее, очень хорошо в нее вписывается. Люди из одного круга разделились на людей и более близких и менее близких. А под действием стресса, естественным желанием будет спасать более близких людей.
Почему-то мне кажется, что в соседней команде происходили такие же процессы, и мне бы очень хотелось посмотреть как вели и как чувствовали себя ребята, которые участвуют в обеих командах.
Вообще, такая сепарация, хоть и выглядит "так себе", но позволяет ощутить себя частью новой командой. Мы с женой шутим, что ничего не укрепляет взаимоотношения в паре, как обсуждение других пар.
С другой стороны, что меня, если честно порадовало, я не заметил никакого негатив к другой команде в дальнейшем. Возможно, это еще проявится в других стрессовых ситуациях, или когда произойдет очередное недопонимание.
Вообще, чем больше я наблюдаю, за такими процессами тем сильнее убеждаюсь, что создание команды - это сложный процесс, что команда, даже плохая, это нечто больше чем сумма всех людей, и в третьих, что команду, как единицу нужно ставить на первое место, а цели на второе. Но такой подход я никогда не встречал.
Обычно все происходит наоборот, есть бизнес задача, и под нее собирается команда, а если бизнес необходимость вдруг изменилась, никто не пытается сохранить команду, людей просто растаскивают.
Когда в команде 20 человек договорится очень сложно. Банально на утренних стендапах не всем хватает времени высказаться. Поэтому логично, что нас решили разделить.
Делились на стримы, основываясь на бизнес необходимости. Первый спринт был переходный, и, к сожалению, факапный. Кто-то должен был доделать задачи для другой команды, кто-то не понял, что ему делать, а кто-то просто не смог нормально договориться.
И вот сидим мы на ретро после этого спринта и обсуждаем, почему все пошло не так гладко, как хотелось.
С удивлением я обнаружил, что уже на первом ретро мы начали делиться на своих и чужих, обвиняя другую команду в некоторых провалах.
Еще раз, полторы недели назад мы были одной командой, а сейчас появились "мы" и "они".
Вообще в корпоративной культуре не принято кого-то персонально обвинять. Говорить, это Вася накосячил, или это виновата команда Пети - считается моветоном.
Именно поэтому такие обвинения, в адрес своих же ребят мне показалось странным. Поэтому я решил подмечать такие моменты в дальнейшем, и задумался "а как я к этому отношусь?"
Если вы слышали про теорию "кругов общения", то произошедшее, очень хорошо в нее вписывается. Люди из одного круга разделились на людей и более близких и менее близких. А под действием стресса, естественным желанием будет спасать более близких людей.
Почему-то мне кажется, что в соседней команде происходили такие же процессы, и мне бы очень хотелось посмотреть как вели и как чувствовали себя ребята, которые участвуют в обеих командах.
Вообще, такая сепарация, хоть и выглядит "так себе", но позволяет ощутить себя частью новой командой. Мы с женой шутим, что ничего не укрепляет взаимоотношения в паре, как обсуждение других пар.
С другой стороны, что меня, если честно порадовало, я не заметил никакого негатив к другой команде в дальнейшем. Возможно, это еще проявится в других стрессовых ситуациях, или когда произойдет очередное недопонимание.
Вообще, чем больше я наблюдаю, за такими процессами тем сильнее убеждаюсь, что создание команды - это сложный процесс, что команда, даже плохая, это нечто больше чем сумма всех людей, и в третьих, что команду, как единицу нужно ставить на первое место, а цели на второе. Но такой подход я никогда не встречал.
Обычно все происходит наоборот, есть бизнес задача, и под нее собирается команда, а если бизнес необходимость вдруг изменилась, никто не пытается сохранить команду, людей просто растаскивают.
🗣👉 Стоит ли жестить со стажерами в IT?
Мой знакомый работает в компании в которой достаточно жестко относятся со стажерами. Когда он рассказывал про подход к работе со стажерами он описал его примерно так. С ними не нужно нянчиться, как с джунами. Дал задачу, пусть идет разбирается. Если не получается, уволим и возьмем другого.
Найм тоже происходит достаточно жестко. В целом задачи не отличаются от тех, которые задают джуну или мидлу. В процессе работы, задачи ничем не отличаются от тех, что дают штатным сотрудникам.
Несмотря на то, что стажеры очень быстро начинают, работать как полноценные сотрудники в штат их переводят спустя год работы.
И что удивительно, в компании достаточно много хороших специалистов, которые выросли из стажеров.
Почему так происходит?
Для компании такая политика очень выгодна. Когда у тебя есть большой поток кандидатов, то можно устраивать достаточно жесткий отбор на всех этапах работы стажера. Выплывет - отлично, нет - не повезло.
Когда я думаю, про такой подход, чисто рационально я его понимаю. Плюс я понимаю, что стажеры, чаще всего студенты, имеют больше мотивации к обучению, проще переносят подобные невзгоды, легче адаптируются и так далее.
Но с другой стороны, я считаю, что чисто по-человечески - это не правильно. Не правильно относиться к каким-то сотрудникам как к людям второго класса, устраивая такую дедовщину. Те кто, пройдет, запомнят это, и будут так же относиться уже к своим стажерам, возможно даже , не понимая, что это не хорошо.
Помимо этого, такой подход создает психологические проблемы, для тех, кто этап отбора не прошел. И, несмотря на то, что для компании это не имеет значение, я все-равно считаю, что это не экологично.
А как ты считаешь, нормально ли так относиться к стажеру? Нужно ли их жалеть?
Мой знакомый работает в компании в которой достаточно жестко относятся со стажерами. Когда он рассказывал про подход к работе со стажерами он описал его примерно так. С ними не нужно нянчиться, как с джунами. Дал задачу, пусть идет разбирается. Если не получается, уволим и возьмем другого.
Найм тоже происходит достаточно жестко. В целом задачи не отличаются от тех, которые задают джуну или мидлу. В процессе работы, задачи ничем не отличаются от тех, что дают штатным сотрудникам.
Несмотря на то, что стажеры очень быстро начинают, работать как полноценные сотрудники в штат их переводят спустя год работы.
И что удивительно, в компании достаточно много хороших специалистов, которые выросли из стажеров.
Почему так происходит?
Для компании такая политика очень выгодна. Когда у тебя есть большой поток кандидатов, то можно устраивать достаточно жесткий отбор на всех этапах работы стажера. Выплывет - отлично, нет - не повезло.
Когда я думаю, про такой подход, чисто рационально я его понимаю. Плюс я понимаю, что стажеры, чаще всего студенты, имеют больше мотивации к обучению, проще переносят подобные невзгоды, легче адаптируются и так далее.
Но с другой стороны, я считаю, что чисто по-человечески - это не правильно. Не правильно относиться к каким-то сотрудникам как к людям второго класса, устраивая такую дедовщину. Те кто, пройдет, запомнят это, и будут так же относиться уже к своим стажерам, возможно даже , не понимая, что это не хорошо.
Помимо этого, такой подход создает психологические проблемы, для тех, кто этап отбора не прошел. И, несмотря на то, что для компании это не имеет значение, я все-равно считаю, что это не экологично.
А как ты считаешь, нормально ли так относиться к стажеру? Нужно ли их жалеть?
🤮 Негативные последствия код-ревью
Процесс ревью кода, был во всех компаниях, в которых я работал. Он настолько неотъемлемая часть процесса разработки, что может показаться - его наличие всегда благо. Но это не так.
Ниже 4 негативных последствия код-ревью
🤑 Удорожание процесса разработки
Предположим, я написал достаточно большой кусок кода, и отправил его на ревью. На следующий день, в середине дня его посмотрели, и. естественно оставили замечания. Отправив код на ревью, я занялся другой задачей. Потому вернулся к предыдущей задаче, когда текущую довел до какого-то логического завершения.
В лучшем случае поправил к концу дня, и снова отправил на ревью. Никто не сидит и судорожно не обновляет страницу в ожидании моих правок. Поэтому следующий раз его посмотрят в лучшем случае завтра.
И таких итерация может быть много. В итоге, я не могу погрузиться в новую задачу, и постоянно меняю контекст, от чего устаю быстрее. Коллеги тоже постоянно меняют контекст, прыгая от своих задач к моей, тоже не могут сконцентрироваться и быстрее устают.
Т.е. код написан, но работает, но не двигается дальше, а компания продолжает за это платить.
⚔️Конфликты внутри команды
Ревью может обидеть. Вроде бы ревьювер не хотел ничего плохого, просто написал как есть, но в состоянии недостатка вербальной информации (а ревью чаще всего проходит в виде текстовой переписки), можно такого себе придумать... И когда это происходит из раза в раз, то негатив копится, ухудшая взаимоотношения.
👎Снижение мотивации разработчиков
Во многих компаниях, ревью это единственный регулярный источник обратной связи. Причем негативной!
Единственный раз, когда я видел, чтобы человек на ревью писал, что-то вроде "great work", "amazing decision" и т.д. Причем делал это постоянно, но всегда уместно. Все остальные только указывали на ошибки.
Любой человек будет с удовольствием делать вещи, которые имеют положительный фитбек, и будет стараться избегать вещей, которые приносят негативный фитбэк. В итоге, если от написания кода в компании сотрудник получает исключительно негатив, он будет писать код меньше.
Зачем проявлять инициативу, если тебе просто укажут на ошибки и отправят переделывать?
📉Замедление роста разработчиков
Ответственность - это единственное топливо, благодаря которому люди растут. Если ревю сотрудника проходит тщательную проверку, то ответственность за результат делится между тем кто написал код и тем кто его смотрит.
Зачем все проверять самому, если все-равно за тобой будут перепроверять.
А еще вот это паскудное ощущение, что тебе не доверяют. В общем, код ревью сделает из тебя вечного мидла.
⚠️ Ошибки которых изначально не было
Если задача достаточно сложная, я себе записываю условия которым должна удовлетворять готовая задача, а так же тест кейсы. Конечно, это ни в какое сравнение не идет с тем, что пишут наши тестировщики, но это помогает убедиться, что фича полностью работает.
После каждой итерации исправлений на код ревью, мне приходится проверять фичу снова и снова. Это отнимает кучу времени и сил, и в итоге, я все-равно тестирую ее не так тщательно, как в самом начале.
И да, я ни раз, ловил баги, которые появились после правок на код ревью.
Если говорить на чистоту, то та однозначность, с которой все компании используют в своем флоу этот инструмент, вызывает у меня сомнения в его однозначной полезности.
А с какими негативными последствиями ты встречался?
Процесс ревью кода, был во всех компаниях, в которых я работал. Он настолько неотъемлемая часть процесса разработки, что может показаться - его наличие всегда благо. Но это не так.
Ниже 4 негативных последствия код-ревью
🤑 Удорожание процесса разработки
Предположим, я написал достаточно большой кусок кода, и отправил его на ревью. На следующий день, в середине дня его посмотрели, и. естественно оставили замечания. Отправив код на ревью, я занялся другой задачей. Потому вернулся к предыдущей задаче, когда текущую довел до какого-то логического завершения.
В лучшем случае поправил к концу дня, и снова отправил на ревью. Никто не сидит и судорожно не обновляет страницу в ожидании моих правок. Поэтому следующий раз его посмотрят в лучшем случае завтра.
И таких итерация может быть много. В итоге, я не могу погрузиться в новую задачу, и постоянно меняю контекст, от чего устаю быстрее. Коллеги тоже постоянно меняют контекст, прыгая от своих задач к моей, тоже не могут сконцентрироваться и быстрее устают.
Т.е. код написан, но работает, но не двигается дальше, а компания продолжает за это платить.
⚔️Конфликты внутри команды
Ревью может обидеть. Вроде бы ревьювер не хотел ничего плохого, просто написал как есть, но в состоянии недостатка вербальной информации (а ревью чаще всего проходит в виде текстовой переписки), можно такого себе придумать... И когда это происходит из раза в раз, то негатив копится, ухудшая взаимоотношения.
👎Снижение мотивации разработчиков
Во многих компаниях, ревью это единственный регулярный источник обратной связи. Причем негативной!
Единственный раз, когда я видел, чтобы человек на ревью писал, что-то вроде "great work", "amazing decision" и т.д. Причем делал это постоянно, но всегда уместно. Все остальные только указывали на ошибки.
Любой человек будет с удовольствием делать вещи, которые имеют положительный фитбек, и будет стараться избегать вещей, которые приносят негативный фитбэк. В итоге, если от написания кода в компании сотрудник получает исключительно негатив, он будет писать код меньше.
Зачем проявлять инициативу, если тебе просто укажут на ошибки и отправят переделывать?
📉Замедление роста разработчиков
Ответственность - это единственное топливо, благодаря которому люди растут. Если ревю сотрудника проходит тщательную проверку, то ответственность за результат делится между тем кто написал код и тем кто его смотрит.
Зачем все проверять самому, если все-равно за тобой будут перепроверять.
А еще вот это паскудное ощущение, что тебе не доверяют. В общем, код ревью сделает из тебя вечного мидла.
⚠️ Ошибки которых изначально не было
Если задача достаточно сложная, я себе записываю условия которым должна удовлетворять готовая задача, а так же тест кейсы. Конечно, это ни в какое сравнение не идет с тем, что пишут наши тестировщики, но это помогает убедиться, что фича полностью работает.
После каждой итерации исправлений на код ревью, мне приходится проверять фичу снова и снова. Это отнимает кучу времени и сил, и в итоге, я все-равно тестирую ее не так тщательно, как в самом начале.
И да, я ни раз, ловил баги, которые появились после правок на код ревью.
Если говорить на чистоту, то та однозначность, с которой все компании используют в своем флоу этот инструмент, вызывает у меня сомнения в его однозначной полезности.
А с какими негативными последствиями ты встречался?
👴 Проект про который я расскажу внукам
Неверно принятое архитектурное решение тем дешевле исправить, чем раньте их обнаружить. На этапе проектирование - дешево, на этапе разработки дороже, после разработки еще дороже.
Ну и дороже всего править архитектурные проблемы, которые много лет в проде, которые неоднократно подбивали костылями, а люди, писавшие этот код давно уволились.
Именно такая задача мне как-то досталась.
У нас в приложении была небольшая документация для клиентов, в ней раскрывались некоторые моменты работы с приложением.
Наполнением занимался отдел контента. Во время проектирования, кому-то в голову пришла гениальная идея. Дать возможность контенту править содержимое самостоятельно. В целом идея здравая, зачем отвлекать разработчиков, каждый раз, когда нужно поправить текст.
Для решения этой задачи была выбрана Тильда.
В интерфейсе конструктора, контент менеджер мог поправить тест или добавить статью. После чего он должен был запустить специальный скрипт, который генерировал из тильды статические файлы. Картинки и ссылки до стилей подменялись на те, которые лежат у нас. Чтобы тильда не лезла к себе на сервера, мы манкипатчили их либы. Получившаяся статика собиралась и вставилось в iframe в нашем приложении;.
Для общения с родительским приложением были расписаны специальные события через window post. Ну и чтобы отслеживать и перехватывать ненужные клики во время активации iframe подпиливали туда свой скрипт, который вместо кликов слал событие наверх.
И вот такой Фронштейн проработал несколько лет, пока все те, кто его писал не уволились.
Нюанс был в том, что контент очень быстро захотел новый дизайн, больше возможностей, анимации, видео, а поверх этого навешать амплитуду, чтобы строить тепловую карту поведения пользователя, куда кликнул, на что смотрел и тд
Именно в таком состоянии я взялся за эту задачу.
Особенность этой задачи для разработки была в том, что поднять тестовое окружение и играться с ним, не получалось. Поскольку все файлы создавались в интерфейсе Тильды, то и работать с ними нужно было там. А документацией, повторюсь пользоваться. Поэтому все приходилось делать осторожно, чтобы не поломать.
Изначально задача, которая мне досталась, была оценена в 2 дня разработки, но по факту я потратил на нее 2 месяца с небольшим. При этом глубина кроличьей норы изначально была не понятна, и чем дольше я погружался в задачу, тем больше факторов и стперов возникало.
По итогу я получил опыт который мне больше нигде не пригодится (я надеюсь), несколько седых волос, звание тильда-архитектора и понимание куда может завести преждевременная оптимизация.
Дело в том, что документация как в новом, так и в старом дизайне менялась очень редко, изредка расширяясь новыми статьями.
Именно поэтому решать проблемы нужно по мере их поступления.
Неверно принятое архитектурное решение тем дешевле исправить, чем раньте их обнаружить. На этапе проектирование - дешево, на этапе разработки дороже, после разработки еще дороже.
Ну и дороже всего править архитектурные проблемы, которые много лет в проде, которые неоднократно подбивали костылями, а люди, писавшие этот код давно уволились.
Именно такая задача мне как-то досталась.
У нас в приложении была небольшая документация для клиентов, в ней раскрывались некоторые моменты работы с приложением.
Наполнением занимался отдел контента. Во время проектирования, кому-то в голову пришла гениальная идея. Дать возможность контенту править содержимое самостоятельно. В целом идея здравая, зачем отвлекать разработчиков, каждый раз, когда нужно поправить текст.
Для решения этой задачи была выбрана Тильда.
В интерфейсе конструктора, контент менеджер мог поправить тест или добавить статью. После чего он должен был запустить специальный скрипт, который генерировал из тильды статические файлы. Картинки и ссылки до стилей подменялись на те, которые лежат у нас. Чтобы тильда не лезла к себе на сервера, мы манкипатчили их либы. Получившаяся статика собиралась и вставилось в iframe в нашем приложении;.
Для общения с родительским приложением были расписаны специальные события через window post. Ну и чтобы отслеживать и перехватывать ненужные клики во время активации iframe подпиливали туда свой скрипт, который вместо кликов слал событие наверх.
И вот такой Фронштейн проработал несколько лет, пока все те, кто его писал не уволились.
Нюанс был в том, что контент очень быстро захотел новый дизайн, больше возможностей, анимации, видео, а поверх этого навешать амплитуду, чтобы строить тепловую карту поведения пользователя, куда кликнул, на что смотрел и тд
Именно в таком состоянии я взялся за эту задачу.
Особенность этой задачи для разработки была в том, что поднять тестовое окружение и играться с ним, не получалось. Поскольку все файлы создавались в интерфейсе Тильды, то и работать с ними нужно было там. А документацией, повторюсь пользоваться. Поэтому все приходилось делать осторожно, чтобы не поломать.
Изначально задача, которая мне досталась, была оценена в 2 дня разработки, но по факту я потратил на нее 2 месяца с небольшим. При этом глубина кроличьей норы изначально была не понятна, и чем дольше я погружался в задачу, тем больше факторов и стперов возникало.
По итогу я получил опыт который мне больше нигде не пригодится (я надеюсь), несколько седых волос, звание тильда-архитектора и понимание куда может завести преждевременная оптимизация.
Дело в том, что документация как в новом, так и в старом дизайне менялась очень редко, изредка расширяясь новыми статьями.
Именно поэтому решать проблемы нужно по мере их поступления.