Заметки посредственного специалиста из мира программирования о профессии

Kate

Administrator
Команда форума
Моя дебютная статья – набор всяческих мыслей, которые местами связаны друг с другом, местами не очень. Все они навеяны моим личным опытом и довольно субъективны. Поработать я успел только в продуктовых ИТ-компаниях, для других областей многое вероятно будет мимо.

илл. «О чем размышляют роботы?» — Жан-Пьер Пети
илл. «О чем размышляют роботы?» — Жан-Пьер Пети

Основная сложность​

Частый вопрос на собеседованиях – с какими самыми сложными задачами вы сталкивались на работе? И откровенно говоря, ни с какими – трудности ведь вовсе не в самих задачах, самые сложные из которых заканчиваются в институте или придумываются самостоятельно и без особой нужды. На работе они могут быть небольшими, а могут быть очень масштабными. При этом у среднестатистического разработчика, обывателя типа меня, они почти всегда простые, если не сказать рутинные. Трудность состоит не в том, чтобы их решить, а в том как. Как сейчас принять такие решения, о которых не придётся жалеть в будущем? Спойлер: среди них в любом случае будут плохие, независимо от того, как устроен процесс разработки, сколько времени уделяется на проектирование, сколько людей там задействовано и т. д.

В одиночных проектах, которые делаются по своей инициативе, такая проблема не стоит. Сделал плохо – не беда, можно переделать, даже заново. Я когда-то любил этим заниматься – начал, забросил, снова открыл, а там уже какая-то ерунда – кажется, будто бы сейчас можно сделать гораздо лучше. Бывало так, что потом уже в процессе понимал – «а, ну да, вспомнил, вот почему тут всё так на первый взгляд по-дебильному», ха-ха. А бывало, что и не понимал, и всё действительно становилось гораздо лучше – так сказать, раз на раз не приходится.

В совместной деятельности намного сложнее – чтобы поправить свою часть, бывает необходимо внести соответствующие изменения в чужие части, взаимодействующие с ней. Допустим, всё уже почти сделано, но вдруг я понял, что я могу сделать свою часть лучше. Это не отразиться на конечном результате, наши клиенты не заметят разницы. Единственное, что изменится от этого «улучшения» – мне дальше будет легче с ним работать. Возможно, моим коллегам будет легче, если они полезут в мой код. Правда, ради этого придётся переделать несколько методов из API, но его делаю не я.

Вот мой коллега, который занимается его разработкой. Я не могу распоряжаться его временем – я всего лишь простой разработчик, такой же как он. Максимум что я могу, предложить ему – «смотри, какая тема, ты можешь ещё разок сделать примерно то же самое, что ты уже сделал – наш совместный результат станет чуть лучше, хотя никто кроме нас этого не заметит». Не очень заманчиво звучит, правда? Я могу ввести своего коллегу в заблуждение, представив это чем-то необходимым. Я не хочу вводить его в заблуждение. Я могу попросить его, типа – «ну давай сделаем это, пожалуйста». Хотя, а оно мне надо? Кому оно вообще больше надо, мне или компании, на которую я работаю? Конечно же ей, жалко только, что она этого не сможет понять.

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

Святая вера​

В начале пути волнуют зарплата / доход, условия труда, применимость своего опыта и т. п. Да и потом не перестают волновать, однако, чем взрослее я становлюсь, тем больше беспокоит, чем именно я занимаюсь. Не с технической точки зрения, а вообще – что из себя представляет проект? Нравится ли он мне? Способен ли он вызвать у интерес у меня, как у постороннего для компании человека? Вижу ли я в нём пользу? Стал бы я его пользователем? А если стал бы, была бы в этом заслуга компании или скорее воля случая?

Примерно такая же воля случая, которой можно устроиться на работу. Мы так привыкаем с детства быть частью чего-то, во что мы не верим, что во взрослом возрасте это кажется совершенно естественным. Вот мои родители – я их не выбирал, они такие мне достались. Вот моя школа – не я её выбрал, меня туда отдали родители. Вот мой институт, хоть я и выбрал его, но по факту я не знал, чем они отличаются. Вот моя компания – я сам её выбрал. Я смогу там прокормиться, чем она занимается – мне не так уж важно. Я знаю, что она воспринимает меня примерно похожим образом. Это классика жизни.

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

Осознание того, этим придётся заниматься по 8 часов 5 дней в неделю, вообще делает это невозможным, прямо с порога – руки не то чтобы опускаются, они даже хотят подниматься. По ТК РФ 40 часов – это максимальная продолжительность рабочей недели. Однако, почему-то работодатели свято верят в то, что это ограничение должно действовать в обратную сторону тоже – эдакая норма, стандарт, меньше не катит. Если биться – то только насмерть, если покупать кофе в ларьке – то 500 мл, и никак не меньше.

Да и вряд ли снова появится коммунисты и заведут серьёзные разговоры о законодательном уменьшении продолжительности рабочего дня. Просто ситуация уже не та, ограничение то на самом деле искусственное – я лично вообще за то чтобы его убрать. Закон не должен заниматься такими вещами. Если человек сам хочет работать, пусть хоть по 14 часов в сутки без выходных – зачем ему в этом мешать?

Смена не кончится​

Программирование – штука творческая в том плане, что задачи решаются разными путями. Тут полно таких, на выполнение которых можно потратить пару часов, получив вполне сносный результат. А можно потратить пару дней, и получить результат чуть получше. Делая графику, можно использовать CanvasRenderingContext2D, а можно заморочиться, и использовать WebGL. Делая парсер, можно реализовать его «в лоб», а можно заморочиться и отделить грамматику от кода. На худой конец, делая любую программу, можно сразу писать код, а можно начинать с алгоритма. Какой путь решения выбирать?

Если я что-то делаю сам для себя, у меня естественным образом работает принцип: чем быстрее – тем лучше. Мне есть куда спешить, быстрее закончу – быстрее смогу пользоваться результатами своего труда. Быстрее стану свободен. Даже такой порок как «лень» здесь идёт на пользу. Ничего не нужно выдумывать, чтобы выдерживать баланс между качеством и скоростью работы, это делается на автопилоте.

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

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

Невидимый спрос​

Когда пытаешься выйти за пределы, так сказать, своего мультипериметра – то есть начать собственное дело, большое или маленькое, первый вопрос, с которым сталкиваешься – а чем, собственно, заниматься? Тут три полюса – либо тем, что очень сложно или даже нереализуемо, либо тем, что не востребовано. Либо тем, что уже было сделано раньше, рассчитывая, что очередная версия окажется чем-то лучше.

Страшно подумать, сколько делается и сколько уже сделано всякого рода велосипедов в различных компаниях, многие из которых никогда не попадут в open-source. Причина их появления не в отсутствии предложения, а в невозможности узнать спрос. Я могу воспользоваться поиском, посмотреть, сделал ли кто-нибудь библиотеку для моего языка программирования, которая, например, реализует протокол SIP. Но я почти ничего не могу узнать о том, сколько людей бы хотели такую библиотеку, кому бы она могла пригодиться. Хотя это довольно важный вопрос. Поэтому, даже если она вдруг оказалась нужна мне самому, и я обнаружил, что её пока не существует – мне предстоит выбор. То ли заняться ей, то ли вообще отказаться от протокола SIP в пользу чего-то другого.

Надеюсь, когда-нибудь у сообщества появится что-нибудь наподобие wishlist’а такого рода (может уже есть, и я не в курсе?).

Куда приводит инерция​

Был я в одной компании, где все задачи, все комментарии к ним и к коду были на английском языке. Компания была небольшая, а родным языком для всех её сотрудников был русский. Я, было дело, попытался узнать – а как так произошло то? «Да работал у нас тут один человек пару лет назад – он предложил, давайте писать всё на английском – дескать, потом с англоязычными сотрудниками легче будет – так и повелось» – примерно так звучал ответ. Тот человек уже давно уволился, между собой все говорили по-русски. Описания задач, документация и т. п. по-прежнему писались на только на одном языке – английском. Никаких англоязычных сотрудников так и не появилось. Но дело даже не в этом.

Это очень милая идея, что когда-нибудь весь мир вдруг заговорит на одном языке – она мне тоже нравится. Да вот незадача, чтобы это когда-нибудь воплотилось в жизнь – нам, тем, для кого этот язык неродной, придётся куда-то из этого мира исчезнуть.

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

The end​

Смотрю на название статьи, и думаю – как и в какой момент я всё-таки умудрился стать посредственным? Наверное, в один из тех, когда программирование превратилось из развлечения и хобби в способ заработка денег. Нет страсти к этому процессу – тяжело было её не растерять в такой ситуации, да и ладно.

В какой-то момент просто смиряешься с тем, что программирование – лишь средство, инструмент для решения различных проблем. И уже становится не с кем поспорить, на тему того, какой язык программирования лучше. Уже не с кем посмеяться над оператором «PLEASE DO». Уже некому пожаловаться на каскад из define’ов, в глубине которого была какая-то чертовщина без комментариев. Остаётся только вообразить себя эдаким стэндап-комиком и ждать, пока кто-нибудь скажет – «ну да, жизненно, так и есть».

 
Сверху