Народная мудрость: «Если ты сделаешь что-то быстро, но плохо, никто не вспомнит, что ты сделал это быстро. Но все скажут, что ты сделал это плохо. Если ты сделаешь что-либо медленно, но хорошо, никто потом не вспомнит, что ты делал это медленно. Но все потом скажут, что ты сделал это хорошо».
Можете ли вы поручить своему лучшему программисту любую задачу? А если поручите, то сможет ли он блестяще ее решить? Ответ на эти вопросы лежит не только в формальной области знает/не знает, опытен/не опытен, но и в области психологии мышления. Задачу можно решить:
- Быстро и хорошо.
- Быстро и плохо.
- Медленно и хорошо.
- Медленно и плохо.
В зависимости от индивидуальных качеств, любого программиста можно отнести к одной из этих 4 групп. Но на самом деле, при классификации программиста, у вас будет выбор только между двумя категориями. Почему?
Потому, что люди, которые могут делать работу быстро и хорошо, стремительно совершают восхождение по карьерной лестнице и становятся либо руководителями, либо открывают свой бизнес. Вероятность встретить их на рядовых программистских должностях мизерна. Те, кто работает медленно и плохо программистами так и не становятся- их "заворачивают" еще на стадии стажера. Вот и остается два реально действующих типа программистов: работающих быстро и плохо, работающих медленно и хорошо. Обе категории важны для процесса производства ПО.
Тип работающих быстро, но плохо наиболее распространен. По моим ощущениям- не менее 60% от программистов, входящих в эти две группы. Эту категорию любит начальство и заказчик, потому, что они умеют прямо таки с космической скоростью клепать код. Именно, что клепать, так как такой код для дальнейшего развития вообще не пригоден. При модернизациях программ его либо полностью выкидывают, либо нанимают консультантов, которые чаще всего внешними косметическими мерами улучшают его. В таком коде, как правило, отсутствуют какие-либо проверки в функциях на корректность входных параметров, нет ни строчки комментариев и, чтобы избавится от надоедливых исключений (exception), густо натыканы их перехваты (catch) с пустыми операторными скобками. Такой код изобилует неожиданными "ходами" на ровном месте. Неожиданными, потому, что решение тривиальной задачи уже накатанным приемом решается вдруг каким-то умопомрачительным вывертом, который полдня разбираешь, а потом еще полдня цедишь сквозь зубы ругательства в адрес того м… который пару тривиальных и всем понятных строчек раздул в невесть что.
Но ведь заказчик и начальство не смотрят на код- их интересует конечный результат, который данная группа программистов может обеспечить весьма быстро. На практике оказывается не столь уж и важно, что потом при эксплуатации такого ПО возникает куча ошибок- благодаря умению быстро клепать код, такой программист молниеносно "залатывает" сотни обнаружившихся ошибок. Большое преимущество таких программистов в том, что с их помощью ПО можно запустить в дело весьма быстро. Находясь в эксплуатации, это ПО уже начнет приносить прибыль, а возникающие многочисленные ошибки в работе ПО быстро устраняются, не приводя к долгим простоям. Минус такого стиля кодирования проявляется не часто- в основном когда требуется внести существенный функционал в ПО. Тогда выясняется, что лучше его переписать с нуля.
Второй тип- медленный пишут ПО, но код грамотный, с хорошими возможностями расширения. Код медленно пишется не потому, что они тугодумы, а потому, что предпочитают перед написанием кода продумать архитектуру порученного им участка кода, и приступают к кодированию когда в голове складывается во едино вся картина предстоящей работы. Их труды можно распознать в первую очередь по комментированию кода и широкому использованию абстракций. В результате их работы код состоит в множества функций, небольших по объему, но в самих функциях делается много вложенных вызовов других функций. И тут чаще ругаешься по поводу того, как загнул сильно мысль свою программист, что "без 100 грамм и не поймешь".
Обычно заказчики и начальство недовольно ими из-за затягивания сроков. Но потом, когда в ходе эксплуатации, такое ПО работает устойчиво, с небольшим количеством ошибок, заказчик уже не помнит о том, с какими задержками проходило внедрение, а радуется текущей хорошей работе ПО. Чаще всего потом заказчик снова обратится к этому же разработчику с другим заказом. Поэтому начальники и ценят этих "тормозов"-программистов- если за "торопыг" заказчики не держатся ("торопыги" берут не качеством, а количеством), то у "тормозов" образуется свой круг клиентов.
Поэтому, получив заказ, грамотный начальник, раздавая задания своим подчиненным, будет учитывать не только их профессиональный уровень, но и психологию мышления. Обе группы важны для процесса производства ПО- главное, правильно распределять между ними обязанности. Например, второй группе (медленные-хорошие) можно поручить реализацию сложного кода, ядра ПО, тех вещей, которые по-быстрому, не продумывая, не сделать никак. А программистам группы "быстрые-плохие" прекрасно подойдут короткие задания, реализации интерфейсных функций.
Самим программистам, прочитавшим эту статью, я рекомендую четко определиться с принадлежностью к тому или иному психологическому типу программистов и, в соответствии со своим типом, подбирать работу. Это повышает ваши шансы оказаться "на своем месте", получить максимальную отдачу от работы и в плане зарплаты, и в плане удовлетворения результатами своих трудов.
