Comments 31
Поэтому менеджеры по продукту и нестабильные требования — не враги программистов
Менеджеры воспринимаются как враги потому, что именно от них в большинстве случаев приходит все то, что у вас далее описано в разделе "Сложность". Т.е. именно из их уст привносятся новые фичи и т.д. (хотя они по сути только озвучили пожелания стейкхолдеров) Но иногда менеджеры не только не способствуют снижению сложности, но и сами добавляют ее на ровном месте. Вместо рефакторинга, за который никто не заплатит, накидывают новых фичей и т.д. Поэтому грамотный менеджер это подарок для любого проекта.
Не понятно почему программист должен бояться изменения требований, если весь процесс разработки построен на итеративных изменениях кода.
Менеджеры воспринимаются как враги потому, что тратят время программиста на решение собственных задач (бесполезные митинги, метрики, отчеты), которые не создают ценности, а только поддерживают их менеджерский статус.
Не понятно почему программист должен бояться изменения требований, если весь процесс разработки построен на итеративных изменениях кода.
Сильно зависит от ситуации. Как пример, менеджер пообещал большому начальству какую-то фичу через три дня. А фича эта ломает все, что уже сделано и работает. На негодование со стороны технарей менеджер просит сделать костыль, который потом обязательно исправим. И такое встречается не реже чем бесполезные отчеты.
Первая итерация - залили фундамент.
Вторая итерация - построили первый этаж.
Третья итерация - построили второй этаж.
Четвертая итерация - перезаливаем фундамент.
С точки зрения многих менеджеров этот проект вполне итеративный. Но мне бы не хотелось не то что жить в таком доме, но и строить его.
Написание кода для множества «больших проектов» — это не только неинтересное, но и опасное занятие, гораздо менее увлекательное, чем решение алгоритмических задач в LeetCode
Ну мои соболезнования автору, если он сжав зубы в страхе пишет продуктивный код, а расслабляется только на литкоде. 14 лет в таком режиме - не шутки.
У меня наоборот радость от труда приходит только когда делаю что-то нужное людям. Даже если "опасно".
Аналогичная мысль была при чтении статьи. Может быть автору стоит задуматься о работе преподом? Если ему не нравятся задачи реального мира, а нравятся синтетические задачи, в которых заранее известно, что они решаемы.
Дело не в синтетических задачах. Просто разработчики не так часто с нуля пишут большие системы. Обычно они приходят на проект, который уже большой. А на нем за 5-10 лет поработать успело сколько-то десятков разработчиков, а то и сотен. И вот сидишь пишешь какую-нибудь новую фичу для этого проекта... Пишешь правильно, все как надо. Но в системе, где даже старожилы плутают в коде. И вот релиз, который потенциально после запуска может сломать что-то совсем в другом месте, там где не тестили, потому что целиком всю огромную систему тестить при каждом релизе нецелесообразно (невозможно). И конечно же, все будут в напряжении, в готовности к быстрому откату изменений. А ведь после отката что-то могло тоже поломаться... Цена ошибки, простоя - миллионы, десятки, а то и сотни... Это условный пример. Такое можно встретить в каком-нибудь банке, например.
Если мне все задачи ставит начальник, значит ли это, что весь код надо писать в одном божественном объекте? Ведь у него же единственная причина для изменения!
Если юнит-тесты улучшают архитектуру, то почему, простая функция из одной строки с простой и понятной сигнатурой, превращается в несколько классов и фабрик их создания с зубодробительными интерфейсами, которые требуют при использовании настраивать детали внутренней реализации?
Юнит-тесты не про архитектуру. Вообще именно юнит-тестирование переоценено. Но подачу принял. Надо было дальше пойти по солиду:
Если классы должны быть закрыты для модификации и доступны для переопределения зачем тогда во многих апи используют final?
Если функции должны использовать наследника не зная об этом то зачем тогда sealed?
Если многие простые интерфейсы проще чем один сложный то почему всегда не использовать функциональные интерфейсы, или вовсе анонимные функциональные типы?
Насколько глубока кроличья нора абстракций? Если я с одного перехода в IDE вижу кто создает экземпляр имплементации интерфейса, то почему это плохой и неправильный DI, а правильный там где я его ищу полдня чертыхаясь и матерясь?
кстати, вот что надо на собесе спрашивать, а не "расшифруйте мне солид"
На собесах сеньоров гоняют джуновскими вопросами) а ты хочешь, чтобы тебе задали вопросы по финалку))
это я себе говорю, вслух просто, а то что гоняют это я в курсе, тем забавнее на них ходить когда сам параллельно ищешь сеньоров по совсем другим критериям
Я тут искал работу и очень сильно удивился, что почти 95% собеседовавших меня тех диров задавали вопросы про виртуальные таблицы, и ни один из них разу не спрашивал, как вообще я мыслю, как я собираю код, как я определяю то, что нужно здесь сделать.
Я некоторое время назад устраивался в соньку, так там вообще для профилактики спросили техчасть, и все остальные вопросы были направлены исключительно на то, как я работаю. Что буду делать в этой ситуации, в той. С кем бы я говорил, какие бы шаги выполнял, как я мыслю, какие решения принимаю.
Ни разу в русских компаниях такого подхода не видел, к сожалению. Буду исправлять)
Здесь неплохо подчеркнута важная проблема, которая слабо обсуждается.
Не проблема написать функцию или переложить данные из одной коробки в другую.
Но основная работа индустриальных программистов - это на самом деле писать функции и перекладывать коробочки на гигантской запутанной фабрике с кучей комнат, конвейеров через стены и проводов из потолка.
Поэтому важнейший аспект - умение понимать, как устроена фабрика и искать, куда ведет провод (и есть ли на нем питание)
Ну и организовывать это.
Иногда сложность в этом смысле буквально угнетает начинающих. Ты видишь красные провода, но попытка понять, что это такое, вызывает ступор.
Я уже 14 лет в отрасли, но программировать по-прежнему сложно
Я уже 32 года в отрасли, и понял что сложность программирования зависит от архитектора. :)
Отличного качества перевод, настолько, что я лишь в конце понял, взглянув на автора публикации. Спасибо!
Годнота. Тоже ровно 14 лет в программировании с 2010-го. Программировать сложно. Следовало ещё добавить аспект как раз про возраст/опыт. Способность потреблять некоторый объем информации и держать тонус/фокус обратно пропорционально возрасту/опыту, как ни странно. Если в 22 года ты горишь кодингом и можешь инвестигировать проблему до 5 утра, то ближе к 40, несмотря на весь опыт, переработать большой объем информации сложно. Потому что к 7 вечера ребёнок требует внимания, надо ложиться в 9-10, чтобы утром отвезти его в садик, да и организм не тот, чтобы ночью работать. В 20-25 несмотря на мЕньший опыт у тебя есть люфт во времени и "на половину пустой стакан". А опыт из флешбеков о вымерших технологиях не всегда релевантен. Дорогу молодым! 😀
У меня жена в садик отводит, ходя на работу рядом с домом с условным доходом.
Сложность - это когда что-то новое. Если в программировании уже 30 лет, то новое встречается крайне редко - только новые слова для описания старых понятий.
У меня наоборот. В 35 мне некий объем информации казался неподъёмным, в 40 я отлично с ним справлялся на лету. Молодые, судя по коллегам, вообще любят в частности закапываться и не видеть общей картины
А кто сказал что будет легко?
Писать код легко, но писать хороший код — сложно
Стейкхолдерам не нужен хороший код. Плохой код, кстати, тоже.
Им нужно решить бизнес-задачу.
Их интересует "когда" и "как дорого".
К сожалению, в статье нет ни одного упоминания про "софты". И очень зря. После 10+ лет в специальности обычно приходит понимание, что одних хардов - мало. Если понимание не приходит... ну что же, человек продолжает из года в год наступать на одни и те же грабли.
Я уже 14 лет в отрасли, но программировать по-прежнему сложно