20 марта в 22:23

Куда деваются программисты после 40



— Вам уже 45? Но у нас коллектив очень молодой. Вы уверены, что хотели бы у нас работать?
— Да, конечно! Я много наслышан о вашей компании. Это мечта всей моей жизни!
— Ну ладно. Вот вам простой вопросик. Что означает буква L в аббревиатуре SOLID?
— Liskov Substitution Principle.
— Нет. У меня написано, что это Liskov Substitutability Principle.
— Но…!
— Никаких «но»! Неверно ответили, ведь видно же, что не готовились к собеседованию, так и скажите, да еще и спорите! Вы вообще конфликтный человек? Ладно, даю вам еще один шанс. Как развернуть односвязный список?
— Развернуть односвязный список за один проход? Да, пожалуйста. Проходимся по каждой ноде, запоминаем её next, вставляем ей в next указатель на предыдущую, потом идем по запомненному next-у и так далее. Да, в первую ноду в next вставляем, конечно же, nullptr. Нечетко объясняю? Ну давайте я лучше напишу.
— Хм… Хорошо, достаточно. А рекурсивно можете?
— Да, рекурсивно тоже могу.
— А сколько в Москве бензозаправок?
— O-)????!!! 1127!
— Откуда вы знаете???
— А у меня папа работал в Лукойле.
— Ладно… А знаете наихудший случай quicksort? Есть такой наихудший случай. У меня тут на листочке записано…
— Да, знаю.
— Но молодые специалисты это тоже знают. Почему мы должны платить вам на 15% больше?
— Но у меня семья, дети, ипотека… Да я и английский знаю.
— Все его знают. Этим сейчас уже никого не удивишь.
— Но я его очень хорошо знаю и говорить могу тоже хорошо. If you would like to ask me some questions in English, you are welcome.
— Huh!.. Это для нас не принципиально. Зачем программисту говорить на английском?
— Но я еще и французский знаю. Si vous voulez parler francais…
— Хватит!!! Кому в баню в программировании сдался ваш французский???
— Что же мне тогда делать?
— Застрелитесь! То есть… что там у меня написано?.. мы вам перезвоним. Если у нас возникнет такая потребность.

почти выдуманный диалог на собеседовании

У меня растут года. Будет мне 120.
Где работать мне тогда? Чем заниматься?

актуально в свете повышения пенсионного возраста

Когда я начинал свою трудовую деятельность в далеком 1996 году, то и представить себе не мог, как будет развиваться моя профессиональная карьера на десятилетия вперед и чем я буду заниматься, скажем, в 2017. Уверен был, что это будет связано с компьютерами, а чем конкретно – понятия не имел. Даже не был уверен, кем стану: программистом или сисадмином.

Вокруг меня все время были молодые специалисты, причем чем старше я, тем моложе они… 2000-й год… молодые специалисты…. 2010-й год… молодые специалисты…. 2017-й год – другие молодые специалисты. Удивительно, но работаешь 20 лет – и вокруг тебя одни молодые специалисты … и специалистки. Да, в последнее время стало много девушек-программисток. Раньше, лет 15 назад, в процентном отношении среди моих коллег их было от 0 до 5%, а теперь все 20%.

Причем чем больше я работал, тем больше вокруг было молодых специалистов. Как ни удивительно, меньше всего их было на самой первой моей работе, когда сам я был зеленым молодым специалистом, которого никто никуда не хотел брать, только … в компанию к «немолодым специалистам». Я рос, креп, переходил в другие компании, но никак не мог объяснить этот странный феномен. Откуда же берутся все новые и новые молодые специалисты и куда деваются старые? Они же вроде бы должны взрослеть и переставать быть «молодыми»? Но они постоянно присутствуют и появляются все в большем количестве!

Пришло время, я переходил «от подмастерья к мастеру» и наконец на собственной шкуре узнал, куда деваются программисты после 40! Они … стреляются! Шутка! На самом деле все мои бывшие коллеги, которые были когда-то «молодыми специалистами», осели либо за рубежом, либо растворились в граале отечественных IT-технологий Яндексе (не хочу обижать альтернативные граали – Касперского, Abbyy, Parallels, а также сотни менее крупных по масштабам, но, возможно, более прекрасных по духу граальчиков). Никого не осталось! Вот куда поступает «осадок» молодых специалистов. Почему же никто из них не стал «биг-боссом», менеджером высшего звена или иным руководителем? Ну это ж программисты, они код писать любят и своей профессии не предадут. Так что под конец карьеры такие вот «пожилые» специалисты концентрируются в лучших компаниях (а где еще можно работать?).

Поймал себя на мысли, что 20-й год тем только и занимаюсь, что перекладываю данные из одного места в другое… Почти как сортировщик апельсинов из известного анекдота. Ну просто никаких алгоритмов, обычное перекладывание туда-сюда, туда-сюда. И так 15 лет. Ну максимум, был у нас merge sort больших файлов лет 10 назад. И всё. Засортировали и будя.

Вообще, профессия у нас рабочая. Руками мы любим трудиться. Ну мозгом, конечно, тоже надо, не без этого. Не зря же Андрей Аксенов (автор поисковой системы Sphinx) сравнивал программистов, точнее, низкоуровневых программистов-оптимизаторов, с «сантехниками, которые ковыряются в потрохах, рыцарями г… и пара» (доклад на HighLoad 2010 по низкоуровневой оптимизации С/C++).

Дедушка мой, кстати, был сапожником. И не обычным сапожником, а модельным. Он работал в театре и обувал актеров для спектаклей. Он не был менеджером. Зачем сапожникам менеджеры по сапогам? Так вот и я считаю, что менеджер – это совершенно другая профессия. Сапожник сапоги шьет, как и программист, производит реальный продукт, а менеджер управляет процессом производства сапог. Но в театре нет массового производства сапог, равно как и в небольшом стартапе нет массового производства софта.

Не все программисты идут в управленцы, так же как не все управленцы – хорошие программисты. Но для управленца, как ни странно, это не самое главное. Главное — иметь под рукой грамотного профессионала, с которым всегда можно посоветоваться.

Когда лет десять назад подвернулась возможность «продвинуться» в менеджеры, я усомнился в целесообразности этого. Потому что это означало бы деквалификацию. Ведь для любого мастера очень важно ежедневно оттачивать свою технику. Вот для скрипача главное — ежедневная практика. Для спортсмена что главное? Ежедневные тренировки. Если бы я стал полноценным менеджером, то потерял бы возможность главного и самого приятного – программировать. Мне пришлось бы заниматься оргвопросами, принимать участие в совещаниях, ругать и хвалить пресловутых «молодых специалистов», и вообще руко-водить, то есть водить за руку эту зелёную молодежь, вчерашних студентов. Нет! Без меня обойдутся. Займусь-ка лучше тем, где я лучше всего самореализовываюсь.

Относительно себя с возрастом в профессии ты хуже не становишься. Но есть ли возможность беспредельно развиваться в рамках профессии программиста, не меняя её? Конечно, ты не угонишься за всеми трендами и технологиями в Computer Science.

Если в 80-е и 90-е годы IT-специалист в принципе мог владеть исчерпывающим объемом знаний, касавшихся Computer Science, то теперь единственный путь IT-специалиста, как мне кажется – в специализацию. Число областей Computer Science растет в геометрической прогрессии, а время на их изучение ограничено, поэтому специализируйтесь и выбирайте вашу специализацию тщательнее!

Мне как-то пришло сообщение в linkedin от одной рекрутерши или … рекрутрисы (много их теперь стало, а раньше не было совсем. Сам, всё сам… даже через FIDO приходилось искать работу). Она писала:

«Добрый день:) Для восстановления справедливости во Вселенной Орден Джедаев набирает в свои ряды Великих Воинов джедая С++. Действия происходят на хорошо защищенной и комфортной Планете Yandex в центре Московской Галактики!
…(описание вакансии опущено)…
Итак, если Вы — Великий Воин или готовы им стать, жду Тайного манускрипта (резюме). В нашей галактике Вам не страшна звезда уныния и тоски !!»


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

Я тут же ответил в духе воина-джедая, не подавая виду, что и сам не догадался бы про «манускрипт» без подсказки:

«Здравствуйте. Большое спасибо за проникнутое юмором послание. Я улыбнулся. Джедаем, Великим Воином, гуру и сенсеем я, безусловно, собираюсь стать. Еще большее спасибо за рекомендацию конкретной вакансии Яндекса. Мне нравится афоризм, в котором говорится, что все программисты делятся на тех, кто уже работает в Яндексе и тех, кто мечтает об этом. Я из последней категории, но мои многие бывшие коллеги уже «там»: они вкусили прелесть работы в лучшей технологической компании страны. Мне же, чтобы дорасти до минимального «проходного» уровня Яндекса (я трезво оцениваю свои знания) необходимо 2-3 года интенсивной подготовки. Необходимо вспомнить институтский курс тервера, порешать задачки на логику и сообразительность, детально изучить то, что «под капотом» у современных библиотек, изучить последние «писки» моды в стандартах С++, алгоритмы на графах и многое, многое другое (список литературы и лекций включает примерно 50 наименований). А ходить «на шару» на интервью в _такую_ компанию (авось пройду) мне совесть не позволит. Отнимать время у Яндексоидов понапрасну не могу. Последний раз был на интервью в «Яндексе» в 2007 году примерно. Получил большое удовольствие (бесплатно обучили :) С тех пор, конечно, уровень свой поднял, но мне еще далеко до необходимого минимума знаний. По рассказам «знающих людей» интервью продолжается более 14 часов. Кандидату дают задачи из разных областей, его собеседуют интервьюеры различных направлений, чтобы составить взвешенное мнение о кандидате. Раньше было проще: не так интенсивно. У меня есть знакомые, которые смотрят на интервью как на своеобразное хобби, позволяющее улучшить свой уровень, пообщаться с коллегами по цеху, приятно провести время наконец. Я отношусь к этому серьезнее, поэтому и подготовкой занимаюсь соответственно. Не буду надолго задерживать ваше внимание. На этом попрощаюсь, но предлагаю поддерживать контакт».

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

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

Меня потряс как-то «список знаний и умений любого уважающего себя» программиста из miram.livejournal.com/630972.html и sharpc.livejournal.com/67583.html. Не поленюсь привести полную цитату:

Все, что должен знать программист, чтобы его после 40 лет не выбросили на Помойку, Где Бомжи.
… В возрасте около 45 лет начинает активно проявляться деградация мозга, приводящая к существенным проблемам в понимании и способности оперировать кодом с обычной цикломатической сложностью. Потеря способности писать код в сочетании с неспособностью из-за отсутствия тренировок к анализу/синтезу — гарантированный путь именно туда. Некоторые люди сохраняют способность оперировать нормальной цикломатической сложностью и в старости, однако лишь за счет превышающих норму показателей в молодости. Проверить, входите ли вы в зону риска, можно на TopCoder.

Добавление от себя. TopCoder – это реально хорошее место, чтобы держать себя в тонусе. Решаем задачки оттуда и поддерживаем тонус (или даже участвуем в challenges, конкурируем с другими и зарабатываем деньги). Итак, что же нужно знать, чтобы тебя не выбросили на помойку?

• C++, стандарт, Comeau, 1TBS, Страустрап/D&E/Джосаттис/Вандервуд, Дьюхэрст/Мейерс/Саттер, RAII/copy-and-swap/exception-safety, правило пяти, Александреску/Абрахамс-Гуртовой, type erasure, CRTP, NVI, SFINAE, Koenig lookup, Duff's device, Boost, Сик-Ламсдейн/Карлссон, TR on C++ performance, тест Степанова, forwarding problem/move semantics, SPECS, GotW, Meyer's singleton, cppgm
• Компиляторы С++, особенности реализации стандарта, ограничения реализации, интринсики, отличия стандартных библиотек (контейнеры, rand), ABI, реализация виртуальных функций, виртуального наследования, исключений, RTTI, switch, указателей на функции и методы; оптимизации, copy elision (RVO, NRVO), sizeof на различных платформах, дефайны компилятора и среды, __declspec, ключи компилятора, empty-base optimization, статическая и динамическая линковка, манглинг, распределенная компиляция, precompiled header, single compilation unit, (strict) aliasing/restrict, inline/_forceinline, volatile, быстрое вычисление математических функций через битхаки, linkers & loaders by Levine
• Мультитредность, обедающие философы, deadlock/livelock/race condition/starvation, атомарность, lock инструкции процессора, memory model/barrier/ordering, CAS или LL/SC, wait/lock/obstruction-free, ABA problem, написание lock-free контейнеров, spin-lock, TLS/per-thread data, закон Амдала, OpenMP, MPI, map-reduce, critical section/mutex/semaphore/condition variable, WaitForSingleObject/WaitForMultipleObjects, green thread/coroutine, pthreads, future/deferred/promise, модель акторов, parameter server, RDD (as seen in sparks), downpour SGD, wait-free, stackful vs stackless
• Язык ассемблера, Зубков/Хайд/Дреппер/Касперски/Фог/Абраш, x86, FPU/MMX/SSEn/AVX, AT&T и Intel-синтаксис, masm32, макросы, стек, куча/менеджеры кучи, соглашения вызова, hex-коды, машинное представление данных, IEEE754, little/big endian, SIMD, аппаратные исключения, прерывания, виртуальная память, реверсинг, срыв стека и кучи, return oriented programming, alphanumeric shellcode, L1/L2/RAM/page fault и их тайминг, язык ассемблера ARM
• Аппаратное обеспечение, Хоровиц-Хилл/Титце-Шенк/От физики к Си от panchul, полупроводниковая электроника/спинтроника/фотоника, транзистор, триггер, схемотехника, микрокод, технология создания процессоров, logic synthesis, static timing analysis, FPGA, Verilog/VHDL/SystemC, SISAL, Arduino, устройства памяти (ROM → EEPROM, RAM, SSD, HDD, DVD), RISC/CISC, Flynn's taxonomy ([SM]I[SM]D), принстонский и гарвардский подход, архитектуры процессоров, архитектуры x86, VID/PID
• Процессоры, конвейеризация, hyper-threading, алгоритм томасуло, спекулятивное исполнение, static/dynamic branch prediction, префетчинг, множественный ассоциативный кэш, кэш-линия/кэш-промах, такты, кольца защиты, память в мультипроцессорных системах (SMP/NUMA), тайминг памяти, intel optimization manuals, performance counters
• Дискретная математика, K2, теорема Поста, схемы, конечные автоматы (ДКА и НДКА), автомат Калашникова, клеточные автоматы
• Вычислимость, машина Тьюринга, нормальные алгоритмы Маркова, машина Поста, диофантовы уравнения Матиясевича, лямбда-функции Черча, частично рекурсивные функции Клини, комбинаторное программирование Шейнфинкеля, Brainfuck, эквивалентность тьюринговых трясин, проблема останова и самоприменимости, счетность множества вычислимых функций, RAM-машина, алгоритм Тарского, SAT/SMT-солверы, теория формальных систем, interactive proofs, теорема Левина-Кука, 3SAT, PSPACE = NPSPACE, #P
• Языки программирования, грамматики, иерархия Хомского, теорема Майхилла-Нероуда, лемма о накачке и лемма Огдена, алгебра Клини, НДКА → ДКА, алгоритмически неразрешимые задачи в формальных языках, Драгонбук, Фридл, регекспы и их сложность, PCRE, БНФ, Boost.Spirit + Karma + Qi/Ragel, LL, LR/SLR/LALR/GLR, PEG/packrat, yacc/bison/flex/antlr, статический анализ кода, компиляция/декомпиляция/обфускация/деобфускация, Clang/LLVM/XMLVM/Emscripten, GCCXML, OpenC++, построение виртуальных машин, JiT/AoT/GC, DSL/DSEL, on-stack replacement, type checking/type inference алгоритмы, CYK parser, advanced compiler design and implementation by Muchnick
• Алгоритмы и комбинаторная оптимизация, Кормен/Скиена/Седжвик/Кнут/Ахо-Хопкрофт-Ульман/Пападимитриу/Шрайвер-Голдберг/Препарата-Шеймос/e-maxx.ru, структуры данных, алгоритмы, сложность, символика Ландау, теорема Акра-Баззи, time-space tradeoff, классы сложности, NP-полные задачи, КМП, графы и деревья, потоки в сетях, матрица Кирхгофа, деревья поиска (особенно RB-дерево и B-дерево), occlusion detection, куча, хэш-таблицы и идеальный хэш, сети Петри, алгоритм русского крестьянина, метод Карацубы и матричное умножение Винограда-Штрассена, сортировки, жадные алгоритмы и матроиды, динамическое программирование, линейное программирование, diff-алгоритмы, рандомизированные алгоритмы и алгоритмы нечеткого поиска, псевдослучайные числа, нечеткая логика, gusfield (suffix tree, string alignment), motif search, scanning line, cache oblivious, funnel sorting, VEB-layout, корневая оптимизация, алгоритмы для динамических графов,
модели вычисления (RAM-machine/pointer machine/decision trees и т.д.), алгоритмы в иерархиях памяти/стриминговые алгоритмы, time forward processing, range & rank, LSM-trees, buffered a-b-trees, toku trees, персистентные структуры, succint-структуры, lossy-струтуры (bloom/bloomier filter, hash-tables with false positives), locality sensitive hashing, space-time tradeoff в хэш-таблицах, scheduling strategies
• Численные методы, дихотомия/метод Ньютона, интер- и экстраполяция, сплайны, метод Гаусса/Якоби/Зейделя, QR и LU-декомпозиция, SVD, МНК, методы Рунге-Кутты, метод Адамса, формулы Ньютона-Котеса, метод Ритца, метод Бубнова-Галеркина, метод конечных разностей/элементов, FFT/STFT, сходимость и устойчивость, l-bfgs и другие квазиньютоновские методы, adagrad, PARAFAC, cassowary, interior point methods, вариационные методы для байесовского вывода, nesterov, автоматическое дифференцирование, alternating least squares, what every computer scientist should know about floating point arithmetics by Goldberg, Nocedal & Wright/Boyd & Vandenberghe
• Машинное обучение, Тибширани/Bishop, подходы к моделированию AI, переобучение/кроссвалидация, байесовские сети, нейросети, сети Кохонена, Restricted Boltzmann machine, градиентный спуск/hill climbing, стохастическая оптимизация (метод Монте-Карло, метод отжига, генетические алгоритмы, муравьиные алгоритмы), SVM, gradient boosting, кластерный анализ, метод главных компонент, LSH, обучение с подкреплением, MDP, information retrieval/data mining/natural language processing, машинное зрение, Szeliski, OpenCV, image processing, OCR, фильтры Собеля, каскад Хаара, Viola-Jones framework, SURF, введение в психофизиологию зрения, IPython/pandas/scikit-learn, (ME)HMM, CRF, label bias problem, stacked NN, LeToR, factorization machines, autoencoders, RNN/CNN, вместо NLP лучше отдельные задачи (language modelling, co-reference detection, text chunking, POS-tagging, probabilistic parsing, statistical machine translation, misspell correction, question answering, NER, collocation detection, text summarization, speech recognition, fact extraction, sentiment analysis), эффективное вычисление softmax, feature engineering/selection, quality estimation, Manning/Jurafsky/McCallum/Koehn, latent topics (LDA, chineese restaurant, pLSI), parallel coordinates, vowpal wabbit, NLTK, structured learning, EM-алгоритм, contrastive divergence, optimal brain surgery, belief propagation, semi-supervised learning, inductive vs transductive learning, kernel trick, discriminative/generative pairs (as seen by Ng & Jordan), sequence to sequence learning, bagging, анализ социальных графов, рекомендательные системы/collaborative filtering, multimodal learning
• Теория информации, сжатие, Хаффман, RLE, BWT, LZ, коды коррекции ошибок, сжатие с потерями (изображения, аудио, видео), информационная энтропия, формула Шеннона, сложность Колмогорова, maximum entropy problem, kullback-leibler divergence, elias/shannon-elias encoding
• Криптография, Шнайер/Ященко, Принцип Керкгоффса, симметричная (DES, AES), асимметричная (RSA), качество ГПСЧ, алгоритм Диффи-Хеллмана, эллиптические кривые, хэширование (MD5, SHA, CRCn), DHT, криптостойкость, криптоатаки (атака гроссмейстера), WEP/WPA/WPA2 и атаки на них, цифровая подпись и сертификаты, PKI, HTTPS/SSL, доказательство с нулевым разглашением, пороговая схема, murmurhash/cityhash, DKIM
• Математика, Кнут-Грэхем-Паташник/Зорич/Винберг, Spivak/Dummit-Foote, матан, линал, комплан, функан, диффгем, теория чисел, дифуры/интуры/урчпы/вариационное исчисление/оптимальное управление, производящие функции, ряды, комбинаторика, теорвер/матстат/слупы/теория массового обслуживания, цепи Маркова, интегральные преобразования (Фурье, Лаплас, вейвлет), NZQRCHOS, матпакеты (Mathematica, Maple), теория категорий
• Физика, правила Кирхгофа, закон Джоуля-Ленца, комплексное сопротивление, скорость и частота света, уравнения Максвелла, лагранжиан и гамильтониан,
quantum tunnelling/hot electron injection :)
• Химия, стехиометрия, химия кремния :)
• Архитектура и стиль кода, Макконнелл/Фаулер/Лебланк/Гамма/Александреску-Саттер/Буч, защитное программирование, паттерны, SOLID/GRASP/KISS DRY SPOT/YAGNI, UML, OOP (Smalltalk), OOD/OOA, метрики кода, uncle Bob
• Методологии разработки, Waterfall/RUP/Agile/Scrum/Kanban/XP, TDD/BDD, CASE
• Тестирование, юнит-тесты, функциональное, нагрузочное, интеграционное тестирование, тестирование UI, mocks/stubs/spies, fixture, запахи и паттерны тестов (Osherove/Meszaros)
• Инструментальные средства разработки, IDE, IntelliSense, отладчики (VS/Olly/WinDbg/kdb/gdb) и трейсеры (strace/ltrace), DWARF debug information format, дизассемблеры и декомпиляторы (IDA/HexRays/Reflector), системы контроля версий (SVN, GIT), merge/branch/trunk, системы именования файлов и бранчей, continuous integration, ant, code coverage, статический анализ (lint, cppcheck), динамический анализ (valgrind, фаззинг), верификация и валидация ПО (Frama-C, RAISE (RSL), Coq), профайлинг, багтрекеры, документирование кода, системы сборки (CMake), пакетные менеджеры (NuGet)
• Фреймворки, Qt, moc и метаинформация, концепция слот-сигнал, Саммерфилд-Бланшет/Шлее, PoCo, промышленные библиотеки: GMP, i18n, lapack, fftw, pcre
• Операционные системы, Silberschatz/Рихтер/Соломон-Руссинович/Робачевский/Вахалия/Стивенс/Таненбаум/Love/Linux Kernel Internals, менеджер памяти, менеджер кучи и ее устройство (LAL/LFH/slab), менеджер устройств, менеджер процессов, context switch, реальный и защищенный режим, исполнимые файлы (PE/ELF/Mach), объекты ядра, отладочные механизмы (strace/ptrace/dtrace/pydbg, Debug API) и минидампы, bash, сетевой стек и высокопроизводительные сервера, netgraph, CR0, IPC, оконная подсистема, система безопасности: ACE/ACL и права доступа, технологии виртуализации, RTOS (QNX), программирование драйверов, IRQL, IRP, файловые системы, BigTable, NDIS/miniport/FS drivers/filter driver, Mm-, Io-, Ldr-функции, DKOM и руткиты, GDT/IDT/SDT, ядра Windows/Linux/BSD, POSIX, TRIM
• Компонентно-ориентированные модели, Роджерсон/Таварес, COM/OLE/ActiveX/COM+/DCOM RPC, ATL, апартменты, моникеры, MIDL, XPCOM, CORBA, TAO, D-Bus
• Сеть, Стивенс, OSI model/Internet model, Ethernet, TCP/IP, TCP window, алгоритм Нейгла, сокеты, Protocol buffers/Thrift/Avro/ASN.1, AMQP, ICMP, роутинг/BGP/OSPF, ARP, атака Митника, syn flood, HTTP/FTP, P2P/DHT, DHCP, SMB/NBNS, IRC/XMPP, POP3/SMTP/ESMTP/IMAP, DNS, WiFi/WiMax/GSM/CDMA/EDGE/Bluetooth/GPS, ACE, Wireshark
• Графика и GPGPU, алгоритм Брезенхема, цветовые модели, трассировка лучей vs полигональная графика, OpenGL/GLSL/Open Inventor, DirectX/DirectShow/DirectAudio/HLSL, stencil/depth/alpha-test, графический конвейер в DirectX 11, шейдеры, модели освещения (Фонг), пропускная способность, fillrate, OpenCL/CUDA/AMP, ландшафты, лоды, тени, deferred shading, текстурирование и фильтрация, антиалиасинг, HDR, tone mapping, virtual/augmented reality
• Форматы, XML/XSLT/XPath/XMLStarlet/DOM/SAX, RTF/ODF, JSON/BSON/bencode, YAML, JPEG/PNG/WebP, AVI/MPEG/RIFF/WAV/MP3/OGG/WebM, SVG, Unicode, кодировки однобайтные/UTF-8/UTF-16/UCS-2/UTF-32, проблемы длины и сравнения Unicode-строк, base64, markdown
• Базы данных/Распределенные системы, Грубер/Дейт, ANSI SQL, T-SQL, ODBC, MySQL/PostgreSQL/MS SQL/BDB/SQLite/Sphinx, хранимые процедуры, триггеры, алгебра Кодда/А, Tutorial D, нормальные формы, оптимизация и выполнение запросов, структуры данных индексов, транзакции и ACID, CAP-теорема Брюера, graph DB, document store, wide column store, key-value storage, теория распределенных систем, CRDT, net split проблема, протоколы консенсуса, теория шардинга/репликации, ORM (C++ ODB), ERD, OLAP, семантическая сеть, triplestore, RDF/Turtle, SPARQL, OWL, Semanticscience Integrated Ontology, reasoner, DBpedia, big table/hbase vs. dynamodb/cassandra/riak, 2/3PC, chubby/zoo keeper, leader election (paxos/raft), hdfs/gfs/glusterfs, deduplication problem, causality detection (vector clock/stamps), R/W quorum, load balancing, устройство индексов поисковых систем, event sourcing, CRDT, дизайн протоколов и принципы коммуникации, с точки зрения эволюции, расширяемости, надежности, дизайн программных интерфейсов (API)
• Прикладное программирование, C#/F#, Шилдт/Троелсен/Рихтер, генерики, yield, linq/plinq, рефлексия, AST, WCF, WinForms/WPF/Silverlight, AOP, фреймворки логгирования, .NET assembly, Scala, Хорстманн/Одерски, pattern matching, макросы/квазицитаты
• Квантовые вычисления, алгоритм Шора, квантовая криптография
• Функциональное программирование, Haskell/Ocaml/Scheme/Alice или Oz, SICP/TaPL/YAHT/Purely Functional Data Structures/Харрисон-Филд, HOF (map/fold/filter), система типов Хиндли-Милнера, монады, тайпклассы, АТД, dependent types, ленивость/энергичность, логическое программирование (Prolog или Mercury), конкурентное программирование (Erlang или Oz)
• Веб-программирование и скриптовые языки, Фланаган/Zend PHP5 Certification Course + Study Guide, Apache/nginx, CGI/FastCGI, PHP/Zend Framework/ReactPHP/Zend Engine/Doctrine или Propel/CodeIgniter или Symphony или Yii, Python/Django/Twisted, Ruby/RoR, ASP.NET MV*, JavaScript/jQuery/React/Google Closure/ExtJS/node.js, ООП в JavaScript, HTML5, CSS3/табличная и блочная верстка, RSS, canvas/WebGL, Ajax/WebSockets, вопросы безопасности (XSS, SQL injection, CSRF), highload, C10k problem, SWIG, CDN, shadow DOM, квирки браузеров, real time bidding/trading, anomaly detection, архитектура single page apps, устройство веб-краулеров, web/social graph random walk, asm.js и компиляция в js, v8/spidermonkey internals, PaaS/IaaS, SPDY
• Проектирование GUI и представление информации, Раскин/Тафти, юзабилити, основы дизайна и типографики, закон Фиттса, основы верстки, LaTeX, алгоритмы визуализации данных (as seen in d3), subpixel rendering

Немного на 40 лет, правда? Или много, если надо еще и работать? Действительно, когда же это изучать, если надо работать? В свободное время? А я не знаю и половины из этого списка. И четверти не знаю. Метод Карацубы пока не освоил. Химию кремния, наверное, придется, как и уравнения Максвелла, отправить в долгий ящик. Есть более приоритетные темы.

Но в свете будущего повышения пенсионного возраста мне ведь еще минимум лет 40 работать – как раз узнаю вторую половину в свободное от работы время. И что же, что будет, если я всё это узнаю? Что будет с тем гением, который знает всё по этому списку? Уверен, что его не только не выбросят на помойку, более того, его под конец жизни ожидает священная грааль – Яндекс (и зарплата молодого специалиста + 15%). Там он и найдет упокоение. Аминь.
Михаил Горшков @mike1
карма
54,0
рейтинг 37,2
Похожие публикации
Самое читаемое Управление

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

  • +59
    Самая большая проблема программистов людей при возрастании пробега — прогрессирующее занудство, исчезающая самоирония и старческая слезливость. В качестве профилактики могу только предложить витамины, полистать луркмуар и послушать группу «Кровосток».

    Колян, 40 лет.
    • –11

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

      • +26
        У автора как раз, вроде, неплохая самоирония, а вот у вас с этим уже слабовато, прям как MzMz написал.
    • +4
      > луркмуар

      Луркмоар
      • +8
        прям как MzMz написал: «прогрессирующее занудство»
        • +1
          я старался :)
      • +4
        Обнаружил, что шутки с луркмоар молодые сотрудники не понимают
        • 0
          Ну так на то и они и молодые) У них шутки про «патимейкер-шейкер-шейкер». Нам с вами не понять.
      • 0

        Луркнуар :)

    • 0
      Зависит от того, доволен ли человек своими результатами в жизни да процессом жизни в целом. С возрастом все основные черты личности проступают и усиливаются. Если был молодым занудой вырастешь той еще брюзгой )
  • +68
    Что-то зачастили с такими статьями на хабре, настолько, что мне аж в 30 уже страшно стало.
    • +13
      Профессия программистов в массы не так уж давно пошла, особенно в россии.
      Нытье 40 летнего программиста — 2017-40=1977 года рождения
      + 18 лет = 1995 год начала работы по профессии — по сути первая массовая волна как раз тех, кто занимался этим «с рождения».
      2017-1995 ~= 20 лет, аккурат тот срок когда можно начинать ныть о «старых добрых временах» (при дельте в 10-15 лет как-то это еще не так звучит).
      Чем дальше — тем больше будет таких статей и тем больше будет упоминаемый возраст.
      В 2037 вангуем статью «Куда деваются программисты после 60».
      При чем занудство сие постигло не только программистов, достаточно посмотреть аналогичные посты в контактике типа «лайкни если ты помнишь» и дальше какая-нибудь жевачка, которую почти никто не жевал, но вкладыши от которой были местной валютой:)

      А вообще программист как таковой это типичная профессия со стеклянным потолком. Проблема стеклянного потолка умноженная на устаревание технологий не только в том что рано или поздно некуда больше расти, а еще в и в том, что опыт больше 5 лет по сути не имеет значения в большинстве случаев, поэтому эффект «не успел разогнаться тебя уже догнали» очень силен. А смена профы на менеджера или управленца это именно смена профы.
      • +6
        Добавлю к последнему абзацу то, что некие «сакральные» знания, якобы доступные исключительно людям с 20-летним опытом часто не нужны по причине того, что для 95% IT-проектов в России реально достаточно just good enough качество (особенно это касается коротких проектов и мелких бюджетов). То есть нужно просто знать технологию X и молча без зауми херачить проект Y.

        Смена профессии на менеджера тоже не серебрянная пуля — в связи с более низкой ликвидностью среднего сферического менеджера относительно разработчика такой же геометрии.
        • +2
          Зачастую нужны сакральные знания по какому-то продукту, но проблема в том, что этот продукт или уникален или используется в единицах компаний и, уходя из одной такой, нет смысла менять шило на мыло. Как итог — сакральные знания есть, но толку… и чем дольше в этом вариться, тем больше этих знаний и тем больше полезного места они занимают и бОльшим якорем становятся.
        • +2
          Есть люди, которым и надо сидеть 20 лет на месте Z, зная только технологию X и молча без зауми пилить проект Y. А кому не надо, идут в ту же сервисную аутсорсинговую компанию и пилят сухие микросервисы на солидной архитектуре через TDD. Мода что-то пошла всех под одну гребенку грести. Программист, пожалуй — одна из самых толерантных к возрасту профессий. Это у токаря-фрезеровщика если единственный в городе завод закрылся, то дороги две — в алкаши да в дворники. А здесь кофе налил, пошел на какой-нибудь Апворк и сиди себе никуда не спеша поддерживай легаси проекты хоть до 80-ти. С нынешним курсом пенсиям даже до индусских рейтов, как до Луны.
          • +1
            Достаточно условно толернатная так-то. Если слесарь в 40 будет цениться практически однозначно выше 20летнего, и только из-за возраста проблем у него не будет точно, то про компании, в которых программистов отсеивают из-за того что «слишком старый» я периодически слышу. Это, конечно, не значит что работы сразу нет, но ее однозначно меньше чем 5-10-15 лет раньше.
            • +2
              У компаний тоже есть некий психологический возраст. Молодые разработчики всегда находятся чуть ниже этого возраста, поэтому подходят для практически любой фирмы, но чем более компетентен (заметьте, не просто более опытен, а именно более компетентен) становится разработчик, тем больше компаний он «перерастает». От того и складывается впечатление, что рабочих мест становится меньше. В абсолютных значениях — да, но в остальном всё на своих местах. Как в крупную корпорацию не нужен мальчик на должность системного архитектора, так и начинающим сервисникам, клепающим одностраничные визитки на шаблонах с themeforest, не нужны дядьки, рассуждающие про метод подстановки Лисков.
      • +2
        + 18 лет = 1995 год начала работы по профессии — по сути первая массовая волна как раз тех, кто занимался этим «с рождения».

        Гы. И кудаж мне теперь деваться? Я начал программировать в 1975, а деньги зарабатывать в 1978. В это время все студенты у нас к диплому изучали пару языков, если было на то желание, Алгол-60 давали на первом курсе, а Фортран приходилось учить самостоятельно, так как появилась потребность. И это не программисты, а инженеры-механики, между прочим.

        Это я насчет «массы», если что.

        А с остальным совершенно согласен — причем опыт больше 5 лет не просто не имеет значения — его еще и практически невозможно подтвердить, и если угодно, монетизировать — потому что управленцы, в большинстве своем, не в состоянии оценить этот самый уровень.
        • +2
          Вам надо было аналогичную статью тиснуть 20 лет назад:)

          А по поводу «массы» все же. Массовой профессией программист стал когда на рынок массово пришли персональные компьютеры, это все же никак не 1975, даже на западе это ближе к 1985 году, а в ссср/россии ближе к 1995. До этих лет профессия программисты была не массовой, скорее областью для энтузиастов любителей и узких специалистов
          Это все равно как сейчас назвать массовой профессию физика-ядерщика, то что их много — неоспоримо, но массовой профессией это станет не раньше выхода 120 айфона на ядерных батарейках, который будет жить аж 3 дня без дозарядки и на каждом углу будет киоск с починкой оных.
          • 0
            Ну, я целом наверное согласен, массовость тоже бывает разная. Просто в 1980-х один чисто инженерный факультет уже выпускал в год примерно 600 человек, каждый их которых знал как минимум Алгол-60. И это только один факультет, прошу заметить, а ведь были и другие, включая тех, у кого программист специальность. Разумеется, далеко не все они реально программировали — но факт обучения никуда не девался.
    • +1
      Да у меня после таких статей в 24 уже коленки начинают дрожать))) Соберитесь Мужики!!!
      • +3
        мне 52 и я кодирую… не ссцы!
  • +45
    42 года. Профессионально в IT 23 года. Самая большая проблема — я вижу на 10 шагов вперёд к чему приведут те, или иные решения, в то время как более молодые коллеги видят, едва ли на 3. Поэтому возникает грусть и некий налёт скуки.
    • +12

      Пишите больше статей и книг, повышайте уровень знаний коллег.
      В крайнем случае всегда приятнее запустить в коллегу томиком собственного авторства=)

      • +2
        им не нужно повышать вот так свой уровень.

        Сейчас «развлекаюсь» тем, что у новым задачам линкую писанные мною несколько лет назад, на эту же тему.
    • +1

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

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

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

        Один пример: в одном из компонентов у нас был реализован «белый список» системных вызовов, которые этот компонент имел право совершать. Ну и комментарий типа «если нужно что-то то ещё — пишите, мы список расширим!»).

        Как вы думаете сколько подобных запросов мы получили за пять лет? Предположение «нуль» всё же неверно — один запрос был. От нашей же команды. Зато какие «чудеса героизма» были обнаружены в компонентах, созданных партнёрами, которые были совершены для того, чтобы не писать письмо!

        И вот тут — можно говорить что угодно, но «хотьба по граблям» всё-таки продолжится. Просто потому что даже умным людям, но без опыта, сложно представить насколько по-разному могут быть устроены компьютерные компании. И никакие «конструктивные намерения» вам не помогут, так как вы предлагаете тратить ресурсы на решение проблем, которых, с точки зрения «молодежи» нет и быть не может!
        • +6
          Примеры с «чудесами героизма» можно и в любой другой сфере найти. Это одна из базовых психологических черт людей вообще.

          Вы сделали ограничения?
          image
          • +1

            Chalenge accepted — фигня! NotInventedHere!

        • 0
          Зато код партнеров работал с любой версией вашего компонента. Лично я бы долго думал, прежде чем пожертвовал бы совместимостью с уже развернутой версией. И, скорее всего, совместимость перевесила бы. Ну и страх, что новая версия вашего компонента вызовет регрессию.

          А вам лучше такие вещи вынести в конфигурациионный файл.
    • +9
      не дай бог озвучишь, может ещё и по шапке от начальства прилететь за то, что (цитирую) «опять ты со своим брюзжанием, видишь одно только говно». а когда таки говно случается, по шапке прилетает ещё раз, потому что имел смелость озвучить.

      мне 36, в IT я с 18 лет. на собственном опыте отлично знаю, к чему может привести плохо продуманное решение. но попробуй докажи.
      • +1

        Вы не задумывались, что проблема может быть в способах, которыми вы высказываете своё мнение?


        По опыту, «опять ты со своим брюзжанием, видишь одно только говно» — обычно ответ на условное «всё говно, архитектура говно, код плохой, всё будет только хуже» и в таком духе далее. И никакой другой реакции ожидать не приходится — посыл изначально деструктивен и вызвает желание ему сопротивляться.


        Другое дело:


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

        На текущий момент у нас есть проблемы с архитектурой в %название_модуля%, заключающиеся в том, что %краткое_описание_проблем%. В дальнейшем, если мы продолжим развивать это решение, при разработке задачи Б, имеющейся в плане, нам придётся пойти на внедрение компромиссного решения %костыль%, что, впоследствии, в свою очередь, также увеличит трудозатраты на реализацию задачи В, в силу %список_причин%. Также возможно и %другое_решение% задачи Б, не имеющее этих недостатков, зато имеющее %другие_недостатки%. Кроме того, задача Г может оказаться и вовсе нерешаемой, так как %причины%.

        Таким образом, мы можем оказаться в ситуации, когда дальнейшая разработка на основе текущего решения станет настолько трудозатратна, что выгоднее будет реализовать модуль заново. В пррцессе наверняка всплывут дополнительные проблемы, которые заранее предсказать невозможно, а так как продукт будет уже в зрелом состоянии, придётся тестировать гораздо больший объём взаимосвязанного функционала. Кроме того, на локализацию и устранение неизбежных ошибок также уйдёт труднопрогнозируемое количество времени, что повлечёт негатив от пользователей / риск срыва сроков по контракту / юридические последствия.

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

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

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


        Пробовали так?

        • +5

          А вот эти пламенные речи и презентации когда делать, в рабочее время, вместо основных задач? Или в свободное время, за свой счёт?

          • +5

            Это ваш выбор.


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


            Не можете или опасаетесь наказания за самодеятельность — обратитесь к руководителю и согласуйте с ним.


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


            Но сначала — сформулируйте, для себя в первую очередь, какой цели вы хотите достичь с точки зрения бизнеса. К примеру, «Сейчас мы тратим по два-три дня дорогого разработчика на добавление нового отчёта, так как надо писать SQL-запросы и готовить шаблоны на PHP. Эти задачи у нас регулярны. Если мы потратим две недели на новый модуль отчётов — в дальнейшем будем делать новые отчёты за считанные часы силами дешёвого верстальщика, потому что будет знакомый верстальщику XSLT и простенький генератор запросов. Это реальная экономия денег и времени, плюс мы сможем быстрее реагировать на пожелания пользователей, а разработчики займутся реальными задачами», вместо «Наши отчёты шляпа, легаси и говнокод, давайте сделаем нормально». Редкий вменяемый руководитель наотрез откажет, видя заинтересованность работника в результате. А если и откажет — можно не смириться сразу, а выяснить причины решения, возможно, вы видите не всю картину. В конце концов, если в руководстве реально невменько — что вы делаете на такой работе?

        • +4
          это не работает, и после десятка часов объяснений с разными стратегиями и примерами анологичных ситуаций из прошлого тоже.
          • +9

            Я повторю вопрос и вам — что вас держит на такой работе?


            Если у вас есть аргументы, а у начальства нет — смысл такой работы? Быть инструментом автоматизации желаний? Чувствовать себя ничтожным? Просиживать штаны, выполняя тикет буква-в-букву?


            Или просто не нравятся аргументы руководства? Или даже не пытались узнать?


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


            Можно быть гением программиррвария, но в жизни программирование должно приносить прибыль. Самая прекрасная архитектура бесполезна, если решает не те задачи, что требуются бизнесу. Для многих разработчиков профессия выросла из хобби, и удовольствие для них, по привычке, на первом месте. Но нанимают нас вовсе не для того, чтобы мы пускали радостные пузыри, полируя код, а чтобы мы эффективно решали задачи бизнеса в рамках имеющихся ограничений. И, на самом деле, это — реальный интересный вызов, а не игры в 30 строк на JavaScript.


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

            • +3
              ээээ, к чему этот вопрос?, тут вроде про другое, ну уйдете вы с такой работы, на ней что-то изменится? ну кроме того что некому, или другой будет указывать на огрехи.
              • 0

                Если десятичасовые объяснения не возымели эффекта, нужно выяснять, почему. Как минимум, разузнать (и понять) аргументацию отказа. Убедиться, что вы преследуете совместимые цели. В конце концов, вы либо поймёте, как правильно преподнести своё предложение, либо найдёте альтернативный вариант, всех устраивающий. Либо, в худшем случае — узнаете, что ваши старания напрасны, смысла в трате сил на попытки применить свои профессиональные качества нет, здесь уже не исправить ничего, Господь, жги.
                С работы, на которой вы не востребованы, уходить вполне нормально, иначе есть риск демотивации и профессиональной стагнации, а то и личностной деградации. Это вас тоже должно волновать, а не судьба компании, которой вы не нужны. Стокгольмский синдром, ей богу.

          • –1
            А вы не пробовали с другой стороны посмотреть? Да, можно переписать «правильно». И в долгосрочной перспективе (5-10 лет) это выгодно. А в краткосрочной — это пустая трата времени.

            Вася и Петя одновременно начали писать один и тот же продукт. Помните?

            Умение управлять техническим долгом — приходит ещё позже, чем понимание, к чему приводит неудачная архитектура.
            • +5
              Но Вася выпустил уже через месяц первую версию программы, пусть и не идеальную, пусть с багами, но рабочую, и ...

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

              А Петя — через пару месяцев выпустил отличный продукт, который принес ему заслуженые деньги и славу.

              Обе истории выдуманные, конец будет такой, как автор захочет, а оправдывать сообственный быдлокод сказками — низко.
              • –1
                Да вот в реальности — быдлокод побеждает. Сравните популярность Windows 95 c OS/2 Warp 4.0 или Windows NT 4.0. Из недавно мелькавшего на хабре — Duke Nukem 3D.

                Для оценки уровня быдлокодовости движка Duke Nukem
                Код движка находится в одном файле из 8503 строк и с 10 основными функциями (Engine.c) и в двух дополнительных файлах:

                cache1.c: содержит виртуальную файловую систему (sic!) и процедуры системы кэширования.
                a.c: реализация на C воссозданного обратной разработкой кода, который был высокооптимизированным x86-ассемблером. Код работает, но читать его — огромная мука!


                Так что увы, в реальности как в сказке.

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

                А быдлокод вообще-то называется технический долг. Просто использовать этот долг надо умеючи.
                • +1
                  Видите ли, бывает и так и так, а вы просто ищите оправдания быдлокода и потому видите только то, что хотите) Вот, например, вы увидели Duke Nukem 3D, но не увидели Doom с хорошим кодом)

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

                  Запускать технический долг выгодно только в одном случае — вы закончите продукт как его видите и никогда не будете поддерживать. Потому этот подход используют для прототипов, которые идут на выброс.
                  • –1
                    Глянул я тут по наводке в исходный код Doom и обмер…

                    Заранее приготовьте валидол
                    void Error (char *error, ...)
                    {
                    	va_list argptr;
                    
                    #ifndef __NeXT__
                    	if ( *(byte *)0x449 == 0x13)
                    		TextMode ();
                    #endif
                    
                    	va_start (argptr,error);
                    	vprintf (error,argptr);
                    	va_end (argptr);
                    	printf ("\n");
                    	exit (1);
                    }
                    



                    Ну если if ( *(byte *)0x449 == 0x13) для вас хороший код — то вы на 100% правы. Потому что до такого мы даже в прототипах не скатываемся.

                    Потому и живут у нас неоптимальные технические решения лет 5-10. И вполне переносят модификации. Та же Windows при всей её быдлокодовости проживала 25 лет.

                    Так что с вашей оценкой кода — у нас быдлокода вообще нет… :-) А с нашей оценкой — ну скорее всего весь ваш код плох.

                    но уже через 3 месяца внесения правок в продукт

                    Мда… Что это за анализ предметной области, если код нужно править в ближайшие полгода? Что-то мне вспоминается мой бывший коллега, который в своей книжке писал:

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

                    Результат неизменно стабильный…

                    Случайно это не ваш случай? Если ваш — то мне вас жаль.
                    • +1
                      Я не сказал, что через три месяца после начала разработки вносятся правки в продукт.
                      Я сказал про три месяца правок. Они могут начаться и значительно позже.
                      А в геймдеве и вообще активные правки с самого начала — единственный путь для нешаблонной игры. И да, геймдев — мой случай.
                      Кстати, вы про аджайл и итеративную разработку слышали? Или только на водопаде с заранее прописанной документацией работаете?
                      • –1
                        Ну судя по статьям Мосигры — далеко не единственный. Но могу ошибаться. Мы, конечно, не авионику делаем с её двухлетним циклом, но наше АСУТП намного ближе к авионике, чем к игрушкам. По крайней мере сегодняшние правки — как раз для беспилотника.

                        Про аджайл и так далее — почитайте "дефрагментацию мозга". Серега там хорошо и по аджайлу прошелся.

                        Одна из цитат
                        5. Одни из наших конкурентов широко используют agile-методы и TDD[121], но что-то оно им не очень помогает писать безошибочный код. Мы сравнивали количество найденных проблем в течение месяца-двух после major release, у нас показатели лучше в разы, если не на порядок. Частый выпуск версий просто не позволяет им довести код до ума и провоцирует исправление старых и серьёзных проблем методом написания «залепени». (Прим. автора: исправление ошибок, добавляющее новые проблемы.)


                        А у нас что-то среднее. Не аджайл, но и не жесткий водопад. И да, мы обычно на 3-5 лет понимаем, что может потребоваться, а что — нет. Неожиданности бывают, но редко.

                        А претензии к красивому коду у меня как у Жванецкого — "включаешь – не работает.". То есть шик, блеск, красота… но работает только для сферической лошади в вакууме. А на реальных данных — валится, как бык по скользи. Потому что программер думал об архитектуре, декомпозиции, делегировании, концепции… о чем угодно, но не о том, что модуль должен работать. Работать на реальных данных. С выбросами, лакунами и прочим дерьмом отклонением от идеала.

                        И любой работающий быдлокод — в 100 раз лучше неработающей красоты.

                        Особенно, если автор этой «красоты» заявляет, что адаптировать к реальным данным нельзя, ибо «архитектура не позволяет» и «концепция сломается». :-)
                        • +1
                          Ну судя по статьям Мосигры — далеко не единственный

                          При чем тут Мосигра? У них коробки делают, а не софт. Там делал-делал пока не закончил, а потом выпустил, что сделал. И имеешь очень мало влияния на проданные продукты.

                          И да, мы обычно на 3-5 лет понимаем, что может потребоваться, а что — нет

                          Так это ж просто ляпота, никаких сложностей.

                          Одни из наших конкурентов широко используют agile-методы и TDD[121], но что-то оно им не очень помогает писать безошибочный код

                          Очень странное понимание целей agile. Он и не создавался для того, чтобы код был качественнее, а для того, чтобы на изменения можно было реагировать быстро. Билд на продакшн, где сотни тысяч пользователей и огромное количество правок по их фидбеку каждые две-три недели, в том числе довольно серьезных. Куда уж там вашим 3-5 годам. Конечно у людей, которые работают по 3-летнему циклу будет багов в среднем меньше, чем у тех, которые работают по 2-недельному. Потому что 3-летний значительно проще.

                          Потому что программер думал об архитектуре, декомпозиции, делегировании, концепции… о чем угодно, но не о том, что модуль должен работать. Работать на реальных данных. С выбросами, лакунами и прочим дерьмом отклонением от идеала.

                          У вас странные понимания качественного кода. Не удивительно, что вы так агритесь на него. Качественный код — это не когда «много интерфейсов», а когда регулярные правки не вносят множество регрессий, когда новые фичи органично и легко вписываются в архитектуру, когда поддерживаются любые данные, или легко дореализовываются, когда сложность добавления фичей не растет с каждой новой фичей геометически.

                          Я понимаю, с таким циклом как у вас и на редаксе можно поговнокодить. За 5 лет оно все утрясется, костыли покроются пылью, которая потом отвердеет, а если пользователям что-то не нравится, то проект уже сдан и пусть приспосабливаются.

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

                            Мне помнится, в блоге Мосигры (а может и не в нем) были рассказы про разработку компьютерных игр. Не все игры писались «методом тыка», иногда люди хорошо представляли, что именно они хотят сделать.

                            У нас нету трехлетнего цикла. Есть основные продукты и есть заказы на конкретную модфикацию основного софта. Но, поскольку компания маленькая, аналитики и программисты — одно и то же. При разработке понимается, ну грубо говоря, что танк с вертикальным взлетом возможен, розовый танк с оборками и стразиками — невероятен, а вот деревянная броня — возможна, хотя и маловероятна.

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

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

                            Вы немного путаете качество кода со способностью кода к модификации.

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

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

                            P.S. Если не трудно, расскажите что такое редакс. А то «мужики-то и не знают». :-)
                            • +1
                              розовый танк с оборками и стразиками — невероятен


                              Некий российский режиссер с вами не согласен…
                              Обитаемый остров
                              image
                              • 0
                                Оборочек не вижу. И стразиков. Но +1!
                          • 0
                            Чтобы вам было понятней, почему качество и способность к изменениям -разные вещи, простой пример.

                            Вот есть восьмислойная плата, качественная-перекачественная. Чипы на BGA, рассыпуха 01005 (0,4 × 0,2 мм), дины линий выверены, импедансы рассчитаны и смоделированы, все фронты — ровненькие, хоть на 5 гигагрерц работой. Но вот только срок обновления у неё — 6 месяцев. И ремонтабельность нулевая.

                            А есть макетка. Быдло-быдло. Чипы — на DIP, рассыпуха — 1210 (3,2 × 2,5 мм), монтаж — проводом МГФТ, фронты завалены, об импедансе и длине линий и разговора нет, дай бог, чтобы на 150 мегагерц завелась. Но срок обновления у такой платы — 3 часа. И ремонт — хоть дома, хоть в офисе.

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

                            Ну у нас не макетки, но ближе к этому концу. За 3 недели можно новую плату сделать и софт на неё переделать. И даже за две, если печатную плату не заводским методом делать, а ЛУТом.
                        • 0
                          И любой работающий быдлокод — в 100 раз лучше неработающей красоты.

                          А вы действительно не путаете проблемность целевой области и заточку кода под неё (что может включать в себя массу адских хаков на частные случаи исключительно из-за ТЗ) и некачественность самого кода?
                          Если первое, то это не принято называть быдлокодом (разве что быдлозадачей).
                          Если второе, то покэпствую
                          1) красивый неработающий код, скорее всего, легче довести до рабочего состояния;
                          2) после этого он лучше сопровождаем, в отличие от быдлокода.


                          Пример с Doom и куском для NeXT, кстати, тут очень хорош дидактически :) С одной стороны, там очевидные странности в виде магических констант, которые по обычным нормативам надо описать в виде #define. Но я бы тут вместо этого поставил комментарий с описанием смысла конкретного числа.
                          С другой стороны, стиль, рекомендуемый во многих местах, потребовал бы сделать тут безусловно вызванное макро, которое было бы определено в непустое действие только для NeXT. А вот это уже хуже потерей локальности — надо идти неизвестно куда только для того, чтобы узнать, что для 99.999% случаев макро просто пустое.

                          • 0
                            Давайте разделим:

                            1. Быдлокод — это простой, некрасивый код, написанный в лоб. Часто большие размеры процедур, связь через глобальные переменные и так далее.
                            2. Хакерский код — эффективный, но очень сложный в понимании код с множеством трюков.
                            3. «красивый» код — эффективный код, написанный по всем правилам (классы, методы на все случаи жизни).

                            И вот вам пример, чем быдлокод лучше. Известная "Задача о восьми ферзях": Простой вариант с 8 циклами — легко обеспечивает переход к доскам непрямоугольной формы. А вот быстрый алгоритм Дейкстры…

                            1) красивый неработающий код, скорее всего, легче довести до рабочего состояния;
                            2) после этого он лучше сопровождаем, в отличие от быдлокода.

                            Увы и ах. Если в «красивом, эффективном коде» неверно понято ТЗ — заставить его работать можно лишь путем хакережа. И сопровождаемость после этого падает в ноль.

                            Неужели непонятно, что красота и эффективность идет за счет специализации кода (по условиям ТЗ)? Что вся декомпозиция — хороша лишь, пока программист верно понимает ТЗ и спектр его изменений? А если программер построил "мост вдоль реки", то его разворот обойдется дороже, чем написать его заново.
                            • +1
                              Неужели непонятно, что красота и эффективность идет за счет специализации кода (по условиям ТЗ)?

                              EPARSE, простите. Красота и эффективность — следствие специализации кода, или они страдают (ухудшаются) из-за специализации кода?


                              Что вся декомпозиция — хороша лишь, пока программист верно понимает ТЗ и спектр его изменений?

                              Нет, непонятно. На практике можно считать, например, что через год изменятся 10% требований, а за десятилетний цикл развития — чуть менее, чем все. (Реальные цифры с одной из моих прошлых работ.) Но каким образом из этого следует рекомендация писать всё так, что не заботиться о его сопровождении? Ведь даже если 20% изменилось, остальные 80% те же, а сопровождать надо каждый день.


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

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


                              И вот вам пример, чем быдлокод лучше. Известная "Задача о восьми ферзях": Простой вариант с 8 циклами — легко обеспечивает переход к доскам непрямоугольной формы. А вот быстрый алгоритм Дейкстры…

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


                              Давайте разделим:
                              Быдлокод — это простой, некрасивый код, написанный в лоб.

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

                              • –2
                                На практике можно считать, например, что через год изменятся 10% требований, а за десятилетний цикл развития — чуть менее, чем все.

                                МДА. Ну или у вас аналитики действуют методом памяти покойного академика тыка, или вы путаете изменения ТЗ с дополнениями, из у вас какое-то "настоящее" программирование типа поддержи сайта.

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

                                С другой стороны газонокосилка вполне может начать отстреливаться очередями, стан для оцинковки — делать алюминирование, а атомный ледокол — перейти экватор. Это маловероятно — но возможно.

                                Точно так же я понимаю, что на компе может не быть часов, а в байте неожиданно может оказать 32 бита,

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

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

                                Красота и эффективность — следствие специализации кода, или они страдают (ухудшаются) из-за специализации кода?

                                Ни то ни то. Делая код эффективным — мы теряем в его универсальности. Делая код красивым — опять теряем в универсальности.

                                Чтобы было понятней — вспомните дискуссию про goto сороколетней давности. Код с goto -очень гибкий. Но и некрасивый.

                                очень вероятно, что те же решения (быки-опоры, пролёты, методы их сцепления, покрытие для дороги) годятся для моста что вдоль, что поперёк

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

                                A вот сами быки и пролеты — выкидываются. Ибо после демонтажа быка половина остается под руслом. Там же сваи, они глубоко забиваются.

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

                                Вот из написания «в лоб» никак не следуют огромные процедуры и связь через глобальные переменные, и наоборот.

                                Соглашусь, лоб у всех разный, естественный код — тоже.

                                В моей юности процедуры на 5 страниц считались отличным (и понятным кодом). Именно в этом стиле и писали в журналах и книгах по программированию. Ну и блок глобальных данных — был вообще единственным способом эффективной связи по данным.
                                • +1
                                  Так что если я решил, что какого-то изменения не будет, а оно произошло — это моя ошибка. Дописываний бывает много и очень разных, а вот непредсказанные изменения — это редкость. Ну, разумеется, если понимаешь предметную область.

                                  Никакое понимание предметной области не спасёт от странных инновационных требований заказчика. Или, как вариант: "когда мы это обсуждали 5 лет назад, то было совсем другое правовое поле, никому в голову не могло прийти, что законодатель ограничит размер пени сверху". Не думаю, что следует считать своей ошибкой то, что никому в голову прийти не могло.

                                  • 0
                                    Уточню — моя ошибка как аналитика предметной области. Или другого аналитика.

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

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

                                    Новый режим стирки — дополнение. Изменение параметров режима стирки — тоже дополнение, пишем новый режим, а старый просто не вызывается.

                                    Замена датчика — опять дополнение. Пишем чтение с нового датчика и не вызываем код для старого датчика.

                                    ДА, исходники разбухают. Но одним кодом + таблица конфигурации мы поддерживаем всю линейку стиральных машин от царя гороха до наших дней.
                                    • +1
                                      В качестве примера, придумайте изменения ТЗ для программы, работающей в стиральной машине.

                                      Вы раз за разом приводите в пример вотерфол-подобные методологии. Да, такой подход есть и он накладывает повышенную ответственность на аналитика и снимает эту ответственность с программиста. Я же вам привел пример — почти весь современный ГеймДев, трехнедельные итерации, есть поверхностное понимание, что будет в задачах в ближайшие два месяца и максимум — хорошее понимание на ближайший спринт. И сам домен к этому располагает — в любой нешаблонной игре любая фича может зайти или не зайти.

                                      Посмотрите на историю развития World of Tanks, к примеру. Или Hearthstone. Или RimWorld. Или Minecraft.

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

                                      Да, на таких проектах в среднесрочной перспективе говнокод может вполне себе работать. Именно потому я в самом начале ветки написал следующее:
                                      Запускать технический долг выгодно только в одном случае — вы закончите продукт как его видите и никогда не будете поддерживать

                                      И ваш пример со стиральной машинкой — отличный. Вы сделали, как сделали, небольшая группа потестила, всё, что криво — записали в руководство «дважды кнопку не нажимать» и отдали пользователям — пускай себе трахаются. А вот если стиральную машинку отдаете пользователям, а потом понимаете, что барабан должен быть на 60% больше и вам это нужно сделать не в новой машинке, а за три недели. А потом понимаете, что механические кнопки слева не подходят и надо поставить рычажки справа и у вас на это три недели. А потом понимаете, что рычажки справа не подходят, а сверху надо поставить тач-скрин. А после этого понимаете, что слив в том месте у 20% вызывает разлив воды потому что они его неправильно подключают и вы переделываете слив. И так три года.

                                      Если вы в таком режиме будете быдлокодить — поймете, о чем я говорю.
                                      • –2
                                        Вы раз за разом приводите в пример вотерфол-подобные методологии.

                                        Отнюдь. Вполне можно и по скраму.

                                        У вас есть 200 сейчас продающихся моделей стиральных машин, 100 — уже не продающихся, но поддерживаемых и 50 в новой разработке. Реально это выливается в поддержку 7 вариантов процессорной платы, 30 вариантов пультов и по 3-5 вариантов каждого датчика и исполнительного устройства + не на всех моделях есть все датчики и все агрегаты.

                                        И вот всю эту армаду в 350 моделей вы и делаете по скраму. По модели (или группе моделей на спринт).

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

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

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

                                        Если вы в таком режиме будете быдлокодить — поймете, о чем я говорю.

                                        я в таком режиме уже почти 10 лет работаю. 6 операционок (Linux, Windows, FreeRTOS, FreeBSD, MS-DOS, QNX, МСВС считаем за linux), 6 компиляторов (gcc, clang, lcc, borland C++, С Builder, MS VC++) 3 разных архитектуры (x86, ARM, SPARC) и куча конкретных продуктов. Ну не 350, но к двум десяткам. И всё это — на единой кодовой базе и с приличным техническим долгом.

                                        Ниша у нас такая — полузаказные продукты делать. И поддержка пожизненная. То есть лет на 10-20.

                                        Да, такой подход есть и он накладывает повышенную ответственность на аналитика и снимает эту ответственность с программиста.

                                        Последние лет 15-20 лет я занимаюсь и тем и тем. То есть для меня это перекладывание ответственности с одного плеча на другое.

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

                                        Это называется разработка методом тыка. Или вы настолько мелкая сошка, что аналитики не считают нужным ставить вас в известность.

                                        А основное отличие в другом. Мы делаем для реального мира. Наши приборы и решения реально нужны. За них платят потому, что без них — обходится дороже.

                                        А вы — делаете для выдуманного, цифрового мира. Если не будет игрушек — никто денег не потеряет. Никто не придет к вам и не скажет — сделайте мне систему, это мне сэкономит полмиллиона долларов в месяц. Сделали. Сэкономили в итого больше сотни миллионов в год на отдельных режимах.

                                        Вы можете позволить себе сидеть без заказов и действовать методом тыка. Мы — не можем. Методом тыка мы можем только по миру пойти.

                                        Мы знаем, что мы можем сделать за 2 месяца, за год, за 3 года… И постоянно ищем себе заказы. И постоянно выбираем, в какие ниши идти, а в какие нет.

                                        Мы не можем сказать «а давайте попробуем вот такой вариант, вдруг он кому-то нужен». Прежде чем что-то делать, мы должны понимать, кому мы продадим, по какой цене, каким тиражом.

                                        А что касается гавнокода, то я уже описывал вам, чем гавнокод лучше. И что именно из-за гавнокода мы имеем короткий цикл модификации. Увы, вы на это ничего не ответили.
                                        • +2
                                          Это не за три недели, в нормальном коде это делается за день, если не за час. Изменили константу в конфигурации, потестили и отдали в production.

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

                                          У вас есть 200 сейчас продающихся моделей стиральных машин...

                                          Вы теоретизуруете. А я говорю о реальных проектах.

                                          А что касается гавнокода, то я уже описывал вам, чем гавнокод лучше. И что именно из-за гавнокода мы имеем короткий цикл модификации. Увы, вы на это ничего не ответили.

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

                                          А вы — делаете для выдуманного, цифрового мира

                                          Да, я знаю, что вы обижены на game-developer'ов и web-developer'ов, но эти факты не делают вас лучше. Вот я какое-то время писал медицинский софт, то не говорю ведь вам теперь: «вот, вы просто за бездушные деньги работаете, а я жизни людей спасал». Странно звучит, правда. А вы так постоянно говорите.

                                          Это называется разработка методом тыка. Или вы настолько мелкая сошка, что аналитики не считают нужным ставить вас в известность.

                                          Молодцы. Возьмите с полки пряник. Это специфика вашей отрасли. Огромное количество фирм сейчас живет по другим принципам.

                                          Это называется разработка методом тыка.

                                          Я стараюсь не судить о том, в чем не разбираюсь. А зачем вы поступаете иначе?

                                          Или вы настолько мелкая сошка, что аналитики не считают нужным ставить вас в известность.

                                          Оскорбления. Прекрасный ход. Сразу видно силу и аргументированность вашей позиции.
                                      • 0
                                        Хочется ещё немного покэпствовать.

                                        Запускать технический долг выгодно только в одном случае — вы закончите продукт как его видите и никогда не будете поддерживать

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

                                        Технический долг не мешает развивать системы десятилетиями. Думаете в linux или FreeBSD нету технического долга? Его там порядочно. Мы ушли с FreeBSD, обнаружив, что драйвер ком-порта для нужной нам SoC просто не работает на высоких скоростях (выше 19200 бод). А в тексте драйвера нашелся комментарий «я знаю, это будет сбоить на высоких скоростях, если кому нужно — исправьте сами».

                                        Ещё смешнее технический долг в процессорах. Самая смешная история — 1986ого года. Иногда программа вылетает по нереализованной операции. Разбираемся, выясняется что при старте делится мусор на мусор. Смотрю в микрокод процессора и вижу, что нормализация операндов перед делением не сделана, а если операнд не нормализован — дается прерывание по нереализованной операции. Меняем микрокод процессора с 14ой версии на 18ую — и все работает. Кстати, меняли перетыканием платы с микрокодом. Он хоть и микро, но занимал отдельную плату в корзине процессора.

                                        Правильно я понимаю, что вы работали лишь в системе бардак? И что вы никогда не понимали планов на ближайшие 3-5 лет? Обратите внимание, что бардак — это не базар. Что во многих открытых проектах есть roadmap на годы вперед.

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

                                        Ну и о быдлокоде.

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

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

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

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

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

                                        Если нужен пример, то представьте в WoW этот самый летающий ледокол. Корневая иерархия — плавающие, едущие, летающие… Потом иерархии второго уровня. Ну и что вы сделаете с летающим ледоколом? Новый тип «плавающие-летающие»? Или множественное наследование?

                                        Более-менее тут помогают интерфейсы, наподобие тех, что в JAVA.

                                        Ну и последнее — это усталость кода. Вот она прежде всего зависит от того, что удалось предусмотреть при выборе архитектуры. Не предусмотрели — получите усталость или рефакторинг. Предусмотрели — все норм.
                                    • +1

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


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

                                      • 0
                                        Внезапные — это те, которые приняли во втором чтении прямо с голоса. А все что шло через АСОЗД — это уже не внезапные. В данном случае законопроект проходил Думу 5 лет, а от принятия поправки до вступления закона в силу — больше полугода. Если вы об этом узнали внезапно — это опять проблема ваших аналитиков.

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

                                        ОГО! Удалять — это как??? Неиспользуемые — это как????

                                        У вас 350 моделей стиральных машин. Вы собрались на них иметь 350 комплектов исходников? И каждый баг ядра править в 350 местах?

                                        Делается один комплект исходников. И 350 файлов конфигурации к нему. Или путем задания дефайнов или путем присваивания указателям на процедуры (а что не вызывается — линкер выкинет).

                                        Замена датчика — только в новых машинах. Новый режим стирки — только в новых машинах, Изменение параметров режима стирки — тоже только в новых.

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

                                        У вас что, единый софт для всех банков и всех стран? И никаких правок для отдельных банков? ну так вам везет, не надо с зоопарком версий мучаться.

                                        У нас тоже не 350 вариантов, но пара десятков наберется. 6 операционок, 6 компиляторов, 3 архитектуры процессора… Так что прежде чем выкидывать — надо понимать, точно ли ни одно из живых устройств никогда не потребует выкидываемого кода…

                                        Да и вообще, выкидывание кода — дело линкера. Он это сделает лучше.
                                • +1
                                  МДА. Ну или у вас аналитики действуют методом тыка, или вы путаете изменения ТЗ с дополнениями, из у вас какое-то "настоящее" программирование типа поддержи сайта.

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


                                  Да, значительная часть хотелок превращалась в дополнения, но были и такие, которые требовали рефакторинга с самого нижнего слоя.


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

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


                                  Точно так же я понимаю, что на компе может не быть часов, а в байте неожиданно может оказать 32 бита,

                                  У нас без часов там не бывало, и 32 бита на системе наблюдения — тоже, хотя для этого не нужно гоняться за изделиями загадочной российской военщины — простой Cray тоже отлично подойдёт на это. Некоторым приближением к таким диверсиям были вычислительные модули на Cell.


                                  Так что если я решил, что какого-то изменения не будет, а оно произошло — это моя ошибка.

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


                                  В качестве мини-примера: одно из таких направлений, очень перспективное, сорвалось из-за того, что генподрядчик попал под санкции. (Это было ещё в 11-м году, так что с нынешней политикой прямо не связано.) В результате были запущены другие направления развития. Несмотря на материальность сферы, предсказать такое невозможно. Можно только быть готовым держать систему наготове к движению в любую разумную сторону.
                                  И да, мы могли предсказать, что направление A потребует такого-то изменения, B — другого. Но пока нет никаких достоверных данных о движении в эту сторону — браться менять смысла нет. А изменения между собой слабо совместимы, скорее конфликтуют. Так зачем спешить вводить одно, даже если видишь, куда и как оно могло бы двинуться? Чем проще и прямее реализация на каждом этапе под его требования и под гарантированную (а не предполагаемую) перспективу, тем лучше.


                                  Чтобы было понятней — вспомните дискуссию про goto сороколетней давности. Код с goto -очень гибкий. Но и некрасивый.

                                  Я скорее отношусь к тем, кто "GOTO considered harmful" considered harmful. Потому что и return из середины, и break/continue это смягчённое goto, и автогенерация кода может их рожать пачками, и в машинном коде оно, а не if/while, и ваще. Сам иногда применяю в типичных шаблонах (например, на голом C — объединить код cleanup-веток некоторой функции). У меня критерий к нему — чтобы код был понятен тем, кто не заражён религиозной неприязнью.


                                  И вот это


                                  Код с goto -очень гибкий. Но и некрасивый.

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


                                  Делая код эффективным — мы теряем в его универсальности. Делая код красивым — опять теряем в универсальности.

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


                                  В моей юности процедуры на 5 страниц считались отличным (и понятным кодом). Именно в этом стиле и писали в журналах и книгах по программированию. Ну и блок глобальных данных — был вообще единственным способом эффективной связи по данным.

                                  Не знаю, как это соотносится с моей юностью, но начинал я на Fortran. Common-блоки использовались скорее для удобства не-передачи контекста каждый раз и для замены не существовавших тогда структур, чем для собственно эффективности.
                                  Процедуры на 5 страниц и более там и сейчас норма (на днях копался в BLAS), но в специфическом контексте, где это почти не мешает. В системном программировании такие или там, где ну очень тяжело разрезать иначе (как tcp_input() в классическом BSD), или в очень специфическом стиле (sendmail).
                                  А что было неэффективным в случае иной связи? Слишком много возни с указателями?

                                  • 0
                                    Да, значительная часть хотелок превращалась в дополнения, но были и такие, которые требовали рефакторинга с самого нижнего слоя.

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

                                    Но когда оказывалось, что сокращение предельного времени реакции на событие X означало, что вся старая логика детекта этого события на основании характерных свойств последовательности значений датчиков не работает,

                                    Ну вот примерно ради такого мы и отлаживали СУБД на миллион записей в секунду при том, что реально у нас всего 10 тысяч в пике (и до 200 без пика).

                                    Никакая «реальность» задачи, в Ваших терминах, не защитит от таких проблем.

                                    Да, тут только опыт. Помните у Туполева "сломается здесь"? 100% не предусмотришь, но 95% — вполне.

                                    Вот тут принципиально расходимся. Не ошибка.

                                    Уточню. Моя ошибка как аналитика предметной области. Ну или ошибка того аналитика, кто подписался, что уж такого — точно не будет.

                                    Можно только быть готовым держать систему наготове к движению в любую разумную сторону.

                                    И я об этом же. Если система к движению в какую-то сторону не готова — это ошибка аналитика. Или команда программистов вообще не видит дальше спринта (а надо смотреть на 5-10 лет вперед).

                                    Второе совсем сомнительно

                                    Красота — это ещё и выкидывание лишнего. Разных зацепок, закомментированного кода «на будущее», полировка разных мест, по которым видна история кода… В итоге красивый код модифируется хуже.

                                    Красиво:
                                    printf("V=%.1f\n",GetV());
                                    

                                    Некрасиво:
                                    double V = GetV());
                                    printf("V=%.1f\n",V);
                                    

                                    Но второй вариант проще и в отладке и в модификации.

                                    А что было неэффективным в случае иной связи?

                                    Обращение к переменным объемлющей процедуры. Алгол-60 это позволял. Указателей в алголе-60 и фортране-IV вроде не было (или не было в тех реализациях, с которыми я работал). В алголе-60 можно было немного оперировать с метками, но это указатели на код, а не на данные.
                                    • +1
                                      Давайте не путать изменения ТЗ с дополнениями, которые потребовали рефакторинг из-за непродуманности структуры.

                                      Почему не путать? Как раз я не вижу причины вводить тут вообще какую-то принципиальную разницу. Формально дополнение очень часто вызывает необходимость перестройки, а изменение столь же часто вызывает всего лишь поверхностную переделку отдельных компонентов. В любом случае это изменение ТЗ, а какое оно даст эффекты — непредсказуемо. Иллюстрация в тему.


                                      100% не предусмотришь, но 95% — вполне.

                                      В 95% мы вполне вкладывались. Оставшихся 5% хватало, чтобы последствия обсуждать ещё много лет. :) И Туполеву наверняка не ставили задачи в виде "самолёт должен летать год без посадки".


                                      И я об этом же. Если система к движению в какую-то сторону не готова — это ошибка аналитика. Или команда программистов вообще не видит дальше спринта (а надо смотреть на 5-10 лет вперед).

                                      Реально получалось видеть с достаточным качеством на год, в общих чертах — на три.


                                      double V = GetV());
                                      printf("V=%.1f\n",V);
                                      Но второй вариант проще и в отладке и в модификации.

                                      Ну, опустим, что они неравнозначны (вот в варианте

                                      printf("V=%.1f\n", (double) GetV())
                                      есть действительно полное соответствие). Если отладка это распечатать V и/или не спутать пошаговый проход GetV() с printf() — да, согласен.
                                      Но с модификацией связи не вижу. Наоборот, первый кажется проще для модификации — за счёт отсутствия лишних сущностей. Ту же переменную V надо проследить, чтобы её значение нигде дальше не использовалось. Вот если бы был оператор типа unvar (del в Python), чтобы поставить после printf и после этого чтобы V была неизвестна — тогда не надо было бы смотреть вниз.


                                      Указателей в алголе-60 и фортране-IV вроде не было (или не было в тех реализациях, с которыми я работал).

                                      В Фортране IV всё передавалось по указателю. Передача по значению появилась позже. От этого возникал ряд неприятных эффектов. Но я понял идею этого пункта, спасибо.

                    • 0
                      Мда… Что это за анализ предметной области, если код нужно править в ближайшие полгода?

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

                      • –1
                        В нормальном быдлокоде это дописывания, а не правка. Причем больше конфигурации, чем кода.

                        Но вообще внутренний софт редко пишется нормально…
                        • 0

                          Правка — довольно частое явление, причём очень значительная, в корне меняющая модель, а то и архитектуру. Из личного опыта, например, предоставление новых услуг, в том числе анонимно (много лет была одна единственная по предъявлению паспорта и заведения клиента в базе) или требование государства обеспечивать фискальную регистрацию, да ещё в режиме онлайн, когда архитектура вообще интеграции с периферией не предусматривала и понятий типа "закрытие кассы", "Z-отчёт" и т. п. не было.

                          • 0
                            Ну если у вас бизнес-процессы заведены прямо в код — то я вам сочувствую. Подумайте о том, почему в 1С-предприятии при тех же изменениях в законах не пришлось ничего переписывать.
                            • 0
                              Подумайте о том, почему в 1С-предприятии при тех же изменениях в законах не пришлось ничего переписывать.
                              Потому же, почему при изменениях в ТЗ не нужно переписывать код компилятора С или интерпретатора BASIC?

                              Вынуждан признать — с 1С я сам лично не общался. Но на болезненный процесс переписывания модулей при выходе новых законов моя сестра, бухгалтер, жалуется регулярно…

                              Уверяю вас, при изменениях в законах в системах, созданных на базе 1С приходится переписывать массу всего. А интерпретатор — он интерпретатор и есть, чего с него взять-то?
                              • +1
                                Такое происходит только тогда, когда біли произведены модификации самой конфигурации 1С. Это как жаловаться что при апдейте зависимостей композером у вас в папке вендор перетираются ваши фиксы
                              • 0
                                Ну насколько много? Где-то порядка десятой процента кода на 1С максимум. Потому что само 1С-предприятие — не просто интерпретатор языка 1С.

                                А «много переписывать» — это такая мантра, при помощи которой программисты на 1С набивают цену. Потому что можно ничего не переписывать, а сделать новый документ с новой функциональностью.

                                А дописывать — намного проще, чем переписывать. Так вот, структура 1С позволяет в большинстве случаев просто дописать новые документы (модули).
                            • 0

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


                              Я тоже не переписываю PHP при изменениях в законах. Вот надо интеграцию с ККМ делать теперь бизнесу — пишу PHP-код технической интеграции и делаю изменения в код бизнес-процессов.

                              • 0
                                Ускорение запросто делается путем написания своего компилятора, Благо технологии компиляции — это вполне доступная рядовому программисту штука. То есть один раз разпарсили, потом скомпилировали нужные SQL-выражения и записали во временном файле. Дальше просто проверяем, не изменилось ли описание бизнес-процесса.

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

                                Что касается эффективности — то у нас один и тот же технологический код отлаживался на персоналке, а выполнялся под DOS на 80188 с 40 МГц.

                                Вот на таких вот
                                image

                                Заказчики очень удивлялись, что мы делаем серьезную автоматизацию производства на таких вот крохах.

                                Так что не преувеличивайте потери скорости — они не больше 5%. Зато у такой системы два важных плюса:

                                • Отладка на конструкторе в десятки раз быстрее, чем на контроллере.
                                • Процесс описания ТЗ сливался с процессом конструирования. То есть ТЗ было проще описать прямо на конструкторе, лишь отдельные места описав словами.
                                • 0

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

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

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

                                    • 0

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

                                      • 0
                                        Ну или вы жалуетесь, что быдлокод не позволяет делать изменения, а изменения у вас частые и постоянные. Или = утверждаете, что изменений немного. А одновременно и то и то — это выглядит смешно. Мыши плакали и кололись, кололись и плакали, но они все равно продолжали грызть кактусы.
                                        • 0

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


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

                                          • –1
                                            Вот вам пример, как быдлокод позволяет ускорить время внесение изменений в сотни раз. Разумеется, за счет других, не так важным нам характеристик.

                                            И не путайте дописывание с переписыванием. Дописывание намного меньше вызывает усталость кода.
                                            • 0

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

                                              • 0
                                                Ну тогда и разницы между 8086 и Xeon тоже никакой нет. :-) В принципе архитектура та же. Подумаешь 3 гигагерца вместо 8 мегагерц…

                                                Ну и разница между dBase и MS SQL тоже нулевая. Ведь и то и другое — СУБД.

                                                Да и современный телевизор — брат-близнец приемника Поповаю
                    • +1
                      Ну если if ( *(byte *)0x449 == 0x13) для вас хороший код — то вы на 100% правы. Потому что до такого мы даже в прототипах не скатываемся.
                      А в чём проблема с данным кодом? Два хорошо известных (в те годы) числа сравниваются друг с другом — в чём проблема? 0x449 — это текущий видеорежим, 0x13 — это VGA-графика (которую, соответственно, нужно отключить).

                      Эти числа в годы написания DOOM'а чуть ли не на столбах клеились! Уж во всяких книжках по программированию они были точно и, зачастую, в книжках, прилагаемых к компьютеру, они тоже существовали.

                      А влияние добавления сотни строк к коду на скорость компиляции в те годы оказазывало заметное влияние…
                      • 0
                        А элементарно задефайнить константы слабо? Ну скажем на случай смены видеорежима?
                        • 0
                          А элементарно задефайнить константы слабо? Ну скажем на случай смены видеорежима?
                          Вы притворяетесь или издеваетесь? После VGA — уже ничего никогда не было. Вообще. Никогда. SuperVGA — уже не было стандартом и, соответственно, простой заменой чисел не обойтись. Нужно будет добавить таблицы известных видеоадаптеров (да-да, это DOS, детка), код для их распознавания и прочее.

                          А оно точно надо во внутренней утилите конвертации файлов? Может лучше просто решить что вот конкретно она — будет работать только в VGA и всё?
                          • –1
                            В любом случае — это пример быдлокода.

                            Что касается технической оправданности — вполне можно было подумать о порте под аркадный автомат с конкретным видоадаптером. Или о будущем порте под iPhone.

                            В любом случае, если бы я писал такой код, то он минимум был бы под #ifdef PC_VGA. Потому что #ifndef __NeXT__ это мягко говоря неправильно. Ну неверно же считать, что всё, что не NeXT — это именно IBM_PC и VGA!
                            • 0
                              вполне можно было подумать о порте под аркадный автомат с конкретным видоадаптером
                              Это вы утилиту конвертации файлов под аркадный автомат портировать собрались? Нафига она там?

                              Ну неверно же считать, что всё, что не NeXT — это именно IBM_PC и VGA!
                              Внутри студии id Software во времена создания Doom'а? Почти наверняка.

                              Ещё раз: вы смотрите на код вспомогательной утилиты, которая никогда не поставлялась вместе с Doom'ом.

                              Сам Doom был портирован… куда он только не был портирован! Разве что на калькуляторах его нет (хотя нет — есть). А утилита конвертации… изначально она только под NeXT затачивалась, а потом её ещё и на PC с горем пополам запустили.

                              Уже велась разработка Quake, уже было понятно, что этой утилите долго не жить — и вы хотите, чтобы её затачивали под аркадные автоматы???
                              • –2
                                Интересно, откуда информация, что cmdlib — это утилита конвертации файлов? Судя по исходной статье — это что-то более интеллектуальное.

                                В любом случае, быдлокод — есть быдлокод.

                                А что касается технических преимуществ быдлокода — то согласен с вами, они есть.
                      • 0
                        Да и не в те годы, а сейчас, человеку, который эти два числа никогда не видел, все понятно. Но лучше было бы вынести проверку в отдельную функцию
                        bool isTextVideoMode()
                        
                        • 0

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

                          • +1

                            Учитывая, где эта функция вызывалась, она точно не могла быть узким местом.
                            А использование макросов стоит избегать настолько, насколько это возможно.

                            • +1
                              Глядя на вашу дискуссию плакать хочется. Вы, вообще, учитываете что речь идёт о годах, когда на компютерах штатно стояло по 640К памяти, а в журналах на полном серьёзе обсуждалось — нужно ли использовать в циклах указатели или индексы (и да, разница была заметной — десятки процентов)?

                              Не стоит оценивать качество тогдашнего кода с позиций сегодняшнего дня. Чушь получается. Даже если сегодня пишется код под DOS (а он пишется, не сомневайтесь — вот прямо тут и пишется), но даже при этом они на этой крохе свои проекты не компилируют! А тогда… Вы думаете все эти NOKANJI и NOSERVICE от хорошей жизни появились?
                • 0
                  Но верно и то, что линейка Win95 загнулась, потому что просто не смогла развиваться.

                  Связано ли это с качеством её кода? Или всё-таки с тем, что принципиально беззащитный дизайн перестал котироваться, а компы дотянули до мощности, когда NT-based решения перестали быть аццким тормозом?
                  Насколько я в курсе, там существенные затраты шли таки на проблемы совместимости с DOS. Избавление от неё сначала при переходе на Win2000, а затем (в Vista) при устранении DOS mode и 16-битки — были громкими праздниками.

                  • +1

                    Вы таки удивитесь, но таки Win2000 из линейки nt. И оно изначально было самостоятельной операционкой, а не надстройкой над DOS. Равно как и её продолжатель XP.


                    Линейка 9х кончилась в виде:
                    95 (+апгрейды), 98 (+апгейды), миллениум.

                    • +1
                      Вы таки удивитесь, но таки Win2000 из линейки nt.

                      Я таки удивился, что Вы считаете, что я считаю иначе. Я не дал к этому никакого повода.


                      95 (+апгрейды), 98 (+апгейды), миллениум.

                      Спасибо, кэп. :)

                  • 0
                    Вы путаете разные вещи. Одно дело — подсистема WoW, которая вполне себе жила и в Win2к и дальше и устранилась лишь в 64битных вариантах. Сосбственно никаких особых проблем она не создавала.

                    Другое дело — старт Windows 3.1 как приложения MS-DOS и использование досовых драйверов. Вот тут и были основные проблемы. Они решаемые, Win95 уже обычно использовала 32битные собственные драйвера для диска дисплея, звуковой карты и так далее… Но сказалась усталость кода…
                    • –1
                      Вы путаете разные вещи.

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


                      Одно дело — подсистема WoW

                      Про WoW я ничего не говорил. Говорил про то, что в линии NT называется NTVDM, а в 9x как-то иначе. Сейчас уточнил — да, оно в 32-битных версиях вроде бы есть и сейчас.


                      Но сказалась усталость кода…

                      Или скорее то, что альтернативный перспективный код был давно стабилизирован и готов к использованию.

                      • 0
                        RTFM, NTVDM — это основной компонент подсистемы WoW16:

                        NTVDM (NT Virtual DOS Machine — «виртуальная машина DOS для системы NT») — компонент, входящий в состав 32-разрядных редакций операционных систем семейства Windows NT, позволяющий запускать 16-разрядные приложения Windows и 16/32-разрядные приложения DOS


                        Для справки. Windows NT вышла в июле 1993 года, OS/2 Warp на той же кодовой базе в октябре 1994ого.

                        А линейка Win 3.1 загнулась после крайне неудачной WinMe:

                        Windows Me сильно критиковалась пользователями из-за её нестабильности и ненадёжности, частых зависаний и аварийных завершений работы. В одной из статей в журнале PC World аббревиатуру МЕ расшифровали как «Mistake Edition» (ошибочное издание) и поместили на 4-е место в списке «Худших продуктов всех времён».


                        Почитайте "Inside Windows 95" или Unofficail windows 95 — поймете, что только титаническим трудом они смогли заставить Win95 работать настолько стабильно. То есть падать раз в несколько часов, а не раз в 5 секунд. Но к WinMe даже возможностей микрософт для поддержания гавнокода не хватило.
                        • 0
                          Но к WinMe даже возможностей микрософт для поддержания гавнокода не хватило.
                          Не совсем так. Windows 98SE — последняя запланированная версия Windows 9X — была весьма стабильной. А Windows ME пришлось срочно выпускать, чтобы «закрыть дыру», когда-то​ с Windows Neptune вышел облом-с.

                          Разумеется изделие сделанное далеко не лучшими программистами, знавшими к тому же, что они делают продукт «на выброс» оказалось не самым лучшим…
                          • 0
                            Может быть и так, особенно, если вы видели пруфы, что ME делала иная команда.
                        • 0
                          RTFM, NTVDM — это основной компонент подсистемы WoW16:

                          Это никак не следует ни из процитированного Вами текста, ни из просто определения win-on-win. Скорее надо говорить, что NTVDM — нижележащее средство для WoW16.


                          Почитайте "Inside Windows 95" или Unofficail windows 95 — поймете, что только титаническим трудом они смогли заставить Win95 работать настолько стабильно.

                          Читал, и именно об этом и говорю. И там как раз написано, почему так — не потому, что просто вдруг оказался там кривой код (с их ресурсами они всё это исправили бы), а потому, что само построение ОС не давало шансов сделать беспроблемное устройство.


                          А линейка Win 3.1 загнулась после крайне неудачной WinMe:

                          Которую мало кто ставил.

                          • 0
                            Организационно NTDVM — это часть подсистемы WIn16. То есть у нас есть kernel API и подсистемы WIn32, Win16, OS/2, POSIX с пользовательскими API. А отдельной подсистемы DOS — нету, она считается «Win16 console».

                            Из этого следует интересный технический вывод — в консольной DOS-программе под Windows NT можно использовать то, что было в WIn16, но отсутствовало в DOS. Например — обращаться к сетевым файлам.

                            само построение ОС не давало шансов сделать беспроблемное устройство.

                            Это и называется «усталость кода». А кривизна там возникала из-за необходимости сделать совместимость с софтом, накопленным за 20 лет.
                            • 0
                              А отдельной подсистемы DOS — нету, она считается «Win16 console».

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


                              в консольной DOS-программе под Windows NT можно использовать то, что было в WIn16, но отсутствовало в DOS. Например — обращаться к сетевым файлам.

                              Ну там очень много чего можно было использовать через спец. интерфейсы. Например, то, что запускалось через DOS4G[W] и тому подобные экстендеры, под Win95 запускалось нативно (а даже если программа просила экстендер, тот просто "встраивал" свои действия в Windows). Для сети Win95 эмулировала SMB интерфейсы стиля Lantastic и аналогов. Но если это не выглядело Win бинарником, а был просто досовским .exe — то прямой путь к Windows-интерфейсам был недоступен (можно было требовать её dllʼки, но там требовалась особая осторожность).
                              Вообще, этот слой там чуть ли не высшее произведение инженерной осторожности за всю историю осестроения — заслуживает отдельного рассказа (увы, я знаю оттуда дай бог чтобы 2%, и не возьмусь).

                              • 0
                                Ну в общем да, Win95 глюкало ещё то было… И для совместимости там столько наворочали,… что даже думать страшно. Вплоть до опознавания отдельных EXE (в основном игрушек) по имени.
        • +2
          Проблема, как правило, не в способах предоставления информации, а в политических мотивах лиц принимающих решение. В частности, в преследовании краткосрочной выгоды для себя лично (должность, авторитет, ЧСВ), чем долгосрочной для организации (прибыль, положение в сегменте рынка).
          • +4

            В таком случае, почему вы позволяете этому происходить, если деструктивная природа действий вам очевидна? Если работник, преследуя личные интересы, вредит производственному процессу и лично вашей работе — чем это отличается от воровства, например? Если вас реально волнует результат работы, почему вы позволяете кому-то обесценивать ваш труд и вредительствовать? Хата с краю?


            Повторюсь, в конце концов, если невозможно исправить ситуацию — из неё всегда можно выйти. Было бы желание реально что-то делать, а не уныло констатировать факты.

            • +1
              Да, вы все правильно пишете: не нравится — меняй, не можешь изменить — уходи. Изменение неосуществимо в виду политической специфики (руководство — близкие друзья директорства). Но подобные расклады не очевидны в первые месяцы работы. И через какое-то время, когда все становится ясно, планируется тот же уход. Который крайне редко делается моментально.

              Так что какие бы красивые схемы в учебниках не предлагали на тему реализации изменений — в реальной жизни они очень редко применимы.
              • 0
                Очень редко в данном случае было бы, если бы описанная вами ситуация была почти везде. Впрочем тогда было бы странно ожидать иного и эта ситуация была бы очевидна сразу просто потому что так везде. Но в реальности это все-таки не совсем так и есть достаточно компаний, где изменения возможны.
              • 0

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


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


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

                • 0

                  А какие вопросы могут помочь это выяснить на этапе собеседования?

                  • 0

                    Очевидно, любые, вас интересующие. А уж там всё становится понятно по ответам или уклонению от них.

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

          словоблудием я мог бы заниматься, но во-первых, читать многабукав никто не будет, во-вторых, «спасибо за мнение, но мы всё равно будем делать как нам хочется, а не как по уму надо». то есть, всё решает политика. и бабло. по уму ведь делать — дольше и дороже.
          • +1
            Бизнес отлично понимает что такое стоимость владения и способен умножить человекочасы на рейт. А вот абстрактные «по уму и как надо» для бизнеса действительно белый шум.
            Проанализируйте ситуация и подайте в виде сравнительной таблицы
            Стоимость разработки, поддержки, внедрения новых фич в человекочасах. Если это не поможет, тогда либо начальник ваш Тимоти Декстер
            • +1
              либо ваши «лучше и как надо» на самом деле не лучше.
        • +1
          Конечно же, эта пламенная речь должна сопровождаться хотя бы парой слайдов

          Не перебор ли для предупреждения попыток руководства наступить на грабли? Пара "продающих" слайдов — это день работы минимум.

          • +1

            Это только в первый раз, и то только при неоптимальном подходе. Я б даже сказал — неправильном. Любой доклад надо выносить, в один присест мало кто способен сделать.


            Основная часть вообще времени не занимает — проблемы находятся сами в рабочее время, возможные решения, равно как и повествовательная часть, формируются в уме фоновым процессом в любое время вообще, эксперименты, тесты, прототипы — зависит от желания: в личное (ну не прикручивать же очередной сторадж к реакту), в рабочее попутное или специально выделенное. Всё зависит от вовлечённости и желания реально достичь результата.


            А слайды — скорее выжимка тезисов, изредка графики или скриншоты. Это несложно. Это же презентация технаря, а не маркетологов, тут смысл важен.

            • 0

              Презентовать-то бизнесу надо, а не технарям.

              • 0
                Исходя из этого: минимум технических подробностей, максимум логических цепочек действие — затраты на него — выгода бизнесу от результата.
        • 0
          Это хорошо, когда проблема в %название_модуля%, или двух модулей, или трёх… Но я-то вижу, что всё – говно. А начальство этого упорно не желает видеть (про коллег вообще молчу). А если я его и переубежу, то всё равно нет ни времени, ни достаточно квалифицированных программистов, чтобы это исправить, или хотя бы не допускать впредь. А я один за всех это разгребать не собираюсь, прошёл юношеский максимализм. Так вот говном и обрастаем.
        • 0
          Пробовали, конечно. Пишешь такое письмо с кросспостом десятку адресатов (включая руководство) и получаешь ровно 0 (ноль) ответов, потому что длинные письма никто никогда не читает до конца, особенно, адресованные группе людей. И угадайте, кто будет виноват, когда при разборе полётов оно всё-таки всплывёт?
      • +4
        Подтверждаю.

        За 15+ лет сформировалось по этому поводу не сколько утверждений, вот пара из них:
        — больше чем указывающего на недостатки (даже с приведенными решениями) люди ненавидят того, кто оказывается в этих случаях прав.
        — осуществлять критику и предлагать решения имеет смысл только в том случае, если изменения осуществимы.
        • 0

          Это называется "подтверждаю"? Вы понимаете, что вы только что намекнули человеку что все его предложения могли быть неосуществимы? :)

          • –1
            Простите, но вы о чем? Что значит «намекнул», когда он сам об этом пишет? Более того, второй пункт из моего комментария указывает на необходимое условие для прохождения предложений.
        • 0
          задача, которая выглядит простой с точки зрения бизнеса, запросто может быть внутренне сложной и не осуществимой за выделенное ей время.

          и только наличие определённого опыта позволяет определять такие задачи заранее и поднимать панику, пока оно ещё не пошло в работу.
        • 0

          Указывать недостатки надо уметь. Можно ныть и поносить всё и вся, безрезультатно. А можно предлагать возможные решения и обсуждать их, совместно доводя до идеала. Важность социальных навыков программистами бывает сильно недооценена.

      • 0
        40 лет, в IT c 16. Я в таких случаях сразу готовлю план «Б», что бы в критический момент можно было предложить альтернативу.
      • +2
        Я код пишу с 91 года, плохо продуманных решений не боюсь — ну либо исправим, либо и так сойдёт. Совсем гавно не выпустим, ибо QA, процессы, люди хорошие, опыт и всё такое.

        Хорошо думать надо о критикал пасе, о фаллбэках и о риск митигейшен. А как конкретно какой код писать — да в целом срать, код дело такое, сегодня написал, завтра переписал, послезавтра вообще выкинул. Учитывая то, что любой софт в принципе гавно и всегда не работает, думать надо о том, как с этим жить, а не как этого избежать.
        • 0
          Сбежал несколько лет назад из такой фирмы, где говнокод считался нормой. Копипаста, перекрестные зависимости, неожиданные глобальные переменные, имена методов, прямо противоположные их функциональности, методы по 10 тыс строк и ни одного теста, просто никакого, ни юнит, ни неюнит, никакого — это норма. Проект был в таком запущенном состоянии, что проще его было переписать с нуля, чем починить. Меняешь в одном месте — разваливается в совершенно других непредсказуемых местах. На 20 глюкописов у них был один мальчик, который всё это самоотверженно вычищал в одиночку и… ненавидел этих субъектов-генераторов дерьмокода, поскольку не мог бороться с ними. А они ненавидели его. Мне была уготована роль второго такого мальчика… но это было выше моих сил… работать было почти невозможно… хотя я продержался там 2 года. Но я же не ассенизатор и не детектив, чтобы раскапывать коммит 1993 года, из-за которого в 1998 году появился баг, который неудачно исправили в 2000 году и он перестал проявляться до 2005 года, когда внесли другое изменение, после которого он стал проявляться, но не совсем так, как сейчас, потому что именно в это время криво реализовали другую функциональность, а вот теперь ее прямо реализовали и он стал проявляться нормально. Тьфу!!!
          • 0
            Я говорил немножко о другом, но могу прокомментировать и ваш случай.

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

            И вот только тогда, когда доказано, что дело в копипасте и юнит-тестах — вот тогда надо за них бороться.

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

            Отдельно отмечу, что не понимаю, почему девелоперы не любят раскапывать баги, это же интересно.
            • 0

              Кому интересно, кому нет. Да и баг багу рознь, начиная с баг-репорта: "у меня система не работает" против "если я использую вот такое сочетание полей A и B в форме документа от юзера в группе "менеджеры", то документ идёт по маршруту 1, а согласно п. 7.3.4 описания системы должен идти по маршруту 3."

    • 0
      И какие планы строите на будущее?
    • 0
      Поэтому возникает грусть и некий налёт скуки.

      Т.е. первый комментатор прав:
      «прогрессирующее занудство, исчезающая самоирония и старческая слезливость»
      • +1
        Вообще то наоборот — отточенное годами чувство юмора и отсутствие юношеского максимализма в оценке задач делает, лично меня, одним из самых позитивных людей, что никак не противоречит иногда возникающему чувству грусти, при общении с молодыми коллегами, не умеющими даже хорошо выражать свои мысли и налёту скуки, когда я всё же вынужден внимательно выслушать их оценку ситуации.
    • 0
      Меняйте работу. Серьезно. Если в комнате вы оказались самым умным, то вам срочно надо найти другую, где люди будут умнее вас. Потому что только там смогут по достоинству оценить ваши фундаментальные знания и опыт, а вам будет, куда развиваться. И не бойтесь диалога, который автор статьи привел в самом начале. Трудовая деятельность — это взаимовыгодное сотрудничество, а не продажа себя в рабство. В данном случае не человек не подошел компании, а компания — человеку. Не та комната.
    • 0
      Пришло время передевать опыт более юным коллегам =)
    • 0

      И ещё раздражение со стороны менеджмента, он же приносит "новую прорывную идею, изобретённую долгими вечерами" а вы ему сообщает что это уже было и кончилось "ни чем"

    • 0
      Ну то есть вам грустно от того, что вы стали тем, кем хотели — профи?))
  • 0
    Из моего опыта, компании требуется один специалист с высокой зарплатой на пять-десять простых программистов с зарплатой в два — три раза ниже. У молодых знаний меньше, запросы ниже, как результат, легче устроиться. Так что молодых в компании всегда будет больше.
  • 0
    В наше время невозможно знать всё, лучше выбрать специализацию, которая нравится и дрючить её до экспертного уровня. Если данная специализации будет на пересечении нескольких тематических сфер, то работа всегда найдется.
  • +24
    * yar229 застрелился, просматривая список после фразы «Итак, что же нужно знать, чтобы тебя не выбросили на помойку?»
  • 0

    40-летние программисты, как мне кажется, никуда не деваются, они просто растворяются в толпе прибывающей бешеными темпами молодёжи

    • 0
      По своему опыту знаю, 40-летние программисты бывают очень разные. У некоторых падает скорость и эффективность. А некоторые работают еще быстрее и лучше. Все зависит от конкретного человека, главное не терять способность к обучению, изучая новые приемы и методы, тем самым держать себя в тонусе.
      • +1
        Собеседую разных, как тут уже писАл — «звёзды» после 40, которые после института осели на одном объекте/проекте, зачастую в единственном экземпляре, являются заядлыми велосипедостроителями и не готовы развиваться, если кто пробовал разные направления — тот и после 40 готов учиться и развиваться. Хотя, моя выборка сужена фильтром HR по потолку з/п и требованиям — потому точные пропорции не видны.
      • 0

        Да я и 25-30 летних динозавров уже успел повидать: что изучили в 20 лет, тем дальше и пользуются без расширения кругозора.

  • +21
    У вас обычная прокрастинация, товарищ. Даже зная все на 100% из этого списка, всегда можно составить еще один такой список, чего вы не знаете, перед тем как идти на собеседование. Будьте откровенны с собой, вы либо не хотите работать в яндексе, либо очень хотите но ужасно боитесь что вам скажут «мы вам позже позвоним».
    И вообще, я не понимаю вашего пиетета по отношению к яндексу. Контора как контора, не лучше и не хуже других.
    • +10

      Раньше мечтал туда попасть, но как то тихо и незаметно она стала обычной компанией.

      • +4

        Чем выше уровень развития, тем сложнее расти дальше.
        После 17 лет развития поисковой системы, как-то ее улучшить уже достаточно сложно.
        Если в самом начале гениальная идея могла прийти во время обеда, то теперь что бы выжать еще 0.5% скорости/качества/стоимости, нужно с десяток академиков привлечь…
        Такова судьба любой технологии.
        Если интересно менять мир, нужно искать новые перспективные технологии.
        В данный момент VR в тренде.
        А через десятилетие и туда придет стогнация

        • 0

          Я для себя мир блокчейна открыл, это как раз и стало поворотным моментом.

  • +8
    О Яндекс! Грааль мечты! Только у тебя люди не просто перекладывают данные, а делают с ними что-то осмысленное.

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

    • +1
      Это ирония, конечно. Хотел поразвлечь благородную публику. Но проблема есть — потолок в профессии, кажется, достигнут, вот я и думаю, это тупик или нет и что делать дальше. А в Яндексе хотя бы какая-то движуха происходит. Хотя может я и заблуждаюсь и нигде нет счастья.
      • –1
        дался вам этот Яндекс с их методами мотивации
      • 0
        может быть, счастье в том, чтобы продолжать делать то, что хорошо умеешь?

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

        Меняйте профессию. Кроме программизма, в мире есть ещё много интересных инженерных дисциплин. :)


        Или, как вариант, откройте стартап. Скучать не придётся. :)

  • +2
    Сделал себе небольшой «грааль», забил на собеседования и занимаюсь в своё удовольствие. За 30 лет сделать свою кормушку не проблема.
    • +1
      Сдается мне, что многие программисты от 40 как раз в свои «граали» и пропадают, а не в яндекс)
  • +6
    Это очень интересная и актуальная тема для меня:
    С одной стороны сам видел, как провожали на пенсию одного из разработчиков (65 лет). Т.е. писать программы можно и в этом возрасте.
    С другой стороны по себе замечаю, что в свои 30 я уже не так эффективен, каким был в 25. Т.е. с точки зрения производительности я пока ещё дам фору 25и-летним, а вот с обучением всё уже намного хуже. Например я уже не готов жертвовать сном, чтобы написать какой-то тестовый проект и попробовать новую технологию; семья и дом отнимают бОльшую часть времени вне работы; технологии развиваются очень быстро и даже с моими попытками не отстать, всё равно отстаю. Вон уже Angular2 вышел, а я с Angular 1 ещё дальше простых примеров не продвинулся.
    И если в 30 лет всё можно списать на проскатинацию (и начать бороться с ней — притом довольно эффективно), то страшно подумать что будет в 45-50.
    Также правда была сказана про «стеклянный потолок». Компаниям не нужны программисты с 15-20 годами опыта, им достаточно 3-5 лет. Т.е. у разработчика с 3-5 годами опыта есть достаточно знаний (притом актуальных), умеренные апетиты в зарплате и лёгкая обучаемость по причине молодости), а то что вы писали 10 лет назад на VB6 или Delphi уже никого не интересует.
    Куда же деются 40-летние программисты: мне кажется есть несколько вариантов:
    — расти и учиться постоянно и со всё большим усердием, и быть умеренным в зарплате (и оставаться обычным разработчиком)
    — уйти в менеджеры или техлиды (но это путь не для всех)
    — развивать экспертизу и стремиться и стать уникальным специалистом (но есть шанс, что экспертиза или технология устареет морально)
    — учить архитектуру и идти в направлении системного архитектора (их требуется очень мало + обычно растят внутри компании).

    Так что разработчики — это как спорт или балет, пока молодой всё красиво и есть шанс заработать, но с возрастом — либо тренером, либо спиться :(

    ЗЫ: На самом деле не всё так грустно. Спрос на разработчиков пока ещё огромный, а квалифицированных людей всегда нехватает. Если ваш уровень хотя бы чуть выше среднего, то без работы вы не останетесь…
    • –2
      Спрос на разработчиков пока ещё огромный, а квалифицированных людей всегда нехватает. Если ваш уровень хотя бы чуть выше среднего, то без работы вы не останетесь…

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

      Вообще работать 20 лет программистом это скорее исключение из правил, многим уже через 5-10 лет становится понятно, что надо уходить во что-то другое.
      • +7
        С чего бы исключение? Я уж скоро 13 лет как работаю и наслаждаюсь профессией. И интерес не только не пропадает, а постоянно не хватает времени на то, что бы изучить новые интересные штуки.
        Не хватает тех, кто способен думать головой, исследовать, брать ответственность, принимать решения, развиваться и тащить банду обормотов, что бы они не отстрелили себе все подряд :) И биологический возраст тут не важен.
    • +2
      > Например я уже не готов жертвовать сном, чтобы написать какой-то тестовый проект и попробовать новую технологию
      А это скорее не из-за возраста, а из-за опыта. Мой личный опыт показывает, что многие «новейшие» технологии на самом деле сырые и полные костылей и часто находятся на уровне proof-of-concept. Короче смысл перебирать все что модно-молодежно прямо сейчас как-то теряется, потому как время убивает, а серебряной пулей в итоге не становится. Начинаешь понимать медленный энтерпрайз с выверенным стеком устаревших технологий, но работающий. В одной из контор где я работал до сих пор используют программы на фортране, написанные в 90х, а может и раньше.
      • +1

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

        • 0
          Вот когда станут, тогда и приходите :)
          Серьезно, некоторые технологии пока я хотел изучить, но не было времени, успели стать немодными и чуть ли не deprecated. Why bother then?
          • 0
            А с таким мышлением «новые технологии сырые, я старыми решу всё быстрее» мозг костенеет и можно оказаться программистом на Borland C++ Builder в 2017-ом. Причём на старте это всё действительно так и было, технологии сырые, без них быстрее, а потом переходный момент упускается. Ну или даже старыми технологиями всё ещё решается быстрее (с 10 годами опыта-то), но вокруг их никто уже не использует.

            А раз уж топик про старость, тут тоже есть подвох. С годами мозг всё меньше и меньше формирует новых нейронных связей, всё больше следует ранее проторенным дорожкам. И так как признать свою неполноценность человек неспособен, мозг начинает вырабатывать подобные реакции на абсолютно несознательном уровне, типа «как я раньше делал — единственный правильный путь, все остальные просто глупые и этого не понимают». Если пообщаться со стариками (60-80 лет), слышишь это постоянно, тут и там.

            Поэтому критично постоянно изучать что-то новое, развиваться. Даже если это новое кажется не нужно и глупо. Даже если это приходится делать вместо сна и семьи (ну, баланс надо искать). Это единственное что спасает мозг от старения.
            • 0
              Вы не поняли мой посыл. Я не запрещаю использовать новые технологии, следить за ними. Я говорю о другом, не стоит сразу хвататься за все новое только потому что оно новое. Технология должна пройти хотя бы какую-то проверку временем, собрать комьюнити, получить LTS версии и т.д. С текущим темпом это происходит не за 25 лет. Не особо хочется быть первым граблепроходцем в продакшене.

              Т.е. хвататься за каждый «о, чуваки новую крутую штуку придумали, версия аж 0.2.137, надо срочно пробовать» не стоит, только распыляешь свое время.
              • 0
                Мне кажется вы не совсем правы. Проверка временем это хорошо, но, имеет смысл хотя знакомиться с новыми технологиями. Если за плечами многие годы разработки, то вполне можно прикинуть возможную пользу от новой технологии и шансы на ее развитие. Да, ошибиться здесь не сложно, но так гораздо проще не проморгать переходный период у чего-либо действительно крутого.
                То есть изучать все подряд что появляется действительно не очень разумно, но хотя бы знать что это — стоит.
                • 0
                  Ну ок, я прочитал статью про новую ништяковую штуку версии 0.1.12, полистал доку с примерами. Я все понял, приходите когда дойдете до чего-то серьезного.

                  Я это не просто так говорю, мне уже довелось попрыгать по граблям «новейших» технологий прямо в продакшене. Так что теперь я стараюсь выбирать только устоявшиеся решения с какой-никакой базой.
            • 0
              Даже если это новое кажется не нужно и глупо

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

        А ещё иногда бывает открыл новость о чём-то "новом", и в голове всплывает — "я же это уже видел n лет назад" :)

        • 0

          И не иногда, а очень часто. И чем больше опыта, тем чаще. :(


          Вот, скажем, до меня только недавно дошло, что Модная Технология MapReduce, с которой так носятся возбуждённые пионеры, это тупо вариации на тему grep/map блоков, которыми я пользовался в перле в конце 90-х. И которые изобрели ещё чёрти когда вообще, задолго до того, как я до них добрался.


          Хы-хы, сказали суровые сибирские мужики и пошли пить пиво.

          • 0

            Маркетинг-с!

            • 0
              Маркетингом это стало, которая это стали продвигать как решение всех задач на свете. А так — это просто технология. Полезная и концептуально простая.
          • 0
            Вот, скажем, до меня только недавно дошло, что Модная Технология MapReduce, с которой так носятся возбуждённые пионеры, это тупо вариации на тему grep/map блоков, которыми я пользовался в перле в конце 90-х.
            Дык. Решаемые задачи похожи, похожи и решения.

            MapReduce — это такой способ разбить задачу на три части: две (Map и Reduce) — известные «бизнес-аналитикам» и не требующие от них умения программировать кластеры и связывающая их распределённая сотировка, над которой «ломают голову лучшие умы» — но которая вообще никак не зависит от того, какая задача решается.

            grep/map блок — это в точности то же самое, только сортировка там выделена отдельно, не чтобы использовать 100'000 компьютеров в кластере, а мощь языка C, который гораздо быстрее perl'а.
            • 0
              Дык. Решаемые задачи похожи, похожи и решения.

              Всё уже украдено до нас. Иногда от этого даже грустно становится. :(


              grep/map блок — это в точности то же самое, только сортировка там выделена отдельно, не чтобы использовать 100'000 компьютеров в кластере, а мощь языка C, который гораздо быстрее perl'а.

              <зануда="вкл">
              В блоке grep { ... } map { ... } сортировка не выделена отдельно, её там вообще нет. Потому что для этого добавляется блок sort { ... }. :) А всё вместе называется Schwartzian transform.


              Что касается мощи языка C, который гораздо быстрее Perl, то это тоже не на 100% верно. Во многих задачах перловый код существенно быстрее чисто сишного.
              </зануда>


              :)

              • +2

                Примеры перолового кода, который быстрее сишного?

                • –1

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


                  Сравнения можете сами погуглить, если интересно. Во времена оно была популярная тема вполне.

                  • 0
                    Быстрее либа, а не сам язык, правильно? А перловый движок регекспов разве на Перле написан?
                    • –1

                      В перле регулярные выражения встроены в синтаксис языка, это не отдельная библиотека, как в PHP или Java. Движок regex написан на C, с блекджеком и макросами. Я конкретно в ту часть не смотрел, но судя по другим кускам кода, без бутылки там не разберёшься и с бодуна такое не напишешь.


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


                      C вообще не лучший выбор для работы со строками, а тем более с большими объёмами строк. Никаких чудес, просто malloc/free, обнуления, копирования, защита от переполнений и ручная работа с UTF-8 будет стоить вам циклов CPU и седых волос задолго до того, как вы вообще доберётесь до регулярных выражений.


                      А perl для этих задач оптимизировали два десятка лет, пусть даже ценой читабельности кода. Смотреть в него не обязательно, можно просто пользоваться.

                      • 0
                        C вообще не лучший выбор для работы со строками, а тем более с большими объёмами строк
                        Вы, случаем, не из параллельной вселенной, где движки Google и Yandex на Perl'е написаны, нет?

                        Можно спорить по поводу удобства работы на строками на C (хотя чего там спорить — неудобно), но по-поводу скорости… Вы на цифры-то смотрели? Ну так взгляните: RE2 быстрее perl'а обычно, C'шный grep быстрее на порядок (хотя это и достигнуто за счёт использования более ограниченных регулярных выражений).

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

                        Никаких чудес, просто malloc/free, обнуления, копирования, защита от переполнений и ручная работа с UTF-8 будет стоить вам циклов CPU и седых волос задолго до того, как вы вообще доберётесь до регулярных выражений.
                        Опять-таки — это вопросы удобства, а не скорости. Ну так с дуру можно и х@й сломать. А вы, как бы, обещали большую скорость. Ну и где она? Примеры можно, а не абстрактные «махания руками»?
                      • +1
                        В перле регулярные выражения встроены в синтаксис языка, это не отдельная библиотека, как в PHP или Java

                        Да, я знаю. Тот же движок, на самом деле, используется и в php и, вроде, в JS. И его в Си можно использовать, наверное. Просто я не совсем понял, как можно сравнивать движок написаный на Си и просто Си и при чем тут Перл? Ну да, в перле клевый движок используется, но он ведь на Си написан, как этот движок может свидетельствовать о скорости Перла?
                        • 0
                          Тот же движок, на самом деле, используется и в php и, вроде, в JS
                          Вы, наверное, про PCRE? Ну так он только в PHP и используется, у Perl'а и JS — свои движки.
          • 0

            А задолго до перла это было в виде понятий моноида и катаморфизма.

    • +5
      Еще варианты, куда деваться:
      — учить pet-проекты генерировать доход.
      — работать удаленно. В интернете никто не знает что ты кот 40-летний программист.
      — отправить работать жену.
    • 0
      Т.е. с точки зрения производительности я пока ещё дам фору 25и-летним, а вот с обучением всё уже намного хуже. Например я уже не готов жертвовать сном, чтобы написать какой-то тестовый проект и попробовать новую технологию; семья и дом отнимают бОльшую часть времени вне работы; технологии развиваются очень быстро и даже с моими попытками не отстать, всё равно отстаю.


      Я случайно для себя нашёл ответ на этот вопрос :) Когда внезапно стал тимлидом. И в должности тимлида стал доступен лайфхак — даёшь задание молодым: «вот тебе мануал по продукту/технологии/протоколу, разберись и через недельну доложи коротенько, стоит с этим возиться или нет». Как минимум — уменьшает время на перебор разных продуктов (подойдёт или не подойдёт, т. к. чтобы это понять — надо посидеть и поразбираться. И когда «не подойдёт», то жалко потраченного времени).

      А так все в профите — молодёжь прокачивается, тимлид не тратит своё драгоценное время на фильтрацию технологий, и может сразу начинать разбираться с тем, что реально будет использоваться. Причём не с нуля — молодой-то уже ознакомился с продуктом, и обладает информацией о плюсах и минусах, где брать толковые методички, примеры использования показать и т. п.
      • 0

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

        • 0
          Ну, во-первых, задание на изучение даю я, и если есть ключевые моменты, на которые стоит обратить особое внимание, то я это оговариваю отдельно. Т. е. молодёжь тут не выбирает. Максимум — предлагает варианты на рассмотрение.

          А во-вторых — да, указанный вами риск есть. Но от ошибок не застрахован никто, даже ракеты вон падают из-за программерских ошибок.

          Тут вступает в дело уже вопрос управления рисками. Если цена ошибки велика — стоит дать задачу на изучение одной и той же технологии двум или более людям независимо, и затем сверить их показания.
  • 0
    Профессиональное выгорание, вообще приводит к падению мотивации в депрессию и полному отсутствию концентрации. Читать книжки при таком раскладе весьма сомнительное развлечение. К моменту когда начинаешь читать второй абзац с трудом можешь вспомнить о чем был первый. И уж то, чем меньше всего хочется заниматься, отторжение буквально на физиологическом уровне, тем на чем выгорел. То что у вас было судя по всему с трудом можно назвать скукой, и к выгоранию отношения никакого не имело.
    • 0
      Книжки совсем недавно начал читать и узнал много нового. А раньше фигачил так, без книжек, кустарно, и на протяжении многих лет. Отторжения нет к коду, написанному хорошо. Но представляю гипотетически, что буду искать новую работу, а там окажется какой-нибудь очередной дерьмопроект, который легче выбросить и написать новый, чем починить. Чинить дерьмопроекты, написанные не по SOLID, вызывает депрессию. Тьфу-тьфу, к текущему работодателю это (пока) не относится, там все относительно хорошо с этим. Успеваешь зачинить предыдущее, пока нагадят новое.
      А куда, в какую область помимо программирования, еще можно податься, не представляю. Вообще нет идей.
      • +1
        Ну как куда податься — программирование микроконтроллеров, ЧПУ, всякий там софт для IoT развивать. Во многих случаях просто откроются новые неосвоенные земли, где потребуются все возможные знания из индустрии.
        • 0
          Программирование микроконтроллеров мне не кажется прогрессом по сравнению с тем, чем я сейчас занимаюсь. Может, не в тему, но приведу пример.
          Как-то друг дал девайс чинить. Знаете такие девайсы Lacie (мини-комп с RAID-массивом). Так вот, друг поставил в устаревший Lacie диски больше 3Гб и девайс не забутился, потому что boot был старый и не поддерживал большие диски. Я нашел апдейт и перепрошил, но речь не об этом. Я посмотрел исходники этого boot image, чтобы проверить патч, который эту проблему лечит. Весь имадж 256 кбайт. Но mama mia. Это ассемблер для ARM-процессора Motorola 68000. Что-то мне подсказывает, что я этим не хотел бы заниматься. Там страшный код. Если не сказать большего. Как туда после С++ перейти? Немыслимо.
  • +2
    Мне кажется, тут поднята проблема, которая в том или ином виде существует везде, и судьба программиста — ещё не худший вариант. А какой смысл платить, например, немолодому повару в столовой в два раза больше, чем выпускнику кулинарного техникума? А водителю?.. Если оставить в стороне вопросы квалификации, всегда найдутся молодые ребята, которые согласятся больше работать за меньшие деньги,

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

    — Работать там, где не уволят (крупная компания, государство и т.п.) Предвижу ухмылки, но тут всё зависит от конкретных мест и обстоятельств, всё может оказаться не так плохо.

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

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

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

    Если работодатель этого не понимает, ну и к чёрту его. Мой опыт общения с разными людьми за последние годы не слишком позитивен. Желающих работать много, но средний уровень невысок. Если большего и не требуется, тогда да, проблема, но стоит чуть-чуть повысить планку, и уже очень немногие сумеют её взять.
    • +1
      Частный случай первого варианта: уйти в банковский сектор. Там можно сидеть долго и получать даже несколько выше рынка.
      • +1
        Проблема в том, что сидеть на попе ровно не всем нравится, от клепания всяких отчётных формочек воротит.
      • 0
        В банковсвком секторе своя специфика. Зачастую вместо реального программирования приходится заниматься политикой, чтобы сюрпризом не оказалось на очередном performance-review что твои KPI-очки были начислены более комфортному и удобному для менеджмента товарищу.
  • +3
    Уверен был, что это будет связано с компьютерами, а чем конкретно – понятия не имел. Даже не был уверен, кем стану: программистом или сисадмином.

    Мне 37 и я всё ещё не программист. Да, я кое-как пишу программы, но всё ещё не зарабатываю этим себе на жизнь. Чёрт, я даже не знаю, смогу ли вообще. Что, если нет? Кто сказал, что я доживу хотя бы до 60?
    Не об этом я думал, когда в юности гадал, что со мной будет в будущем. А ведь это единственная сфера (как я считал ранее), в которой я могу спокойно ошибаться, а потом исправлять свои ошибки, и ничего плохого из-за моих ошибок не случится. Оказалось, многие мыслят быстрее, безошибочнее, чем я, мгновенно дают ответы, над которыми мне нужно думать неделями. В школе, среди будущих трактористов, я считал себя программистом, а вот уже в институте, среди программистов, я понял, что я тракторист.
    • 0
      На каждого человека найдется другой, который думает быстрее. Еще быстрее думает олимпиадник. Но главное — найти свою нишу. Вам явно есть куда расти, а самобичевание никому не помогает.
      • +1
        Определенное небольшое количество самобичевания все-таки помогает. Стоит всегда помнить что расти есть куда и ты не самый крутой на планете. Последнее конечно возможно, но это все-таки исключение, с такими людьми вообще все сложно.
        • 0

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

  • +2
    Лет с 30 уже можно начинать активно вести здоровый образ жизни, почитать Курцвейла «Transcend. Девять шагов на пути к вечной жизни», и его же книжку про сингулярность. Разница между 30 и 45 не столь драматическая, если не угробить свой организм в процессе, что при желании сделать весьма просто.
    Если вы сами не деградируете во всех смыслах к этому возрасту, то я думаю в любом случае это будет лучше, даже учитывая предвзятое отношение работодателей к тем, кому «за».
  • +3
    Мне 46. И не вижу ни одной из проблем указанных в статье. Собеседование в начале — но простите, непрофессиональность многих айчаров от возраста соискателя не зависит. Как раз много раз сталкивался с крайне положительным опытом работы в компаниях с молодым коллективом, там где есть дух ПРОРАММИРОВАНИЯ, знания и опыт всегда будут к месту. А проблемы с недостаточной квалификацией для ведущего российского разработчика — ну да, не все специализируются на тех задачах, которые нужны им. Кстати, мне очень интересно, а авторы React, Rust, Haskel, WPF смогли бы пройти их собеседование? Все же специалист по программированию не только и не столько специалист по мат алгоритмам.
    • 0
      Вспоминается история, как то ли Томпсон, то ли Керниган не смог пройти внутреннюю гугловскую аттестацию на знание языка Си.
  • +5
    Как-то проводил собеседование, и пришел мужчина 80 лет. Он с ребятами (такими же по возрасту как он) с подачи зарубежного организатора окучивали стоматологический рынок земли обетованной. Спрашиваю в чем причина, зачем хочет уйти, ответ был поразителен: Надоели старые зануды.
    И вот тогда, в свои 38 я понял, что и 80 не предел. Дотянуть бы, а там разберемся!

    Александр, 42 года
    • +1
      > и 80 не предел.

      Вы его взяли?
      • 0
        Я бы взял, но владелец фирмы не смог перешагнуть через барьер. Сложно когда в подчинении работает сотрудник годящийся тебе в отцы (деды), особенно для рожденных на Кавказе.
  • 0
    Многие «старшие» программисты либо работают где-то заграницей либо преподают в университетах.
    Но есть и такие которые дальше усердно работают на компании либо сами на себя.
  • –2
    Ясно куда. На Бали же.)
  • 0
    Автомат Калашникова — это чтобы застрелиться?
    • +6
      Ага, конечный автомат Калашникова.
      • +1
        Существует мнение, что этот автомат является огнестрельным костылём…

      • +1
        И множество на 30 терминальных состояний.
        • 0
          Вопрос на засыпку, боекомплект в АК это очередь или стек?
          • 0

            Сначала стек. В процессе работы элементы перекладываются в очередь.

            • –2
              А если разрядить его в очередь, то она превратится в стек.
          • 0
            Для этого достаточно вспомнить, что у АК «магазин», а у конечного автомата (pushdown automaton) — «магазинная память».
          • 0
            LIFO
            https://ru.wikipedia.org/wiki/LIFO
            Абстрактный механизм LIFO, применяемый в вычислениях, реализуется в реальных структурах данных в виде стека, название которого совершенно очевидно имеет отношение к «пачке бумаги», «стопке тарелок» и т. п. (англ. stack переводится как «штабель, кипа, стопка»).
  • 0
    Я сейчас же все дела откладываю, и, короче, немедленно сажусь за химию кремния. Я обязательно должен прочитать про химию кремния всё, что только сумею найти.

    А потом… потом я думаю посвящу себя квиркам браузеров. Хорошенько в них закопаюсь… Ох какие квирки, прям жду не дождусь
  • –14
    Чумуродная конечно профессия. Для обезьян. Не хочу тут никого обидеть, но иной раз видно, что у человека программист на лице написан. И для некоторых это диагноз и крышка до конца жизни, сколько б умных глупостей они не знали.
    • +2
      сам то понял, что написал?
  • 0
    Даже не был уверен, кем стану: программистом или сисадмином.


    И стали программистом. А меня интересует вопрос: «Куда деваются сисадмины после 40?»
    • 0
      Меня тоже очень интересует
      38+
    • 0
      Уходят в безопасники! )))
    • 0
      Напишите об этом, когда Вам будет 40+. Кроме шуток, из моих знакомых сисадминов многие со временем переквалифицировались в программистов.
  • +9
    — Но молодые специалисты это тоже знают. Почему мы должны платить вам на 15% больше?
    — Но у меня семья, дети, ипотека…

    Никогда не понимал подобных "причин" для обоснования повышенной по сравнению с другими зарплатой. Правда, обычно, такое характерно как раз для "молодых специалистов": "Я женился и хочу ипотеку — повысьте зарплату". Думал, к 40 годам ко всем приходит понимание, что твои проблемы никого не волнуют, ни за "выслугу лет", ни за "жену и детей" платить никто не будет, если это не явно заявленная политика фирмы. В основном платят за то, что ты можешь делать. Если к 40 годам не можешь сформулировать почему тебе надо хотя бы на 15% больше чем "студенту" платить, то, скорее всего, и не за что.

    • +6
      Это ироничный пример неверного поведения на собеседовании как интевьюруемого, так и интервьюирующегося. Оба стоят друг друга. Конечно, недопустимо ни приводить такую аргументацию, ни задавать вопросы по бумажке, не разбираясь в теме.
      </zanuda mode off>
      • +1

        Воспринял его как типичный, пускай и несколько гипертрофированный пример.

    • +4
      Никогда не понимал подобных «причин» для обоснования повышенной по сравнению с другими зарплатой

      Никогда не понимал причин, почему надо объяснять свою зарплату относительно других. «Я хочу» — это уже сама по себе достаточная причина хотеть такую зарплату. А платить или нет — это решать работодателю.

      понимание, что твои проблемы никого не волнуют

      а так же понимание, что и тебя проблемы компании не волнуют. Не хотят платить, сколько ты хочешь? Найдутся те, кто заплатит. Если, конечно, дела обстоят не так, что
      платить, то, скорее всего, и не за что
      • +1

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

        • 0

          Обоснование может быть только рыночным. Мне сейчас платят X, я сижу на булках ровно и чувствую себя хорошо. Если я вам нужен, давайте X + 15%. Не даёте? Будьте здоровы, не чихайте.


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

          • 0

            А если X и есть твоя реальная рыночная цена? Менять работу с рисками разного рода "не сложилось" из-за шанса, что получится развести текущее руководство на +15%? По-моему, за применение очень похожих скиллов есть уголовная ответственность.

            • +3
              Ну на самом деле «гоните бабло или я ухожу» это проиграшная стратегия.
              1. Нужно быть готовым уйти (иметь запасной аэродром или запас прочности на время поисков в крайнем случае)
              2. Даже если руководство прогнется, потмоу что вы ценный кадр и на вас многое держится, то отношение к вам в большинстве случаев сменится с «отличный надежный сотрудник» на «надо бы срочно подыскать кто сможет его заменить». И как только замена будет найдена, то вас уйдут или зделают так, что сами уйдете.
              3. Больше одного раза такое не прокатит, ибо после первого руководство будет готово к подобному повороту.

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

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

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

                Полностью согласен, особенно с пунктом 2, о котором многие вообще не думают почему-то.

              • 0
                Больше одного раза такое не прокатит, ибо после первого руководство будет готово к подобному повороту.
                Прокатывает и 3 и 5 и 10 раз. Только с одним отличием: нужно не пугать тем, что вы уйдёте, а сходить на пару собеседований и вернуться с реальным предложением от команды куда вы, в принципе, были бы готовы реально уйти.

                С некоторой вероятностью вам скажут «скатертью дорога» — и вы, со спокойной душой, уйдёте. Ну и отлично, задача решена.

                А если такой компании всё никак не находится — то значит вы и стоите столько стоите, сколько вам платят — и нефиг кого-то шантажировать и расстраивать.
              • 0
                Ну на самом деле «гоните бабло или я ухожу» это проиграшная стратегия.

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


                По поводу пунктов: у вас такой опыт есть или вы теоретически рассуждаете? У меня есть, и он работает. Но только в том случае, если реально готов уйти в другое место и на руках предложение оттуда с конкретными цифрами.


                Вы посмотрите на это со стороны вашего начальника: он, может, и не против поднять вам зарплату, но ему ведь тоже какое-то обоснование нужно. Наличие предложения от другой конторы на X + Y% это железобетонный повод пойти к своему начальству и сказать: вот, смотри какой ценный кадр. Даже уходить не хочет, просто денег хочет. Давай удержим.


                Я в такой ситуации был с обеих сторон и никаких проблем в этом не вижу. Главное, поменьше эмоций, только бизнес.

                • 0
                  По поводу пунктов: у вас такой опыт есть или вы теоретически рассуждаете? У меня есть, и он работает. Но только в том случае, если реально готов уйти в другое место и на руках предложение оттуда с конкретными цифрами.


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

                  2. Так как я не практикую подход «башляйте или свалю», то в таких ситуациях я не бывал. Но был свидетелм двух случаев. В первом парень получил повышение, а через полтора месяца его увоилили. Вот прямо сразу как заказчик принял проект. Во втором случае парню ну и уходи.

                  3. Ну тут мое имхо
                  • 0
                    Когда я готов уйти, я ухожу. Не вижу смысла требовать больше денег, если уже решил уйти.

                    Случаи разные бывают. Обычно когда решаешь уйти с работы, то для этого есть определённые причины: платят мало, не устраивает то и сё. А теперь представьте, что начальство предлагает и деньги поднять, и устранить то и сё. Будете срываться нипочему, или подумаете?


                    У меня были и такие ситуации, и не такие. Всё относительно.


                    Так как я не практикую подход «башляйте или свалю», то в таких ситуациях я не бывал.

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

                    • 0
                      Случаи разные бывают. Обычно когда решаешь уйти с работы, то для этого есть определённые причины: платят мало, не устраивает то и сё. А теперь представьте, что начальство предлагает и деньги поднять, и устранить то и сё. Будете срываться нипочему, или подумаете?


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

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


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

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

                      ззы. У нас в Украине основная масса программистов работает как ЧП, потому уволить кого-либо это как два пальца об асфальт. Возможно потому я предпочитаю не делать «башляйте или свалю». Даже если забашляют, то уволить могут прямо через неделю, если появится достойная замена.
              • 0
                Не раз пользовался этим приемом, и он реально работает. Просто вся ситуация выглядит по-другому.
                Во-первых, раз в полгода походить по собеседованиям всегда полезно для понимания трендов на рынке и того, где у вас пробелы в знаниях, а также чтобы не терять навык прохождения собеседований, так что у вас всегда есть (или вот-вот будут) на руках активные предложения.
                Дальше, получив предложение, приходим к руководителю и говорим:
                Сейчас я получаю X рублей, но мне дали оффер на 30% больше. Это меня расстраивает, я чувствую себя недооцененным в нашей компании, так что, если есть возможность, я бы хотел получить повышение зп, или бонус, или акции, или что угодно еще. Это не шантаж, если ответ будет «нет», я не уйду и приложу все усилия к тому, чтобы и дальше работать продуктивно, но, сам понимаешь, это все будет меня демотивировать.
                На моей практике никто ни разу не отказал и потом никаких козней не строил.
                Разумеется, это текст для случая, если уходить не хочешь. Если хочешь уходить — стоит сразу об этом сказать, но дать возможность обсудить варианты твоего удержания, просто из лояльности и уважения к текущему работодателю.
            • +4

              Мы с вами о разных рынках разговариваем? Рыночная цена === сколько платят или сколько готовы платить в другом месте. Если платят X, а хочется Y, то поди найди, где будут платить Y. Если найдётся и контракт на подписи, значит рыночная цена — Y. А если нет, то X. Чудес не бывает.


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


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

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

              • 0

                Я не про ситуацию, когда есть на руках конкретное предложение, а когда приходишь и говоришь "мне предложили +100%, давайте столько же или я уйду", прекрасно понимая что на рынке вряд ли получишь хотя бы +10%.

                • 0

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


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

          • +1
            Поэтому умение аккуратно обозначить себя как потенциальную добычу для корпоративных браконьеров я считаю одним из наиважнейших soft skills специалиста в любой ценной области.

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

            А вот по поводу рыночного обоснования, если это не аутстаф и аутсорс, то компаниям все-таки выгодно удерживать работников как можно дольше. И они вполне могут платить гораздо выше рыночных денег тем, кто будет за это бороться. Опять же, все в руках работника, soft skills и все остальное.
            • 0
              И они вполне могут платить гораздо выше рыночных денег тем, кто будет за это бороться.

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


              Если я приду к начальству и скажу: хочу +10% к зарплате, это не даст результата. Если я приду и скажу: у меня на руках job offer от другой конторы, они дают мне +15%, это даст результат. Потому что конкуренция за ресурс (мою голову). И результатом этой конкуренции является рыночная цена в +15%.


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


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

              • +2
                Никто никогда не будет платить выше рынка, в том-то и фикус
                Четкого рынка не существует в принципе, вот в чем фокус.
                Кого-то контора наняла когда ей остро нужен был сотрудник и переплатила 20%, теперь фиг понизишь. Кого-то контора наняла когда ему остро нужна была работа и недоплачивает 20% и будет недоплачивать, т.к. уйдет этот — придет другой, вакансия не критична. Кто-то согласился на 20% зарплату ниже потому что компания ближе к дому на 2 часа. Кому-то заплатили на 20% выше потому что мало кандидатур согласных ездить 2 часа к ним в офис в е-ня.
                Рынок — миф. Для средней квалификации разброс в 30% в зарплате норма. Чем выше квалификация — тем меньше вакансий и специалистов — тем больше разброс.
                • +1

                  Это и есть рынок, просто в нём не 2 измерения как в упрощённой модели а гораздо больше.

                • +1
                  Рынок — миф. Для средней квалификации разброс в 30% в зарплате норма. Чем выше квалификация — тем меньше вакансий и специалистов — тем больше разброс.

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

    • +1
      Никогда не понимал подобных «причин» для обоснования повышенной по сравнению с другими зарплатой.. Думал, к 40 годам ко всем приходит понимание, что твои проблемы никого не волнуют, ни за «выслугу лет», ни за «жену и детей» платить никто не будет, если это не явно заявленная политика фирмы. В основном платят за то, что ты можешь делать.
      Это потому что Вы со стороны руководителя на это не смотрели. Платят еще и за надежность.
      -хочу на 15% больше.
      -почему?
      -я не сменю работу, доведу проект до конца, буду стабилен
      -с чего бы?
      -у меня дети, ипотека, куда я денусь — надо пахать.
      В упомянутом Вами сценарии 3 и 4 фраза пропущены как самоочевидные обоим сторонам. Обременения и платежи подразумевают что человек не забьет на все и не слиняет за лишней пару рублей или обещания карьеры.
      Мы как-то фрилансера нанимали молодого, через месяц после работы над проектом пропал, появился через месяц с шикарной отмазой (цитируем по памяти) «ну лето, пиво, расслабился, решил отдохнуть, живу у мамы, кормит сестра, чего мне у тебя на проекте ж-пу рвать, другой найду»©
      • +1