Нехорошие новости для джунов.

Сейчас джуны не нужны, невыгодны, и нас в большинстве случаев не будут нанимать. Сейчас не так много мест, где хотят брать джунов на фронтенд.

Ключевая причина — AI-агенты выполняют джуновские задачи и требуют ревью от мидла или сеньора. А если есть джун, то он добавляет лишнюю ступень в этой цепи:
AI → Джун → Мидл/Сеньор.

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

В целом профессия программиста возвращается к истокам и снова становится делом по призванию, так как учиться нужно больше и уметь многое. Сейчас, чтобы войти в IT, скорее всего, придется вырасти до уровня мидла — либо с небольшим шансом попасть на позицию джуна/стажера.

Такие выводы я сделал после просмотра видео «Как AI меняет разработку?».

Я трогал программирование еще 12 лет назал в универе и оно мне нравилось, но тогда у меня не было долгосрочных планов, и я просто перестал уделять внимание учебе.

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

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

В коментах приклеплю видео с цитатой

—

Обещанный второй ролик из серии “Дорога в Айти”

Смотреть на Ютуб
(всего 4 мин)

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

Спустя месяц работы над задачей 🙈

▻ изменено 133 файла
▻ добавлено 2300 строк
▻ удалено 1400

Этот MR на стартапе, где я работаю никто не будет проверять. Я его проверял сам с нейронкой и просил найти критические и важные ошибки.

По итогу нашлись ошибки именований, типов и надо было обновить тесты.

В целом думаю что прогонять MR/PR через нейронку хорошо даже если потом его будет смотреть человек. Помогает найти то, что мы недоглядели. Особенно в разделах, которые мы не трогали, но они связаны с нашими изменениями.

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

Начал проходить курс по TypeScript

Я до сих пор не проходил системно структурированные материалы по TypeScript. И в мои руки попал свежий курс по TypeScript.
(Спасибо другу за это 🤝)

В первом ролике на тему “Иерархии типов” узнал про важную особенность объектных типов (object types).

Оказывается в TypeScript при описани подобного типа:

type User = 
{ name: string; }

это правильно читать следующим образом: “поле name обязательно в объекте и должно иметь тип string”. Но это не означает что объект типа User должен иметь только одно поле name.

Eсли в переменную типа User напрямую присваивать объект с лишними полями

{ name: 'Bob', age: 33 }

то будет ошибка проверки лишних свойств (“Excess Property Checks”). А если присвоить через промежуточную переменную или получить объект из сетевого запроса — ошибок нет.

Excess Property Checks срабатывает, если объект сразу присваивается переменной.

А вы знали про эту особенность?

#100DaysOfStudy День 92

Нашел способ как облегчить чтение статей 🗿

И можно выбирать скорость чтения.

Задачка на понимание TypeScript

Вопрос: Почему нету подсветки ошибки в коде, но падает Run?
Ссылка на Код

——
Ключевые моменты:

1) Надо учитывать особенность что в TS объектные типы являются открытыми. И они не запрещают иметь больше полей чем мы указали.

2) Указывать явно типы не всегда есть хорошо. А еще есть такая вещь как “satisfies” которая не указывает тип, а проверяет его на совместимость.

3) Опциональный тип “:?” в объекте может вызывать проблемы при типизации параметров функции.

В этом примере он позволил принимать объект без поля verificationDate, что позволило принять тип User. От этого можно было бы защититься если в типе VerifiedUser типизировать поле вот так

verificationDate : Date | undefined

Разбор в открытом доступе - Ютуб

#100DaysOfStudy День 93