В общем тут о поведении людей.

Привет всем. Бьюсь тут с одним новым разрабом (1.5 мес в команде). Он ни в какую не хочет принимать мою архитектуру почти в каждой задачке, хотя я грамотно и аргументированно ему объясняю почему именно так я хочу сделать (и разумеется я прав 😊 и с остальной командой никогда нет проблем). Меня учили не топать ногами и не давить авторитетом и субординацией. У разработчика позиция: "Сейчас для этой задачи и так сойдет, а когда будет сложнее, то переделаем". Моя позиция: "Я вижу что точно будет сложнее, поэтому давай сразу сделаем архитектурно красиво (кстати, вобще без увеличения трудозатрат), чтобы решение было модульным, прозрачным и развиваемым в лучших традициях SRP и ООП.". Бьемся буквально из-за вынесения трех строчек в отдельный класс с бизнес-логикой из view. Чувак принципиально, как будто боиться принимать подходы отличные от собственных. Это перевоспитывается? Может я слишком авторитарен в таких вопросах? Просто сложный сотрудник с которым тяжело и лучше расстаться?

Если это javascript то это норма 😁

а откуда такая стопроцентная уверенность в правоте своих решений?
разве не может быть, что архитектурных вариантов решения может быть несколько?

Задача техлида создавать техническое видение, обеспечивать стандарты качества через гайдлайны и стандарты,  и обучать сотрудников лучшими практиками

Если нет гайдлайнов или хотя бы бест-практикс и код стайла в любом виде - нужно его создать и потом тыкать в него

И возможно обучить сотрудника, рассказать подробно о чистом коде, паттернах, солид и так далее

Если он не готов учиться - то досвидания

ну опять же, разве оно не может быть оспорено?:)
вот всю жизнь работаю с этим кодом, он прекрасен насколько я могу представить и описать
а приходит новый человек и возможно может меня чему то новому научить

Может быть несколько. Есть же какие-то базовые принципы: разделение уровня фреймворка и бизнес-логики, например. (PS речь идет о django проекте).
Я же и пытаюсь обучить лучшим практикам, а разработчик говорит, что "сейчас и так сойдет, потому что широко и гибко мыслить в задаче из jira не просили. Также не просили делать с применением ООП и SRP". Он типа senior и на собесе красиво рассказывал о паттернах, солид и чистом коде. На практике цепляется за какие-то уловки фреймворка, которые при малейшем усложнении бизнес-логики окажутся 100% неприменимы. Вкупе с кучей других проблем (трудовая дисциплина, трудности общения) думаю выкидывать. Mighty прав.

А как его нанимали?

Оспорено может быть на уровне диалога и самого документа, но не на уровне кода. Но это только в самоорганизовывающих командах.

Изменения кодстайла принимаются коллективно. Собираешь всех заинтересованных, и когда изменения приняты, они не оспариваются до принятия следующих изменений)

> сейчас и так сойдет, потому что широко и гибко мыслить в задаче из jira не просили.

🙁

👍

возможно не донесены последующие итерации развития проекта и решение "не переусложнять" диктуется текущим видением. Могу понять разработчика - зачамтую такиетрешения лучше предварительно построенной модели которая еще не факт что подойдет или будет соблюдаться.

Ну на самом деле в большом проекте с очень запутаной кодовой базой и бизнес-логикой и костылями возможно требовать, чтобы новый человек умел "гибко мыслить" это несправедливо по отношению к кандидату.
Платформа Django/jQuery.
Кодстайл вчера начал писать после очередного акта общения с новым сотрудником.

я так понимаю, что речь не про код стайл (как ставить запятые и объекты называть), а про архитектурные вещи, которые могут быть неоднозначны

например, можно использовать какие то разные подходы к декомпозиции на классы или использовать\не использовать какие то сторонние либы

У меня есть такой разработчик. Я когда пришла в команду, он лучше всех знал проект, но делал "как побыстрее". Год-полтора кодревью, книжек, примеров из самого фреймворка и разных статей - и сейчас это техлид команды :)
Вопрос ресурсов и времени. И, наверно, удачи)

у меня больше проблем бывало с "давайте забубеним что-нибудь мегаважное и новое" в пятиминутной задачке на "закостылить".