[work.thoughts] О понимании условий задач и полезности олимпиадного программирования

Вот какая мысль одолевает меня сегодня с самого утра…

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

Если кто-то хочет с этим поспорить – лучше напишите еще сотню-другую тысяч строк кода. Спорить не придется.

Но это банальность, про это все программисты очень быстро узнают. Что есть хорошо.

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

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

Имхо, программисты привыкли к наличию ошибок в своих программах, но не привыкли к тому, что их программы делают не то (или не совсем то), что нужно.

После такого длительного вбрасывания зайду с другой стороны…

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

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

• первая и самая большая – это люди, которые могут решать олимпиадные задачи в олимпиадных условиях и все. В пиковом режиме “расколоть” очередную задачку на перебор и поиск чего-нибудь, быстро и абы-как все это закодировать и пройти максимум тестов – это пожалуйста. Но если скрупулезно изучать чужую спецификацию и педантично воплощать ее в жизнь в течении нескольких месяцев (а то и лет) –  здесь они пасуют;
• вторая, редкая и малочисленная – это программисты от Бога, которым все равно, решают ли они олимпиадную задачу, реализуют ли они TCP/IP стек для встраиваемой операционной системы или делают Web-2.0 морду для очередного интернет-магазина. Столкнуться с таким человеком – это большая удача, практически, как найти килограммовый золотой самородок. Лично я за 20 лет занятия программированием встречался только с двумя такими людьми (один из них работает у нас).

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

А теперь возвращаемся к первоначальному вбрасыванию…

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

По крайней мере так было со мной. Именно на олимпиадах я постоянно бился фейсом об тэйбл узнавал, что сделал в своем решении слишком много собственных допущений. Например, в условии сказано: “даны координаты вершин выпуклого многоугольника на плоскости… корректность данных не гарантирована…” Ну и писал я код, который не рассчитывал на многоугольники с пересечениями граней – это же не выпуклый многоугольник думал я. Забывая о том, что фраза “корректность данных не гарантирована” означает, что мы не можем доверять входящим данным вообще.

Вот так, неожиданно для себя, я открыл хорошую сторону олимпиадного программирования. Т.е., если без фанатизма, то в школе/ВУЗе принять участие в 2-3 олимпиадах может быть и полезно.

PS. Кстати говоря, домыслы программистов об условиях задач – это очень серьезный бич. Например, есть задача – отослать в 01:00 на указанный e-mail сводку об активности за день, которая должна находиться на указанном сетевом ресурсе. Тупая реализация в лоб: берешь сводку, отсылаешь, забиваешь на все ошибки. Если же подойти обстоятельно, то нужно уточнить: а что делать, если сводка не готова к указанному времени? А что делать, если размер сводки по каким-то причинам оказался больше разумного объема (и есть ли вообще этот разумный объем)? А что делать, если связаться с STMP сервером не удалось? А что делать… В общем, в любой задаче есть достаточно вопросов, чтобы задолбать ими постановщика задачи ;)