Coders at Work

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

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

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

Питер Норвиг: Мы любим чувствовать себя умными и любим завершенность.

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

Армстронг: ... мы поняли, что открывать новые вещи не так-то легко. И невероятно трудно убедить людей пользоваться новыми, более совершенными вещами.
Сейбел: Erlang относился к этим новым, более совершенным вещам?
Армстронг: Да, разумеется.

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

Будет неплохо несколько месяцев поизучать “Structure and Interpretation of Computer Programs” вместе с сыном. Говорят, это отличная книга.

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

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

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

Затем “Elements of Style” (Элементы стиля). Хотя она, собственно, не о программировании, прочесть ее нужно по двум причинам. Во-первых, потому, что разработчик ПО тратит значительную часть времени на написание прозы. Если вы неспособны создавать логичные, стройные, хорошо читаемые спецификации, вашими программами никто не сможет пользоваться. Поэтому все, что способствует улучшению стиля изложения, есть благо. И во-вторых, большинство высказанных там мыслей применимы и к программам.

Сейбел: Каков, по-вашему, самый важный навык для программиста?
Фицпатрик: Мыслить как ученый; за один раз изменять только что-то одно.

Фицпатрик: Не знаю. Мне знакомы по-настоящему умные люди, я бы сказал, хорошие программисты, но которые знают только Java. Они думают о решении задачи в пределах известной им области. Они не думают о задаче от начала и до конца. По-моему, надо знать всю цепочку, даже если оперируешь только с одним звеном.

Была и еще одна книга, которую все считали величайшим трудом своего времени: “Design Patterns”. По-моему, отстой. Там учили программировать методом “вырезания и вставки”. Вместо того чтобы подумать над своей задачей, берешь сборник рецептов, ищешь там что-то более-менее похожее и просто пытаешься это воспроизвести. Это не учебник программирования, а книжка-раскраска. Но, похоже, многим она нравилась.