Привет! Если ты сейчас учишься программировать, и думаешь что‑то вроде «Вот выучу все, и тогда пойду на собесы», то у меня для тебя плохая новость — выучить все невозможно. Это осознание пришло ко мне только спустя несколько лет работы backend разработчиком.

В этой статья я расскажу

• Почему даже синьоры постоянно что‑то учат

• Как в IT оценить сроки задач и при чем тут Toyota

• И на каком языке написаны программы, обрабатывающие 90% банковских транзакций в мире.

Погнали!

Без чего невозможно программировать?

Представь, что ты решил стать программистом на Java. Ты хочешь понять, что нужно знать, чтобы устроиться на первую работу. Конечно сам язык, но что еще? Если у тебя нет знакомых айтишников, которые могут подсказать, ты, скорее всего, зайдёшь на сайт вакансий, чтобы проверить свои догадки.

В вакансиях ты увидишь слова вроде Maven, Gradle, JDBC, SQL, Postgres, REST API, Spring, Kafka, Kubernetes и ещё много других загадочных терминов.

Теперь ты можешь закрыть ноутбук и пойти работать курьером, там как раз подняли зарплаты.

А че так сложно-то?

Проблема в том, что даже в одной области программирования существует слишком много инструментов. Знать их все досконально невозможно. Чтобы найти человека, который идеально знаком с вашим стеком, вам нужно... нанять того, кто уволился из вашей команды год назад. Но даже он успел многое забыть, ведь все это время использовал совсем другие инструменты: вместо Kafka — RabbitMQ, вместо Postgres — MongoDB, а вместо Kubernetes — OpenShift.

Вот почему глубоко разбираться в какой‑то конкретной технологии зачастую бессмысленно. Достаточно иметь общее представление обо всём, чтобы понимать, о чём идёт речь. Для этого даже придумали красивый термин: T‑shaped специалист.

Такой человек хорошо разбирается в чем‑то одном, и имеет представление о смежных областях. Сейчас от разработчика ждут не только написание кода, но и работу с ci/cd, тестирование, поддержка сервиса в проде, эффективную коммуникацию с командой, а иногда и с бизнесом.

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

Есть одна вещь, без которой невозможно программировать (помимо компьютера конечно), — это интернет. Отключи программисту доступ в сеть — и с вероятностью 90% он не напишет даже простое веб-приложение. Тем более полноценный большой сервис. И это нормально, держать в голове все необходимое практически невозможно. Главное - способность найти нужную информацию и разобраться в ней настолько, чтобы выполнить задачу в установленные сроки.

А как установить сроки?

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

К сожалению, нет.

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

Программисты хитрые, они не говорят "Мы не знаем, когда сделаем задачу", они говорят "AGILE". Существует два распространенных подхода к оценке задач в условиях неопределенности.

Первый вариант - Story points

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

1. Берем самую простую задачу которая есть на проекте и говорим - она занимает один стори-поинт.

2. Все остальные задачи оцениваем относительно этой - 2, 4, 10 стори-поинтов. Оценивать кстати - тоже непросто, для этого есь отдельный ритуал - planning poker, об этом можно почитать тут - https://ru.wikipedia.org/wiki/Покер_планирования.

3. Теперь ждем какое-то время и смотрим, сколько в среднем стори-поинтов за спринт выполняет команда.

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

5. PROFIT - теперь мы знаем сколько стори поинтов может сделать команда за спринт.

6. Правда это число со временем постоянно меняется, но лучше чем ничего

В одной команде 1 стори-пойнт может быть примерно равен часу работы, а в другой — неделе. Вот что имеем в итоге:

• Никто все еще не знает, сколько точно времени займёт задача.

• Мы выглядим профессионально, ведь вместо “да хрен его знает” мы говорим: “это задача на 3 стори-пойнта”.

Второй вариант - kanban

Эта практика честно украдена c производства Toyota. Правда там это были физические бумажки на доске, а у нас тикеты в Jira, но сути это не меняет. Давай разберемся как оценить сроки задач с помощью канбана.

1. Задаем несколько статусов, например - To Do, In Progress, Review, Testing, Done

2. Ждем какое-то время, и замеряем сколько занимает переход задач из статуса To Do в статус Done

3. Теперь совершается магия - например 95% задач проходят этот путь за 10 дней. Теперь мы можем говорить бизнесу что задачу, с вероятностью 95% будет готова через 10 дней.

4. Есть конечно, нюанс, что с вероятностью 1% она будет готова через год, но зачем забивать бизнесу голову какими-то нюансами.

   

Хорошо, программисты не знают сколько займет задача, но они ведь знают как работают их системы? Да?
Не совсем...

ТОП-1 язык программирования в 2025 году

Небольшое отступление от темы - мы уже выяснили, что технологий существует множество, включая языки программирования. Java, Python, JavaScript, Go, C++ — как выбрать самый важный?

Без какого языка нельзя представить современный мир?

Внезапный ответ: самый важный язык — это COBOL, созданный в 1959 году.

Почему COBOL до сих пор актуален?

На COBOL работают программы, которые обрабатывают 80–90% банковских транзакций в мире. Это все, конечно, круто, но язык выглядит устаревшим и неудобным по сравнению с современными.

IDENTIFICATION DIVISION.
PROGRAM-ID. HelloWorld.

ENVIRONMENT DIVISION.

DATA DIVISION.
WORKING-STORAGE SECTION.
01 WS-USER-NAME    PIC A(30).  *> Переменная для хранения имени пользователя

PROCEDURE DIVISION.
    DISPLAY "Введите ваше имя: "  *> Печатает сообщение в консоль
    ACCEPT WS-USER-NAME          *> Принимает ввод от пользователя
    DISPLAY "Привет, " WS-USER-NAME "!"  *> Выводит приветствие с именем
    STOP RUN.                    *> Завершает выполнение программы

Почему тогда его не заменяют? Всё просто. Многие системы на COBOL работают десятилетиями. Их переписывание потребовало бы огромных затрат времени и денег, а также несёт риск полного краха, потому что:

1. Эти системы настолько сложны, что вряд ли кто-то понимает все детали их работы полностью.

2. Документация редко бывает актуальной.

3. Те, кто создавал систему, давно ушли из компании (или из программирования).

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

...несколько лет назад Commonwealth Bank of Australia попробовал переписать ядро системы на новом языке. Переход состоялся, но на проект ушло около 1 млрд австралийских долларов — это в несколько раз больше, чем планировалось.

Итоги и советы

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

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

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

Если чего-то не знаешь - это нормально, спроси.

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

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