Энергетический катализатор Андреа Росси (сокращенно E-Cat), может стать открытием столетия и переворотом в энергетике. Найден дешевый источник энергии на основе холодного ядерного синтеза который может существенно повлиять на стоимость энергетических ресурсов таких как нефть и газ.

Решил поделиться своими наблюдениями по теме профессионального роста, о вопросе который волнует многих разработчиков. Я слышу вокруг: «У меня застой, хочу развиваться дальше, а у меня нет (не дают) такой возможности. На этом проекте я не могу совершенствоваться. Я деградирую не работая с новыми технологиями». Давайте рассмотрим путь, который проходит разработчик с момента начала своей карьеры.

Уважаемые коллеги, представляю на ваш суд стартап Tahometer (www.tahometer.com).



Задача Тахометра – отчитываться перед заказчиком о затраченном фрилансером времени, рассчитывать стоимость проделанной работы в соответствии с заданными почасовыми ставками.

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

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

Мне очень нравится эта история как демонстрация того как должна действовать компания предлагающая решения.

Ситуация с которой мне часто приходится сталкиваться заставила меня поговорить о полномочиях команды разработки и в частности об их использовании. Современные гибкие направления разработки (в частности Scrum) предоставляют широкие возможности для самоорганизации. Методологи-консультанты обучают менеджеров по всему миру предоставлять командам всю полноту принятия технических решений и свободу действий. И надо признаться, многие наши руководители действительно достигают в этом успеха. Сначала с опаской, а затем все более настойчиво предлагают своим командам дополнительные полномочия и поддержку.

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

Я хотел бы напомнить об этих полномочиях. Полномочиях, которые используются самоорганизованными командами профессионалов, командами которые делают реальные вещи. Командами, которые не просят разрешения заняться рефакторингом, не просят разрешения написать тест. Потому, что подобные вещи — часть жизни профессионалов. Они имеют полномочия делать свою работу хорошо и пользуются этим, не извиняясь за то, что они профессионалы. Такие команды мотивированны, потому, что они хотят быть таковыми. Поскольку им не безразлично. Они искренне, глубоко переживают за то, что они создают. И я думаю, что так и должно быть. Это самый первый, верный шаг на пути к успеху. Если вам действительно не безразлична ваша профессия, вам нужно научиться использовать имеющиеся у вас полномочия. Полномочия разрабатывать действительно классный продукт, писать ясный и качественный код. Вам нужно очень серьезно подумать над этим. Именно вам. Это позволит вам чувствовать гордость за то, что вы делаете, изменить отношение к себе, изменить вашу компанию… Мяч на вашей стороне. Дело за вами.

P.S. Даю ссылка на оригинальную статью, которую я существенно изменил.

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

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

Чувствуете ли вы себя игроком в Дженгу (игра, в которой игроки попеременно добавляют по одному элементу к возводимой конструкции, проигрывает тот, чье действие приведет к её разрушению), когда программируете? Насколько легко вносить изменения в ваши программные системы? Опасаетесь ли вы, что после внесения изменений ваш код неожиданно перестанет работать? Если вы утвердительно ответили на один из этих вопросов — это явный признак некачественно спроектированного кода, который приводит к замедлению вашей работу уже на следующий день после его появления. А приходилось ли вам когда нибудь разрабатывать код, который сложно было понять уже на следующий день? Мне посчастливилось присутствовать на многих презентациях Боба Мартина (Uncle Bob) и мне очень нравится та часть его выступления, где он спрашивает слушателей, сталкивались ли они с существенным замедлением скорости разработки из-за плохого кода. Когда большинство слушателей поднимали руки, он спрашивал: «Так зачем же вы его так написали?».