Подтвердить что ты не робот

Стать самой эффективной командой одного человека

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

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

Чтобы максимально использовать свое время и наиболее эффективно выполнять мою работу, какие советы или практики я мог бы реализовать в своей повседневной рутине, чтобы стать лучшей командой из одного человека?

4b9b3361

Ответ 1

  • Ежедневный список того, что я собираюсь делать.

  • Удалите как можно больше отвлекающих факторов, чтобы сосредоточиться на задачах. Выключить электронная почта, отключить IM и т.д., даже если на определенный период времени, а затем во время перерыва проверьте их.

  • Найдите время, чтобы узнать о других методах кодирования, инструментах и ​​мудрости программирования. Это я считаю важным для моего развития. Это легко просто прогнать и почувствовать себя продуктивным. Как насчет того, что может быть, если у вас только что появилось больше знаний/оружия под вашим поясом, чтобы выгнать следующий виджет. Я знаю, что это действительно звучит контрпродуктивно, но на самом деле это не так. Знание/ноу-хау - наша настоящая валюта. Чем больше мы знаем, тем больше мы можем принять лучшее решение о том, как что-то нужно делать и делать это быстрее.

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

  • Научитесь использовать правило 80/20 для своего преимущество. Я не имею в виду ленивый. Часто, хотя мы будем хвост для этого 20%, когда он не был необходимо.

  • Задайте цели для себя (ежедневно, еженедельно, раз в две недели). Убедитесь, что цели также соответствуют тем, которые вы кодируются или вы можете найти вас потратили некоторое время.

Из технического аспекта рассмотрим:

  • Рассмотрим модульное тестирование /TDD. Я нашел в моя собственная работа, которая фактически спасает время. Требуется некоторое время, чтобы получить но с чем угодно поправляйся.
  • Уход за кодом. Рефакторинг (особенно если вы запустите блок тестирование). Чем лучше ваш код тем легче поддерживать занимает меньше времени. Чем проще это сделать понять, чем быстрее вы сможете изменить /реализовать функции.

Ответ 2

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

Ответ 3

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

Ответ 4

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

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

Ответ 5

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

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

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

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

Ответ 6

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

Ответ 7

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

Ответ 8

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

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

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