Читаем Кодеры за работой полностью

Один мой университетский знакомый, уже отучившийся и работавший в BBN, сказал мне: «Давай к нам». Помню, я впервые попал туда в полночь, потому что BBN была безумным местом, где работа кипела круглосуточно, семь дней в неделю. Компания была своеобразным продолжением лабораторий MIT. Каждый мог приходить и уходить когда хочет. И мой приятель как раз работал в ночную смену. Вот мы и наведались туда как-то поздно вечером. Все было загадочным и мистическим; я, по-моему, вообще не понимал, что мне показывают. Вскоре мне передали, что меня хотят нанять. Пригласили на интервью и взяли на работу.

Сейбел:

Вы тогда были на третьем курсе MIT?

Козелл: Точно. В сентябре меня взяли на полставки. А уже в начале октября я отчислился и устроился в BBN на полный рабочий день. Теперь мне кажется, что я не был так уж хорош. Я видел компьютер PDP-1, но понятия не имел, как на нем программировать. И ничего не знал о том, что такое разделение времени. Впрочем, это неудивительно, потому что об этом тогда знали хорошо если человек пятьдесят во всем мире.

В BBN тогда делали совместный проект с Главным госпиталем Массачусетса по автоматизации работы больниц, и меня взяли в этот проект. Начинал я как программист приложений, поскольку это было все, на что я тогда годился. Проработал в этом качестве недели три. Но вскоре стал системным программистом, писал библиотеки, которые они использовали. И некоторое время спустя два системных гуру, парни, создавшие большую часть системы разделения времени для PDP-1, взяли меня под опеку и подключили к своей работе. Той зимой они оба покинули BBN, чтобы продолжить свое университетское образование. И к январю я был «царем системы разделения времени PDP-1» — отвечал за весь проект целиком.

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

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

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

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

Я решил, что вся система должна быть абсолютно безотказной. Не помню, требовало от меня этого начальство или нет, я сам поставил перед собой такую задачу. Решил, что должен доказать — именно я должен, — что разделение времени может работать. Что это достаточно надежная вещь, чтобы медики могли ей довериться. Я представлял себе ситуацию, когда пациенту срочно нужно лекарство, а система вдруг «упала». Или, что еще хуже, она потеряла рецепт и пациент вообще никогда не получит свое лекарство. А что будет, если все рецепты перепутаются, а ничего не подозревающие врачи поверят электронике? Так что я решил, что система вообще не должна ломаться. Ее нужно было сделать столь же надежной, как UNIX 30 лет спустя.

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

Сейчас даже страшно подумать, насколько лучше. В общем, в итоге начальству пришлось выдать мне пейджер. В те времена это был настолько крутой аппарат, что служебные давали только врачам. Громоздкая неудобная штука, которая умела только одно — пищать. Никакого обмена сообщениями. И он работал только в Бостоне и вокруг него, потому что передатчик был установлен на крыше Пруденшл-центр. Но в радиусе 50 миль сигнал был.

Перейти на страницу:

Все книги серии Профессионально

Кодеры за работой
Кодеры за работой

Программисты — люди не очень публичные, многие работают поодиночке или в небольших группах. Причем самая важная и интересная часть их работы никому не видна, потому что происходит у них в голове. Питер Сейбел, писатель-программист, снимает покров таинственности с этой профессии. Он взял интервью у 15 величайших профессионалов: Кена Томпсона, создателя UNIX, Верни Козелла, участника первой реализации сети ARPANET, Дональда Кнута, Гая Стила, Саймона Пейтон-Джонса, Питера Норвига, Джошуа Блоха, Брэда Фицпатрика, создателя Живого Журнала, и других. Все они «подсели» на программирование еще в школе. Тогда, на заре зарождения отрасли, лишь в немногих учебных заведениях читались курсы по компьютерным наукам. Поэтому будущим гуру приходилось покорять профессиональные вершины самостоятельно, но всех их отличает творческое горение и полная самоотдача любимому делу.Вы узнаете, что они думают о будущем программирования и как сами научились программировать, как, по их мнению, нужно проектировать ПО, как выбор языка программирования влияет на продуктивность и можно ли облегчить выявление труднонаходимых ошибок.

Питер Сейбел

Биографии и Мемуары / Программирование / Прочая компьютерная литература / Документальное / Книги по IT
Человеческий фактор
Человеческий фактор

Немногие книги о компьютерах оказали такое заметное влияние на управление разработкой программного обеспечения, как «Человеческий фактор». Уникальное озарение этой книги, долгие годы сохранявшей свое положение в списке бестселлеров: самые сложные проблемы разработки ПО носят не технологический, а социальный характер. Эти человеческие проблемы решать не просто, однако, решив их, вы увеличите шансы на успех до верхнего предела.В третьем издании появилось шесть новых глав и внесены многочисленные правки в основной текст, так что теперь книга лучше соответствует современным средам разработки и современным проблемам. В частности, обсуждаются патологии лидерства, которые раньше за патологии не считались, эволюционирующая культура собраний, а еще растущее понимание того, что некоторые наши инструменты служат скорее якорями, а не двигателями. Каждый, кому необходимо управлять проектом по разработке ПО или целой организацией такого рода, найдет на страницах этой книги множество ценных советов.

Тимоти Листер , Том ДеМарко

Деловая литература
97 этюдов для программистов. Опыт ведущих экспертов
97 этюдов для программистов. Опыт ведущих экспертов

Приобщитесь к мудрости экспертов и запомните то, что должен знать каждый программист, с каким бы языком и на какой платформе он ни работал. 97 кратких и очень полезных советов повысят ваш профессионализм посредством новых подходов к старым проблемам, лучших практик и разумных подсказок, предназначенных для оттачивания мастерства.Авторы этой книги, очень опытные и признанные в отрасли специалисты, передадут вам практические знания и принципы, полезные для проектов любого типа. Статьи касаются разных тем: от рекомендаций по написанию кода до культуры, от выбора алгоритмов до гибкого программирования, от приемов реализации до профессионализма, от стиля до сущности. Новички смогут познакомиться с фундаментальными положениями, а для профессионалов сборник сможет стать отправной точкой для обсуждений.

Пит Гудлиф

Программирование, программы, базы данных

Похожие книги