A
перевести быстро разработчика можно только на unemployment
кстати, вот тонкий намек на это может включить уши
Size: a a a
2021 February 03
IV
научится бы еще делать такие тонкие намеки
SS
если человек хочет остаться в компании, иногда помогает объяснить ему, как здесь дела делаются, а как нет. и дать срок на усвоение. просто иногда у молодого сотрудника может быть в голове не та картина мира, и он не понимает добрых намерений. но после адаптационного периода оказывается ценным кадром
+1
АА
Суть проблемы: Парень достаточно толковый но ооооочень завышенной самооценкой, в его вселенной он бог и весь код который не его это конечно же говно (он пришел в проект которому 3-4 месяца), я реально эту фразу слышу каждый! наш созвон в разных вариациях.
Очень боится говорить "не знаю"" от чего иногда несет полную чушь и теряет очки доверия с дикой скоростью, на реальных задачах чуть послежнее простой вертски - буксует даже со своим кодом.
При этом попытки научить подсказать и тд воспринимаются в штыки как проявление недоверия таланту.
Вот мы с моим партнером обсудили что можно сделать, мне кажется без опусканию на землю и старта сначала но в правильных позициях хорошего не будет. Партнер считает что это не лечится быстро, и вообще это больше работа психотерапевта чем наша и предлагает не обращать внимания не обсуждать это даже и ждать либо пройдет само постепенно либо расстанемся (второе естественно вероятнее).
Очень боится говорить "не знаю"" от чего иногда несет полную чушь и теряет очки доверия с дикой скоростью, на реальных задачах чуть послежнее простой вертски - буксует даже со своим кодом.
При этом попытки научить подсказать и тд воспринимаются в штыки как проявление недоверия таланту.
Вот мы с моим партнером обсудили что можно сделать, мне кажется без опусканию на землю и старта сначала но в правильных позициях хорошего не будет. Партнер считает что это не лечится быстро, и вообще это больше работа психотерапевта чем наша и предлагает не обращать внимания не обсуждать это даже и ждать либо пройдет само постепенно либо расстанемся (второе естественно вероятнее).
А айосник пришел как джун? Откуда интересно у него концепт «фатального недостатка»
KS
научится бы еще делать такие тонкие намеки
А зачем намекать? Можно просто разобрать на 1+1 встрече по фактам, что у него есть потенциал, но его критика кода демотивирует других людей, что для любого кода можно придумать миллион метрик по которым он будет говном, и что с точки зрения каких то бизнес метрик его код все таки хуже чем код его коллег. Понятно, что такие разговоры тоже надо уметь вести, но мне кажется этому проще научиться чем намёкам, тем более намёки могут быть восприняты как пассивно агрессивное поведение, особенно если у человека завышенная самооценка. В конечном счёте если его взгляды на разработку отличаются от ваших и он не готов их менять вы не сработаетесь. И чем раньше вы разойдетесь тем лучше будет для обоих сторон. Я всегда считаю, что прямой и честный разговор самый лучший способ решения конфликта.
IV
все так
E
Суть проблемы: Парень достаточно толковый но ооооочень завышенной самооценкой, в его вселенной он бог и весь код который не его это конечно же говно (он пришел в проект которому 3-4 месяца), я реально эту фразу слышу каждый! наш созвон в разных вариациях.
Очень боится говорить "не знаю"" от чего иногда несет полную чушь и теряет очки доверия с дикой скоростью, на реальных задачах чуть послежнее простой вертски - буксует даже со своим кодом.
При этом попытки научить подсказать и тд воспринимаются в штыки как проявление недоверия таланту.
Вот мы с моим партнером обсудили что можно сделать, мне кажется без опусканию на землю и старта сначала но в правильных позициях хорошего не будет. Партнер считает что это не лечится быстро, и вообще это больше работа психотерапевта чем наша и предлагает не обращать внимания не обсуждать это даже и ждать либо пройдет само постепенно либо расстанемся (второе естественно вероятнее).
Очень боится говорить "не знаю"" от чего иногда несет полную чушь и теряет очки доверия с дикой скоростью, на реальных задачах чуть послежнее простой вертски - буксует даже со своим кодом.
При этом попытки научить подсказать и тд воспринимаются в штыки как проявление недоверия таланту.
Вот мы с моим партнером обсудили что можно сделать, мне кажется без опусканию на землю и старта сначала но в правильных позициях хорошего не будет. Партнер считает что это не лечится быстро, и вообще это больше работа психотерапевта чем наша и предлагает не обращать внимания не обсуждать это даже и ждать либо пройдет само постепенно либо расстанемся (второе естественно вероятнее).
Его случайно не Максимом зовут?
IV
Его случайно не Максимом зовут?
ну камон 😉
E
вот интересно, люди, которые пишут feat вместо feature.. что они делают с уймой освободившегося времени?
- это просто конвения
- на самом деле это удобно, потому что настраивают commit lint, который не дает писать больше 72 символов. Так что иногда очень даже полезно иметь в распоряжении больше на 3 символа)
- на самом деле это удобно, потому что настраивают commit lint, который не дает писать больше 72 символов. Так что иногда очень даже полезно иметь в распоряжении больше на 3 символа)
E
ну камон 😉
Ну шутка же)
D
А длинна сообщения коммита как-то коррелирует с длинной строки кода?
K
то есть 50, чтобы быть как можно ближе к медианному значению длины из ядра линукса, а 72 - чтобы быть по центру 80-колоночного терминала
50 - чтобы следовать рекомендациям, упомянутым в документации к самому git.
$ man git commit | grep 50 -A 1 -B 1
DISCUSSION
Though not required, it’s a good idea to begin the commit message with a single short (less than 50 character) line summarizing the change, followed by a blank line and then a more thorough description. The text up to the first blank line in a commit message is treated as the commit title, and that title is used throughout Git. For example, git-format-patch(1) turns a commit int
Исходя из этой рекомендации сделаны куча тулзов. Ну хоть взять тот же гитхаб, который обрезает длинные первые строки даже на очень широких экранах
$ man git commit | grep 50 -A 1 -B 1
DISCUSSION
Though not required, it’s a good idea to begin the commit message with a single short (less than 50 character) line summarizing the change, followed by a blank line and then a more thorough description. The text up to the first blank line in a commit message is treated as the commit title, and that title is used throughout Git. For example, git-format-patch(1) turns a commit int
Исходя из этой рекомендации сделаны куча тулзов. Ну хоть взять тот же гитхаб, который обрезает длинные первые строки даже на очень широких экранах
D
А длинна сообщения коммита как-то коррелирует с длинной строки кода?
Потому что от 80 уже давно даже в ядре Linux отказались.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=bdc48fa11e46f867ea4d75fa59ee87a7f48be144
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=bdc48fa11e46f867ea4d75fa59ee87a7f48be144
D
50 - чтобы следовать рекомендациям, упомянутым в документации к самому git.
$ man git commit | grep 50 -A 1 -B 1
DISCUSSION
Though not required, it’s a good idea to begin the commit message with a single short (less than 50 character) line summarizing the change, followed by a blank line and then a more thorough description. The text up to the first blank line in a commit message is treated as the commit title, and that title is used throughout Git. For example, git-format-patch(1) turns a commit int
Исходя из этой рекомендации сделаны куча тулзов. Ну хоть взять тот же гитхаб, который обрезает длинные первые строки даже на очень широких экранах
$ man git commit | grep 50 -A 1 -B 1
DISCUSSION
Though not required, it’s a good idea to begin the commit message with a single short (less than 50 character) line summarizing the change, followed by a blank line and then a more thorough description. The text up to the first blank line in a commit message is treated as the commit title, and that title is used throughout Git. For example, git-format-patch(1) turns a commit int
Исходя из этой рекомендации сделаны куча тулзов. Ну хоть взять тот же гитхаб, который обрезает длинные первые строки даже на очень широких экранах
Github режет не 50 символов.
K
Github режет не 50 символов.
65 по-моему, но это по той причине, что 50 - это не жёсткий лимит, а рекомендация
D
65 по-моему, но это по той причине, что 50 - это не жёсткий лимит, а рекомендация
72
AR
