Только для условного котлина вам придется искать кучу разных библиотек - работа с БД
Таких библиотек много, но добавим 1-2 часа на интеграцию.
всякая арифметика с датами, временем, фиксированной точкой
Мне сложно даже сказать, в какой технологии этого нет.
то прежде чем его использовать, вы обязаны провести полный аудит всего кода
В банках уже используется Java, Kotlin, Python, C++ и еще куча всего, если верить вакансиям. Я не знаю, откуда это дополнительно требование.
А потом убедиться, что все это по производительности и потреблению ресурсов не хуже и вам не потребуется в два-три раза больше железа подо все это ставить.
Мне сложно поверить, что современный JVM (с зелеными потоками и пр.) будет медленнее, чем Cobol. Разве есть хоть какие-то свидетельства этого?
И "более читаемым" оно будет только для того, кто этот самый котлин знает.
Это задача на один день для человека, который имеет опыт с другим языком JVM, ну или на 1-4 недели изучения и работы, если человек вообще новичок. Так-то Котлин в вузах изучают, на нем программы пишут уже после первых пары занятий (то есть буквально после потраченных 3-5 часов). Затраты только на поиск специалиста на Cobol будут больше.
а что там такого на этом Коболе написано, что нельзя взять и переписать?
Там нет ничего такого. Это язык полный по тьюрингу, уровень типизации у него низкий и так далее. Честная перепись на условный Kotlin (с корректной типизацией и пр.) не будет сколько-нибудь сложной вещью, да и финальное приложение будет более читаемое.
Основная проблема в том, что на Cobol осталось только дремучее легаси, которое переписать стоит больше, чем бюджет отдела на год. Более того, проблемы (если верить слухам) усугубляются тем, что ряд приложений уже одобрены/сертифицированы (пусть даже выдают не всегда корректные данные), а документация утеряна, так что перепись на любой другой язык несет в себе риск получить новые проблемы (пусть даже с исправлением всех старых).
Тут подходит пример с факсом - он еще используется, хотя проигрывает современным методам коммуникаций. Но его использование обусловлено наличием старых процессов, которые конкретно сейчас не собираются менять.
Да, всё так, вот только есть несколько (независимых и не очень) системных циклов, которые делают ровно то, что Вы описали. По сути, любая корутина будет выполняться в одном из Dispatcher'ов.
Во-первых, там уже живут люди. Например, климат Сочи лучше климата Питера, но я был рад тому, что в Питере построили дамбу, чтобы нивелировать ущерб от наводнений.
Во-вторых, там может находится что-то полезное, а потому рабочим надо будет где-то жить. А точнее:
Этот город может запустить туризм (а он требует очень много персонала)
Там может быть порт, добыча нефти или фермерские поля (не забываем про ГМО, которое может помочь адаптировать некоторые растения под климат)
Там могут быть электростанции или промышленность, которая требует большого объема энергии (например, сейчас кладут кабель из Туниса в Европу; по задумке солнечную энергию можно добывать в пустынях, а передавать дальше на север).
В-третьих, как я уже сказал, лично мне этот проект нравится тем, что он даст информацию для ученых и инженеров.
Атомную энергетику ведь уже признали зеленой? Ведь признали же?
В мире нет некой "единой комиссии", которая признает что-то зеленым или нет. В ряде стран есть определенные дотации для определенных направлений бизнеса, и их часто связывают с "зелеными", но тут, скорее, будет только корреляция.
Отвечая на вопрос, тут три момента: глобальный, локальный, политический.
Глобальный: основная проблема для текущего климата - это парниковый эффект. Земля получает громадную дозу энергии от Солнца, вот только она всё хуже и хуже рассеивается.
Любой подход, который сможет уменьшить этот самый парниковый эффект, в итоге, приведет к исправлению климата. ГЭС/АЭС позволят сжигать меньше ископаемого топлива, что, в итоге, решит проблему. Ветряки и солнечные панели тоже помогут Земле в целом, но с ними всё хуже (могу расписать детали).
Более того, можно еще компенсировать выбросы путем увеличения объема лесов: по сути, растительность будет "забирать" СО2 из атмосферы.
Локальный: ряд выбросов плохо влияет на людей, а потому переход на условный газ или вынос электростанции подальше из города решит эту проблему. Конечно же, АЭС поможет и тут.
Политический: такие вещи, как АЭС, требуют очень больших инвестиций на начальном этапе, а далее их будут очень долго строить, плюс потом их надо обслуживать и утилизировать отходы. Каждый пункт очень лакомый для коррупции, а то же самое топливо еще и закупать сложно (его продает малое число стран, с которыми тоже придется договариваться). Строительство же газовых электростанций и ветряков намного проще и подконтрольнее, а потому нередко их предпочитают.
Не знаю. Но, для научного эксперимента, так даже лучше. А вдруг получится удачно? В ОАЭ некоторые проекты получились достойными, а некоторые - не очень, но даже неудачные (такие, как искусственные острова) дали новые знания для человечества.
Лично мне эта идея нравится как очень хороший научный эксперимент. По задумке получится озеленить и приспособить к жизни еще один кусочек пустыни, что уже хорошо. А, в идеале, следующая модель запросто будет более дешевой и эффективной.
все текущее айти это буквально Карого-Культ очередного фреймворка и языка с толпой фанатиков
На основе чего у Вас такое утверждение? Разве есть свидетельства того, что большинство разработчиков являются фанатиками некоего единственного фреймворка или языка? И что это за язык такой (начнем с него)?
Почему? Как раз наоборот: сильный коллега сделает команду сильнее, что позволит эффективнее выполнять задачи и тратить меньше времени на споры в стиле "я не знаю gradle, он никогда не будет популярным".
Если речь идет о некой "карьере", то это работает только для крупных компаний (и, желательно, не outsource), а там еще сильнее работает абзац выше, ибо слабые сотрудники уведут команду в бесконечную поддержку продукта и бюрократию, вместо движения вперед.
На самом деле, работа тимлидом несет в себе довольно серьезный карьерный риск, так как:
Опыт накапливается намного медленнее, чем у коллег по команде. Даже если тимлид занимается ревью кода, это и близко не сопоставимо с реальной задачей.
Основная масса управленческой работы заканчивается на уровне "сотрудник хочет в отпуск, можно подписать бумагу и согласиться, или не подписать, и начать искать нового человека, взамен ушедшего, через X недель".
Опыт в общении имеет, как показывает практика, основной смысл только в текущей компании, в текущем отделе, ибо даже другой отдел уже может требовать другого уровня бюрократии и согласований.
В подавляющем числе случаев тимлидов повышают из своих сотрудников, что приводит к тому, что очень сложно перейти на позицию тимлида в другой фирме, ибо ей выгоднее повысить своего сотрудника. Но часто предлагают обман: "ты пока поработаешь разработчиком, а потом, возможно, мы тебе дадим команду", тогда как условный чистый управленец пойдет именно на позицию управленца.
Как показывает практика, есть немало плохих тимлидов (с любовью с микроменеджменту и пр.), и есть немало тех, кто стал управлять на уровне мидла (самая простая проверка - насколько много разных решений человек может предложить для закрытия задачи). Как следствие из этого, можно сделать вывод, что отбор на этих должностях проходит очень плохо после назначения на них. Как следствие из этого, очень легко стать плохим тимлидом, а далее, вместе с первым пунктом, можно вообще получить комбо "слабый сотрудник и очень слабый управленец", ибо обратная связь очень хлипкая.
Тут играет еще момент массовости: 10 запланированных лунных миссий будет стоить дешевле, чем десятикратная стоимость единственной запланированной.
По сути, это обыгрывается в подходах по управлению бизнесом от MBA: есть капитальные затраты (они необходимы вне зависимости от выпуска продукции, например - строительство завода), а есть операционные (например - затраты на исходные материалы для продукции). Если капитальные затраты довольно большие (например, построить инфраструктуру для связи с аппаратом на Луне), то как раз футуристический подход будет более осмысленный.
Или пересчитывайте рубли на цену квадратного метра в районе получасовой доступности от офиса
Это опасная метрика, так как Вы берете, по сути, индекс от индекса, так что идет аккумуляция погрешностей.
Ваша метрика будет колебаться даже от таких вещей, как изменение доли нового элитного жилья в определенных районах (а новостройки дают довольно серьезный вклад в среднюю цену за метр, которую нередко считают по сделкам за определенный период).
Иногда корректнее признать определеную погрешность изначальной метрики, нежели вводить новую, которая может быть менее достоверной.
Насколько мне известно, всё не совсем так, как Вы описали.
Изначально сроки, на протяжении которых интеллектуальная собственность должна охраняться, определяются ВОИС, то есть, по сути, отдельные страны не очень самостоятельны в принятии этих законов.
Более того, по сути, если какая-то страна начинает использовать более свободные законы, то начинаются проблемы с признанием патентов из этой страны.
Практически каждому государству, которое не получает много прибыли за производства кинофильмов, выгодно смягчать эти законы, ибо всё равно основной ажиотаж к произведениям идет в первые годы, и очень редкие фильмы хоть как-то продаются через условные 10 лет. А потому, выгоднее тратить меньше налогов на защиту чужих прибылей, а заодно и меньше штрафовать своих граждан. Примеры таких стран: Швейцария и Бразилия, ибо там, по сути, очень сложно оштрафовать человека, которые раздает фильмы в P2P.
В России ситуация еще более интересная, ибо сейчас выгоды от ВОИС стало еще меньше, а потому и смысла дотошно соблюдать все постановления (которые наследуются из тех же законов о продлении сроков) стало тоже меньше. Стратегически неизвестно, насколько правильно смягчение антипиратских законов, ибо, с одной стороны, это может и усложнить некоторый диалог, но, с другой стороны, в будущем можно попробовать продать обещание ужесточить законодательство (или, по сути, вернуть всё как было) в обмен на определенные уступки. Но этот вопрос уже очень сложный.
Используя факты выше (а также мои размышления, которые, конечно же, могут быть и ошибочными), можно переписать Вашу аналогию еще и следующим образом:
- Мы считаем А, Б и В тем же, что и воровство, а это плохо. Если хотите, чтобы продукцию не воровали (то есть не делали А, Б, В, Г и Д), то вступайте в организацию Х и принимайте законы. - Да, ок, вступаем, но не так радикально, ибо исполнение всех-всех-всех норм слишком дорогое, у нас нет на это бюджета, а потому, В исключаем. - Ок, ну хотя бы так.
А далее: -Б тоже не имеет смысла сейчас, к тому же, вы сами плохо соблюдаете Г и Д (а точнее - их соблюдение не дает никаких плюсов), а потому мы и деньги тратить не будем на это, а далее посмотрим -Ну хорошо, А нам вполне достаточно, а далее посмотрим.
Cообщения 100% не удаляют, так это очень трудоемкая операция, обычно им выставляют флаг deleted=1.
Если говорить про само устройство баз данных, то это не так. При удалении записи сама база проставляет прошлой строке этот флаг, а далее сама база будет переиспользовать это место. Смысла в повторении этого функционала в бизнес логике нет никакого, кроме случаев целостности базы (когда у Вас удаление записи "пользователь" потребует, по сути, каскадного удаления других записей, а потому это действие лучше отложить в стиле CQRS паттерна, чтобы была возможность его перезапустить на случай возникновения deadlock).
А разве Вы всегда знаете все ответы на все вопросы на работе? Разве никогда не бывало ситуации, когда в середине совещания приходится говорить: «так, я эту тему не знаю, но мне она важна для …, а потому мне надо Х времени на изучение, иначе я не смогу принять взвешенное решение. Не подскажете, кто может быть лучшим контактом?»
не преувеличиваю, буквально вчера был случай с тимлидом чужой команды
Это стандартная проблема, очень малая доля тимлидов с опытом имеют уровень синьоров, ибо много времени уходит на менеджмент, внутри команды нередко легче использовать админ ресурс, чем технические аргументы, а выработки совместных решений между командами зачастую требуют политики, а не технических знаний.
Но ожидания у тимлида будут выше, чем у синьора, а потому Вам случай выше, на самом деле, довольно частый.
Если исключить компании, оказывающие "консультационные услуги в нишевом сегменте", то где вообще требуются сертификаты (ну или хотя бы они могут хоть как-то помочь)?
Я видел код, сравнивающий два дерева (а точнее - два xml файла) и выводящим разницу, да еще и по определенным правилам. Бизнес логика этого сравнения была не самой тривиальной, а потому, по сути, код постоянно бегал вверх и вниз по дереву.
Ко мне этот код пришел уже после того, как на него были потрачены единицы недель с целями "оптимизировать", а задача стояла "добавить кеш, чтобы сравнивать int, а не string".
После дня (плюс/минус) работы сравнение стало работать быстрее секунды, хотя долгое время оно занимало до часа работы.
В принципе, в этом и есть разница между "знание простейших алгоритмов" и "не люблю leetcode" (хотя, тогда его еще не было): изначально команда тратила своё время на оптимизацию, время сотрудников поддержки, время клиентов и так далее, что, суммарно, серьезно превышало тот самый один день на написание корректного кода.
Позволю себе предположить, что им предложат более высокий оклад, то потребуют более высоких знаний, в том числе и алгоритмов. Далее кто-то не пройдет собеседование, а потом пожалуется, что "ужас-ужас, на более высокие зарплаты нужна более высокая квалификация".
Другими словами, Вы сейчас неявно только подтвердили, что, для высоких окладов, желательно знать алгоритмы.
Таких библиотек много, но добавим 1-2 часа на интеграцию.
Мне сложно даже сказать, в какой технологии этого нет.
В банках уже используется Java, Kotlin, Python, C++ и еще куча всего, если верить вакансиям. Я не знаю, откуда это дополнительно требование.
Мне сложно поверить, что современный JVM (с зелеными потоками и пр.) будет медленнее, чем Cobol. Разве есть хоть какие-то свидетельства этого?
Это задача на один день для человека, который имеет опыт с другим языком JVM, ну или на 1-4 недели изучения и работы, если человек вообще новичок. Так-то Котлин в вузах изучают, на нем программы пишут уже после первых пары занятий (то есть буквально после потраченных 3-5 часов). Затраты только на поиск специалиста на Cobol будут больше.
Там нет ничего такого. Это язык полный по тьюрингу, уровень типизации у него низкий и так далее. Честная перепись на условный Kotlin (с корректной типизацией и пр.) не будет сколько-нибудь сложной вещью, да и финальное приложение будет более читаемое.
Основная проблема в том, что на Cobol осталось только дремучее легаси, которое переписать стоит больше, чем бюджет отдела на год. Более того, проблемы (если верить слухам) усугубляются тем, что ряд приложений уже одобрены/сертифицированы (пусть даже выдают не всегда корректные данные), а документация утеряна, так что перепись на любой другой язык несет в себе риск получить новые проблемы (пусть даже с исправлением всех старых).
Тут подходит пример с факсом - он еще используется, хотя проигрывает современным методам коммуникаций. Но его использование обусловлено наличием старых процессов, которые конкретно сейчас не собираются менять.
Да, всё так, вот только есть несколько (независимых и не очень) системных циклов, которые делают ровно то, что Вы описали. По сути, любая корутина будет выполняться в одном из Dispatcher'ов.
Во-первых, там уже живут люди. Например, климат Сочи лучше климата Питера, но я был рад тому, что в Питере построили дамбу, чтобы нивелировать ущерб от наводнений.
Во-вторых, там может находится что-то полезное, а потому рабочим надо будет где-то жить. А точнее:
Этот город может запустить туризм (а он требует очень много персонала)
Там может быть порт, добыча нефти или фермерские поля (не забываем про ГМО, которое может помочь адаптировать некоторые растения под климат)
Там могут быть электростанции или промышленность, которая требует большого объема энергии (например, сейчас кладут кабель из Туниса в Европу; по задумке солнечную энергию можно добывать в пустынях, а передавать дальше на север).
В-третьих, как я уже сказал, лично мне этот проект нравится тем, что он даст информацию для ученых и инженеров.
В мире нет некой "единой комиссии", которая признает что-то зеленым или нет. В ряде стран есть определенные дотации для определенных направлений бизнеса, и их часто связывают с "зелеными", но тут, скорее, будет только корреляция.
Отвечая на вопрос, тут три момента: глобальный, локальный, политический.
Глобальный: основная проблема для текущего климата - это парниковый эффект. Земля получает громадную дозу энергии от Солнца, вот только она всё хуже и хуже рассеивается.
Любой подход, который сможет уменьшить этот самый парниковый эффект, в итоге, приведет к исправлению климата. ГЭС/АЭС позволят сжигать меньше ископаемого топлива, что, в итоге, решит проблему. Ветряки и солнечные панели тоже помогут Земле в целом, но с ними всё хуже (могу расписать детали).
Более того, можно еще компенсировать выбросы путем увеличения объема лесов: по сути, растительность будет "забирать" СО2 из атмосферы.
Локальный: ряд выбросов плохо влияет на людей, а потому переход на условный газ или вынос электростанции подальше из города решит эту проблему. Конечно же, АЭС поможет и тут.
Политический: такие вещи, как АЭС, требуют очень больших инвестиций на начальном этапе, а далее их будут очень долго строить, плюс потом их надо обслуживать и утилизировать отходы. Каждый пункт очень лакомый для коррупции, а то же самое топливо еще и закупать сложно (его продает малое число стран, с которыми тоже придется договариваться). Строительство же газовых электростанций и ветряков намного проще и подконтрольнее, а потому нередко их предпочитают.
Не знаю. Но, для научного эксперимента, так даже лучше. А вдруг получится удачно? В ОАЭ некоторые проекты получились достойными, а некоторые - не очень, но даже неудачные (такие, как искусственные острова) дали новые знания для человечества.
Лично мне эта идея нравится как очень хороший научный эксперимент. По задумке получится озеленить и приспособить к жизни еще один кусочек пустыни, что уже хорошо. А, в идеале, следующая модель запросто будет более дешевой и эффективной.
На основе чего у Вас такое утверждение? Разве есть свидетельства того, что большинство разработчиков являются фанатиками некоего единственного фреймворка или языка? И что это за язык такой (начнем с него)?
Почему? Как раз наоборот: сильный коллега сделает команду сильнее, что позволит эффективнее выполнять задачи и тратить меньше времени на споры в стиле "я не знаю gradle, он никогда не будет популярным".
Если речь идет о некой "карьере", то это работает только для крупных компаний (и, желательно, не outsource), а там еще сильнее работает абзац выше, ибо слабые сотрудники уведут команду в бесконечную поддержку продукта и бюрократию, вместо движения вперед.
На самом деле, работа тимлидом несет в себе довольно серьезный карьерный риск, так как:
Опыт накапливается намного медленнее, чем у коллег по команде. Даже если тимлид занимается ревью кода, это и близко не сопоставимо с реальной задачей.
Основная масса управленческой работы заканчивается на уровне "сотрудник хочет в отпуск, можно подписать бумагу и согласиться, или не подписать, и начать искать нового человека, взамен ушедшего, через X недель".
Опыт в общении имеет, как показывает практика, основной смысл только в текущей компании, в текущем отделе, ибо даже другой отдел уже может требовать другого уровня бюрократии и согласований.
В подавляющем числе случаев тимлидов повышают из своих сотрудников, что приводит к тому, что очень сложно перейти на позицию тимлида в другой фирме, ибо ей выгоднее повысить своего сотрудника. Но часто предлагают обман: "ты пока поработаешь разработчиком, а потом, возможно, мы тебе дадим команду", тогда как условный чистый управленец пойдет именно на позицию управленца.
Как показывает практика, есть немало плохих тимлидов (с любовью с микроменеджменту и пр.), и есть немало тех, кто стал управлять на уровне мидла (самая простая проверка - насколько много разных решений человек может предложить для закрытия задачи). Как следствие из этого, можно сделать вывод, что отбор на этих должностях проходит очень плохо после назначения на них. Как следствие из этого, очень легко стать плохим тимлидом, а далее, вместе с первым пунктом, можно вообще получить комбо "слабый сотрудник и очень слабый управленец", ибо обратная связь очень хлипкая.
Тут играет еще момент массовости: 10 запланированных лунных миссий будет стоить дешевле, чем десятикратная стоимость единственной запланированной.
По сути, это обыгрывается в подходах по управлению бизнесом от MBA: есть капитальные затраты (они необходимы вне зависимости от выпуска продукции, например - строительство завода), а есть операционные (например - затраты на исходные материалы для продукции). Если капитальные затраты довольно большие (например, построить инфраструктуру для связи с аппаратом на Луне), то как раз футуристический подход будет более осмысленный.
Это опасная метрика, так как Вы берете, по сути, индекс от индекса, так что идет аккумуляция погрешностей.
Ваша метрика будет колебаться даже от таких вещей, как изменение доли нового элитного жилья в определенных районах (а новостройки дают довольно серьезный вклад в среднюю цену за метр, которую нередко считают по сделкам за определенный период).
Иногда корректнее признать определеную погрешность изначальной метрики, нежели вводить новую, которая может быть менее достоверной.
Насколько мне известно, всё не совсем так, как Вы описали.
Изначально сроки, на протяжении которых интеллектуальная собственность должна охраняться, определяются ВОИС, то есть, по сути, отдельные страны не очень самостоятельны в принятии этих законов.
Более того, по сути, если какая-то страна начинает использовать более свободные законы, то начинаются проблемы с признанием патентов из этой страны.
Выгодоприобретателями того, что определенное произведение запрещено копировать являются всем известные крупные фирмы, которые активно проплачивают увеличение сроков охраны своих произведений. То есть, по сути, с большинством государств даже большие фирмы не договариваются напрямую.
Практически каждому государству, которое не получает много прибыли за производства кинофильмов, выгодно смягчать эти законы, ибо всё равно основной ажиотаж к произведениям идет в первые годы, и очень редкие фильмы хоть как-то продаются через условные 10 лет. А потому, выгоднее тратить меньше налогов на защиту чужих прибылей, а заодно и меньше штрафовать своих граждан. Примеры таких стран: Швейцария и Бразилия, ибо там, по сути, очень сложно оштрафовать человека, которые раздает фильмы в P2P.
В России ситуация еще более интересная, ибо сейчас выгоды от ВОИС стало еще меньше, а потому и смысла дотошно соблюдать все постановления (которые наследуются из тех же законов о продлении сроков) стало тоже меньше. Стратегически неизвестно, насколько правильно смягчение антипиратских законов, ибо, с одной стороны, это может и усложнить некоторый диалог, но, с другой стороны, в будущем можно попробовать продать обещание ужесточить законодательство (или, по сути, вернуть всё как было) в обмен на определенные уступки. Но этот вопрос уже очень сложный.
Используя факты выше (а также мои размышления, которые, конечно же, могут быть и ошибочными), можно переписать Вашу аналогию еще и следующим образом:
- Мы считаем А, Б и В тем же, что и воровство, а это плохо. Если хотите, чтобы продукцию не воровали (то есть не делали А, Б, В, Г и Д), то вступайте в организацию Х и принимайте законы.
- Да, ок, вступаем, но не так радикально, ибо исполнение всех-всех-всех норм слишком дорогое, у нас нет на это бюджета, а потому, В исключаем.
- Ок, ну хотя бы так.
А далее:
-Б тоже не имеет смысла сейчас, к тому же, вы сами плохо соблюдаете Г и Д (а точнее - их соблюдение не дает никаких плюсов), а потому мы и деньги тратить не будем на это, а далее посмотрим
-Ну хорошо, А нам вполне достаточно, а далее посмотрим.
Если говорить про само устройство баз данных, то это не так. При удалении записи сама база проставляет прошлой строке этот флаг, а далее сама база будет переиспользовать это место. Смысла в повторении этого функционала в бизнес логике нет никакого, кроме случаев целостности базы (когда у Вас удаление записи "пользователь" потребует, по сути, каскадного удаления других записей, а потому это действие лучше отложить в стиле CQRS паттерна, чтобы была возможность его перезапустить на случай возникновения deadlock).
О подобном можно почитать даже на хабре - https://habr.com/ru/articles/342838/ .
А разве Вы всегда знаете все ответы на все вопросы на работе? Разве никогда не бывало ситуации, когда в середине совещания приходится говорить: «так, я эту тему не знаю, но мне она важна для …, а потому мне надо Х времени на изучение, иначе я не смогу принять взвешенное решение. Не подскажете, кто может быть лучшим контактом?»
Иногда фирма хочет и то, и другое, но дает больше денег.
Это стандартная проблема, очень малая доля тимлидов с опытом имеют уровень синьоров, ибо много времени уходит на менеджмент, внутри команды нередко легче использовать админ ресурс, чем технические аргументы, а выработки совместных решений между командами зачастую требуют политики, а не технических знаний.
Но ожидания у тимлида будут выше, чем у синьора, а потому Вам случай выше, на самом деле, довольно частый.
Если исключить компании, оказывающие "консультационные услуги в нишевом сегменте", то где вообще требуются сертификаты (ну или хотя бы они могут хоть как-то помочь)?
Я видел код, сравнивающий два дерева (а точнее - два xml файла) и выводящим разницу, да еще и по определенным правилам. Бизнес логика этого сравнения была не самой тривиальной, а потому, по сути, код постоянно бегал вверх и вниз по дереву.
Ко мне этот код пришел уже после того, как на него были потрачены единицы недель с целями "оптимизировать", а задача стояла "добавить кеш, чтобы сравнивать
int, а неstring".После дня (плюс/минус) работы сравнение стало работать быстрее секунды, хотя долгое время оно занимало до часа работы.
В принципе, в этом и есть разница между "знание простейших алгоритмов" и "не люблю leetcode" (хотя, тогда его еще не было): изначально команда тратила своё время на оптимизацию, время сотрудников поддержки, время клиентов и так далее, что, суммарно, серьезно превышало тот самый один день на написание корректного кода.
Позволю себе предположить, что им предложат более высокий оклад, то потребуют более высоких знаний, в том числе и алгоритмов. Далее кто-то не пройдет собеседование, а потом пожалуется, что "ужас-ужас, на более высокие зарплаты нужна более высокая квалификация".
Другими словами, Вы сейчас неявно только подтвердили, что, для высоких окладов, желательно знать алгоритмы.