Это выдавить можно только на уровне культурного пласта, максимально вытравливать низкокачественный контент, но этого вероятно уже не случится никогда, и дерьмовый ллм контент с нами до следующего витка развития
3000 часов активного развития под надзором преподавателя - и макака заговорит. Обыватель вряд ли 3000 часов сможет/захочет выделить на проект "изучить ин.яз" на каких угодно условиях и сроках.
Литкод easy - дело полезное, ради самого паттерна "а вот тут наверное можно ускорить если подумать". Задач 50 решить по вечерам - проект невеликий. Литкод mid не нужен, если оптимизация кода это не профиль позиции. Литкод hard имхо нужен 3.5 гениям, а мы не гении.
Вроде прикольно, но нишевое. Имеем гарантированную плату это всё перетаскивать в конфигурацию после доработок, хотя если делаем расширение, то будет попроще. Для правок сложных процессов без отладки полезность ощутимо падает. А для очень сложных вообще может быть необходимость откатывать базу после каждой попытки). Но для больших конфигураций с тяжелым перезапуском польза вероятно будет.
В любом случае респект за развитие глобального инструментария
Наличие тестировщика никак не снимает с разраба задачи провести хотя бы ручной дымовой тест, выявить очевидные ошибки/опечатки, в идеальном мире к задаче на постановке составляется 3-4 кейса, которые можно проверить сразу. Создавать лишнее трение ни к чему
Разработчики 1С с глубоким знанием бухучета это наоборот архаика. Ну, есть конечно свежая кровь на предприятиях где один человек и жрец и жнец, там выбора нет. А везде где покрупнее будет обычная связка БА+СА+лид+архитектор+разрабы. Элементарно потому что изучение всего сразу требует много лет. Людей, которые совмещают все 5 компетенций на хотя бы мидл - один на многие тысячи. А там ведь ещё девопс, администрирование, да тот же uiux
С каждым днём всё быстрее начинаю распознавать статьи, написанные с ллм. Этот стиль трудно описать в существующих терминах, но от него ощутимо воняет, отбивает желание читать.
В финтехе часто делают самописки именно для бухучета, т.к вариантов вести учет много, и типовые решения не подходят примерно никогда. У нас три соседних отдела сидели на двух различных самописках плюс одном глубоко доработанном типовом решении. И большая часть регламентированной отчетности по фин. продуктам шла из них. Плюс типовые зуп и бп чисто для административных нужд и внутрянки.
Сама по себе она не хороша и не плоха, но в данном примере избыточна. Со вторым абзацем согласен полностью, это надо читать когда сам уже хотя бы мидл и можешь не просто взять идеи, но перед этим обдумать, а стоит ли
Критический медицинский софт никто в одно лицо и не пишет. Там целый консилиум придумывает тесты на код, и консилиум поменьше придумывает тесты на тесты. У рядового разраба ответственность за код больше вымышленная, чем отличная от крудошлепов
Это выдавить можно только на уровне культурного пласта, максимально вытравливать низкокачественный контент, но этого вероятно уже не случится никогда, и дерьмовый ллм контент с нами до следующего витка развития
3000 часов активного развития под надзором преподавателя - и макака заговорит. Обыватель вряд ли 3000 часов сможет/захочет выделить на проект "изучить ин.яз" на каких угодно условиях и сроках.
Литкод easy - дело полезное, ради самого паттерна "а вот тут наверное можно ускорить если подумать". Задач 50 решить по вечерам - проект невеликий. Литкод mid не нужен, если оптимизация кода это не профиль позиции. Литкод hard имхо нужен 3.5 гениям, а мы не гении.
Вроде прикольно, но нишевое. Имеем гарантированную плату это всё перетаскивать в конфигурацию после доработок, хотя если делаем расширение, то будет попроще. Для правок сложных процессов без отладки полезность ощутимо падает. А для очень сложных вообще может быть необходимость откатывать базу после каждой попытки). Но для больших конфигураций с тяжелым перезапуском польза вероятно будет.
В любом случае респект за развитие глобального инструментария
И с таблицы истинности
В принципе, если рассматривать гармонические кривые, выясняется, что для хороших переговоров размер ZHOPA имеет ключевое значение
Наличие тестировщика никак не снимает с разраба задачи провести хотя бы ручной дымовой тест, выявить очевидные ошибки/опечатки, в идеальном мире к задаче на постановке составляется 3-4 кейса, которые можно проверить сразу. Создавать лишнее трение ни к чему
Можно делить день на кванты - например с 9 до 12 фокус на 1-2 задачи, 12-14 мелочь, потом 15-17 фокус и 17-18 мелочь
Разработчики 1С с глубоким знанием бухучета это наоборот архаика. Ну, есть конечно свежая кровь на предприятиях где один человек и жрец и жнец, там выбора нет. А везде где покрупнее будет обычная связка БА+СА+лид+архитектор+разрабы. Элементарно потому что изучение всего сразу требует много лет. Людей, которые совмещают все 5 компетенций на хотя бы мидл - один на многие тысячи. А там ведь ещё девопс, администрирование, да тот же uiux
На порядки это в 100 раз или 1000?
"универсальной" и "документ" лучше заменить, мало ли что в 2027 примут
С каждым днём всё быстрее начинаю распознавать статьи, написанные с ллм. Этот стиль трудно описать в существующих терминах, но от него ощутимо воняет, отбивает желание читать.
7 марта на отчисление..
В финтехе часто делают самописки именно для бухучета, т.к вариантов вести учет много, и типовые решения не подходят примерно никогда. У нас три соседних отдела сидели на двух различных самописках плюс одном глубоко доработанном типовом решении. И большая часть регламентированной отчетности по фин. продуктам шла из них. Плюс типовые зуп и бп чисто для административных нужд и внутрянки.
Могут ли розетки платить налоги..
Сама по себе она не хороша и не плоха, но в данном примере избыточна. Со вторым абзацем согласен полностью, это надо читать когда сам уже хотя бы мидл и можешь не просто взять идеи, но перед этим обдумать, а стоит ли
Зачем читать содержание книги, если ИИ выдаст главную мысль?
Сэм Альтман съел на завтрак бутерброд с авокадо
Дожили. Скайрим и Ведьмак 3 - старые игры.
Критический медицинский софт никто в одно лицо и не пишет. Там целый консилиум придумывает тесты на код, и консилиум поменьше придумывает тесты на тесты. У рядового разраба ответственность за код больше вымышленная, чем отличная от крудошлепов