Да немного странно про безопасность.
Вообще мобильный он условно, он же в рабочем состоянии полностью открыт.
Т.е. вокруг должно быть полноценное здание, охрана и т.п.
Не так что в поле под ЛЭП закинул и майнишь :)
Да это обычный хайп, не совсем здоровый, как и все хайпы.
И обычная ошибка выборки, когда на форумах девелоперов меряются своими репами. Они меряются, да, но наличие репы на гитхабе говорит лишь о наличии репы на гитхабе, ни о чем больше.
Насчет интервью — всматриваться в чужой код занимает очень много времени, в этом часто нет никакого смысла, тем более делать это самому. Я иногда тыкаю в проект из резюме и прошу кандидата самого рассказать что там было интересного, почему он так считает и т.п. Это куда полезнее имхо.
Олимпиадники смеются над эти «открытием».
В жизни не довелось групповым заниматься, но парным — да.
Помогает, но man hours в среднем больше конечно уходит, чем по отдельности.
Поэтому я и написал про режим эксперимента. Вываливаешь в продакшн 5 дизов и проводишь AB тестирование.
Если дизайны Васи стабильно оказываются внизу при прочих равных — то он работает плохую работу.
Это кстати вполне годный вариант. Когда ты приходишь с готовым решением, и четко говоришь какие есть плюсы и какие минусы, но все уже готово. Как говорится лучше извиниться после, чем не сделать вообще.
Но тут как — если ты таким образом генеришь хорошие решения — то молодец, тебя заметят. Иначе попросят не портить код в будущем без согласования. И это может привести к написанию подобных статей.
Например если ты генеришь решения которые не совсем целям компании служат, и реализуешь их без обсуждения. К примеру потратил втихаря неделю чтоб ускорить код на 30%, в то время как вся команда пытается реализовать новую фичу, заваливая дедлайны, а со скоростью и так все было ок и запас есть.
работа дизайнера вообще никогда не увидит реальность
Вообще-то именно дизайн и видят люди.
Внутренняя метрика может быть количество итераций в работе с тем же фронтендером. Если каждый диз отфутболивается по 20 раз — это повод туда взглянуть поглубже и разобраться в чем проблема, иначе это тупо тормозит команду.
Внешняя метрика — можно вводить новый дизайн как эксперимент, и считать изменения метрик на сайте. Количество уходов / кликов и пр. Ну смотря что именно за дизайн вы делаете там.
Тут надо понимать, что если ты не выполняешь метрики это не значит что ты плохой работник или плохой человек :) Это значит что ты делаешь не совсем то, что нужно компании.
Странное разделение.
А разве человек который грамотно пишет репорты не может быть хорошим разрабом?
Может конечно. Да и вообще на большинстве сениор позиций нужно нормально общаться уметь, уж по крайней мере расписать чем ты занимаешься и зачем и кому это надо.
Никто не будет слушать человека, который не может заставить себя слушать.
Это естественный отбор, эволюция такая.
Свое решение надо уметь обосновать, добиться одобрения, и важно (!) и после защищать его от нападок и попыток отмены / отката.
Если не автор решения, то кто же еще это будет делать??
Ну в общем «критикуешь — предлагай». Вместо программиста и менеджера можно вставить «рабочего — прораба», «главврача — доктора», и т.п. Наивно думать что это проблема уникальна.
Конечно бывают клинические случаи, или просто нововведения реально не нужны в компании — ну так ты же программист, найти новую работу тебе это 2 дня работы.
Но теперь я знал: чтобы работа появилась в моем промо-пакете, я должен сначала настроить метрики, чтобы у нас появились исторические записи частоты оповещений.
Это конечно старый боян, и иногда это правда. Но не всегда :)
Часто действительно много времени занимает первоначальный сетап, чтобы все автоматизировать. Но это не значит, что ты потом пожизненно такую же зп должен получать :)
По хорошему это 2 процесса — создание инфрастуктуры и ее поддержка. Естественно на эти процессы тратятся разные ресурсы, разные скиллы и man months. Грубо говоря после сетапа тебя могут перевести на полставки, или четверть ставки. Разве это не справедливо? Вполне справедливо.
Просто если такой админ сидит на попе ровно, конечно его проклятие настигнет, как и любого наемного работника, сидящего ровно и плюющего в потолок.
Вообще если программер в гугле сам и метрики выбирает, то это вполне ОК.
В примере автора так-то непонятно вообще, сделал он лучше или хуже — имею в виду тот случай, когда сервис постоянно рестартился после рефакторинга. Весьма спорно.
Добавил бы метрику — количество случаев выдачи ложной информации. Получил бы прибавку :)
Еще один нюанс — по видимому автор никогда не имел своего хотя бы мелкого онлайн бизнеса, или даже не был фрилансером, что тоже бизнес по сути.
А дело в том, что будучи инди-разрабом ему придется принимать такие бизнес-решения каждый день, по многу раз в день. Все что он делает будет связано с одним вопросом — принесет ли это денег. Вот тогда он и поймет смысл метрик :)
Автор преподносит End to End покрытие тестами как большое необсуждаемое благо.
Но метрики — это то же самое покрытие тестами, только с точки зрения бизнеса.
Поэтому перед тем как начать работу над фичей или проектом, нужно:
— составить метрики — что конкретно плохо сейчас с точки зрения продукта и что ты хочешь решить — это и будут «тесты»
— оценить объем работ
— оценить или посоветоваться стоит ли потенциальное улучшение трудозатрат
— если да, то выполнить техническую часть
— проанализировать достижение метрик (выполнение «тестов»)
Любой сениор-разработчик должен дело это для любого даже самого мелкого задания.
Иногда это достаточно делать в уме, а не на бумаге.
И еще раз, самое важное здесь — каждый сениор программист должен это делать сам, для себя. Это не работа менеджера или QA и т.п.
И это не манагерский подход, это обычный подход здравого смысла.
Если программист не может / не считает нужным так делать — то он и не является сениор девелопером.
Вообще мобильный он условно, он же в рабочем состоянии полностью открыт.
Т.е. вокруг должно быть полноценное здание, охрана и т.п.
Не так что в поле под ЛЭП закинул и майнишь :)
И обычная ошибка выборки, когда на форумах девелоперов меряются своими репами. Они меряются, да, но наличие репы на гитхабе говорит лишь о наличии репы на гитхабе, ни о чем больше.
Насчет интервью — всматриваться в чужой код занимает очень много времени, в этом часто нет никакого смысла, тем более делать это самому. Я иногда тыкаю в проект из резюме и прошу кандидата самого рассказать что там было интересного, почему он так считает и т.п. Это куда полезнее имхо.
Сениор — должен включать мозг прежде чем тратить свое время.
В жизни не довелось групповым заниматься, но парным — да.
Помогает, но man hours в среднем больше конечно уходит, чем по отдельности.
Если дизайны Васи стабильно оказываются внизу при прочих равных — то он работает плохую работу.
Но тут как — если ты таким образом генеришь хорошие решения — то молодец, тебя заметят. Иначе попросят не портить код в будущем без согласования. И это может привести к написанию подобных статей.
Например если ты генеришь решения которые не совсем целям компании служат, и реализуешь их без обсуждения. К примеру потратил втихаря неделю чтоб ускорить код на 30%, в то время как вся команда пытается реализовать новую фичу, заваливая дедлайны, а со скоростью и так все было ок и запас есть.
Вообще-то именно дизайн и видят люди.
Внутренняя метрика может быть количество итераций в работе с тем же фронтендером. Если каждый диз отфутболивается по 20 раз — это повод туда взглянуть поглубже и разобраться в чем проблема, иначе это тупо тормозит команду.
Внешняя метрика — можно вводить новый дизайн как эксперимент, и считать изменения метрик на сайте. Количество уходов / кликов и пр. Ну смотря что именно за дизайн вы делаете там.
Тут надо понимать, что если ты не выполняешь метрики это не значит что ты плохой работник или плохой человек :) Это значит что ты делаешь не совсем то, что нужно компании.
А разве человек который грамотно пишет репорты не может быть хорошим разрабом?
Может конечно. Да и вообще на большинстве сениор позиций нужно нормально общаться уметь, уж по крайней мере расписать чем ты занимаешься и зачем и кому это надо.
Это естественный отбор, эволюция такая.
Свое решение надо уметь обосновать, добиться одобрения, и важно (!) и после защищать его от нападок и попыток отмены / отката.
Если не автор решения, то кто же еще это будет делать??
Ну в общем «критикуешь — предлагай». Вместо программиста и менеджера можно вставить «рабочего — прораба», «главврача — доктора», и т.п. Наивно думать что это проблема уникальна.
Конечно бывают клинические случаи, или просто нововведения реально не нужны в компании — ну так ты же программист, найти новую работу тебе это 2 дня работы.
Часто действительно много времени занимает первоначальный сетап, чтобы все автоматизировать. Но это не значит, что ты потом пожизненно такую же зп должен получать :)
По хорошему это 2 процесса — создание инфрастуктуры и ее поддержка. Естественно на эти процессы тратятся разные ресурсы, разные скиллы и man months. Грубо говоря после сетапа тебя могут перевести на полставки, или четверть ставки. Разве это не справедливо? Вполне справедливо.
Просто если такой админ сидит на попе ровно, конечно его проклятие настигнет, как и любого наемного работника, сидящего ровно и плюющего в потолок.
В примере автора так-то непонятно вообще, сделал он лучше или хуже — имею в виду тот случай, когда сервис постоянно рестартился после рефакторинга. Весьма спорно.
Добавил бы метрику — количество случаев выдачи ложной информации. Получил бы прибавку :)
Еще один нюанс — по видимому автор никогда не имел своего хотя бы мелкого онлайн бизнеса, или даже не был фрилансером, что тоже бизнес по сути.
А дело в том, что будучи инди-разрабом ему придется принимать такие бизнес-решения каждый день, по многу раз в день. Все что он делает будет связано с одним вопросом — принесет ли это денег. Вот тогда он и поймет смысл метрик :)
Но метрики — это то же самое покрытие тестами, только с точки зрения бизнеса.
Поэтому перед тем как начать работу над фичей или проектом, нужно:
— составить метрики — что конкретно плохо сейчас с точки зрения продукта и что ты хочешь решить — это и будут «тесты»
— оценить объем работ
— оценить или посоветоваться стоит ли потенциальное улучшение трудозатрат
— если да, то выполнить техническую часть
— проанализировать достижение метрик (выполнение «тестов»)
Любой сениор-разработчик должен дело это для любого даже самого мелкого задания.
Иногда это достаточно делать в уме, а не на бумаге.
И еще раз, самое важное здесь — каждый сениор программист должен это делать сам, для себя. Это не работа менеджера или QA и т.п.
И это не манагерский подход, это обычный подход здравого смысла.
Если программист не может / не считает нужным так делать — то он и не является сениор девелопером.