antonv писал(а): ↑12 июл 2020, 11:07pakkemodra, почему вы так уверены, что в крупных компаниях (вы ведь хотите офис в топовом бизнес-центре) каждый рядовой программист озабочен вопросами архитектуры и принимает важные для продукта решения, а не делает то, что ему говорит его лид?
Вы так рассуждаете, будто претендуете сразу на должность CTO в Кремниевой долине:)
Нет, офис в крупном БЦ я не хочу. Я просто упомянул, чем обычно руководствуются люди, принимая решение о выборе места работы.
Я бы предпочел комфортную удаленку, но там, увы, очень страдает карьера. А к 35-40 уже очень хорошо бы продвинуться дальше, чем рядовой программист или тимлид. Не из-за скуки к работе, вовсе нет. Просто устроиться будет все сложнее и сложнее, а молодых нанимать выгоднее, чем сильно опытных (тут и понятие сверхквалификации, и уровня задач в большинстве компаний, и предрассудков по поводу опыту). Хотя, возможно, все-таки надоест программировать лет через 15-20, тоже может быть. А терять работу в IT не хочется
Тем более, работа иного плана в том же IT не кажется скучной.
Про архитектуру. С моей точки зрения, это ключевой момент и для лида, и для обычного программера. И, разумеется, для крупного проекта - ведь даже прекрасные алгоритмы, доступ к которым затруднен для рядя пользователей из-за того, что бэкендеры добились немасштабируемости проекта каким-либо образом.
Не обязательно принимать важные для продукта решения. Важно понимать, как писать легкоподдерживаемый, простой в отладке, надежный и расширяемый код. Ведь архитектура важна на всех уровнях, иначе получится слабоструктурированный спагетти-код с высокой связанностью (Coupling) и низкой связностью (Cohesion) (см. принципы SOLID). На верхних решение принимает лид или вся команда, а на нижних очень часто где косячат. Работая на удаленке, видел очень много примеров хорошего кода (нет, правда хорошего), но с неграмотной планировкой, из-за чего тратился большой объем времени, можно сказать, впустую на переделку всех этих "особенностей".
Почему важно знать архитектуру на всех уровнях даже тем, кто не принимает решений? Продукт к моменту прихода новичка-программиста представляет собой сложную структуру. И крайне важно понимать, как она функционирует, как она задумана расширяться, как с ней правильно работать. То есть, как ничего не сломать и интегрировать все правильно. Или наоборот - что-то устранить из нее, что может быть еще более сложной задачей. Вносить правки все же проще.
Отсылка к Кремниевой долине - замечу, что в РФ множество IT-проектов, где это возможно и следует применить. Если, конечно, дело не ограничивается десятком скриптов на сотню строк.
Перестал удивляться, что эта штука сегфолтится раз в день.