Пишите ли вы TDR?
Anonymous Poll
20%
Да, у нас похожий процесс
7%
Да, но у нас по-другому
6%
Нет, вводили, но не прижилось
34%
Нет, не вводили, но думаем
34%
Другое
Влияет ли стресс на результативность технического собеседования?
Часто читаю блог Тимура и нахожу много полезных статей. Например, эта дает понять, как сильно отличаются разные подготовки к собесам.
Одна из моих целей когда-нибудь пройти собес в FAANG. Поэтому я много уделяю подготовки не только для реальных задач, но и для собесов. Я долго отказывался верить, что собеседования отличается от реальной жизни. Винил себя, что недостаточно опытный или скилловый. Бесспорно, это так. Но я понял, что на собеседованиях также важны навыки, которые не натренируешь на рабочих задачах.
Я думал, что будет достаточно спокойно и без спешки решать задачи и всё будет окей. А если не прошел собес, то значит просто недостаточно много решал.
Но вот очередные исследования, где доказали как стресс и сжатые условия влияют на результат.
В этом эксперименте людей разделили на две группы и заставили решать задачу у доски:
🟣 В первой группе люди решали задачи в раслабленном темпе, но сильно выходили за временные рамки
🟣 Во второй же группе люди решали задачи перед интервьюерами, где укладывались в сроки
🟣 Первая группа находила более оптимальные решения.
🟣 Результаты тех, кто провалил задачи в первой группе равны 36.3%, а во второй аж 61.5%.
Охереть. Я догадывался, что стресс сильно дебафает, но не настолько.
🌋 О чем это говорит?
Как минимум, что навыки решения задач сильно падают при реальном собеседовании и что недостаточно просто соло решать литкод, закрывшись в четырех стенах. А решение тысяч задач на платформах не гарантирует успех.
Такие статьи корректируют планы развития. Обесценивает просто сборники задач как литкод, голые задачи и кол-во решение. Показывают, насколько же важно окружение и практика в боевых условиях. Необходимые условия и контексты.
Нужно работать над психологическим состоянием и уметь контролировать стресс. Эта же проблема была очень часто и в спорте, когда множество ребят отлично показывают себя на тренировках, но теряются на соревнованиях.
Возможно, именно поэтому мы и сделали мок-собесы, чтобы каждый желающий мог попробовать себя, натренироваться и поделиться опытом с другими.
Часто читаю блог Тимура и нахожу много полезных статей. Например, эта дает понять, как сильно отличаются разные подготовки к собесам.
Одна из моих целей когда-нибудь пройти собес в FAANG. Поэтому я много уделяю подготовки не только для реальных задач, но и для собесов. Я долго отказывался верить, что собеседования отличается от реальной жизни. Винил себя, что недостаточно опытный или скилловый. Бесспорно, это так. Но я понял, что на собеседованиях также важны навыки, которые не натренируешь на рабочих задачах.
Я думал, что будет достаточно спокойно и без спешки решать задачи и всё будет окей. А если не прошел собес, то значит просто недостаточно много решал.
Но вот очередные исследования, где доказали как стресс и сжатые условия влияют на результат.
В этом эксперименте людей разделили на две группы и заставили решать задачу у доски:
Охереть. Я догадывался, что стресс сильно дебафает, но не настолько.
Как минимум, что навыки решения задач сильно падают при реальном собеседовании и что недостаточно просто соло решать литкод, закрывшись в четырех стенах. А решение тысяч задач на платформах не гарантирует успех.
Такие статьи корректируют планы развития. Обесценивает просто сборники задач как литкод, голые задачи и кол-во решение. Показывают, насколько же важно окружение и практика в боевых условиях. Необходимые условия и контексты.
Нужно работать над психологическим состоянием и уметь контролировать стресс. Эта же проблема была очень часто и в спорте, когда множество ребят отлично показывают себя на тренировках, но теряются на соревнованиях.
Возможно, именно поэтому мы и сделали мок-собесы, чтобы каждый желающий мог попробовать себя, натренироваться и поделиться опытом с другими.
Please open Telegram to view this post
VIEW IN TELEGRAM
1
Что выведется в консоль?
Anonymous Quiz
16%
one, two, three, five
7%
one, two, three
5%
five, three, two, one
29%
1, 2, 3, 5
21%
1, 2, 3
5%
5, 3, 2, 1
2%
3, 2, 1
2%
three, two, one
12%
Другое
Вчера я писал пост, что мок-интервью — очень хороший инструмент преодолеть психологический мандраж, который сильно ухудшает наши навыки на собесах. Недостаточно в комфортных условиях решать задачи и зубрить ответы. Собеседования чаще очень отличаются, от условий реальной работы.
Считается, что собесы яндекса часто являются одними из сложных и стрессовых. Там много кодинга, много практики и мало теории. Все очень сжатое в сроках и большая конкуренция за место.
Вот мы и позвали разработчика из Яндекс.Еды, чтобы он поделился своим опытом. Показал, какие косвенные вопросы он бы задал и на что бы смотрел. Вышло очень круто.
Подписывайтесь на его канал
@swifyway
Please open Telegram to view this post
VIEW IN TELEGRAM
Все что говорят в интернете умножай на ноль
Забавно, на днях в чате мы общались по поводу Kotlin Multiplatform. Вспоминали тему мобиуса год назад. Где множество команд говорили, что Kotlin Multiplatform — это будущее. А сейчас разработчики, которые работают в тех командах говорят, что почти никогда не слышали и не видели то, о чем говорят свои коллеги. Никаких Kotlin Multiplatform уже нет в проектах. Ну либо эти инструменты уже выпилили, либо юзают только в очень специфичных кейсах.
Как теперь верить этим громким заголовкам, что будущее не станет как прежде?
Если так подумать, что почти всегда интернет был местом сказок. Статьи и доклады сильно искажали реальность.
Десять лет назад мобильную индустрию должен был убить React Native. Потом Flutter. Потом Kotlin Multiplatform. Сейчас BDUI.
Но натив все равно не просто подает признаки жизни — он живее всех живых.
Каждый год доклады приносят очередного геймченджера и кричат, что это будущее мобильной разработки. Но страшное будущее быстро становится забытым прошлым. А на его место приходит очередной громкий заголовок.
Много сказок у нас было в мобильной разработке:
- хайп по архитектурам, которые помогают писать юнит тесты. Которые в итоге никто и не пишет на клиентах.
- кроссплатформы
- BDUI
- тесты
- алгоритмы
- систем дизайн
В итоге, из своих громких обещаний завоевать рынок, это начало скромно лежать в стороне Или вообще отмирать.
Забавно, на днях в чате мы общались по поводу Kotlin Multiplatform. Вспоминали тему мобиуса год назад. Где множество команд говорили, что Kotlin Multiplatform — это будущее. А сейчас разработчики, которые работают в тех командах говорят, что почти никогда не слышали и не видели то, о чем говорят свои коллеги. Никаких Kotlin Multiplatform уже нет в проектах. Ну либо эти инструменты уже выпилили, либо юзают только в очень специфичных кейсах.
Как теперь верить этим громким заголовкам, что будущее не станет как прежде?
Если так подумать, что почти всегда интернет был местом сказок. Статьи и доклады сильно искажали реальность.
Десять лет назад мобильную индустрию должен был убить React Native. Потом Flutter. Потом Kotlin Multiplatform. Сейчас BDUI.
Но натив все равно не просто подает признаки жизни — он живее всех живых.
Каждый год доклады приносят очередного геймченджера и кричат, что это будущее мобильной разработки. Но страшное будущее быстро становится забытым прошлым. А на его место приходит очередной громкий заголовок.
Много сказок у нас было в мобильной разработке:
- хайп по архитектурам, которые помогают писать юнит тесты. Которые в итоге никто и не пишет на клиентах.
- кроссплатформы
- BDUI
- тесты
- алгоритмы
- систем дизайн
В итоге, из своих громких обещаний завоевать рынок, это начало скромно лежать в стороне Или вообще отмирать.
10
В чате мы начали новую рубрику. Каждый день решаем какие-то задачи для iOS.
Вы можете предлагать свои в комментах или лс @lvbond
буду иногда делиться тут
Вы можете предлагать свои в комментах или лс @lvbond
буду иногда делиться тут
This media is not supported in your browser
VIEW IN TELEGRAM
Молодым до 30 посвящается
Остальным кто после соболезнуем
Остальным кто после соболезнуем
3
This media is not supported in your browser
VIEW IN TELEGRAM
Мы все пришли сюда, чтобы нормально покодить
О слитых сборниках для собесов.
Не секрет, что уже давно по сетям ходят всякие паровозики собесов или сборники "сливов". В начале этой недели мне подогнали один из сборников за косарь рублей и я его изучал. Думал может что-то подчерпну в канал или ноушен. Но как же я ошибался... Посмотря на него я даже подумал, что мой контент стоит слишком мало, раз люди не стесняются продавать настолько абсолютно сырой материал за подписку в 2 раза дороже.
Давайте разберемся по порядку почему никакие сливы не дадут ощутимого импакта:
1. Все сливы — это записи собесов. Стоит ли говорить, что вопросы для джуна и сеньора чаще ничем не отличаются? Ожидается лишь качество ответа. Но в этих сливах был самый рофл — там просто аудиосообщения в комментах телеграма. Будто кто-то диктофоном записал свой собес без кода и тупо выложил свое эканье и бэканье. Ну или в 80% откровенно неправильную инфу.
2. Задачи решены неправильно. Обычно сливами и активной подготовкой к собесам занимаются либо стажеры, либо джуны. Уровень решения на задачи мы уже разбирали в чате. Большинству решений не дашь уровень мидл-, а чаще и джун-. До среднего мидла ответы нужно переписывать раз 10. Многие кейсы не утчены, условия недопоняты.
3. Неправильный сбор требований или понимания вопросов. Накрученный опыт и навыки не дадут скиллы и культуру, которая легко читается. Это видно по тому, как сформулированы эти "слитые задачи". Что-то в стиле "ну вот меня спросили какую-то хрень и я даже не понял о чем это". Это было в алгоритмах, где какой-то новичок не знал про оценку алгоритмов. Все это выглядело как кривой перевод с али-экспересса, где даже опытный разработчик не всегда понимает что же "слил" джуниор. Ведь он попытался связать слова, которые он не понимает, в предложения. От чего никто ничего не понял.
В общем, если кто-то верит, что можно просто пропустить десятки и сотни часов обучения и обмануть систему — вы страшно ошибаетесь. Аудит эти подходы не прошли и были разбиты. Это как посмотреть сотни видосов на ютубе по изучению английского от индусов с ярким акцентом, но забывать про практику. Попробуй теперь отмойся и переучись.
Ну а мы пришли сюда, чтобы нормально покодить и найти самые эффективные инструменты развития, не боясь трудностей и ошибок. Главное помнить, что нет никаких сеньорных вопросов, есть только сеньорные ответы и окружение.
Не секрет, что уже давно по сетям ходят всякие паровозики собесов или сборники "сливов". В начале этой недели мне подогнали один из сборников за косарь рублей и я его изучал. Думал может что-то подчерпну в канал или ноушен. Но как же я ошибался... Посмотря на него я даже подумал, что мой контент стоит слишком мало, раз люди не стесняются продавать настолько абсолютно сырой материал за подписку в 2 раза дороже.
Давайте разберемся по порядку почему никакие сливы не дадут ощутимого импакта:
1. Все сливы — это записи собесов. Стоит ли говорить, что вопросы для джуна и сеньора чаще ничем не отличаются? Ожидается лишь качество ответа. Но в этих сливах был самый рофл — там просто аудиосообщения в комментах телеграма. Будто кто-то диктофоном записал свой собес без кода и тупо выложил свое эканье и бэканье. Ну или в 80% откровенно неправильную инфу.
2. Задачи решены неправильно. Обычно сливами и активной подготовкой к собесам занимаются либо стажеры, либо джуны. Уровень решения на задачи мы уже разбирали в чате. Большинству решений не дашь уровень мидл-, а чаще и джун-. До среднего мидла ответы нужно переписывать раз 10. Многие кейсы не утчены, условия недопоняты.
3. Неправильный сбор требований или понимания вопросов. Накрученный опыт и навыки не дадут скиллы и культуру, которая легко читается. Это видно по тому, как сформулированы эти "слитые задачи". Что-то в стиле "ну вот меня спросили какую-то хрень и я даже не понял о чем это". Это было в алгоритмах, где какой-то новичок не знал про оценку алгоритмов. Все это выглядело как кривой перевод с али-экспересса, где даже опытный разработчик не всегда понимает что же "слил" джуниор. Ведь он попытался связать слова, которые он не понимает, в предложения. От чего никто ничего не понял.
В общем, если кто-то верит, что можно просто пропустить десятки и сотни часов обучения и обмануть систему — вы страшно ошибаетесь. Аудит эти подходы не прошли и были разбиты. Это как посмотреть сотни видосов на ютубе по изучению английского от индусов с ярким акцентом, но забывать про практику. Попробуй теперь отмойся и переучись.
Ну а мы пришли сюда, чтобы нормально покодить и найти самые эффективные инструменты развития, не боясь трудностей и ошибок. Главное помнить, что нет никаких сеньорных вопросов, есть только сеньорные ответы и окружение.
Премии — это чаевые
Часто слышу, что премии это обман. Но я так не считаю и не иду в компании, где их нет.
Я из семьи работяг. Учителей, которые были под вечным давлением требуемой от них образцовости. Нужно допускать минимум ошибок или придет чья-то мамка со словами «как вы наших детей воспитываете, если сами не даете пример или плохо воспитываете своих?».
В архитектуре их работы лежит преданность делу и тяжелый труд. Лимит на ошибки был минимальный. Давление и переработки. Для таких людей признание их работы и благодарность имеют особую ценность. Ведь в это вложены плоть и душа.
Это воспитание научило меня также не только уважать свою работу, но и быть благодарным за чужую хорошую работу. Кто имеет уважение и профессионализм. За это я всегда стараюсь платить чаевые или дать взамен ценность. Чтобы не угасал огонь внутри. Будь это барбер, официант, программист или кто-либо еще.
А уж если человек очарован своей работой, то он вызывает восхищение и добрую зависть. Хочется приблизиться к нему и постоять рядом дольше.
Часто слышал истории, как хорошие чаевые меняли жизнь на «до» и «после» у официантов. Им начинала нравится их работа и появлялось старание и конкуренция. Сервис и качество работы сильно улучшались. Люди придумывали целые системы и методологии.
Я не рассматриваю компании, где нет хороших премий. Там нет стимула для развития. Есть фикс оклад, который заставляет монотонно работать от звонка до звонка. Это гнетущая и неплодородная атмосфера.
А главное, без справедливой системы премирования нет культуры благодарности и мотивации делать что-то лучше.
Плоды не растут лучше без оценки за сверхрезультат
Часто слышу, что премии это обман. Но я так не считаю и не иду в компании, где их нет.
Я из семьи работяг. Учителей, которые были под вечным давлением требуемой от них образцовости. Нужно допускать минимум ошибок или придет чья-то мамка со словами «как вы наших детей воспитываете, если сами не даете пример или плохо воспитываете своих?».
В архитектуре их работы лежит преданность делу и тяжелый труд. Лимит на ошибки был минимальный. Давление и переработки. Для таких людей признание их работы и благодарность имеют особую ценность. Ведь в это вложены плоть и душа.
Это воспитание научило меня также не только уважать свою работу, но и быть благодарным за чужую хорошую работу. Кто имеет уважение и профессионализм. За это я всегда стараюсь платить чаевые или дать взамен ценность. Чтобы не угасал огонь внутри. Будь это барбер, официант, программист или кто-либо еще.
А уж если человек очарован своей работой, то он вызывает восхищение и добрую зависть. Хочется приблизиться к нему и постоять рядом дольше.
Часто слышал истории, как хорошие чаевые меняли жизнь на «до» и «после» у официантов. Им начинала нравится их работа и появлялось старание и конкуренция. Сервис и качество работы сильно улучшались. Люди придумывали целые системы и методологии.
Я не рассматриваю компании, где нет хороших премий. Там нет стимула для развития. Есть фикс оклад, который заставляет монотонно работать от звонка до звонка. Это гнетущая и неплодородная атмосфера.
А главное, без справедливой системы премирования нет культуры благодарности и мотивации делать что-то лучше.
Плоды не растут лучше без оценки за сверхрезультат
iOS Makes Me Hate
Мы все пришли сюда, чтобы нормально покодить
Media is too big
VIEW IN TELEGRAM
Вторая часть шедевра
Мы пережили блокировку ноушена.
На всякий случай мы рыли окопы, пытались перейти в альтернативы.
База знаний соощества работает и не удалена. Остаемся в ноушене, но кому-то нужно включить VPN.
В честь этого праздника я решил сделать новую рубрику. Я понял, как много контента генерирует чат и я его преступно нигде не фиксирую.
Мы пришли сюда, чтобы решать задачи. Как в Google. Как в Apple.
Только с конца августа и начала сентября мы обсудили около 30 технических вопросов, и около 20 реальных задач. Всего за 2 недели, а это больше и чаще чем подборки в ноушене, которые я делаю сам. Может пора делать журнал, с разными авторами, а не личный блог?
Я знаю, что 1/3 подписчиков не подписана на чат, а те кто подписан не всегда могут его читать. Поэтому решил сделать отдельную подборку. Теперь она моя самая любимая. Этот сборник посвящен всем вопросам и задачам, которые мы решали в сообществе, встречали на собеседованиях или на работе. Они будут в рандомном порядке, без тем и часто без ответов (так даже лучше для самостоятельного изучения).
Если ты не следишь за чатом, то это отличная возможность оставаться в курсе без активного мониторинга.Но все же ты упускаешь живое обсуждение, которое лучше помогает усвоить материал.
💎 Получить доступ к задачам можно через подписку в бусти, там последний день скидок, или в боте.
На всякий случай мы рыли окопы, пытались перейти в альтернативы.
База знаний соощества работает и не удалена. Остаемся в ноушене, но кому-то нужно включить VPN.
В честь этого праздника я решил сделать новую рубрику. Я понял, как много контента генерирует чат и я его преступно нигде не фиксирую.
Мы пришли сюда, чтобы решать задачи. Как в Google. Как в Apple.
Только с конца августа и начала сентября мы обсудили около 30 технических вопросов, и около 20 реальных задач. Всего за 2 недели, а это больше и чаще чем подборки в ноушене, которые я делаю сам. Может пора делать журнал, с разными авторами, а не личный блог?
Я знаю, что 1/3 подписчиков не подписана на чат, а те кто подписан не всегда могут его читать. Поэтому решил сделать отдельную подборку. Теперь она моя самая любимая. Этот сборник посвящен всем вопросам и задачам, которые мы решали в сообществе, встречали на собеседованиях или на работе. Они будут в рандомном порядке, без тем и часто без ответов (так даже лучше для самостоятельного изучения).
Если ты не следишь за чатом, то это отличная возможность оставаться в курсе без активного мониторинга.
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Карьера в FAANG
Прежде чем давать советы по оптимизации карьерных документов, давайте разберемся в общем процессе. Если вы уже знаете правила, не спешите закрывать этот пост, дайте ему шанс передать вам новую перспективу.
Итак, в Big Tech компаниях существует процесс под названием performance review. Каждый сотрудник хочет бонус побольше. Большинство сотрудников хотят повышения позиции. Чтобы жизнь организации не превратилась в хаос все время клянчущих денег сотрудников, эти естественные желания официально признаны, и организованы в стандартизированный процесс, который и назвали performance review, или, в простонародье, perf (перф). Прежде чем обсуждать суть дела, быстро про форму:
- Заранее готовится сетка требований для уровней, о которой я много писал
- 1-2 раза в год в фиксированные даты объявляется perf
- Каждый сотрудник пишет документ, который называется self assessment. В этом документе сотрудник описывает, что он полезного сделал для мира и компании, что у него получилось особенно хорошо, а где он в себе обнаружил слабые стороны
- Сотрудник так же просит коллег, с которыми работал, написать ему "peer feedback" -- то же самое, что и self assessment, только вкратце и с точки зрения коллеги
- Сотрудник сам пишет peer feedback для коллег
- Лиды организации собираются в calibration committee и обсуждают все self assessment документы, анализируют и соглашаются (или нет) с тезисами
- Дальше идет процесс stack ranking, который изобрел лично дьявол, поэтому я про него тут писать не буду (а еще потому, что о нем бесполезно писать, все равно кандидат ничего не может сделать, чтобы на него повлиять)
- В результате обсуждения self assessment документов сотруднику назначается "рейтинг"
- От рейтинга напрямую и значительно зависит годовой бонус -- можно заработать вплоть до x1.5 от ожидаемого
Дополнительно, сотрудник может номинировать себя на повышение уровня. Да, именно так: ты просто говоришь: по сетке требований я работаю на уровень выше, вот в моем self assessment все доказательства. Потому повышайте меня, чтобы моя работа на уровень выше была и оплачена тоже на уровень выше. В этом случае добавляется несколько шагов:
- Self assessment документ становится больше / полнее / сложнее написать, ведь нужны дополнительные доказательства для новой аудитории читателей
- Дополнительно к calibration committee собирается promo committee, обычно из более старших коллег (а в Гугле раньше еще и из случайных коллег со всего Гугла)
- Второй комитет решает, одобрить ли номинирование сотрудника или нет
- Senior leaders (обычно VP) подписывают одобренные номинации, делая повышение официальным
Такова форма, а в чем же суть? Суть процесса в том, чтобы главным по процессу получения бонусов и повышений был самый заинтересованный в них человек -- сам сотрудник. Именно он сам для себя изучает ладдер, весь год выбирает правильную работу, которая ему поможет на перфе, сам собирает все нужные доказательства, сам составляет self assessment -- презентацию своих аргументов, сам анализирует, что нужно изменить в работе в следующий цикл, чтобы в следующий раз составить еще более впечатляющий документ, который приведет к еще большим бонусам. Кандидат больше всех заинтересован в финансовом вознаграждении, а значит никто больше не сможет так хорошо доказать, что он его достоин. Такой процесс убирает гигатонны микроменеджмента, назначения задач, слежки, кто что сделал. Ведь perf рассудит.
Это теория. Реальность, как всегда, вносит свои коррективы. Их я буду обсуждать в следующем посте, а сейчас я предлагаю читателям (вы же инженеры!) найти уязвимости в этом процессе и мы обсудим их в комментариях.
#perf
Итак, в Big Tech компаниях существует процесс под названием performance review. Каждый сотрудник хочет бонус побольше. Большинство сотрудников хотят повышения позиции. Чтобы жизнь организации не превратилась в хаос все время клянчущих денег сотрудников, эти естественные желания официально признаны, и организованы в стандартизированный процесс, который и назвали performance review, или, в простонародье, perf (перф). Прежде чем обсуждать суть дела, быстро про форму:
- Заранее готовится сетка требований для уровней, о которой я много писал
- 1-2 раза в год в фиксированные даты объявляется perf
- Каждый сотрудник пишет документ, который называется self assessment. В этом документе сотрудник описывает, что он полезного сделал для мира и компании, что у него получилось особенно хорошо, а где он в себе обнаружил слабые стороны
- Сотрудник так же просит коллег, с которыми работал, написать ему "peer feedback" -- то же самое, что и self assessment, только вкратце и с точки зрения коллеги
- Сотрудник сам пишет peer feedback для коллег
- Лиды организации собираются в calibration committee и обсуждают все self assessment документы, анализируют и соглашаются (или нет) с тезисами
- Дальше идет процесс stack ranking, который изобрел лично дьявол, поэтому я про него тут писать не буду (а еще потому, что о нем бесполезно писать, все равно кандидат ничего не может сделать, чтобы на него повлиять)
- В результате обсуждения self assessment документов сотруднику назначается "рейтинг"
- От рейтинга напрямую и значительно зависит годовой бонус -- можно заработать вплоть до x1.5 от ожидаемого
Дополнительно, сотрудник может номинировать себя на повышение уровня. Да, именно так: ты просто говоришь: по сетке требований я работаю на уровень выше, вот в моем self assessment все доказательства. Потому повышайте меня, чтобы моя работа на уровень выше была и оплачена тоже на уровень выше. В этом случае добавляется несколько шагов:
- Self assessment документ становится больше / полнее / сложнее написать, ведь нужны дополнительные доказательства для новой аудитории читателей
- Дополнительно к calibration committee собирается promo committee, обычно из более старших коллег (а в Гугле раньше еще и из случайных коллег со всего Гугла)
- Второй комитет решает, одобрить ли номинирование сотрудника или нет
- Senior leaders (обычно VP) подписывают одобренные номинации, делая повышение официальным
Такова форма, а в чем же суть? Суть процесса в том, чтобы главным по процессу получения бонусов и повышений был самый заинтересованный в них человек -- сам сотрудник. Именно он сам для себя изучает ладдер, весь год выбирает правильную работу, которая ему поможет на перфе, сам собирает все нужные доказательства, сам составляет self assessment -- презентацию своих аргументов, сам анализирует, что нужно изменить в работе в следующий цикл, чтобы в следующий раз составить еще более впечатляющий документ, который приведет к еще большим бонусам. Кандидат больше всех заинтересован в финансовом вознаграждении, а значит никто больше не сможет так хорошо доказать, что он его достоин. Такой процесс убирает гигатонны микроменеджмента, назначения задач, слежки, кто что сделал. Ведь perf рассудит.
Это теория. Реальность, как всегда, вносит свои коррективы. Их я буду обсуждать в следующем посте, а сейчас я предлагаю читателям (вы же инженеры!) найти уязвимости в этом процессе и мы обсудим их в комментариях.
#perf
Кодревью: Запахи кода
Делюсь небольшим контентом связанным с запахами кода. Я уже делал один и второй сборник в закрытой базе знаний.
Здесь я же хочу поделиться интересными для меня "запахами", почти как парфюмер. Кода я понюхал много и чаще споры об этих запахах возникают на кодревью.
Давайте же разберем несколько примеров:
1. Force Unwrapping и Force Casting. Многими нелюбимая вещь, которая может привести к крашем. В проде нужно свести к минимуму любой потенциальный сбой приложения
2. Переизбыток синглтонов. Сами по себе синглтоны не несут в себе зла, но их злоупотребление может сделать код сложнее. Так усложнится рефакторинг и предсказуемость.
3. Дублирование кода. Наверное, самый частый запах. Когда код повторяется в разных местах класса или приложения, то усложняется, поддержка кода и возникает риск ухудшения стабильности приложения.
4. Надуманная сложность. Одна из главных проблем охотниками за повышениями и любителей поумничать — выдувать из воздуха сложность задач и делать сложным простое. Сорри, яндекс, но ваших разрабов часто за это ругают. Нужно всегда правильно рассчитывать как можно обойтись более лаконичным решением и не усложнять без необходимости.
5. Комментарии. Комментарии важны для любого кода, поскольку они улучшают понимание разработчиками этого конкретного кода. Следовательно, комментарии можно добавлять везде, где возникает необходимость, но не слишком много, поскольку это может нарушить поток кода и усложнить его.
Основная цель комментариев — определить логику и обоснование различных частей кода и объяснить их точку зрения. Однако разработчику следует избегать переусердствовать, поскольку слишком много комментариев приведет к усложнению и баннерной слепоте, а иногда и комментированию очевидных вещей.
Делюсь небольшим контентом связанным с запахами кода. Я уже делал один и второй сборник в закрытой базе знаний.
Здесь я же хочу поделиться интересными для меня "запахами", почти как парфюмер. Кода я понюхал много и чаще споры об этих запахах возникают на кодревью.
Термин “запах кода” (code smell) некоторое время назад был введен Кентом Беком и популяризирован книгой Мартина Фаулера о рефакторинге (Refactoring: Improving the Design of Existing Code).
В русскоязычном переводе можно встретить “код с душком”. Такой перевод явно говорит о том, что речь идет о чем-то не слишком хорошем.
Давайте же разберем несколько примеров:
1. Force Unwrapping и Force Casting. Многими нелюбимая вещь, которая может привести к крашем. В проде нужно свести к минимуму любой потенциальный сбой приложения
2. Переизбыток синглтонов. Сами по себе синглтоны не несут в себе зла, но их злоупотребление может сделать код сложнее. Так усложнится рефакторинг и предсказуемость.
3. Дублирование кода. Наверное, самый частый запах. Когда код повторяется в разных местах класса или приложения, то усложняется, поддержка кода и возникает риск ухудшения стабильности приложения.
4. Надуманная сложность. Одна из главных проблем охотниками за повышениями и любителей поумничать — выдувать из воздуха сложность задач и делать сложным простое. Сорри, яндекс, но ваших разрабов часто за это ругают. Нужно всегда правильно рассчитывать как можно обойтись более лаконичным решением и не усложнять без необходимости.
5. Комментарии. Комментарии важны для любого кода, поскольку они улучшают понимание разработчиками этого конкретного кода. Следовательно, комментарии можно добавлять везде, где возникает необходимость, но не слишком много, поскольку это может нарушить поток кода и усложнить его.
Основная цель комментариев — определить логику и обоснование различных частей кода и объяснить их точку зрения. Однако разработчику следует избегать переусердствовать, поскольку слишком много комментариев приведет к усложнению и баннерной слепоте, а иногда и комментированию очевидных вещей.