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

Когда код пах железом
Первый раз я увидел PDP-11 не в музее, а на складе старого НИИ. Она стояла под слоем пыли, с выпавшими переключателями, но внутри — идеально чистые платы, где каждая дорожка нарисована как вручную. Тогда я впервые понял, что когда-то инженер знал каждый байт своей машины, буквально.
Когда я разбирал старые исходники, то ощущение было странным: будто читаешь личные записи. Всё было просто, почти интимно)) Ни фреймворков, ни ORM, ни абстракций. Только человек и процессор.
Например, в коде на ассемблере PDP-11, который я когда-то переписывал ради эксперимента, всё дышало прямотой:
; Ввод символа и вывод обратно
MOV $3, R0 ; номер устройства (консоль)
JSR PC, GETCHAR ; получить символ
MOVB R0, BUF ; сохранить
JSR PC, PUTCHAR ; вывести
HALT
Ни одной лишней строчки. Даже комментарии - короткие.
Когда работаешь с таким кодом, невозможно не уважать человека, который его писал. Он не прятался за слоями абстракций - он говорил с машиной на одном языке.
Когда комментарии были личными
Сейчас комментарии — редкость. А если они есть, то в духе // TODO: когда-нибудь переписать.
Но когда я впервые прочитал исходники на Fortran IV (нашёл их в архиве старой космической программы, если честно — случайно), то был поражён тем, насколько в них много… человечности.
C ВЫЧИСЛЕНИЕ ОРБИТАЛЬНОЙ СКОРОСТИ
V = DSQRT(G * M / R)
C ЕСЛИ ТЫ ЧИТАЕШЬ ЭТО — ПРОВЕРЬ, НЕ ЗАБЫЛ ЛИ Я ПРО КИЛОМЕТРЫ
IF (UNIT.EQ.'MILES') V = V * 1.60934
PRINT *, 'ORBITAL VELOCITY =', V
STOP
END
Эта строка ЕСЛИ ТЫ ЧИТАЕШЬ ЭТО… меня зацепила. Человек писал не ради ревью, не ради KPI, а ради того, кто когда-нибудь откроет этот код и продолжит работу. В этом был какой-то теплый профессиональный этикет — уважение к следующему инженеру.
Сейчас у нас для этого есть issue-трекеры, документации, CI-логика. Но всё это мёртвое. А там — живая связь между людьми через код.
Когда оптимизация была делом чести
Сейчас мы спокойно говорим: «да ладно, потом оптимизируем, ресурсы дешёвые».
Но я вырос на коде, где оптимизация была частью мировоззрения. Тогда без неё программа просто не запустилась бы.
Помню, как читал исходники на С конца 70-х — и удивлялся, насколько аккуратно всё устроено. Каждый байт, каждый такт, всё под контролем.
int sum_array(int *arr, int n) {
register int s = 0;
while (--n >= 0)
s += *arr++;
return s;
}
Сегодня register ничего не даёт. А тогда — это был сигнал компилятору: "я знаю, что делаю".
Разработчик не надеялся на оптимизатор. Он думал, где переменная лежит, как устроен стек, что делает процессор.
Не из гордости — из необходимости. Это была настоящая инженерия, не программирование «на удачу».
Иногда я думаю, что вместе с потерей ограничений мы потеряли часть уважения к своей работе.
Когда код был лицом инженера
У каждого программиста был свой почерк. Настоящий, узнаваемый.
Я видел проекты, где можно было определить автора по тому, как он выстраивает отступы, как ставит комментарии, как называет переменные.
Это было как графика: чистая, искренняя, без шаблонов.
В одном проекте на Pascal я нашёл перед каждой подпрограммой ASCII-рамку из символов *. Просто украшение, но с какой любовью!
Код был не просто функциональным. Он выражал личность.
А теперь — линтер, форматер, CI, eslint, prettier… всё привели к общему знаменателю.
Да, стало чище. Но когда смотришь на старые исходники, где каждая строка — отпечаток автора, начинаешь скучать по временам, когда код ещё пах человеком, а не регламентом.
Когда разработчик чувствовал свою программу
Я не из тех, кто говорит «раньше было лучше». Просто раньше разработчик знал, сколько его программа весит — буквально.
Он чувствовал время исполнения, знал, сколько байт уйдёт на стек, где находится граница памяти.
Сейчас я иногда спрашиваю молодых коллег: «Сколько тактов займёт эта операция?» — и получаю в ответ улыбку. Не потому что им всё равно, а потому что им это просто не нужно.
Но именно это знание делало инженеров прошлого ближе к железу.
Когда ты понимаешь, что каждая переменная имеет вес — физически — ты начинаешь писать иначе. Бережнее. Честнее.
И, возможно, именно поэтому их код был человечным: в нём было уважение к машине, к читателю и к себе.
Заключение
Я не ностальгирую по перфокартам и не предлагаю писать на Fortran вместо Python.
Но иногда стоит вспомнить, что код — это не только синтаксис. Это форма общения между людьми, разделёнными временем.
Хочется, чтобы через 30 лет кто-то, открыв наши исходники, почувствовал то же самое, что чувствовал я, читая эти старые программы:
что здесь писал человек, не инструмент.
Комментарии (52)

usiqwerty
23.10.2025 13:11Хочется, чтобы через 30 лет кто-то, открыв наши исходники, почувствовал то же самое, что чувствовал я, читая эти старые программы: что здесь писал человек, не инструмент.
Сколько там процентов AI кода в гугле?

Huchlers
23.10.2025 13:11Думал, что аналогия с пластмассой будет о том, что они ломаются под нагрузкой, а тут опять луддитские тейки про "душу".

Lizdroz
23.10.2025 13:11Ну, аналогия с пластмассой тут как раз к месту. Современный софт собирается из готовых "пластмассовых" компонентов (библиотек, фреймворков) - это быстро, дешево, масштабируемо. Но когда что-то ломается внутри такого компонента, починить это почти невозможно - ты просто меняешь "деталь" целиком. А раньше, когда все было "из железа", ты мог починить что угодно, потому что сам это сделал

Keeper22
23.10.2025 13:11Один из лучший примеров кода, с которым мне довелось поработать -- библиотека SQLite. Желающие могут причаститься.

T700
23.10.2025 13:11Посмотрел. И странно, нет пробелов операторов в if, for и т. д. Это плохо и странно для меня. I don't know, так делать.

cher-nov
23.10.2025 13:11Один из лучший примеров кода, с которым мне довелось поработать -- библиотека SQLite. Желающие могут причаститься.
У SQLite ещё и очень интересный этический кодекс: https://sqlite.org/codeofethics.html. Без него, боюсь, впечатление может оказаться несколько неполным. :)

PereslavlFoto
23.10.2025 13:11через 30 лет кто-то, открыв наши исходники
Это запрещено авторским правом.

ArtyomOchkin
23.10.2025 13:11Значит, через 70 лет :).
Если к тому времени исходники ещё будут лежать где-то в цифровых архивах

shurutov
23.10.2025 13:11Open source? Не, нет такого...

PereslavlFoto
23.10.2025 13:11Open source
Open source бывает не через тридцать лет, а сейчас. Поэтому здесь речь не про open source.

smart_pic
23.10.2025 13:11Когда код был лицом инженера
У каждого программиста был свой почерк. Настоящий, узнаваемый.
Я видел проекты, где можно было определить автора по тому, как он выстраивает отступы, как ставит комментарии, как называет переменные.Когда писал программы на ПЛ1 для ЕС1035 , то операторы по одному виду листинга программы определяли кто автор.
Я не ностальгирую по перфокартам
Но согласитесь в них что то есть. Когда сидишь и набираешь программу на перфокарты на перфораторе. а потом проверяешь правильность набора . перенабиваешь заново ошибочные строки , и только потом отдаешь колоду карт на исполнение.

saag
23.10.2025 13:11отдаешь колоду карт на исполнение
Какие там девушки-операторы были, с одной по имени Аэлита я работал:-)

Di-den
23.10.2025 13:11Закладки из перфокарт (отец был динозавром СУБД на ЕС ЭВМ) до сих пор встречаю в книгах, перекочевавших из его библиотеки... Сам застав понятия "машинное время" и "пакетное выполнение" вспоминаю, что тоже когда-то умел писать код на несколько сотен строк без копипастов, автоподстановок и синтаксического контроля без единой ошибки. И да, оставлял комментарии. Я не любитель рассматривать старые фотографии (у меня даже детские видео сына-уже-студента ещё лежат на MiniDV кассетах в коробке), но знаю, где лежит моя коробка с дискетами 5.25" Dyson (да пребудет с ними сила).Пожалуй пойду в выходные присмотрю на барахолке антикварный Пентиум с флоппи-дисководом.

Hrodvitnir
23.10.2025 13:11Обожаю я вот это мужицкое "серьезно фоткаюсь с семьей" и "я самый счастливый мужик в мире, я поймал карася"
Ваш комментарий мне прям вот это напомнил

MkIV007
23.10.2025 13:11Ну не знаю, цепляться за прошлое - нафиг нужно то? Были и у меня дискеты 5.25 и даже одна 8 дюймовая. Продал на ибее, как и все старье. А древние глюкавые машины (ЕС, СМ и прочая) без дрожи вспоминать не хочу.

Yak52
23.10.2025 13:11Я как то раз свой недельный труд в виде почти полтыщи перфокарт понес из перфораторской на машину. По пути споткнулся и вся стопка рассыпалась по полу коридора. Поскольку я их не пронумеровал, да и перфоратор был самый простой, он только дырки пробивал, а не печатал на перфокарте дополнительно текст, то еще день потратил на приведение всей колоды в правильный порядок. Даже с распечаткой.

Frogy_F
23.10.2025 13:11Вот если бы в наса, космическую программу по полёту на луну, сохранили бы на перфокартах, она бы не потерялась. А то эти ваши новомодные дискеты, ищи их теперь.

Hemml
23.10.2025 13:11хахаха, так они были не на дискетах и даже, существенная часть, не на перфокартах, а в виде таких здоровенных косиц проводов с вплетенными в них ферритовыми кольцами:


kneaded
23.10.2025 13:11Я сам и раньше и сейчас пытаюсь поддерживать человечность. Помню как кто-то открыл мой код, а там "если не пришла жёлтая курица - то ничего страшного" и всё было понятно. Логика такая, что можно не бояться, что какие-то данные не пришли. Оно дальше как надо отработает. Но было весело это спустя время услышать что вот, мой код прочитали и эта строчка их зацепила

VADemon
23.10.2025 13:11«Сколько тактов займёт эта операция?» — и получаю в ответ улыбку.
А можно, нахмурившись, про спекулятивное исполнение вне очереди на конвеере пофантазировать, инженер точных наук мой. (:
Я думаю, раньше программирование было в меньшей мере поставлено на поток как сегодня. Т.е. провожу параллель вплоть до конвееризации и разделения труда. Ядро Линукс выхолощено до максимума. Старые комментарии делали "шаги в сторону", сейчас вряд ли факи в комментариях пропустят? (делаю предположение на основе их уменьшающегося числа в коде). А где есть лишнее время, там работается легче и человечней. Был code owner, не только как ревьювер, а вообще единоличный автор всей или части программы.
Для меня человечность ныне измеряется в удобстве пользования и документации. Комментарии по-прежнему пишу мало (т.е. современное мышление), но из-за подобных статей иногда задумываюсь. А выражаю человечность через stdout. Можно сухо "Invalid input". Но почему бы машине не "разговаривать" с пользователем? "Did you forget XY?". "I can't bind to the configured port, maybe because ..." и т.п.

GidraVydra
23.10.2025 13:11Я сейчас вспоминаю расчетные программы 80х, написанные на Коболе, Фортране и Паскале настоящими инженерами, и у меня волосы на жопе шевелятся. Такого зубодробительно нечитаемого и неосмыслимого кода большинство ныне живущих и не видело. Если говорить про "человечность", то этот код был больше похож на некроморфов из DS.
З.Ы. Погромисты, перестаньте называть себя инженерами.

PereslavlFoto
23.10.2025 13:11Там были непонятные имена переменных? И не было циклов?
Пожалуйста, подробности. Что такое нечитаемое было на фортране-то?

Hlad
23.10.2025 13:11PDP-11 это хорошо. Могу привести пример с MSP430, который вроде на неё похож. Было первое семейство MSP-шек. Там всё просто и понятно. Было второе - практически то же самое. И было пятое. В котором надо было напихать множество функционала так, чтобы сохранить совместимость с предыдущими семействами. Поэтому новый функционал был, как бы это сказать, вставлен перректально. Нет, там не костыли, просто по сравнению с первыми семействами всё было устроено заметно сложнее и неудобнее. А потом я полез в ARM-ы. Там тоже аналогичная ситуация: в Cortex-M0...M3 всё просто и понятно. А когда пытаешься на низком уровне разобраться, как работает USB на каком-нибудь Cortex A53, становится неудобно сидеть, потому что волосы на седалище начинают шевелиться.
Современный хард слишком сложен, чтобы под него можно было писать простой и понятный софт.

Aggle
23.10.2025 13:11Поддерживаю двумя руками. Касательно почерка (хотя и не про чисто программирование):
В своё время, при пусконаладке одного из наших объектов, по-быстрому сваял расчётную схему процесса в excel. Разрисована схема процесса, все операции, стрелочки, кружочки, таблички с параметрами, все дела. Вбиваешь нужные исходные данные - рассчитываются показатели процесса. Прошло 15 лет, многое поменялось (из показателей), и вот, в очередной раз решили что-то изменить. Присылают мне на почту файлик, - посмотри, мол, так сможем нормально работать? И я вижу, что файлик-то мой, тот самый (почерк в таких делах уже тогда был выработан - имена, обозначение операций, форматы стрелок, ячеек, цветовые схемы и т. п.). Звоню на производство кому-то из "старичков":
- Пацаны, это что, тот самый файл, который я вам тогда на пусконаладке рисовал?
- Ну да.
- Так это 15 лет назад было!
- А что, там всё красиво, удобно, понятно - мы постоянно пользуемся, нафига чего-то менять?
Честно скажу, было приятно от того, что когда-то сделал полезную для людей вещь, которой до сих пор пользуются и менять не хотят.Ну и на днях прислали для анализа производственной статистки сводку с предприятия, которым я очень давно не занимался. Открываю - очень знакомая. Смотрю, кто автор - а это я эту форму делал 11 лет назад.

Panzerschrek
23.10.2025 13:11Комментарии в каждой строчке были необходимостью, ибо без них чёрт ногу сломит. Писали ведь на ассемблере или чём-то другом, не очень высокоуровневом. Сейчас же абстракции современных языков программирования позволяют показывать намерения программиста средствами самого языка, так что комментарии редко нужны.

Hlad
23.10.2025 13:11Нет, по крайней мере, в низкоуровневой разработке. Средства языка позволяют показать, что мы делаем. И возможно, даже зачем мы делаем. Но не позволяют показать, почему мы делаем именно так.
Условно говоря: по коду можно понять, что "вот тут - пауза в 100 мсек". Если писали качественно, то можно даже понять, что "мы ждём инициализации узла XXX". Но нельзя понять, что "при включении устройства надо проводить инициализацию узлов A, B и C последовательно, хотя они друг с другом никак не связаны, либо выждать паузу. Потому что если мы их врубим сразу - то у нас при подсевшей батарейке просядет питание, и устройство может уйти в перезагрузку".

5Coins
23.10.2025 13:11С языка снял! Мы писали комментарии, превращая машинный код в алгоритм, описанный человеческим языком. Код легко читался, пока ты его помнишь и пока ты в нем варишься — я про ассемблер. «Прочитать» забытый код — это исполнить его в голове. Одна строчка когда сегодня — это (условно) могло занять несколько экранов на TASM. Без реперных точек в виде комментариев было просто невозможно работать. Ладно ещё написать, но поддерживать-тот иначе как!

sepulkary
23.10.2025 13:11Все эти милые кусочки программ на ассемблере хороши и ламповы, когда рассматриваешь их изолированно, с подробным комментарием и в ностальгическом контексте. А вот когда пытаешься пытаешься написать на ассемблере относительно сложную, контролируемую и сопровождаемую систему, то литературного слога очень скоро начинает не хватать...

user-book
23.10.2025 13:11за комментарии могу ответить
лично для себя всегда все комментирую "на лету" что бы потом когда вернусь было проще разбираться
но по работе пишу без коментариев, максимум формальные к методам. Очень часто сначала пишется и отлаживается кусок "для себя", а затем он вычесывается, сливается в один коммит и уже так пушится в работу
просто потому что командная работа. Это себе я могу написать "ебаный пиздец но оно работает, не лезть!" или "скопипащенно из решения http://..., вроде работает но надо погонять". Для публики или в команде это нормальная вежливость, как не присоединятся на видеосозвон в одних трусах. Вот только вычитка всех коментариев это время и силы, потому для економии я просто их удаляю. Для вещей которые еще не закончены, развожу по разным веткам для удобства.

iiwabor
23.10.2025 13:11Я однажды, в пятилетней давности коде, наткнулся на комментарий с дружеским приветствием и сочувствием от автора к тому, кто будет в его коде разбираться через года. Улыбнуло)

ALexKud
23.10.2025 13:11Система разработанная мною в в 2001 г. на SQL SERVER и DELPHI для одного дилера и содержащая CRM для менеджеров ,ЗАКАЗЫ,Снабжение,Отгрузки, Склад , хранилище документов в SQL Server и имеющая по тому времени много таких иновационных вещей как вычисляемые складские остатки , изменение приоритеов заказов с учетом скадских запасов и оплат и учетом частичных отгрузок , автоформирование спецификаций для комплектации заказов для снабжения , формирование счетов предложений и счетов на оплату, счетов фактур и накладных, импорт документов 1С бухгалтерию и т п. Система прожила 10 лет без особых проблем в связи с тем что логика все была в хранимых процедурах на сервере и клиент на DELPHI . Но к тому времени и контора стала хиреть и разваливаться, вернее стали разваливать, так как функцию дойной коровы она выполнила. Недавно посмотрел свой SQL код . В общем все неплохо выглядит, а прошло больше 20 лет.

event1
23.10.2025 13:11Сегодня register ничего не даёт. А тогда — это был сигнал компилятору: "я знаю, что делаю".
Разработчик не надеялся на оптимизатор. Он думал, где переменная лежит, как устроен стек, что делает процессор.
Не из гордости — из необходимости. Это была настоящая инженерия, не программирование «на удачу».Сегодня компилятор лучше вас знает, что надо делать. Требования выравнивания, иерархия кэшей, предсказание ветвления и тому подобное зашито в компилятор добрыми разработчиками процессора. Раньше не было ни таких навороченных процессоров, ни таких мощных компиляторов.
Я видел проекты, где можно было определить автора по тому, как он выстраивает отступы, как ставит комментарии, как называет переменные.
Спасибо, не надо. Пусть лучше весь проект будет в одном стиле, чем кто-то сможет определить автора
А там — живая связь между людьми через код.
О, да. Когда-то переписывал на сях код эквалайзера с DSP ассемблера с комментариями на немецком. Такая живая связь была, до сих пор побаливает.
А вот ещё другой случай: взяли на поддержку код на джаве от японской компании с комментами на японском. Почему-то японская компания не сумела в utf-8 и кодировка была какая-то японская. Коллега открыл код в редакторе, после чего ХР упала и подняться не смогла. Пришлось переустанавливать. В общем, ну её нафиг эту вашу живую связь.

Lizdroz
23.10.2025 13:11Все это очень мило, но автор упускает из виду масштаб. Код для PDP-11, который управляет одним устройством, и код современного веб-сервиса, который обслуживает миллионы пользователей - это задачи разного порядка сложности. Абстракции, фреймворки, линтеры - не от хорошей жизни, это инструменты, которые позволяют десяткам и сотням разработчиков не поубивать друг друга и хоть как-то поддерживать огромные кодовые базы. Человечность принесена в жертву масштабируемости

victor_1212
23.10.2025 13:11масштаб это конечно дорого, но он был так примерно с середины 50х, когда в одном проекте уже участвовали не одна сотня программистов, системы реального времени sage и др.

cdriper
23.10.2025 13:11да, да, давайте ностальгировать по тупым копиляторам Си, которым надо было указывать какую локальную переменную стоит в регистр засунуть
и вообще, давайте писать на одном ассемблеер ради совсем уж полной "человечности"

Zotann
23.10.2025 13:11Верх идиотизма писать комментарий к каждой строчке кода. Код должен быть понятен и читаем без комментариев (если это не касается супе сложной бизнесс логики) Т.е. мне как программисту нужно дважды читать одно и тоже : 1) сперва строку кода 2) потом строку комментария. Ведь и так понятно a = a + b что это сложение двух переменных. Зачем подобное комментировать?
Зачем разработчику знать про такты? Что они решают, когда современные процессоры,ОЗУ, диски имеют несколько уровней кэшей и в миллиард раз быстрее оптимизируют циклы, условия и от посчитанного количества тактов ничего не останется потому что cpu умеет предсказывать результат или поместит в кэш часть функций и будет их использовать.
Не нравится фреймворк - пиши в блокнотике. Да и вообще можно ручкой в тетраде писать код. Но насколько это эффективно?
Зачем в примерах используется сортировка? В любом современном языке все сортировки уже давным давно реализованы наилучшими способами - вызывай нужный метод и наслаждайся.
Сиди прокалывай дырочки в перфокартах и чувствуй себя инженером без инструментов мучающимся с сортировками массивах , а я буду наслаждаться автоматически генеративных кодом и творить мегаархиважные оптимизированные системы за считанные минуты.
Ну вот как часто кому-либо приходится оптимизировать сортировки? Есть sql, есть spark и другие инструменты где все это оптимизировано и реализовано. Зачем придумывать велосипед? Я не спорю что это нужно и важно , но менее чем в 5% случаев требуется самостоятельно реализовать собственный алгоритм поиска максимума, сортировки и т.п. Надо понимать что такое алгоритмическое программирование ,но если в твоей специализации или текущем месте работы оно не нужно то зачем его использовать?
Да, если разработка ПО ускорится в десятки раз от того что я куплю железяку на 128ГБ (256, 512) ОЗУ и забуду обо всех проблемах - то я ее куплю и буду наслаждаться и использовать везде Int32, а не мучаться с Int16 гонять байтики туда сюда , писать собственные оптимтзаторы и ради чего ? Чтобы сэкономить 2байта? Ну не смешите.
Автор предлагает деградировать и переместиться во время 640кб? Вернуться к дискетам?
Зачем столько раз повторять "душа" и "душевный"?

spbrus
23.10.2025 13:11Я сегодня резал овощи просто ножом. Обычным бездушным массовым продуктом. А ведь раньше были ножи с душой. Хороший нож месяцами затачивается и полировался, наносился декор вручную. Вот бы все ножи были такими, чтобы через 30 лет все резали овощи ножами в которые вложена душа мастера. Это краткий пересказ статьи в лёгкой интерпретации, если кто не понял )))
T700
Возможно раньше программировали по призванию, а сегодня на волне хайпа, программируют ради денег, плюс требования рынка, фреймворки и стандарты, в которых есть рамки фрейворков, оформление кода и комментариев. Творчество возможно, есть в пет проектах, и даже в них, код для себя и код для публикации, отличаются по оформлению.
Были ли люди раньше более человечны?
K0tm4n
Более чем. В литературе разных времён хорошо отражено как менялся человек и нормы морали. Да и в кино заметны изменения. Сравните финалы оригинальных фильмов "Ограбление по-итальянски" и "11 друзей Оушена" с финалами римейков. Думаю ещё найдутся такие пары.
zhuravlevanastia
Творчество это именно пет-проекты и не более, потому что в бизнесовых задачах тебе особо никто и не даст эксперименты свои в жизнь воплощать, по-крайней мере по той причине, что есть сроки и базовые потребности клиентов, которые достаточно шаблонные
T700
А это интересная грань понимания. С одной стороны, сотрудник этовинтик, ведь он пишет на готовом фреймворке, где стиль уже определён, где за него всё сделали. Работа где ему ставят задачи и контролируют его код. Работа где нет творчество, есть пустая работа.
Другая позиция, когда разработчик, сам строит архитектуру проекта, выбирает компоненты системы. Создаёт её сам, в том числе и дизайн и функционал админ панелей. Где он решает бизнес задачи. Это другая грань. Творческий подход имеет место быть.
Пет проект, в большинстве случаев, не про бизнес.
Lizdroz
Дело не столько в хайпе, сколько в специализации. Раньше программист был человек-оркестр, сейчас есть фронтендер, бэкендер, девопс, QA... Каждый работает в своем узком коридоре, по своим стандартам. Места для личного почерка просто не остается, потому что твой код должен быть понятен десятку других специалистов
Moog_Prodigy
Я могу привести свой пример, в 2011 году я писал свою систему учета домашних финансов на VB. Но она настолько прозрачно показала траты семьи, что и я и жена решили что ну его нафиг. Потому что у всех есть свои небольшие слабости) Но это ладно. Меня впечатляет - то как я это сделал тогда. Я писал на VB, с DB Acsess , и там все настолько вылизано что спустя время я не знаю что добавить. Я бы сказал, что это писал совсем другой чел, если бы у меня не остались бумажки про архитектуру этой штуки. И вот... Кем был я тогда в то время, когда это все разрисовал, закодил? Сам собой? А сейчас я кто? Смотрю на это как полный бездарь на произведение гения, и такое странное ощущение. Отупел? Вроде нет, даже много больше стал знать и уметь. Но такой код я уже хрен бы написал. Старею или просто сам себя лишний раз критикую?
T700
Я сохраняю свой код в бекап, и часто также думаю, что как круто все сделано, неужели это делал я. Этот эффект, когда с прошествием времени, ты забываешь весь тот контекст в котором создавал программу, и когда смотришь снова на прошлый код, у тебя появляется страх, из-за того что ты забыл контекст, код и как ты это делал. Тема сложная на, самом деле. Есть состояние потока, это когда ты работаешь без времени, полностью в процессе, когда мозг оперирует огромными объемами информации. Поток, это не, всё, откуда он, если ясно что мозг не может по физическим каналам, передавать такие обьемы информации в голове, есть дугой принцип передачи. Если смотреть ещё глубже, станет ясно, что мы обращаемя к информации, куда-то в другое место, и получаем ответы и видения процесса, образа своих шагов (далее вопрос, открыт, куда и как (есть эксперимент, с лягушками, в полностью закрытом металлическом резервуаре и немного открытом)).