2 года назад поиск работы там ещё работал - за несколько месяцев не слишком активного поиска таки удалось найти, при этом разговаривал с представителями лишь нескольких компаний. Массово резюме не рассылал. Полагаю, ИИ-фильтры придумали чуть позже.
В некоторых конторах мидлом называют, чтобы урезать зарплату. Типа, ты последние лет 15 лет пилил уникальную технологию (и лет 5 назад таки допилил), обучал людей, получил учёную степень (описав эту технологию в статьях и диссертации) - оп, и ты мидл.
Дело в том, что эти "... должен ...", подразумеваемые за каждой должностью и вакансией, во всех компаниях разные, и о них редко говорится в вакансии (и хорошо, если хотя бы в должностной инструкции). Так что ваш список обязанностей применим только для вас. Но его возьмёт HR из другой компании, загонит в промпт в дополнение к уже существующим пунктам, и будет фильтровать всех направо и налево.
Сам удивился, когда пару раз подряд нейросеть за пару часов наоптимизировала -30% на ровном месте. Claude очень лихо пишет бенчмарки, меряет, оптимизирует, меряет... Только желательно критерий остановки задавать.
Наверно, вот оно - решение проблемы жрущего память, диск, процессор и всё такое прочее кода. И это только подтверждает тезис о том, что код можно не оптимизировать [вручную].
180 файлов - это и есть проект на 1 человека... Если есть хоть какая-нибудь структура, с этим вполне можно работать, причём даже без ide (хотя это уже грустно).
Есть ещё неприятный эффект "пролетаризации" - раньше для входа в профессию достаточно было потратить 1000$ на комп (и уйму времени на учёбу), а теперь средство производства (дорогая видеокарта для инференса) работнику уже не принадлежит, по крайней мере на данный момент оборудование дорогое.
Законы физики - вряд ли (хотя наши современные модели мира могут оказаться неверны), скорее люди очередной раз обойдут технические ограничения, с помощью ИИ или без.
Закон Мура, который хоронят лет 20, тем не менее продолжает существовать в переформулированном виде. Даже сейчас есть масса путей (даже банальных, типа 3d чиплетов), чтобы увеличивать производительность.
Со временем соотношение цены/производительности оборудования снизится так, что llm из 2026 можно будет запускать на ноутбуке (пусть вначале не на самом дёшевом). Лет через 8-10, если экстраполировать данные за последние лет 15.
Индустрии, в которую я пришёл, больше не существует. Той, в которой я работаю сегодня, не будет и в 2036-м. ИИ уже меняет то, как мы пишем код, и, честно говоря, меня это скорее воодушевляет, чем пугает — потому что если это десятилетие меня чему-то и научило, так это тому, что наша настоящая работа никогда не заключалась в наборе кода. Она заключалась в понимании задач, проектировании решений и работе с людьми.
Эти навыки не автоматизируются. Они только дорожают.
Звучит как тост! Сохранил 😁
Я в коммерческой разработке чуть побольше, и подобные пункты у меня другие, но 3-4 пункта из этих очень похожи на мои выводы, а с другими просто сложно поспорить. Надо будет тоже такой список накидать.
От plan mode ощущения не те толку мало, когда нужно быстро сделать какие-то простые очевидные вещи. Нет желания обсуждать или каждый раз пересматривать очевидное - тогда может быть проще сделать самому.
Тут было бы интересно версионирование ФС, чтобы "навороченое" можно было отменить.
Обычная мода. Одни попробовали, выступили на конференциях, другие посмотрели и подумали, что это хорошо. Прошло немного времени... И уже моветон не использовать. Сейчас AI на базе LLM в этой фазе. До этого были микросервисы, NoSQL, agile, "чистый код", наверно паттерны...
Микросервисная архитектура прежде всего предназначена для разделения работы на несколько команд разработчиков, когда вся система не может поместиться в головах одной команды на 10 человек. Есть и другие предпосылки типа горизонтального масштабирования отдельных частей, независимого деплоя частей... Но в одиночку пилить микросервисы - обычно немного смысла, и неудивительно, что получился монолит.
Может нейросеть больше обучена С-подобным языкам, а не Verilog? По идее, лечится специальным промптом, если хоть какие-то подходящие умения есть, но запрятаны.
Ожидание внешнего сигнала, без которого дальнейшая цепочка действий невозможна встречается повсеместно и относится именно к предметной области, а не к деталям реализации
Только вот await из языков программирования для этого почти всегда не применим.
Что будет, если наш процесс прервался на await taskC (например, сбой)? Он перезапустится сначала, причём вся цепочка - с taskA (и хорошо, если те сервисы идемпотентны). Если это плохо применимо (например, сервисы A, B работают неидемпонтентно, отвечают долго, или промежуточные расчёты долгие), то в таких случаях вы всё равно вынуждены делать стейт-машину наподобие следующей, хоть async/await, хоть синхронный код (шагов может быть больше, если отделять расчёты в отдельные состояния):
state, context = await read_state()
while state!=FINAL_STATE:
match state:
case 0:
await serviceA.taskA(x,y)
...do_something...
await save_state(state:=1,context)
case 1:
await serviceA.taskA(x,y)
...do_something...
await save_state(state:=2,context)
case 2:
await serviceA.taskA(x,y)
await save_state(state:=FINAL_STATE,context)
Здесь await вызывает внешний сервис, и заставляет поток ОС заняться другой задачей. Если этот поток ОС прерван (например, был сбой, и наш сервис перезапушен), то стейт-машина продолжит бизнес-процесс с точки сохранения, что была перед сбоем, но заслуги конструкции языка async/await в этом нет. С тем же успехом тут мог быть синхронный код, причём в обоих этих примерах.
async/await - это всего лишь конструкция языка, помогающая вручную компактно упаковать вычисления и ожидания IO в существующие потоки ОС, что даёт эффективность выполнения кода за счёт минимизации простоя процессора и минимизации создания/переключений потоков ОС. Для ожидания внешних систем, если вам нужна устойчивая работа кода, эта конструкция неприменима. Поэтому, на мой взгляд, она и не имеет отношения к предметной области.
async, await, override настолько далеки от пользователя, что в java обходятся без них - язык или инфраструктура берут это на себя, выбирая некий вариант автоматически. А в python, например, решили, что это должен контролировать программист. Я не представляю, где в предметной области может понадобиться await, который относится чисто к управлению потоками внутри процесса ОС в компьютере, а не к бизнес-процессам (отличие в том, что поток в компьютере может прерываться по техническим причинам, а соответствующий бизнес-процесс может в это время продолжаться - т.е. это разные понятия, лишь отдалённо схожие, и ожидание в бизнес-процессе - это совершенно не await).
(@override / @Override здесь плохой пример, т.к. и в java, и в python он "фиктивный" - язык его не требует, в отличие от каких-нибудь scala, где это зачем-то обязательно, или delphi, где override напрямую влияет на способ вызова функции - виртуальный или обычный)
На каком основании async/await в прикладных?? Там рядом такая несуществующая в реальной жизни муть с event loop, что не каждый программист сходу разберётся. То же и @override @staticmethod @abstract - это детали реализации ООП...
А в Rust прикладного, возможно, ничего и нет - там 90% кода "имеет в виду" управление памятью. Постоянно ссылки, Box<T>, разыменования, стек, крейты, делегирование (это ещё число лайфтаймов в коде по сравнению с первыми версиями снижено в 10 раз).
По-моему, Python взлетел из-за 1) простоты, причём явно и фанатично декларируемой, 2) гибкости, подобной Lisp (только вместо списков - в Python словари как базовый контейнер для всего, в т.ч. и кода). Из этого всего смогли соорудить Tensorflow в виде, пригодном для запуска учёными, и пошло-поехало. С++ тоже подходит для таких вещей, но меньше подходит для непрограммистов. Ну и, возможно, ещё п. 3) легкая интеграция с C/С++.
А так сравнение забавное, заставляет задуматься, спасибо.
Сейчас в интернете огромная доля мусорного трафика. Если поднять сервер и посмотреть логи, можно увидеть постоянные попытки взлома.
Все виденные мною исследования рынка труда за последний год почему-то ссылаются на hh, и инфа про 19 (уже 25) резюме на вакансию - оттуда.
2 года назад поиск работы там ещё работал - за несколько месяцев не слишком активного поиска таки удалось найти, при этом разговаривал с представителями лишь нескольких компаний. Массово резюме не рассылал. Полагаю, ИИ-фильтры придумали чуть позже.
В некоторых конторах мидлом называют, чтобы урезать зарплату. Типа, ты последние лет 15 лет пилил уникальную технологию (и лет 5 назад таки допилил), обучал людей, получил учёную степень (описав эту технологию в статьях и диссертации) - оп, и ты мидл.
Дело в том, что эти "... должен ...", подразумеваемые за каждой должностью и вакансией, во всех компаниях разные, и о них редко говорится в вакансии (и хорошо, если хотя бы в должностной инструкции). Так что ваш список обязанностей применим только для вас. Но его возьмёт HR из другой компании, загонит в промпт в дополнение к уже существующим пунктам, и будет фильтровать всех направо и налево.
Сарказм неуместен, увы.
Сам удивился, когда пару раз подряд нейросеть за пару часов наоптимизировала -30% на ровном месте. Claude очень лихо пишет бенчмарки, меряет, оптимизирует, меряет... Только желательно критерий остановки задавать.
Наверно, вот оно - решение проблемы жрущего память, диск, процессор и всё такое прочее кода. И это только подтверждает тезис о том, что код можно не оптимизировать [вручную].
180 файлов - это и есть проект на 1 человека... Если есть хоть какая-нибудь структура, с этим вполне можно работать, причём даже без ide (хотя это уже грустно).
Есть ещё неприятный эффект "пролетаризации" - раньше для входа в профессию достаточно было потратить 1000$ на комп (и уйму времени на учёбу), а теперь средство производства (дорогая видеокарта для инференса) работнику уже не принадлежит, по крайней мере на данный момент оборудование дорогое.
Нейросетями код очень неплохо оптимизируется 😁
Законы физики - вряд ли (хотя наши современные модели мира могут оказаться неверны), скорее люди очередной раз обойдут технические ограничения, с помощью ИИ или без.
Закон Мура, который хоронят лет 20, тем не менее продолжает существовать в переформулированном виде. Даже сейчас есть масса путей (даже банальных, типа 3d чиплетов), чтобы увеличивать производительность.
Со временем соотношение цены/производительности оборудования снизится так, что llm из 2026 можно будет запускать на ноутбуке (пусть вначале не на самом дёшевом). Лет через 8-10, если экстраполировать данные за последние лет 15.
Звучит как тост! Сохранил 😁
Я в коммерческой разработке чуть побольше, и подобные пункты у меня другие, но 3-4 пункта из этих очень похожи на мои выводы, а с другими просто сложно поспорить. Надо будет тоже такой список накидать.
От plan mode
ощущения не тетолку мало, когда нужно быстро сделать какие-то простые очевидные вещи. Нет желания обсуждать или каждый раз пересматривать очевидное - тогда может быть проще сделать самому.Тут было бы интересно версионирование ФС, чтобы "навороченое" можно было отменить.
Обычная мода. Одни попробовали, выступили на конференциях, другие посмотрели и подумали, что это хорошо. Прошло немного времени... И уже моветон не использовать. Сейчас AI на базе LLM в этой фазе. До этого были микросервисы, NoSQL, agile, "чистый код", наверно паттерны...
А нужно или не нужно - это уже другой вопрос.
Микросервисная архитектура прежде всего предназначена для разделения работы на несколько команд разработчиков, когда вся система не может поместиться в головах одной команды на 10 человек. Есть и другие предпосылки типа горизонтального масштабирования отдельных частей, независимого деплоя частей... Но в одиночку пилить микросервисы - обычно немного смысла, и неудивительно, что получился монолит.
"Автор в детстве не просто потерялся в лесу, а был спасён и воспитан большими языковыми моделями".
Может нейросеть больше обучена С-подобным языкам, а не Verilog? По идее, лечится специальным промптом, если хоть какие-то подходящие умения есть, но запрятаны.
Только вот await из языков программирования для этого почти всегда не применим.
Допустим, у нас есть несколько ожиданий:
await serviceA.taskA(x,y)...do something...
await serviceB.taskB(a,b,c)
...do something...
await serviceC.taskC(c,d,a)
Что будет, если наш процесс прервался на await taskC (например, сбой)? Он перезапустится сначала, причём вся цепочка - с taskA (и хорошо, если те сервисы идемпотентны). Если это плохо применимо (например, сервисы A, B работают неидемпонтентно, отвечают долго, или промежуточные расчёты долгие), то в таких случаях вы всё равно вынуждены делать стейт-машину наподобие следующей, хоть async/await, хоть синхронный код (шагов может быть больше, если отделять расчёты в отдельные состояния):
state, context = await read_state() while state!=FINAL_STATE: match state: case 0: await serviceA.taskA(x,y) ...do_something... await save_state(state:=1,context) case 1: await serviceA.taskA(x,y) ...do_something... await save_state(state:=2,context) case 2: await serviceA.taskA(x,y) await save_state(state:=FINAL_STATE,context)Здесь await вызывает внешний сервис, и заставляет поток ОС заняться другой задачей. Если этот поток ОС прерван (например, был сбой, и наш сервис перезапушен), то стейт-машина продолжит бизнес-процесс с точки сохранения, что была перед сбоем, но заслуги конструкции языка async/await в этом нет. С тем же успехом тут мог быть синхронный код, причём в обоих этих примерах.
async/await - это всего лишь конструкция языка, помогающая вручную компактно упаковать вычисления и ожидания IO в существующие потоки ОС, что даёт эффективность выполнения кода за счёт минимизации простоя процессора и минимизации создания/переключений потоков ОС. Для ожидания внешних систем, если вам нужна устойчивая работа кода, эта конструкция неприменима. Поэтому, на мой взгляд, она и не имеет отношения к предметной области.
async, await, override настолько далеки от пользователя, что в java обходятся без них - язык или инфраструктура берут это на себя, выбирая некий вариант автоматически. А в python, например, решили, что это должен контролировать программист. Я не представляю, где в предметной области может понадобиться await, который относится чисто к управлению потоками внутри процесса ОС в компьютере, а не к бизнес-процессам (отличие в том, что поток в компьютере может прерываться по техническим причинам, а соответствующий бизнес-процесс может в это время продолжаться - т.е. это разные понятия, лишь отдалённо схожие, и ожидание в бизнес-процессе - это совершенно не await).
(
@override/@Overrideздесь плохой пример, т.к. и в java, и в python он "фиктивный" - язык его не требует, в отличие от каких-нибудь scala, где это зачем-то обязательно, или delphi, где override напрямую влияет на способ вызова функции - виртуальный или обычный)На каком основании async/await в прикладных?? Там рядом такая несуществующая в реальной жизни муть с event loop, что не каждый программист сходу разберётся. То же и
@override @staticmethod @abstract- это детали реализации ООП...А в Rust прикладного, возможно, ничего и нет - там 90% кода "имеет в виду" управление памятью. Постоянно ссылки, Box<T>, разыменования, стек, крейты, делегирование (это ещё число лайфтаймов в коде по сравнению с первыми версиями снижено
в 10 раз).По-моему, Python взлетел из-за 1) простоты, причём явно и фанатично декларируемой, 2) гибкости, подобной Lisp (только вместо списков - в Python словари как базовый контейнер для всего, в т.ч. и кода). Из этого всего смогли соорудить Tensorflow в виде, пригодном для запуска учёными, и пошло-поехало. С++ тоже подходит для таких вещей, но меньше подходит для непрограммистов. Ну и, возможно, ещё п. 3) легкая интеграция с C/С++.
А так сравнение забавное, заставляет задуматься, спасибо.