Случай с бомжом

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

Обычно вместо денег я даю попрошайкам-мужчинам телефон отдела кадров одной курьерской компании, которая постоянно нуждается в сотрудниках. Но у него не было ног… Тогда я подумал: «Чувак, у тебя полным полно времени. Работа за компом — лучшее, что может случиться в твоей жизни. Купон со скидкой на курс по PHP — вот, что должны были положить тебе на койку туда, где раньше были ноги, когда ты очнулся после ампутации».

Я решил предложить ему изучить программирование. В его положении он должен был быть чертовски мотивирован. Но получится ли у него?

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

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

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

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

Как нам это удается?

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

Всем привет, на связи Лиза, UX-писатель, и Стася, UX-аналитик Центра Развития Финансовых Технологий Россельхозбанка. 

Ближе к релизу наших площадок в продуктовых командах все чаще стали слышны споры о текстах. Все началось с экрана «404» — кто-то считал, что в сообщении об ошибке нужно пошутить, чтобы расслабить пользователя, а другие, что шутить с человеком, раздраженному ошибкой — некорректно. Любители шуток победили в том споре, но появился следующий вопрос: а допустим ли юмор в нашей экосистеме? Все-таки мы серьезная организация, банк. Если юмор допустим, то насколько игривый? У нас не было однозначного ответа на эти вопросы.

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

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

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

Нижележащий текст преследует несколько целей:

1. Дать краткий обзор (читай — немного погундеть на тему) неудовлетворительного состояния инструментария, применимого к хтоническим чудовищам мира C/C++;
2. Предложить своё альтернативное решение (бесплатно-без-СМС-и-регистрации — проект некоммерческий и выложен на GitHub под MIT-лицензией);
3. Призвать сообщество пообщаться на тему и собрать идеи;
4. Пригласить присоединиться к разработке проекта на GitHub.

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

У меня иногда складывается впечатление, что не он служит для нас, а мы служим для этого формата. Поэтому — сэр Markdown.

Заметил за собой, что постоянно записываю всякие мелочи, полезную информацию, просто что-то из буфера обмена прямо в текстовом редакторе. Всегда где-то на фоне висит открытый Sublime Text с кучей вкладок.

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

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

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