Уж если выносите логику в кастомный хук, то настоятельно рекомендую оборачивать колбэки в useCallback, так как при вызове, например, в useEffect, увижу красивую надпись в консоли "maximum update depth exceeded"
А какая модель используется? Base или GPT-4? При выборе последней качество подсказок становится выше. Да, согласен, что контекст как правило берется из открытого файла, но все равно, подсказывает в целом неплохо. А основным преимуществом является чат, с ним даже гуглить ничего не надо. Лично на своем опыте могу сказать, что с ним скорость написания именно нового функционала возрастает чуть ли не x2. Недостатки тоже есть, но они перекрываются преимуществами. А главное преимущество это бесплатность и доступность в России. Пользовались как-то платным copilot, так там качество подсказок заметно ниже, к тому же танцы с бубном при пополнении
Да этот товарищ как тим лид, похоже никакой, уже попадались его статьи. В одной жаловался что работники его не ценят, в другой, что во всем виноваты плохие подчинённые, а сам он белый и пушистый)
Хотелось бы немного раскрыть тему "Вынужденного менторства". Когда тебе Тим лид говорит: вот два Джуна, без опыта, помогай им, направляй их, в общем сделай из них хороших разработчиков. Ты без задней мысли и на энтузиазме берешь их в оборот, ведь в тебе увидели не просто разработчика, а того, кто готов передать свои знания подрастающему поколению, значит тебя ценят.
И здесь ты скорее всего допустишь главные свои ошибки:
1) Не обсудил с руководителем что тебе за это будет;
2) Слишком много на себя взял;
Что касается первого пункта, то здесь стоит "договориться на берегу", можно конечно и в процессе, но тут ты уже будешь не в таком выгодном положении. Плюшками могут быть:
Повышение твоего грейда при достижении твоими падаванами какого то результата;
Послабления по срокам задач, т.к. тебя часто отвлекают и на свои задачи тратишь меньше времени;
Премии и т.п.
По второму пункту: старайся не брать больше одного ученика, особенно если они без опыта. Т.к. даже на одного такого в начале будет уходить львиная доля твоего рабочего времени, а если таких два, то часто на дейликах придется говорить, что по своей задаче ничего вчера не сделал, т.к. занимался проблемами учеников. И тебе за это никто спасибо не скажет.
Что можно сделать по второму пункту, если нет варианта отказаться взять больше одного. Трекать время, затраченное на каждого из них, если это время не уменьшается, выясняешь причину и идёшь к тим лиду, думать что делать дальше. Причина может быть как в тебе, так и в твоём ученике, но в любом случае не молчи о проблемах. Развивай самостоятельность и внимательность в учениках. Да, большинство их проблем это банальная невнимательность. Не спеши по первому зову бежать к нему, скажи чтобы проверил все ещё раз и внимательнее.
Помогать ученикам, конечно, надо обязательно. Как минимум потому что когда то и ты такой был).
Также не надо скромничать, все должны видеть, каким важным делом ты занят, напоминай своему тим лиду, что ты не просто так свои задачи делаешь медленнее. Может случиться так, что тебе будут предьявлять за снижение производительности, а когда скажешь, что много времени тратишь не на свои задачи, тот, кто тебя назначил менторствовать, будет сильно удивлен "Что серьееееезна, а я не знал, ну ты это, меньше времени трать на них что ли, и больше на свои задачи".
Если следовать этим простым правилам, то твое менторство будет выгодно всем. Ты и свои софт скилы поднимешь, и в проекте будешь лучше разбираться, и ещё кое-какие плюшки получишь. Бояться этого не стоит, но и слепо браться тоже, обдумывай, договаривайся, не плошай)
Уж если выносите логику в кастомный хук, то настоятельно рекомендую оборачивать колбэки в useCallback, так как при вызове, например, в useEffect, увижу красивую надпись в консоли "maximum update depth exceeded"
А какая модель используется? Base или GPT-4? При выборе последней качество подсказок становится выше. Да, согласен, что контекст как правило берется из открытого файла, но все равно, подсказывает в целом неплохо. А основным преимуществом является чат, с ним даже гуглить ничего не надо. Лично на своем опыте могу сказать, что с ним скорость написания именно нового функционала возрастает чуть ли не x2. Недостатки тоже есть, но они перекрываются преимуществами. А главное преимущество это бесплатность и доступность в России. Пользовались как-то платным copilot, так там качество подсказок заметно ниже, к тому же танцы с бубном при пополнении
Да этот товарищ как тим лид, похоже никакой, уже попадались его статьи. В одной жаловался что работники его не ценят, в другой, что во всем виноваты плохие подчинённые, а сам он белый и пушистый)
Хотелось бы немного раскрыть тему "Вынужденного менторства". Когда тебе Тим лид говорит: вот два Джуна, без опыта, помогай им, направляй их, в общем сделай из них хороших разработчиков. Ты без задней мысли и на энтузиазме берешь их в оборот, ведь в тебе увидели не просто разработчика, а того, кто готов передать свои знания подрастающему поколению, значит тебя ценят.
И здесь ты скорее всего допустишь главные свои ошибки:
1) Не обсудил с руководителем что тебе за это будет;
2) Слишком много на себя взял;
Что касается первого пункта, то здесь стоит "договориться на берегу", можно конечно и в процессе, но тут ты уже будешь не в таком выгодном положении. Плюшками могут быть:
Повышение твоего грейда при достижении твоими падаванами какого то результата;
Послабления по срокам задач, т.к. тебя часто отвлекают и на свои задачи тратишь меньше времени;
Премии и т.п.
По второму пункту: старайся не брать больше одного ученика, особенно если они без опыта. Т.к. даже на одного такого в начале будет уходить львиная доля твоего рабочего времени, а если таких два, то часто на дейликах придется говорить, что по своей задаче ничего вчера не сделал, т.к. занимался проблемами учеников. И тебе за это никто спасибо не скажет.
Что можно сделать по второму пункту, если нет варианта отказаться взять больше одного. Трекать время, затраченное на каждого из них, если это время не уменьшается, выясняешь причину и идёшь к тим лиду, думать что делать дальше. Причина может быть как в тебе, так и в твоём ученике, но в любом случае не молчи о проблемах. Развивай самостоятельность и внимательность в учениках. Да, большинство их проблем это банальная невнимательность. Не спеши по первому зову бежать к нему, скажи чтобы проверил все ещё раз и внимательнее.
Помогать ученикам, конечно, надо обязательно. Как минимум потому что когда то и ты такой был).
Также не надо скромничать, все должны видеть, каким важным делом ты занят, напоминай своему тим лиду, что ты не просто так свои задачи делаешь медленнее. Может случиться так, что тебе будут предьявлять за снижение производительности, а когда скажешь, что много времени тратишь не на свои задачи, тот, кто тебя назначил менторствовать, будет сильно удивлен "Что серьееееезна, а я не знал, ну ты это, меньше времени трать на них что ли, и больше на свои задачи".
Если следовать этим простым правилам, то твое менторство будет выгодно всем. Ты и свои софт скилы поднимешь, и в проекте будешь лучше разбираться, и ещё кое-какие плюшки получишь. Бояться этого не стоит, но и слепо браться тоже, обдумывай, договаривайся, не плошай)
Зачем в примере с effecror делать такой финт ушами с добавлением состояния запроса в стор, когда у эффектов есть состояние pending?