Людей, разбирающихся в работе программиста, можно встретить где угодно
Людей, которые разбираются в работе программиста, можно встретить, где угодно. А заодно — и в работе бухгалтеров, менеджеров, кассиров, конструкторов и даже переворачивателей пингвинов. Эти парни любят абстракции даже больше, чем сами программисты.
Например, есть такая абстракция, как KPI. Еще Scrum. Канбан. Корпоративная культура. Soft skills. И т.д.
Понять работу программиста, а главное — пути повышения ее эффективности — эти люди пытаются через абстракции. Не изнутри профессии, а снаружи. Натягиваем сову на глобус Адаптируем абстрактную модель к профессии, и пытаемся чего-то понять и улучшить, исходя из правил модели.
Чтобы повысить эффективность работы программиста через Scrum, надо заставить его клеить стикеры и вставать на митапах. Так в методичке написано. В Канбане — переклеивать стикеры почаще. Чтобы сработала корп.культура, надо заставить программиста выучить гимн. Через soft skills — пусть учится говорить. И т.д.
Особо популярны три группы абстракций. Первая — методы серийного производства, вроде Канбана или даже конвейера. Рабочий, который годами точит одинаковые детали — тот же программист ведь, правда?
Вторая — методы проектного управления, вроде Scrum или Waterfall. Понятно, что вмешательство метода выглядит мягким — вроде, задачу ты решай по-программистски, а между задачами веди себя по-скрамовски. Но диффузия есть, в обе стороны. Что водопадный лозунг «уложись в срок», что скрамовский «а-а-а, херачим-херачим-херачим!» влияют на программирование «магически».
Третья — э-ге-гей-методы. Надо просто всех подружить, как в детском саду, шарики развесить, и код напишется. Ну, а чё.
Давайте с другой стороны зайдём. Не снаружи, из далеких галактик непонятных абстракций, а изнутри. Программистским умом поймём, как повысить эффективность работы программиста, и чем он должен заниматься. Это ненадолго, слишком всё просто, если ты изнутри.
Лучший метод повышения эффективности программиста — устранение потерь в процессе. В первую очередь, потерь времени. Потерь — колоссальное количество. До 97% времени, если честно.
Но их сложно увидеть, потому что ни фига не понятно, что это — потери. Вроде, сидит человек, работает, что-то делает, не лежит на кровати, не курит, не болтает о постороннем. Но, с высокой вероятностью, в данный момент он теряет время.
Или стоит на митапе, сидит на совещании, лежит на кушетке у штатного психолога, бежит по корпоративной беговой дорожке, или намертво зажат в массажном кресле. Полезно же?
Как стал бы классифицировать потери тот самый человек, разбирающийся в работе программиста? Не, не так — он вообще начал бы это делать? Конечно. Это ж такой Проектище. Диссертацию можно написать — «виды потерь времени программиста и способы устранения их влияния на финансовые, продуктивные и морально-этические результаты хозяйствования малого и среднего бизнеса в России эпохи перемен».
Всё намного проще, я думаю. Исходя из предположения, что потерь в нашей работе больше, чем полезной деятельности, проще понять, что есть «полезная деятельность», а всё остальное считать потерями. Также, как проще понять, кто такой здоровый человек, чем запомнить названия всех болезней.
Я предлагаю такую формулировку, для программиста: ты занят полезным делом, если пишешь уникальный код.
Просто, ёмко, и понятно. Всё остальное — либо явные, либо пока неявные потери.
Понятно, что это не стопроцентный фильтр, а, скорее, лакмусовая бумажка, выдающая спектр, степень, а не одну/две полоски. И, увы, вся перечисленная в преамбуле деятельность через этот фильтр не проходит.
Явные потери назвать легко. Например, мне неохота работать, и я пошел в соц.сеть ленту полистать. Или не могу решить, какой метод реализации выбрать, и иду погулять, а по дороге забываю, что хотел подумать о задаче, и возвращаюсь без решения. Или вообще лёг спать на работе. Или голова болит так, что разговаривать не могу, не говоря уже о программировании.
Явные потери — когда вы очевидно не делаете ничего, связанного с задачей. Правда, вам самому это не всегда очевидно, т.к. человек защищает сам себя перед самим собой. Ну, как курильщики доказывают всем и себе, что их ежечасные перерывы оказывают позитивное влияние на работу.
Неявные потери сложнее — мы привыкли считать их полезной деятельностью. Ну, или нас убедили, что без этого никак. Не справится программист без митапа, срока и разудалой песни. Часто потери скрываются за формулировкой «я сижу и думаю». Думаю над архитектурой решения, выбираю себе задачу, не могу решить, тумблер или флажок сделать, использовать готовую функцию с пред/постобработкой или написать свою, ищу примеры кода в интернете, шарюсь по зависимостям и т.д.
Всё это я делаю, потому что не могу писать уникальный код. Я встретил какое-то препятствие, не позволяющее мне начать или продолжить, и пытаюсь его преодолеть. Как правило, своими силами.
Если не делить свою деятельность на полезную и потери, то не получится наладить самоконтроль. Всегда будет казаться, что занят чем-то нужным и важным. И мне, и всем окружающим.
Такое определение полезной деятельности, как «ты пишешь уникальный код», всё сильно упрощает. Чем бы вы не занимались, всегда можете быстро ответить на вопрос, хрень это или что-то нужное.
Если вы пишете уникальный код — вы заняты делом. Прям пишете, сидя за компьютером, и стуча пальцами по клавиатуре.
Если вы не пишете уникальный код — что-то не так. Вы либо откровенно отвлеклись, либо застряли, либо вас затянули в очередное натягивание совы на глобус, чтобы потом премию получить и на конференс сгонять диссертацию защитить. И задача ваша чрезвычайно проста — как можно скорее вернуться к написанию уникального кода.
Да, вы заметили, наверное, что я постоянно повторяю слово «уникальный». Ну, понятно, если вы пишете код, который кто-то уже написал, и есть возможность этот код использовать, то вы теряете время.
Собственно, всё. Теперь вы в любой момент времени знаете, чем заняты. Либо дело делаете, либо время теряете.
Менеджеру своему этот текст покажите. Уж он-то придумает, как будут «писать уникальный код» бухгалтеры, кассиры, разнорабочие и переворачиватели пингвинов.
