Всем привет! Меня зовут Максим. Я backend-разработчик, который не так давно устроился на свою первую работу. В этой статье хочу поделиться своими наблюдениями/советами/рекомендациями для начинающих программистов. Ведь, как известно, если опыт не превращён в текст, он даже не становится прошлым.
Материал будет полезен тем, кто ищет первую работу или не так давно её нашёл. Примеры будут из области Python Backend, но наблюдения универсальны и спокойно перекладываются на другую область. Поехали!
Погружайся в инструменты
Судя по тому, что я читаю в Интернете, начинающие программисты делают акцент на изучение языка, фреймворков, best practice и т.д., а инструменты отодвигают на второй план. Очевидно, что человек, будучи джуном, уже в курсе как настроить IDE, что такое Docker, Git и прочее. Однако, когда разрабатываешь что-то большее, чем собственные pet-проекты, следует копать глубже и предметно погружаться в вопрос.
Если раньше можно было спокойно использовать Dockerfile c образом alpine и было ОК, то теперь надо искать эффективные и надёжные альтернативы (например, python-slim-buster).
Создавать отельный файл docker-compose.yml для локальной разработки тоже необязательно, ведь существует docker-compose.override.yml!
Вряд ли в домашних проектах, кто-то кроме тебя добавлял изменения в main-ветку, пока работаешь в feature-ветке. А в коммерческой разработке это норма. Придётся резко узнать о существовании rebase. Подобных моментов куча.
Теперь ты пишешь код не один - значит пришло время полноценно научиться пользоваться pre-commit, black, isort, mypy и другими инструментами, использование которых принято в компании. Чтобы войти в курс дела рекомендую посмотреть ролик:
Также приведу другие ресурсы, которые взял на вооружение:
-
Git
-
Docker
Nginx - Nginx Mastery
Ansible - книга Бас Мейер, Лорин Хохштейн и Рене Мозер Запускаем Ansible. Простой способ автоматизации управления конфигурациями и развертыванием приложений.
Всё это не мишура, которая отвлекает от написания кода. Чем лучше знаешь инструменты, тем быстрее пишешь код и приносишь пользу бизнесу.
Коммуникация и soft skills
Я считаю, для джуна чрезвычайно важны soft skills. Минимальный базовый набор hard skills он получил, а софты дадут возможность быстро прокачиваться за счёт взаимодействия с более опытными коллегами. Очевидно, что обмен реальным опытом даёт мгновенный рост (это я почувствовал на себе уже в первую неделю работы).
Не надо бояться спрашивать. Как говорится - не стыдно не знать, стыдно не хотеть знать. Но спрашивать надо тоже правильно. Нет смысла доставать коллег банальными вопросами из разряда: “А как сделать сортировку в админке?”. Спрашивать нужно то, с чем действительно не можешь разобраться сам. Решения нет на форумах, YouTube, статьях в Интернете. Перепробовал кучу всего, результата нет, а время идёт. Старайся по максимуму закрывать вопросы самостоятельно, но если не получается - это не смертельно. Все с чего-то начинали.
Кроме того, важно уточнять у менеджера, если не до конца понял задачу. Лучше “показаться тупым” и уточнить, чем за день до сдачи проекта переделывать фичу, которая работает не так, потому что ты что-то не правильно понял.
Кроме того, не стоит бояться просить ревью у старших коллег. Команда также заинтересована в твоём росте. Ведь твоё профессиональное совершенствование напрямую связано с решением вопросов бизнеса.
Если хочешь идти быстро иди один, если хочешь идти далеко иди с кем‑то. Это характеризует и современную разработку. Разработчики люди, а люди — существа социальные. И с этим ничего не сделаешь. [Senior Softskills Engineer]
Не изобретай то, что уже сделали в команде раньше
Когда приходишь в компанию, скорее всего, у неё уже есть наработки. Например, при запуске нового проекта не пытайся сочинить структуру самостоятельно, основываясь на своём, напомню, “игрушечном опыте”. Скорее всего в команде есть boilerplate-шаблон, которого следует придерживаться. Узнай про это заранее (опа, soft skills in action).
Это же касается code style и других guidelines. Тот же Black Formatter настаивается по-разному: одинарные или двойные кавычки, длина строки 79 или 88 символов и т.д. Это уже давно продумано и согласовано, твоя задача узнать “правила игры” и придерживаться их. Круто, если ты можешь привнести что-то новое. Например, если нет общего стандарта документирования кода попробуй его продумать и предложить для внедрения.
Узнай как конкретно у вас принято именовать коммиты/ветки при работе с системой контроля версий. Мы в команде используем Conventional Commits 1.0.0. Однако не факт, что у вас будет также.
Аналогично с моментами из кодовой базы. Например, нет смысла изобретать собственную библиотеку для SEO, если её уже сделали раньше. Не факт, что сделаешь лучше или она будет корректно работать, а вот время определённо потратишь. Возьми готовое решение и переиспользуй для своего проекта. Если в последствии доделаешь или расширишь – будет круто. У компании появится внутренний инструмент (а может и open source), который можно тянуть от проекта к проекту. Однако стоит придерживаться одного правила:
"Привносить что-то новое можно и нужно, но только если это не вредит выполнению текущих задач" (с) Егор Романов, Frontend-разработчик в ProninTeam.
Стоит быть аккуратным со сторонними библиотеками. Обязательно посмотри поддерживают ли её авторы до сих пор, закрываются ли issues, пользуются ли ей другие люди. Возвращаясь к вопросу soft skills, спроси у коллег, они подскажут проверенный вариант, если сам не уверен.
"Мне только спросить" - ваша коронная фраза на ближайшее время.
Делай рефакторинг, если позволяют сроки
Безусловно надо стремиться к тому, чтобы сразу писать качественный чистый код. Однако это не всегда получается (особенно если речь идёт о джунах). Поэтому имеет смысл посмотреть код проекта и подумать, что и как можно улучшить. Например, подсмотреть более эффективный алгоритм, найти хорошую библиотеку или внедрить паттерны проектирования. Так можно убить сразу двух зайцев - улучшить качество кодовой базы проекта и прокачаться как разработчику. Потом можно ревью провести и ещё улучшить, но..
"Коммерческая разработка - это про поиск рабочих решений за оптимальное время" (с) Александр Кондратьев, Backend-разработчик в ProninTeam.
"Причёсывать" код необходимо, если тебе позволяют сроки. Да, паттерны это круто. В дальнейшем будет проще расширять код, поддерживать и т.д. Но если ты из-за неопытности долго провозился с внедрением очередной Стратегии и не успел доделать к дедлайну - бизнес спасибо не скажет. Программирование - это не про абстрактные фабрики, микросервисы и Docker. Программирование - это про решение задач бизнеса. Бизнесу нужно, чтобы приложение решало его проблемы (оформляло заказы, присылало уведомления, обрабатывало данные). И если код решает эти проблемы эффективно через набор if’ов, а не pattern matching - бизнес не пострадает.
В идеале планировать процесс разработки, чтобы оставалось хотя бы какое-то время на улучшение. Если удалось выкроить время на рефакторинг, имеет смысл сделать код лучше - внедрить паттерны и приемы. Так ты приобретаешь опыт и в следующий раз, скорее всего, будешь писать код сразу применяя наработки. Значит дополнительное время уже не нужно или пойдёт на усовершенствование других моментов.
Рост - процесс итеративный. Нельзя просто так взять и стать middl’ом. К этому надо прийти, маневрируя между сроками, тасками и саморазвитием.
База про паттерны и DDD
Очень доступно про паттерны (примеры на С++): http://cpp-reference.ru/patterns/creational-patterns/factory-method/
Паттерны с примера на Python: https://github.com/pkolt/design_patterns
Про DDD c примерами на Python:
https://habr.com/ru/articles/559560/
https://habr.com/ru/companies/oleg-bunin/articles/488010/
Щупай смежные области
Изучать разное - это залог профессионального роста и возможность не пресытиться одноплановой работой.
Например, если ты backend’ер можно на базовом уровне разобраться в HTML/CSS/JS. Верстка - смежная область, а значит будет легче понимать, что вообще происходит и станет проще коммуницировать с frontend’ерами в команде (а это ускоряет процесс разработки).
Если frontend’ер, то почему бы не научиться писать Dockerfile для Nest, чтобы самому было проще работать локально.
Работа становится эффективнее, задачи бизнеса закрываются, а ты и твоя ценность, как специалиста, растёт.
Лично я в процессе работы стал робко посматривать на серверные моменты (настройка Nginx, Caddy) и CI/CD-пайплайны.
Сделай план развития
В процессе работы обнаружишь пробелы в знаниях. Составь список того, что стоит изучить/прокачать. В идеале разделить этот список на две части:
пробелы, которые нужно закрыть в кратчайшие сроки (то, что будет нужно в работе уже в ближайшее время)
долгосрочная перспектива (то, что в идеале нужно освоить, но в ближайшую неделю-месяц, скорее всего не понадобится).
Лично у меня получился такой список:
-
Краткосрочные
Админ-панель Django (кастомные виджеты, list_select_related, classes, django-nested-admin и т.д.)
Миграции
Permissions DRF
-
Долгосрочные
Nginx/Caddy
Docker (на продвинутом уровне)
Git (на продвинутом уровне)
Ansible
Развиваться желательно не в рабочее время (см. ущерб текущим задачам). Лично я предпочитаю прокачиваться размеренно в выходные или перед работой. Например, если рабочий день начинается в 8:00 - не грех встать в 7:00 и поучиться. Развитие начинающего - дело рук самого начинающего.
Не пытайся прыгнуть выше головы
Ты теперь часть команды, часть корабля. Не нужно бежать вперёд остальных и пытаться закрыть проект за два дня без еды, сна и отдыха. Разработка - это не спринт, а марафон. Да, на энтузиазме можно один раз сделать всё и сразу. Ну, два раза, три… Но в определённый момент либо не выдержит здоровье, либо наступит то самое хайповое выгорание. От того, что ты сделал проект за три дня вместо пяти запланированных компании лучше не станет. А вот потеря эффективности и трудоспособности точно негативно отразится на процессе разработки в дальнейшем.
В компании есть менеджеры - они выстраивают процесс работы, коммуникацию с заказчиком, пытаются равномерно и по способностям распределить задачи. Ты в руках профессионалов, доверься им. От тебя требуется только качественно и в срок выполнять требуемые задачи.
Это не значит, что не стоит быть активным и нужно пассивно сидеть. Я лично старюсь предлагать какие-то решения и придерживаться принципа давай чуть больше, чем от тебя требуется. Но под “чуть больше” не подразумевается работа в надрыв и ущерб самому себе.
Канбан-доски, кстати, очень помогают организовать работу. Не игнорируй их, если они есть на проекте. Если их нет, веди сам. Например, зарегистрируйся в YouGile и записывай всё в “Приватных задачах”. Также можешь туда складывать персональный бэклог (то, что было бы неплохо сделать, подпилить или доработать).
Отдыхай
Последний в списке, но не последний по важности, пункт - это отдых.
Разработка - это интенсивная интеллектуальная сфера труда. Чтобы ментальная и физическая составляющие не пострадали следует не пренебрегать отдыхом, едой и сном.
Важно делать перерывы и в процессе работы. За это тебе скажет спасибо и продуктивность, и здоровье (спина, шея).
Напоминаю, компании не нужно чтобы ты умер или заболел. Ей нужно чтобы ты качественно делал свою работу, желательно на всём жизненном цикле компании (а не один месяц).
Когда ты сидишь над задачей 10 часов и она не получается, зачастую проблема не в том, что задача сложна или ты тупой, а в том, что нужно просто остудить мозг…сделать перерыв хотя бы 15 минут…(с) Егор Романов, Frontend-разработчик в ProninTeam в интервью каналу PyLounge.
Бытовой отдых нужен обязательно, даже если тебя мучает совесть.
Можно отдыхать каждый день понемногу или полностью разгружать выходные. Лично мне не нравится “тюленить” полные выходные, я предпочитаю отдыхать равномерно в течение недели, например, не делать ничего «полезного» после 20:00. [Как всё успеть? | Мой тайм-менеджмент]
В идеале отдых должен быть в отрыве от компьютера, телевизора, телефона. Лично мне помогает разгрузиться поход в спортзал или просто прогулка по улице.
Заключение
Ко всем этим мыслям я пришёл опытным путём и надеюсь, что эти рекомендации облегчат процесс интеграции при устройстве на первую работу и помогут вам достичь успеха на нелёгком пути Junior-разработчика. Если есть что добавить, милости прошу в комментарии. Читателям и мне будет интересно узнать альтернативное или дополняющее мнение.
Комментарии (45)
Ziyoviddin
11.10.2023 19:34+1Подскажите пожалуйста, как вы нашли работу? Я уже месяц ищу работу, но пока тихо.
Aquahawk
11.10.2023 19:34Сколько резюме вы отправили?
Ziyoviddin
11.10.2023 19:34+1Почти 300
Aquahawk
11.10.2023 19:34+2Достойно, тогда очень странно. Конверсия в первое собеседование какая? Не приглашают, или валитесь на первом же общении с HR, не доходя до технического собеса, или уже на техническом провал? Есть ли в резюме указание на онлайн школы?
fo_otman
11.10.2023 19:34+45С каких пор люди, только недавно устроившиеся на свою первую работу, имеют моральное право раздавать свои советы направо и налево? Хабр когда-то был местом, где делятся опытом лучшие из лучших. Профессионалы. Указывают на неочевидные вещи. Рассказывают об эпичных фейлах и головокружительных успехах. Предотвращают ошибки. А что я вижу теперь? "Почитай книжку про Git и сделай рефакторинг". Серьезно?! Считаю, модераторам портала следует немного построже работать со статьями, содержащими избитые истины. Нет никакого интереса читать эту воду в ленте.
venanen
11.10.2023 19:34+5Лучшие из лучших - это вы загнули, но действительно классные статьи бывали частенько. Сейчас они тоже есть - очень редко, статья, про которую можно сказать "хабратортно". И все понятно - писать долго статью чтобы она утонула в потоке хреновых переводов на главной и мусорных статей - занятие не благодарное. Поэтому вот, как есть, увы.
magn1fique
11.10.2023 19:34+13Автор делится своим джуновским опытом с другими джунами. Или советы всем должна раздавать только абстрактная "элита", которая уже давно не является джунами и даёт советы, которые новичок любо не поймет, либо ему это пока не нужно?
ioncorpse
11.10.2023 19:34+6Джуны имеют полное право раздавать советы тем, кто ещё даже не Джун. :)
У кого опыт 20+ немного о другом думают. И дают советы тем, у кого опыт 10+. Образно конечно.
Aturner060
11.10.2023 19:34+3А разве по заголовку статьи не понятно, о чем пойдет речь? Кому интересно и познавательно, тот прочтет. Кому нет - пропустит. Или хабр только для «элиты»?
sajog84461
11.10.2023 19:34+3А с каких пор люди, только недавно устроившиеся на свою первую работу, НЕ имеют моральное право раздавать свои советы? Браво! Вот действительно тот хабр, который все заслуживают. Алло! Какая еще илита? Вот поэтому хабр и скатывается в безду, потому что оторвано от комьюнити и реальности, где тусуются в своем каком-то мирке.
Solovej
11.10.2023 19:34Такое уже давно: хорошие статьи — редкость, достойные профи перестали писать и делиться опытом. Пропаганду удалять уже нельзя — покушение на свободу слова. А раз дичь стала нормой, то и остальные компании стали тоже писать всякую ахинею.
Nurked
11.10.2023 19:34Я буду продолжать продвигать идею "Судов присяжных для Хабра".
Любой человек, при наличии какого-то определенного порога кармы, который увидил такую гофноту в ленте может попросить собрать суд присяжных. При этом, он должен без эмоций описать что не так со статьёй.
Из всех авторов, которые активны и меют больше 100 кармы, случайным образом выбирается 12 авторов. Им представляется обвинение на статью и то, почему она не Торт.
У присяжных есть 2 дня на то, чтобы каждый независимо вынес своё решение и высказал своё мнение. При этом, автор комментария не имеет права говорить, что статья не торт. Ему надо написать, как эту статью исправить, чтобы она была тортом. (В данном случае, например, можно сказать следующее - представленный опыт сликом однобок и узок. У автора нет достаточного опыта для написания этой статьи. Но если автор пойдёт и опросит своих друзей-программистов, то добавив их опыт, он сможет составить хорошую статью)
Если большинство сказало, что статья - кака, то статья отправляется в черновики, со всеми комментариями по улучшению статьи.
Статью можно будет переопубликовать через неделю с поправками. При этом, присяжные перепроверяют качество, и если оно прошло, то всё хоршо. А если нет, то статья навеки отправляется в черновики.
При этом, модераторам Хабра не надо будет пачкать свои руки в том, чтобы пытаться снять статью. У них есть свои правила, и я понимаю, что некоторые из них это читают с кислой миной и мыслью "Забанил бы". Но у них нет возможности и права этого сделать.
А если мы создаём коллегиальный орган, где условием работы будет необходимость развёрнутых ответов по поводу того, как это исправить, то тогда и модераторы тут ни при чём.
А то висят тут, статьи про астрологию, написаные ChatGPT, и всем от этого становится плохо.
ky0
11.10.2023 19:34+4Если раньше можно было спокойно использовать Dockerfile c образом alpine и было ОК, то теперь надо искать эффективные и надёжные альтернативы (например, python-slim-buster).
Ну да, расскажите эксплуатации с высоты своего опыта, какой образ лучше использовать, как деплоить, про настройку Куба расскажите...
sshemol
11.10.2023 19:34Оффтоп. В чем преимущество делать бекенд на питоне?
paulglad
11.10.2023 19:34+1В том же, в чём преимущество использования питона в принципе. Он создавался как язык, на котором можно было бы разрабатывать быстро. Т.е. удобный синтаксис, много сахара, декораторы, слайсинг и т.п. А также интерпретируемость, позволяющая не ждать пересборки всего проекта при отладке, если ты изменил одну строку.
Почему в таком случае его сейчас не выбирают все подряд - программы, написанные на нём работают медленнее, чем на Java или .NET, отчасти засчёт той же интерпретируемости, поскольку компиляторы способны выдавать очень сильные оптимизации, т.к. знают обо всём твоём коде сразу.
То есть питон выгоден, если надо быстро и в сжатые сроки построить систему и отдать заказчику, но если в системе много вычислений, которые должны работать быстро, то другие языки предпочтительнее.
Btw, могу ошибаться, ибо сам являюсь .NET разработчиком, но в своё время был в восторге от питоновских декораторов, иногда их не хватает
Gotcha7770
11.10.2023 19:34Пошёл прочитал, про декораторы.
Декоратор — это функция, которая позволяет обернуть другую функцию для расширения её функциональности без непосредственного изменения её кода.
Тот факт, что всё является объектами, открывает перед нами множество возможностей. Мы можем сохранять функции в переменные, передавать их в качестве аргументов и возвращать из других функций.
В .Net делегаты есть. Или я что-то не так понял?
paulglad
11.10.2023 19:34Делегаты про передачу функции в качестве параметра. Да, можно сделать подобие вызова функции с декоратором с помощью делегатов, но это будет вызов вида Декоратор(Функция, [параметры функции]), вместо обычного Функция([параметры функции]).
Представим, что мы пишем библиотеку. Разработчик, её использующий, будет видеть только сигнатуры функций. Если мы в питоне навесим на неё декоратор, он будет использован при обычном вызове функции. А в примере с делегатом этот разработчик может не знать о декораторе и не вызвать его.
Да, можно сделать функцию 1 приватной, затем сделать публичную функцию 2, которая будет вызывать функцию 1 с декоратором, но тут возникает проблема: если у нас есть один декоратор, который мы навешиваем на несколько разных функций, то для каждой придётся писать такой дубликат.
В общем, декоратор - удобный синтаксический сахар. При желании на чём угодно можно написать что угодно, вопрос лишь в том, сколько времени это займёт. В питоне навесить декоратор - написать одно слово с @ перед функцией. В примере выше, хоть и немного, но написать нужно больше. А теперь помножим это на количество таких ситуаций, и ещё раз помножим на тот факт, что декоратор - это лишь один из примеров, а подобных сладостей в питоне много. Мне например, ещё очень нравится слайсинг. Вот из всего этого сахара и складываются меньшие затраты времени на разработку.
И, опять же, это лишь общая идея того, для чего вообще создавался питон, я не ручаюсь, что это так работает в реальности, ибо в .NET тоже хватает сахара, по сравнению с той же Java. Я её как-то попробовал, и обплевался от отсутствия даже такой банальной вещи, как Свойства классов. Но это лишь моё мнение, кому-то и без них норм, да и Легаси кому-то надо поддерживать
Boilerplate
11.10.2023 19:34Я несколько лет пишу и на Java, и на C#. Так вот я так и не смог привыкнуть к Java. Слишком много чего нет из того, что есть в C#. Тот же LINQ, например, и много чего еще.
imanushin
11.10.2023 19:34Если Вы используете JVM, то можно писать код на Kotlin. Результатом будет тот же байт-код, а проблема с неудачными конструкциями в Java исчезнет сама собой.
Более того, один и тот же проект может иметь код как на Java, так и на Kotlin (то есть файлы могут соседствовать).
Gotcha7770
11.10.2023 19:34А в Java вроде уже относительно давно есть некие стримы, или это тоже не то?
Gotcha7770
11.10.2023 19:34Спасибо! Вроде понял разницу. А если
Разработчик, её использующий, будет видеть только сигнатуры функций. Если мы в питоне навесим на неё декоратор, он будет использован при обычном вызове функции.
когда я потребитель такой функции я вижу, что на ней декоратор или это от меня скрыто?
Про слайсы - в .Net есть Span<T>, правда без параметра steppaulglad
11.10.2023 19:34когда я потребитель такой функции я вижу, что на ней декоратор или это от меня скрыто?
Тут лучше спросить питониста, но я предположу, что скрыто. Как и любая другая деталь реализации в целях инкапсуляции.
Про слайсы - в .Net есть Span<T>, правда без параметра step
Так step - это самое сладкое!
Gotcha7770
11.10.2023 19:34Я имел ввиду немного другое. Если я, допустим, вызываю делегат в C# там тоже все скрыто. Но, в основном, я могу установить какой конкретно код вызывается, проследив, где делегат был создан. В python я пойму, что функция обернута в декоратор в процессе разработки, или я буду ожидать одного, а в ответ получить могу другое?
paulglad
11.10.2023 19:34Вот здесь я вас не очень понял.
Если это код ваш или вашей команды, и находится в рамках одного проекта/решения, то вам, вероятно, даже IDE подскажет.
Если это код закрытой библиотеки, то всё, что у вас есть - это документация. И тогда всё зависит от неё.
Ожидать одно, получить другое - в целом всё зависит от конкретной ситуации, от того, как хорошо описана функция. Не от наличия декоратора. Да и сами декораторы нужны лишь для пред- и пост-обработки. Не думаю, что кто-то будет писать их для того, чтобы сбить вас с толку.
TDMNS
11.10.2023 19:34+3Хочу еще некоторые дополнения внести про отдых и разгрузку.
Поход в спортзал и прогулка, все таки может сопровождаться мыслями о работе, по крайней мере у меня. Если у кого-то точно также, то я советую вам применить немного другой подход.Мне кажется что разгружаться стоит как физически так и творчески. Я после рабочего дня (или в перерывах) играю на гитаре, и это максимально помогает мне. Я отвлекаюсь от своих задач, компьютера и получаю от этого удовольствие. Иногда я рисую, или даже пою и это тоже полностью помогает отвлечься от задач. Даже элементарно приготовить еду включив на фоне сериал очень поможет вам забыться на несколько часов о работе. И каждый день, я гуляю (не смотря на погоду). Прогулка нужна лично для меня, по той причине что я хочу чтобы мои глаза отдохнули, выходя на улицу я смотрю вдаль, и таким образом берегу свои глаза.
Как сказал Роберт Мартин (Дядя Боб) в своей книге «Идеальный программист. Как стать профессионалом разработки ПО»
Не пишите код, когда вы устали. Преданность делу и профессионализм проявляются в дисциплине, а не в продолжительности работы. Обязательно следите за сном, здоровьем и образом жизни, чтобы вы могли ежедневно посвятить работе восемь хороших часов.
nameless323
11.10.2023 19:34Поход в спортзал и прогулка, все таки может сопровождаться мыслями о работе
Если вы ходите в спортзал чтобы заниматься единоборствами, игрой в командные виды спорта или заниматься видами спорта типа гимнастики, у вас мыслей о работе особо возникать не будет. Если просто потягать железо, то да.
Гитара тоже хорошо, но раздражает людей (не все любят когда гитарист сидит дома после работы и гоняет гаммы по кругу часами) и не дает физ нагрузки важной для людей, которые по 8+ часов в день проводят в сидячем положении за монитором.
Krouler7
11.10.2023 19:34Цитата из приведенной Вами статьи(https://habr.com/ru/companies/oleg-bunin/articles/488010/):
Сначала техническая часть, потом — DDD. Скульптор, который высекает статую из камня не читает мануал о том, как держать молоток и долото — он уже знает, как ими работать. Чтобы привнести DDD в ваш проект, освойте техническую часть: выучите до конца Django, прочитайте туториал и перестаньте спорить, что брать — PostgreSQL или MongoDB.
Т.е. все-таки это не для Junior уровня. DDD - скорее про архитектуру кода. Если нет знаний и опыта на множестве инструментов то и DDD банально не сможете использовать.
Сдается мне что бизнес решил сэкономить на кадрах.
nivorbud
11.10.2023 19:34Пример личного опыта новичкам интересен.
Только смотрю я на всё это... и подсознательно чувствую, что что-то неправильно во всём этом, какой-то тупик. Бесконечное изучение инструментов, инструментов, инструментов... бесконечное перекладывание их с места на место, замена одних другими... В общем переливание из пустого в порожнее. Причем такого рода знания очень быстро устаревают, приходится постоянно крутить педали, чтобы не упасть. Т.е. такие знания, в отличие от фундаментальных, сами по себе малоценны, а ценность обретает лишь поддержание этих знаний в актуальном состоянии. Потом, если устаканится как-то, то работа идет по жестким шаблонам, с фанатичным соблюдением отступов и прочих фентифлюшек. Творческий подход, новизна, оригинальные идеи - всё это улетучивается. Получается, это уже даже не ремесло, а чистый конвейер. Бизнесу нравится. Наверно, это и есть путь к выгоранию...
Извините, это просто сетование ни о чём...
PS
Когда я делаю какой-нибудь личный проект, там процесс совсем иной: большую часть разработки я веду, прогуливаясь по парку, читая смежную литературу. Это занимает где то 80% времени разработки. И только остальные 20% - набор кода, отадка и пр.
Krouler7
11.10.2023 19:34Когда я делаю какой-нибудь личный проект, там процесс совсем иной: большую часть разработки я веду, прогуливаясь по парку, читая смежную литературу. Это занимает где то 80% времени разработки. И только остальные 20% - набор кода, отадка и пр.
Советую углубиться в философию марксизма в таком случае. Там объясняется это.
Если вкратце и по сути:
Компании интересны только 20% - их и будут оплачивать ибо они с них могут поиметь доход. А вот все остальное - пожалуйста сами себе оплачивайте.
Gotcha7770
11.10.2023 19:34Но ведь эти 20% вытекают из тех 80ти. То есть в том, что компании могут таким образом обосновать всю ту чудовищную разработку, которая повсеместно ведётся, я не сомневаюсь. Но проверку на логику такое обоснование не выдерживает, на мой взгляд
alan008
11.10.2023 19:34+1Всё правильно написано, но только надо делать скидку, что каждый разработчик варится в своей среде. Нахрен тебе докеры, нгинксы и ансиблы, если ты разработчик для микроконтроллеров, например.
Тут скорее совет в духе: узнавай, какими инструментами пользуются в твоей области: а может ты разработчик на 1С, например. Или мобильный разработчик. Или разработчик нативных GUI-приложений под Linux. Или разработчик драйверов. Да мало ли разных сфер. И в каждой из них свои инструменты и свои подходы и никто не знает, что из этого будет живо через 5 лет, а что подохнет в море "миллиардов новомодных фреймворков".
Лучший совет уже прозвучал когда-то от Стива Джобса: stay foolish, stay hungry.
saipr
Мне тоже, но это своеобразный отдых. Во время такой прогулки/физзарядки тело отдыхает, набирается энергии, а мозг продолжает оработать. Поскольку рядом нет компьютера, то и нет возможности сразу же опробовать пришедшие в голову решения, которые порой могут быть и ошибочными. А вот хорошо поверьтет их в голове очень даже получается, порой приходят неожиданные решения и намного проще, чем если бы сидел за машиной. И много плюх можно вычистить во время таких прогулок.
Отдыхайте творчески.
uranik
Думать на отдыхе о работе??
saipr
Да, именно так. Именно так я отдыхаю от работы монотонной.
xtended
Основная проблема программиста - нельзя отложить в сторону основной рабочий инструмент, так как он прикреплен шеей)
vova9110
Можно ведь и бегать. Тогда вообще сложно думать о чём бы то не было, да и не хочется. Ну, либо просто другую тяжёлую физ. нагрузку
saipr
Можно и еужно и бегать!
Старанно. Можно бегать и трусцой!
larasage
Действительно тяжелую нагрузку долго не выдержишь. Обычный бег "для здоровья" не должен быть тяжелым, при этом он довольно монотонен. Я вполне решал во время бега и свои рабочие задачи и олимпиадные задачки сына. Чтобы отвлечься нужно занять мозги - чтение, просмотр чего-либо... из физнагрузок - либо что-то игровое, либо просто связанное со сложной координацией движений.
nameless323
Единоборства у меня вообще отключают мозг в процессе, остается только то, что происходит в моменте - отчасти по этому и выбрал их, чтобы мозг реально переключился. Сложно думать о программировании когда напротив человек хочет тебя ударить или бросить или задушить :)