Становление самой эффективной индивидуальной [закрытой] командой

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

Многие другие советы хороши, но они в равной степени применимы как к разработчикам, работающим в команде, так и к разработчикам-одиночке.

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

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

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

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

Я пишу и запускаю интеграционные и системные тесты, но не юнит-тесты, потому что мне не нужно раннее (до интеграции) тестирование: Следует ли тестировать внутреннюю реализацию, или только тестировать публичное поведение?

Следствием закона Конвея является то, что вам нужно тестировать внутренние программные интерфейсы, которые разделяют / объединяют разработчиков, тогда как «армии из одного человека» не нужно явно тестировать свои внутренние интерфейсы таким образом.

• Обязательно выполняйте рефакторинг как можно раньше и чаще. Это почти как вторая пара глаз (по крайней мере для меня).
• Не работайте безумно много часов (особенно сложно, если вы работаете из дома). На самом деле, работа на меньше часов часто оказывается более продуктивной, поскольку надвигающиеся перерывы / давление в конце рабочего дня повышают вашу эффективность.
• Вы можете найти Закон Паркинсона для управления работой / временем.

У меня такая же ситуация. Выше уже есть много хороших советов, но я бы добавил одну вещь: определите, когда у вас лучшее время кодирования, и убедитесь, что вы пишете в это время. У меня есть несколько часов утром, когда я, кажется, в моих силах писать код. Я стараюсь не отвлекаться на это время. Планируйте такие вещи, как встречи, написание документации, тестирование (по крайней мере, утомительные, повторяющиеся вещи) и все остальное на менее продуктивное время. Удерживайте те часы программирования, когда вы в 2–5 раз более продуктивны.

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

Я также использую другой текстовый файл (для каждого клиента), который содержит все рабочие элементы на моей тарелке, расположенные в порядке приоритета , и часто обновляется. Это помогает и мне, и моим клиентам сосредоточиться на том, над чем я должен работать дальше, поэтому насос всегда заряжен.

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