Джоэл о программировании

Книгу читать было интересно и, местами, полезно. Хотя очень много спорных, дискуссионных вопросов. Потом, книга написана довольно давно (вернее, это сборник статей на разные тематики, но дело не в этом), технологии там разбираются, конечно, старые. Но пока речь идет о менеджменте, о подходе к решению проблем и пр., то выводы можно считать актуальными. Другое дело, что американский менеджмент мне в работе как-то неприменим, но почитать было интересно. :) В любых фирмах хватает своих проблем, и на Западе тоже. У автора был большой опыт работы, поэтому смог продемонстрировать конструктивное и неконструктивное решение таких вопросов его начальством. Что касается технической стороны дела, увы, многое уже устарело, и читается как история. Ну, это как вы начнете объяснять детям, что такое дискета. В сети сейчас даже ходит мем, когда ребенку показывают дискету, а он говорит: о, ты сделал 3D модель кнопки “Сохранить”? Вот и тут рассказы про азы почтовых программ и пр. Но сама логика, идея, как и то, почему одна фирма удержалась на рынке, а другую сейчас никто уже и не помнит - это актуально. Потом, сейчас есть такая проблема, что “вход в IT” понизился. Проблема или достоинство? С одной стороны, тут есть ряд очевидных плюсов, с другой - может быть, менее очевидные минусы. Некоторые школьники говорят: зачем мне институт, я программировать и без него научусь. Да, выучить сам язык программирования сейчас несложно. Но этого мало. Это как взяться писать “Войну и мир” только потому, что ты знаешь русский язык. Как говорили в одном известном детском фильме “энциклопедия дает краткую информацию, а школа, институт дают фундаментальные знания”. Так и тут. За 4-хмесячные курсы можно худо-бедно научиться верстать одностраничные сайты. Но за этот срок невозможно погрузиться, например, в Big Data. Да, в программировании есть области, где можно обходиться без знания математики. Но также есть и те, где высшая математика необходима, а есть и те, где очень и очень желательно хорошо разбираться в архитектуре кода. По сути автор тоже пишет об этом в своей книге:

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

Можно использовать инструмент, облегчающий тебе работу. Но для качественной работы ты должен очень хорошо понимать, что именно там прячется “под капотом”. Только тогда ты сможешь обойти ошибки инструмента (а они обязательно будут, ведь программирование без ошибок пока не бывает), а не искать судорожно поломку в своей программе. Кстати, это относится не только к программистам. Если вы пользуетесь какой-то программой для своей, не связанной с IT работы, внимательнее отнеситесь к ее сообщению об ошибках. Не надо сразу закрывать ее и кричать - у меня все поломалось! Иногда достаточно просто спокойно прочитать сообщение и проанализировать ситуацию, чтобы найти решение. Была еще одна интересная фраза, которая сильно заставила меня призадуматься:

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

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