Человеческий фактор в программировании - Ларри Константин

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

Самое интересное в обучении заключается в том, что чем больше вы учитесь, тем легче это становится. Учеба становится привычкой. Если этим заниматься достаточно долго, то можно даже научиться тому, как учиться. Свой первый «второй язык» после родного изучать обычно намного труднее, чем все последующие. То же самое касается и языков программирования. Почему некоторые не хотят изучать новый язык? Ведь вскоре становится ясно, что все языки являются вариациями всего на несколько тем. Вместо того чтобы учиться «программировать на языке Z», можно научиться программировать.

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

В теории

В Бостоне существует огромное количество колледжей и университетов, в которых предлагаются разнообразные подходы к образованию. Когда я пошел в колледж, в инженерной области все равнялись на Массачусет-ский технологический институт и Северо-восточный университет — две школы, которые так же отличаются друг от друга, как Smalltalk и COBOL. В районе Бэк-Бэй1 располагался Северо-восточный университет, в котором упор делался на практику и на приобретение рабочего опыта в процессе совместного обучения. На кембриджской стороне реки2 находился Тех, где правила наука, а акцент ставился на теорию, а не на практику — на фундаментальные принципы инжиниринга. Ходили слухи, что инженеры, прошедшие подготовку в Северо-восточном, могли эффективно работать уже в день своего выпуска, а выпускники Теха могли пять лет отрабатывать свое обучение. С другой стороны, еще через пять или десять лет бывшие студенты Северо-восточного сталкивались с устареванием своих знаний, а выпускники Теха по-прежнему были на высоте.

Теория не является бедной служанкой практики — она превосходит практику. Теория позволяет заглянуть в будущее. Когда Эйнштейн разработал формулу Е = тс2, ядерных реакторов еще не было. Существование планеты Плутон было предсказано еще до того, как ее смогли увидеть; теоретически она должна была существовать, судя по параметрам орбиты Нептуна. В менее космическом масштабе: теория модульной сложности, на которой основано структурное проектирование, предсказала экспериментальные результаты, появившиеся спустя несколько лет. Кроме того, эта теория предвосхитила ключевые понятия объектно-ориентированного программирования, хотя при возникновении понятий связывания и сцепления методология ООП еще не существовала даже как идея.

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

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

Из журнала Software Development, том 3, № 4, апрель 1995 г.

59

Одаренные программисты

Это был долгий год. Месяц за месяцем вы, как и другие программисты из вашей команды, тяжело работали, выполняя обязательства по проекту. Вы начинаете думать о премии в конце года. Это сезон подарков — зимнее солнцестояние, Ханука, Рождество, Кванза и обыкновенный Новый год — праздники идут один за другим. Что вы подарите вашим высокопроизводительным программистам, чтобы они поняли, как вы их цените? И вообще — как вы оцениваете, награждаете или стимулируете разработчиков приложений и программного обеспечения? По существу, именно в этом заключался вопрос, поднятый аудиторией на одном из лекционных туров, который я совершал по Австралии вместе с такими индустриальными светилами, как Роб Томсет и Эд Йордон. Это заставило всех нас задуматься о более творческих и эффективных методах поощрения разработчиков.

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

Игрушки для технарей

Многие из нас, чокнутых, любят технологические игрушки. Тест на родство со славным гранфаллоном довольно прост. Загораются ли ваши глаза при мысли о новом замечательном устройстве в ГПИ, или о SD-видео-карте к 21-дюймовому плоскоэкранному монитору, или о гигагерцовом лэптопе с диском в 20 Гбайт? Вы один из тех людей, которые не могут дождаться выхода бета-версии нового продукта? Вы раздираете целлофановую обертку для того, чтобы узнать, решены ли в релизе 2.0 проблемы релиза 1.1?

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