Моя дебютная статья – набор всяческих мыслей, которые местами связаны друг с другом, местами не очень. Все они навеяны моим личным опытом и довольно субъективны. Поработать я успел только в продуктовых ИТ-компаниях, для других областей многое вероятно будет мимо.
Основная сложность
Частый вопрос на собеседованиях – с какими самыми сложными задачами вы сталкивались на работе? И откровенно говоря, ни с какими – трудности ведь вовсе не в самих задачах, самые сложные из которых заканчиваются в институте или придумываются самостоятельно и без особой нужды. На работе они могут быть небольшими, а могут быть очень масштабными. При этом у среднестатистического разработчика, обывателя типа меня, они почти всегда простые, если не сказать рутинные. Трудность состоит не в том, чтобы их решить, а в том как. Как сейчас принять такие решения, о которых не придётся жалеть в будущем? Спойлер: среди них в любом случае будут плохие, независимо от того, как устроен процесс разработки, сколько времени уделяется на проектирование, сколько людей там задействовано и т. д.
В одиночных проектах, которые делаются по своей инициативе, такая проблема не стоит. Сделал плохо – не беда, можно переделать, даже заново. Я когда-то любил этим заниматься – начал, забросил, снова открыл, а там уже какая-то ерунда – кажется, будто бы сейчас можно сделать гораздо лучше. Бывало так, что потом уже в процессе понимал – «а, ну да, вспомнил, вот почему тут всё так на первый взгляд по-дебильному», ха-ха. А бывало, что и не понимал, и всё действительно становилось гораздо лучше – так сказать, раз на раз не приходится.
В совместной деятельности намного сложнее – чтобы поправить свою часть, бывает необходимо внести соответствующие изменения в чужие части, взаимодействующие с ней. Допустим, всё уже почти сделано, но вдруг я понял, что я могу сделать свою часть лучше. Это не отразиться на конечном результате, наши клиенты не заметят разницы. Единственное, что изменится от этого «улучшения» – мне дальше будет легче с ним работать. Возможно, моим коллегам будет легче, если они полезут в мой код. Правда, ради этого придётся переделать несколько методов из API, но его делаю не я.
Вот мой коллега, который занимается его разработкой. Я не могу распоряжаться его временем – я всего лишь простой разработчик, такой же как он. Максимум что я могу, предложить ему – «смотри, какая тема, ты можешь ещё разок сделать примерно то же самое, что ты уже сделал – наш совместный результат станет чуть лучше, хотя никто кроме нас этого не заметит». Не очень заманчиво звучит, правда? Я могу ввести своего коллегу в заблуждение, представив это чем-то необходимым. Я не хочу вводить его в заблуждение. Я могу попросить его, типа – «ну давай сделаем это, пожалуйста». Хотя, а оно мне надо? Кому оно вообще больше надо, мне или компании, на которую я работаю? Конечно же ей, жалко только, что она этого не сможет понять.
Я могу сказать об этой ситуации нашему общему руководителю. Если я предложу ему выбор, скорее всего, максимум, что он сделает – переадресует этот выбор моему коллеге. Фанаты рефакторинга встречаются редко, поэтому в разработке ошибки из прошлого обычно тянутся в будущее. Есть причины позавидовать людям тех профессий, работа которых не то чтобы продолжается изо дня в день, а скорее начинается заново.
Святая вера
В начале пути волнуют зарплата / доход, условия труда, применимость своего опыта и т. п. Да и потом не перестают волновать, однако, чем взрослее я становлюсь, тем больше беспокоит, чем именно я занимаюсь. Не с технической точки зрения, а вообще – что из себя представляет проект? Нравится ли он мне? Способен ли он вызвать у интерес у меня, как у постороннего для компании человека? Вижу ли я в нём пользу? Стал бы я его пользователем? А если стал бы, была бы в этом заслуга компании или скорее воля случая?
Примерно такая же воля случая, которой можно устроиться на работу. Мы так привыкаем с детства быть частью чего-то, во что мы не верим, что во взрослом возрасте это кажется совершенно естественным. Вот мои родители – я их не выбирал, они такие мне достались. Вот моя школа – не я её выбрал, меня туда отдали родители. Вот мой институт, хоть я и выбрал его, но по факту я не знал, чем они отличаются. Вот моя компания – я сам её выбрал. Я смогу там прокормиться, чем она занимается – мне не так уж важно. Я знаю, что она воспринимает меня примерно похожим образом. Это классика жизни.
Сознательно понимаю, что самому живётся легче и лучше, когда непосредственная выгода имеет приоритет, затмевая остальное. Только есть проблема – в такой ситуации очень сложно заставить себя работать – просто неинтересно. Даже за приличные деньги, даже в приятном коллективе.
Осознание того, этим придётся заниматься по 8 часов 5 дней в неделю, вообще делает это невозможным, прямо с порога – руки не то чтобы опускаются, они даже хотят подниматься. По ТК РФ 40 часов – это максимальная продолжительность рабочей недели. Однако, почему-то работодатели свято верят в то, что это ограничение должно действовать в обратную сторону тоже – эдакая норма, стандарт, меньше не катит. Если биться – то только насмерть, если покупать кофе в ларьке – то 500 мл, и никак не меньше.
Да и вряд ли снова появится коммунисты и заведут серьёзные разговоры о законодательном уменьшении продолжительности рабочего дня. Просто ситуация уже не та, ограничение то на самом деле искусственное – я лично вообще за то чтобы его убрать. Закон не должен заниматься такими вещами. Если человек сам хочет работать, пусть хоть по 14 часов в сутки без выходных – зачем ему в этом мешать?
Смена не кончится
Программирование – штука творческая в том плане, что задачи решаются разными путями. Тут полно таких, на выполнение которых можно потратить пару часов, получив вполне сносный результат. А можно потратить пару дней, и получить результат чуть получше. Делая графику, можно использовать CanvasRenderingContext2D, а можно заморочиться, и использовать WebGL. Делая парсер, можно реализовать его «в лоб», а можно заморочиться и отделить грамматику от кода. На худой конец, делая любую программу, можно сразу писать код, а можно начинать с алгоритма. Какой путь решения выбирать?
Если я что-то делаю сам для себя, у меня естественным образом работает принцип: чем быстрее – тем лучше. Мне есть куда спешить, быстрее закончу – быстрее смогу пользоваться результатами своего труда. Быстрее стану свободен. Даже такой порок как «лень» здесь идёт на пользу. Ничего не нужно выдумывать, чтобы выдерживать баланс между качеством и скоростью работы, это делается на автопилоте.
Когда я что-то делаю для других, этот принцип необязательно будет работать. Бывает так, что компания платит разработчику за то, что он «присутствует на рабочем месте» – это довольно точная формулировка. Бывает ситуация, когда компания пытается купить его время работы, или, что ещё более странно – он сам вполне искренне пытается его продать. Кстати, я тоже когда-то верил в то, что это возможно. Спойлер: разработчик – не кассир и не рабочий у конвейера. Конечно, торговать его временем тоже возможно, но торговать временем, затраченным на разработку – сомнительно.
Когда одну и ту же задачу можно решить за сильно разные временные отрезки, и в зависимости от ситуации все варианты уместны, и платят только за потраченное время – одному богу известно, как будут взаимосвязаны скорость и качество результата. Насколько бы исполнитель не был порядочен, он не робот – его собственная интуиция просто не сможет делать оптимальный выбор, поскольку личные корыстные интересы будут в противоречии с интересами заказчика.
Невидимый спрос
Когда пытаешься выйти за пределы, так сказать, своего мультипериметра – то есть начать собственное дело, большое или маленькое, первый вопрос, с которым сталкиваешься – а чем, собственно, заниматься? Тут три полюса – либо тем, что очень сложно или даже нереализуемо, либо тем, что не востребовано. Либо тем, что уже было сделано раньше, рассчитывая, что очередная версия окажется чем-то лучше.
Страшно подумать, сколько делается и сколько уже сделано всякого рода велосипедов в различных компаниях, многие из которых никогда не попадут в open-source. Причина их появления не в отсутствии предложения, а в невозможности узнать спрос. Я могу воспользоваться поиском, посмотреть, сделал ли кто-нибудь библиотеку для моего языка программирования, которая, например, реализует протокол SIP. Но я почти ничего не могу узнать о том, сколько людей бы хотели такую библиотеку, кому бы она могла пригодиться. Хотя это довольно важный вопрос. Поэтому, даже если она вдруг оказалась нужна мне самому, и я обнаружил, что её пока не существует – мне предстоит выбор. То ли заняться ей, то ли вообще отказаться от протокола SIP в пользу чего-то другого.
Надеюсь, когда-нибудь у сообщества появится что-нибудь наподобие wishlist’а такого рода (может уже есть, и я не в курсе?).
Куда приводит инерция
Был я в одной компании, где все задачи, все комментарии к ним и к коду были на английском языке. Компания была небольшая, а родным языком для всех её сотрудников был русский. Я, было дело, попытался узнать – а как так произошло то? «Да работал у нас тут один человек пару лет назад – он предложил, давайте писать всё на английском – дескать, потом с англоязычными сотрудниками легче будет – так и повелось» – примерно так звучал ответ. Тот человек уже давно уволился, между собой все говорили по-русски. Описания задач, документация и т. п. по-прежнему писались на только на одном языке – английском. Никаких англоязычных сотрудников так и не появилось. Но дело даже не в этом.
Это очень милая идея, что когда-нибудь весь мир вдруг заговорит на одном языке – она мне тоже нравится. Да вот незадача, чтобы это когда-нибудь воплотилось в жизнь – нам, тем, для кого этот язык неродной, придётся куда-то из этого мира исчезнуть.
Я понимаю далеко не все слова, но могу читать по-английски. Я даже могу что-то писать и говорить так, чтобы меня понимали. Но я не буду делать вид, что мне это даётся легко, что в моей речи не будет ошибок. Нет, это требует гораздо больших усилий по сравнению с родным языком. Вы уж лишний раз не стреляйте в ногу сами себе – не стоит прогибаться под этих мифических иностранцев, ну хотя бы в тех случаях, когда вы их просто выдумали, и рядом их нет.
The end
Смотрю на название статьи, и думаю – как и в какой момент я всё-таки умудрился стать посредственным? Наверное, в один из тех, когда программирование превратилось из развлечения и хобби в способ заработка денег. Нет страсти к этому процессу – тяжело было её не растерять в такой ситуации, да и ладно.
В какой-то момент просто смиряешься с тем, что программирование – лишь средство, инструмент для решения различных проблем. И уже становится не с кем поспорить, на тему того, какой язык программирования лучше. Уже не с кем посмеяться над оператором «PLEASE DO». Уже некому пожаловаться на каскад из define’ов, в глубине которого была какая-то чертовщина без комментариев. Остаётся только вообразить себя эдаким стэндап-комиком и ждать, пока кто-нибудь скажет – «ну да, жизненно, так и есть».
Комментарии (90)
anonymous
00.00.0000 00:00
Gorthauer87
27.08.2021 18:13Ну вот мне нравится работать молотком, но не нравится перфоратором. А если я, допустим, скульптор, то моя работа молотком принципиально другой результат дает, чем если бы я просто гвозди забивал. То есть аналогия вообще никакая и не учитывает вообще ничего.
А умение получать удовольствие от процесса позволяет избавиться от пустоты в момент, когда в очередной раз сделал нечто в стол.
0xd34df00d
27.08.2021 20:40+7Именно поэтому фраза "мне нравится программировать" — это либо лукавство, либо неопытность. Потому что молотки могут нравиться по сравнению с другими молотками как они быстрее забивают или лучше лежат в руке, но не забиванием гвоздей. Этот процесс всегда одинаковый. И он всегда приводит к готовому изделию с гвоздями.
Можете развернуть эту мысль? Просто, ну, мне действительно нравится программировать, и я это делаю не то чтобы совсем недавно.
А вот готовые изделия мне не нравятся, к слову.
major-general_Kusanagi
27.08.2021 21:27+7фраза «мне нравится программировать» — это либо лукавство, либо неопытность
мне действительно нравится программировать, и я это делаю не то чтобы совсем недавно
Автор — просто очередной Вайт-В-АйТишник считающий, что ему должны платить не за профессионализм, а за садомазохистское протирание штанов по 14 часов в сутки на НЕНАВИСТНОЙ ему работе. И если тупые менеджеры измеряют работу усталостью, то у автора мерилом работы служат СТРАДАНИЯ, и он абсолютно не понимает что такое любимая работа и как это любить программирование.
PS программированием занимаюсь 33 года, и я пошёл в эту профессию потому что люблю программировать, и 33 года назад программист не зарабатывал круто, а был всего лишь обычным советским «инженеришкой» с очень скромной зарплатой.major-general_Kusanagi
28.08.2021 11:23-1Офигеть! Как (при плюсах за комментарий) Вайти-В-АйТишники НЕНАВИДЯЩИЕ ПРОГРАММИРОВАНИЕ мне за ночь карму слили!
lxsmkv
27.08.2021 14:52+4Мне кажется, что задача программиста оставить программу в лучшем состоянии чем она была до этого. Не нужно искать сверхцелей.
Вот я сейчас сижу над окаменелостью пятилетней давности, и моя основная задача, как я ее себе вижу - снизить технический долг, снизить стоимость дальнейшей разработки. А отсюда уже проистекают мои технические решения - рефакторинг, упрощение, дизайн интерфейсов, так чтобы человеку неподготовленному было легко въехать в устройство всей этой котовасии. Чтобы меня можно было заменить студентом, а я пойду "разрыхлять" следующую окаменелость или проектировать и сажать новый сад, если это "проект с чистого листа".
kibizoidus
27.08.2021 15:03-12Задача программиста - решить конкретную задачу. Все. Точка. Извините за тавтологию.
Все эти "лучше чем предыдущий", "чтоб не было стыдно", "чтоб мама похвалила" - это все бред собачий, простите.lxsmkv
27.08.2021 15:45+4Это "дискретное", "механистическое" видение. Оно рассматривает человека как функцию. Оставляя за скобками то, к чему вы стремитесь в перспективе. Т.е. закончив одну задачу вы будете ждать следующую, а если их нет, то и ладно. Так работают большинство. И потом немало из них страдают выгоранием, потому что задачи в большом отдалении, впринципе, одинаковые, а личного стремления, "вектора", никакого нет. И тебя в один момент захлестывает ощущение бессмысленности твоего труда. Если спросить себя: "К какой личной цели меня приближает выполнение этой задачи?", то многие не смогут на этот вопрос ответить, или скажут, "к зарплате 30 числа".
Moжно решать конкретные задачи. Тогда за жизнь вы решите много конкретных задач. Но оглядываться на такую жизнь мне было бы очень досадно. Гораздо приятней оглядываться на, то сколько песчинок добра ты оставил в мире, скольким людям помог, хотя бы тем, что ты просто был самим собой. Я уже как-то приводил отсылку к этой притче: один кладет камни, другой строит храм.
Убедить я Вас в этом конечно, не смогу, да и не пытаюсь, но возможно Вас самого посетят похожие мысли, со временем, при определенных обстоятельствах.
Желаю Вам меньше "бреда собачьего" в решении Ваших конкретных задач.kibizoidus
27.08.2021 16:29-5О, как вы филигранно вмешали меня лично в канву обсуждения и перешли на личности. И уже наделали выводов о моей профессиональной пригодности. Браво.
Желаю вам никогда не повторять текущей ошибки и обсуждать проблему, а не личностей, втянутых в обсуждение.lxsmkv
27.08.2021 17:04+2Прошу прощения, если задел, я от всего сердца пожелал Вам удачи в решении профессиональных задач. Да, в интеренете такие откровенности неприняты, и расцениваются как "троллинг". (Хотя и это искреннее извинение можно расценить как троллинг, но тут уж я бессилен)
По жизненному опыту я знаю, что убедить какого бы то ни было человека сменить жизненную позицию практически невозможно, если он сам этого не хочет. Поэтому я и сделал эту оговорку, что не хочу давить на вас своим мнением.
А что до профессиональных качеств, то я о них не судил. Но, раз уж зашла речь, у меня нет никаких сомнений, что вы эффективно справляетесь с поставленными задачами, если, конечно, придерживаетесь представленной вами парадигмы.
К сожалению, выделяя достоинства какого-то ракурса, всегда невольно и незаслуженно "обижаешь" тех кто видит мир иначе. Еще раз прошу прощения. Будет мне урок, надеюсь.kibizoidus
27.08.2021 17:17-1Принято.
С точки зрения пространных философствований механистическое мышление в союзе с правильной декомпозицией приносит конкретные результаты, даже если вы механистически выполняете четко поставленную задачу или задачи в их строгих пределах. Именно это - главный навык ремесла программирования. Это вот то, что все обсуждают здесь под видом "видеть подводные камни", "продумывать на пять шагов вперед", "писать расширяемый код" - это все выполнение конкретных маленьких задач, которые при правильной декомпозиции складываются в одну большую задачу "сделать хорошо".И ваш аргумент про "зарплату 30 числа" - это, как раз таки, отсутствие поставленной перед собой задачи.
lxsmkv
27.08.2021 18:36Ну да, если так посмотреть, то я тоже не "от балды" перекапываю код, а составил себе список проблемных тем, и почему их надо исправить, и что будет если их не исправить. Т.е. любое изменение кода ложится на один этих пунктов. А в конце должно стать "хорошо". Только не все из этих целей можно достигнуть одним рывком, к некоторым приближаешься по капельке, делая правки по ходу, "тут и сям", когда на глаза попадаются.
dolovar
27.08.2021 15:58+6Задача программиста — решить конкретную задачу. Все. Точка. Извините за тавтологию.
Если пройти немного дальше, то получится:
Все эти «лучше чем предыдущий», «чтоб не было стыдно», «чтоб мама похвалила» — это все бред собачий, простите.Задача сотрудника — обеспечить предприятие прибылью. Все. Точка. Извините за тавтологию.
Но нужно ли начинать идти по этому пути?
Все эти «профессиональные навыки», «профессиональная этика», «самоуважение» — это все бред собачий, простите.kibizoidus
27.08.2021 16:27-6А вы не ходите "немного дальше" и не путайте божий дар с яичницей. Хороший код - тот, который работает и выполняет задачу в данных условиях.
mSnus
27.08.2021 16:30+8..и который потом удобно, если что, расширять и поддерживать..
kibizoidus
27.08.2021 16:35Снова таки, если перед кодом стоит доп. задача быть расширяемым и поддерживаемым. Это такая же задача, как и все остальные.
dolovar
27.08.2021 16:44+4если перед кодом стоит доп. задача быть расширяемым и поддерживаемым. Это такая же задача, как и все остальные.
ТЗ идеальны только в идеальных мирах, содержат все возможные подзадачи и ограничения. В нашем же мире хороший программист не бросается выполнять задачу, а уточняет контекст, чтобы достроить картину необходимыми условиями и приоритетами.
Да и в идеальных мирах ТЗ наверняка оставляют программистам свободу решений, которые должны основываться на опыте и здравом смысле (иначе робот заменяет человека). И здравость смысла — это именно то, что выходит за рамки «просто реши поставленную задачу».kibizoidus
27.08.2021 16:49-1Вы мне пытаетесь доказать то, чего сами не видите в моих словах. "Решать конкретную задачу / задачи" - это, в том числе, и то, что вы описали. Быть расширяемым, красивым, модульным, в контексте, по ТЗ или с "плюшками" - это все задачи. Конкретные задачи куска кода. Не находите, что в таком случае ваши пространные рассказы о здравом смысле так же прекрасно ложатся в строку "решать конкретную задачу"?
dolovar
27.08.2021 16:53+2Не находите, что в таком случае ваши пространные рассказы о здравом смысле так же прекрасно ложатся в строку «решать конкретную задачу»?
Не нахожу, не только в этом случае, не пространные, не ложатся.
Начало треда — только решать, прочее бред собачий — сюда никак не ложится здравый смысл и подзадачи, которые в ТЗ отсутствовали и вообще появились только после запуска, когда назрели, а не в момент решения исходной задачи. И именно «чтобы не стыдно было» и «чтобы мама гордилась» — это то, что позволяет минимизировать расходы на то, что произойдет после «просто решил».kibizoidus
27.08.2021 17:00-1А вот в этом как раз и состоит основная ценность хорошего программиста - расширять круг задач конкретного куска кода в зависимости от контекста. Если задача есть в контексте, даже воображаемом, но не решена, и программист ее не обозначил и не решил - возникают проблемы. Именно об этом я и пытаюсь сказать. И даже в этом случае код должен будет просто выполнять свою задачу.
saboteur_kiev
27.08.2021 23:27+2Именно об этом я и пытаюсь сказать
Нет, вы сказали что выполняет свою задачу и Точка.
А теперь оказывается, что разные программисты ставят точки в разных местах, и от того, где именно программист поставит точку в определении условий задачи, зависит и его ценность и квалификация. То есть сейчас вы говорите полностью противоположное своему первому изречению.
kibizoidus
28.08.2021 03:32-1Отделяйте код от программиста, пожалуйста. Мухи - отдельно, котлеты - отдельно. Ваш код - не ваше достояние и ценность, ценно то, что делает этот код.
DMGarikk
27.08.2021 16:45+1зачастую эта доп. задача стоит всегда. и вам как программисту надо об этом знать, а также помнить что менеджеры зачастую не в полной мере осознают её необходимость и зачастую голосом никогда её не поставят и будут потенциально неодобрять её поскольку она затягивает сроки
Я сталкивался с таким подходом, когда задачи берутся и выполняются атомарно без попыток анализа окружения. буквально как менять колеса и красить дверь у автомобиля который уже на грузовике едет на пресс.
Это полный пи… ц, и если это не учитывать то ваше развитие навсегда останется на уровне рядового кодера.kibizoidus
27.08.2021 16:53-2Встанет эта доп. задача в приоритеты выполнения или нет - в канве обсуждения уже не так важно, важно что это такая же задача, как и все остальные, и никак не противоречит постулату выше о том, что код должен выполнять свои задачи. Те, которые перед ним поставили. Ни больше - ни меньше.
dolovar
27.08.2021 16:57+1код должен выполнять свои задачи. Те, которые перед ним поставили. Ни больше — ни меньше.
Перед кодом поставили задачу — два на первом входе, два на втором входе, выдать на выход сумму. Программист решил задачу. Точка.
Через неделю стартап загнулся, потому что код оказался ненадежным, нетранспортабельным, отсутствовала сигнализация о сбоях, платформа была выбрана неподходящей для нагрузки…
Программист разводит руками — ну надо же было поставить такие подзадачи, я бы решил.
Ему — тебе не стыдно?
Он в ответ — бред собачий, моё дело только решать поставленные задачи.kibizoidus
27.08.2021 17:03-2Т.е. перед кодом стояла задача быть расширяемым, надеждым, включать сигнализацию о сбоях под нагрузкой, так? Задачи были, но не решились. Так?
DMGarikk
28.08.2021 21:50+1очень нечасто попадаются места работы где у вас будет полный комплект в команде, техписатели, аналитики, постановщики задачи, тимлид, техлид, рук.проекта, продактовнеры (понимающие в ИТ и вообще что программисты делают).
собственно если вы будете писать код «как заказано так и сделано» то вас… ну не уволят наверное но ваш скилл будет оцениваться гораздо ниже
dolovar
27.08.2021 16:34не путайте божий дар с яичницей
В данном случае Вы свой вердикт «бред собачий» сравниваете с божьим даром или с яичницей?решить конкретную задачу. Все. Точка.
Если программист будет выполнять свою задачу, забив на всё, кроме «решить», то ничего хорошего из этого не выйдет. Помимо «решить» есть немаловажное «когда» и архиважное «как». Работа программиста, как и любого другого специалиста, состоит из компромиссов между «быстро», «дешево» и «качественно», и выбор того или иного пути решения — вот что отделяет хорошего программиста от плохого. Мало просто решать задачи.kibizoidus
27.08.2021 16:40Пока программист из Вилларибо думал, как лучше ему спроектировать высоконагруженную опердень для миллиона будущих клиентов - его коллега из Виллабаджо уже выпустил забагованный прототип, собрал первых клиентов и фидбек и съел рынок...
dolovar
27.08.2021 16:46+2Преждевременная оптимизация — одна из возможных крайностей. Противоположная ей крайность ничуть не лучше и на практике тоже зачастую позволяет профукать рынок (который состоит не только из быстрорастущих стартапов). Поэтому лучше стремиться не к крайностям, а к разумному балансу между ними.
kibizoidus
27.08.2021 16:54-1И, снова же, все это прекрасно систематизируется и укладывается в конкретные и четко поставленные задачи перед кодом. Которые можно так же обсуждать, выверять приоритеты, доказывать их необходимость и жизненную важность и т.д. и т.п.
Все это никак не противоречит тому, что код должен выполнять свою задачу.DMGarikk
28.08.2021 21:52+1И, снова же, все это прекрасно систематизируется и укладывается в конкретные и четко поставленные задачи перед кодом
чтобы это так было, надо потратить кучу времени чтобы вам ТЗ написать, а этого времени почти никогда нет.
это всеравно что автослесарю объяснять с каким моментом гайки затягивать, масло после работы протереть и временно отключенные провода назад в правильном порядке подключить… а то вы приедете колеса менять, а вам выдадут полуразобранное авто со словами «ну мы колеса поменяли, а за остальное вы нам не платили и вообще не упоминали»
DMGarikk
27.08.2021 16:48а это не значит что надо начать *омно в прод выпускать.
тАкже, не все вокруг работают в стартапах который только только с нуля написали продукт
ZhetoN
27.08.2021 18:17+1проект, в котором сейчас работаю, как в том мультике - Полезных ископаемых нет (свой фреймворк поверху ангуляра, все стандартные подходы в основном не работают). Воды (тестов) нет. Растительности (каждая сепулька как npm библиотека) нет. Населена роботами (в основном багами). И вот 95% разработчиков в основном занимаются тем что чинят друг за другом, т.к. "решение конкретной задачи" в большинстве случаев ломает какую-нибудь другую "конкретную задачу", потому что там тоже не думали а "решали". Так что полностью согласен с автором статьи, нужно просто проинформировать руководителя, он же должен лучше разбираться, пусть и решает нужен ли рефакторинг.
0xd34df00d
27.08.2021 20:50+1Это задача программиста в глазах менеджера.
Моя задача в моих глазах — максимизировать интеграл удовольствия по жизни. Я получаю удовольствие от обмазывания плюсовыми темплейтами — я это и делаю (возможно, ища работу, где я мог бы применить эти навыки). Получаю удовольствие от низкоуровневой оптимизации кода — занимаюсь этим (возможно, ища работу… ну вы поняли). Начал получать удовольствие от обмазывания пруверами — начал это делать. Работу пока найти не смог, где за это бы платили, правда.
Я просто занимаюсь интересными мне задачами, попутно стараясь часть из них монетизировать, находя людей, у которых есть проблемы, приводящие к аналогичным задачам. Но только часть — личный опенсорс, который я не буду монетизировать никогда, и где мне уже довольно давно плевать на применимость саму по себе, у меня был всегда.
Можете считать меня непрограммистом, постараюсь это как-нибудь пережить.
mangoodan
27.08.2021 18:17+2Одно только проблема — понимание простоты, техдолга и окаменелости меняется с опытом. Много раз меняется. Спустя свои 18 лет опыта я так и не знаю достиг ли просветления в этом.
lxsmkv
27.08.2021 18:56А разве такая вещь как стандартизация, не безусловное "добро"? Когда мы проводим "нормализацию" и из спагетти-кода, он приближается к той парадигме в которой был создан фреймворк, разве это не "благородная" цель? Когда улучшается его читаемость, улучшается производительность?
Хотя я уверен, если как следует надавить на любого, самого добронамеренного разработчика, он тоже начнет "фигачить" как будто "завтрашний день уже не наступит". И в этих обстоятельствах, его, пожалуй, будет не в чем упрекнуть (кроме как в том, что не еще не свалил с этих адских галер).
zynaps76
27.08.2021 15:20+3Если человек сам хочет работать, пусть хоть по 14 часов в сутки без выходных – зачем ему в этом мешать?
Затем, что очень не хочется лететь с пилотами находящимися за штурвалом 14 часов. И не хочется ехать в таком же такси. И к хирургу такому тоже не хочется.... Ну и не хочется пользоваться онлайн банком / автопилотом, где разрабы уже "ничего" не соображали пока код фигачили. :-)
И уже становится не с кем поспорить, на тему того, какой язык программирования лучше.
Потому, что.... его нет? :)
dvoeglazyi Автор
27.08.2021 17:47+1Всё так, профессия профессии рознь. Именно поэтому вероятность попасть к такому пилоту небольшая. А вероятность попасть к такому таксисту всё же есть - если он сам захочет, вряд ли ему получится помешать. Но причин для какой-то универсальной нормы про 40 часов в неделю для всех я не вижу. Самому мне и по 8 часов в день как-то не особо программируется.
Потому, что.... его нет? :)
Да, да. Потому что его нет... не языка, а того, с кем можно поспорить :)
zynaps76
27.08.2021 22:07+3Вот, поэтому и ограничивают. Разреши 14 часов и ура, шанс встретить такого таксиста будет близится к 100%. Это раз, а еще work/life баланс. Дети/разводы, опять же. Здоровье - туда же. И еще список из овердофига пунктов.
Впрочем, если все это не парит - регайте ИП: контрактная работа и хоть 24, хоть ноль часов в сутки в ай ти. сами себе хозяин и никаких ограничений. ;-)
0xd34df00d
27.08.2021 22:27+1Разреши 14 часов и ура, шанс встретить такого таксиста будет близится к 100%.
Я таксистов выбираю не по тому, сколько они работают (не выспаться можно и при восьмичасовом дне), а по отзывам. По факту при работе с убером у них может быть произвольно большой рабочий день.
Это раз, а еще work/life баланс. Дети/разводы, опять же. Здоровье — туда же. И еще список из овердофига пунктов.
Надо запретить заниматься хобби, связанными с работой, в личное время, ящетаю. Тем более, что в ряде стран в Европе на контрибьюшены в рабочие или околорабочие проекты, сделанные в личное время, и так смотрят очень косо.
zynaps76
27.08.2021 22:47+2Ну каммон, хобби - смена деятельности, а это лучший отдых. Мне кажется, довольно странным хобби в закрытии рабочих тасков бесплатно, но мало ли странных хобби. Все остальное - нормально. Не?
TokarLimadze
28.08.2021 18:55+1вероятность попасть к такому пилоту небольшая.
Да не такая уж и маленькая. А с таксистом так просто высокая - чтобы выйти на 60/мес. надо "от заката до рассвета".
mSnus
27.08.2021 16:32+3Вообще нормальный человек вполне может работать 8 часов, но программировать день за днём по 8 часов подряд -- это, мне кажется, быстрый путь к выгоранию. Реально -- часа 4 в день, остальное на текучку, совещания, саморазвитие,
аджайл, скрам, бигдата
anonymous
00.00.0000 00:000xd34df00d
27.08.2021 20:52+3Почему среднего возраста? Это становится понятно сразу, как задумываешься о смысле жизни.
anonymous
00.00.0000 00:00
shyneko
28.08.2021 08:36То чувство, когда зарплаты не очень отличаются у меня, и у работника пятерочки
WASD1
28.08.2021 14:55+1>>Дайте кассиру из пятёрочки почитать и после этого свою зарплату озвучьте.Я думаю что вы услышите много интересного.
Я в принципе на условия не жалуюсь. Но при вашем эксперименте предложил бы говорить “whole truth”.
Например что в 8-9 классах до 10 вечера ботал математику (а начиная с 10 - до 12 вечера минимум программирование (как сейчас бы сказали пет-проджекты) вызывая недовольство учителя математики хД).
gdt
27.08.2021 17:41При этом у среднестатистического разработчика, обывателя типа меня, они почти всегда простые, если не сказать рутинные.
Вот не сказал бы, мне казалось, что в продуктовых компаниях как раз наоборот. Да и хороший руководитель будет давать задачи равномерно, когда посложнее, когда попроще, чтобы не было перекосов в работе. Конечно, одно дело круды писать, там конечно никакого челленджа не будет. Краши разбирать тоже неинтересно, но необходимо. Совсем другое дело реализовывать какую-нибудь новую продуктовую фичу, не интерфейсную, причём такую, что во всём интернете никто тебе не может помочь - такое случается чаще, чем хотелось бы. Если скучно и хочется чего-нибудь особенного - попробуйте засертифицировать какой-нибудь драйвер у Microsoft, для усложнения - на виртуалках.
sgrogov
27.08.2021 17:49+3Вы уж лишний не стреляйте в ногу сами себе – не стоит прогибаться под этих мифических иностранцев, ну хотя бы в тех случаях, когда вы их просто выдумали, и рядом их нет.
Комментарии на английском стали негласным стандартом индустрии (хотя может и гласным, я не в курсе ). Точно так же как автоматические тесты или деплоймент например. И если компания стремится поддерживать эти самые стандарты, то это этого обычно выигрывают все:
Программисты повышают или как минимум поддерживают свою квалификацию
Компании легче привлекать квалифицированных кандидатов. Редко хороший специалист согласится присоединиться к команде не умеющей писать автотесты, например
Качество продукта в среднем подрастает
Если рассматривать работу только как обмен своего времени на деньги, тогда правда предложение вроде использовать английский для комментариев вместо родного выглядит нецелесообразно. Особенно когда обосновано оно какой-то далёкой перспективой работы с англоязычными коллегами.
Но если смотреть на работу как на способ расти профессионально и тем самым поддерживать себя в хорошей профессиональной форме, то это по сути бесплатная практика английского. Ну за счёт работодателя конечно.
dvoeglazyi Автор
27.08.2021 17:56Да, есть в этом доля правды. В теории звучит хорошо.
На практике качество комментов и документации оставляет желать лучшего. Т.е. если говорить про мой опыт, получалось не так, что из-за чтения и написания текстов на английском у людей рос навык, а наоборот. Из-за низкого навыка у них получались очень плохие, сжатые тексты. Гораздо хуже тех, на которые они были способны на родном языке. И планка качества так и оставалась на уровне "лишь бы меня поняли".
Происходит так, потому что потребность искусственная в данном случае. Основная часть людей не принимала решения "я хочу целенаправленно изучать английский", но в итоге пассивно участвует в этом, ну и т.п. Они так и будут вариться в собственном соку - нет англоязычных коллег, которые заметят, поправят, скажут - тут ты ошибся и написал фигню.
Gorthauer87
27.08.2021 18:20Обычно самая проблема это в принципе придумать как написать комментарий, а язык там небольшой вклад вносит.
dvoeglazyi Автор
28.08.2021 01:09Если писать научный труд - всё так, мысль должна быть строгой и логичной. Если писать публицистику, то нет, необязательно.
И приведённая вами цитата вполне справедлива в том числе и в обратную сторону - сможете ли вы понять верно "противоречивый поток сознания" (кстати, не соглашусь с такой формулировкой в отношении моей статьи), окажется ли он вам близок, либо нет.
Но опять таки, это вы снова начали философствовать о том, "как надо". Если хотите, можете сказать что-то по существу - с чем из статьи вы не согласны и т.д. и т.п. - у вас уже есть практика в виде 2 комментариев, может с третьей попытки появится и конкретика?
anonymous
00.00.0000 00:00dvoeglazyi Автор
27.08.2021 18:12+1Хотим поделиться мыслями? Так можно написать развёрнутую статью, пофилософствовать и т.п.
Хотим подискутировать и поспорить? Так можно делать это по существу.
А из того, что вы написали - всё хотим. Отчасти для этого эта статья и написана, дескать, "вот он я - такой, какой есть, притворяться не буду". А так, сидя на диване, можно долго подучиваться, определяться, искать, советоваться, но в итоге продолжать оставаться ни с чем.
vya
27.08.2021 19:15Спасибо большое за иллюстрацию. Читал эту книгу в далёком детстве и всё никак не мог вспомнить название.
rustambmt
27.08.2021 19:23А у вас в команде есть Тим лид ?
Счастье не в том что мы все можем сделать а в том что рядом есть человек у которого есть чему поучиться.
В данном случае мне кажется не программист посредственный а компания в котрых вы работайте. Скорее всего это что то для внутреннего использования.
dvoeglazyi Автор
27.08.2021 19:23Я был и там, где он был, был и там, где его фактически не было. Сейчас вообще не работаю.
А поучиться можно даже у оболтуса, тому как не надо делать - уж не знаю, есть ли тут счастье :)
gochaorg
27.08.2021 19:33А в чем сила, брат?
Вообще это хороший пост, мог бы быть началом Бойцовского клуба
Если быстро пробежаться по тексту, то у меня сложилось впечатление усталости и надвигающейся депрессии
По закону жанра есть два пути
Первый это Чак Палланик - т.е. жесть
Второй это Дуглас Коупленд - т.е. само рассосётся
Вот три раздела текста: Святая вера, смена не кончится, не видимый спрос - это мне напоминает роман Рабы Майкрософта
Только в романе там интереснее, там другой ракурс на этот же вопрос
Главное отличие от романа, автор поста один, а начало романов Коупленда - это бросить уставшую обыденность, отказаться от нее и с сподвижниками уехать искать приключения на ж. - при том это обязательное условие, иначе будет Палланик.
Причина настроения мне кажется лежит именно между двумя абзацами 1. Святая вера 2. Смена не кончится
Разобравшись с пропастью между этими двумя абзацами, все остальное будет легко
TokarLimadze
27.08.2021 21:16Если человек сам хочет работать, пусть хоть по 14 часов в сутки без выходных – зачем ему в этом мешать?
В интервальном беге важно остановиться до того, как не сможешь дышать. А то, можно и не продышаться.
Коммунизм = инвестиции в человеческий капитал + компьютеризация.
dvoeglazyi Автор
27.08.2021 23:22+1Не знаю, почему все прицепились именно к этому предложению.
Но абзац имел примерно противоположный смысл - рабочий день даже в 8 часов - тема весьма сомнительная. Люди думают, что раз от них этого везде хотят - они это смогут. От них этого хотят, потому что считают это неким стандартом, отчасти из-за ТК.
А по факту, не всегда получается добросовестно работать даже 8 часов в день.
TokarLimadze
28.08.2021 10:19+1Наверно потому, что у меня попытка суицида на производстве была. Девка одна... из петли вытащили.
duke_alba
28.08.2021 01:11+3По-моему, Вы ошиблись с выбором профессии. Желание сделать код красивее и эффективнее не пропадает с годами. А заниматься тем, что не интересно - очень грустно.
TiesP
28.08.2021 09:10Я не только комментарии, я даже код на русском пишу. Так действительно проще)
пример кода// Возвращает представление периода в нижнем регистре или с заглавной буквы, // если с него начинается фраза (предложение). // Например, если требуется вывести представление периода в заголовке отчета // в формате "Продажи за [ДатаНачала] - [ДатаОкончания]", то ожидается, что // результат будет выглядеть так: "Продажи за февраль 2020 г. - март 2020 г.". // Т.е. - строчно, т.к. "февраль 2020 г. - март 2020 г." не является началом предложения. // // Параметры: // ДатаНачала - Дата - начало периода. // ДатаОкончания - Дата - конец периода. // ФорматнаяСтрока - Строка - определяет способ форматирования периода. // СЗаглавнойБуквы - Булево - Истина, если с представления периода начинается предложение. // По умолчанию - Ложь. // // Возвращаемое значение: // Строка - представление периода в требуемом формате и регистре. // Функция ПредставлениеПериодаВТексте(ДатаНачала, ДатаОкончания, ФорматнаяСтрока = "", СЗаглавнойБуквы = Ложь) Экспорт Если ДатаНачала > ДатаОкончания Тогда Возврат ""; КонецЕсли; ПредставлениеПериода = НРег(ПредставлениеПериода(ДатаНачала, ДатаОкончания, ФорматнаяСтрока)); Если СЗаглавнойБуквы Тогда ПредставлениеПериода = ВРег(Сред(ПредставлениеПериода, 1, 1)) + Сред(ПредставлениеПериода, 2); КонецЕсли; Возврат ПредставлениеПериода; КонецФункции
vsh797
28.08.2021 10:05+1работал у нас тут один человек пару лет назад – он предложил, давайте писать всё на английском
Респект парню!
дескать, потом с англоязычными сотрудниками легче будет
По мне, вопрос даже не в этом, а в том, что код все равно пишется на английском. И если код, комменты к нему и документация будут на одном языке, то синхронизацию между ними будет намного легче поддерживать. Вплоть до автогенерации.
dvoeglazyi Автор
31.08.2021 20:30Код пишется не столько на английском, сколько латинскими буквами. Там могут использоваться англоязычные слова, а могут использоваться общепринятые обозначения, типа i для счётчика массива. Так или иначе, код - это код, для его чтения / написания особых навыков английского не требуется.
Язык документации - как по мне, он должен зависеть в первую очередь от того, для кого она предназначена. Следуя вашей логике, можно прийти к тому, что "код в конечном счёте всё равно транслируется в машинные инструкции, а давайте программировать на машинных инструкциях".
Синхронизацию будет намного легче поддерживать при условии, что те, кто её поддерживает, одинаково хорошо знают английский и, в данном случае, русский. Иначе - нет, не это будет не намного легче, а может быть даже и вообще не легче.
vsh797
31.08.2021 21:46+1Код пишется не столько на английском, сколько латинскими буквами.
Ок, если вы в коде пишете "prognoz", то и в доках пишите так же. А вот постоянное переключение между "forecast" и "прогнозом" лично меня вымораживают. В конце концов все равно переходишь на язык кода. Т.к. источником истины является он.
kibizoidus
Ну т.е. вы программист, и не понимаете, почему все на английском? И размышляете на эту тему? Серьезно?
Ну и по тексту...
1. Вы должны о возможном улучшении сообщить руководителю и предоставить ему право выбора - делать или не делать. Т.к. именно в его обязанности входит не только выбирать, что делать, но и находить под это ресурсы. Если вы этого не сделали - вы хреновый разработчик, если он не решил и переложил решение на ваши плечи - он хреновый руководитель.
2. Человек и так может работать по 14 часов в сутки, ему никто не мешает. Мешает то, что все мы разные, и многие. очень многие просто не могут работать 14 часов в сутки. И если убрать эту норму из закона - многие просто обяжут своих сотрудников так фигачить.
Ну а если серьезно, то чувствуется какая-то доля инфантилизма и неуверенности.
Программирование - это всего лишь инструмент. Любимый молоток. Им можно гвозди забивать, а можно повесить на полку и любоваться гранями. Но я не видел еще ни одного человека, у которого была бы страсть к молоткам. Именно поэтому фраза "мне нравится программировать" - это либо лукавство, либо неопытность. Потому что молотки могут нравиться по сравнению с другими молотками как они быстрее забивают или лучше лежат в руке, но не забиванием гвоздей. Этот процесс всегда одинаковый. И он всегда приводит к готовому изделию с гвоздями.
Чем быстрее вы это поймете - тем лучше вам будет в будущем.
hunterlan
Так можно любить забивать гвозди не за процесс забивания, а за то, что получишь изделие, которое тебе по душе.
kibizoidus
Это все-таки любовь к результатам труда. И молоток здесь - средство достижения этого результата.
tropico
Ну вот взять Python - самый эстетический язык программирования. Никаких дурацких скобочек. Когда работал на Cisco, на код можно было просто смотреть как на произведение искусства (отсутствие комментариев в коде из-за правильной декомпозиции, ООП и всего остального в докстрингах) и ловить эстетический кайф.
Это как смотреть на грани молотка - взять советские и американские инструменты. Одни выглядят просто как мусор, вторые годами радуют глаз.
0xd34df00d
Типов нет (статических, но другие-то — оксюморон), скоупинг наркоманский, ну и, субъективно, когда мне надо было поправить скрипт на питоне, у меня заранее начинали болеть пальцы.
Zifix
Нет, программирование — это не молоток, аналогия неудачная. Это такое же ремесло, как у условного столяра высокого уровня. И есть люди, которым нравится работать с деревом. Всю жизнь.
kibizoidus
Только эти люди показывают свое мастерство конкретными готовыми стульями, а не долгими рассказами, как в паровой бане гнуть липовый брус. И любят их за это.
Zifix
Позвольте, но ведь и программисты показывают мастерство готовыми программами или их модулями.
F0iL
“Talk is cheap. Show me the code.” -- Linus Torvalds
mkone112
Люблю молотки. И программировать.
dvoeglazyi Автор
Почему что на английском? Почему языки программирования и прочие технологии на английском? Почему документация к ним на английском? Я всё это понимаю. Я не совсем понимаю, почему русскоязычные разработчики для формального общения между собой (такого, как описание задач в таск-трекере и комментариев к коду) выбирают английский.
И далее по пунктам.
Речь о том, что решение зависит от того, как разработчик представит и опишет ситуацию.
"Человек и так может работать по 14 часов в сутки, ему никто не мешает" — мешает закон. Вы можете работать по трудовому договору. Вы можете работать 14 часов в сутки. Вы не можете составить договор по ТК РФ, в котором вы будете фигачить по 14 часов в сутки 5 дней в неделю. Если у вас то что прописано в договоре и в законе отдельно, а то что происходит фактически — отдельно, то на кой чёрт вам вообще нужны законы и договор? "Многие просто обяжут своих сотрудников так фигачить" — не крепостное же право, что мешает уволиться и не фигачить?
Начали сравнивать с инструментами — окей. Любимая отвёртка. Я не видел человека, у которого была бы страсть к отвёрткам. Но я наблюдаю человека, который ни во что не ставит шуруповёрт. Для него шуруповёрта либо не существует, либо он предпочитает не замечать разницы между ними. И фраза "всего лишь инструмент" — это либо лукавство, либо неопытность.
kibizoidus
Давайте по порядку.
1. Я не пытался вас лично чем-то обидеть или обвинить в лукавстве или неопытности. Если вы именно это увидели - прошу прощения.
2. Английский в коде и IT - де-факто стандарт общения, приносящий больше плюсов, чем минусов. От языковой практики до упрощения последующей продажи проекта и привлечения внешних ресурсов. It's a must. Спросите у начальства, или у высшего руководства, почему все на английском. Думаю ,там будет более полная картина и вам смогут внятно ответить без "исторически так сложилось".
3. Проблемы возникают не тогда, когда между работодателем и сотрудником все радужно и белые пони, а когда вас внезапно уволили и вы желаете доказать свою правоту и получить положенное вам и заработанное. Ну и про крепостное право - если у всех на рынке будут договора на 14 часов смены в сутки - к кому вы пойдете работать на 8 часов?
4. Любовь к отверткам и шуруповертам - это уровень компетенции конкретного сотрудника и вообще к обсуждению не имеет отношения, но если вы начали - так же глупо расширять отверстие, чтобы пролез любимы шуруповерт, если можно взять отвертку, так ведь? Глупо ждать, пока зарядится аккум в шурике, если можно один шуруп закрутить отверткой и дальше заниматься другими задачами, так ведь? Я могу приводить десятки таких примеров, но суть одна - конкретный инструмент или инструментарий нужно уметь применять. И программирование - такой же инструмент решения задач, как литье стали или деревообработка. Для своих задач.
dvoeglazyi Автор
Про п. 2 - см. мой другой коммент - уже написал на эту тему.
Про п. 3. - иногда можно мирно расстаться и не затягивать. Бывает одна из сторон (работодатель/работник) проблем не наблюдает и считает, что всё хорошо. А другая сторона уже знает - дальше будет хуже.
Есть же области, которые не регулируются какими-то подобными ограничениями, и вроде люди как-то живут. Например, если у всех женщин будет требование, чтобы их партнёр был как минимум принцом Камбоджи - где вы будете искать подругу или жену? Но всё-таки такая проблема не стоит.
F0iL
Например, потому что проект может быть в какой-то момент опубликован в опенсорс или куплен какой-нибудь международной компанией.
У Яндекса на эту тему вообще интересная история была.
quaer
Возможно, общение на неродном языке убирает эмоциональную составляющую. И позволяет на всё смотреть как бы со стороны.