Вопрос времени мы уже затрагивали – на все нужно время. И на себя тоже.
Это с одной стороны.
С другой стороны, по моим представлениям, здоровье не может рассматриваться как отдельная какая-то вещь в себе, как примочка. Здоровье – это продукт мировоззрения человека, причем продукт, глубоко интегрированный во все сферы деятельности и тесно переплетенный со всем, что делается человеком; в одних случаях здоровье – следствие, в других – причина… Да и сам термин «здоровье» - очень емкий, тогда как большинство понимает его просто - «болит/не болит» (если ничего не болит, еще не значит что здоров,
на самом деле)… Эта взаимосвязь и заставляет меня подходить к пути улучшения здоровья (да чего там - сохранить бы то, что есть :-)) не с позиции «надо заниматься спортом», а с позиции «надо менять жизнь». А жизнь изменится только когда в голове переключение произойдет. Только тогда владелец этой головы пойдет не пиво вечером пить а оденет кеды и пойдет побегать. На стадион.
В общем, вот это вот сочетание «Отсутствие времени + Взаимосвязь с образом жизни» привело меня вот к какому размышлению…
Если говорить об эффективности вашего труда программиста – как можно его оценить? Не по деньгам, не по качеству написанного кода, не по количеству строк (как это сейчас кое-где делают, – на мой взгляд, это бред), не по важности программы для предприятия, а также не по количеству затраченного времени… Это все срезы, которые интересуют вашего начальника или заказчика.
А вот другой срез, который очень мало кто применяет – просто потому что никто из тех, кто дает задание на выполнение проекта – не задается целью сделать такой срез. Ну и по инерции все исполнители свой труд и оценивают – количеством строк, например.
Этот предлагаемый мной срез звучит так: «Что выполненная работа принесла мне лично».
Вот такая вот оценка. Причем формулировка «мне лично» подразумевает не деньги, которые вы за работу получили. Она подразумевает «Что у меня осталось в голове» после выполнения проекта.
Поясняю на примере. Я пишу софт для 8-канального АЦП 8МГц, 2ЦАП 100кГц и т.п. с кучей других параметров. Данный АЦП для меня новый, я с ним еще не работал. Значит, по идее, после написания софта я научусь работать с его драйверами, библиотеками, узнаю новый способ адресации, может быть представления данных в памяти, у меня на будущее будет объектный модуль
для применения в других аналогичных программах.
Все перечислил? Даже если не все, важен сам принцип. Смотрим, что получается на самом деле.
На разработку я трачу месяц. Из этого времени неделю я трачу на планирование - изучение документации к плате, выработку ключевых решений по обмену данными и отображению осциллограмм, строю в голове или на бумаге (или в диаграмм-редакторе) схемы, отображающие мое видение алгоритма, изучаю примеры, пишу маленькие программки для проверки отдельных функций драйвера…
И приступаю кодить, как говорится. И кодю, кодю, кодю - аж три недели. За это время возможны какие-то исправления и доработки, не учтенные на этапе планирования, естественно.
Внимание вопрос. Сколько времени из этих четырех недель ложится в вашу личную копилку? Ну, как личности, как специалиста, в конце концов? Не как пишущий автомат, давящий кнопки, а как человек? Попробуйте меня убедить, что больше 50% всего времени. То есть, в рассматриваемом случае, – 2 недели. Потому что вы как специалист растете только то время, в течение которого вырабатываете решение (первая неделя) и то время, когда находите новые библиотеки, компоненты, исправляете ошибки планирования
(максимум еще неделя из оставшегося).
Программисту трудно, наверное, сразу принять эту мысль. Бьет по самолюбию. Но все же, я ее озвучу: «Программист не растет над собой большую часть времени, затрачиваемого на разработку». Потому что реализацию проекта на стадии непосредственно кодирования трудно назвать ростом. Это набивание текста, это объяснение машине того, что в голове уже сформировано. Это не рост. А вот процесс формирования решения в голове – это рост.
Но специфика работы программиста такова, что тупой машине нужно долго объяснять что от нее требуется. Вы же не будете спорить, что объяснение ваших идей относительно решаемого проекта соседу-дилетанту – бездарная трата времени? Ну, хотя бы потому, что гораздо плодотворнее поговорить с собратом-специалистом – поймет он больше за гораздо меньшее время объяснения.
Так вот, компьютер – дилетант, которому все надо разжевать на понятном ему языке. Прибавьте еще исправление синтаксических ошибок, формирование четкого алгоритма…
И вот это время «разжевывания» - уходит от вас в прошлое навсегда.
Если вспомнить расчет, выполненный в прошлом выпуске, где я утверждал, что обычный человек имеет в своем личном активе только 30% всего времени своей жизни, и также учесть, что программист, как частный случай «обычного человека», на работе 50% времени тратит на объяснение тупому компьютеру элементарных вещей, то получится, что на самом деле «программист» - не очень выгодная профессия с точки зрения личного роста и наличия свободного времени. Если на чистоту говорить и не прятаться
от очевидных выводов.
Я думаю, что истина где-то рядом, потому что не даром все известные компании – производители сред разработки – конкурируют на поле автоматизации труда кодировщика.
Конечно, то, что программист работает с современными технологиями – своего рода компенсация. Ну, это результат вашего личного отношения к данному вопросу.
И все-таки, если соседу начать объяснять, через сколько минут захочется его послать подальше?
А ПК не посылаем. Потому что кормит.
Так вот, хотите получить обратно свои две недели из четырех? Станьте руководителем отдела. Тогда за вами будет только выработка решений. А кодированием пусть желающие занимаются.