Задайтесь вопросом «ГДЕ?». Где находится центр управления движением галактик или поведением циклона? Где та сила, что объединяет атомы в сложные соединения, те в свою очередь — в цепочки белков, и порождает такие устойчивые и сложные явления как биологическая жизнь, разум, социум.

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

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

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

Agile движение имеет свой взгляд на спецификации. Наиболее экстремальное крыло выражает свои взгляды так:

В жопу спецификации!

На www.edx.org в рамках курса Software as a Service опубликована интересная лекция технического руководителя (engineering manager) Дэнни Бурка (DANNY BURKES) о том, как устроена их работа в Pivotal Labs. Выдержками из этой лекции, переведенными на русский язык, хочу с вами поделиться.

Лекция построена следующим образом. Сначала рассказывается о философии разработки ПО в Pivotal Labs. Затем даны более конкретные рекомендации для разработчиков и менеджеров проектов. В конце рассказывается о практике найма людей в их организацию.

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



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

Я сполна получил п***й за первый пост. Самое время писать продолжение! Итак, чего же мне надо от резюме разработчика?

Все ниже в порядке приоритета.

Код

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

Честно скажу, когда я искал работу, мое резюме смело можно было отнести к категории плохих. Да, там было несколько хороших секций (типа, а вот я написал 2 книжки и 30 статей), но также там была и таблица скилов со строчкой: C#, 1 year of experience, Intermediate (!).

Сейчас я читаю много резюме и приглашаю людей на интервью. За последние 3 года я провел около сотни интервью, а резюме повидал раз в 5 больше. Так что сейчас я довольно четко представляю, что я хочу видеть в резюме. Но для начала я расскажу, чего в резюме я видеть не хочу.

Шаблоны

Многие аутсорсинговые компании придумали себе шаблоны резюме. Мотивация, в принципе, понятна, они хотят все унифицировать чтобы использовать machine learning для извлечения хороших кандидатов все выглядели одинаково, как рядовые в строю. Однако, шаблоны эти одинаковы для всех позиций и составлены мудрыми CTO недалекими HR, которые понятия не имеют, что такое реально классный программист.

В данной статье я затрону современные интерфейсы. Не все из них плохие. Но складывается впечатление, что такие титаны создания ПО, как Microsoft и Google, идут неверным путем. И этот путь заведет всех нас в глубокую … ситуацию.
Внимание, много букв!

Вы слышали, что в некоторых компаниях сотрудникам разрешается 20% времени работать над собственными проектами? Оказывается, существует компания, где этот принцип возвели в абсолют. Представьте, что 100% рабочего времени вы можете работать над любыми проектами, какими пожелаете. Менеджеров не существует вообще, никаких отделов и начальников. Структура компании — плоская, все сотрудники равны между собой и добровольно группируются по интересам. Выживают те проекты, которые привлекают больше сотрудников.

Звучит как утопия? Знакомьтесь с принципами менеджмента в компании Valve, которая занимается разработкой компьютерных игр (Half-Life, Portal, Steam).

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

Коллеги, на правах публикации в хабе компании, разрешите поделиться новостью, к которой мы шли примерно год. Мы официально выпустили бесплатную версию TargetProcess в «облаке» aka SaaS aka On-Demand.

TargetProcess – система управления проектами с фокусом на методологии Agile (XP, Scrum, Kanban). Систему начали разрабатывать в 2004 году четыре белорусских программиста. Теперь ей пользуется больше тысячи компаний по всему миру (Orange, Sony, Intel, Microsoft, Paralles, Kaplan и др.). Основные преимущества: скорость, гибкая настройка и удобство использования.

Дальше я расскажу, как она наша система может вам пригодиться.

В начале 1880 года, некий Чарльз Певи, дантист из Вустера, привлёк внимание общественности предложив $1000 (тогда это были неплохие деньги), за решение следующей задачи: пятнадцать шашек были размещены в квадратной коробочке в правильном порядке, и только шашки 14 и 15 были переставлены, как показано на рисунке. Задача состояла в том, чтобы, последовательно передвигая шашки, привести их в нормальное положение, причем, однако, порядок шашек 14 и 15 должен быть исправлен.

У нас в компании каждый сотрудник может 5 часов в неделю заниматься самообразованием (читать/писать на «Хабр», учить F# или читать SICP). Со временем данная практика эволюционировала в создание мини-проектов. Так, например, Максим, опытный JavaScript-разработчик, решил попробовать себя в создании приложений под iOS, и, примерно, за полтора месяца выпустил пятнашки, которые, без всякой рекламы, за неделю продаж вошли в TOP 10 русского App Store в категории игры.

Далее код проверки на Objective-C и принцип прохождения пятнашек из книги Якова Исидоровича Перельмана «Живая математика».

В продолжение темы «Наш процесс разработки: 50 месяцев эволюции» разрешите вам рассказать историю формирования нашей support-команды.

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

1. Я прав, а ты нет

Начиная с 2009-го года, компания Atlassian, производитель известного issue-tracker JIRA и корпоративной wiki Confluence, проводит ежегодное мероприятие под названием Atlassian Summit.

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



По традиции Саммит проходит в Сан-Франциско, где расположен один из офисов компании, и в этом году я впервые побывал там. Хочу немного поделиться с вами новостями из мира Atlassian, да и просто впечатлениями.

Нашей компании уже 6 лет. Она была основана на принципах agile и росла на них. Мы использовали Extreme Programming с самого первого дня, добавили немного Scrum позже и в конце концов переключились на Kanban. Хочется поделиться бесценным опытом и рассказать об изменениях нашего процесса разработки за последние 4 года.

Дорогие мои, любимые, сохабровцы! Должен признаться вам, что я, на правах религиозного фанатика, являюсь совершенно счастливым человеком, но последних лет 16, из своих 32, наблюдаю вокруг все усугубляющуюся картину борьбы общества с абсурдностью бытия. Дело в том, что многие из моих знакомых работают в крупных компаниях, где их безжалостно гнобит офисная сансара, а у меня, уж так сложилось, никогда не было жесткого графика и довлеющей корпоративной машины за спиной, за что я денно и нощно возношу хвалу Аллаху. Находясь на значительном удалении от этих проблем и будучи в них эмоционально не вовлеченным, занимаясь наукой в свое удовольствие в НИИ Системных технологий (а на жизнь зарабатывая собственным ИТ-бизнесом), при помощи чудодейственного системного анализа я постараюсь обобщить тут все, что знаю по теме.

Доброго времени суток. Это статья — перевод заинтересовавшего меня поста в блоге аспиранта Университета штата Нью-Йорк в Стоуни-Брук. Статья в доступной форме описывает основные концепции функционального программирования, их преимущества и недостатки. Думаю она будет полезна широкому кругу читателей, которые сомневаются, нужно ли им углубляться в мир функционального программирования или нет. Пожелания, предложения и замечания по переводу и терминологии принимаются по личной почте.

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

UPD: альтернативный вариант перевода вы можете найти на rsdn (спасибо flamingo за ссылку).

В пятницу мы поделились тайными секретами нашей работы. Либо секреты оказались не такими уж тайными, либо звезды стали в неудобную позицию, либо наш уровень интеллекта слишком низок, но реакция на пост оказалась не такой, как мы ожидали.

Сегодня мы хотим рассказать вам, как мы на самом деле работаем.

Кухня

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

Начнем с самого главного — с пищи материальной. Все, что написано ниже, бесплатно для всех сотрудников. У нас стоит итальянская кофе-машина:

Сегодня мы хотим приоткрыть завесу и рассказать о нескольких секретных практиках нашей компании. Мы делаем систему управления гибкими проектами TargetProcess. Надеемся, что практики помогут вам понять наши ценности и видение лучше.

Смотритель за Функциональными Тестами (СФУТ)

У нас есть специальная роль смотрителя за функциональными тестами. Роль ротируется, каждый день за тесты отвечают разные люди. Человек в этой роли улучшает зеленые тесты и комментирует красные. Тесты становятся лучше и стабильнее со временем.

Для обозначения СФУТ разработчика у нас есть кот. Кот целый день сидит на столе возле СФУТ и улыбается.



В течение ежедневного собрания кот передается от одного разработчика к следующему по списку.

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

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

И, как обычно, прощу прощения за объем статьи. Но, надеюсь, вам будет интересно дочитать до конца.