JavaRush /Курсы /C# SELF /Пишем код: как выглядит рабочий день программиста

Пишем код: как выглядит рабочий день программиста

C# SELF
12 уровень , 5 лекция
Открыта

1. Обычный день из жизни разработчика

Быть программистом легко и приятно ☀️. За организацию работы отвечает Project Manager, за список фич продукта — Product Owner. Митинги организует Scrum Master. Все организационные процессы максимально формализованы и стандартизированы ✅.

img

Вы приходите утром на работу, делайте себе чаек или кофе ☕️, садитесь за компьютер 🖥️. Открываете общий чат 💬, смотрите нет ли срочных сообщений, не заболел ли кто 🤒, и, если все в порядке, приступаете к работе.

Вы открываете сайт JIRA, в котором хранится список всех задач вашей команды: бэклог проекта и бэклог текущего спринта. Задачи уже рассортированы по приоритету вашим Scrum Master/TeamLead или ProductOwner.

Вы берете задачу с самого верха — самую приоритетную 🔝 и начинаете над ней работать. Для этого ее нужно перевести в статус In Progress. Это делается парой кликов 🖱️. Все, время пошло ⏳.

К описанию задачи обычно добавляется дополнительная информация или ссылка на документацию 📄. Задача должна содержать всю необходимую информацию для того, чтобы вы могли ее выполнить. Наличие такой информации — это задача вашего менеджера 👨‍💼.

Если что-то не так, вы можете переназначить задачу ("таску" на программистском языке) на вашего менеджера и написать в комментариях к ней о том какие возникли вопросы и/или какой информации не хватает.

2. Пишем код

Вы изучили описание задачи и вам понятно, что нужно сделать. Отлично, приступайте к работе 🏁. Тут вам поможет ваш опыт обучения на JavaRush и опыт работы в команде 🤝.

После того, как очередная фича готова, и вы в этом убедились, вам нужно залить код в Git. Делается это парой кликов прямо из IDE. В вашем случае — из Rider 🚀. Вы комитите ваш код сначала в свой локальный репозиторий, а затем пушите (push) его в центральный Git-репозиторий.

Чаще всего последняя операция делается через Pull Request, когда вы через Git отправляете запрос вашему тимлиду на ревью вашего кода. Если с кодом все отлично и замечаний по нему нет, то ваш тимлид утвердит (accept) ✅ ваш pull request и он попадет в основную рабочую ветку Git’а.

Важно! Ни в коем случае нельзя сидеть и молчать, если вы не знаете, как делать задачу. Такая ситуация часто возникает, и многие новички (и не только новички) часто решают ее неправильно. Запомните, если вы в течение 2-х часов так и не разобрались, как делать задачу, вам нужно уведомить об этом вашего менеджера 🚩.

Также не стоит ходить к тимлиду с фразой «это нельзя сделать». Такая фраза очень раздражает, особенно если тимлид точно знает, что «это сделать можно», и сам делал что-то аналогичное, причем неоднократно.

Не знаете, как делать — скажите: «я потратил два часа/два дня, пытаясь разобраться, как это сделать, но у меня не получается». Тимлид подскажет вам, в каком направлении гуглить 🔍.

Вот мы и прошлись по картине современной разработки продукта. Написание кода — это только маленькая часть всей работы, но все организовано так, чтобы вас от вашей работу ничего не отвлекало. Так что смело переходите к изучению C# — работать программистом вам понравится 😉.

Комментарии (3)
ЧТОБЫ ПОСМОТРЕТЬ ВСЕ КОММЕНТАРИИ ИЛИ ОСТАВИТЬ КОММЕНТАРИЙ,
ПЕРЕЙДИТЕ В ПОЛНУЮ ВЕРСИЮ
Slevin Уровень 55
27 января 2026
"Хочешь я оформлю эту статью в PDF добавив в нее еще больше смайликов?"
Yokei Уровень 16
29 января 2026
легенда
Евгений Уровень 17
3 декабря 2025
Красиво. Утопично. В СНГ для большинства компаний среднего и малого бизнеса (про фриланс тактично умолчим) все описанное - в лучшем случае благие пожелания (а в худшем - грустный анекдот). Типичная ситуация: "настроенные процессы" есть в голове у начальника, поэтому меняются в режиме реального времени. На ПМа никто не тратился (как и на скраммастера - зачем бизнесу такие излишества?), в роли ПО выступает все тот же начальник. Если повезет, оный немного разбирается в разработке и умеет формулировать мысли. Рассчитывать на это не стоит, шутка про задачу "сделайте мне кнопку 'зашибись'" не на ровном месте возникла. Поэтому чаще это выглядит как хрестоматийное "Программист - это инструмент по превращению кофе и бреда заказчика в рабочий код". Отсюда совет всем начинающим: избавляйтесь от айтишной спеси и учитесь понимать далеких от сферы людей и самостоятельно работать на полный цикл: "Снятие задачи у заказчика/начальника -> формирование и согласование(!) ТЗ -> согласование сроков/ресурсов -> настройка технического окружения -> написание прототипа кода -> согласование работающего прототипа (это важно в условиях скачущих хотелок у заказчика) -> написание продакшн-кода -> тестирование -> сдача проекта". Опционально можно после каждого пункта поплакать и вернуться к исходной точке. Собственно, именно этот процесс и имеется в виду под словом "самостоятельность" во всевозможных вакансиях.