6 ценных советов от программиста с 45-летним опытом работы

Джоэл Голдберг (Joel Goldberg) больше 40 лет проработал в области разработки программного обеспечения. Перед уходом на пенсию он поделился с коллегами по компании BTI360 уроками, которые извлёк за свою долгую карьеру.

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

1. Остерегайтесь проклятия знания

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

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

Боритесь с проклятием знания. Работайте над пониманием своей аудитории. Попробуйте представить, каково это — узнать впервые о том, о чём вы говорите.

2. Сосредоточьтесь на основах

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

1. Работа в команде — отличные команды создают отличное ПО. Не воспринимайте командную работу как должное.
2. Доверие — команды работают на доверии. Будьте надёжным человеком, с которым сами бы хотели работать.
3. Коммуникация — общайтесь честно и проактивно. Избегайте проклятия знания.
4. Поиск консенсуса — найдите время, чтобы собрать всю команду. Пусть обсуждение и несогласие приведут вас к лучшему решению.
5. Автоматическое тестирование — хорошо протестированный код позволяет вашей команде двигаться быстро и уверенно.
6. Чистый, понятный и удобный для навигации код — думайте о следующем разработчике, который будет работать с вашим кодом, как о заказчике. Пишите код, который не будет вызывать проблем с чтением, обслуживанием и обновлением.

3. Упрощайте

Борьба со сложностью — бесконечное занятие. Решения должны быть максимально простыми. Предположите, что следующий человек, который будет работать с вашим кодом, не так умён, как вы. Используйте меньше технологий, когда это возможно.

4. Стремитесь сначала понять

Одна из семи привычек Стивена Кови (американский консультант по вопросам руководства, управления жизнью, преподаватель и консультант по организационному управлению — прим.пер.) гласит: «Стремитесь сначала понять и только потом — быть по́нятым». Этот принцип помог мне больше, чем любой другой совет, стать хорошим слушателем и товарищем по команде.

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

5. Остерегайтесь привязки

Постоянно появляются новые продукты, которые обещают произвести революцию в разработке программного обеспечения. Средства автоматизации разработки программ (CASE), готовые к использованию технологии (COTS), продукты планирования ресурсов предприятия, такие как Peoplesoft и SAP, и да, даже Ruby. Они заявляют об удивительном сокращении затрат и времени, если вы поверите в их целостную философию.

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

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

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

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

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

Я никогда не сомневался в правильности сделанного выбора.