🇺🇸 Как выучить английский с B1 до C1 (часть 3)

Как прокачивать чтение:
B1: Гуглим на английском. Используем расширение с переводчиком, чтобы наводить на слово и получать перевод. Читаем статьи на интересующие темы. Например, если вы программист, читайте про используемые вами технологии.
B2: Все так же, как с B1. Можно пробовать читать адаптированную литературу, максимально простые уровни.
C1: Читаем литературу в оригинале, и все что выше. Вместо переводчика можно использовать Power Thesaurus, чтобы показывать синонимы выделенного слова.

Дополнительно, для всех уровней:
- Переведите телефон и компьютер на английский язык
- Пишите заметки на английском
- Если есть деньги, купите занятия с носителем. Хороший ресурс — italki
- Научитесь печатать десятью пальцами вслепую на английском (и на русском)
- Решайте word formation. Загуглите и решайте. Со временем будет становиться лучше, как будете натыкаться на одни и те же формы слова.

Вот и все. Подведем итог.
Подъем уровня с B1/B2/C1 занимает куда больше времени и усилий, чем подъем с A1. Чем выше ваш уровень, тем дольше вам прокачиваться до следующего и тем больше труда нужно прикладывать. Если вы готовы уделять лишь 30 минут в день, будучи на B1, то, вы будете расти очень медленно, но все же будете. Учите хотя бы 2-3 карточки и повторяйте все. На уровне B1 это очень важно. Оптимально — час на активный вокабуляр, 20-30 минут на текст. Текст можно не каждый день.
На B2 и выше уделять 30-40 минут уже будет нормально, ибо вам не нужно тратить много времени на прокачку активного словарного запаса. Рассказывать тексты все еще желательно, чтобы практиковать говорение.
Поймите, что только самодисциплиной и привычками можно добиться высокого уровня английского. Нет волшебного способа "легко и просто" выучить английский.

С этим я вас отпускаю. Этот гайд я советую использовать как инструкцию и возвращаться к нему по мере необходимости. Если у вас есть какие-то вопросы, задавайте их в комментариях под этим, последним, постом. Всех обнимаю.

🔥 4 часть, для А1

Напоминаю, что другие мои посты вы можете найти в навигации

К посту про английский до С1

Это иконка WordUp. Не перепутайте с другими приложениями с таким же названием

🇺🇸 Как выучить английский до C1 (здесь начинаем с А1) (часть 4)

Часть 1, как вообще выучить английский. Если не читали, начинайте с неё

Что делать на А1-А2

Дисклеймер: действовать так нужно, если у вас нет возможности взять платные курсы и хорошего преподавателя

На самом деле, все просто

1. Читаем мои посты выше для Б1-С1
1.1 Обязательно скачиваем дуолинго и проходим весь курс (актуально только для А1). Дуолинго - лучшее, что мне известно для начинающих. Я использовал его для немецкого
2. Скачиваем wordup
3. Прорешиваем любую грамматическую книжку от корки до корки
4. Где-то через 2 недели начинаем учить и учим первые 2000 слов как активный словарный запас (в постах выше объяснено, как именно это делать). По 20 слов в день
5. По инструкции в посте пересказываем тексты, но выбираем для пересказа самые простые — для уровня А1-А2
6. Слушаем на ютубе видео, созданные специально для практики аудирования у начинающих.
7. Переводим телефон и компьютер на английский
8. Очень желательно, покупаем pro подписку в wordup (8$/мес), гуглим список самых популярных фразовых глаголов и руками добавляем их в вордап через поиск

На самом деле, почти все, что вам нужно знать, я уже написал в предыдущих постах. Этот краткий пост — адаптирование написанного мной гайда под А1-А2. Ваша задача — делать то, что написано тут, по инструкции, что написана в частях 1-3.

Тратить придется 2-3 часа каждый день, не меньше. 20 слов в активный словарный запас + грамматика + тексты + аудирование. Желательно делать все каждый день. Повторять слова и во время повторения все так же проговаривать свои примеры обязательно. Примеры могут быть максимально простыми, "I have an apple" для слова "яблоко" пойдет.

Только огромными вложениями времени можно выучить английский. Занимаясь по 15 минут в день на А1, вы мало что добьетесь.

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

Наверное, пост получился немного резким. Я не хочу закидывать вас мотивирующими фразами. Мотивация работает лишь в начале, а дальше все строится на привычках и каждодневных вложениях в свою цель. Два компонента успеха — это тяжелый труд и везение. Вам уже повезло найти гайд, как выучить английский, в 4 части (и скоро будет пятая, для экстремалов), первую же часть вам придется делать самим.

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

Когда вы пройдете 2к слов в wordup и перенесете их в активный словарный запас, а также прослушаете кучу аудирования на ютубе, прорешаете всю грамматическую книжку и перескажите много-много несложных текстов (все по инструкции из прошлых частей делайте, опять же), то можете переходить к следующему шагу — подъему с B1 до C1.

У вас к тому моменту может быть B1, может не быть. Зависит от того, как вы старались, делая каждую из вещей. Чем больше вы прикладывали усилий, тем менее больно будет на следующем шагу.

Как выглядит вордап — https://imgur.com/a/WYCh4BK

🧠 Эффективное обучение

Давайте разбираться, что за зверь такой эффективное обучение. В частности, сегодня мы рассмотрим два стула, из которых желательно сесть на оба: интервальное повторение и Active Recall через гугл таблицы.

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

Начнем с первого стула.

Интервальное повторение

Был такой мужик, звали его Эббингауз. Он исследовал память, исследовал, и доисследовался: понял, что если что-то выучим, а затем повторим это через день, через 3 после этого, через неделю после этого, и т.д. (цифры условные), то после каждого повторения наша память запомнит материал на все более долгий период. Таким образом, если вы учите английское слово 10 января, то сначала вы повторите его 11, 13, 18, 30 января (цифры, опять же, условные), а потом 20 февраля, 30 марта, через 3 мес, через 6 мес, через год. Видите, как растет время до следующего повторения после каждого освежения памяти? Это и есть интервальное повторение. Вы повторяете через увеличивающийся интервал.

Руками это делать очень больно, поэтому для изучения языка (или теоретического материала, который вы хотите запомнить на долго) существуют две программы: Anki и Wordup. Первая подходит для всего, хоть древнекитайский там учите, вторая — чисто для английского. О них я писал в этом посте. Он про то, как выучить английский до С1. Если не читали, советую прочитать после этого.

Едем дальше.

Active Recall с гугл таблицами

Этот способ подходит больше для краткосрочной перспективы — 1-2 месяца. Это период, когда ваши знания будут самыми мощными. Например, вы готовитесь к собесу/экзамену и вам нужно выучить или освежить в памяти какие-то знания.
Давайте рассмотрим на примере, как он работает.

Вы создаете гугл таблицу. На скриншоте ниже вы можете увидеть, как она выглядит.
Самая первая колонка — это вопрос. Например, пускай нашим вопросом будет "Первый принцип SOLID".
Самый первый ряд — это дата. Здесь вы должны проставить дату от, скажем, сегодняшнего дня, на где-то 10 дней вперед. Если у вас очень много вопросов, то поставьте больше дней.

Вы рассказываете себе вопрос, что же такое первый принцип SOLID. Поскольку вы рассказываете его первый раз, то его мы будем считать "первым контактом"/"заучиванием"/вы поняли. Пересечение между сегодняшней датой и этим вопросом мы окрашиваем в синий цвет.

Предположим, вы создали еще два вопроса. "Методы жизненного цикла в реакте" и "Как работает виртуализация списков". Вы также рассказываете их себе, и красите прямоугольничек в синий цвет.

На этом заканчиваете.

Наступает следующий день.
Вы садитесь за таблицу, и начинаете рассказывать каждый вопрос. На первый вопрос, про SOLID, вы ответили средне. Вы красите клетку в таблице в желтый цвет. На второй вы ответили хорошо, вы красите её в зеленый. А с виртуализацией совсем плохо, вы вообще забыли, что это такое. Её красим в красный.
Естественно, ресёрчим первый и третий вопросы, ведь нам нужно вспомнить, что же это такое. Если у вас есть еще какие-то вопросы, вы можете выучить пару новых. Здесь, думаю, все понятно. Оптимально учить по 5-10 вопросов в день.
На этом сегодня закончили. Идем дальше.

Наступает третий день. Вы уже хорошо отвечаете на вопрос SOLID, и хорошо отвечаете на все остальные вопросы. Красим их всех в зеленый.
И вот тут-то наступает самое интересное.
Четвертый день. Заметьте такой момент: мы два раза подряд ответили "хорошо", зелененьким, на вопрос. Значит, мы можем быть уверены, что пока что его запомнили, и сегодня его можно не повторять. Повторяем лишь те, где последовательность "желтый - зеленый", "желтый - желтый", "желтый-красный", и так далее. То есть повторяем все, что не "зеленый - зеленый".

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

читаем дальше ниже

20 вопросов займет примерно 15 дней. Вопросом может быть "написать рекурсивную копию объекта", "как работает принцип единственной ответственности". Главное, чтобы на вопрос был четкий ответ, как на собесе. Это не вопрос на "порассуждать".

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

В заключение хочу сказать, что лучше всего комбинировать оба способа: Active Recall вам нужен, чтобы подготовиться к собесу/экзамену, на некоторое время поместив в голову то, что обычно спрашивают. Интервальное повторение — для долгосрочного запоминания. Active Recall — повторять много всегда, помнить только когда повторяешь в течение 10-20 дней. Интервальное повторение — повторять сначала много, потом все меньше, помнить при условии того, что повторяешь с увеличивающимися интервалами, даже раз в полгода.

В качестве бонуса, короткий совет:

Объясняйте себе то, что вы учите:
1. Так вы усвоите лучше материал
2. Вы поймете, что не поняли и сможете закрыть эти пробелы.

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

Напоминаю, что другие мои посты вы можете найти в навигации

UPD Советую посмотреть пост про подготовку к собесу по ванильному JS, тратя 15 минут в день

💻 Что фронтенд разработчики делают на работе, как устроены процессы разработки и пошагово как выучить веб с нуля бесплатно.

Я фронтенд-разработчик. Что конкретно делают фронтенд-разработчики:

Допустим, вы заходите в вк. Вы взаимодействуете с интерфейсом. У вк очень большой функционал: музыка, фотографии, сообщения, группы, клипы, звонки. Как вы называете такую штуку, которая у вас в телефоне? Приложение. Точно так же и на компьютере: только здесь это называется веб-приложение. Фронтенд-разработчики пишут интерфейс для веб-приложений. Кнопочки, на которые вы нажимаете, сообщения, которые пишете — все это делаем мы. Причем мы не просто рисуем их, а делаем так, чтобы, написав сообщение, оно отправилось, и как только ваш собеседник вам ответил, с минимальной задержкой пришло к вам. Как обычно, есть два стула: фронтенд и бекенд. Иногда стульев может быть больше, например, мобильное приложение (мобильный фронтенд), веб-приложение (фронтенд в браузере), и несколько бекендов. Фронтенд-разработчик, пишет он мобильное приложение, веб-приложение или приложение в холодильник с интерфейсом и доступом в интернет, делает так, чтобы вы взаимодействовали с бекендом через понятный интерфейс. Вы ведь не будете отправлять http-запрос на сервер вк, чтобы загрузить фотографию и устанавливать websocket-соединение, чтобы переписываться, верно? Все это вы делаете мышкой и клавиатурой. И фронтенд-разработчик, в том числе и разработчик фронтенда веб-приложений, кем я являюсь, создает этот самый интерфейс, чтобы вам было удобно пользоваться.

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

Есть такой стул, называется Jira. В нем есть задачи. Представьте себе список дел. Теперь, разбейте его на категории. "Можно брать в работу". "В работе". "Сделано" (Категорий больше, но для упрощения пока рассмотрим эти три). Вы берете задачу в работу, работаете и затем заканчиваете над ней работать, попутно перетягивая её карточку из этих категорий.
Базовую концепцию поняли. Теперь рассмотрим полностью, что же это за стул такой.
Статусы могут варьироваться от проекта к проекту, но, грубо говоря, выглядит все так:
"Можно брать в работу"
"В работе"
"В ревью"
"Ревью пройдено"
"Готово к тестированию"
"В тестировании"
"Сделано"

Задачи не берутся из воздуха. Их создают разработчики и бизнес-аналитики — люди, которые формулируют то, что хочет бизнес, в понятный для команды язык. Если бизнес хочет стул, то бизнес-аналитик расписывает дизайнерам, как этот стул должен выглядеть, а бекендерам и фронтендерам — как его реализовать.
Эти задачи попадают в беклог. Беклог — это большое ведро, где лежат задачи. Там лежат как новые, необработанные задачи, назовем их "Новая", так и задачи из остальных категорий. Время от времени несколько человек на проекте собираются на такой мит, называется он "груминг, и решают, что можно брать в работу, перемещая это в соответствующую категорию. Задачи, независимо от их статуса, могут разделяться на специальные категории, называемые "Эпик". Это группа задач по одной теме. Например, вы делаете интернет-магазин и реализуете функционал заказов. Все задачам, связанным с этим: для фронтов, для беков, и для дизайнеров, присваивается категория — "Заказы". И "эпик" и есть эта категория. Команда может, к примеру, поработать над одним эпиком и двигаться к следующему. Может вестись работа и над двумя, и тремя, и параллельно над задачами вне эпика вообще, например над фиксом разных багов.

Итак, вот я сажусь работать. У меня есть несколько задач в каждом статусе. Предположим, у меня есть задача в начальном статусе "Сделать страницу просмотра заказа". Давайте её откроем. Что мы там увидим? Чаще всего, две ссылки: ссылка на документацию и ссылка на дизайн. Рассмотрим их повнимательнее. Документация, если мы используем Jira, скорее всего будет написана в продукте от той же компании — Confluence. Если очень просто, то это обычный портал, где описано, как должны работать фичи, как должен работать бек и фронт. Дизайн же делается в таком инструменте как Figma. Не будем вникать в принципы его работы, по мере необходимости вы просто посмотрите первый гайд на ютубе. Скажем лишь, что фигма очень точно отражает то, как должен выглядеть фронтенд. То есть вы не смотрите на картинку и пытаетесь примерно повторить, а вам дано все: отступы, цвета, размер шрифтов, и так далее.

Описание задачи мы просмотрели. Едем дальше. У задачи есть оценка по времени. Её может ставить тимлид, её можете ставить вы сами. Она может быть как в часах, так и в сторипоинтах. Если проект адекватный, то оценка в 4 часа означает, что в идеальном мире задача, по мнению оценивающего, заняла бы 4 часа, но а) могут быть проблемы, б) оценивающий может ошибаться. Оценка на нормальных проектах происходит не для того, чтобы наказать разработчика, если он в неё не уложится, а чтобы понимать, правильно ли вообще оцениваются задачи, основываясь на том, во сколько задача была оценена и сколько времени разработчик на неё затратил. Теперь сторипоинты. Что же такое сторипоинт? Допустим, есть две задачи: сделать стул, сделать трон. Сделать стул занимает X времени, сделать трон — 10X, то есть в десять раз сложнее. А сделать стул со встроенным унитазом еще сложнее — 20X. Теперь давайте заменим X на SP — сторипоинт. Сделать стул занимает 1SP, сделать трон — 10SP, сделать трон с унитазом — 20SP. То есть сторипоинт просто показывает, насколько задача сложнее или проще других задач на проекте. Если одна задача занимает 1SP, а вторая 2SP, то, значит, вторая в два раза сложнее. А задача в 10SP сложнее вышесказанных в 10 и 5 раз соответственно.

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

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

Допустим, все хорошо, все данные есть и все детали мне известны. Приступаем к фиче. Я захожу в редактор кода и открываю терминал. В нем я переключаюсь на ветку develop. Это ветка, где лежит код, который еще не видят пользователи, но который уже написан разработчиками. Я пишу git pull, чтобы влить себе последние изменения и работать с актуальным кодом. Это очень важно сделать, поскольку может быть очень больно, когда вы сделаете фичу и обнаружите, что писали её поверх старого кода, который больше не существует. Затем я пишу git checkout -b feat/номер_задачи-order-view-page. Эта команда создаст новую ветку и сразу переместится на неё. Примерно так оформляется название ветки. Может быть по-другому, естественно.

Я её сделал. Я пишу git commit (либо, скорее, открываю коммит в редакторе кода), и указываю в сообщении коммита, что же такое я сделал. Например, я пишу "feat: order view page", где feat означает, что я сделал фичу (может быть fix — фикс, perf — улучшение производительности, ref — рефактор, и т.д. semantic commits), и order view page — страница просмотра заказа, то есть краткое описание того, что я сделал.

Что дальше? Дальше нам нужно отправить это на ревью, и вот как мы сделаем. Когда вы используете гит, вы делаете все локально. Но, если вы делали пет-проекты, вы, скорее всего, заливали их на гитхаб. Гитхаб — это не единственное место, куда можно заливать код. Есть еще такие штуки как BitBucket, GitLab, которые часто используют на коммерческих проектах. Я пушу свой код на GitLab. Помните, я создал отдельную ветку под фичу? Мы не пушили код в main или dev, ведь сначала его должны посмотреть наши коллеги.
Дальше мы открываем такую вещь, которая называется pull request или merge request. Если объяснить человеческим языком, то мы как бы "открываем запрос на merge, то есть вливание нашей фичи в dev". Мы открываем merge request в develop, да, нам надо нашу фичу туда. Заходим в Jira, и перетягиваем нашу задачу из "В работе" в "В ревью".

Затем его смотрит один или несколько наших коллег, оставляет комментарии по нашему коду. Мы их читаем, возможно спорим, делаем правки по комментариям, и получаем "одобрение", в народе называемый апрувом (от слова approve — одобрить). Это специальный индикатор на гитлабе/гитхабе/битбаккете, означающий, что наши коллеги одобрили наш merge request — MR — и мы можем вливать его в develop (помните, мы открыли запрос именно в dev). Мы его туда вливаем и перетягиваем нашу задачу в "ревью пройдено". Иногда мы можем не вливать, а подождать, пока наши коллеги получат апрувы своих фичей, и вылить сразу несколько. Это полезно, чтобы убедиться, что фичи "не мешают" друг другу, и в случае чего созвониться и вместе порешать все мёрж конфликты (когда гит не знает, чей код воткнуть в файл).

Дальше процесс может варьироваться. Допустим, в течение нескольких дней мы с вами вливаем фичи в дев. Они там накапливаются, задачи висят в "ревью пройдено". Затем, когда они накопились, мы открываем MR из dev в ветку для тестировщиков, куда заходят и тыкают тестировщики, и в ветку для разработчиков, куда могут зайти и потыкать разработчики. Мы все проверяем и мержим (вливаем) его.
Когда мы влили из develop в, скажем, dev-server и test-server (назовем их так), то запускается процесс деплоя — грубо говоря, выливания нашего кода "в свет" (для команды, не для пользователя). Запускается такой процесс, который мы назовем "пайп". Представьте себе трубу с несколькими этапами обработки. Наши фичи проходят эти этапы и, либо все проходит успешно, либо пайп падает. Если он падает, мы находим причину, в чем дело и чиним.

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

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

Перейдем к тому, как оказаться во всем этом. Когда-то я учил программирование. Я попробовал разные направления, но ресурсы, которые я использовал, были не очень хороши, а потому прогрессировал я очень медленно. И в один прекрасный момент я наткнулся на ресурс, который называется The Odin Project. Это огромный, полностью бесплатный, поддерживаемый сообществом курс, который позволяет стать фронтенд либо фулстак разработчиком. Может быть фронтенд+бекенд на javascript, может быть фронтенд на javascript + бекенд на руби.
Он проводит вас от самого начала, от основ html, до написания своей соцсети и того, как составить резюме и торговаться на собесах. Есть три секции: Foundations, Fullstack JS Path, Fullstack Ruby Path. Начать нужно с первой, Foundations. Затем вы выбираете либо руби, либо js. Я выбрал js, поэтому расскажу про него. По прохождении где-то 70% JS пути вы будете полноценным джуном-фронтендером, работающим с библиотекой React. То есть да, вам не придется мучиться с выбором фреймворка. Дальше вы, конечно, можете начать искать работу, но я советую пройти хотя бы половину идущей дальше секции по Node.js, чтобы вы научились нормально работать с бекендом на фронте (и освоить основы бека заодно).
Как все устроено:
Дано несколько уроков по теории, вы их проходите.
Делаете проект.
Повторяем так где-то 20 раз, теория и проекты становятся сложнее, вы становитесь умнее
Проходим собесы и получаем оффер.

Во всем интернете я не видел чего-то лучше, будь оно платным или бесплатным. Я не видел того, что покрыло бы настолько детально почти все, что нужно знать веб-разработчику, и дало такое огромное количество практики. А я накопал много ресурсов в процессе своего обучения.

Теперь, несколько моментов.

1. В начале говорят установить линукс, если вы на винде. Можете не ставить.
2. В середине изучения реакта начинайте самостоятельно изучать typescript и все дальнейшие проекты пишите на нем. Это маст-хев, вы обязаны его знать, если будете писать фронтенд. Документация + learntypescript.dev прекрасно подойдут
3. Если выберете JS путь, то знания по фронту у вас будут куда сильнее знаний по беку. Ищите работу на оба, но акцентируйте внимание на том, что ваш фронт будет значительно сильнее.
4. Ресурс на английском, но простом. Для свободного чтения и просмотра коротких видео нужен B1. Знаю людей, которые проходили с переводчиком, или вообще полностью переводили теорию на русский. Работало. Вот мой пост, как выучить английский и что делать на А1

Ссылка — theodinproject.com

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

Напоминаю, что другие мои посты вы можете найти в навигации

🔥 Все посты

Английский:
- Как выучить английский до С1
- Что делать на А1
- Дуолинго - плохой или хороший инструмент для изучения языка?

Айти:
- Я прошел 20 собесов на Senior React. Что у меня спрашивали и что надо отвечать
- Как применить SOLID на практике
- Детальное описание, что конкретно фронтенд-разработчик делает на работе и как выучить веб с нуля бесплатно
- Как расти, когда вы джун (и не только джун)
- Какой язык программирования выбрать новичку, или что на самом деле нужно выбирать и как выучить это ваше программирование
- Как подготовиться к собесу по ванильному js, тратя 15 минут в день
- Как выбрать ноутбук и ОС для разработки
- Заменит ли ИИ разработчиков
- Как я вкатился в айти в 18 лет на миддла после школы

Продуктивность:
- Эффективное обучение. Как быть машиной при подготовке к собесу и экзамену
- Как лучше концентрироваться

Мысли:
- Есть ли джунам место в мире, где разработка ведется с помощью нейросетей

💻 Как расти, когда вы джун

и не только джун

UPD 2026 - ребят, крутите опыт и залетайте сразу на миддла. Используйте этот пост, чтобы просто прокачиваться)

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

Первое, примите тот факт, что вы никогда не будете знать все. Никто не знает всё. Поэтому, это нормально, когда вы что-то не знаете, когда у вас что-то не получается. Даже сеньоры сталкиваются постоянно с задачами, где им что-то неизвестно. Для этого у вас есть коллеги, ментор, гугл и чатгпт. Вы учитесь чему-то именно благодаря тому, что сталкиваетесь с неизвестным и решаете эти проблемы.

Второе, примите тот факт, что ошибаться и оставлять после себя баги — это нормально. От вас ждут не чтобы вы не делали багов, а чтобы вы их за собой (и за другими) фиксили. В том числе и нормально, когда у вас большая задача и после неё осталось несколько багов. Ведь за всем уследить невозможно, верно?

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

Четвертое, не бойтесь, что вас уволят. Уволить могут в следующих случаях:
- Вы слишком, слииишком медленно делаете тикеты. Например, делаете 10 минутную правку текста 4 часа
- Вы конфликтный
- Вы совсем не выходите на связь. Вам написали утром, вы ответили вечером.
- Вы пишете отвратительный код. Вам приходится 4-5 раз править пул-реквест, у коллег горит.
- Вы оставляете после себя ломанный или вообще нерабочий функционал. Нормально - это оставить баг. Ненормально несколько раз оставить фичу, которая вообще не работает.

Если вы боитесь этого, возьмите тетрадку и ручку и оцените свои действия по каждому из пунктов. Действительно ли вы правите две буквы в тексте 4 часа? Действительно ли вы конфликтуете, а не решаете вопросы культурно? Действительно ли вы делаете нерабочие фичи или очень сильно отклонённые от требований?

Пятое, у вас должен быть крутой ментор. Если вам такого дала компания — хорошо. Если нет — найдите в интернете или среди знакомых. Но иметь хорошего ментора мало. Нужно уметь выжимать из него все. Когда я был джуном, я в течение дня записывал все вопросы, что у меня возникли, и каждый день утром вываливал их своему ментору. Мы сидели почти час и разбирали их. Вам нужен такой же ментор и такая же тактика. Со временем вопросов станет меньше, и тогда такие сессии можно устраивать реже.

Шестое, вам должны платить как минимум 500$. Если вам платят 200$, меняйте работу. Это зарплата стажера, который может даже не сидеть на проекте. Джун же приносит пользу, делая задачи, нормальные для него по сложности.
продолжение ниже

Седьмое. Учите английский. Это позволит вам работать в аутсорс компаниях и просить там больше денег и быть более желанным, плюс позволит работать на валютной удаленке или вообще переехать в другую страну. Как выучить английский с B1 до C1, и что делать на A1

Восьмое. Вы становитесь мидлом, решая неизвестные задачи, разбираясь с ними и узнавая таким образом что-то новое. Плюс вы совершаете ошибки, исправляете их и снова учитесь. Есть дополнительный стул, который ускорит ваш рост до мидла.
1. Гуглите паттерны, присущие вашему фреймворку и вашему направлению. Например, если вы пишете фронтенд на реакте, гуглите React patterns, оптимизацию производительности, веб-метрик. Если вы пишете на джаве, гуглите паттерны проектирования и их применение в спринг.
2. Изучите досконально документацию своего фреймворка.
3. Изучите самые-самые основы алгоритмов и структур данных. Нет, вам не нужно помнить, как написать сортировку. Просто знайте, что такое О большое, почему два цикла это O(n^2), как работает стек и как работает очередь. Эти вещи пригодятся, остальное нет (может что-то забыл, но это большинство)
4. Пройдите этот материал по SOLID. Он объясняет, как применять его на практике. Это позволит вам вместо совершения ошибок и набивания шишек сразу понять, как делать правильно.
5. Просите задачи посложнее. Не надо сразу просить сделать супер-сложный компонент. Поговорите с вашим тимлидом, попросите его давать вам задачи чуть-чуть сложнее, чем те, что вы делаете сейчас. Так он будет спокоен, что вы способны их сделать, а вы действительно будете способны их сделать, причем нормально. И так повторяйте раз в 1-2 месяца. Таким образом, сложность ваших задач будет возрастать, и соответственно скилл решения проблем будет становиться лучше вместе с ней.

Девятое. Пройдитесь по вакансиям (на все уровни) и узнайте, каких технологий хочет рынок. Может, вам стоит сделать пет-проект на Next.js и настроить гугл-аналитику, если вы на своем рабочем проекте с этим не занимаетесь, а видете это в каждой четвертой вакансии?

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

Напоминаю, что другие мои посты вы можете найти в навигации

💻 Какой язык программирования выбрать новичку,
или что на самом деле нужно выбирать и как выучить это ваше программирование

Допустим, вы хотите изучить программирование. Первый вопрос, который, скорее всего, лезет вам в голову, это "А какой язык учить?". Возможно даже, вы идете смотреть список популярности языков, натыкаетесь на несколько из них и приходите в недоумение, увидев, что в одном списке на первом месте JavaScript, а в другом Python.

Итак. Чтобы решить проблему, нам нужно сначала поставить задачу. И постановка задачи в виде "какой язык учить" категорически неверна. Не важно, знаете вы Python, JavaScript, Rust, или что-то еще: если вы знаете только язык, но не технологии, используемые при разработке чего-то, то ваши знания для потенциального работодателя не совсем то, что он хочет. Его в первую очередь будут интересовать не ваши скиллы в написании консольного приложение калькулятора, сделанного с помощью алгоритма польской нотации и функции вычислять производную, если вы знаете только язык. Его будет интересовать, можете ли вы принести деньги. Почему? Представьте себе, что вам дают на выбор воспользоваться консольным калькулятором и калькулятором с интерфейсом. Какой из них вы выберете? Какой из них, по вашему мнению, выберет большинство людей? Тот, что с интерфейсом. Точно так же рассуждает и работодатель. Он видит разработчика, способного написать консольный калькулятор, и разработчика, способного написать калькулятор, работающий с интерфейсом в браузере и разместить его в интернете, Как думаете, кого он выберет? Какой калькулятор принесет больше пользователей и, соответственно, больше денег (допустим, что за определенные фичи у калькулятора, скажем, вычисление производной, нужно заплатить. Да, еще второй разработчик может сделать удобный интерфейс оплаты)

К чему я веду? Знание языка без знания технологий, которые с ним используются, для джуновской позиции недостаточно. Исключения — new grads в FAANG компаниях и возможность пойти на стажировку в крутую компанию. И, если вы пойдете на стажировку, вас все равно заставят учить технологии и вы не будете писать чисто на языке без дополнительных вещей.

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

Поэтому, если вы хотите делать деньги, то вопрос стоит поставить не как "Какой язык программирования выбрать", а сделать шаг дальше и спросить себя: "Как мне изучать разработку?". Или, более конкретно, "Как мне стать разработчиком?".

Перед тем, как пойдем дальше. Еще раз. Программировать — писать код и решать какие-то задачи. Быть разработчиком — приносить деньги компании и себе, делая задачи. Заметьте, я не выделяю в разработчике написание кода, ведь это не единственное, чем он занимается. Когда вы выбираете библиотеку, чтобы не писать много кода, не изобретать велосипед и сохранить время бизнесу, вы не пишете код, но перед вами стоит какая-то задача, и вы занимаетесь её решением. Вы находитесь в той точке решения, где вам не нужно писать код. Затем вы ставите эту библиотеку и пишете код. А потом вдобавок идете к бизнес-аналитикам уточнять требования, ибо что-то не понимаете.

продолжение ниже

Теперь перейдем к тому, как ответить на наш новый вопрос, "Как мне стать разработчиком?".
Часто я вижу советы спросить себя после этого "Какие направления разработки мне интересны?". Окей, допустим, вам интересна тема всяких железяк, написания кода под них, чтобы они работали. Вы начинаете изучать, как писать код для железяк, делаете это пару месяцев и вот вы считаете, что можете искать работу. Вы заходите на сайт с вакансиями и обнаруживаете, что все вакансии требуют только сеньоров с опытом работы с огромным количеством технологий. Даже если вы нарисуете опыт в резюме, у вас уйдет огромное количество времени, чтобы выучить все эти вещи, многие из которых потребуют от вас покупки железа, под которое вы будете программировать, построение имитации реальной системы, настройку её инфраструктуры и прочее и прочее. В конечном счете вы придете к своей цели и получите работу. И, скорее всего, её вывезете. Но потратите вы на это очень много времени.

Напрашивается вопрос, который на самом деле стоит задать себе следующим. "Какие направления разработки сейчас востребованы, чтобы у меня получилось найти работу, действуя рационально и не прикладывая при этом нечеловеческих усилий?". Усилия придется прикладывать, но они должны быть, скажем, человеческими. То есть, чтобы как в примере выше, вам не пришлось сетапить систему из hardware целой организации у себя в комнате, лишь бы научиться тому, что требуют вакансии.

Допустим, мы ответим на этот вопрос так, руководствуясь первой ссылкой из гугла:
1. Веб-разработчик
2. Тестировщик
3. Мобильный разработчик
4. Разработчик игр

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

Как выбрать? Тут есть несколько стульев. Сначала мы спрашиваем себя: "Меня что-нибудь из этого интересует? Если да, то что больше всего?".
Если одинаково интересно несколько вещей, выбираем рандомно.
Если нет какой-то тяги к чему-то еще, выбираем рандомно.
Да, сразу скажу, вам не обязательно должна нравиться своя работа. Даже если вы выберете направление, которым вы горите, то будьте готовы к тому, что 70% работы разработчика состоит из рутинных задач.
Поэтому, если нет фаворита, выбираем рандомно

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

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

Поэтому вы должны глазами пробежаться по поднаправлениям в выбранной вами сфере и решить, какое выбрать. Опираемся на логику из предыдущего вопроса. Мы выбрали веб-разработчика. Скажем, тянет делать интерфейсы? Берите фронтенд. Совсем не хотите делать интерфейсы или знаете джаву/питон/что-то еще для бекенда и слышали, что оно там юзается? Берите бекенд.
Не знаете, что выбрать? Выберите рандомно или вообще не выбирайте.

Последнюю фразу мне стоит объяснить, но для этого нам стоит пойти дальше. Представим, что вы или выбрали, или не выбрали поднаправление. Если вы его не выбрали, то это не страшно. Ваш следующий шаг — это найти хороший обучающий материал по выбранной сфере (напоминаю, сфера — то, что я называл направлением выше. веб, мобилки, и т.д.)
Как найти хороший обучающий материал? При поиске стоит опираться на следующее. Если он не подходит хотя бы по одному из пунктов, выбрасываем его и ищем дальше:

продолжение ниже

1. Материал покрывает больше, чем просто язык программирования. Что еще он должен покрывать? Технологии. Если мы выбрали веб-разработку, то он должен не только объяснять язык, но и детально покрывать, скажем, какой-нибудь фреймворк, объяснять как работает веб,
2. Материал имеет хорошую теорию, написанную текстом либо предоставленной в виде коротких (не больше ~15-20 минут) видео. Если он состоит из 2 часовых лекций или, прости господи, вебинаров, то вы должны его выбрасить. Почему?
- Такой контент в половине случаев состоит из воды
- Если он не состоит из воды или состоит из воды, вам будет сложно его употребить, поскольку вы вряд ли сможете усвоить кучу информации за 2 часовую лекцию, особенно если в ней нет воды. Обучение состоит из итерации в виде "выучил теорию - попрактиковался, выучил теорию - попрактиковался". Вы не сможете попрактиковаться, употребив в себя 2 часа материала, даже если вы все поняли.
3. Практика. После нескольких уроков по теории (скажем, нескольких статей или нескольких 5-20 минутных видео) у вас должен быть проект. У вас должен быть не тест, не упражнения, а проект. Даже если все, что вы можете после прохождения первых уроков — это написать консольное приложение, то этим проектом как раз и должно быть консольное приложение. Да, в определенных случаях могут быть полезны упражнения. Если они есть — это плюс. Если они единственная практика — это плохой материал для обучения. То есть, в идеале, чтобы были и проекты, и упражнения на отработку каких-то скользких моментов. Важно. Этот проект вы должны делать сами, а не смотреть видео и повторять за учителем. Вам должны дать задачу, например, "сделать такой-то проект, в нем есть фичи A, B, C, D и при желании можно сделать E". Как делать — вы должны решить сами. Если вы столкнулись с проблемами, то вы гуглите. Если вдруг есть ментор, гуглите и потом просите помощь у него, если не нагуглили.
4. Сложность, размер проектов и время, что нужно на них потратить, должны возрастать по мере вашего прогресса. Вы не будете делать мини-проекты в виде крестиков-ноликов на работе. Чем дальше вы прогрессируете, тем больше вы должны приближаться к реальным проектам. А реальные проекты большие, куда больше чем многие обучающие и пет-проекты. Соответственно, под конец вы должны делать проекты наподобие создания, скажем, соцсети.

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

И все. Проходите этот материал от начала до конца, и тратьте на него не менее 2,5 часов в день каждый день (можно брать 1-2 выходных). Можете поставить таймер помодоро на час и перерыв на 10 минут. Так вы не будете терять концентрацию, я так и выучил весь веб. Почему не менее 2.5 часов и каждый день? Потому что если будет меньше, вы будете прогрессировать очень, очень медленно. Почему каждый день? Потому что если вы выучили что-то сегодня, то чем быстрее вы это отпрактикуете, тем лучше. То есть, вы быстрее перейдете от теории к проекту. Если вы уже пишете проект, то каждодневные занятия помогут вам оставаться в контексте.
Я должен признать, что брать выходные все-таки желательно. Иногда вы можете быть перегружены делами, задачами на теперешней не айтишной работе, проблемами. Энергии может просто не быть. Если у вы чувствуете, что обучение начинает вызывать тревогу или становится дурно, это не значит, что вам не дано. Вы просто можете схватить выгорание, и стоит взять 1-2 дня на полный отдых. Полный, то есть очень желательно отдохнуть вообще от всего и почиллить.

продолжение ниже

Я затронул тему "не дано". Нет, дано. Есть люди, которые имеют определенный набор генов и бекграунд из детства, и, может, им лучше дается обучаемость. Есть одаренные. Есть обычные люди, таких абсолютное большинство. Но нет обычных людей, которые не могли бы освоить программирование. Да, разве что если отвращает от компьютеров, то не стоило сюда и лезть изначально. Не нужно даже быть полностью ментально здоровым: я изучил весь веб с серьезным тревожным расстройством. Вам не дано только если вы не способны мыслить. Если вы способны мыслить, но у вас не получается решить задачу или понять что-то, это значит не то, что вам не дано, а то, что вам надо встать, походить 10 минут и попить чай.

Какие еще есть ред флаги при выборе обучающего материала?
1. Агрессивный маркетинг. Если вам во все уши трещат, что вы будете зарабатывать 3000$, жить на Бали, работая из кафе с дорогим макбуком, то я бы обходил такое стороной. Скорее всего, это инфоцыгане. Это все построено на обещаниях, которых много, а конкретики о материале никакой. Если же обещаний не так много и написано, как именно проходят занятия (тут проверяем, норм ли это формат для нас, руководствуясь тем, что выше), что именно будет изучено (а вы должны сравнить это с вакансиями и посмотреть, покрывает ли курс 80-90% того, что просят), есть ли ментор, то это можно рассмотреть. В таких ситуациях копайте глубже, найдите людей, которые прошли этот материал. Узнайте, как они устраивались, помогли ли им в этом руководители курса, нашли ли они работу вообще, много ли им пришлось изучать самостоятельно (хорошо, когда немного. плохо, когда много)
2. Он старый и не обновляется. Иногда курсы могут выдать как что-то вроде "Complete Python Developer in 2023", хотя записан он был в 2018 году (реальный кейс). Если материал внутри него обновляется с каждым годом — ок. Если это курс по языку — ок. Если это курс по фреймворку — не ок. Найдите людей, прошедших его и лично спросите их, в каком году они проходили курс. Можете не искать и просто посмотрите отзывы. Если есть отзывы пару лет назад, то стоит задуматься. Здесь, в силу отсутствия экспертизы, вы можете не знать, рассказывают ли об актуальных технологиях в курсе, поэтому вы не можете понять, обновлялся ли он. Поэтому если это язык и курс не древний, то все ок. Если это фреймворк, какая-то технология, то лучше найти что-то другое, ибо, опять же, его могли не обновлять.

Какие есть ошибки мышления при выборе обучающего материала?
- Думать, что платные курсы лучше бесплатных. Чаще всего они одинаковые, и хороший материал нужно уметь найти, будь он платным или бесплатным.
- Стремиться пройти как можно больше курсов и изучить как можно больше всего. Здесь есть ошибка, которую совершал я много раз, уже став разработчиков и находясь в поиске путей развития. Я строил сложные планы того, как и в каком порядке я буду учить то, это, третье. Это так не работает. Проблема в том, что когда вы только начинаете учиться, вы не можете знать, как именно и в каком порядке, и вообще что на самом деле вам нужно изучить. Максимум, что вы можете — это открыть 10 сайтов по поводу того, что нужно знать, чтобы стать разработчиком в своей сфере, и найти среднее арифметическое между тем, что они пишут.

Что делать, если нет материала, покрывающего всё сразу и подходящего под все пункты (нет возможности купить или нет нормального в принципе)
Если его нет, сделаем его сами, вот как:

продолжение ниже

1. Гуглим, что нужно изучить в вашей сфере, чтобы стать разработчиком
2. Находим среднее арифметическое между тем, что написали
3. Если в среднем арифметическом оказались алгоритмы и структуры данных, выкидываем и заменяем на "что такое О большое, как работают основные структуры данных". Вам не нужно знать quick sort, чтобы быть разработчиком. К тому же, как только вы перестанете повторять, вы забудете. А вот что такое стек и очередь (структуры данных) знать надо, это вам понадобится.
4. У вас должно получиться минимум пунктов 20, вы должны покрыть все реально нужные разработчику темы. Вероятность "реально нужное" возрастает благодаря тому, что мы берем среднее арифметическое. У ChatGPT не советую спрашивать, он напишет слишком мало.
5. Гуглим обучающий материал по каждой теме. После каждой темы делаем себе проект. Идеи для проектов все так же гуглим. Если вы в начале, гуглим маленькие проекты для начинающих. В середине — средние. В конце — большие, как пример соцсеть, если это веб
Материал можно брать и платный, и бесплатный. Важно, чтобы выполнялись пункты выше, кроме пункта с проектом. Проект вы должны делать сами. Если в обучающем материале делается какой-то проект — ок, вы его делаете, повторяя за инструкциями, но после этого делаете что-то похожее, но другое, самостоятельно, притом ставя себе задачу сделать какие-то конкретные фичи.

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

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

Бесплатный и просто прекрасный стул.

Если коротко, то тут вы можете стать либо javascript-разработчиком, либо ruby-разработчиком.
Да, часто говорят язык+разработчик, но под этим подразумевают что-то конкретное. Под javascript-разработчик понимается либо фронтендер, либо бекендер на ноде, либо фулстак на том и другом. Под ruby-разработчиком понимается бекендер на ruby.

Состоит из курсов:
1. Foundations, это основы, с них надо начать
2. Fullstack JS. Будет фулстак с сильным уклоном во фронтенд.
3. Fullstack Ruby. Я не знаю, не могу пояснить, на свой страх и риск. Знаю только, что по руби куда меньше вакансий, чем по js.

После прохождения Foundations нужно выбрать путь. Я искренне советую выбрать fullstack js. В конце идет секция по бекенду, пройдя её на процентов 70 вы можете начинать искать работу фронтом. Я могу поручиться за этот вариант, потому что сам его выбрал и он действительно качественный.

По времени у меня заняло 4-7 часов каждый день в течение 6 месяцев. Я прошел на 90%, дальше меня взяли в компанию.

Он подходит под все критерии нужного нам материала и не имеет красных флагов.

Поэтому, если хотите выучить программирование, то предлагаю не думать и сразу шагать на theodinproject.com

Если есть деньги, то купите себе регулярные консультации у ментора со стеком React+Node.js и организуйте с ним ревью вашего кода.

Если хотите мобилки, но не хотите искать самостоятельно материал в самом начале обучения, то сможете перекатиться из веба в React Native, используя те знания, что получите на ресурсе.

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

Напоминаю, что другие мои посты вы можете найти в навигации