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

Ярило

Летом 2016 я провел замечательною неделю на балконе в Новосибирске (а там можно это делать только летом, и то не всегда) в попытках вернуться к программированию. Результатом этой недели были наброски реализации языка программирования с временным названием YARILO. Yet Another Rebol Inspired Language, Obviously!

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

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

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

В те дни Ярило, мне захотелось эффективно использовать память, из чего следовал собственный GC, трансляция в эффективный байт-код и так далее. Несколько часов я оптимизировал цикл интерпретатора, добивался возможности компилятора Nim/C использовать tail calls, а потом переписывал этот цикл к хуям, аннигилируя часы работы, и так далее. В общем я программировал, но не работал. Что естественно для человека который соскучился по программированию.

Хорошие программисты

В общем я делал все то, что делают многие “хорошие” программисты. “Хороший” программист – это программист, который программирует ради программирования, и их немало. Еще они за это получают деньги. Если бы это был реальный проект, и у меня был типичный менеджер, а я был бы на хорошем, счету как программист, то у нас бы случился match in heaven. Я бы каждый день показывал ему какой у нас охуенный прогресс (как мы ускорилсь тут или там, как у нас появился байткод и так далее), и объяснял бы что свой язык - сложная тема, и все эти вещи жизненно необходимы, чтобы взлетело (что безусловно правда).

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

Полезные программисты

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

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

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

Отличные программисты

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

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

Говнокод

Когда я слышу от программиста слово “говнокод”, ну например на собесе в ответ на вопрос про его прошлые места работы – у меня сразу вколючается маячок: с этим человеком скорее всего что-то не так. Вероятнее всего передо мной “хороший программист”. Скорее всего я его не возьму на работу, а если и возьму, то мы скоро расстанемся. Мне не нужны “хорошие” программисты (с ними сложно добится полезного результата), мне так же неинтересны “полезные” программисты – с нимим невозможно достигать больших целей, да и не решить сложных задач.

Люди, часто употребляющие слово “говнокод”, обычно “хорошие” программисты, и могут найти этот “говнокод” везде, даже в очень мной уважаемых проектах, достойных восхищения. Один мне как-то показывал “говонокод” от Erich Gamma. Еб твою мать, дружище, я и сам такое могу найти везде. но как ты можешь знать об условиях в которых находились люди написавшие этот код? Ты же как “хороший”, но “бесполезный” программист не думаешь об обратной совместимости, о текущих пользователях этого кода, о задачах бизнеса, о сроках, о тех кто ждет этого “фикса”, о том насколько это важно и так далее. А применимо к данному коду ты об этом ничего не знаешь.

Я более чем уверен, что если бы тебя погрузили в ту ситуацию, и попросили найти оптимальное решение всех стоящих задач – ты бы не справился. В жизни часто бывает, что написать “хороший” код это не оптимальное, а часто губительное в долгосрочной перспективе решение для проекта. Да и не факт что твой код был бы лучше (хотя тут мы опять уходим в определение “хорошего”).

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

Назад, к записям