Comments 58
Более современные низкоуровневые языки это Rust и Go.
Go - высокоуровневый язык.
Ну если сравнивать Go и Java, то Go все-таки можно считать более низкоуровневым, как мне кажется. А так конечно, по сравнению с машинным кодом все языки это языки высокого уровня.
есть очень простой критерий "низко-уровневости": вставки на ассемблере можно писать или целые функции? Если можно, то язык низкоуровневый, по моему вполне логично.
Низкоуровневые и высокоуровневые языки отличает уровень абстракции.
Низкоуровневые языки позволяют писать код, используя только машинные команды для его аллокации и выполнения. То есть, это языки, которые позволяют работать напрямую с устройством выполнения, посредством команд.
Высокоуровневые языки обладают набором инструментов в компиляторах и интерпретаторах, которые позволяют вынести процесс написания машинных команд для часто встречающихся абстракций, под капот. То есть, предлагают абстракции, которые позволяют писать более человекочитаемый код. Например, если вам не нужно выделять вручную область памяти для инкапсуляции, а достаточно просто написать class или struct, определив в нëм области видимости свойств и методов, то это абстракция над машинным кодом. Аналогично, абстрагированию поддаются монады, полиморфизм, реализация структур данных и т.д..
Высокий или низкий уровень языка определяется не просто вставками на ассемблере, а общим стилем написания кода. Либо код, в большей степени, построен на использовании абстракций, либо предлагает выполнять машинные команды для управления устройством исполнения. Так-то, теоретически, мы можем сделать расширение для любого высокоуровнего языка, чтобы на нëм можно было напрямую выполнять машинные команды. Но это не сделает язык низкоуровневым, поскольку, он, так или иначе, будет иметь большой стек абстракций, позволяющих уйти от написания машинных команд в любой момент времени.
По каким критериям Java, по вашему, более высокоуровневый, чем Go? Для меня это одно и то же.
Например, Java компилируется в байт-код, а Go в машинный. Java запускается в виртуальной машине, которая запускается на процессоре, а Go сразу на процессоре. У Java есть дополнительный уровень абстракции над железом.
Промежуточный код в CLR и JVM - это только один из множества способов абстракции. В Go есть похожий слой в виде встроенного в бинарь рантайма. Один и тот же код по прежнему работает на всех платформах. Никто не работает с системными потоками напрямую, не управляет памятью руками, не вдается в подробности реализации fs. В некоторых случаях по типу работы с конкурентностью, по уровню абстракции его можно поставить выше Python и Kotlin.
Реляционную теорию знать не нужно
...Физику знать не нужно.
...Математику подробно знать не нужно.
Ничего знать не нужно...
Программирование знать нужно)
Программирование бывает разное. Может вебщикам на "пыхе" клепающим CMS-ки для сайтиков интернет магазинов и достаточно знать таблицу умножения, я не знаю, бесконечно далек от веба, не интересно. Но программирование не ограничивается сайтиками и php, там есть масса отраслей, где и физику и математику знать надо.
И вообще - программирование это скорее не сколько наука, сколько ремесло. А любое ремесло, опирается на фундаментальные основы той предметной области, в которой используется.
Я же не сказал, что таких отраслей вообще нет, я описал ситуацию в среднем. Понятно, что всегда можно найти исключения, все знают, что есть NASA, и там физика для программ нужна, и т.д. Просто даже если все будут знать физику и математику, то столько программистов таким отраслям все равно не нужно, и большинство будет работать в других. Будет неплохо, если вы поделитесь описанием, где это требуется, и что именно надо знать.
Идеальный скилл-сэт для продавца Пятëрочки.
З.Ы. это при том, что я, не имея высшего образования, ориентируюсь в области принципов построения реляционных БД, физики, математическом анализе. А вы приходите в ВУЗ и учите тому, что ничего из этого знать не нужно! Так может, следуя вашей логике, следует закрыть факультеты, которые готовят программистов? А то, смотрю, вузовские разработчики в последнее время лавируют между "институт даëт хорошую базу" и "я учу своих студентов, что математику знать не нужно".
это при том, что я, не имея высшего образования
То есть вы в вузе это не изучали, и это не помешало вам работать программистом и изучить это всё по ходу дела, при приеме на работу у вас этих знаний не требовали. Это только подтверждает мои слова.
ориентируюсь в области принципов построения реляционных БД, физики, математическом анализе
Ну так разговор же не о том, в чем вы ориентируетесь, а о том, как часто вы используете эти знания в работе программистом.
"Ориентироваться в области" и "хорошо знать" это все-таки не одно и то же. В статье я указывал примеры, что нужно знать, чтобы ориентироваться в области.
Так может, следуя вашей логике, следует закрыть факультеты, которые готовят программистов?
Это не моя логика. Если честно, я не вижу логики в утверждении "Программистам физика обычно в работе не требуется, значит надо закрыть факультеты, которые готовят программистов".
То есть вы в вузе это не изучали, и это не помешало вам работать программистом
Не совсем так. Это не мешает начать кодить. Однако, без этих знаний вы не будете программистом. Только кодером.
Ну так разговор же не о том, в чем вы ориентируетесь, а о том, как часто вы используете эти знания в работе программистом.
Кроме физики, остальные знания используются довольно часто. Несколько раз в день. Реляционная теория нужна для проектирования таблиц БД с учëтом нормализации и оптимизации выборки. Математика, в той или иной мере, используется при выборе алгоритмов. Есть огромная разница между человеком, который может прокрутить в голове различные параметры качества выбранного алгоритма, или оценить применимость выбранной структуры данных, и человеком, который не может этого сделать.
Что же касается физики, то, как минимум, понимать принцип работы компьютерного железа, человек обязан. Трудно работать с программистом, который считает, что в ОЗУ сидят волшебные феи, которые запоминают целые слова и картинки. Не так ли?
Если честно, я не вижу логики в утверждении "Программистам физика обычно в работе не требуется, значит надо закрыть факультеты, которые готовят программистов".
Видимо, это связано с вашими утверждениями о том, что математика программистам не нужна. Поскольку, следуя вашему повествованию, получается, что вы ходите в ВУЗ, чтобы рассказать студентам о том, что они получают там бесполезные знания. Хотя, по сути, можно найти кучу примеров, когда простейшие знания математики или теории реляционной модели данных позволяют быстро и эффективно найти решение задачи.
Я знаю как работает ОЗУ но за все время работы програмистом все что мне понадобилось узнать это обший обьем этой самой ОЗУ . Если бы я думал что для программы не хватает фей чтоб ее обслужить и надо или добавить коробочку фей или оптимизироваь программу то ничего бы не поменялось.
Ну теперь кафедры физики и схемотехники можно смело распускать. Наконец-таки в древнем споре поставлена точка! Человеку из интернета не понадобилось знание о том, как работает ОЗУ! Это явно доказывает, что знание это лишнее, и его можно не знать.
схемотехника и програмирование немного разные вещи. зачем закрывать кафедры непонятно .пусть выпускают физиков и схемотехников. вопрос зачем это надо програмистам остается открытым. математику сюда приплетать надо только в случае если переобучаются математики. ДЛя того чтоб вырастить програмистов достаточно програмисткой фигни и доп нагрузки в виде устройства компа и истории кпсс добавлять не надо
вопрос зачем это надо програмистам остается открытым
Обоснование вида "мне не пригодилось, значит никому не надо" просто антинаучно
ДЛя того чтоб вырастить програмистов достаточно програмисткой фигни
Много ли вы вырастили программистов? Каковы их успехи? Откуда вы тогда знаете, чего достаточно для того, чтоб их вырастить?
вот 5-го обучаю. 4 предыдущих успешно работают мидлами. затыки случаются но достаточно сказать как гуглить проблему или скинуть особо удачную статью на эту тему. я понимаю что часть знаний у них на уровне магии но и я не очень понимаю как устроен процессор . мне достаточно что если я его прошу поделить 2 числа то он возвращает правильный результат . а как там это происходит внутри него мне не важно
доп нагрузки в виде устройства компа
Возможно это снова вопрос определений, что именно такое "устройство компа". Но архитектура ЭВМ и ассемблер нужны чтобы лучше понимать код. По моему опыту люди без таких знаний не понимают указатели и кодировки строк. Реальный пример из жизни - чел читает строку из файла, там крокозябры, полнейший ступор, решение типа "посмотри какая кодировка и укажи явно при вызове функции" не понимает, что делать не знает в принципе, вообще глухо.
Однако, без этих знаний вы не будете программистом.
Мы будем таким же программистом, как и вы, и точно так же узнаем их во время работы.
Реляционная теория нужна для проектирования таблиц БД с учëтом нормализации и оптимизации выборки.
По моему опыту это всегда была логическая связь и техническая необходимость. Я не знаю на память теоретические определения нормальных форм, и в работе это не требуется.
Математика, в той или иной мере, используется при выборе алгоритмов.
Ну я вот выбираю алгоритм "Оплатить заказ, отправить пользователю письмо о заказе" или "Отправить пользователю письмо о заказе, оплатить заказ". Как мне математика в этом поможет?
как минимум, понимать принцип работы компьютерного железа, человек обязан
Обычно это более высокоуровневые знания, чем университетский курс физики.
Не так ли?
Да нет, если в работе это не мешает. В разговорах обычно подразумевают, что данные записываются в оперативную память, без деталей как именно это происходит. Пусть и феями. Это и называется "абстракция")
В случае чего говорим "Да ты что, какие феи, там ячейки памяти, которые подпитываются электричеством, данные состоят из 0 и 1, и в ячейках это задается как "есть заряд" и "нет заряда"". Если он это не понял, значит он плохой программист.
что вы ходите в ВУЗ, чтобы рассказать студентам о том, что они получают там бесполезные знания
Я не хожу в вуз, это была идея, которая никогда не случилась на практике. И да, некоторые знания бесполезны. Но процесс получения некоторых знаний небесполезен.
Хотя, по сути, можно найти кучу примеров
Хорошее замечание, давайте обсудим. Приведите пожалуйста несколько примеров.
Ну я вот выбираю алгоритм "Оплатить заказ, отправить пользователю письмо о заказе" или "Отправить пользователю письмо о заказе, оплатить заказ". Как мне математика в этом поможет?
Как в том анекдоте: если бы этот дуб умел говорить, Наташа, он бы сказал, что он - тополь.
Математика здесь вам поможет понять, что обозначенный вами юз-кейс не является алгоритмом в контексте написания программирования. Программисты под "алгоритмами" понимают последовательность операций в коде для получения требуемых значений. Например, результатов поиска, ближайших адресов или отсортированного списка.
У слова "алгоритм" есть общепринятое определение, это порядок действий для решения задачи.
"Cовокупность точно заданных правил решения некоторого класса задач или набор инструкций, описывающих порядок действий исполнителя для решения определённой задачи."
В данном случае задача это создание заказа. Порядок действий для ее решения это алгоритм. Надо понимать, почему надо сначала сохранить данные, а потом отправлять письмо, а не наоборот, и уметь выразить это в программном коде. А математика в этом не помогает.
Чисто ради информации. В курсе "Теория алгоритмов" в самом начале первой лекции рисуют классификацию ЯП в зависимости от математической модели алгоритма (детерминированная машина Тьюринга, частично-рек. функция, исчисление предикатов). Для языков процедурных определением алгоритма является тезис Тьюринга, т.е. в рамках этой мат.модели алгоритм - ДМТ- программа. В школьном определении алгоритма тоже говорится гораздо больше. Что алгоритм должен выполняться детерминированно, что должен существовать формальный исполнитель, способный выполнить инструкции и проч.
Однако, без этих знаний вы не будете программистом. Только кодером.
Если не сложно, изложите набор критериев, по которым определяется программист. Если вдвойне не сложно, объясните свой выбор.
Программирование - это процесс создания программного обеспечения. Само словосочетание "программное обеспечение" состоит из двух слов. Хотя, по множеству ГОСТов и ISO стандартов, "Программа" и "Программное обеспечение" взаимозаменяемые, словосочетание является составным. Слово "обеспечение" означает "продукт". Ещë, можно сказать, что это некоторый код, выполняющий какую-то работу. В английском эквиваленте - это -ware из слова Software.
А вот слово "программное", или Soft из слова Software означает некоторые качественные признаки Программы. То есть, совокупность данных, инструкций, алгоритмов и архитектуры. Соответственно, скрипт, выполняющий некую работу, является, в большей степени текстом, продуктом работы кодера. Он представляет собой Программное Обеспечение только тогда, когда рассматривается в совокупности с алгоритмами, архитектурой, входными и выходными данными.
Поэтому, вполне очевидно, что программист - это специалист, разрабатывающий и/или прорабатывающий весь состав Программного Обеспечения. И ТС, когда рассказывает о своей опыте, явно упускает простой момент: он не прорабатывает используемые алгоритмы, не строит определëнную архитектуру. Даже не задумывается об окружении и экосистеме, в которой выполняется его код. Он просто использует готовые решения и пишет простые скрипты для их интеграции. Соответственно, его код можно назвать Программным Обеспечением с большой натяжкой. Точнее, можно, но, скорее-всего ему либо спускают алгоритмы лиды, и он не видит результат в целом, либо пишет сам, но его код может не пройти стандартные экспертизы качества и состава. Кодер не прорабатывает совокупность составляющих ПО. Он пишет скрипты. Программист делает программный продукт, то есть, прорабатывает алгоритмы, входные и выходные данные, архитектуру, тесты, скрипты и инструкции для инфраструктуры и т.д.
простые скрипты для их интеграции
Любая программа на любом уровне абстракции это лишь интеграция более низкоуровневых готовых решений. Программа на ассемблере это скрипт для интеграции готовых машинных команд.
А вот слово "программное", или Soft из слова Software означает некоторые качественные признаки Программы.
У слова Soft из слова Software есть вполне определенное словарное общепринятое значение. Оно используется как противоположность слова Hard (железо). Ваше значение вы придумали сами.
он не прорабатывает используемые алгоритмы, не строит определëнную архитектуру
Прорабатываю и строю, просто для этого мне не нужны те теоретические знания, которые давали в университете. Странно, что вы всему обучились без университета, но отказываете другим в этом праве.
Ваше значение вы придумали сами.
Нет, приводимое мной значение является компиляцией определения слову, данное Робертом Мартином в книге "Чистая Архитектура", а также, ГОСТ 19781—90, ГОСТ Р 51904-2002, ГК РФ ст 1261.
Это вы ваши инфоцыганские песни придумываете сами. А я вам даю только проверенную и качественную информацию. Можете открыть книгу, открыть стандарты и убедиться.
Странно, что вы всему обучились без университета, но отказываете другим в этом праве.
От выпускников технических ВУЗов на собесах я не жду, что они будут вкатываться в IT. Они должны приходить с базой. Для вкатывающихся джунов или стажëров другие критерии. Но, опять же, в долгосрочной перспективе они либо заполнят пробелы в знаниях, либо окажутся "не вкатившимися".
данное Робертом Мартином в книге "Чистая Архитектура", а также, ГОСТ 19781—90, ГОСТ Р 51904-2002, ГК РФ ст 1261
ГОСТ 19781—90
Программа - Данные, предназначенные для управления конкретными компонентами системы обработки информации в целях реализации определенного алгоритма
Программное обеспечение - Научная и практическая деятельность по созданию программ
Программирование - Совокупность программ системы обработки информации и программных документов, необходимых для эксплуатации этих программ
ГОСТ Р 51904-2002
программное обеспечение (ПО): Совокупность компьютерных программ и программных документов, необходимых для эксплуатации этих програм
ГК РФ ст 1261
Программой для ЭВМ является представленная в объективной форме совокупность данных и команд, предназначенных для функционирования ЭВМ и других компьютерных устройств в целях получения определенного результата.
В книге Мартина именно определений я не нашел. Про программное обеспечение там написано следующее.
"Компьютерная программа — это подробное описание политики преобразования входных данных в выходные"
"Первая ценность программного обеспечения — его поведение."
"Вторая ценность программного обеспечения заключена в самом названии «программное обеспечение» Слово «обеспечение» означает «продукт»; а слово «программное»... Как раз в нем и заключается вторая ценность. Идея программного обеспечения состоит в том, чтобы дать простую возможность изменять поведение компьютеров. Для достижения этой цели программное обеспечение должно быть податливым — то есть должна быть возможность легко изменить его."
Ссылку не привожу, так как книга защищена авторским правом.
В этих определениях нет ничего про "качественные признаки" или "прорабатывание алгоритмов".
Приведите пожалуйста цитаты из сторонних источников, где указано ваше значение слова "Soft".
Они должны приходить с базой.
База это то, без чего нельзя делать определенные действия. Если без знания определений нормальных форм можно проектировать структуру таблиц в реальной СУБД, значит это не база.
Пока что выглядит так, что вы путаете теоретические знания и практические навыки, и возмущаетесь тем, что я как будто бы предлагаю не иметь практических навыков. Практические навыки нужны, а реляционную теорию никто не спрашивает, это факт.
В этих определениях нет ничего про "качественные признаки" или "прорабатывание алгоритмов"
Простите, но обычно, в этом случае у таких как вы спрашивают по поводу любовных утех посредством органов зрения.
Программное обеспечение - Научная и практическая деятельность по созданию программ
Программа - Данные, предназначенные для управления конкретными компонентами системы обработки информации в целях реализации определенного алгоритма
Программирование - Совокупность программ системы обработки информации и программных документов, необходимых для эксплуатации этих программ
Программой для ЭВМ является представленная в объективной форме совокупность данных и команд, предназначенных для функционирования ЭВМ и других компьютерных устройств в целях получения определенного результата.
Что же касается Мартина, то если бы ваши очи не были такими "замутнëнными", то они бы заметили, что слово "Программное" Или Soft Мартин связывает с архитектурой ПО. Собственно, вам достаточно было просто ознакомиться с обложкой книги, чтобы найти на ней слово на букву "А". Впрочем, полагаю, что и Русский Язык вы считаете "ненужным".
Ну то есть цитат у вас нет, вы сами додумали, как понимать написанное. То, что вы выделили, прекрасно применимо и к скрипту, выполняющему некую работу, который вы противопоставляете термину "программное обеспечение". Любой скрипт обрабатывает информацию в целях реализации определенного алгоритма и является совокупностью данных и команд.
Впрочем, полагаю, что и Русский Язык вы считаете "ненужным".
Неправильно полагаете. Я уже говорю это второй раз, поэтому предлагаю вам попробовать понять, о чем пишет собеседник, а не спорить с тем, что вы сами придумали.
Нужно знать, как разделять данные на таблицы и как их соединять через внешние ключи.
Как вы это предлагаете делать без знаний реляционной модели и нормальных форм?
почитать статьи в интернете? ТАм же прочитать что чаще всего надо наоборот денормализовать данные чтоб быстрее запросы выполнялись. и тут оказывается что знание математики не нужно. прочитать статью где обьясняются джойны на примере диаграмм вьете гораздо быстрее и полезнее чем изучать всю область математики
Очень просто, берешь и делаешь) Так же как мы в коде без реляционной теории выделяем классы с набором свойств. На практике это сводится к действию "указать id из одной таблицы в полях другой таблицы", достаточно понять, что это просто ссылка на данные.
Это просто если доменная модель простая. Значит, предлагаете самостоятельно "переизобретать велосипед" методом проб и ошибок.
Хорошо, сможете привести пример сложной доменной модели, для создания которой в БД нужны именно теоретические знания, включая определения нормальных форм, и которая не сводится к "указать id из одной таблицы в полях другой таблицы"?
Фактически, для большинства баз данных, так или иначе требуется проработка. От журнала дежурств на складе - и до электронного дневника. Вы просто не понимаете необходимость нормализации, но это не проблема архитекторов - только ваша. Вы - не первый, кто кричит о том, что БД можно запилить на коленке. И не первый, кого эта коленка выставляет за дверь организации, когда заказчик понимает реальный уровень специалиста, накодившего ему не обслуживаемое решение.
Меня пока еще никто не выставлял за дверь, заказчики довольны качеством моей работы.
Я понимаю необходимость нормализации, я говорю о том, что теоретические определения нормальных форм для практического умения делать нормализацию не требуются. Просто у вас похоже какое-то свое понимание того, что такое теоретические знания.
Меня пока еще никто не выставлял за дверь, заказчики довольны качеством моей работы
Ну это вы так говорите. А в других статьях на тему того, что должен знать младший программист, или какая сейчас ситуация на рынке, прямым текстом пишут, что такие "не знающие" Специалисты сейчас никому не нужны. Так что, годика два назад я бы с вами согласился. А сейчас, стажëров нанимают работать бесплатно. И, если они после стажировки не будут готовы рассказать минимум на собесе, то пойдут ещë работать бесплатно.
Такими темпами, будет очень хорошо, если люди, придерживающиеся вашего кодинг-гедонизма, не будут через год доплачивать за стажировку.
Приведите пожалуйста ссылки и цитаты на эти статьи, где пишут, что специалисты должны знать теоретические определения нормальных форм.
В таких статьях пишут про незнание практических навыков. И как раз наоборот говорят, что есть много кандидатов, которые зазубрили теорию, но не знают, как применять ее на практике.
В очередной раз убеждаюсь, что вы неправильно представляете, что такое реляционная теория, а также путаете понятия "знать" и "ориентироваться в области", и предполагаете, что я говорю, что даже ориентироваться в области не нужно, что конечно же не так.
Для создания модели знания о нормальных формах не нужны. Для грамотного дизайна схемы базы данных необходимо понимание того, что такое нормализация, а также когда и почему от нее нужно отказаться.
Так проектирование БД никогда к этому не сводится. Прежде, чем связывать таблицы, нужно ведь определить эти таблицы. И нормальные формы описывают как это делать целесообразней.
Простой пример - журнал автосервиса. Вы же не станете хранить данные автомобиля и информацию об обслуживании в одной таблице? Иначе это будет нарушением 1НФ.
Недавно тут как раз была статья. Тоже наглядный пример даже на не сложной модели.
И нормальные формы описывают как это делать целесообразней.
Нет, не описывают. Таблицы определяются предметной областью и технической необходимостью.
Приведите пожалуйста пример задачи, где вам надо было знать, чем отличается 3НФ от 4НФ (или любые другие), которую вы бы не смогли сделать, или сделали хуже, или потратили больше времени, если бы не знали.
Вы же не станете хранить данные автомобиля и информацию об обслуживании в одной таблице? Иначе это будет нарушением 1НФ.
Я не стану так хранить данные, потому что это будет неправильная модель или это будет неудобно обрабатывать технически. Какое там у 1НФ определение, на мое решение не влияет.
А вот для заказа надо дублировать цену товара, потому что в товаре она со временем изменится, а в заказе должна остаться какая была на момент заказа.
Тоже наглядный пример
Пример чего именно? Я там не вижу необходимости знать нормальные формы или другую информацию из реляционной теории.
Как вы это предлагаете делать без знаний реляционной модели и нормальных форм?
Как человек, который сдуру когда-то изучал реляционную теорию, ответственно заявляю - все необходимые знания реляционной теории можно изложить за час. Современные БД бесконечно далеко ушли от голой реляционной теории.
Разве? В MySQL, PostgreSQL и т.п. реляционная теория не работает?
Есть множество вещей, который к реляционной алгебре отношения не имеют, но которые надо знать - индексы, вьюхи, хранимки, триггеры, права доступа, профилирование. Есть специальные типы данных - xml, json, spatial. Есть более специфические СУБД - графовые, key-value, объектные, time-series. Есть в реляционной алгебре, к примеру, операция деления, а в СУБД ее нет. В SQL есть аггрегаты, который в РЛ нет и т.д. и т.п. Да и вообще говоря таблица это не совсем отношение из реляционной алгебры.
Поэтому достаточно дать историческую справку откуда что пошло. А дальше уже учить как непосредственно SQL, так и СУБДшные штучки типа триггеров и разграничений прав доступа.
Ничего знать не нужно...
Физика не нужна кроме редчайших случаев. Да и в редчайших случаях надо знать скорее математику, типа как дифуры численно считать.
Про математику тут скорее вопрос определений, что именно значит "подробно". Тем более что в среднем техническом ВУЗе все равно в математику глубоко не залазят. Поэтому получается что для серьезных вещей знаний все равно мало, а для типичных айтишных задач условное ТФКП не нужно.
Я бы сказал так. Современный мир предоставляет просто роскошные возможности учиться. Такого реально никогда не было. Разнообразные мобильные устройства с огромной вычислительной мощностью, высокоскоростной интернет, любые лекции на ютубе, любые электронные книги, любые профессиональные форумы, искусственный интеллект который ответит на любые вопросы и разжует любую непонятную информацию. Поэтому - если вы студент - пользуйтесь моментом.
Учите программирование, что бы там ни говорили про то что ИИ вытеснит программистов. Учите много, разные языки, разные платформы одновременно. Отдавайте предпочтение более высокоуровневому, но знайте и низкоуровневое. Отдавайте предпочтение более фундаментальному (теория, алгоритмы, структуры данных, ООП, ФП...), но знайте и прикладное.
Учите иностранный язык (хотя опять таки можно сказать что ИИ переводит лучше человека, как минимум быстрее). В современном мире это очень важно. mp3-плеер с аудиокнигами на иностранном языке должен быть с вами в дороге всегда.
Учите фундаментальную науку. Математика всех направлений (физика тоже нелишняя, т.к. она на 90% тоже математика). Языки программирования приходят и уходят, а вот математика вечна. И мало того что она - отличная разминка для мозгов, так еще и вполне может оказаться нужна на практике.
Устанавливайте контакты с преподами (особенно с теми которые сами имеют много контактов, в т.ч. зарубежных), участвуйте во всяких научных проектах на кафедре, если есть возможность участвовать в программах студенческого обмена - тоже участвуйте.
Ну и гуманитарные знания тоже не стоит отбрасывать. Сейчас большинство ВУЗов имеют статус университета, а университетское образование на то и университетское, что универсальное. Гос.пропаганду, которую сейчас стали преподавать, конечно фильтруйте, а в целом такие науки как философия, психология, социология, экономика - весьма полезны для общего развития.
Не спешите зарабатывать бабки в ущерб учебе. Заработать всегда успеете, а вот незаконченное высшее образование это полная фигня. А диплом - это своеобразный пропуск в другой мир. Пусть не в высшую элиту, но все-же.
Если есть возможность выбирать где подрабатывать, сразу предпочитайте удаленную работу (лучше международную), фриланс или даже собственный бизнес. Приучайтесь к лучшему, в офисе успеете насидеться.
Статья капитана очевидности
Предлагаю добавить ещё про важность знания английского языка хотя бы в достаточной мере чтобы понимать документацию, книги и лекции - не ждать же пока для вас все переведут, а многое и никогда не переведут. Я сам самоучка, из "не благополучной семьи", в свое время пришлось убежать из дома в 17 лет, не окончив даже 11 класс школы, конечно же никакого институтского образования. Способность к языкам сильно помогла мне выжить, я собственно так и выучил вначале английский на практике, из-за не желания ждать пока интересующие меня книги по интересным фреймворкам и технология. переведут на русский. В то время (середина 200х) это был Ruby on Rails и пока на русский переводили книгу, могла выйти уже новая мажорная версия и информация устаревала быстро. Сейчас и того быстрее. Ну и можно сравнить количество ответов по той или иной теме на stackoverflow на английском и др. языках, и станет ясно. Также рекомендую сразу ставить локаль английскую во всем софте и ОС. Это просто вопрос эффективности. Также можно сравнить количество результатов поисковой выдачи если загуглить сообщение об ошибке на английском и русском. Если с переводом документации и тп ещё может помочь chatgpt и аналоги, то при поиске по конкретному сообщению об ошибке это уже сложнее тк перевод бывает разный и точно предсказать текст оригинала по переводу не всегда возможно. Номера ошибок и названия классов исключений помогут, конечно, но они есть не везде.
Также это поможет при устройстве в международные компании.
В общих чертах расписано толково.
Конечно, в каждой области свои нюансы. Физика и математика не так нужны на фронте и многих частях бэка, однако порой профиль компании предполагает их знание. Поэтому лучше учить, пока есть возможность.
Меня после вуза сильно выручили полтора года "фриланса" - время, когда я с друзьями дополнял наш ролевой сайт написанными мною же на PHP модулями (а-ля внутренний магазин, всякие мини-игры и ивенты тематические), когда на JS клепал скрипты всякие. Т.е. уже хоть что-то, а не девственная пустота в резюме и скромное "Теремок" в трудовой. Главное расписать с нужных ракурсов.
Автор не упомянул, но язык нужен (если, конечно, вы не 1С выбрали). Английский. Хоть какой. Просто потому что переменные а-ля chisloOdin и функции poschitai выглядят отвратно. Да и читать документацию порой приходится. И код чужой. Переводчики, конечно, сейчас удобные, но не всегда точные и не всегда под рукой.
Это описание того, что большинство студентов может ожидать в реальной работе. Для примера можно открыть hh.ru и проверить описания вакансий на первой странице. Исключения есть всегда, но их немного.
Для начинающих программистов