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

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

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

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

Каким же должно быть идеальное сообщение об ошибке?

Удалённая работа или офис открытого типа? Идея общего рабочего пространства далеко не нова. Вспомним, хотя бы, планировку статистической организации, в которой трудились известные персонажи советского художественного фильма «Служебный роман». Чем не «опенспейс» версии 1977 года?

Предположим, вы устраиваетесь на новую работу, заполняете кучу бумажек. Один из вопросов в короткой незатейливой анкете звучит примерно так: «Вы бы согласились за хорошие деньги отштукатурить комнату в доме под снос?» Некоторые ответят на этот вопрос утвердительно: «Почему бы и нет? За работу заплатят, а что будет дальше — меня не касается». Другие ни за что не согласятся выполнять бесполезную работу, так называемый «мартышкин труд». В крайнем случае — за неприлично большие деньги. Разработчики некоторых программных систем вынуждены отвечать на этот вопрос утвердительно.

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

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

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

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

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

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

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

Нашёл у себя в ящике стола один очень старый каталог книг Microsoft Press за 1988–89 годы. Мне нравится иногда его доставать, перечитывать описания компьютерных книг тех лет, разглядывать их обложки. Да и просто названия книжек из этого проспекта заставляют погрузиться в ностальгическое настроение.

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

У химиков есть известная байка, которую они любят рассказывать молодому поколению. Главный герой этой истории — студент, который пошагово воспроизводил методику одного химического эксперимента из учебника. Он старательно выполнил очередной шаг «добавьте азотную кислоту» и... в лаборатории прогремел взрыв! Когда впоследствии стали разбираться, в чём же дело, выяснилось, что на следующей странице учебника было написано: «... медленно, по каплям».

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

Как же лучше писать и оформлять примечания в технических текстах?

«Ваша документация — отстой!», «Я её никогда не читаю, всё равно там ерунда написана!», «Эти документаторы опять всё напутали», «Да любая нейросеть быстро напишет это в сто раз лучше», «Там никогда не найти ничего нужного», «А разве у нас есть документация?»

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

Давайте ненадолго перенесёмся в школьные годы и вспомним уроки математики и физики. Помните, чему равно число π? Естественно, помните, мы же на Хабре! А чему равно π в квадрате? Это тоже странный вопрос. Конечно, 9,87. А чему равно ускорение свободного падения g помните? Ещё бы, это число так тщательно вдолбили в нашу память, что захочешь — не забудешь: 9,81 м/c². Конечно, оно может варьироваться, но для решения базовых школьных задачек мы обычно использовали именно это значение.

А теперь, внимание, следующий вопрос: а с какого это перепугу π² примерно равно g?

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

— Это ты тестировал систему продажи билетов?
— Да…
— Клиент сейчас купил билет на дату «82.13.-891». Либо ты сейчас скажешь ему, сколько дней осталось до поездки, либо переводим тебя на должность стажёра.

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

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

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

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

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

Для меня таким старым надёжным другом стала программа TreePad Lite. Она со мной уже без малого 30 лет. Мне очень близок минимализм TreePad: простота интерфейса, отсутствие необходимости установки, нетребовательность к ресурсам, открытый формат файлов, отсутствие каких-либо зависимостей от сторонних библиотек и интернета.

В статье я хочу рассказать об одной очень интересной теории разработки документации на системы и программы. Её авторы утверждают, что создали ни много ни мало «Великую Единую Теорию Документации» (The Grand Unified Theory of Documentation). Мы привыкли с опаской относиться к заявлениям о том, что кто-то обнаружил сокровенную истину и раскрыл её профессиональному сообществу. В теории изложены идеи и правила, которые мы встречаем в разных методиках разработки документации и сами применяем на практике.

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

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

Через некоторое время одно из мобильных приложений выдало мне рекламу... тараканов. Предлагалось приобрести жирненьких мадагаскарских тараканчиков по необременительной цене. В этом не было бы ничего странного — мало ли что сейчас рекламируют в сети — если бы не загадочное обстоятельство: во время той самой беседы о тараканах рядом не было ни одного электронного девайса...

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

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

Дисклеймер. Все совпадения фрагментов этого текста с реальными комментариями в вашей документации совершенно случайны. При написании этого текста не пострадал ни один проверяющий.