Вопрос к программистам⁠⁠

Задача на две недели - это скорее всего какое-то исследование (включая проектирование подсистемы). Это уровень мидла (который скоро станеть синьором) или синьора. Типовые задачи для джуна, например - это до 2 дней: обозримо, понятно и если упёрся во что-то - быстро понятно техническому начальнику (синьору или техлиду). Для мидла в норме задача будет на неделю примерно.

Примеров, извините, приводить не буду: гипотетический случай придумывать лень, а реальные будут стоить денег, причём мне. Впрочем, если вы только изучаете отрасль - вам это всё равно не нужно. Вам больше нужно сначала наработать алгоритмы и структуры данных, а потом - научиться оценивать вашу собственную производительность. Автоматизируйте что-нибудь, что нужно вам более или менее часто. Или пойдите в опенсорсный проект, который вам интересен, возьмите какой-нибудь простенький (или нет - всё равно на данном этапе) баг и занимайтесь им: спроектируйте решение (требования, бизнес-правила, разбивку на задачи) и оцените сколько вам надо времени на то, чтобы сделать эти задачи в соответствии с правилами проекта. А дальше - цикл: решение задачи - сравнение с изначальной оценкой - переоценка оставшихся задач. И, конечно же, обдумывание: почему промахался с оценкой?

Кстати, оценку лучше делать в виде интервала "оптимистичная - пессимистичная". Оптимистичная - это когда всё идёт хорошо, пессимистичная - это когда реализуются все заложенные в оценку риски (да, проблемы тоже надо планировать, причём не под абстрактным имененм "проблема", а конкретные такие проблемы поимённо с указанием времени на их персональное решение). И потом принимать за основу реалистичную оценку, которая делит интервал от оптимистичной до пессимистичной в соотношении 1:3.

Например, задача (в рамках проекта супер-пупер-инженерного калькулятора): разбор синтаксиса выражения и построение синтаксического дерева. Вход: токенизированное выражение. Выход: дерево операций, где листовые узлы - константы, а остальные узлы - операции. Оценка оптимистичная: 4 часа (делать там скорее всего больше нечего и даже их многовато - но пусть). Риски:
- я плохо знаю работу с деревьями. Решение: изучить соответствующую темы в "Алгоритмы и структуры данных". Время на изучение и практику - 3 дня (24 часа) (Это маловато для темы вцелом, но для целеё задачи - достаточно).

- я не понимаю как работают указатели. Решение: изучить соответствующую главу в учебнике, решать задачи. Время: неделя (40 часов) (И это очень оптимистично на самом деле).

Пессимистичная оценка: 68 часов. Реалистичная: (3 * 4 + 64) / 4 = 17 часов.

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

Забыл сказать: если даже ваши правки в опенсорсном проекте будут хуесосить - отнеситесь к этому позитивно: вам показывают к чему надо стремиться. А с какого-то раза, причём не очень даже далёкого, вам ответят: вот тут и тут хорошо бы поправить так или эдак, и - вуаля! - ваш коммит принят в проект! Можно с гордостью звать друзей и коллег отмечать ваше серьёзное достижение в новой профессии!

В общих чертах это выглядит так (по крайней мере у меня на работе)

Обычно есть специально обученный человек в лице бизнес аналитика, который напишет документацию (проще говоря ТЗ)
Архитектор (или если его нет - тимлид) ознакомится с тз и, поскольку он человек опытный, декомпозирует одну большую задачу на множество мелких.
Мелкие задачи раздаются в виде тикетов разработчикам, которые он и выполняет, приходя на работу

Много уже промелькнуло, но в вопросе был интересный момент, про постановку задачи: написать вот такую вот функцию a(b) и вот полное описание а и б. Такое может и бывает но не часто. Этим занимались раньше люди типа кодировщиков.. человек который переводил заданный алгоритм из человеческого/математического языка в компьютерный код. Сейчас такие люди не нужны, нужны инженеры, которые в условиях абстрактных требований сами должны сконструировать/создать логику работы и запрограммировать её. Т.е. задача, например: я хочу чтобы пользователь ПО мог совершить транзакцию(перевести деньги со счета на счёт). Все, дальше уже этим занимаются разработчики, которые разрабатывают для этого определенный алгоритм/последовательность действий, определяют потоки информации для совершения транзакции. Как они это делают технически - это уже их проблемы и их решения. Сам процесс написания чего-то в виде кола занимает обычно 5-10% процентов времени, остальное это поиски решения проблемы. Но.. всегда бывают исключения.

Так и не скажут, у тебя вопрос ну очень не корректный. Сказать именно свои задачи? У меня NDA сказать примеры мифических или с прошлой работы? А смысл тут в треде куча программистов и все разные фронт Бэкон разные языки разные проекты у людей разный техуровень от стажера до архитектора. Ну вот представь форум инженеров и ты спрашиваешь у всех разом примеры работы: а там инженера: фермы, тракторного завода, космического корабля, тсж и инженера любителя - ну как тебе вот ответить? Или уточни пожелания что хочешь услышать? У нас практически нет задач без отвязки от контекста проекта: условно нет задачи сортировка пузырьком а есть задача отсортировать карточки клиентов на странице контактов. Согласись без деталей на чем написано, где, и что там за страница и контакты - из задачи ну непонятно же.

А что происходит с самого начала?
Пришёл клиент и говорит "Я хочу программу такую-то".

А вот тут немножко интересней. Клиент приходит к продажникам (сэйлзам), сэйлзы приходят ко мне.

- Слушай, тут клиент пришел, хочет программу.

- Они все хотят программы. Какие бизнес-потребности клиент хочет автоматизировать?

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

Дальше пишем поэтапный план (breakdown) для минимального прототипа, отсылаем сэйлзам, они расценивают и вместе с расценками отсылают клиенту.

Вот там архитектура и закладывается на этапе брейкдауна. Но, возможно, в процессе она будет меняться - аджайл такой аджайл.

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

поподробнее про "задачи из бэклога", пару примеров хотя бы. На восемь попугаев и на два тоже.

Ну, например, на проекте не хватило возможностей стандартного nginx по обработке токенов безопасности.

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

Это на самом деле был "эпик", т.к. заняло весь спринт, и там внутри было 5 отдельных задач по 2 дня каждая.

Т.е. атомарные задачи размером с весь спринт, или полспринта - это на самом деле редкость и прзнак недодробленности, либо плохой архитектуры.

На 2 попугая было "починить неверную отдачу статуса HTTP от upstream сервиса".

По большому счёту вопрос - не о программировании в узком смысле слова, а об управлении (программными, если придираться к словам) проектами.

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

2. Надо понять как раньше решал эту задачу заказчик - зафиксировать бизнес-правила - то есть узнать что в принципе допустимо, что - не допустимо и как с этим всем обращаться.

(Здесь пропущены разные интересные для больших программных продуктов шаги. Вам они в начале пути - примерно на уровне пояса.)

3. Разбить задачу создания программы на какое-то количество небольших частных задач - как минимум, дожен осуществляться ввод данных, их обработка и вывод результатов. Всё это - в соответствии с бизнес-правилами. Разбиение продолжается до тех пор, пока для каждой задачи не станет ясно как именно она дожна быть решена. Как минимум для каждой задачи должен быть прописан алгоритм решения хотя бы для основного хода событий (т. е. игнорируя ошибки) в понятном и доступном исполнителю (программисту) виде. Могут быть указаны основные структуры данных, общие для нескольких задач - просто чтобы не забыть. (На самом деле не только и не столько чтобы не забыть - но нам сейчас эти соображения похуй).

И вот мы подошли к самому программированию. Ура!

4. Делаем задачи, которые определили в пункте 3. Если мы всё спланировали хорошо, то у нас всё срастётся и задача будет решена.

Если что-то пошло не так, то надо понять почему и вернуться к самому корню проблемы для её правильного устранения - вплоть до пересмотра функциональных требований (что чаще всего всё же не нужно). При этом мы старое не выкидываем, а творчески преобразуем стараясь менять как можно меньше для достижения ожидаемого эффекта: чем меньше изменений, тем меньше работы - а нам лень. Впрочем, иногда лучше выкинуть почти всё (из разбиения на задачи) и сделать заново - но это либо самые первые крупные проекты, либо какая-то фатальная патология была на этапах 1-2.

5. Оценка результата. Испытания.

При необходимости сделать совсем сложную систему её можно разбить на несколько частей и ходить по пунктам по кругу для каждой из этих частей.

Начинать, естественно, надо по маленькому. Потому что если сразу по большому начать, можно обосраться и сильно из-за этого расстроиться. Поэтому сначала берётся задачник по программированию на языке XXX (бери Паскаль - не ошибёшься: базовые управляющие структуры и алгоритмы везде одни и те же, а решать-то всё равно сам будешь). Потом можно попробовать книгу вроде "Алгоритмы и структуры данных" поизучать - естественно, всё программировать, крутить-вертеть и чтобы оно писало что-то на экран. В результате может получиться методом наращивания мяса какой-нибудь супер-пупер-инженерный калькулятор, который умеет вычислять выражения даже с эллиптическими и гиперболическими функциями комплексного аргумента. Но начнётся он всё равно со сложения и умножения двух чисел.

Всё очень просто. Пришёл на работу, открываешь жиру. А там таск на тебя назначен:

Заказчик требует новый функционал. Из семи перпендикулярных друг другу красных линий две должны быть зелёные, ещё две синие и ещё несколько прозрачных, по возможности. И одна должна быть в форме котёнка. Бюджет 4 часа.

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

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

Начинать лучше всё таки в команде, там и совета можно спросить и не будешь болтаться сам по себе как говно в проруби.

Ну и по теме. Я недавно наткнулся на такой вот канал, человек отвечает на подобные общие вопросы от новичков. Как начать работать, как войти в АйТи, что начинать учить, как учить и так далее. Я думаю для начала вам будет полезно, как втянитесь - там вы уже сможете составить своё мнение о процессе работы. Я не со всем согласен что он говорит, но большая часть советов полезна.

https://www.youtube.com/c/SergeyNemchinskiy/videos

Утром открываешь журнал текущих задач (jira) на две недели (sprint) берёшь по порядку свободную задачу или ту которая записана на тебя, делаешь ее, потом проверяешь что правильно сделал (unit test) и хвастаешься коллегам смотрите как я могу (review) коллеги говорят крутяк но вот там индуский код поправь (fix review) правишь, коллеги говорят ты молодец (approved) сливаешь задачу (merge request) у задачи в журнальчике ставишь галочку что сделал... и так пока не зае... устаёшь, каждые две недели вы с коллегами и начальством придумываете что бы ещё упороться и пишите новые задачи

Как и в каком виде происходит поставка задачи? Как она формулируется?
Кто эти задачи "распределяет"?
Как вообще проходит рабочий день?

Ну, например так.

Работа ведется короткими двухнедельными отрезками - "спринтами".

Перед стартом каждого спринта проводится совещание как минимум из менеджера проекта и занятых на проекте специалистов (разрабы, архитекторы, тестировщики, аналитики, техписы).

На совещании из общей очереди задач проекта (backlog) вытаскивается очередная и оценивается в попугаях.

Условно, у нас команда в 10 разрабов. Каждый разраб за спринт может закрыть 10 попугаев, итого емкость спринта у нас 100 попугаев. Вот жирная задача, аж на 8 попугаев. Её возьмет сеньор Денис. И еще Денис возьмет вот эту на 2 попугая. Всё, емкость Дениса на этот спринт кончилась. И так далее. Причем в любой момент условный Вася может сказать - о, я уже делал похожую задачу в этом модуле/сервисе, и я ее сделаю не за 8 а за 6 попугаев. И ему отдадут эту задачу.

Собственно, задачи ведутся в таск-трекере, например Jira. Сел за задачу, перетащил ее в состояние "In progress" - все, заинтересованные лица видят над чем ты работаешь. Закончил - перетащил дальше. Не можешь закончить - тащишь в состояние "Заблокировано" и в комментах пишешь - почему, на очередном совещании озвучиваешь. Совещания от одного раза в неделю до ежедневок, обычно с утра.

В конце каждого спринта, если есть результат, который можно "показать лицом" - проводится демо, где представителю заказчика демонстрируется прогресс. Обычно это провоцирует пополнение бэклога спринта )