ты пришел устраиваться и видишь, что здесь в целом всем все равно
то зачем принимать оффер?
потому что у тебя три оффера на примерно те же деньги и везде примерно одно и то же. редко когда бывает выстреливает что-то интересное, но уже через пол года даже самый интересный проект преваращается в рутину. не говоря уже о том, что как правило больше всего денег предлагают конторы именитые и софт там обычно хуже всего.
В последний раз потому, что деньги заканчивались, нужна была любая работа :)
имхо любой «чистый» код есть непосредственно та самая рутина в абсолюте между написать фичу и правильно написать фичу пропасть из труда вообще работа в целом состоит из рутинных действий, даже если пишешь что-то интересное если так волнует правильность процессов то и их и надо продвигать самому не думаю, что вокруг кодеры начнут говорить «ой нет, знаешь я люблю писать как выйдет и потом отлаживать это неделями» прийти на что-то готовое, где все налажено это больше из области повезло люди чаще всего делают плохо не потому что хотят так делать, а потому что никто не хочет или не может этим заниматься и за это отвечать чистый код надо уметь продавать бизнесу и следить, чтоб это не превратилось в архитектурный нацизм и код ради кода
давай сразу переведем в практическую плоскость. сколько раз в жизни ты пришел в проект, которому хотя бы уже год и переделал людей и процессы так как ты описываешь?
это по сути моя основная работа и меня за не увольняют, а нанимают
ну так можешь про конкретные кейсы рассказать?
что именно? как исправить процессы и тебя за это не уволили?
там же выше задан вопрос. про процессы и, что меня интересует гораздо больше, про людей. конкретно твой экспириенс, я так понимаю у тебя он большой.
у меня было 3 таких кейса с разной степенью запущенности и 1 стартап где я заложил изначально всё как вижу насчет людей, среди прогеров я не встречал каких-то особых проблем главный критерий для них твои хардскиллы, ты не можешь просто прийти и говорить ребят вы пишите гавно и при этом делать свою работу плохо, недостаточно знать идеальный кейс когда ты оверскилл относительно команды с менеджментом и продюссерами сложнее, но в целом надо въехать в их категорию ценностей и полезностей и говорить на их языке исправлять надо постепенно, поднимать все кейсы проебов из-за плохого качества кода на обсуждение при этом иметь поддержку среди кодеров, чтоб это в глазах менеджмента не выглядело как очередной «хранитель чистоты» самое главное забыть фразу «давайте все перепишем» после этого умирают все проекты нужно вводить плавные меры условно нет общего кодостайла, то ввести его это дешево, добиться на уровне инструментария его поддержки дальше нужно иметь гайдлайн и понимание проекта, чтоб можно было выделить участки в которых можно начать писать правильно сегодня, обернув всё неудачное во что-то человеческое тут уже нужны процессы ревью кода и понимание, что тебе придется читать кучу чужого кода далеко не всегда хорошего и умение донести до человека как лучше стоит сделать, при этом не обосрав его и унизив если гореть этим и делать четко, то через какое-то время хороший код будет доминировать над плохим, да и сама команда втянется да это куча пота и нервов на старте читать, дебажить и рефакторить гавно неприятно тяжелее еще не утонуть в этом, выбивать и не проебывать сроки потому что если проебаться, то доверия сверху тебе резко начнет ухудшаться идеально если получится продемонстрировать быстро результаты, что вот на новом участке мы начали быстрее деливерить фичи, чем раньше, потому что делать начали иначе с кодовой базой легче работать и все остальное другой вопрос надо ли оно тебе это все?
ну это ты меня догмами забросал. я в общем-то согласен с много чем из того, что ты перечислил. только я прошу не выводы, а кратко описать свой реальный опыт. "я пришел, было так-то, я сразу понял что нужно улучшить такой-то процесс, через 3 месяца было сделано то-то и начало давать такой-то результат, в итоге это привело к тому что уже через год 45% было доведено до такого-то уровня качества".
Обсуждают сегодня