Какие идеи из других профессий вы применили к разработке программного обеспечения?

У Элияху Голдратта есть книга под названием «Цель», которая представляет собой новеллизированную бизнес-книгу по оптимизации завода. В нем много хороших дискуссий о том, как определить реальность (или, по крайней мере, подвергнуть сомнению ваше собственное представление о ней), а также про узкие места, что очень полезно при общей проблеме масштабируемости.

Психология одна. Это не просто мотивация себя и своих товарищей по команде, но использование техник, позволяющих понять, чего на самом деле хочет клиент, а не того, о чем он просил. Юзабилити - это еще кое-что, что имеет значение для разработки программного обеспечения, это фактор, ориентированный на человека.

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

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

Бережливое развитие - очевидный выбор, взятый из производственных принципов Тойота для борьбы с экономией на масштабе мощной промышленности США. Он хорошо сочетается с гибкой структурой разработки программного обеспечения.

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

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

Я полагаю, что Фред Брукс назвал бы это синдромом второй системы.

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

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

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

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

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

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

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

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

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

Я почти закончил преподавание ИКТ в средних школах. Я многому научился:

• Даже учителя остаются учениками - все время учатся.
• Лучшие учителя - лучшие ученики
• Вы можете многому научиться у окружающих, независимо от уровня их навыков.
• Подготовка часто является ключом к успеху
• Предположение - мать всех ебли
• Технологии меняются слишком быстро, чтобы успевать за последними разработками - признайтесь, вы не все знаете.

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

В хорошей компании я не могу сказать, из какой профессии я смоделировал такое поведение.

Принцип KISS (Keep яt Simple, Stupid) применяется здесь так же, как и в моих исследованиях в области машиностроения. Что касается кодирования, то, скорее всего, разработчик и другие пользователи потратят больше времени на чтение код, чем на письмо. Поэтому очень помогает иметь максимально простой дизайн для данной проблемы. Излишняя инженерия в этой области заставит даже первоначального разработчика почесать голову через три-шесть месяцев, говоря: «С какой стати я это делал?»

Только мои 0,02 доллара.

Контрольные списки! Они не только для пилотов:

Сила контрольного списка

Видео о производственном предприятии Dell вдохновило на создание архитектуры системы распределенной агрегации контента на основе очередей. Сообщение в очереди представляло рабочие элементы с рабочими листами, задачами, деталями и т. д., Передаваемыми от станции к станции.

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

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

Это был захватывающий момент - впервые увидеть, как система «дышит».

Любознательность и упорство.

Хотя это не совсем профессия, я думаю, что нам также нужно черпать из творческих личностей. Например, писатель обычно блокирует себя на определенные отрезки времени, чтобы писать без перерыва. Пол Грэм проводит четкие параллели между Хакеры и художники