DS
Установка вида "мне сказали, я сделал"
Size: a a a
2019 April 29
АК
Коллеги, привет! У нас небольшие изменения и завтрашний Peer Lab пройдет в офисе компании Альфа Банк (Комсомольская). Точный адрес вышлю чуть позже всем, кто зарегистрировался.
2019 May 02
N
может сработать, кстати.
Всего полгода заведения задач со сноской "Обновить документацию" и дело пошло даже без сноски.
Всего полгода заведения задач со сноской "Обновить документацию" и дело пошло даже без сноски.
2019 May 04
V
Petr Valing
Привет всем. Бьюсь тут с одним новым разрабом (1.5 мес в команде). Он ни в какую не хочет принимать мою архитектуру почти в каждой задачке, хотя я грамотно и аргументированно ему объясняю почему именно так я хочу сделать (и разумеется я прав 😊 и с остальной командой никогда нет проблем). Меня учили не топать ногами и не давить авторитетом и субординацией. У разработчика позиция: "Сейчас для этой задачи и так сойдет, а когда будет сложнее, то переделаем". Моя позиция: "Я вижу что точно будет сложнее, поэтому давай сразу сделаем архитектурно красиво (кстати, вобще без увеличения трудозатрат), чтобы решение было модульным, прозрачным и развиваемым в лучших традициях SRP и ООП.". Бьемся буквально из-за вынесения трех строчек в отдельный класс с бизнес-логикой из view. Чувак принципиально, как будто боиться принимать подходы отличные от собственных. Это перевоспитывается? Может я слишком авторитарен в таких вопросах? Просто сложный сотрудник с которым тяжело и лучше расстаться?
Чем в итоге закончилась войнушка с упёртым?
PV
Vyacheslav
Чем в итоге закончилась войнушка с упёртым?
Он проболел весь период до праздников, так что разговор ещё впереди ). Буду держать в курсе
V
Petr Valing
Он проболел весь период до праздников, так что разговор ещё впереди ). Буду держать в курсе
Я с подобным сталкивался. Парень просто показывает, что он главный, имхо. У него есть потребность в том, чтобы самому принимать решения. Возможно, в будущем, он придёт к архитектуре, но есть два но. 1. Он может не прийти. 2. Твоя архитектура может являться слишком замороченной. 3. У тебя есть потребность в жёстком управлении - тебе самому комфортно в этой модели существовать (да, это нормально, но это не показатель качества). Тут я бы советовал критичнее к себе относиться. И если этот человек слишком тебе не подходит, то попрощаться с ним. Или же поговорить, на основании чего ты принимаешь те или иные архитектурнын решения. Также проводи собрания команды с общением про архитектуру и непосредственно код, чтобы вопросов не возникало.
V
Такими людьми можно пользоваться в контексте критики кода и трезвого взгляда
EB
Petr Valing
Он проболел весь период до праздников, так что разговор ещё впереди ). Буду держать в курсе
Мне все-таки интересно, как этот человек оказался в команде? Его навязали?
V
Мне все-таки интересно, как этот человек оказался в команде? Его навязали?
Думаю, что он по формальным критериям подошёл. От этого полностью обезопасить себя перил. Добавлю, что это человек с собственной Томской зрения. Зачастую такие люди имеют потребность в управлении ( но не всегда). Думаю, что нужно было по этому критерию фильтровать: есть ли возможность/желание управлять.
EB
Vyacheslav
Думаю, что он по формальным критериям подошёл. От этого полностью обезопасить себя перил. Добавлю, что это человек с собственной Томской зрения. Зачастую такие люди имеют потребность в управлении ( но не всегда). Думаю, что нужно было по этому критерию фильтровать: есть ли возможность/желание управлять.
А насколько у разработчиков при приеме на работу на софт скиллы смотрят? Или «задачи решает и ладно»?
IK
А насколько у разработчиков при приеме на работу на софт скиллы смотрят? Или «задачи решает и ладно»?
Мы стараемся смотреть начиная с тех. собеса. Смотрим как человек рассуждает, воспринимает критику, предлагает решения, оценивает задачи, аргументирует принятые решения и т.д.
V
А насколько у разработчиков при приеме на работу на софт скиллы смотрят? Или «задачи решает и ладно»?
Сейчас опять же имхо напишу. На хард скилы нужно смотреть только в контексте: врёт в резюме или не врёт. Главное нужно смотреть на 1. Мозги 2. Софт скилы.
EB
Vyacheslav
Сейчас опять же имхо напишу. На хард скилы нужно смотреть только в контексте: врёт в резюме или не врёт. Главное нужно смотреть на 1. Мозги 2. Софт скилы.
Тут у всех имхо) мне кажется нет золотого стандарта. Я просто в начале работы в IT замечала, что многим на софт скиллы кандидата плевать. Тенденция по-моему меняется
IB
На тех скиллы плевать? А как же множество историй про то как на собеседованиях кучу сложных задач приходится решать и вообще к этому надо готовиться, причем не пару дней.
С
Вместо тех скилов https://play.elevatorsaga.com/ 😁
V
На тех скиллы плевать? А как же множество историй про то как на собеседованиях кучу сложных задач приходится решать и вообще к этому надо готовиться, причем не пару дней.
Это скорее про мозги, а не техскиллы. Инженерные задачи более релевантны. И даже, чёрт возьми, вопросы про круглые люки более релевантны, нежели вопросы про API
IB
Ну вот кажется гугл отказался от задач про люки уже
IB
Несколько лет назад
IB
Разговор на технические темы: проблемы, решения и т.д сильно релевантнее люков
V
Ну вот кажется гугл отказался от задач про люки уже
Ну это я утрирую, конечно. Но спрашивать, что делает тот или иной метод — вообще нерелевантно