Эти ваши IT⁠⁠

В hr. На самом деле у меня есть сокурсники с курсов Яндекса, где учился, и один работал в газете репортером, другая менеджером по закупкам и тд. Сейчас они джуны в разных компаниях Главное чтоб глаза горели, а остальное придёт.

Вы сейчас только не смейтесь, но у вас прямо классическая "ошибка выжившего" :)))

Вы не только догадываетесь о существовании всей этой хрени (часто достаточно знать, что такое бывает и начать искать), но ещё и знаете... и считаете, что не пользуетесь.

Попробую по порядку (но я институт заканчивал 20 лет назад, у нас было немного по другому):

Матан? Дифуры? Операционка?

Из вышки мне за всё время понадобилось преобразование фурье (и то для pet-проекта), интегралы, дифференциалы, работа с матрицами, немного из статистики и теория игр (она вообще в жизни оказывается крайне полезной, её бы в школе надо давать).

Алгоритмы?

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

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

Ещё что-то у нас было из алгоритмов, но это уже мелочи.

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

Сети? А сколько раз обычный разраб сталкивается с протоколами ниже прикладного и транспортного уровней? Вообще, много таких, кто назовет состояния TCP-сеанса?

А вот тут - заблуждение.

Разрабов, которые уверены, что "ну я вот тут сделал tcp.connect() и дальше передаю данные" пруд пруди (хорошо если tcp, могут и  к udp также относиться). Они не понимают, что вообще-то сеть ненадёжна и не даёт никаких гарантий, у неё есть latency, не знают про jitter, потери пакетов (tcp, конечно, поможет, но попытки переповтора могут занять и 100ms и 10s), буфера.

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

В итоге web сервер по таймауту рубит соединение (у нас стояло 60 секунд), а эти ящеры через 30 минут обнаруживают "unexpected end of file".

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

С TCP State'ами тоже бывают занятные приколы, когда приложуха открывает-закрывает тонны запросов, а потом на пустом месте попадает на лимит по открытым файлам (угу, у нас же сокет занят пока соединение в FIN_WAIT).

Оси даже не расписываю. Из несистемников там никто даже приблизительного отличия процесса от потока не скажет.

Это вы прям совсем загнули.

Начиная с того, что "стоимость" запуска процесса и потока отличается буквально на порядок (запустите 20k тредов и 20k процессов - будет очень показательно).

Если вы пишите только однопоточные приложения, то да - разницы никакой. Если же начинаете оперировать даже сотнями потоков, то всё это просто обязательно знать. А чуть позже подойдёт понимание, что запуск потока - это тоже крайне дорогая операция и начнёте смотреть в сторону "зелёных потоков", которые обходятся намного дешевле. А тут рядом уже может оказаться и необходимость писать на другом языке - к примеру, в Golang "потоки" (горутины) практически бесплатны на фоне потоков Java, но ограничены по количеству (начиная с единиц миллионов уже начинаются вопросы), а в Erlang они буквально совсем бесплатны, но осознать красоту и одновременно наркоманию Erlang'а дано не каждому.

Про архитектуру даже не говорю: без практики ты просто не будешь это понимать за ненадобностью.

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

Если же вы вообще не догадываетесь, что такое существует - да, будет плохо.

Так что там за фундамент то такой? Я тут просто унтер из нижайшего IT. Может, сейчас пойму, что мне дальше учить, так как взлечу в высоты сеньорского мастерства.

Уже почти ничего и не надо - есть базовое понимание многих вещей, остальное уже только на практике :)))

И отдельный момент - курс по базам данных был тоже ОЧЕНЬ полезен.

Вот та тупая фигня с "нормальными формами" БД по факту оказалось никакой не фигнёй, а очень нужной штукой.

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

p.s. На всякий случай - я _не_ разработчик по основной области деятельности :))

Да хуйня это все, у меня за плечами прикладная математика и магистратура со специализацией в AI, для работы вебмакакой с зп до 10к$ это не надо

разве что обучение всей этой залупе нейронов посоздавало, но я за последние 2 года их уже все проебал :)

Ага, кругом фундамент-фундамент.

Если послушать говорящих про машинное обучение, то там нужна математика-математика, прям ух.

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

Может, так не во всех сферах ML (он занимается решением бизнес-задач, а, не, к примеру, картинками или беспилотными авто), но факт остаётся фактом - можно быть в машинном обучении топовым специалистом и почти не знать высшую математику.

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

Оговорюсь сразу что любое мнение по данной теме субъективно.

Под математикой думаю в основном имеют ввиду не столько матан, сколько дискретку (все же курсы в основном о мобильной разработке и вебе)

Алгоритмы и структуры нужны сами по себе. На практике всего один раз merge sort реализовывал руками, да. Но не зная базовых алгоритмов сортировки, обхода графов идт много хуже представляешь как работают инструменты которыми пользуешься.

Условно сделать индекс в mysql можно не зная ничего, включая сам синтаксис запросов. Но понимание что индекс это b-tree* позволяет делать их эффективнее и быстрее переходить между стеками.

Более практический пример из фронта.

Можно научиться на курсах делать морды на react и не знать нормально js. До какого то придела/на каких то задачах этого будет хватать. Но любой отход от темы и ты идешь искать решения в гугле. Новый инструмент выходит и ты учишь его с нуля.

При этом понимание работы event loop, жизненного цикла событий и общего принципа того как работает virtual dom позволит переходить между стеками быстро и безболезненно.

Что такое react - это virtual dom. Ты через plain объекты пишешь шаблон (jsx развернется в обычный js состоящий из вложенных структур с мета информацией). При каждом изменении состояния компонента строится новое дерево и сравнивается с предыдущим. Разница между деревьями добавляется в реальный dom. Т

.к. diff 2 деревьев это O(n^3), что дорого, react делает не глубокое сравнение, что тянет за собой использование атрибута key в перечислениях. По сути если на одном уровне вложенности у тебя div меняется на span, то на этом сравнение закончится и все поддерево будет считаться несовпавшим и будет размонтированно.

На document регистрируется один обработчик который перехватывает все события и уже внутри обрабатывет  "виртуальное" всплытие, что важно при использовании таких вещей как portal. Portal позволяет добавить компонент в реальный dom в одном месте, а виртуальый в другом. Например всплывающее окно находится по пути body >div.main, а в реальном по пути body >div.dialog, что повлияет на всплытие событий. Без эмуляции перехватить событие на div.main не получится.

Если используем mobx для сторов, то важно понимать что реактивность там работает благодаря Proxy API. Мы перехватываем чтение и запись в свойства объекта стора. При чтении выполняется код, который запоминает компоненты, из которых был вызов. При записи в свойство мы достаем связку свойство + компоненты и вызываем рендор только этих компонентов.

Зная подобные особенности инструментов не нужно переучиваться с нуля при переходе с react скажем на vue. Там так же будет virtual dom, реактивность и вот это все.

В программировании часто меняются именно инструменты, но не базовые алгоритмы и паттерны.

Cassanda db относительно новая база, но lsm на котором она построена придуман в 70-х. Чем меньше ты знаешь базы, тем больше нужно учиться и тем больше будет проблем при изменении инструментов/задач. А они как уже говорил меняются крайне часто.

Я закончил МГУ, знаю и математику на нормальном уровне, и программирование. Никогда мне вся эта хрень не пригождалась. МГУ даёт две вещи:

1. Знакомство с умными ребятами, с которыми ты по-любому в будущем будешь пересекаться. Это самое главное.

2. Хорошая тренировка для мозгов. Математика бесполезна, но тип мышления, нужный для программирования, она вырабатывает.

Ничего, непосредственно нужного для программирования, в МГУ нет. Ну вру, было, конечно, паскаль, лисп, пролог. Это всё любопытно и где-то полезно. Но на практике лучше начать с жаваскрипта и им же и закончить. Ещё был курс баз данных с основами SQL. Там была куча математической подоплёки, всякие нормальные до усрачки формы. Вот если из всего этого выжать 10% сути, применяемой на практике, вот примерно это дал универ. Из 5 лет - условно 5 месяцев.

Ругать не буду и кто хочет поступать в хороший университет - отговаривать не буду. Но кто не хочет - вы не многое теряете. И если, пока один студент учит диффуры и историю философии, вы будете учить JS и работать джуниором, то скорей всего через 5 лет вы будете мидом, готовящимся идти в синоры, а студент будет драться с выпускниками курсов за право работать джуниором и проходить у вас собеседование.

Алгоритмы?

Да, так как, не зная их, намного сложнее понимать, как работает ПО. И, без этого понимания, сложнее писать свой эффективный код.

А вот про многопоточные алгоритмы кто вообще чего знает?

Вообще, много таких, кто назовет состояния TCP-сеанса?

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

Из несистемников там никто даже приблизительного отличия процесса от потока не скажет.

Я вот помню только, что процесс

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

без практики ты просто не будешь это понимать за ненадобностью

Так что там за фундамент то такой?

Если ты не можешь более-менее быстро ответить, почему база данных использует B* деревья, а не красно-черные, то надо копить на фундамент. А, без этих знаний, тебе сложнее будет выбрать хранилище для сложной задачи.

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

Нет