07.07.2023 08:37
sergiodev 150 18000 Источник

Я не писатель, извините, если криво изложил, но суть должна быть понятна...

В общем, когда я только учился программированию, мне было очень интересно. Особенно ковыряться в коде на C++, изучать, как там устроена память, загрузка модулей DLL, или внутренности операционной системы. Но работы особо не было по этой тематике, поэтому со временем приходилось двигаться на уровень абстракции всё выше и выше.

Но штука в том, что по мере того, как я получал больше опыта и наблюдал за индустрией, после изучения разных технологий и фреймворков начала накапливаться какая-то усталость от всего происходящего в мире разработки. Сейчас постараюсь объяснить.

Вот кто-то сегодня создал очередной новый фреймворк. Здорово! Все переходят теперь на него. Через 3 года ещё один умный чувак напишет что-то ещё лучше, и модным станет это. Прогресс!

Но дело в том, что со временем мне стало лень изучать всю эту тряхомудь, которая всё равно скорее всего умрёт через 3 года и на её смену придёт что-то новое. Фундаментально ведь не особо что-то меняется - используются одни и те же низлежащие технологии. Однако, если я не буду это вот всё изучать, то отстану от других и будет уже меньше шансов найти работу в будущем. Ведь в компаниях стараются использовать модные и молодёжные технологии, чтобы быть популярными у соискателей, чтобы не дай бог какой-нибудь Вася не плюнул на них и не ушёл в другую контору - кому захочется работать с древней версией Java 8 или каким-нибудь AngularJS V{current - 3}, когда есть Kotlin и React?

Вот взять web к примеру. Многие из нас начинали просто с изучения HTML, CSS, JavaScript. Не было фреймворков, хватало знания этих трёх фундаментальных технологий для написания сайтов. С ними ты мог создать что угодно. Теперь же потенциальные работодателя от тебя требуют знания (и опыта работы!) с Vue.js, React, Angular, Svelte, Webpack, Tailwind, и ещё с десяток какой-то ерунды. И с каждым днём кажется, что ты отстаёшь всё больше.

Или вот хотел я понять когда-то, что такого в мессадж-брокерах, разобраться с их устройством и вообще смыслом. Но не успел - появилась Kafka, теперь придётся изучать эту шляпу. Хотел конкретно изучить Docker, но уже поздно - он больше не в моде, теперь же есть Kubernetes, Ansible, и ещё чёрти сколько технологий, которые я никогда не изучу. А раньше было достаточно просто знаний администрирования Linux...

Мне просто уже кажется, что я никогда не уcпею за движущимся поездом прогресса, и нет никакого смысла изучать все эти новые технологии и фреймворки, и что выпускник 3-месячного буткэмпа знает больше, чем я, несмотря на мой опыт. Хотя ведь фундаментально ничего не меняется уже десятилетиями - мы по-прежнему используем HTML, CSS, JS, по-прежнему кодим на ООП-языках (с лёгким добавлением функциональщины), по-прежнему используем всё те же структуры данных и алгоритмы. Поэтому, мне кажется, что работодатели вообще не должны требовать опыт работы конкретно с каким-то «стэком» или тулзой, а проверять, имеет ли соискатель знания, которые позволят ему изучить необходимое в рабочее время в короткие сроки. А все эти «опыт работы с Golang от 3-х лет» меня очень раздражают (можно подумать там что‑то такое сложное, что аж нужно 3 года учиться).

Короче, накипело просто, и надоело. Надоело изучать какую-то ерунду в свободное время. Хочу жить как человек, а не сидеть за компом 24/7, чтобы оставаться в теме.

Комментарии (150)


  1. MiraclePtr
    07.07.2023 08:59
    #25726952
    +23

    Немного странно читать, конечно.... Kafka существует уже 13 лет, и принципиально нового в ней прям ничего нет, развитие старых брокерских идей. Docker существует уже 10 лет, по-прежнему цветет и пахнет, и никто от него не отказывается... Более того, даже во фронтенд-мире React'у уже 10 лет, Vuejs почти столько же, и они до сих пор не устарели. Времена, когда каждый год выходил "принципиально новый фреймворк" на который все сразу бросались переписывать кодовую базу уже давно прошли.

    Меня даже подмывает задать классический вопрос "А может просто просто программирование - это не ваше?", но да ладно, скажу по-другому. Бро, переходи обратно к нам в мир C++. Работы выше крыши, фреймворки не меняются десятилетиями. Новые стандарты языка докатываются до продакшена тоже очень медленно (даже жаль, там очень много вкусного). Не надо никуда нестись и каждые два года срочно изучать что-то очередное новомодное. Низкоуровневые штуки, работа с памятью и сисколлы ОС прям рядом, только руку протяни.


    1. serjeant
      07.07.2023 08:59
      #25727012
      +6

      В С++ сейчас каждые 3 года новый стандарт. А работы существенно меньше и оплачивается ниже рынка. Сам ушел с С++/Qt на Golang. Может с ситуацией импортозамещения что-то изменится....


      1. MiraclePtr
        07.07.2023 08:59
        #25727042
        +3

        В С++ сейчас каждые 3 года новый стандарт

        В плюсах "новый стандарт" обычно означает "мы тут исправили несколько доставших всех проблем языка, перетащили несколько новых классов из буста и досыпали сверху приятного сахарочку". Короче говоря, крайне редко бывает что-то прям принципиально новое, что требует кучи времени и сил на изучение, достаточно раз в три года потратить пару вечеров на чтение статей. Да и спешить никуда не надо - от момента, когда принимается новый стандарт до момента, когда его полностью реализуют в компиляторах, а потом версии компиляторов обновят на продакшене и наконец-то переведут кодовую базу на новый стандарт, обычно проходит ещё 3-5 лет, а в некоторых проектах и все 10. И никто не заставляет прямо разу в обязательном порядке использовать сразу все фичи из новой версии языка.

        А работы существенно меньше и оплачивается ниже рынка.

        Тут неплохо бы уточнять, про какую страну и какую конкретно часть мира разработки ПО идёт речь, ибо мир большой. В РФ я плюсы именно в связке с Qt встречал в основном во всяких там НИИ и НПФ и среднемелких локальных конторах, там действительно с зарплатами не густо было. При этом в те времена в РФ в двух столицах (подозреваю, что после февраля 2022 стало гораздо печальнее, ибо самые вкусные работодатели ушли) и сейчас в мире достаточно приличных мест с хорошими зарплатами и интересными задачами - и всякий Embedded Linux для крупных вендоров, и разработка движков браузеров, и финтех (большие банки, HFT, и т.д.), и софт для датацентров и телекома, и всякий высоконагруженный бэкенд в простигосподи FAANG'ах и их аналогах.


        1. serjeant
          07.07.2023 08:59
          #25727078
          +1

          РФ конечно (Ростов-на-Дону). Отрасль - десктоп разработка, системное программирование.
          https://rostov.hh.ru/vacancy/81389407?from=vacancy_search_list&query=программист С


        1. 0xd34df00d
          07.07.2023 08:59
          #25729696
          +21

          В плюсах "новый стандарт" обычно означает "мы тут исправили несколько доставших всех проблем языка, перетащили несколько новых классов из буста и досыпали сверху приятного сахарочку".

          Корутины уже все зашарили? constexpr научились эффективно пользоваться? Зачем std::launder нужен, все понимают? range'и тоже поняли и научились ими пользоваться кроме как для хелловорлдов? UB на стыке этого всего глаз уже наметан ловить?


          Плюсы — ходячий мертвец.


          1. cat_chi
            07.07.2023 08:59
            #25731678
            +1

            Плюсы — ходячий мертвец.

            Этот мертвец ещё долго будет ходить. Какие есть альтернативы для высокопроизводительного кода?


            1. SpiderEkb
              07.07.2023 08:59
              #25731754
              +1

              Ну... Строго говоря, чистый С в целом более способствует.

              Чтобы писать высокопроизводительный код на С++ надо очень хорошо знать как устроены его библиотеки (та же stl) внутри. Иначе, при бездумном использовании, рискуете нарваться на множественные динамические выделения/освобождения памяти, что не очень способствует высокой производительности.

              Также бездумное использование исключений может весьма отрицательно повлиять на производительность.

              Так что тут прежде всего в голове, а потом уже в языке дело.


              1. cat_chi
                07.07.2023 08:59
                #25731814
                +2

                Ну лично я предпочёл бы писать код на C++, а отдельные узкие места дорабатывать напильником... Нежели писать всё на C или писать одни куски кода на C++, а другие на C.

                В рамках одного модуля, само собой. Или сервиса, или микросервиса, или ещё какой-либо единицы абстракции. Вообще комбинировать несколько языков – не проблема. Но не смешивать их вот таким странным образом.

                Также бездумное использование исключений может весьма отрицательно повлиять на производительность.

                Думаю, большинство опытных плюсовиков хорошо это знают ????


              1. 0xd34df00d
                07.07.2023 08:59
                #25732378
                +5

                Строго говоря, чистый С в целом более способствует.

                Чистый С как раз ещё хуже, потому что средств для написания обобщённого кода с компилтайм-специализациями нет, а компилятору очень сложно продираться через все эти void* и инлайнить вещи с последующими оптимизациями. Поэтому отсортировать много чисел с std::sort, например, может быть в разы быстрее, чем с qsort.


                1. SpiderEkb
                  07.07.2023 08:59
                  #25732418

                  Есть конкретные примеры?

                  На самом деле *void это просто указатель на область памяти. И компилятору совсем не надо через него продираться

                  Я вот сейчас работаю с языком, где указатели не типизированы (точнее, там два типа - указатель на данные и на процедуру). А чтобы с указателем работать, нужно объявить связанную с ним переменную. Можно и несколько. И разных типов.

                  А вообще, написать абы какой код и надеяться что компилятор за вас вывезет, ну такое себе...

                  И любой универсальный метод может проиграть в скорости написанному руками под конкретную задачы с учетом специфики данных.

                  Как пример. Есть две строки суть которых набор двухсимвольных кодов. Их надо сравнить. Причем, порядок кодов не играет роли. Только наличие в строке. Т.е.

                  D1C2N1 == C2N1D1

                  Казалось бы отсортируй и сравнивай. Но с учетом большой плотности вызовов это непозволительная роскошь.

                  Вот и приходится включать мозг. Оказалось, что есть алгоритм со сложностью O(n). Т.е. быстрее любой сортировки.

                  И таких примеров полно в личной практике


                  1. 0xd34df00d
                    07.07.2023 08:59
                    #25732594
                    +9

                    Есть конкретные примеры?

                    Раз: на массиве в 100к элементов std::sort (+ копирование массива) в 2.4 раза быстрее qsort (+ копирование массива).
                    Два: на коротком массиве, который мне не лень написать руками, чтобы избежать копирования, std::sort почти в 4 раза быстрее qsort.


                    На самом деле *void это просто указатель на область памяти. И компилятору совсем не надо через него продираться

                    Угу, именно поэтому


                    int stdsort()
{
    int arr[] = { 3, 5, 7, 2, 1 };
    std::sort(std::begin(arr), std::end(arr));
    return arr[0];
}

                    компилируется в нулевой рантайм-оверхед


                    stdsort():                            # @stdsort()
        mov     eax, 1
        ret

                    а


                    int intcmp(const void *lPtr, const void *rPtr)
{
    return *static_cast<const int*>(lPtr) - *static_cast<const int*>(rPtr);
}

int qsort()
{
    int arr[] = { 3, 5, 7, 2, 1 };
    qsort(arr, sizeof(arr) / sizeof(arr[0]), sizeof(arr[0]), &intcmp);
    return arr[0];
}

                    компилируется в порнографию из


                    intcmp(void const*, void const*):                        # @intcmp(void const*, void const*)
        mov     eax, dword ptr [rdi]
        sub     eax, dword ptr [rsi]
        ret
qsort():                              # @qsort()
        sub     rsp, 24
        movaps  xmm0, xmmword ptr [rip + .L__const.qsort().arr]
        movaps  xmmword ptr [rsp], xmm0
        mov     dword ptr [rsp + 16], 1
        lea     rcx, [rip + intcmp(void const*, void const*)]
        mov     rdi, rsp
        mov     esi, 5
        mov     edx, 4
        call    qsort@PLT
        mov     eax, dword ptr [rsp]
        add     rsp, 24
        ret
.L__const.qsort().arr:
        .long   3                               # 0x3
        .long   5                               # 0x5
        .long   7                               # 0x7
        .long   2                               # 0x2
        .long   1                               # 0x1

                    А вообще, написать абы какой код и надеяться что компилятор за вас вывезет, ну такое себе...

                    Соломенные чучела, попробуйте ещё раз.


                    Как пример. Есть две строки суть которых набор двухсимвольных кодов. Их надо сравнить. Причем, порядок кодов не играет роли. Только наличие в строке. Т.е.
                    D1C2N1 == C2N1D1

                    Очень сложный алгоритм, подождите, мне надо позвать гуглёров.


                    Если строки только восьмибитные, и есть важно именно только наличие, и они достаточно короткие, то без особого пердолинга в профайлер, вот вам O(n)-алгоритм:


                    auto toSet(std::string_view s)
{
    std::unordered_set<std::string_view> codes;
    codes.reserve(s.size() / 2);
    for (size_t i = 0; i < s.size(); i += 2)
        codes.insert(s.substr(i, 2));
    return codes;
}

bool sameCodes(std::string_view s1, std::string_view s2)
{
    return toSet(s1) == toSet(s2);
}

                    Если без байтоложества жизни нет или хочется прям совсем производительность-производительность, то можно заменить toSet на


                    struct Code
{
    uint16_t repr = 0;

    static Code fromString(const char *ptr)
    {
        uint16_t repr = (ptr[0] << 8) + ptr[1];
        return Code { repr };
    }

    auto operator<=>(const Code&) const = default;
};

auto toSet(std::string_view s)
{
    auto hasher = [] (Code code) { return std::size_t { code.repr }; };
    std::unordered_set<Code, decltype(hasher)> codes;
    codes.reserve(s.size() / 2);
    for (size_t i = 0; i < s.size(); i += 2)
        codes.insert(Code::fromString(&s[i]));
    return codes;
}

                    — будет примерно в два раза быстрее, но всё ещё вполне с STL.


                    Если строки длиннее, или если алфавит совсем короткий (скажем, 26 символов на первый знак и 10 на второй), то выгоднее построить табличку и её потом сравнивать, но даже там кое-где пригодится кое-что из STL. Да и, например, лично я бы оставил реализацию выше для тестов как более интерпретируемую и наваял бы quickcheck-подобный тест, что обе реализации дают одни и те же результаты.


                    Правда, всё ещё не понимаю, причём тут обсуждение самого языка C++ как имеющего больше возможностей писать более выразительный и понятный машине-компилятору код.


                    1. 5nw
                      07.07.2023 08:59
                      #25733090

                      std::sort компилируется в нулевой оверхед потому что для массивов таких размеров внутри вызывается insertion_sort (2 цикла), который естественно оптимизируется лучше, чем сложный qsort


                      1. 0xd34df00d
                        07.07.2023 08:59
                        #25733106
                        +1

                        qsort, как я показал рядом, тоже фоллбечится на insertion sort. Хотя нельзя не отметить комментарий о выборе константы для порога:


                        This particular magic number was chosen to work best on a Sun 4/260

                        — как диды в 1987-м году написали, так никто больше в это чудо поддерживаемости не лез и не обновлял для более современного железа. Но это, впрочем, нормальная ситуация с кодом на C.


                        Но это всё неважно. Можно весь массив заменить на один элемент (это уже достаточно мало даже для очень релевантного сегодня Sun 4/260?):


                        int arr[] = { 3 };

                        и для компилятора это всё равно будет непрозрачный вызов:


                        intcmp(void const*, void const*):
        mov     eax, DWORD PTR [rdi]
        sub     eax, DWORD PTR [rsi]
        ret
qsort():
        sub     rsp, 24
        mov     ecx, OFFSET FLAT:intcmp(void const*, void const*)
        mov     edx, 4
        mov     esi, 1
        lea     rdi, [rsp+12]
        mov     DWORD PTR [rsp+12], 3
        call    qsort
        mov     eax, DWORD PTR [rsp+12]
        add     rsp, 24
        ret


                      1. 5nw
                        07.07.2023 08:59
                        #25733116
                        +1

                        Немного магии, меняем массив на {3, 5, 7, 2, 2} и оптимизация уже не работает https://godbolt.org/z/adjcPvsf7, по крайней мере на шестнадцатом clang и тринадцатом gcc все компилируется в ту же порнографию
                        Более того, на всех других массивах, что я пробовал, получается то же самое
                        Это какой-то специальный массив, подобранный для C vs C++ холиворов?)


                      1. 0xd34df00d
                        07.07.2023 08:59
                        #25733124
                        +2

                        Не, действительно случайно взятый.


                        Но хорошим контрпримером было бы показать массив, который оптимизируется в константу в C, но не оптимизируется в плюсах.


                      1. 0xd34df00d
                        07.07.2023 08:59
                        #25733128
                        +1

                        Поигрался ещё — всё работает, если минимальным является последний элемент, и если дубликатов других элементов нет, иначе оптимизатор походу просто сдаётся.


                        Но это не беда, в c++20 можно просто поставить constexpr, и всё снова работает (на теоретических компиляторах, реализующих constexpr std::sort)!


                    1. SpiderEkb
                      07.07.2023 08:59
                      #25733294
                      -2

                      1. Что внутри stdsort происходит? Разверните.

                      2. Что происходит внутри unordered_set и во что выливается toSet(s1) == toSet(s2) ? Разверните. Вы уверены что там внутри не будет поэлементного сравнения "каждый с каждым"? Плюс еще формирование наборов (там точно нет динамического выделения памяти под каждый элемент)?

                      Это типичное заблуждение "фреймворкеров" - кажется, что если все укладывается в 2-3 строки кода, то и в исполняемом виде будет те же самые 2-3 строки кода. Но это не так.

                      Чтобы сравнивать и понимать нужно брать хороший профайлер и смотреть - что там со стеком происходит (разворачивать-сворачивать стек тоже не бесплатно).

                      Что там с динамическим выделением памяти - это тоже небесплатно.

                      Если говорить о моем варианте, то там цикл по количеству элементов и внутри цикла две операции побитового XOR и три операции сложения целых чисел. на выходе еще операция побитового сдвига, две побитовых AND и операция сложения двух целых чисел.

                      Все. Больше там нет ничего (никаких динамических выделений, никаких конструкторов, никаких лишних вызовов функций и образованием нового уровня стека). На выходе сравниваем два целых числа.

                      Фактически - это своеобразный хеш, формируемый с учетом особенностей входных данных. Т.е. мы не идем "в лоб" сравнивая два массива, но считаем хеши и сравниваем их. Нам не надо знать чем отличаются массивы. На надо только знать совпадают они или нет. И решаем вот эту конкретную узкую задачу.

                      Если пойти еще дальше, то один набор хранится в таблице и может считаться один раз (при занесении в таблицу). и тогда хеш считаем уже не два раза, а один (старый хеш хранится в таблице и подтягивается при чтении записи, новый хеш считаем, если отличается - изменяем запись в таблице с занесением нового хеша). И сразу сокращаем в два раза время на операцию сравнения.

                      Почему это важно (скорость)? Потому что задача на самом деле в поиске совпадений по ряду признаков (строки - коды по каким признакам есть совпадения) двух наборов данных. Один набор порядка 50млн записей, второй - ну несколько сотен тысяч записей. И сравнить надо каждую с каждой. Естественно, что там на каждом этапе такое вот - выбор самого быстрого варианта из всех возможных. С максимальным учетом специфики данных.

                      Все подобные задачи у нас прогоняются через PEX (Performance EXplorer). Где можно смотреть полную статистику, с разворотом стека - там будет видно какая функция сколько раз вызывалась, сколько процессорного времени и ресурсов занимает и т.д. и т.п.


                      1. 0xd34df00d
                        07.07.2023 08:59
                        #25735594
                        +2

                        Что внутри stdsort происходит? Разверните.

                        Компилятор может вычислить в рантайме некоторые даже весьма нетривиальные выражения, потому что ему это проще. В случае C — не может, даже если собирать код с -flto (чтобы определение qsort было доступно).


                        Вы уверены что там внутри не будет поэлементного сравнения "каждый с каждым"?

                        Там сложность O(n) amortized.


                        Плюс еще формирование наборов (там точно нет динамического выделения памяти под каждый элемент)?

                        Это — будет, но от них легко избавиться, если взять pmr'ные версии unordered_set (божечки, наконец-то поделия Лакоса пригодились, пусть даже и для бессмысленных комментариев на хабре!) вместе с этим. Из этого легко делается арена, делающая одну аллокацию на всё.


                        разворачивать-сворачивать стек тоже не бесплатно

                        Да, add и sub на современных процессорах очень дорогие.


                        На выходе сравниваем два целых числа.

                        Какой разрядности? Даже в uint64_t влезет только 64 разных возможных кода, а мне что-то подсказывает, что их может быть больше.


                        Если пойти еще дальше, то один набор хранится в таблице и может считаться один раз (при занесении в таблицу). и тогда хеш считаем уже не два раза, а один

                        Вы снова меняете условия. Естественно, если одна строка фиксирована, то её представителя (будь то unordered_set или ещё что) можно вычислить один раз.


                        Один набор порядка 50млн записей, второй — ну несколько сотен тысяч записей. И сравнить надо каждую с каждой.

                        Что за ерунда? Не нужно вам сравнивать каждую с каждой, конечно. Если вы построили ту самую табличку для каждой записи, о которой я говорил вначале (и вместо которой у вас каким-то магическим образом целое машинное число), то вы можете отсортировать тот массив записей (вернее, их представителей), что поменьше, и искать бинарным поиском в нём. Множества представителей изоморфны множеству классов эквивалентности исходных строк, поэтому здесь это одно и то же.


                        Теперь, если в одном массиве у вас n₁ (= 50 млн), а в другом — n₂ (= несколько сот тыщ) записей, то ваши попарные сравнения заставят пробежаться по n₁×n₂ байтам ваших чисел/табличек/етц (даже если вы все ваши «хэши» заранее подготовили), тогда как в случае с сортировкой нужно будет сделать O(n₂ logn₂) + n₁ logn₂ сравнений. В первом случае вы делаете 25 триллионов сравнений (для «несколько» = 5) «каждого с каждым», во втором — где-то немного больше полумиллиарда для любой разумной константы сортировки. То есть, во втором случае всё это вообще можно делать почти онлайн. Но вместо этого вы заботитесь о том, сколько xor'ов у вас будет при вычислении одного хэша.


                        А всё почему? А всё потому, что когда занимаешься байтоложеством и перепроверяешь, что ты там куда кастуешь из void*, то у тебя, как и у компилятора, нет времени думать об алгоритмических улучшениях.


                      1. 0xd34df00d
                        07.07.2023 08:59
                        #25735674

                        Олсо, за полчаса наваял


                        чё-т такое 
                        template<std::pair<char, char>... Alphabets>
constexpr auto PositionalFactors()
{
    constexpr std::array sizes { (Alphabets.second - Alphabets.first + 1)... };
    std::array<size_t, sizeof...(Alphabets) + 1> result { 1 };
    std::partial_sum(sizes.begin(), sizes.end(), result.begin() + 1, [](auto a, auto b) { return a * b; });
    return result;
}

template<std::pair<char, char>... Alphabets>
auto toSet(std::string_view s)
{
    constexpr auto factors = PositionalFactors<Alphabets...>();
    constexpr auto tableSize = (factors.back() + 7) / 8;
    constexpr auto codeLength = sizeof...(Alphabets);
    constexpr std::array starts { Alphabets.first... };

    std::array<char, tableSize> table { 0 };
    for (size_t i = 0; i < s.size(); i += codeLength)
    {
        size_t repr = 0;
        for (size_t j = 0; j < codeLength; ++j)
            repr += (s[i + j] - starts[j]) * factors[j];
        table[repr / 8] |= 1 << (repr & 0b111);
    }
    return table;
}

template<std::pair<char, char>... Alphabets>
bool sameCodes(std::string_view s1, std::string_view s2)
{
    return toSet<Alphabets...>(s1) == toSet<Alphabets...>(s2);
}

bool sameCodesSpec(std::string_view s1, std::string_view s2)
{
    return sameCodes<std::pair { 'A', 'Z' }, std::pair { '0', '9' }>(s1, s2);
}

                        — слишком долго тупил над тем, как там правильно в такой варьирующейся позиционной системе считать числа. Там наверняка ошибки есть в этом, потому что я отвык считать кроме как на палочках, но суть, надеюсь, понятна.


                        Компилятор генерирует почти такой же (с точностью до порядка операций) ассемблер, как если бы писать руками. Можно теперь такое же на сишечке, чтобы можно было настраивать алфавит каждой позиции в коде, и оно там всё само?


                1. 5nw
                  07.07.2023 08:59
                  #25733088
                  +1

                  Вы пытаетесь сравнить теплое с мягким и из этого делаете вывод, что C++ лучше)
                  Если мне не изменяет склероз, std::sort использует 3 алгоритма внутри: insertion_sort для мелких массивов, собственно qsort, и heap_sort если qsort начинает слишком глубоко проваливаться в рекурсию
                  Сравнивать его с голым qsort, естественно, нельзя


                  1. 0xd34df00d
                    07.07.2023 08:59
                    #25733100
                    +2

                    Стандарт не специфицирует конкретный алгоритм, по крайней мере, для std::sort, и стдлиб может реализовывать что ей захочется, покуда сложность соответствует стандарту. cppreference говорит, что с qsort аналогично.


                    Да и glibc'шный qsort, который используется выше, вполне себе счастливо также использует insertion sort: пруф.


                    1. 5nw
                      07.07.2023 08:59
                      #25733112

                      ОК, будем знать, что сишный qsort внутри может быть не совсем qsort
                      Но сравнение двух разных алгоритмов из двух разных библиотек все равно вызывает много вопросов, тогда уж весь код руками писать


                      1. 0xd34df00d
                        07.07.2023 08:59
                        #25733122
                        +2

                        Но сравнение двух разных алгоритмов из двух разных библиотек

                        Они все из одного семейства библиотек — glibc'шная libc и почти-glibc-шная libstdc++, которая идёт с gcc только потому, что у плюсов нет стандартизованного ABI и потому, что она больше зависит от фич языка.


                        Смысл-то ровно в том, что писать на С библиотеки, которые были бы юзабельными, переиспользуемыми и повторяемыми, мягко скажем, сложнее, чем на плюсах.


                  1. SpiderEkb
                    07.07.2023 08:59
                    #25733302
                    -2

                    Я уже написал выше - в данной конкретной задачке сортировка вообще не нужна :-)

                    Если же говорить о сортировках, то опять по задаче. Если речь идет о некоем кеше, который заполняется один раз и потом по нему 100500 раз что-то ищем - тут выгоднее сортированный массив.

                    Если идет постоянная работа с данными (добавили - ищем, удалили - ищем) - сортированный список ключ-данные где нет отдельной операции сортировки (новые данные сразу вставляются "по месту"). Хотя в целом поиск по такому списку насколько медленнее чем двоичный поиск по сортированному массиву, но в целом будет быстрее т.к. нет операции пересортировки после каждого изменения данных.


                    1. mayorovp
                      07.07.2023 08:59
                      #25733328

                      сортированный список ключ-данные где нет отдельной операции сортировки (новые данные сразу вставляются "по месту")

                      Это вы предлагаете вставлять данные сдвигая хвост за O(n) или как?


            1. 0xd34df00d
              07.07.2023 08:59
              #25732374

              Какие есть альтернативы для высокопроизводительного кода?

              Да хоть тот же хруст, хоть, если задача числодробильная, тот же хаскель.


              1. cat_chi
                07.07.2023 08:59
                #25732412
                -1

                "хруст" в смысле Rust?

                Ну что-то прям даже не знаю. Пока он не выглядит достаточно зрелым, чтобы всерьёз конкурировать с плюсами. Вот пока не созреет, "мертвец" наш будет бодреньким


                1. 0xd34df00d
                  07.07.2023 08:59
                  #25732436
                  +3

                  Ну хз, как тут зрелость измерять?


                  1. cat_chi
                    07.07.2023 08:59
                    #25732776

                    По тому, насколько хорошо компилятор соптимизирует плюс-минус похожий код.

                    Но вообще я не готов вступать на столь зыбкую почву :) Несколько месяцев хочу поиграться с растом и реализовать уже что-то серьёзное, но всё руки не доходят. Потому сейчас спорю не очень предметно


                    1. 0xd34df00d
                      07.07.2023 08:59
                      #25732796
                      +1

                      По тому, насколько хорошо компилятор соптимизирует плюс-минус похожий код.

                      Я периодически тут развлекаюсь бессмысленными бенчмарками разных вещей на сишке против хаскеля, и раст показывает вполне себе результаты в окрестности C. Что, в принципе, разумно: бекенд-то у него тот же, что и у clang.


                      Но вообще я не готов вступать на столь зыбкую почву :)

                      Я вообще в расте не разбираюсь так-то, что не мешает о нём дискутировать :]


                  1. k-morozov
                    07.07.2023 08:59
                    #25732984
                    +1

                    Ну хз, как тут зрелость измерять?

                    Устоявшейся memory model например.


                    1. 0xd34df00d
                      07.07.2023 08:59
                      #25733010
                      +1

                      Вы же в курсе, что ЕМНИП в C++20 изменили семантику для acquire и release, потому что чё-т там на арме неэффективно было?


                      1. k-morozov
                        07.07.2023 08:59
                        #25733026

                        Да изменили, но честности ради acq/rel все таки часть этой самой MM и не самая большая. В таком ключе полагаю можно все таки говорить об устоявшейся mm в С++.

                        Чего про rust пока нельзя сказать:

                        Rust does not yet have a defined memory model.


                      1. 0xd34df00d
                        07.07.2023 08:59
                        #25733084

                        Тут нужен комментарий AnthonyMikh. Как дела с моделью памяти в расте?


            1. X3_Shim
              07.07.2023 08:59
              #25732598
              +1

              открою страшную тайну. Действительно высокопроизводительные библиотеки в HPC и около пишутся до сих пор в основном на C, С + интринсики, ASM ну и да, до сих пор Fortran (ну это правда чуть меньше уже, но кода много на нем еще поддерживается в быстрой математике).


              1. cat_chi
                07.07.2023 08:59
                #25732762
                +1

                Тайну не открыли, но замечание полезное


          1. ioncorpse
            07.07.2023 08:59
            #25733908

            Ушел с С++ после boost. Да, отличная штука, как и все остальные прибамбашки. Но мозг ломает, особенно то, что компиляторы по разному работают. Но жить будет, С99 точно.


      1. cat_chi
        07.07.2023 08:59
        #25729268
        +3

        Есть подозрение, что дело вовсе не в C++, а в Qt. Точнее, не подозрение, а уверенность. "Чистый" C++ много где нужен. Наверное, везде, где важна высокая производительность. А вот если добавить к стеку Qt, то это сразу ограничивает нас десктопной разработкой... ну во всяком случае в России это было так, насколько я помню. А десктопная разработка на Qt в 2023... Ну знаете... Я бы даже не пытался искать. Особенно после начала войны, т.к. многие крупные компании, в которых ещё были действительно вкусные позиции на Qt, ушли из страны.

        Что до новых стандартов – ну ок, допустим. Вот писали мы в компании году, скажем, в 2018 на C++11/14/17. Именно в такой формулировке, потому что крайне сложно разделить эти стандарты. На выходе всё равно получается "С++11 с некоторыми фишками из 14 и 17". Вышел 20-й стандарт. Где-то через полгода мы начали его понемногу себе втягивать, по мере того, как его фичи начали поддерживаться компиляторами. Корутины попробовали, понравилось, можно пользоваться. А кардинально-то что изменилось? Ну кроме того, что мы прошли через традиционный геморрой перехода на новую версию компилятора и обновления всех библиотек, которые до того не обновлялись годами.


      1. SpiderEkb
        07.07.2023 08:59
        #25730838
        +2

        Ну, как правильно заметили уже "новый стандарт" в С++ это "мы тут поправили косяки, которые притащили в прошлом стандарте, добавили новых, плюс подсмотрели в языке ХХХ классную фичу и перетащили ее к себе".

        Что касается оплаты... Если работать только ради денег, то любая работа быстро надоедает. Когда сам процесс не доставляет удовольствия, напрягаться только ради результата все сложнее и сложнее.


      1. Wan-Derer
        07.07.2023 08:59
        #25733448

        Сам ушел с С++/Qt на Golang. Может с ситуацией импортозамещения что-то изменится....

        На мобильной ОС Аврора, как я понял, стек разработки как раз С++/Qt. Есть смысл поизучать. Если проект взлетит, будет очень много востребованной работы, хотя бы по переписыванию нужных приложений с других платформ.


    1. Kiel
      07.07.2023 08:59
      #25730784

      Теперь уже модно писать на react-next. И переписывать придётся очень и очень и очень много (


    1. Leetc0deMonkey
      07.07.2023 08:59
      #25730954
      +4

      Бро, переходи обратно к нам в мир C++

      Я очень сильно сомневаюсь что на современном рынке труда кому-то нужен плюсовик без 10+ лет свежего опыта. Сам язык и характер работы требует большого опыта. И нет готовых ждать несколько лет когда созреет вчерашний жавист или фронтендер. Если вообще созреет. Могу ошибаться, интересно посмотреть примеры обратного.


      1. ioncorpse
        07.07.2023 08:59
        #25733954

        Требуется стаж 10+ ассемблера.
        Сейчас 10+ С++? Проблема будет потом, лет через 10, программисты не знают, что делают, код пишет нейронка, требуется 10+ NoCode + AIw.


    1. ALexhha
      07.07.2023 08:59
      #25731226

      Docker существует уже 10 лет, по-прежнему цветет и пахнет, и никто от него не отказывается...

      ну как сказать, kubernetes, например, отказался, а это показательный пример


      1. geher
        07.07.2023 08:59
        #25731430

        А что теперь модно использовать вместо докера?

        Пока в живой природе ничего кроме докера в качестве средства "недовиртуализации" я не видел. А полноценная виртуальная машина тут вроде как перебор получается. Или я чего не понимаю?


        1. LeavemeAcKerman
          07.07.2023 08:59
          #25732482

          LXD есть как альтернатива докеру


          1. cat_chi
            07.07.2023 08:59
            #25732764
            +1

            LXD это:

            1. Вообще не докер. Если угодно, это что-то вроде аналога ovz – "дешёвая" альтернатива виртуализации.

            2. Говно.


      1. metamorph
        07.07.2023 08:59
        #25731448
        +3

        Нуууу, вопрос терминологии.

        Для создателей OCI-совместимых образов не изменилось чуть менее чем ничего. Как писали докерфайлы, так и будут писать.

        А исчезновение докершима и замена containerd на cri-o для рядового потребителя не особо видна, вроде.


    1. underdante
      07.07.2023 08:59
      #25732484
      -2

      Реакт был ООП подобный , сеичас функциональный. Перемены есть. И они скорее всего цикличны. Из ООП в функциональный и наоборот.


      1. mayorovp
        07.07.2023 08:59
        #25732666

        Вот как раз ООП-версия Реакта была функциональной (если смотреть на неё издалека и одним глазом). А современный Реакт не функциональный, а процедурный.


  1. mikelavr
    07.07.2023 08:59
    #25726956
    +9

    Вам в модный тэг #выгорание.


    1. kimor
      07.07.2023 08:59
      #25729304
      +1

      А вот у меня другое ощущение от текста. То что я прочел свидетельствует о мудрости автора и осознания суеты сует! Вероятно, пришло время засесть за докторскую или мемуары, или заняться еще чем-то "в вечность" -- пойти преподавать, например, в школу.


      1. berng
        07.07.2023 08:59
        #25731210
        +5

        поверьте, докторская тоже - суета сует, и проблем не решает, и уже тем более - преподавание. Проблема в том, что автор работает на дядю, а с такими проблемами пора заводить свой стартап и заниматься искусством ради искусства.


        1. AntoineLarine
          07.07.2023 08:59
          #25732546

          Много лет хочу так сделать, подташнивает от десктопной разработки. Но идей нет, что и кому можно продавать.


          1. lovermann
            07.07.2023 08:59
            #25733342
            +1

            Это абсолютно нормально. Кто-то готов пускаться в свои проекты в 20 лет, а кто-то в 60. Когда "оно" само придёт, тогда и придёт.


        1. MiraclePtr
          07.07.2023 08:59
          #25732722
          +2

          пора заводить свой стартап и заниматься искусством ради искусства

          Это только если у автора есть во-первых хорошая идея, которую можно продать, а во-вторых способности и большое желание делать бизнес, руководить людьми, заниматься финансами, вести переговоры, и т.д., потому что при запуске и руководстве стартапом всего этого там будет гораздо больше, чем искусства. А если такого желания или способностей нет, то выгорит он от этого ещё быстрее, чем от новых фреймворков, и просто впустую потратит время, деньги и нервы.


      1. Captain_Jack
        07.07.2023 08:59
        #25731952
        +8

        Скорее похоже на усталость, потерю собственного драйва и интереса, которая ведёт в консервацию "хочу как раньше, раньше было классно".

        Если в таком состоянии пойти преподавать или писать книги, то в них будет написано ровным счётом одно: "как же раньше было круто, почему сейчас всё стало не так, куда катится мир!"

        Таких преподавателей мы видели, и это печально. Учитель без искры в глазах, не заряжающий на рост, а брюзжащий, что ученики глупы и ничего им не нужно. Препод, который классно знает свою тему, но не может передать свои знания ученикам, а только демотивирует молодое поколение.

        Куда лучше поискать, где там завалялся твой драйв, и пойти зажигать других тем, что нравится тебе.

        При этом всё равно можно и нужно быть несогласным с полезностью ряда вещей в современном IT, это называется "иметь позицию". Но только не когда вся твоя позиция - старое как мир "раньше было лучше".


      1. vvzvlad
        07.07.2023 08:59
        #25734532
        +2

        пойти преподавать, например, в школу.

        А можно не надо, а? Он же детям в голову ровно этим и будет срать, а им еще жить потом в современном мире.


  1. panzerfaust
    07.07.2023 08:59
    #25727044
    +16

    выпускник 3-месячного буткэмпа знает больше, чем я, несмотря на мой опыт

    Заранее извиняюсь, но если интерн реально знает больше человека с опытом, то это человек не с опытом, а с потраченным временем. Опыт - он ведь по большей части в умении видеть в новом знакомые паттерны и вообще понимать, откуда и куда мы движемся. Если это в инженер есть, то он не будет говорить "зачем нужна кафка и котлин, если мы и на сях огого как писали". Как раз с опытом становятся видны резоны внедрения новых технологий, и так же их сильные и слабые стороны.


    1. MiraclePtr
      07.07.2023 08:59
      #25727062
      +5

      Я бы еще добавил, что крайне редко появляется что-то действительно революционное и принципиально новое, обычно происходит развитие старых идей. Разработчик, который уже знает пару UI-фреймворков, быстро разберётся с новым. Разработчик, который знает, как работают очереди сообщений, легко разберётся с новым брокером, который решили использовать в его проекте. Чем больше опыта, тем легче осваивается новое.


      1. Leetc0deMonkey
        07.07.2023 08:59
        #25730928
        +1

        Прошли времена охоты на "светлых голов", которые "разберутся". Сейчас всем нужны годы коммерческого опыта, вплоть до конкретных версий фреймворков и инструментов.


        1. MiraclePtr
          07.07.2023 08:59
          #25730936

          Годы безусловно нужны, а конкретные версии конкретных тулов обычно никто и никогда не требует.


          1. Leetc0deMonkey
            07.07.2023 08:59
            #25730972

            Скажем так, требуют самое последнее. Поэтому, задержался на несколько лет на проекте - считай проблемы с поиском новой работы. Это и C++ касается. Можно ответственно пилить на C++11, но на вакансию C++17 тебя уже завернут. Хотя там делов разобраться-то.


            1. MiraclePtr
              07.07.2023 08:59
              #25731006
              +1

              Можно ответственно пилить на C++11, но на вакансию C++17 тебя уже завернут

              Есть довольно много жизненных примеров, полностью опровергающих это смелое и ничем не подкреплённое заявление. Опытного разработчика на 11-х плюсах в проект на 17-х с руками оторвут. Именно потому что "там делов разобраться-то", а опыт и понимание базы не пропьешь.


            1. Nick0las
              07.07.2023 08:59
              #25731024
              +4

              А кто вас завернет? HR которая не увидит C++20 в резюме? Потенциальный коллега который сам относительно недавно перешел на новый стандарт? Или на собеседование специально прийдет C++ буквоед и завалит вас каверзными вопросами по стандартам? Командам обычно нужны люди которвм можно поручить задачи, с деталями стека, библиотек, проекта всеравно прийдется знакомиться. И стандарт языка тут зачастую совсем не главная сложность.


              1. Leetc0deMonkey
                07.07.2023 08:59
                #25731074
                +2

                HR и буквоед наиболее вероятные сценарии.


                1. sshikov
                  07.07.2023 08:59
                  #25731360
                  +3

                  Не дело HR — решать, что в проекте важно, а что нет. Если у компании такой HR — вам вероятно туда не надо.


                  Буквоед? Ну значит этому проекту видимо люди не нужны. Вам туда тоже не надо.


                  Ну то есть, эти сценарии — они реальные, но не страшные. Они с большой вероятностью показывают, что вам с этой компанией не по пути.


                  1. iig
                    07.07.2023 08:59
                    #25731390

                    HR должен проверять соответствование кандидата требованиям. Если в требованиях к вакансии написано именно C++20 - не ему решать, годится чел со знанием C++11.


                    1. sshikov
                      07.07.2023 08:59
                      #25731402
                      +2

                      Так я об этом и говорю. Если в компании HR бракует кандидатов сам, принимая такие решения — либо автор вакансии напрасно написал "C++ 20", либо HR занимается не своим делом.


                  1. SpiderEkb
                    07.07.2023 08:59
                    #25731394
                    +2

                    Один из моментов, который понравился ге сейчас работаю, HR делает только первичный отбор (достаточно широкий) кандидатов и передает резюме в команду.

                    Дальше уже команда решает кого собеседовать, кого нет. HR организует встречу, но собеседование только с командой. Тот кандидат, кого выбрала команда, уже "уходит" к HR который организует прием на работу до момента "встретить в первый день и привести на рабочее место".

                    Т.е. HR решает все оргвопросы, но в технических участия не принимает.

                    И собеседование только одно - с командой. Достаточно неформальное, без тестовых олимпиадных задач. Просто поговорить - чем занимался кандидат, чем занимаемся мы. Понятно, что могут быть какие-то технические вопросы, но не "на засыпку".

                    Все равно готового человека на эту платформу практически нереально найти. Так что первые три месяца будет обучение с наставником (формально - испытательный срок, но с полной оплатой и это больше чтобы понять сработаемся или нет, научить азам, ну и самому человеку понять что к чему)


                    1. sshikov
                      07.07.2023 08:59
                      #25731406
                      +1

                      Именно так. У нас другая платформа, но примерно такой же подход. Готовых специалистов практически нет в живой природе.


                      1. SpiderEkb
                        07.07.2023 08:59
                        #25731778
                        +1

                        У нас IBM i и RPG (на котором пишется более 80% кода под эту платформу). Готовых разработчиков в стране... Ну сотни три-четыре. Может пять. И все они так или иначе трудоустроены.

                        А платформа ну очень специфическая, радикально не похожая ни на что другое. Много тонкостей и особенностей на понимание которых может уйти год-два.

                        А требования к качеству и эффективности достаточно высокие - система высоконагруженная и при этом много задач класса mission critical.

                        Так что выход один - искать человека с хорошим опытом разработки и обучать самим.


                      1. gluck59
                        07.07.2023 08:59
                        #25732342

                        Скорее всего такому человеку будет 40+ (а то и 50+), что автоматически означает "резюме не прошло HRа"...


      1. Scott_Leopold
        07.07.2023 08:59
        #25732500
        +2

        Автор же не пишет, что он не может разобраться. Он пишет, что его достало количество "штук", в которых надо дополнительно разбираться.


      1. DmSting
        07.07.2023 08:59
        #25732864

        Выскажусь с позиции человека, который в разработке просто "мимо стоял" - а нафига нужно новое, если оно не исправляет ошибок или не ускоряет/упрощает работу старого?

        Это будет пустое заучивание, без прогресса в использовании. Этак можно IF менять на FI, а else на esle каждые два года и говорить потом что это-то вот истинный прогресс, ёптэ!


        1. cat_chi
          07.07.2023 08:59
          #25733058
          +3

          а нафига нужно новое, если оно не исправляет ошибок или не ускоряет/упрощает работу старого?

          Новое, которое ничего не исправляет и не улучшает – это что-то крайне редкое. На уровне погрешности. А так почти в 100% случаев что-то новое создаётся с какой-то целью.

          И так же в 100% случаев у любого новшества почти мгновенно появляется армия фанатов и армия хейтеров


  1. irod87
    07.07.2023 08:59
    #25727114
    +5

    Очень понимаю автора, тоже в какой-то момент от кодинга стало воротить. После нескольких (на самом деле больше) тяжелых лет метаний, работы на нелюбимых работах и параллельного изучения математики успешно перекатился в data science. Теперь изучаю/применяю соответствующие алгоритмы, и математики еще столько что на всю жизнь хватит - вот где я нащупал свой интерес. К кодингу больше не отношусь серьезно, просто применяю в работе, а так чтоб прям сесть и изучать язык или фреймворк - да ну нахер эту скукоту, я просто осваиваю это в процессе работы надо задачами.


    1. leafup
      07.07.2023 08:59
      #25730922
      +2

      >> После нескольких (на самом деле больше) тяжелых лет метаний, работы на нелюбимых работах и параллельного изучения математики успешно перекатился в data science.


      Что конкретно вы используете в DS ? Статистика ? А что еще там вы используете? Интересно просто.


      >> Теперь изучаю/применяю соответствующие алгоритмы, и математики еще столько что на всю жизнь хватит - вот где я нащупал свой интерес.


      А какие алгоритмы если не секрет?


      >> К кодингу больше не отношусь серьезно, просто применяю в работе
      Вы используете Python?


  1. bubn0ff
    07.07.2023 08:59
    #25727274
    +3

    Всё правильно говорит автор. С такой проблемой каждый айтишник сталкивается, особенно разработчик. Угнаться за всеми требованиями невозможно, да в этом и нет смысла - всё равно будешь далеко позади. Вообще непонятно - куда так все торопятся в плане разработки? Обогнать конкурентов? А дальше что? В итоге копится нехилый технический долг плюс дикая усталость наравне с выгоранием и отсутствием мотивации.


    1. Wan-Derer
      07.07.2023 08:59
      #25734084

      А я вот не понял причину плача. Почему-то константой считается необходимость скорой смены работы. А почему собственно? Что мешает оставаться на полюбившемся проекте и развивать его с помощью полюбившихся инструментов, обновляя их строго по мере необходимости?

      Ну а если реальная необходимость переходов есть, то изволь соответствовать требованиям тех кто рулит в тех местах.

      По-моему, всё просто. Не?


  1. vagon333
    07.07.2023 08:59
    #25727792
    +1

    Хочу жить как человек, а не сидеть за компом 24/7, чтобы оставаться в теме.

    Крипту не пробовали? :)

    Если серьезно, может не 24/7, но мне интересна тенхо-струя.
    Каждое утро - Хабр без фильтра. Иногда заминусованные статьи вполне интересны, просто иное мнение, а сейчас тепимость на плинтусе.
    Каждый новый framework интересно оценить и сравнить.
    Каждая новя технология увлекает новыми перспективами и возможностями.
    В IT 30+ лет, и это не ageism, а объяснение что для меня IT работает.
    Да, ежедневный зал - обязательно. Иногда дважды в день, иначе здоровью кирдык.


  1. homm
    07.07.2023 08:59
    #25728218
    +21

    Принципиально не трогал Докер много лет, не хотелось вкладываться во что-то, не понимая, что оно дает. Прекрасно себя чувствовал всё это время. Потом в какой-то момент все же разобрался, стал чувствовать себя ещё лучше. Теперь докер почти такой же дефолтный инструмент для любого проекта, как git. С кубером недавно решил разобраться, тоже оказалось довольно полезно.

    Я к чему. Не хочется — не надо. Придет время или крайняя нужда — познакомитесь.


    1. mayorovp
      07.07.2023 08:59
      #25728290

      Опасная идея. Я вот недавно работу искал, так когда хрюши узнавали что я ни одного микросервиса не написал — отказывали сразу же.


      1. 0xd34df00d
        07.07.2023 08:59
        #25729714
        +3

        Не так давно вбросил резюме на одну хаскель-вакансию. У меня там, собсна, хаскель, идрис, агда, завтипы, всякая прочая ерунда. Эйчарка на созвоне, по смыслу: «а sql-запрос-то написать смогешь?»


        1. cat_chi
          07.07.2023 08:59
          #25731682
          +2

          Ну так смогешь? ;)


          1. 0xd34df00d
            07.07.2023 08:59
            #25732382
            +3

            Ща, как раз постгрес-байндинги для идриса допилю и смогу.


            1. Wan-Derer
              07.07.2023 08:59
              #25734104

              Этта...

              select * from USER;

              Каков вопрос - таков ответ :)


        1. mello1984
          07.07.2023 08:59
          #25732502
          +1

          Вы хотите понимания технологий от HR, которая делает скрининг по ключевым словам? Понятно же, что это просто первичный фильтр, который надо просто пройти. Странно на это обижаться / удивляться этому. У нее в работе тоже, наверное, есть нюансы, которые ей очевидны, а вам - нет...


      1. cat_chi
        07.07.2023 08:59
        #25731684
        -1

        Вообще интересно, а почему вообще хрюши отказывают? В нормальной компании это не их полномочия. Их задача искать кандидатов, а не отсеивать


        1. Leetc0deMonkey
          07.07.2023 08:59
          #25732056
          +2

          Потому что техлид хочет с запасом и швеца, и жнеца, и на дуде игреца, а HR если не видит в резюме требуемого условного C++20, то отправляет его в помойку. Да, резюме должны выбирать строго разрабы, а HR проводить лишь административную работу. Но в реале имеем то что имеем.


          1. cat_chi
            07.07.2023 08:59
            #25732402
            +2

            В общем, хорошие эйчары должны быть как дельфины. Никто не должен знать о кандидатах, которых они утопили :D


            1. randomsimplenumber
              07.07.2023 08:59
              #25732612

              Никто не должен знать о кандидатах, которых они утопили :D

              Неудачники нам не нужны (ц) :D


          1. MiraclePtr
            07.07.2023 08:59
            #25732730

            Потому что техлид хочет с запасом и швеца, и жнеца, и на дуде игреца

            Если техлид не идиот, то он прекрасно понимает, что с таким набором требований искать нового разработчика он будет ещё два года (если только это не вакансия в каком-нибудь MAANG'е, но что интересно, они как раз таким не страдают), и все это время в его команде будет не хватать рабочей силы. Поэтому в требованиях к кандидату будет написано просто "C++", а конкретный стандарт будет упомянут разве что в разделе "would be nice to have", и это не будет заградительным фильтром при отборе эйчарами.


            1. cat_chi
              07.07.2023 08:59
              #25732772

              Я примерно так и отбирал. В итоге HR (золото, а не HR) довольно бодро опрашивала кандидатов по ключевым вопросам, вплоть до того уровня, что она могла реально оценить, умеет ли человек в C++ или пи... лукавит. А потом давала очень качественный фидбэк. В т.ч. по кандидатам, которые её не впечатлили, т.е. отсевом не занималась


            1. 0xd34df00d
              07.07.2023 08:59
              #25732806

              если только это не вакансия в каком-нибудь MAANG'е, но что интересно, они как раз таким не страдают

              Но не потому, что они все такие мудрые, а потому, что у них в почти всех командах непосредственно технически-языковой уровень очень низкий. Да, если вы пойдёте лично в команду к Чендлеру Карруту пилить там clang, то у вас будет шанс блеснуть знанием языка, но в среднем… в среднем не оч.


              А вот в тех компаниях, что зарабатывают деньги в играх с нулевой суммой за счёт высокой производительности и знания языка (HFT, например) — там вполне себе могут ожидать C++20/23. Да, там готовы дать послабление сильному разрабу и без самых свежих стандартов, но скорее потому, что и уметь плюсы хорошо, и быть готовым к hft'шной потогонке может околонулевое количество людей.


            1. Leetc0deMonkey
              07.07.2023 08:59
              #25733226
              +1

              Если техлид не идиот

              Ключевое слово - если. Этот техлид ещё и выть потом на весь интернет будет как якобы мало толковых и какой якобы жуткий дефицит кадров.

              "would be nice to have", и это не будет заградительным фильтром при отборе эйчарами.

              Так кандидат с интересным бэкграундом проиграет тому у кого точно есть "would be nice to have". Всё же "рыбак рыбака видит издалека" и первичный отбор должны производить строго технические специалисты.


    1. mbait
      07.07.2023 08:59
      #25730756
      -1

      Вопрос как к разобравшемуся с Docker: чем это лучше chroot или systemd-nspawn? Использую последние два в работе. Почитал про Docker и не понял, зачем оно мне.


      1. mayorovp
        07.07.2023 08:59
        #25731164
        +3

        У докера есть репозиторий (dockerhub) и докерфайлы, которые позволяют описать процесс создания образа с нуля и положить его в гит. И ещё есть docker compose, позволяющий декларативно описать частично изолированную группу контейнеров, что сильно помогает при возникновении желания "потрогать" фичу до слияния в основную ветку.


        1. mbait
          07.07.2023 08:59
          #25731638
          -2

          Я так полагаю, что docker compose это набор bash/python скриптов? Репозиторий есть и для контейнеров systemd. А какие-то фундаментальные различия есть? Я сходу не нашёл, как в Docker настроить сеть между хостом и контейнером с различными уровнями узоляции.


          1. iig
            07.07.2023 08:59
            #25731764

            в Docker настроить сеть между хостом и контейнером с различными уровнями изоляции

            Вряд ли. Это для изоляции процессов скорее. На nftables наверное можно наваять то что нужно.


          1. mayorovp
            07.07.2023 08:59
            #25732250
            +3

            Нет, docker compose это вообще не набор bash/python скриптов. Проекты compose декларативны, скрипты императивны.


            Что же насчёт сети — что вы вообще вкладываете в понятие "уровня изоляции сети"?


      1. iig
        07.07.2023 08:59
        #25731222
        +1

        чем это лучше chroot

        Приблизительно всем. В смысле изоляции от chroot мало отличается. Но если нужно масштабировать за пределы localhost - chroot категорически не годится.


        1. mbait
          07.07.2023 08:59
          #25731614
          -2

          Хотите сказать, что если я сделаю образ файловой системы, затем смонтирую этот образ на каждый узел в сети и запущу chroot, то это в корне будет отличаться от использования Docker? Что насчёт systemd-nspawn?


          1. iig
            07.07.2023 08:59
            #25731736
            +4

            Во первых это самописный костыль, который нужно запилить и поддерживать. Во вторых, uid/gid файлов внутри chroot должны одинаково соответствовать uid/gid на каждом хосте - очень желательно чтобы все хосты были одинаковые. А вносить изменения в это будет совсем интересно ;)

            docker - установил, работает. Всё ;)


      1. cat_chi
        07.07.2023 08:59
        #25731824
        +2

        Тем, что для быстрого погружения в docker не надо в нём разбираться. И вообще думать не надо.

        А это однозначный плюс, потому что чем меньше специалист думает о рутинных проблемах, тем больше мыслетоплива у него остаётся на что-то полезное.

        P.S. Конечно, при дальнейшем погружении понадобится изучить docker поглубже (и ужаснуться ???? ). Но это будет уже в рамках улучшения того, что уже работает...


  1. EvilsInterrupt
    07.07.2023 08:59
    #25729812
    +3

    А может вам и не надо в ИТ? Не надо программировать? Как бы это вам сказать, если человеку нравится бегать. Улучшать свои показатели в беге, то вопроса, а зачем нужны упражнения СБУ у него не будет! В программирование надо идти, когда тебя от всех этих "шестеренок" прет и не важно, что шестеренка1 похожа на шестеренку2 изученную ранее. Понимаете? Занимайтесь программированием ради самого программирования!


    1. Anton-V-K
      07.07.2023 08:59
      #25732860
      +2

      А может вам и не надо в ИТ?

      Птичка Автор уже внутри ИТ :) Не исключено, что на синьорской позиции или типа того. К нему, похоже, пришло понимание, что количественный рост (профессионализма) достиг фазы насыщения (пресыщения), а как расти качественно, он пока не вкурил, и в его окружении подсказки ждать не от кого. Об этом и сказ.


  1. eton65
    07.07.2023 08:59
    #25730184
    +6

    Хочу жить как человек

    Так люди так много не зарабатывают.


  1. i360u
    07.07.2023 08:59
    #25730402
    +12

    Так и в чем проблема, если у всех модных технологий под капотом все те-же "вечные" принципы? Наоборот ведь, хорошо: все должно быть знакомо, ничего не должно пугать... Любой UI-фреймворк - это компоненты, шаблоны, привязка данных, контроль жазненного цикла... Какая разница, для опытного инженера, как оно там называется?

    Мне 44 года, я, можно сказать, уже динозавр в веб-разработке, но меня вообще не беспокоит динамика изменений. И даже наоборот, я вижу, как многие вещи взрослеют и становятся, наконец, такими, какими они должны быть. И за этим приятно наблюдать.


    1. gluck59
      07.07.2023 08:59
      #25732346
      +1

      Какая разница, для опытного инженера, как оно там называется?

      До опытного инженера вы просто не дойдете. Эйчарша не пропустит — не увидит знакомых буковок в резюме.


      1. dim111
        07.07.2023 08:59
        #25732404
        +1

        В MAANG никого не волнует какой там у вас стек в резюме и опыт на модных технологиях.

        Сможете рассказать содержимое книг от Таненбаума и Кнута и прорешать литкод задачи на харде с ходу. Будет вам работа на 200-300к долларов в год. Нет Ну значит вы свои инженерные навыки глубокого computer science явно переоценивайте и проблемы не в Эйчарах

        Попасть на собеседования в такие компании легче легкого. Пройти алгоритмическую часть, вот тут большинство сыпется. Но потом жалуются что "Я инженер с 30 годами опыта и не хочу учить модный стек"


  1. dedmagic
    07.07.2023 08:59
    #25730754
    +8

    Многие из нас начинали просто с изучения HTML, CSS, JavaScript. Не было фреймворков, хватало знания этих трёх фундаментальных технологий для написания сайтов. С ними ты мог создать что угодно. Теперь же потенциальные работодателя от тебя требуют знания (и опыта работы!) с Vue.js, React, Angular, Svelte, Webpack, Tailwind, и ещё с десяток какой-то ерунды.

    Не ставлю под сомнение основной посыл статьи, но вот это вот сравнение некорректно.

    Сложность современных фронтенд-приложений несопоставима с тем, что писалось тогда. Попробуйте сейчас на нативном JS, без фреймворков – будет очень больно и, скорее всего, закончится провалом.


    1. PrinceKorwin
      07.07.2023 08:59
      #25731020

      Не согласен. Я вот буквально три месяца назад делал свой небольшой веб-проект.

      Специально использовал чистый JavaScript. А до этого голый JS (+jQuery) использовал лет наверное 15 назад. И должен сказать новая версия языка приятно удивила. Очень многое можно уже делать на нем и не плеваться не привлекая сторонних библиотек типа jQuery.

      Да и CSS изменился в лучшую сторону.

      В общем сделал на голом JS все и доволен результатом.

      Правда и проект небольшой и есть опыт/понимание как нужно код и данные размещать.


      1. MiraclePtr
        07.07.2023 08:59
        #25731032
        +1

        При желании можно и бэкенд на ассемблере писать, кто же запрещает, ровно как и писать фронтенд на чистом JS без фреймворков. Основной вопрос, сколько лишних телодвижений и boilerplate-кода придется навернуть при этом для элементарных вещей (MVVM-байндинги, валидация для форм, маршрутизация для SPA, и т.д.).


        1. PrinceKorwin
          07.07.2023 08:59
          #25731056
          +3

          У меня там 5 экранов. С небольшой интерактивностью. Проще и быстрее на JS это запилить в 7Кб, чем тянуть фреймворки.

          Я стараюсь использовать принцип минимализма и не усложнять решение без нужды.


          1. gluck59
            07.07.2023 08:59
            #25732368
            +4

            Инженерный подход. Жму лапу.


          1. Skomich
            07.07.2023 08:59
            #25732426
            +1

            Согласен с вами. Уже достало каждый раз при открытии сайта, у которого контента на 2-3 страницы и больше никакого функционала, видеть размер его в 30+ мб и это без картинок… А вообще непонятно почему в современном вебе вся верстка до сих пор передается строкой!? Если бы это компилировалось, то занимало бы раз в 10 (а на крупных проектах еще бОльшая разница) меньше места. Да и работал бы js быстрее через байт код, условный, а не через «читаю - исполняю».


            1. Wan-Derer
              07.07.2023 08:59
              #25734246
              +1

              Чего там такого на мегабайты? Я недавно делал проект на Angular + Bootstrap, как раз на несколько экранов. В собранном виде около 300 кб. Остальное-то что? Неужели столько сео-шной хрени? :)


            1. theWaR_13
              07.07.2023 08:59
              #25734332
              +1

              Ну вот вы прям каждый раз сидите с открытыми девтулзами и смотрите размер загружаемого бандла? Я могу понять, когда человек уехал куда-нибудь в лес и там медленный интернет и сайт грузится одну минуту. Но в городах интернет уже вроде бы достаточно быстрый и особой разницы между 7КБ и 30МБ не замечаешь.


              1. vvzvlad
                07.07.2023 08:59
                #25734552
                +1

                Очень хотелось бы пожелать тем, кто не замечает разницы между 7КБ и 30МБ пойти в задницу пожить месяц на спутниковом интернете.


              1. 0xd34df00d
                07.07.2023 08:59
                #25735598

                Для того, чтобы у меня сайты грузились по минуте, мне не нужно уходить в лес — достаточно отойти с электронной читалкой на 10 метров от точки доступа (например, прилечь почитать во дворе), или попытаться воспользоваться мобильником в парке.


    1. gluck59
      07.07.2023 08:59
      #25732354

      Например в B2B, где не нужны немыслимые анимации, поблескивающие кнопки, тени в три экрана и прочие свистоперделки — легко и непринужденно.


      1. MiraclePtr
        07.07.2023 08:59
        #25732530
        +1

        В B2B обычно много форм для отображения и ввода, и писать вручную без фреймворков MVVM-байндинги, валидацию и подобное для них - то ещё "удовольствие".


  1. SpiderEkb
    07.07.2023 08:59
    #25730858
    +1

    Ну что ж... Я бы советовали все-таки искать что-то более низкоуровневое и более стабильное.

    Предложений не сказать чтобы на каждом углу, но их есть. Всякие системные вещи (преимущественно по Linux) сейчас поднимают голову. Из того, что мне предлагали в последнее время:

    • разработка сетевых приложений и модулей ядра, обрабатывающих сетевой трафик под Линукс

    • разработка аналога Active Directory на основе SAMBA под Линукс

    • работа с ПЛК в области нефтегазового сектора

    ну и еще что-то подобного плана. Везде С/С++, много где Линукс на уровне системы. Минимум фреймворков.

    Уровень оплаты... Ну так скажем не нищенская, где-то в середине рынка, хотя и не топовая. Но проекты точно не рутинные - многое с нуля и вход в проект на начальном его этапе.

    Ну или посмотреть какое-нибудь легаси типа банков (только самый нижний слой - центральные системы, то, что работает на уровне ядра АБС на центральных серверах - там не будет фреймворков, зато будет много замороченной бизнес-логики с высокими требованиями по производительности). Правда, там могут оказаться специфические языки всякие. Лично я оказался именно в этой области (попал можно сказать случайно, но затянуло - оказалось что это реально интересно - и платформа специфическая и язык основной, хотя и С/С++ тут тоже есть, и каждая вторая задача - головоломка в плане "как сделать это еще быстрее и эффективнее").

    Или обратить взор в сторону промавтоматизации. Но там, говорят, платят совсем немного. Но скучно точно не будет.

    Короче говоря, искать себе интересный проект. Да, придется поискать, но найти можно.


    1. MiraclePtr
      07.07.2023 08:59
      #25730942
      +1

      Или обратить взор в сторону промавтоматизации.

      С этим надо очень осторожно. Может оказаться оооочень "на любителя", как в плане зарплат и отношения к работникам, так в плане процессов разработки в целом. Реальность, увы, такова, что из АСУ ТП и всякого кустарного эмбеддеда народ массово валит куда угодно, хоть даже в веб-дев и кровавый энтерпрайз, лишь бы подпльше. Здесь на Хабре уже было немало грустных реплик в комментариях по этому поводу.


      1. SpiderEkb
        07.07.2023 08:59
        #25730984
        +2

        Да, согласен. На так давно было про это. Так что это последний вариант, наверное.

        Я в свое время отдал этому значительную часть своей жизни (Система Мониторинга Инженерного Оборудования Зданий) - было безумно интересно т.к. начинали в 93-м году, абсолютно с нуля (в стране не то чтобы аналогов не было, не было даже идей что такое возможно как-то). И по деньгам некоторое время было неплохо. Потом по деньгам застопорился рост, какое-то время на энтузиазме и гордости (столько времени потратили, не гоже бросать) держались, но в какой-то момент довели очередную версию до прома и решили что все, хватит.

        Случайно попал в банк (хотя этот вариант не рассматривал вообще, но позвали сами, решил просто сходить на собес, что называется, "жалом поводить" и вдруг понял что хочу). И зацепило. Да, дремучий легаси, да никаких фреймворков (кроме тех, что сами себе сделали), да, кровавый энтерпрайз.

        Но при всем этом очень необычная и интересная возможностями (низкоуровневыми в том числе) платформа, достаточно интересный язык (процедурный, типа классического Паскаля на первый взгляд, но когда зарываешься в него глубже понимаешь, что там очень хорошо развиты возможности описания структур данных и это достаточно мощный язык для разработки бизнес-логики при всей его внешней простоте).

        Поначалу, конечно, достаются рутинные задачки. Те, что делаются по стандартным шаблонам (скелетонам, как их тут называют) - берешь готовый шаблон, переименовываешь, наполняешь нужными структурами и переменными и готово.

        Но потом начинают подкидывать уже реально интересное и нестандартное. Обычно такое, что требует разработки высокоэффективных алгоритмов и предельной оптимизации. И тут уже надо разбираться - можно так, а можно этак, но вот так будет работать быстрее. Там можно вместо двух циклов в один уложить, здесь что-то закешировать на входе один раз, потом из памяти тянуть. Где-то быстрее прямым обращением к таблицам БД, а где-то скулевым запросом (язык позволяет скули непосредственно в код интегрировать). А где-то комбинируешь - быстрее не втаскивать в скуль всю логику с различными group by и агрегатными функциями, но сделать его попроще, а данные уже просеивать в процессе обработки... И приятно видеть когда выкидываешь старый модуль, который 30 секунд работал, пишешь свой и видишь что он то же самое делает за 3 секунды...


        1. gluck59
          07.07.2023 08:59
          #25732392
          +2

          Но потом начинают подкидывать уже реально интересное и нестандартное.

          ...а потом в личке объявляется эффективный менеджер и заявляет "ты написал в джире что потратил целых 8 часов на старинную задачу на которую три года все забивали!!! мы не можем столько платить!!! укажи там два часа и больше никогда не пиши столько!!!"
          Не далее чем в апреле с таким столкнулся...


  1. ALexhha
    07.07.2023 08:59
    #25731230
    +5

    Хотел конкретно изучить Docker, но уже поздно - он больше не в моде, теперь же есть Kubernetes, Ansible, и ещё чёрти сколько технологий, которые я никогда не изучу.

    Хотел я научиться плавать, но смотрю что гироборды больше не популярны. Если что, k8s/ansible не имеют особого отношения к Docker


  1. duke_alba
    07.07.2023 08:59
    #25732244

    Да, появляется много чего... Однако опыт как раз и нужен для того, чтобы сравнительно быстро понять, для чего эта штука придумана и стоит ли тратить время на её изучение? И вдруг выяснится, что в интересующей Вас области не так много и происходит...


  1. Mox
    07.07.2023 08:59
    #25732338
    +1

    Тут два решения - внутренее и внешнее (условно)

    Решение "внешние" - выбирать не технологии которые меняются раз в 3 года, а выбрать какой-нибудь rust, или go, которые будут еще десяток лет спокойно и неспешно разиваться.

    Решение "внутренее" состоит в том, чтобы перестать циклиться на том на чем написан продукт и думать о продукте, фичах и как его развивать. Для этого лучше работать в продуктовых компаниях. Тогда пофиг на чем писать, а если и захочется новый фреймворк, то с позиции "ту фичу которую я дебагал тогда 2 недели теперь можно за пол дня написать". Совсем другая мотивация для изучения чем "теперь надо что-то новое".


  1. czz
    07.07.2023 08:59
    #25732356
    +3

    Многие из нас начинали просто с изучения HTML, CSS, JavaScript. Не было фреймворков, хватало знания этих трёх фундаментальных технологий для написания сайтов. С ними ты мог создать что угодно. Теперь же потенциальные работодателя от тебя требуют знания (и опыта работы!) с Vue.js, React, Angular, Svelte, Webpack, Tailwind, и ещё с десяток какой-то ерунды. И с каждым днём кажется, что ты отстаёшь всё больше.

    Ну хз. Не мог тогда создать все что угодно. Все убогое было. Netscape, IE6, Opera, фреймы всякие, верстка на таблицах, Ajax с горем пополам через long polling, Perl, PHP 3, CGI, RealVideo, Adobe Flex. Современные веб-технологии дают в сотни раз больше возможностей. Наоборот, есть ощущение, что с каждым днем можешь все больше с новыми инструментами.


  1. SerJook
    07.07.2023 08:59
    #25732406
    -3

    Да не беспокойтесь вы так, не надо никуда спешить, скоро программистов заменит ИИ и спешить придется лишь в очередь за пособием по безработице.


  1. POMXARK
    07.07.2023 08:59
    #25732506

    Согласен, это так заэбало, уже год как в веб разработке. А уже с такими же ощущкниями


  1. WebPeople
    07.07.2023 08:59
    #25732510
    +2

    Я думаю, что автору надо не язык разработки менять, а сферу, либо пообщаться с коллегами на эту тему.

    У меня есть знакомые сеньоры, они делают типовые задачи, с которыми джуны и мидлы могут провозиться пару недель, за 1-3 дня. И им тоже скучно всем этим заниматься. Поэтому они ищут себе не работу с высокой зарплатой, а работу, которая им интересна. Т.к. зарплата на их уровне и так высокая. И они даже не пытаются изучить абсолютно все. Зачем им знать вью или новомодный го? Достаточно лишь обзорно ознакомиться с ним, чтобы иметь представление что это.

    А вот к чему они стремятся, так это к интересным им задачам. Кому-то нравится лидить и обучать других, помогать менее опытным коллегам, кто-то уходит в анализ данных и машинное обучение, кто-то в прикладные задачи (например, сельхоз дроны, компьютерное зрение и т.п.). В общем, каждый ищет себе свой интерес. А само программирование это лишь навык, позволяющий решать эти интересные задачи.


    1. vldmrmlkv
      07.07.2023 08:59
      #25733080
      +1

      Ещё бы добавил, что навык программирования универсальный и это даёт преимущество в скорости изучения новых языков, фреймворков и, уверен, даже докера и кубера(на уровне пользователя). А вот зачем разработчику ansible не понял, такое обычно только админам нужно.

      Ещё состояние когда пытаешься за всё хвататься и ничего не успеваешь похоже на FOMO(Fear of missing out;) - прямой путь к выгоранию.


  1. AzIdeaL
    07.07.2023 08:59
    #25732650
    -1

    Пятничный вызов] перекур. Надоело программировать

    так ответил в бюро пропусков привлеченный из-за периметра соискатель на сезонную позицию слесаря МСР по сборке изделий тройного назначения.

    !?

    Ну, тыж со своим С# и С+ по деньгам просядешь!!

    Ну и что, говорит, -- зато руки от Клавы и мыши, да глаза от компа отдохнут.

    ЗЫ: ничто, что со своими метизации побрегсад?)))


  1. MaM
    07.07.2023 08:59
    #25733250
    -2

    Ну почти, вывод немного неверный. Вообше нужно называть все своими именами. Никакого культа знаний нет, в реальности это способ создать нервозы, никакой команды и семьи нет, есть коллективная ответственность, никакой инженерии нет, есть капитализм. Никому не нужен софт, точка, нам насрать на всех, точка, нам нужны бабки, точка.

    Конечно айтишников это все раздражает люди которые намного глупей их, неспособны вообше что либо создавать паразитирует на труде айтишников. Все эти эйчарки и менеджеры в реальности обсолютно не нужны. Почти каждая эйчарка это девочка 18 лет которая отсидела в педаузе или международном праве, ну или в языках.

    Их прибавочная стоимость смехотворна. Большинство из них были наняты из за вешности.

    Менеджеров не знают даже азов управления, из разряда задачу нужно делать на независимые и тд и тп Всё что они делают это паразитруют.

    Тоесть меня нанимает какая-то гуляшая кукла, а управляет алигофрен "ну че там?".

    Причём, если начать работать как следует, за каждым предложением имя, у каждого внедрения ответственный, за каждый факап наказывать. Мы уволим просто треть. Но в реальности, они не способными применять к себе же свой подход, потому что, изначально не хотят работать, их цель паразитация на чужом труде (сиди получаем деньги, пока эти мартышки пашут).

    Большинство фирм это веб галеры - современные конвееры 21 века, а большинство программистов это обезьянки. Добро пожаловать в Sity 17. Скоро все буду за миской риса пахать за 500, пока не помрут как та тестировшица. Просто имх, наивные пони айтишники, которых капиталисты вместе с ХР шоблой и магагерами посадили на цепь как животное и доят

    P.S. Никуда не нужно торопится, перерабатывть, получать копейки.Берегите себя, своих близких и свое здоровья. Разговаривать и играть в их игры не нужно, щуллер всегда обманет. Бейте на упражнение первыми как видите, что вас собираются поиметь.

    И да, не верьте коммунистам и либералам, они нас обязательно придадут, просто берите свое силой


    1. MiraclePtr
      07.07.2023 08:59
      #25733450
      +2

      Все эти эйчарки

      Задача эйчара - разгрести стопку присланных резюме (отсеяв неподходящих по критериям, которые передали ей программисты), созвониться/списаться с кандидатами, уточнить важные вопросы (сколько хочет, когда готов, где находится), согласовать время интервью, и т.д. Логично, что пусть лучше этим занимается HR, а не самим программисты будут тратить на это свое рабочее время (которое стоит многократно дороже, да и заниматься этим им не интересно). Плюс HR для уже устроенных людей в нормальной фирме - это этакий саппорт, в плане сделать все нужные бумажки и подписи, получить нужные справки, оформить всякие бенефиты (фитнес-карты, мобильный тариф со скидкой, и т.д.), короче говоря этакий single contact point для всех сервисов внутри компании, напрямую не относящихся к производству.

      менеджеры в реальности обсолютно не нужны

      Это у вас просто менеджера нормального не было. Нормальный менеджер очень неплохо уменьшает количества хаоса в процессах разработки и работе команды, берет на себя коммуникацию с заказчиками/стейкхолдерами, другими отделами, планирование, и кучу всего другого - короче говоря, обеспечивает и помогает, чтобы у команды было все необходимое для их работы, доводит до них четкое понимание того, что от них требуется сейчас и что ожидаетчся в будущем, уменьшает количество рутины и узких мест в процессах, и т.д. Если вам не встречались нормальные менеджеры - то вы что-то в жизни делаете не так.

      либералам

      Либералы = приверженцы либеральных взглядов, считающие права и свободы человека высшими ценностями, в том числе свободу слова, свободу совести, неприкосновенность частной собственности, верховенство закона и равенства всех граждан перед законом. Вы против всего вышеперечисленного?


      1. MaM
        07.07.2023 08:59
        #25733470
        -3

        Это словоблудие, обман и шиза, зарплата одной хрюши примерно как у мидла 3к, загон обычно состоит из 3 голов, отсюда они за 8 месяцев закрывания сожрут несоизмеримо больше, чем просто мидла на месяц посадить разобрать всю эту стопку и нанять кого. Хотя в реальности, если поставить цель нанять и расширяться, это решается за 4 дня.

        Да, за 8 лет ещё ни одного не встретилось. Вечно они нихуя не понимают, вечно за ними все нужно доделать, вечно у нас делайны, любые неудачи это вы дураки там понаписали чего-то, не оценили верно, не спланировали или еще че. Пока они сверх бонусы получают, летают в Дубаи нюхать кокос, и ходят с шлюхами по блокчейн митапам. Вот и вся суть этого вашего айти, а разбираться в сортах я очень устал, поэтому они мне все враги, как все слабовики. Тут же дело какое, я уверен были и нацисты которые в печи вели и думали, что они нивиноватый.


        1. randomsimplenumber
          07.07.2023 08:59
          #25733502
          +2

          это решается за 4 дня

          Любая работа выглядит простой, если ее делаю не я ;)

          Код писать тоже ничего сложного, нажимай себе кнопки. Это не мешки ворочать.


          1. MaM
            07.07.2023 08:59
            #25733522
            -2

            Я её делал, и да код писать легко, и программисты это делают очень очень хорошо, правда от работы программиста написание кода это от силы 10%, но да черт с ним


        1. MiraclePtr
          07.07.2023 08:59
          #25733614
          +2

          зарплата одной хрюши примерно как у мидла 3к

          Это где для хрюш такие шикарные условия? Срочно поделитесь названиями мест, я своим знакомым HR передам, они будут нереально счастливы иметь такие деньги.

          чем просто мидла на месяц посадить разобрать всю эту стопку

          А миддлу это нахрена надо? Миддлу интересно код писать, а не с кандидатами созваниваться и емайлы целый день строчить.

          Хотя в реальности, если поставить цель нанять и расширяться, это решается за 4 дня.

          Вот эта фраза говорит о том, что вы не имеете вообще ни малейшего представления о том, как обстоят дела в реальности.

          Да, за 8 лет ещё ни одного не встретилось.

          Сочувствую. Должно быть вы что-то в жизни делаете не так. Ну, или карму себе испортили, и судьба вам мстит.

          летают в Дубаи нюхать кокос

          Не видел ни одной компании, где линейные проджект/продакт-менеджеры зарабатывают столько, чтобы регулярно нюхать кокс в Дубае.

          ходят с шлюхами по блокчейн митапам.

          Менеджеры обычно на митапы не ходят, это больше занятие как раз для программистов. Ходить на митапы, да ещё вместе с леди лёгкого нрава - отличное занятие, советую.


          1. eton65
            07.07.2023 08:59
            #25734086

            Такого товарища забанили, эх...


            Это где для хрюш такие шикарные условия? Срочно поделитесь названиями мест, я своим знакомым HR передам, они будут нереально счастливы иметь такие деньги.

            За 3 не встречал, но за 1-1,5 полно, причем обычно по блату нанятые. Причем их работа не стоит даже этих денег.


            А миддлу это нахрена надо? Миддлу интересно код писать, а не с кандидатами созваниваться и емайлы целый день строчить.

            Я так понял, что созвоны все-таки на эйчарах, а мидлы должны резюме читать и первичный отсев осуществлять. Я тоже так считаю.


            Вот эта фраза говорит о том, что вы не имеете вообще ни малейшего представления о том, как обстоят дела в реальности

            Так в реальности обычно директор видит, что команда постоянно не успевает и дает указание нанять рокет-сайнса за 3 копейки. Пока эйчары проверят гороскоп каждого кандидата проходит месяц, потом они смотрят чтобы буквы в описании стека совпадали и т.д. Эйчары вынуждены затягивать процесс найма, иначе для всех станет очевидным, что в таком качестве и с такими з/п они просто не нужны.


      1. 0xd34df00d
        07.07.2023 08:59
        #25735682
        +2

        Либералы = приверженцы либеральных взглядов, считающие права и свободы человека высшими ценностями, в том числе свободу слова, свободу совести, неприкосновенность частной собственности, верховенство закона и равенства всех граждан перед законом.

        Это классические, французские либералы. Вы опоздали лет на двести-триста.


    1. 0xd34df00d
      07.07.2023 08:59
      #25735686
      +2

      обсолютно
      придадут
      алигофрен
      бесчисленное количество несогласованных предложений
      девочка 18 лет которая отсидела [...] в языках.

      Чё-т проиграл.


  1. lovermann
    07.07.2023 08:59
    #25733350
    +1

    Если рутина убила интерес, то все проблемы, - в недостатке мотивации. Я бы выбрал ту сферу, где профессиональные амбиции, желание и мотивация будут превалировать. Благо, сфер много!


  1. galkon
    07.07.2023 08:59
    #25733956

    Привет, как я тебя понимаю :)

    Раньше сам программировал игрушки на С++/С# (комп графика, OpenGL, D3D, AndroidNDK, PhysX, Bullet, Newton Dynamics), но рыночек заставил изменить профиль. Плюс поменялись инструменты (появились Unity, UE4) + при пересчете трудозатрат на денежную выгоду я понял, что на С++ смогу себе заработать только сердечный приступ :)

    >Хотел конкретно изучить Docker, но уже поздно - он больше не в моде, теперь же есть Kubernetes

    ну как бы k8s использует внутри себя Docker и решает он внутри себя другие задачи. k8s - осуществляет управление docker контейнерами и zeroDownTime.
    Есть docker swarm для этой задачи, но он для прода не очень годится (тема холиварная)

    > А все эти «опыт работы с Golang от 3-х лет» меня очень раздражают (можно подумать там что‑то такое сложное, что аж нужно 3 года учиться)
    После опыта в C++ вкатываешься очень легко, но переходя со стека на стек я внезапно наткнулся, что структура проекта тоже регламентирована (название папок) гайдлайнами. Тоже справедливо даже к синтаксической записи.
    Ну и обычно — требуют знание каких-то общих библиотек, реализующую конкретную функциональность

    Общий опыт на С++ помогает тут очень, но любой 'новый' язык — это своя экосистема


  1. mr_iamam
    07.07.2023 08:59
    #25734256

    java 8 one love


  1. vvzvlad
    07.07.2023 08:59
    #25734522
    +1

    Хотел конкретно изучить Docker, но уже поздно - он больше не в моде, теперь же есть Kubernetes, Ansible, и ещё чёрти сколько технологий, которые я никогда не изучу. А раньше было достаточно просто знаний администрирования Linux...

    Ха-ха, у ТС фиксация на новых технологих почище, чем такая же фиксация у компаний, только в противоположную сторону.

    Docker, Kubernetes, Ansible — это разные технологии, сделанные каждая под решение конкретной задачи. В чем проблема изучить докер сейчас? Ну да, не возьмут на работу, где есть задачи, требующие Kubernetes. Но ведь куча задач, где работает докер, будет доступна же, не?

    Нет, будем ныть "чо вокруг все меняется", писать статьи на хабр, вместо того, чтобы локально поиграться с этими технологиями (это займет пару дней) и составить понимание, для чего они они нужны, какие проблемы решают и надо ли в это погружиться глубже. Проще, конечно, сказать что в наше время такого не было и отказаться от изучения просто по факту того, что они как-то слишком быстро появляются.


  1. santa324
    07.07.2023 08:59
    #25735554

    Изучайте то что не устаревает. Алгоритмы и математику вообще, компьютерсаенс. И не меняйте слишком часто работу, если возможно, что-бы не тратить время каждый раз на изучение всех этих модных технологий.

    Это выгорание из-за ощущения бесполезности потраченного времени. Я тоже это когда-то ощутил, и с тех пор с энтузиазмом изучаю только фундаментальные вещи, а все эти технологиии только необходимый минимум для конкретной задачи.

    Уверен, адекватные работодатели тоже все это прошли и совершенно адекватно относятся к не знанию каких-то технологий, но пониманию принципов подобных решений.