Вы компетенции разработчиков меряете их личностными особенностями?
В моем понимании, seniority так и выражается — если что-то не нравится, и ты сказал/предложил/решил, если что-то не работает, и ты сказал/предложил/решил, а не наоборот — забил до момента пока спросят.
Вам нравится загонять людей в зону некомфорта? Раз они рассказывают на встрече, но не приходят сами — наверное им так комфортнее?
Изначально, мы договариваемся о всех процессах. Если они приняты в команде, значит, либо всем нравятся, либо нравится большинству, либо так просто правильно в определенной ситуации. И если мы приняли правила, значит, мы считаем их эффективным. Если это некомфортно для человека, значит, это команда ему не подходит. Нормально, когда не подходит, и, конечно, в любой адекватной команде/компании пытаются сделать лучше, что-то поменять или перенастроить. Но не всегда же идти на уступки, так будет бардак.
Так кого он спрашивает, если над решением работает вся команда?
В специальный корпоративный чат, тегая всех (в Слаке — here, например) либо отдельно кого-угодно. Вся команда его читает, и ответственный за задачу, либо тот кто в курсе ситуации по задаче, отвечает.
Эм, вы правда думаете, что 121 делается только потому, что в организации запрещают сообщать сразу что кому-то что-то не нравится? А не потому, что частенько если тебе начинают жаловаться открыто — чинить проблему уже гораздо сложнее, а то и просто потерял человека.
Я старался выстроить процесс открытости и раннего фидбека. Если тебе жалуются, и уже поздно — человек хочет уйти, потеряли ресурсы, потеряли нервы, — стоит задуматься над компетенциями тех, кто поздно сказал. Значит, либо им все равно, либо безответственные, либо что угодно. У меня была возможность протестировать это, я много раз говорил «почему не сказал раньше, я же говорил», в итоге это работает — легко протестировать, назначаешь отдельный митинг, спрашиваешь фидбек, если тебе рассказывают что-то, что должны были рассказывать — напоминаешь о процессах, раннем фидбеке.
Как вы видите работу 50 таких команд над единым продуктом?
Это все моей компетенции сейчас, мой максимум — две команды, которые надо интегрировать между друг другом и наладить разработку, но не 50.
А с кем они сейчас общаются когда им нужно пообщаться по эпику делают который 90% разработчиков?
Мне надо понять что именно значит «пообщаться». Эпик, если мы на одной волне, это список задач, связанных одной тематикой (или частью проекта, в таком духе). У нас в компании, так как она продуктовая, и не только, задачи так не ставятся нашей команде, ставится типа — «Плохо работает нахождение похожих объявлений недвижимости», а мы уже сами за все отвечаем (подзадачи, их приоритеты). Бизнес не приходит и не спрашивает за что-то конкретное, могут спросить насколько новое решение эффективнее, либо нет ли блокеров, когда ориентировочно можно ждать.
Настроил процессы в команде, чтобы именно так как в статье описано все работало. Следил чтобы процессы не останавливались, люди теряют мотивацию, интерес, это в любом случае.
Т.е. разделения нет, но оно есть.
Это не совсем разделение, это полномочия, которые выходят за рамки команды. Например, уволить кого-то или обсудить зарплату — такое не решается на коллективном митинге.
И чисто ради интереса можно было бы попросить оценить трудозатраты на работы по такому же ТЗ некоторому количеству «классических» ПМ-ов. Ну, чтобы было с чем сравнивать эффективность, а то вдруг человечество не зря придумало разделение труда и специализацию.
Я работаю в продуктовой компании, в команде где нужно и исследовать самому, и работать с командой по машинному обучению, которые тоже в свою очередь исследуют и экспериментируют. Так что в моем случае, не получилось бы. Вот если бы продукт был другим, действительно пилить фичи, можно было бы попробовать. Я на своих ощущениях считаю, что самоорганизующиеся команда лучше, из опыта в в ряде компаний, с абсолютно разными процессами, ролями, менеджментом.
Не получилось, каждый разработчик начинал делать задачу и заканчивал, не передавал другим разработчикам (если заболел, надо уйти, отпуск, а задачу надо сделать на сейчас, то передавал, конечно).
И мы наоборот старались распределять задачи таким образом, чтобы не образовывалось экспертов в какой-то области.
Технически — не знаю, не работал с Helm на таком уровне. Но я находил операторы, у которых есть поддержка Helm. Например — github.com/apache/camel-k. В общем, это интересно, я поресерчу больше на этот счет, спасибо! :)
Технически — не знаю, не работал с Helm на таком уровне. Но я находил операторы, у которых есть поддержка Helm. Например — github.com/apache/camel-k. В общем, это интересно, я поресерчу больше на этот счет, спасибо! :)
Применение интерфейсов не зависит от языка программирования — например, для реализации паттерна стратегия.
С модификаторами доступа — чтобы не тратить время на то, чтобы пофиксить код, который использует приватный метод из твоего класса. Потому что он внезапно упал, когда ты изменил поведение метода.
Про «20 минут» и правда надо написать больше и яснее, про баланс.
Про сокращенные ссылки — только просто шаринг коллегам и вряд ли корпоративные сервисы не требуют авторизации на корпоративную почту.
Про мердж — правильно ставить блокировку на слияние в дефолтные ветки, поэтому без веб-интерфейса (после код-ревью и CI) не получится смерджить.
Про гработу коллеги — правда, надо уточнить.
У меня была фокус группа, не только с джуниоров, я опрашивал на очевидность и полезность материала — получил хорошую оценку. Решил выложить в открытый доступ.
Никогда не стоит отказываться написать что-то свое, прорекламировать это и развивать. Потому что это опыт, общение с коммьюнити, и попросту приятно. В любом случае естественный отбор покажет какие пакеты можно использовать и каким поделкам доверять.
Вам нужно было не пробегаться, а изучить домэйн немного глубже. О каких HTTP статус-кодах речь, если Телеграм нам ничего не возвращает? Мы ему кормим ссылку на наш веб-сайт, а он уже сам делает запрос на наш сервер (например, как сделано с виджетом на редирект).
Что касается нейминг также не соглашусь. Например, verify_telegram_authentication или create_callback_login_widget максимально приближенные к названиям в документации Телеграм, как и переменные, строящие строку виджета.
Претензии на идиоматичный код мне также не ясны. Код алгоритм аутентификации построен на инструкциях из документации. Остальной код (не больше 50 строк от силы) содержит банальные конструкции, похожие во всех языках.
Спасибо большое, что оставили минус с комментарием — навык, которого многим не хватает. Если бы вы разъяснили по недовольствам подробнее, чтобы я смог испрувнуть свои навыки, я был бы рад.
Часто, думаю, никто, но разработчик с определенными планами, исчерпав свое видение продукта, обязательно должен ознакомиться с альтернативными мнениями как в технической части, так и в «пяти метрах от кода».
В любом случае, мне интересно пополнить Хабрахабр своей статьей, потренироваться писать текст и выражать мысли.
Других решений по вопросу парсинга расписания на данный момент нет, и, в любом случае, если поменяется html-разметка сайта, касающаяся непосредственно самой таблицы с информацией — придется переписывать.
Учусь на третьем курсе по специальности «Программная инженерия». Спасибо! :)
В моем понимании, seniority так и выражается — если что-то не нравится, и ты сказал/предложил/решил, если что-то не работает, и ты сказал/предложил/решил, а не наоборот — забил до момента пока спросят.
Изначально, мы договариваемся о всех процессах. Если они приняты в команде, значит, либо всем нравятся, либо нравится большинству, либо так просто правильно в определенной ситуации. И если мы приняли правила, значит, мы считаем их эффективным. Если это некомфортно для человека, значит, это команда ему не подходит. Нормально, когда не подходит, и, конечно, в любой адекватной команде/компании пытаются сделать лучше, что-то поменять или перенастроить. Но не всегда же идти на уступки, так будет бардак.
В специальный корпоративный чат, тегая всех (в Слаке — here, например) либо отдельно кого-угодно. Вся команда его читает, и ответственный за задачу, либо тот кто в курсе ситуации по задаче, отвечает.
Я старался выстроить процесс открытости и раннего фидбека. Если тебе жалуются, и уже поздно — человек хочет уйти, потеряли ресурсы, потеряли нервы, — стоит задуматься над компетенциями тех, кто поздно сказал. Значит, либо им все равно, либо безответственные, либо что угодно. У меня была возможность протестировать это, я много раз говорил «почему не сказал раньше, я же говорил», в итоге это работает — легко протестировать, назначаешь отдельный митинг, спрашиваешь фидбек, если тебе рассказывают что-то, что должны были рассказывать — напоминаешь о процессах, раннем фидбеке.
Это все моей компетенции сейчас, мой максимум — две команды, которые надо интегрировать между друг другом и наладить разработку, но не 50.
Мне надо понять что именно значит «пообщаться». Эпик, если мы на одной волне, это список задач, связанных одной тематикой (или частью проекта, в таком духе). У нас в компании, так как она продуктовая, и не только, задачи так не ставятся нашей команде, ставится типа — «Плохо работает нахождение похожих объявлений недвижимости», а мы уже сами за все отвечаем (подзадачи, их приоритеты). Бизнес не приходит и не спрашивает за что-то конкретное, могут спросить насколько новое решение эффективнее, либо нет ли блокеров, когда ориентировочно можно ждать.
Настроил процессы в команде, чтобы именно так как в статье описано все работало. Следил чтобы процессы не останавливались, люди теряют мотивацию, интерес, это в любом случае.
Это не совсем разделение, это полномочия, которые выходят за рамки команды. Например, уволить кого-то или обсудить зарплату — такое не решается на коллективном митинге.
Я работаю в продуктовой компании, в команде где нужно и исследовать самому, и работать с командой по машинному обучению, которые тоже в свою очередь исследуют и экспериментируют. Так что в моем случае, не получилось бы. Вот если бы продукт был другим, действительно пилить фичи, можно было бы попробовать. Я на своих ощущениях считаю, что самоорганизующиеся команда лучше, из опыта в в ряде компаний, с абсолютно разными процессами, ролями, менеджментом.
И мы наоборот старались распределять задачи таким образом, чтобы не образовывалось экспертов в какой-то области.
С модификаторами доступа — чтобы не тратить время на то, чтобы пофиксить код, который использует приватный метод из твоего класса. Потому что он внезапно упал, когда ты изменил поведение метода.
У меня была фокус группа, не только с джуниоров, я опрашивал на очевидность и полезность материала — получил хорошую оценку. Решил выложить в открытый доступ.
В данных от Телеграма должна придти ссылка на аватар. Не приходит?
конечно, поддерживаются. Забыл добавить равно. :)
Спасибо, исправлено.
Никогда не стоит отказываться написать что-то свое, прорекламировать это и развивать. Потому что это опыт, общение с коммьюнити, и попросту приятно. В любом случае естественный отбор покажет какие пакеты можно использовать и каким поделкам доверять.
Вам нужно было не пробегаться, а изучить домэйн немного глубже. О каких HTTP статус-кодах речь, если Телеграм нам ничего не возвращает? Мы ему кормим ссылку на наш веб-сайт, а он уже сам делает запрос на наш сервер (например, как сделано с виджетом на редирект).
Что касается нейминг также не соглашусь. Например, verify_telegram_authentication или create_callback_login_widget максимально приближенные к названиям в документации Телеграм, как и переменные, строящие строку виджета.
Претензии на идиоматичный код мне также не ясны. Код алгоритм аутентификации построен на инструкциях из документации. Остальной код (не больше 50 строк от силы) содержит банальные конструкции, похожие во всех языках.
Спасибо большое, что оставили минус с комментарием — навык, которого многим не хватает. Если бы вы разъяснили по недовольствам подробнее, чтобы я смог испрувнуть свои навыки, я был бы рад.
В любом случае, мне интересно пополнить Хабрахабр своей статьей, потренироваться писать текст и выражать мысли.
Учусь на третьем курсе по специальности «Программная инженерия». Спасибо! :)