Вопрос - "программист" и "вайбкодер" - это одна и таже профессия или разные? Сейчас выглядит так, что разные: - вайбкодер - фуллстек для разработки мелких приложух \ MVP - программист - для работы в крупных, prodaction-ready проектах.
А если профессии разные - то какой смысл middle+ программисту переучиваться на вайбкодера, чтобы начинать карьерный путь с 0?
Скромный, не забудьте про мою потрясающую скромность!
Извините, но если человек говорит "я не ошибаюсь в граничных условиях, а ещё пишу код быстро", - а вы говорити по сути это, то я ему не верю.
Помимо того, что это крайне сложный навык у меня есть и практические наблюдения.
Мы пару раз в своей команде компиляторщиков проводили эксперимент: white-boarding задачек из собеса (когда выяснялось "что-то собеседуемые задачки решают плохо").
Меньше 50% справлялось, основные ошибки - на граничных условиях.
П.С. Сейчас я уже восстанавливаю по памяти (дисклеймер: порядка 20% воспоминаний ложные), но ЕМНИП модный нынче exhausting проблемой не был. А вот ошибки ан +/-1 - были.
Ну мне кажется что вы либо литкод заучиваете либо давненько BinSearch написать не пытались, либо вам повезло проскочить одно узкое место.
Там весьма коварные граничные условия, которые нужно либо помнить, либо копипастить либо есть шанс 50% (как встретить динозавра) просто написать неверно с первого раза, а потом 30 минут отлаживать (как раз до конца интервью с нерешённой задачей).
Из минусов - вряд-ли у вас будет личный наставник который поможет
Ну тут всё как обычно (я на степике курс по Хаскелю смотрел): плоть от плоти университетской системы образования - самые бойкие и сообразительные студенты получают подавляющее большинство времени лекторов.
Но в целом исходный формат степика - короткие теоретические материалы, и сразу же практические задания к ним - прям должен очень помогать (разумеется тут к каждым 5-10 часам такой теории нужен какой-то практический проект тоже на 5-10 часов), к сожалению не все курсы им пользуются и многие вырождаются в "вот вам лекция на 3 часа".
Мне вот интересно - что важно при составлении программы обучения, а что нет (сам больше чем "менторингом" джунов не занимался, но 1-vs-1 и учитель-vs-клас - совсем разные форматы. Для первого нужен обычный здравый смысл, для второго - нехилый опыт)?
Можете дать какие-нибудь релевантные ссылки по теме (в том числе на тот свой отзыв, что упомянули в комментарии)?
Но сегодня более содержательный термин - ЯНУ то, что позволяет управлять ресурсами аппаратуры напрямую, желательно без сайд-эффектов (как минимум в критических к этому секциях).
Простите (ну вот реально не воспримите за наезд), - а зачем вы про "2*2 = 4" портянки пишите. Я же всё про техническую часть написал до вас.
============== Из интересных затронутых тем - действительно в сегодняшнем употреблении: "ЯВУ != ~ЯНУ". Т.к. ЯВУ - про удобство наворачивания абстракций, а ЯНУ - про возможности работать с ресурсами аппаратуры напрямую.
Ну а про термины - могу только повторить: сегодняшнее словоупотребление, учитывая современный контекст (оставить ассемблер единственным синонимом ЯНУ - было бы странно) в отношении ЯНУ мне вполне устраивает.
Биться за термины ради терминов в этом месте - считаю если честно малопродуктивным.
Ну а термины "язык высокого уровня" и "язык низкого уровня" появились очень давно -- вместе с Фортраном и Коболом
Я в курсе. Более того в институте я учил определение "ЯНУ" примерно как вы сказали.
Но времена меняются и сегодня такое определение выглядит для меня устаревшим, самое главное потому, что оно мало содержательно.
======================== Разумеется о значении терминов не спорят, а договариваются (поэтому я не могу запретить вам быть тупоконечником, вы мне остроконечником - но для меня это не столь принципиально). Но сегодня более содержательный термин - ЯНУ то, что позволяет управлять ресурсами аппаратуры напрямую, желательно без сайд-эффектов (как минимум в критических к этому секциях).
Вообще-то, язык низкого уровня -- только ассемблер.
Довольно глупое определение (хотя я не могу запретить вам быть тупоконечником).
Смотрите, положим на минуту, что ассемблер( = мнемоника над ISA) единственный вариант языка низкого уровня, то зачем нам два термина "ассемблер" и "низкоуровневый ЯП". Достаточно одного. Но оба термина существуют - значит оба нужны и полезны.
Скажите, а в проектах, в которых вы учавствовали, сколько времени, по вашим оценкам тратилось на интеграцию уровня системы в сравнении с разработкой всей системы (какую-нибудь удобную вам, но понятную метрику)?
Ну и второй вопрос, чтобы диалог проходил быстрее, - о какого уровня проектах идёт речь в ваших оценках, примерно?
Лет 5 назад на Хабре была модная тема "я недопонял Functional Programming и сейчас вам объясню на примере говна и палок КАК ОНО НА САМОМ ДЕЛЕ". Сейчас эта тенденция добралась до С/С++.
> И здесь мы сталкиваемся с первой значимой путаницей между определениями и их интерпретацией. Дело в том что на самом деле язык программирования C является языком высокого уровня, а не низкого как многие его считают. > Почему же так? На самом деле потому что любой язык программирования является автоматически языком высокого уровня, так как сильно абстрагирует нас от вещей которые происходит на самом деле под капотом.
На самом деле надо пользоваться устоявшимися терминами. И если в мире языков программирования С/С++ называют низкоуровневым - то это соглашение.
А в качестве "общего развития" можно посмотреть на иерархию абстракций (в любом приличном институте дают). Низкоуровневые языки дают возможность взаимодействовать с ОС. Более высокоуровневые - начинают содержать библиотеки сложных алгоритмов или DSL-ориентированные имплементации отдельных задач уровня приложения.
Нам не надо бороться за высокое качество итогового продукта как целого, а надо разбить техпроцесс на такие этапы, чтобы качество на каждом было легче достижимо среднестатистическим бухающим михалычем, измеримо, предсказуемо.
Чем дальше вы пишите - тем страннее это выглядит. Именно качество продукта как целого интересует заказчика. А насколько хорошо сделан этап №10016 - его вообще не интересует. При этом качество целого - не сводится к качеству составных частей "на конвейре".
Не исключаю, что это корявые формулировки и какое-то непонимание.
Статья очень хорошая для тех, кто хочет вкатиться в IT, чтобы почитать "как оно".
Со своей колокольни, прочитав ваши мучения по изучению подходов - я бы сказал что у вас подход к работе не программистский. Те же паттерны (да то же ООО DRY / SOLID) - их не надо зубрить. Надо понимать "какие у нас есть проблемы", "как они в принципе решаются" и дальше - запоминать ли 23 частных решения из этих общих подходов - это дело уже ваше.
Страшная тайна: большинство успешных бизнесов‑проектов‑стартапов — велосипед. Но сделаный лучше конкурента, тем и ценится.
Всё так хорошо начиналось, но в этом месте вы сломались. Большинство успешных бизнесов 1. найти нишу 2. Сделат свою "раму от велосипеда" - которая даст ключевое преимущество 3. Всё остальное - сделать из готовых компонент, чтобы сесть на "существующую инфраструктуру".
То есть говоря вашим языком метафор: "большинство успешных бизнесов - это удобные красивые креслица в стандартном РЖД-шном вагоне метро". Объём завелосипеженого vs объём стандартного взятого просто даже близко не сравним.
Вот приходите вы в больницу, в первый раз (замечу в хорошую частную клинику). Вам выкатывают типовой договор на оказание медицинских услуга на 10 листах 10м шрифтом. После чего у 99.9% людей ровно 2 опции. - не подписывать, и уйти с приёма. - Подписать по-существу не глядя.
В типовом договоре содержатся, в том числе фразы: "мне было разъяснено и мною понято ..... " - разумеется девочки не ресепшне ничего объяснить, а тем более объяснить доступным для неспециалиста языком, не могут.
Ну и так далее.
То есть по существу только варианты "типовой договор по форме 2" (типа ЗоЗПП) - спасают потребителя от того, что он всюду и всегда не прав.
теплоёмкость, скажем металлов, очевидно не линейна с изменением температуры. гугл говорит, что как правило увеличивается - ок, поверим ему.
Вот в этом и сложность. Абсолютно чёрного тела, чтобы калибровать по его излучению, у нас нет. А смешинвание ломается на всяких эффектах типа "отсутствия достаточно длинной шкалы" и "нелинейности теплоёмкости".
Т.е. составить шкалу-то можно, но это не так просто сдлать как поначалу кажется.
Отдельный плюс за метод "ревью плохого кода". Один из немногих рабочих методов для hard-собеседования middle+ (ну кроме "поговорить по душам о прочих проектах").
По поводу "не может объяснять даже простые вещи" - тут следует уточнить. Иногда простые вещи объяснять сложнее всего - надо убедиться, что это это не тот случай (пример условный - буква S в SOLID ппц как сложно).
Если ваши слова читать буквально - то вам в Хэннеси-Паттерсон Computer Architecture: A Quantitative Approach (в принципе хорошая книга ближе к начальному уровню CS по архитектуре компьютеров)
Вы уверены, что хотите именно про микроархитектуру, а не про то, как правильно бэнчмаркать и оптимизировать программы?
П.С. Если что - я почти уверен, что по ссылке не про аппаратный кэш ;)
Проблема в том, что обыватели слабо различают (и как следствие путают) прогресс в интеллекте моделей от важной - но не являющейся прогрессом в интеллекте, оптимизации моделей перед инференсом.
Часто обывателей смущает то, что оптимизации бывают как чисто технические (квантизация, прунинг, дистилляция, спец-форматы ...) так и содержательные, например замена архитектуры на более лёгкую.
Дело в том, что множества "супер-компактных" моделей и "супер-умных" мало пересекаются и подходы и оптимизации в первых ничего не говорят о прогрессе во вторых.
Вопрос - "программист" и "вайбкодер" - это одна и таже профессия или разные?
Сейчас выглядит так, что разные:
- вайбкодер - фуллстек для разработки мелких приложух \ MVP
- программист - для работы в крупных, prodaction-ready проектах.
А если профессии разные - то какой смысл middle+ программисту переучиваться на вайбкодера, чтобы начинать карьерный путь с 0?
Проблема в том, что "все простые, но экономически выгодные" программы уже написаны. Надо писать сложные, или как минимум чуть менее простые.
А при написании "чуть менее простых" - ИИ не справляется с архитектурой.
Извините, но если человек говорит "я не ошибаюсь в граничных условиях, а ещё пишу код быстро", - а вы говорити по сути это, то я ему не верю.
Помимо того, что это крайне сложный навык у меня есть и практические наблюдения.
Мы пару раз в своей команде компиляторщиков проводили эксперимент: white-boarding задачек из собеса (когда выяснялось "что-то собеседуемые задачки решают плохо").
Меньше 50% справлялось, основные ошибки - на граничных условиях.
П.С.
Сейчас я уже восстанавливаю по памяти (дисклеймер: порядка 20% воспоминаний ложные), но ЕМНИП модный нынче exhausting проблемой не был. А вот ошибки ан +/-1 - были.
Ну мне кажется что вы либо литкод заучиваете либо давненько BinSearch написать не пытались, либо вам повезло проскочить одно узкое место.
Там весьма коварные граничные условия, которые нужно либо помнить, либо копипастить либо есть шанс 50% (как встретить динозавра) просто написать неверно с первого раза, а потом 30 минут отлаживать (как раз до конца интервью с нерешённой задачей).
Ну тут всё как обычно (я на степике курс по Хаскелю смотрел): плоть от плоти университетской системы образования - самые бойкие и сообразительные студенты получают подавляющее большинство времени лекторов.
Но в целом исходный формат степика - короткие теоретические материалы, и сразу же практические задания к ним - прям должен очень помогать (разумеется тут к каждым 5-10 часам такой теории нужен какой-то практический проект тоже на 5-10 часов), к сожалению не все курсы им пользуются и многие вырождаются в "вот вам лекция на 3 часа".
Мне вот интересно - что важно при составлении программы обучения, а что нет (сам больше чем "менторингом" джунов не занимался, но 1-vs-1 и учитель-vs-клас - совсем разные форматы. Для первого нужен обычный здравый смысл, для второго - нехилый опыт)?
Можете дать какие-нибудь релевантные ссылки по теме (в том числе на тот свой отзыв, что упомянули в комментарии)?
Простите (ну вот реально не воспримите за наезд), - а зачем вы про "2*2 = 4" портянки пишите. Я же всё про техническую часть написал до вас.
==============
Из интересных затронутых тем - действительно в сегодняшнем употреблении: "ЯВУ != ~ЯНУ". Т.к. ЯВУ - про удобство наворачивания абстракций, а ЯНУ - про возможности работать с ресурсами аппаратуры напрямую.
Ну а про термины - могу только повторить: сегодняшнее словоупотребление, учитывая современный контекст (оставить ассемблер единственным синонимом ЯНУ - было бы странно) в отношении ЯНУ мне вполне устраивает.
Биться за термины ради терминов в этом месте - считаю если честно малопродуктивным.
Я в курсе.
Более того в институте я учил определение "ЯНУ" примерно как вы сказали.
Но времена меняются и сегодня такое определение выглядит для меня устаревшим, самое главное потому, что оно мало содержательно.
========================
Разумеется о значении терминов не спорят, а договариваются (поэтому я не могу запретить вам быть тупоконечником, вы мне остроконечником - но для меня это не столь принципиально).
Но сегодня более содержательный термин - ЯНУ то, что позволяет управлять ресурсами аппаратуры напрямую, желательно без сайд-эффектов (как минимум в критических к этому секциях).
Довольно глупое определение (хотя я не могу запретить вам быть тупоконечником).
Смотрите, положим на минуту, что ассемблер( = мнемоника над ISA) единственный вариант языка низкого уровня, то зачем нам два термина "ассемблер" и "низкоуровневый ЯП". Достаточно одного.
Но оба термина существуют - значит оба нужны и полезны.
Скажите, а в проектах, в которых вы учавствовали, сколько времени, по вашим оценкам тратилось на интеграцию уровня системы в сравнении с разработкой всей системы (какую-нибудь удобную вам, но понятную метрику)?
Ну и второй вопрос, чтобы диалог проходил быстрее, - о какого уровня проектах идёт речь в ваших оценках, примерно?
Вы сейчас утверждаете, что "системные тесты" (и вообще все проверки уровня системы) - лишняя сущность.
Так?
Лет 5 назад на Хабре была модная тема "я недопонял Functional Programming и сейчас вам объясню на примере говна и палок КАК ОНО НА САМОМ ДЕЛЕ".
Сейчас эта тенденция добралась до С/С++.
> И здесь мы сталкиваемся с первой значимой путаницей между определениями и их интерпретацией. Дело в том что на самом деле язык программирования C является языком высокого уровня, а не низкого как многие его считают.
> Почему же так? На самом деле потому что любой язык программирования является автоматически языком высокого уровня, так как сильно абстрагирует нас от вещей которые происходит на самом деле под капотом.
На самом деле надо пользоваться устоявшимися терминами. И если в мире языков программирования С/С++ называют низкоуровневым - то это соглашение.
А в качестве "общего развития" можно посмотреть на иерархию абстракций (в любом приличном институте дают).
Низкоуровневые языки дают возможность взаимодействовать с ОС.
Более высокоуровневые - начинают содержать библиотеки сложных алгоритмов или DSL-ориентированные имплементации отдельных задач уровня приложения.
Чем дальше вы пишите - тем страннее это выглядит.
Именно качество продукта как целого интересует заказчика. А насколько хорошо сделан этап №10016 - его вообще не интересует.
При этом качество целого - не сводится к качеству составных частей "на конвейре".
Не исключаю, что это корявые формулировки и какое-то непонимание.
Статья очень хорошая для тех, кто хочет вкатиться в IT, чтобы почитать "как оно".
Со своей колокольни, прочитав ваши мучения по изучению подходов - я бы сказал что у вас подход к работе не программистский.
Те же паттерны (да то же ООО DRY / SOLID) - их не надо зубрить.
Надо понимать "какие у нас есть проблемы", "как они в принципе решаются" и дальше - запоминать ли 23 частных решения из этих общих подходов - это дело уже ваше.
Всё так хорошо начиналось, но в этом месте вы сломались.
Большинство успешных бизнесов
1. найти нишу
2. Сделат свою "раму от велосипеда" - которая даст ключевое преимущество
3. Всё остальное - сделать из готовых компонент, чтобы сесть на "существующую инфраструктуру".
То есть говоря вашим языком метафор: "большинство успешных бизнесов - это удобные красивые креслица в стандартном РЖД-шном вагоне метро".
Объём завелосипеженого vs объём стандартного взятого просто даже близко не сравним.
Вообще ничего не поменяет.
Вот приходите вы в больницу, в первый раз (замечу в хорошую частную клинику).
Вам выкатывают типовой договор на оказание медицинских услуга на 10 листах 10м шрифтом. После чего у 99.9% людей ровно 2 опции.
- не подписывать, и уйти с приёма.
- Подписать по-существу не глядя.
В типовом договоре содержатся, в том числе фразы: "мне было разъяснено и мною понято ..... " - разумеется девочки не ресепшне ничего объяснить, а тем более объяснить доступным для неспециалиста языком, не могут.
Ну и так далее.
То есть по существу только варианты "типовой договор по форме 2" (типа ЗоЗПП) - спасают потребителя от того, что он всюду и всегда не прав.
теплоёмкость, скажем металлов, очевидно не линейна с изменением температуры.
гугл говорит, что как правило увеличивается - ок, поверим ему.
Вот в этом и сложность.
Абсолютно чёрного тела, чтобы калибровать по его излучению, у нас нет.
А смешинвание ломается на всяких эффектах типа "отсутствия достаточно длинной шкалы" и "нелинейности теплоёмкости".
Т.е. составить шкалу-то можно, но это не так просто сдлать как поначалу кажется.
Статья классная. Чувствуется системный подход.
Отдельный плюс за метод "ревью плохого кода". Один из немногих рабочих методов для hard-собеседования middle+ (ну кроме "поговорить по душам о прочих проектах").
По поводу "не может объяснять даже простые вещи" - тут следует уточнить. Иногда простые вещи объяснять сложнее всего - надо убедиться, что это это не тот случай (пример условный - буква S в SOLID ппц как сложно).
Если ваши слова читать буквально - то вам в Хэннеси-Паттерсон
Computer Architecture: A Quantitative Approach (в принципе хорошая книга ближе к начальному уровню CS по архитектуре компьютеров)
Вы уверены, что хотите именно про микроархитектуру, а не про то, как правильно бэнчмаркать и оптимизировать программы?
П.С.
Если что - я почти уверен, что по ссылке не про аппаратный кэш ;)
Проблема в том, что обыватели слабо различают (и как следствие путают) прогресс в интеллекте моделей от важной - но не являющейся прогрессом в интеллекте, оптимизации моделей перед инференсом.
Часто обывателей смущает то, что оптимизации бывают как чисто технические (квантизация, прунинг, дистилляция, спец-форматы ...) так и содержательные, например замена архитектуры на более лёгкую.
Дело в том, что множества "супер-компактных" моделей и "супер-умных" мало пересекаются и подходы и оптимизации в первых ничего не говорят о прогрессе во вторых.