Не разобрался, мой косяк. Я согласен с тем, что любая оценка – субъективное упражнение, но я пока не вижу мира без совсем без оных.
Когда из команды уходит человек, было бы неплохо понимать какого человека искать на его место. Как минимум какими качествами и свойствами его замене нужно обладать чтобы делать аналогичную работу на аналогичном уровне.
Как бы то ни было, мне нравится идея сведения двух и более субъективных оценок по одним и тем же критериям. Где результатом является не оценка общего уровня от 0 до 10, а скорее сравнение того как ты видишь себя и как тебя видит твой тим лид. Это очень помогает в управлении ожиданиями с обеих сторон.
Я взял все качества, которые лично мне кажутся важными, и каждое из них оценил по шкале плохо/хорошо/отлично.
До недавнего времени в компании, где я работаю не было лычек jun/mid/sr, хотя ребята есть разные. Каждый случай был особенным (продуктовая компания, всего 60 человек, из которых около 25 инженеры). Но потом появились косяки когда тот, кто хорошо показал себя на собесе и зп получал сеньорскую, не оправдал сеньорских ожиданий. И узнал об этом слишком поздно, потому что ожидания эти никогда не были оглашены, как и уровни разработчиков. Так что теперь решили все-таки как-то все формализировать, чтобы было понятно где ты сейчас и как получить рейз на следующий год. Долго не думая, взяли progression framework от Monzo и чуть подогнали под себя. После этого все заполнили self-assessment по всем пунктам выбирая между none/learning/profficien/expert и тимлиды заполнили аналогичные анкеты для инженеров в своих командах. Уже неплохо было увидеть разницу между тем как оцениваешь себя сам, и как видят тебя другие. Потом был интересный митинг по сведению этих двух таблиц между лидами и инженерами 1:1.
Мне собственно интересно что в свой список включил fillpackart. Если у кто-то еще может расшарить метрики с которыми встречались – буду весьма благодарен.
Тут различие в восприятии кодера и программиста. Кодером грустно, конечно, всю жизнь сидеть. Но ведь это можно изменить, если действительно есть желание. Разговоры про недостаток времени из-за семьи и т.п. — ну так значит это для вас более важно сейчас. Не получится взять всё, каждый расставляет приоритеты сам. Если эволюционирование из кодера в программисты для вас не слишком важно, так и расстраиваться по этому поводу тогда не стоит, а сосредоточиться на том, что имеет для вас наибольшую ценность.
В symfony RBAC тоже работает из коробки, и раньше он меня всегда устраивал. Но в этом проекте администратор должен иметь возможность отредактировать любые привилегии каждой роли, а это, на минуточку, 13*7 + 8 глобальных привилегий. Код уже начинает попахивать… Плюс то, что у пользователя может быть несколько из ~20 «настоящих» что-то значащих ролей, и у каждой из них есть ворох ролей, описывающих их привилегии. А если бы заказчик захотел бы добавить/удалить некоторые из них (пусть тот, у кого такого не было первый кинет в меня камень)? Я же застрелился бы!
Несмотря на примечание автора, тип должен быть nested. В примере ArFeRR, ему просто повезло, что у разных свойств были неповторимые значения. У меня были несколько свойств типа да/нет/пусто. Это была катастрофа. По одному «нет» выбирались все объекты, у которых «нет» было хоть в каком-то свойстве. подробное объяснение на примере.
Восхитительная вещь, которую трагически нечем заменить для старичков ie, и потому не будет использоваться в коммерческих проектах еще nадцать лет. Срочно нужна революция.
Для меня legacy — это что-то вроде археологических раскопок. Можно долго скучать, а потом найти что-то интересное. И вот такие неожиданности и подогревают интерес к legacy коду.
Результат тот же, а промежуточных действий — меньше (установить yuicompressor, и добавить пару строк в конфиг). Наверное, я что-то упускаю, не могли бы вы привести какие-нибудь конкретные аргументы в пользу вашего предложения?
В процессе эволюции у человека не просто так появилось чувство прекрасного.
Красивая теория, а мне кажется, что эволюция выработала чувство неудовлетворенности текущим положением. И потому если не унять своего перфекциониста — никогда не сможешь чувствовать себя хорошо здесь и сейчас, т.к. все время придется бежать к лучшему.
Сразу прошу прощения, если мой ответ показался категоричным, я старался этого избежать, как видно неудачно.
Здесь разговор идет о найме джуниора — и внезапности, перечисленные в оригинальной статье это
Внезапно у джуниора может начаться сессия, сдача курсовой, он может найти работу автослесарем или разносчиком пиццы, ведь “там платят уже сейчас”, а “тут вы эксплуатируете меня бесплатно”.
Если даже такие вещи не планировать — то вы действительно просто полагаетесь на удачу.
Падение сервера без возможностей восстановления — тоже косяк планирования, бэкап — наше все. Войны, землетрясения, атака из космоса — это форс-мажор, с этим ничего не поделаешь.
Если вы закончили технический вуз, то как вас могут не смущать субъективные термины «много», «мало» в статье претендующей на техничность? Это и отличает научные статьи от псевдонаучных: научные пытаются дать однозначные критерии, а псевдонаучные — подходящие всем кто их услышит.
Снимите руки с клавиатуры и бросьте взгляд в реальный мир. Некоторые вещи проще указывать в субъективных мерах, и в этом нет ничего криминального. Если вы разговариваете с собеседником на одном языке и понимаете его, то такие вещи не должны вас смущать. Если вы не уверены что ваши представления сходятся — всегда можно уточнить.
Это, когда, за отсутствие на работе из-за какой-нибудь неурядицы, сотрудник просидит следующие несколько дней допоздна, а еще купит печеньки всем коллегам, которые из-за него пострадали.
Это успокоит только вашу совесть, но никак не поможет вашему работодателю.
А отсутствие внезапностей — это удача или умение успешно предсказывать будущее.
1. подломали 5 лет назад, и сейчас уже не найти правды;
2. чтобы что-нибудь сделать было бы неплохо выкинуть всю ту попахивающую кучу неподдающегося рефакторингу исходного кода, переехать на сервер с современными версиями apache/php и доступом, отличным от FTP. Но заказчику такое решение дастся очень тяжело, так что только хардкор. А по поводу конкретно этой проблемы — решением является выпиливание злокачественного файла, с попутным общением с техподдержкой sape.ru в надежде выйти на того, кто это соорудил.
По поводу банальности — хорошо, если для вас они являются таковыми. На разрабатываемых мною проектах такого пока не было. Уверен, что найдется отличное от нуля число разработчиков, которым такое никогда и не встретится.
Если вы уже сталкивались с чем-то подобным и исходя из своего опыта сможете предложить способы нахождения/закрытия дыр — не стесняйтесь оставлять советы.
При первом чтении детали опускаются. Сначала заметил preg_replace(), и глаза сразу начинают искать что-то похожее на регулярное выражение. Вот так, в спешке, особо не разбираясь в порядке параметров, принял странного вида второй параметр за регулярное выражение. И вот оно-то меня и впечатлило. Видимо вы чаще меня пользуетесь регулярками, потому и в заблуждение вас ввести сложнее.
Когда из команды уходит человек, было бы неплохо понимать какого человека искать на его место. Как минимум какими качествами и свойствами его замене нужно обладать чтобы делать аналогичную работу на аналогичном уровне.
Как бы то ни было, мне нравится идея сведения двух и более субъективных оценок по одним и тем же критериям. Где результатом является не оценка общего уровня от 0 до 10, а скорее сравнение того как ты видишь себя и как тебя видит твой тим лид. Это очень помогает в управлении ожиданиями с обеих сторон.
До недавнего времени в компании, где я работаю не было лычек jun/mid/sr, хотя ребята есть разные. Каждый случай был особенным (продуктовая компания, всего 60 человек, из которых около 25 инженеры). Но потом появились косяки когда тот, кто хорошо показал себя на собесе и зп получал сеньорскую, не оправдал сеньорских ожиданий. И узнал об этом слишком поздно, потому что ожидания эти никогда не были оглашены, как и уровни разработчиков. Так что теперь решили все-таки как-то все формализировать, чтобы было понятно где ты сейчас и как получить рейз на следующий год. Долго не думая, взяли progression framework от Monzo и чуть подогнали под себя. После этого все заполнили self-assessment по всем пунктам выбирая между none/learning/profficien/expert и тимлиды заполнили аналогичные анкеты для инженеров в своих командах. Уже неплохо было увидеть разницу между тем как оцениваешь себя сам, и как видят тебя другие. Потом был интересный митинг по сведению этих двух таблиц между лидами и инженерами 1:1.
Мне собственно интересно что в свой список включил fillpackart. Если у кто-то еще может расшарить метрики с которыми встречались – буду весьма благодарен.
В symfony RBAC тоже работает из коробки, и раньше он меня всегда устраивал. Но в этом проекте администратор должен иметь возможность отредактировать любые привилегии каждой роли, а это, на минуточку, 13*7 + 8 глобальных привилегий. Код уже начинает попахивать… Плюс то, что у пользователя может быть несколько из ~20 «настоящих» что-то значащих ролей, и у каждой из них есть ворох ролей, описывающих их привилегии. А если бы заказчик захотел бы добавить/удалить некоторые из них (пусть тот, у кого такого не было первый кинет в меня камень)? Я же застрелился бы!
подробное объяснение на примере.
assetic: debug: %kernel.debug% use_controller: false bundles: [FMElfinderBundle,CMSBundle,FOSCommentBundle] filters: compass: bin: /usr/local/bin/compass apply_to: "\.s[ac]ss$" sass: bin: /usr/local/bin/sass scss: ~ cssrewrite: ~ uglifycss: ~ uglifyjs2: ~ yui_css: jar: %kernel.root_dir%/../vendor/packagist/yuicompressor-bin/bin/yuicompressor.jar apply_to: "\.css$" yui_js: jar: %kernel.root_dir%/../vendor/packagist/yuicompressor-bin/bin/yuicompressor.jar apply_to: "\.js$"{% stylesheets "@CMSBundle/Resources/assets/css/*" "@BraincraftedBootstrapBundle/Resources/sass/form.scss" "css/compiled/*" %} <link rel="stylesheet" href="{{ asset_url }}" /> {% endstylesheets %} {% javascripts '@CMSBundle/Resources/public/js/*' '@CMSBundle/Resources/public/original_js/*' %} <script type="text/javascript" src="{{ asset_url }}"></script> {% endjavascripts %}Результат тот же, а промежуточных действий — меньше (установить yuicompressor, и добавить пару строк в конфиг). Наверное, я что-то упускаю, не могли бы вы привести какие-нибудь конкретные аргументы в пользу вашего предложения?
Лучшее — враг хорошего (с) М. Джиованни
Здесь разговор идет о найме джуниора — и внезапности, перечисленные в оригинальной статье это Если даже такие вещи не планировать — то вы действительно просто полагаетесь на удачу.
Падение сервера без возможностей восстановления — тоже косяк планирования, бэкап — наше все. Войны, землетрясения, атака из космоса — это форс-мажор, с этим ничего не поделаешь.
Это успокоит только вашу совесть, но никак не поможет вашему работодателю.
Я это называю умением планировать.
http://космический-карандаш.рф/
2. чтобы что-нибудь сделать было бы неплохо выкинуть всю ту попахивающую кучу неподдающегося рефакторингу исходного кода, переехать на сервер с современными версиями apache/php и доступом, отличным от FTP. Но заказчику такое решение дастся очень тяжело, так что только хардкор. А по поводу конкретно этой проблемы — решением является выпиливание злокачественного файла, с попутным общением с техподдержкой sape.ru в надежде выйти на того, кто это соорудил.
По поводу банальности — хорошо, если для вас они являются таковыми. На разрабатываемых мною проектах такого пока не было. Уверен, что найдется отличное от нуля число разработчиков, которым такое никогда и не встретится.
Если вы уже сталкивались с чем-то подобным и исходя из своего опыта сможете предложить способы нахождения/закрытия
preg_replace(), и глаза сразу начинают искать что-то похожее на регулярное выражение. Вот так, в спешке, особо не разбираясь в порядке параметров, принял странного вида второй параметр за регулярное выражение. И вот оно-то меня и впечатлило. Видимо вы чаще меня пользуетесь регулярками, потому и в заблуждение вас ввести сложнее.