A. Rudenets

В общем-то посты о том, чего я не знаю, я могу больше не писать. В этом т.н. «минимуме» упаковано материала на десятки лет вперёд, и до пенсии этих тем мне точно хватит :)) Осталось только понять, зачем.

Та структура собеседования, которая описана в статье, отчасти напоминает тот процесс, к которому я в конце концов пришёл по ходу кампании найма сотрудников в Trucker.

Не так давно мне предложили собрать команду из новых разработчиков и стать её тимлидом. Я начал общаться с кандидатами, опираясь на старую структуру собеседования, которую разработал ещё на прошлом месте работы. Однако я быстро понял, что нанимать своих клонов и задавать закрытые вопросы прямо как на экзамене – плохая идея.

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

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

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

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

И в этом случае кажется, что UX вашего Confluence не должен отличаться от сценария, когда кто-то к кому-то пристаёт с вопросом и получает конкретный ответ. А значит, хорошая статья документации – это маленькая статья с перекрёстными ссылками и с понятным заголовком, которую легко найти в поиске.