Coders at Work

По-моему, ночь — просто наименее напряженное время суток. Днём всё время что-то происходит: то тебе хочется перекусить, то идёшь на занятия, то тебе кто-то звонит. Тебя всегда что-то прерывает.

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

Думаю, проблемы начинаются тогда, когда люди принимают на веру некие абстракции, не понимая, что происходит на самом деле.

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

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

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

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

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

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

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

Даже сегодня писать модульные тесты для многопоточных программ — подлинное искусство.

По моему опыту, компании склонны нанимать «человека, умеющего говорить», чем подчас более глубокомысленного и вдумчивого специалиста с яркими чертами интроверта.

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

В каком-то смысле, на низшем уровне код должен говорить сам за себя. На более высоких уровнях — гигантские функции, границы модулей — уже нужна документация. Документирующие комментарии, или документарные строки. Встраивание тестов в комментарии. Думаю, разработчики Python сделали тем самым большое дело.

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

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

Если ваш код соединяется с чужим, он выходит из-под контроля. Вы не можете мысленно смоделировать происходящее.

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

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