🪨джун с опорой: как я строила себя в профессии. советы и мысли

когда только начинаешь карьеру в разработке, сложно понять, на что опираться. особенно если кажется, что все вокруг умнее, быстрее, опытнее.
с самого начала работы я получала очень тёплую и честную обратную связь от коллег. благодаря этому у меня выстраивалась опора — на себя, на процесс, на рост. ниже — пару выдержек из отзывов.

«коллеги очень высоко оценили твою активность, инициативность и желание качественно делать задачи»
«ты справляешься с уже достаточно сложными задачами, проявляешь инициативу и не боишься брать на себя ответственность»
«успешно решаешь сложные проблемы, задаешь правильные вопросы, стремишься к лучшему коду»
«отмечают твой вклад в разработку фич, внимание к деталям и постоянное стремление улучшать решение»
«серьёзно подходишь к проектированию, выстраиваешь коммуникации с командой и заказчиком, быстро адаптируешься и делаешь качественный код»

эти слова давали мне не только поддержку, но и пищу для анализа: а что именно я делаю правильно? а что работает?
сформировались принципы, которые я бы с радостью отдала себе-джуну в первый рабочий день. делюсь ими здесь.

1. всегда проверять реализацию
даже если всё супер и тесты зелёные — всё равно делать смоук-проверку руками. лучше я поймаю баг, чем QA будет разбираться, почему не работает. *в некоторых командах это является зафиксированным процессом, а в некоторых - нет
2. быть пессимистом — полезнее, чем оптимистом
научись сразу думать о худших сценариях. особенно в сроках и оценках. лучше успеть раньше, чем провалить дедлайн. без навыка оценивать дальше никуда.
3. самостоятельность — мышца, которую надо качать
если нет идей — это не повод молчать. я старалась озвучить хоть что-то, и старшие коллеги подхватывали. не страшно быть неуверенной — страшно не учиться на этом.
4. не обижаться на «тщательное» ревью
знаю, что некоторые воспринимают ревью как критику, но это в корне не так. это не про «ты плохо сделал», а про то, как сделать лучше. хорошее ревью - это подарок. я всегда просила меня жестче ревьюить.
5. нужно бороться с иллюзией «все всё знают, а я — нет»
вечно кто-то да обсуждает какую-нибудь сортировку креветками. да, большой пласт незнания на старте - это естественно, но существует категория людей, которая буквально вчера прочитала что-то заумное и редкое на хабре и теперь хочет, чтобы об этом знал весь мир. никто не знает всё. часто задачи специфичны. это просто иллюзия восприятия.
6. ошибаться — нормально
«человек, который ошибался много и часто – но никогда не совершал одну и ту же ошибку дважды, – более надежен, чем тот, кто не ошибался никогда»

⛰напоследок, мои мини-привычки, которые помогают до сих пор:
— если доделываю задачу вечером, утром обязательно перепроверю на свежую голову
— если не знаю, с чего начать, - пытаюсь сформулировать вопрос: ответы самому себе часто приходят в процессе формирования вопроса другому
— сначала пишу код средне, чтобы просто работало. а потом улучшаю до состояния «нравится»

если пост понравился - оставляйте реакцию ❤️

🌺последние пару месяцев я детально изучала проекты Spring Cloud

зачем?

сейчас я работаю на проекте с микросервисной архитектурой, но так было не всегда. до этого у меня был опыт с SOA. понятно, что ни одна архитектура не является универсальной — у каждой свои плюсы и минусы. но дело не в сравнении подходов.

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

Spring Cloud — это не просто фреймворк. это набор обёрток над проверенными архитектурными решениями: Resilience pattern, API Gateway pattern, Distributed events, dynamic configuration и другие.

изучение этих проектов даёт не только новые инструменты для решения нетривиальных задач, но и понимание того, как выстраивать систему более осознанно:
— как автоматизировать CI/CD с помощью contract-тестирования
— почему используют Vault для безопасного хранения секретов
— какие trade-off’ы стоят за выбором: Bus vs manual refresh

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

в конечном счёте, цель — прокачка архитектурного мышления.
не просто использовать аннотации, а видеть за ними реальные паттерны, инженерные компромиссы и логику. в том числе — лучше понимать open source и, возможно, однажды внести вклад в него

оп, выловила златое число!🐡

потихоньку появляются темы докладов предстоящего Joker🍇

уже для себя отметила парочку интересных.

но встал вопрос: ребята-разработчики (бэк), а как у вас отношения с девопс-обязанностями?

сейчас прикреплю опрос

касаемо меня: прожала 3 вариант.

почти каждый день общаюсь с devops-инженерами на работе. базовое понимание их процессов сильно помогает говорить на «одном языке».

не считаю, что разработчику нужно уметь это все, но в некоторых проектах роли всё-таки смешивают — и это сразу можно считать по вакансиям.

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

но цели идти в devops-команду нет.
всё-таки проды, падающие в три ночи, — это не та романтика, которая меня пленит😒

поделиться ли с вами чуть позже своим опытом переезда с java 11 -> java 17 (sb 2.* -> 3.*)?

посмотрю на количество реакций❤️

маленькое наблюдение.

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

я впитываю много знаний, но как только они не используются — мозг откладывает их на дальнюю полку.

правда в том, что сейчас я опираюсь на другую метрику.
не «я всё помню» (что оказалось невозможным), а «как быстро я смогу вспомнить, где это найти и как работает»

это как база данных: ценность в том, чтобы в нужных местах были индексы

и это действительно сильно упрощает мое восприятие мира


💎 - знакомо/узнал себя
⛰ - задумался
🪨 - я все по жизни помню
🐓 - для веселых ребят