Comments 17
в отношении веб-систем могут привести к тому, что приложение потеряет важные финансовые данные или, например, заставит компанию потратить сотни тысяч долларов дополнительных ресурсов на реализацию неоправданно сложной системы.
Очень размытое предложение.
Например. Неоправданно сложной веб-системой я могу назвать практически любую веб систему, которая использует фреймворк в связке с бандлером любым. (Языки кроме js я даже не рассматриваю. Фактически единственный приспособленный язык для веба это js)
Сейчас я не знаю ни одной проблемы, которую нельзя было бы решить модулями и веб компонентами. И есть только один аргумент в пользу фреймворков это документация. Но и это очень сомнительно, потому что в документации очень часто не хватает информации по системе, которая требуется, а ответов на вопросы на stack owerflow не найти. И если такое происходит, единственный вариант лезть в чужой код и ещё с ним разбираться.
Тогда получается по вашей фразе, огромное колличество проектов и практически все коммерческие проекты это неоправданно сложные системы.
Я так понимаю, текст полностью написан АИ
Хорошо, я готов быть джуном-сантехником, если вам угодно, если я продолжу дальше делать свою работу, за свою ЗП.
Кстати, научитесь уже, пожалуйста, называть вещи корректными именами -- если говорите о понимании причины и следствия, так и говорите. Нет никакой проблемы курицы и яйца. Всё, кто хоть немного знают биологию и знают о мутациях, точно знают ответ - первым было яйцо из которого и появилась первая курица, которая является потомком некого пра-существа. Курица это результат мутаций переданных ранее генов.
А про-существо из яйца вылуплялось?
del
Скорее да. Ну, вряд-ли оно было живородящим, а потом, внезапно, начало откладывать яйца. Но курицей оно не являлось. Но было очень близко к курице.
Собственно, когда говорят, что у человека и у обезьян общий предок, говорят примерно об этом же.
Изначально из икринки. Но потом существо мутировало, вылезло на сушу и икринки обзавелись защитной пленкой и стали яйцами. На этом пути побывали миллионы существ и тысячи мутаций.
Кстати, ChatGPT довольно верно сказал что нужно при соискании позиции SDE в AWS, но это относится ко второй части, а первая - technical assesment - там только умение решать задачи, как правило несложные, если имеются познания в DP.
Настоящая причина, по которой вы не станете сеньором
Потому что пирамида иерархии подразумевает на одного сеньера сотню батраков. Если бизнесу не нужны твои знания, если тебе не дают заданий на "сложные проекты, получая при этом правильную обратную связь", то и получить их неоткуда. Можно конечно научиться "плавать на полу" :)
В таких условиях рынок должен подталкивать программистов, имеющих зачатки синьора, но не имеющих подходящей вакансии, становиться предпринимателями. Что часто и происходит. Проблема только в том, что эмоция возникающая походу: «это чего, я опять джун, только теперь джун-предприниматель!?»
Рынок тоже имеет емкость экосистемы. Иерархия -- это не только про угнетение на самом деле. На сотню элементов электронной рассыпухи приходится одна микросхема. Это естественно. Точно так же, в бизнесе на сотню элементарных бизнесов, где дальше джуна не вырастешь, приходится один, где требуется глубокая интеграция. Единственный выход, думать глубже и искать бизнес-идею, которая повысит уровень требований и даст при этом конкурентное преимущество. Пример который я обычно привожу для учеников -- Додо-пицца. Они из сервиса доставки сделали высокоинтеллектуальный бизнес. НО найти такую идею тоже задача не тривиальная.
Старшие разработчики должны оперативно разбираться в сложных системах, обладать глубоким пониманием паттернов чистой архитектуры
А вроде неплохо начиналось, а опять всё туда же... Паттерны, алгоритмы...Профессионала от начинающего отличает наличие чуйки, способность по корке стека понимать, откуда копать проблему и раскопать её быстро, а не всё это...
На всех трех этапах вам предстоит иметь дело с архитектурными проблемами, решение которых способно истребить немало воробьев.
Эту аналогию я не понял вообще. Историю про китайев, а ранее кроликов я знаю. Но тут я не совсем понимаю
Смотрите. Не секрет, что хороший код отличается от говнокода тем, как он выполняет НЕфунккциональные требвоания. И также не секрет, что некоторые нефункциональные требования явно входят "в конфликт" с другими
Но задачу найти баланс, особенно в большом проекте (в маленькком часто вообще по фиг, так как там все просто и никаких вызовов нет), это задача тимлида/архитектора. Условный джун либо миддл даже могут не осознать всей проблематики.
Но главное - я не вижу связи с заголовком. Это банально не уровень ответственности миддла и ниже
Если подвести итог, то главная проблема, отделяющая вас от статуса старшего инженера-программиста, заключается в том, что вы не прорабатываете сложные проекты, получая при этом правильную обратную связь.
Ну так прорабатывайте. Тут странно выгоядит, хотите стать - становитесь. Но нельзя стать сеньором, делая все время тривиальные вещи. Да и в практически любой деятельности
В таком случае вашу статью можно свести до одной рекомендации: раздвигайте горизонты своих возможностей и рост вас настигнет :)
в моем понимании, универсальный совет "как стать сеньором" может быть только один. Думайте о финансах фирмы, в которой работаете. Как лично вы можете помочь либо сэкономить, либо заработать дополнительные. Потому что руководство думает об этом каждый день, и если оно при этом будет регулярно натыкаться на плоды вашей деятельности, то гарантированно обратит на вас внимание.
Много красивых слов. Но по сути отсутствие внятной связи между мидлами и синьорами в компании говорит о закукливании последних и велика вероятность сгорания вторых, пока первые смогут добраться до их уровня.
Настоящая причина, по которой вы не станете сеньором