История о воробушках, правильном фидбеке и житейских проблемах
Четыре зла
В 1958 году Мао Цзэдун инициировал «Большой скачок» — организованную китайской коммунистической партией кампанию по трансформации страны в индустриально развитое государство.
Акция «Четыре зла» входила в число первых шагов, предпринятых в рамках «Большого скачка». Под девизом «Человек должен победить природу» власти нацелились на уничтожение четырех вредителей: крыс, мух, комаров и воробьев.
Борьба с вредителями широко практиковалась по всему миру, а сами её методы считались научно обоснованными. Но, вопреки ожиданиям, большинство принятых мер, хоть трижды научных, пагубно сказалось на производстве продуктов питания.
Истребление воробьев привело к серьезному экологическому дисбалансу. Отсутствие естественных хищников повлекло за собой нашествие насекомых на поля и порчу урожая, что в итоге послужило одной из причин Великого китайского голода 1959-1961 годов.
Великий китайский голод считается одним из самых смертоносных бедствий в истории человечества, а число погибших от его последствий исчисляется десятками миллионов (от 15 до 55 миллионов человек).
Сценарии большой неопределенности
Слишком много светлых умов пострадало от безрассудного увлечения бесполезными знаниями. — Сенека
В сфере разработки программного обеспечения существует три уровня квалификации, характеризующиеся рядом отличительных особенностей:
Младшие разработчики обыкновенно сосредоточены на изучении принципов написания кода, функционирования баз данных и способов сборки всего подряд. Они нередко чувствуют себя погребенными под горой знаний, которые им необходимо впихнуть себе в голову, и большую часть времени они, откровенно говоря, просто пытаются выжить в этом хаосе.
Разработчики среднего уровня должны разбираться в более продвинутых особенностях используемого языка, им приходится рецензировать код, направлять младших и хорошо понимать фреймворк, с которым они работают.
Старшие разработчики должны оперативно разбираться в сложных системах, обладать глубоким пониманием паттернов чистой архитектуры, знать, как происходит масштабирование систем, требующих значительных объемов данных, и, желательно, уметь летать.
На всех трех этапах вам предстоит иметь дело с архитектурными проблемами, решение которых способно истребить немало воробьев. И так же, как во времена «Большого скачка», скоропалительные действия в отношении веб-систем могут привести к тому, что приложение потеряет важные финансовые данные или, например, заставит компанию потратить сотни тысяч долларов дополнительных ресурсов на реализацию неоправданно сложной системы.
Собеседования с программистами чрезвычайно сложны, потому что при их проведении компании в первую очередь пытаются отсеять тех, кто может случайно (или даже осознанно) убивать воробьев.
Но как же понять, с чего следует начать? На свете есть без преувеличения тысячи курсов для младших программистов, обещающих за полгода-год превратить вас в мидла, но на деле, даже закончив целый университет, вы по-прежнему останетесь неоперившимся джуном. Как понять, чему нужно учиться в первую очередь? К чему быть готовым?
Когда вы оказываетесь на уровне мидла, между вами и старшими коллегами возникает огромная пропасть: невозможно получить ни внятный совет, ни качественный фидбек. В этом и заключается реальная причина того, что большинство мидлов не могут стать сеньорами, а некоторые и вовсе не стремятся к этому, разочаровавшись во взаимодействии с коллегами.
Обратная связь
Если ты интересуешься предпринимательством, то наверняка слышал о многочисленных способах проверки бизнес-идеи.
Частая ошибка новичка, которую совершают не только программисты, но и начинающие предприниматели, — попытка проверить свои идеи с помощью анкетирования или путем простого опроса друзей и близких. Люди с легкостью говорят: «Да, я бы это купил», но потом, когда продукт выходит в мир, придумывают тысячу причин, чтобы от него отказаться.
Это создает проблему курицы и яйца: вы не хотите приступать к разработке продукта, не убедившись в том, что он нужен людям, но люди не поймут, нужен ли он им, пока он не станет доступен. Это чрезвычайно усложняет жизнь предпринимателям.
Правильный цикл обратной связи делает процесс обучения возможным: ваш наставник знает правильный ответ и при случае может вас скорректировать. Так же работает современный ИИ: можно обучить модель, если известны правильные ответы.
Как бы то ни было, у мидл-разработчиков возникает та же проблема, что и у предпринимателей: они не располагают циклом обратной связи, чтобы вовремя корректировать свою работу и учиться. А коллега, указывающий вам на проблему, не научит вас ни паттернам, ни средствам обеспечения отказоустойчивости, ни масштабированию.
Оракул
Если бы только существовал бесплатный инструмент, который хранил бы весь контент интернета и мог мгновенно поправлять все, что мы делаем.
Честно говоря, я не очень верю в prompt engineering, в основном потому, что это не «инженерия» как таковая, но всегда ценю креативные примеры взаимодействий с ChatGPT.
Вот один интересный пример общения с ChatGPT, о котором вы, скорее всего, не слышали:
Вот что интересно: чат будет следить за твоими успехами, и в случае отказа ты сможешь получить обратную связь, которую компании обычно не дают:
Уже первая строчка наталкивает на правильные мысли. Я не стал бы ведущим инженером-программистом без таких книг, как «Чистая архитектура».
Знания из реальной жизни
Если подвести итог, то главная проблема, отделяющая вас от статуса старшего инженера-программиста, заключается в том, что вы не прорабатываете сложные проекты, получая при этом правильную обратную связь.
Книги вроде «Cracking the Coding Interview» помогут разобраться в том, как компании FAANG набирают сотрудников, — такие знания можно получить только благодаря инсайдеру, в открытом доступе их не так много. Но помимо этого, вам также необходимо браться за реальные проекты или попадать на настоящие собеседования, чтобы усвоить знания после многих лет практики.
В одном из эпизодов «Теории большого взрыва» Шелдон объясняет, что «научился» плавать путем умственных упражнений из интернета и тренировок на полу. Мол, у него нет никакого интереса к плаванью в настоящей воде.
Не забывайте, что вам также необходимо быть скромным, чтобы учиться у других и принимать их замечания.
Программисты всегда открыты для критики и обсуждения чужого кода. Поэтому пользуйтесь этим. Это полезно, хотя иногда может и раздражать.
Не пункт назначения, а образ жизни
Мастерство — это не пункт назначения, а путь непрерывного обучения и неустанной практики. Вы станете старшим инженером-программистом, только если будете докапываться до сути и бросать себе суровые вызовы.
Пусть ваша работа будет свидетельством настойчивости и объективности, потому что пройдет время, вы станете сеньором, и в этой роли возьмете на себя значительную ответственность — не только за создание качественных приложений, но и за формирования вектора развития для небольшой частички нашего мира.
Комментарии (17)
opusmode
14.04.2024 21:57+15Хорошо, я готов быть джуном-сантехником, если вам угодно, если я продолжу дальше делать свою работу, за свою ЗП.
Кстати, научитесь уже, пожалуйста, называть вещи корректными именами -- если говорите о понимании причины и следствия, так и говорите. Нет никакой проблемы курицы и яйца. Всё, кто хоть немного знают биологию и знают о мутациях, точно знают ответ - первым было яйцо из которого и появилась первая курица, которая является потомком некого пра-существа. Курица это результат мутаций переданных ранее генов.
e-zig
14.04.2024 21:57+2А про-существо из яйца вылуплялось?
opusmode
14.04.2024 21:57+2Скорее да. Ну, вряд-ли оно было живородящим, а потом, внезапно, начало откладывать яйца. Но курицей оно не являлось. Но было очень близко к курице.
Собственно, когда говорят, что у человека и у обезьян общий предок, говорят примерно об этом же.
Tim_86
14.04.2024 21:57Внезапно? То есть то, что было "очень близко к курице", но не было живородящим и не откладывало яйца, "внезапно", за одно поколение, стало откладывать яйца? Серьёзно? Вы в это верите?
MAXH0
14.04.2024 21:57Изначально из икринки. Но потом существо мутировало, вылезло на сушу и икринки обзавелись защитной пленкой и стали яйцами. На этом пути побывали миллионы существ и тысячи мутаций.
Dmitri-D
14.04.2024 21:57Кстати, ChatGPT довольно верно сказал что нужно при соискании позиции SDE в AWS, но это относится ко второй части, а первая - technical assesment - там только умение решать задачи, как правило несложные, если имеются познания в DP.
MAXH0
14.04.2024 21:57+4Настоящая причина, по которой вы не станете сеньором
Потому что пирамида иерархии подразумевает на одного сеньера сотню батраков. Если бизнесу не нужны твои знания, если тебе не дают заданий на "сложные проекты, получая при этом правильную обратную связь", то и получить их неоткуда. Можно конечно научиться "плавать на полу" :)
MikeVentris
14.04.2024 21:57В таких условиях рынок должен подталкивать программистов, имеющих зачатки синьора, но не имеющих подходящей вакансии, становиться предпринимателями. Что часто и происходит. Проблема только в том, что эмоция возникающая походу: «это чего, я опять джун, только теперь джун-предприниматель!?»
MAXH0
14.04.2024 21:57+3Рынок тоже имеет емкость экосистемы. Иерархия -- это не только про угнетение на самом деле. На сотню элементов электронной рассыпухи приходится одна микросхема. Это естественно. Точно так же, в бизнесе на сотню элементарных бизнесов, где дальше джуна не вырастешь, приходится один, где требуется глубокая интеграция. Единственный выход, думать глубже и искать бизнес-идею, которая повысит уровень требований и даст при этом конкурентное преимущество. Пример который я обычно привожу для учеников -- Додо-пицца. Они из сервиса доставки сделали высокоинтеллектуальный бизнес. НО найти такую идею тоже задача не тривиальная.
usego
14.04.2024 21:57+6Старшие разработчики должны оперативно разбираться в сложных системах, обладать глубоким пониманием паттернов чистой архитектуры
А вроде неплохо начиналось, а опять всё туда же... Паттерны, алгоритмы...Профессионала от начинающего отличает наличие чуйки, способность по корке стека понимать, откуда копать проблему и раскопать её быстро, а не всё это...
Batalmv
14.04.2024 21:57+1На всех трех этапах вам предстоит иметь дело с архитектурными проблемами, решение которых способно истребить немало воробьев.
Эту аналогию я не понял вообще. Историю про китайев, а ранее кроликов я знаю. Но тут я не совсем понимаю
Смотрите. Не секрет, что хороший код отличается от говнокода тем, как он выполняет НЕфунккциональные требвоания. И также не секрет, что некоторые нефункциональные требования явно входят "в конфликт" с другими
Но задачу найти баланс, особенно в большом проекте (в маленькком часто вообще по фиг, так как там все просто и никаких вызовов нет), это задача тимлида/архитектора. Условный джун либо миддл даже могут не осознать всей проблематики.
Но главное - я не вижу связи с заголовком. Это банально не уровень ответственности миддла и ниже
Если подвести итог, то главная проблема, отделяющая вас от статуса старшего инженера-программиста, заключается в том, что вы не прорабатываете сложные проекты, получая при этом правильную обратную связь.
Ну так прорабатывайте. Тут странно выгоядит, хотите стать - становитесь. Но нельзя стать сеньором, делая все время тривиальные вещи. Да и в практически любой деятельности
В таком случае вашу статью можно свести до одной рекомендации: раздвигайте горизонты своих возможностей и рост вас настигнет :)
lrrr11
14.04.2024 21:57+1в моем понимании, универсальный совет "как стать сеньором" может быть только один. Думайте о финансах фирмы, в которой работаете. Как лично вы можете помочь либо сэкономить, либо заработать дополнительные. Потому что руководство думает об этом каждый день, и если оно при этом будет регулярно натыкаться на плоды вашей деятельности, то гарантированно обратит на вас внимание.
holms_2000
14.04.2024 21:57Много красивых слов. Но по сути отсутствие внятной связи между мидлами и синьорами в компании говорит о закукливании последних и велика вероятность сгорания вторых, пока первые смогут добраться до их уровня.
19Zb84
Очень размытое предложение.
Например. Неоправданно сложной веб-системой я могу назвать практически любую веб систему, которая использует фреймворк в связке с бандлером любым. (Языки кроме js я даже не рассматриваю. Фактически единственный приспособленный язык для веба это js)
Сейчас я не знаю ни одной проблемы, которую нельзя было бы решить модулями и веб компонентами. И есть только один аргумент в пользу фреймворков это документация. Но и это очень сомнительно, потому что в документации очень часто не хватает информации по системе, которая требуется, а ответов на вопросы на stack owerflow не найти. И если такое происходит, единственный вариант лезть в чужой код и ещё с ним разбираться.
Тогда получается по вашей фразе, огромное колличество проектов и практически все коммерческие проекты это неоправданно сложные системы.