воскресенье, 5 апреля 2015 г.

Чед Фаулер. Программист-фанатик



Фанатизм мной воспринимается как-то отрицательно. Фанатик - это человек, который не воспринимает аргументов и слепо отстаивает предмет, фанатиком которого он является. Вряд ли я купил бы эту книгу, зная о ней только её название. Однако, я - большой любитель почитать комментарии и скорее всего я просто почитал отзывы об этой книге в каком-то онлайн-магазине и они меня убедили в том, что эта книга достойна того, чтобы её прочитать. На самом деле книга называется Passionate Programmer - страстный или пылкий программист. Впрочем, если перевести название книги именно так, многие бы решили, что книга представляет собой какой-то любовный роман о программисте :)

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

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



В среде программистов на таких людей часто навешивают ярлык "ковбой". Однако люди часто останавливают дальнейшие размышления над темой, когда они нашли подходящее слово. Если слово найдено, значит дальше думать не нужно - всё понятно. О чём-то похожем писал Фейнман в книге "Вы, конечно, шутите, мистер Фейнман!", когда рассказывал о своём отце. Люди думают, что если они знают название птицы, значит они знают эту птицу, но на самом деле они могут не знать об этой птице ничего, кроме её названия всего на одном языке. Если задуматься и попытаться осмыслить "ковбоев" как явление, то окажется, что именно "ковбои" придумали экстремальное программирование, гибкие методики разработки, скрам и непрерывную интеграцию. Это те методики, которые заявляют: "Будь мужиком, просто напиши этот код!" или, как гласит девиз Nike, "Just do it!"



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

Мне хочется двигаться именно в таком направлении. Правда такое направление лучше сочетается с деятельностью системного администратора Unix, поэтому я себя позиционирую не как программиста, а как системного администратора. Деятельность системного администратора позволяет проникнуть во все аспекты системы, видеть насущные проблемы системы, общаться с пользователями. Программисты вынуждены каждый день работать над кодом и часто углубляются в тонкости не самых лучших технологий, не имея времени на ознакомление с более перспективными технологиями и не имея возможности оценить место своей программы в общей системе и её роль в компании. У системного администратора оказывается больше времени на то, чтобы уделять внимание изучению перспективных технологий и языков программирования, вырваться за узкие рамки специализации и видеть больше. В результате формируется хорошее понимание проблем, пожеланий и наиболее перспективных направлений для их решения и реализации.

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

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

Комментариев нет:

Отправить комментарий