Ну значит вы не опытный специалист, который не может решить мои проблемы, а значит я не буду работать с вами в дальнейшем. Такая вот логика будет уместной если исполнитель будет часто говорить, что он не знает, ведь мы спрашиваем и оплачиваем ожидая того, что он это знает.
Вспоминаю свое детство и понимаю, что показ "сложных" мультфильмов родителями мне очень даже помогал. Отец скачивал с торрента и давал смотреть 1 раз на русском, а после пересмотреть на английском (как можно ожидать, мне на английском не сильно заходило). Это все было в диапазоне от 3 до 9 лет.
Кажется как что-то ненужное и излишество, но по сути это можно внедрять в проекты, у которых большой бюджет, время и желание сделать все идеально чтобы после не разбираться и платить за тех. долг... Или нет?
Замена команды - очень плохая идея, ссылки не могу кинуть на статьи с такими примерами, но читал об этом много раз. Нужно менять подход команды к проекту и/или менять рук. команды или добавлять новых понижая ставки старых разрабов (на "короткое время").
В идеале, если календарь будет синхронизироваться с календарями других сотрудников (будет общий календарь), то будет ещё круче. Создаётся событие и у всех к этому событию свои соображения и комменты которые можно сделать как приватными, так и публичными.
Ого, контент подъехал.
Влажные фантазии многих джунов. Сразу скажу: для этого вы все равно должны уметь разрабатывать хотя бы на уровне middle+.
Ну значит вы не опытный специалист, который не может решить мои проблемы, а значит я не буду работать с вами в дальнейшем. Такая вот логика будет уместной если исполнитель будет часто говорить, что он не знает, ведь мы спрашиваем и оплачиваем ожидая того, что он это знает.
Много картинок, беру!) Ну не, думаю для малого бизнеса то, что нужно. Прочитаем.
Вспоминаю свое детство и понимаю, что показ "сложных" мультфильмов родителями мне очень даже помогал. Отец скачивал с торрента и давал смотреть 1 раз на русском, а после пересмотреть на английском (как можно ожидать, мне на английском не сильно заходило). Это все было в диапазоне от 3 до 9 лет.
Там 500ка в демо (https://demo.sleepingowladmin.ru/admin/some_models). Надеюсь дело не в коде самой панельке (ну я имею ввиду 500ку не подтянут к себе).
Всем пипец? Я так не думаю.
Кажется как что-то ненужное и излишество, но по сути это можно внедрять в проекты, у которых большой бюджет, время и желание сделать все идеально чтобы после не разбираться и платить за тех. долг... Или нет?
На новый уровень или же повторить то, что было еще 20 лет назад минимум?
Замена команды - очень плохая идея, ссылки не могу кинуть на статьи с такими примерами, но читал об этом много раз. Нужно менять подход команды к проекту и/или менять рук. команды или добавлять новых понижая ставки старых разрабов (на "короткое время").
Для этого нужно чтобы напарник был другом или знал меньше вас и не указывал на ошибки, а просто предлагал идеи и дальнейшие действия.
Другие сценарии очень стрессовые.
Спасибо за коммент, теперь понял.
Именно, к проклятому стеку где JS используется как бэк и фронт пришли не просто так.
За что минусы?
Нет, но считаю, что это обязательные параметры.
Интересная статья, хотелось бы почитать еще и про взаимодействие тимлида с менеджерами проекта (именно с теми, которые руководят разработкой в целом).
Чтобы стать тимлидом в первую очередь нужно работать на бизнес и иметь возраст >20 с опытом от 3 лет.
В идеале, если календарь будет синхронизироваться с календарями других сотрудников (будет общий календарь), то будет ещё круче. Создаётся событие и у всех к этому событию свои соображения и комменты которые можно сделать как приватными, так и публичными.
Как по мне ложь и дезинформация тоже информация, только свойство правдивость равна лжи.