Comments 52
Вы не первый, от кого кто‑то пострадает, жизнь жестока, пусть поплачут. Не стесняйтесь в выражениях, травите и унижайте глупых критиков, доводите до психоза и депрессии, ибо они приносят очень много вреда в мотивации пытливых умов и людей, которые пытаются с грехом пополам делать хоть что‑то. Разговаривать — желающих много, пытаться делать — очень мало, делать так, чтобы хоть как‑то завелось — единицы. Что там реально нужно и что не нужно — покажет рыночек, а не вопли с диванов от тех, кто до рыночка со своим продуктом даже и не дошёл.
Жестко, но верно! За почти 60 лет в программировании не раз убеждался в верности сказанного!
Умение делать то, о чём договорились, осознавая всю ущербность договоренного в сравнении с тем, что «можно было бы, если бы», — это главное
Все подобного рода советы сводятся к тому что можно сделать ИЛИ в срок, ИЛИ хорошо. Возможность сделать И в срок И хорошо даже не рассматривается. Хотя она по смыслу является (должна являться) вариантом по умолчанию.
Чтобы хорошо и в срок должно совпасть много маловероятных событий навроде тщательного ТЗ, архитектура чтоб была проработанная и не пересматривалась кардинально за месяц до окончания проекта, да и вообще, чтоб были компетенции разрабов, компетенции руководства, компетенции заказчика. Совпадение всего этого настолько сферический конь в вакууме, что в природе не встречается.
Все подобного рода советы сводятся к тому что можно сделать ИЛИ в срок, ИЛИ хорошо.
Подобного рода советы может и сводятся к этому, но конкретно в этой статье я не нашел никаких или. Нашел - просто сделать в срок настолько хорошо чтобы заказчик принял работу, не стремиться делать лучше рискуя сроками. Мысль как бы банальная, но без наличия мозгов, умения ими пользоваться и опыта в текущих реалиях - нереализуемая, мне так кажется.
Да, даже не рассматривается. Потому, что элемент "сделать в срок" поддаётся бездушному менеджменту, а качество не поддаётся - элемент везения - нанятый специалист оказался ещё и супер-мастером. Но главная фишечка в технологичности управления этапами, которые делаются в срок. Множество операций, которые делаются чётко в срок, можно выстраивать в предсказуемые по времени технологические цепочки, а уменьшение объёма каждой операции повышает предсказуемость качества каждой. Нам не надо бороться за высокое качество итогового продукта как целого, а надо разбить техпроцесс на такие этапы, чтобы качество на каждом было легче достижимо среднестатистическим бухающим михалычем, измеримо, предсказуемо.
Сделать в срок - базовое требование к технологическому этапу, потому что если оно не сделано, то даже качество померять нельзя. А если сделано, то мы не превышаем расходы на зарплату и хотя-бы можем увидеть, где именно недостатки в качестве и что именно надо улучшать.
Нам не надо бороться за высокое качество итогового продукта как целого, а надо разбить техпроцесс на такие этапы, чтобы качество на каждом было легче достижимо среднестатистическим бухающим михалычем, измеримо, предсказуемо.
Чем дальше вы пишите - тем страннее это выглядит.
Именно качество продукта как целого интересует заказчика. А насколько хорошо сделан этап №10016 - его вообще не интересует.
При этом качество целого - не сводится к качеству составных частей "на конвейре".
Не исключаю, что это корявые формулировки и какое-то непонимание.
При этом качество целого - не сводится к качеству составных частей "на конвейре".
Неверное утверждение. Для того и разбирают, чтобы получить сумму хорошо контролируемых качественных этапов, а в конце просто невозбранно их состыковать лёгким движением руки.
Вы сейчас утверждаете, что "системные тесты" (и вообще все проверки уровня системы) - лишняя сущность.
Так?
Нет, они не помешают убедиться, что всё в собренном виде работает, но интереснее иметь юнит-тесты и чёткие спецификации на юниты.
Скажите, а в проектах, в которых вы учавствовали, сколько времени, по вашим оценкам тратилось на интеграцию уровня системы в сравнении с разработкой всей системы (какую-нибудь удобную вам, но понятную метрику)?
Ну и второй вопрос, чтобы диалог проходил быстрее, - о какого уровня проектах идёт речь в ваших оценках, примерно?
Возможно, одна из причин этого в том, что, если вам поставили срок, за который реально сделать хорошо, то это промах руководства - ведь можно было и раньше
Ещё добавил бы, что полно фанатиков различного толка: фанатики Александреску, фанатики "чистого" кода, функционального или объектного программирования, фанатики питона, раста, плюсов. Не надо вступать в эти секты. Нет серебряной пули, нет универсального решения на все случаи жизни. Надо подбирать инструмент под задачу
Да, корпорации стремятся всех поставить за конвеер, но этому надо сопротивляться
Инженеров тоже?
Инженеров, тимлидов, менеджеров - всех. В этом суть: каждый должен стать роботом, выполняющим одну фунцию очень хорошо и при этом легко заменяемым. Это отвратительно, но так устроено
Так было всегда, автоматизация существут столько же сколько существует цивилизация. Что можно автоматизировать то заменяется. Не вижу что тут отвратительного. Инженеров , ученых заменить на порядок сложнее их задачи творческие, с множеством нетривиальных функций. тимлиды и менеджеры, да, заменяемые, после их автоматизации жить только удобнее будет. Исчезнет еще одна прослойка бюрократии.
Простите, но зачем этому сопротивляться? Это какой-то неолуддизм. Автомобили, электроника, бытовой скарб, даже стройматериалы, скороводки и зубочистки -- делаются сегодня на конвейере, максимально автоматизированно, и это хорошо. Качество высокое и контролируемое, скорость производства на порядки выше кустаря, и цена, как ни странно, тоже падает. То же будет и с разработкой софта. Так же, как профессия кузнеца умерла, сменившись на оператора станка с ЧПУ, так и профессия разработчика сменится на специалиста по настройке и контролю линии производства ПО (условно). Кастомная разработка или разработка "с нуля" не исчезнет, но станет редкостью, как сейчас специализация разработчика станков с ЧПУ или изготовления всяких штучных вещей.
На примере мебели: есть Ikea для самых нетребовательных, есть сотни типовых моделей для тех, кто ищет что-то конкретное, ну и есть, конечно, мебель на заказ. И соотношение их рынков, ну не знаю, допустим 17%, 77% и 6% (цифры из головы). Вы, сопротивляясь конвейеру, отрицаете 94% потребностей рынка. Большинство не может и не хочет морочиться с мебелью на заказ. Их устраивает уровень качества Ikea, проще выкинуть через 3-5 лет то, что износилось или надоело, чем жить с бабушкиным комодом Людовика XiV, потому, что заказать новый это приключение на три месяца и стоимостью в три з/п.
Так же, как сейчас есть люди, недовольные качеством современного ПО, есть и люди, недовольные качеством Ikea. Но они не покупают в Ikea, а покупают то, что дороже. Вы можете возразить, что в случае с ПО часто бывает так, что нет альтернативы. А вот это как раз и есть издержки полу-кустарного производства ПО! Если программа требует 10000 человеко-часов для разработки, то она, конечно, будет уникальной. Если максимально автоматизировать (а так же стандартизировать и унифицировать) разработку, то эта же программа потребует, допустим, 500 человеко-часов. И гораздо большее кол-во компаний сможет себе позволить разработку такой программы. Количество - конкуренция - качество.
Линии производства стула аналогична операции копировать-вставить на компьютере при производстве экземпляра ПО. Разработка ПО эналогична разработке стула, а не его производству по уже готовым чертежам.
Согласен, аналогия не очень соответствует. Уточню. Аналог производства стула -- это копирование готового пакета setup.exe, трудозатраты стремятся к нулю. Разработка стула -- это расчёты, модели, изготовление чертежей и настройка производственной линии. Заметьте, НЕ постройка нового завода под новую модель и даже, в большинстве случаев, НЕ закупка новых станков (не берём плановое обновление оборудования) -- существующий конвейер только слегка модифицируется. А в энтерпрайз разработке ПО зачастую при создании нового приложения завод перестраивается чуть ли не с нуля. Станки плохо совместимы, инженерные решения переизобретаются. Да, уже есть компоненты и библиотеки, ставшие промышленными стандартами, но стандартизация, к сожалению, ещё недостаточная.
В идеальном мире разработчик ПО должен спроектировать систему на высоком уровне, не в виде промта к AI, конечно, а в виде детальной спецификации UX, спроектировать потоки данных в системе, расставить границы безопасности, задать ассеты, лимиты ресурсов, ещё какие-то детали. По этому проекту умная автоматизированная система из унифицированных и совместимых между собой компонентов помогает собрать прототип ПО, который затем множеством итераций тестирования и правки доводится до продакшен состояния. Это -- конвейер, не подразумевающий кастомной разработки каких-либо компонентов, кроме самых необходимых и уникальных, нужных исключительно для данной задачи. Как в наше время множество моделей Ford, Mazda и Volvo построены на едином шасси. Нет бессонных ночей в отладке ядра Linux, криков "эврика" и литров кофе. И нет рутины, когда в сотый раз пишется интерфейс json - websocket - redis - sql - whatever. Понятно, что это не реально сейчас, но хочу верить, что будет реально в будущем.
Из ныне существующих приложений для меня в этом смысле образцом является VSCode (и пусть меня закидают тапками). Да, он на Electron'e, который принято ругать, он тяжеловат и работает помедленнее, чем Visual Studio. Но, он, чёрт возьми, работает везде. Mac, Windows, Linux, даже онлайн. Он модульный внутри, расширяемый снаружи. Он собран из достаточно надёжных и проверенных компонентов, он очень, очень любит стандарты (GDB/LLDB, DAP, LSP, ripgrep, github API, OCI). Так должно быть.
А автор поста, похоже, фанатик пет-проектов. А дальше у программиста небогатый выбор, чем пожертвовать ради этих петов. Можно семьей. Можно физической активностью.
О, это отличная тема, которую надо было дописать отдельным пунктом. Главный интересный вывод, который я понял об этой теме - нет не только серебряной пули, а даже высказывание "каждый инструмент хорош под свою задачу" часто выглядит тупо, хоть и драматургически красиво. Потому что очень часто специалист в своей сфере достигает такого мастерства, что ему не сложно и не долго сделать этим инструментом то, для чего он "как бы не предназначен", причём иногда быстрее чем те, кто использует под эту задачу то, что под неё предназначено. Отсюда вытекает совет о том, "на чём мне делать NNN" - ответ чаще всего такой: что лучше всего знаешь, то и используй, быстрее получится. В жизни так же наблюдается это явление - часто в корпорациях какая-то технология, не предназначенная для NNN с некоторой порпоративной внутренней доработкой вовсю используется для NNN, потому что отцы-основатели искуссно этим микроскопом гвозди забивали, быстрее чем обладатели молотка. Просто допилили микроскоп немножко, сделали ему станину помассивнее и дело пошло веселее! Когда-то слышал такое: "чем выше мастерство, тем меньше инструментов у мастера" - но ссылок нет, может наврали конечно.
Однозначно так. При выборе технологического стека для проекта - в нормальной компании всегда отталкиваются от кадрового вопроса. Что лучше умеет та команда что есть + насколько легко найти на рынке специалистов нужного профиля.
Исключения бывают, но редко. И обычно такое как раз выгодно отдать на аутсорс. Как, например, разработку апплета для java card (если только это не ядро продукта типа cold wallet)
Не стоит думать, что работодатель — обманщик, если не индексирует зарплату
Индексация заработной платы - обязанность работодателя по ТК РФ. При наличии в компании премиальной системы есть возможность юридически это обойти, ну так и разработчик может тогда не впахивать 8 часов, а работать в режиме итальянской забастовки + например тот же удалёнщик может 4 часа не выходить на связь вообще без последствий
Яркий пример МВД им не составили индексацию в 2012 году, потом еще несколько лет, в 2024 году тоже не индексировали, очень громкая новость была, в 2025 году индексация даже не покрывает инфляцию... Кроме этого если смотреть сферу других людей, к примеру на заводах то ее опять нету либо ниже инфляции, в торговле на частника тоже индексация может быть или не может, там зп от продаж может зависеть. Самозанятые вообще сами за себя, ИП тоже и так далее...
Прочитайте же вы тот самый ТК РФ и укажите, где там написано,что индексация прям обязательна в негос организациях. Для негос указано,что индексация выполняется по правилам, установленным в нормативке тех самых негос организаций. А у них, обычно, в локальных нормативных актах, которые вы подписываете при найме, указано отсутствие индексации.
Нельзя всерьёз воспринимать нытиков «ты делаешь велосипед, это ненужно». Во‑первых вы им его и не предлагали, во‑вторых они и такого‑то не осилили. Нужно обязательно уметь кидаться вонючим калом, грубо насмехаясь, в человека, который пытается это делать с вами — баланс тупой критики важен. Нужно активно закидывать грязью авторов плохой критики, которой большинство.
Наказуемо вообще-то, вплоть до уголовной.
Нужно обязательно уметь кидаться вонючим калом, грубо насмехаясь, в человека
Мне моя брезгливость дорога,
мной руководящая давно:
даже чтобы плюнуть во врага,
я не набираю в рот говно.
Мир не помнит имён великих тимлидов, но мир помнит имена великих разрабов — Торвальдса, который до старости в коде копается
Великие разрабы, как правило, не только сами код пишут, но и лидируют в большой команде/сообществе, которые вокруг них и собрались.
Все помнят Джобса, но мало кто помнит Возняка, хотя он был великим инженером - электронщиком. Да и имя Видлара широко известно в довольно лишь узких кругах, хотя он, фактически, в одни руки создал всю современную аналоговую микроэлектронику.
Все по сути верно.
Минус один - когда работаешь часов этак 11 в день, и семья - на пет проекты не тянет ( воротит от вида компьютера).
Вроде платят хорошо, но идет постоянная переработка и не успеваешь вокруг посмотреть.
Я поработал за 25 лет в консалтинге, продукте, поддержке (L3) - более менее время было в консалтинге. Да, бывало что летаешь чуть ли не еженедельно, сидишь у заказчика на проекте, но там бывали перерывы для самоподготовки. Хуже всего конвейер в продукте - ты на максимально равномерной загрузке и растешь в узкой сфере, годами в одной нише, ведешь один два проекта
Еще дополнил бы вот чем.
Учитесь не только на пет-проектах. Учитесь на рабочих проектах. Обязательно извлекайте уроки из своих рабочих задач - как позитивные, так и негативные. И учитывайте в следующих задачах. Так вы будете расти даже быстрее чем на пет-проектах. В том числе - в грейдах и в зарплате.
Если сама компания вас еще и учит при этом - так вообще зашибись. А если нет - каждый сам кузнец своего счастья. Учитесь на любых задачах, даже на скучных. Именно так родилась автоматизация :)
В принципе, со многим согласен, кроме пет-проектов) Мне как будто больше делать нечего, чем пет-проектами заниматься))
Смешно и то, что я, ни разу ни одного пет-проекта не сделавший, в итоге с точки зрения капитализма оказался значительно успешнее всех из моего окружения, кто их делал и делает. Мерило простое - мой доход тупо выше.
При этом время, которое я не тратил на строение говна и палок я вполне успешно потратил на создание семьи, путешествия, на гитаре вот научился играть, ходил в спортзал, прошёл 100500 игр и посмотрел 100500 киношек и сериалов с женой и не только. С кайфом, в общем, провёл)
Просто я делаю работу и делаю её качественно. Любое обучение - в рабочее время. Или в процессе выполнения задач. Подход оказался вполне рабочим.
Ваш доход выше только в данный момент. Прямо сейчас ИИ резко подкосил наши возможности стабильной работы в рамках следующих нескольких лет.
Это не значит, что нас завтра уволят, но это значит, что надо постепенно переквалифицироваться из разработчиков в мини тех-лида и product owner'а в контексте своей работы. Часть людей, к большому сожалению, потеряет работу.
Но в целом, если смотреть в долгосрочной перспективе, то люди, у кого 2-4 пет-проекта и которые зарабатывают в целом даже 1/2 от вашего дохода, могут оказаться в выигрыше.
Мы же не знаем, какие у них там пет-проекты. Может у них недвижимость, гаражный бизнес или много маленьких помещений в аренде. Пет-проект – это же не обязательно очередная игра "змейка" по подписке или трекер расходов.
Сейчас нужно развивать пет-проекты в реальной жизни) та же недвижимость, земельные участки, машины.
Ну и ещё один плюс в пользу адекватных пет-проектов – копеечка в старости. В 40+ рынок труда сильно становится уже, но человек ещё молод и полон сил. Что ему делать, если его не берут из-за возраста? Вот тут и спасают пет-проекты.
Отличная статья, согласен с большинством пунктов исходя из своего тоже немаленького опыта.
Страшная тайна: большинство успешных бизнесов‑проектов‑стартапов — велосипед. Но сделаный лучше конкурента, тем и ценится.
Всё так хорошо начиналось, но в этом месте вы сломались.
Большинство успешных бизнесов
1. найти нишу
2. Сделат свою "раму от велосипеда" - которая даст ключевое преимущество
3. Всё остальное - сделать из готовых компонент, чтобы сесть на "существующую инфраструктуру".
То есть говоря вашим языком метафор: "большинство успешных бизнесов - это удобные красивые креслица в стандартном РЖД-шном вагоне метро".
Объём завелосипеженого vs объём стандартного взятого просто даже близко не сравним.
Ну по факту это так, только ещё нужен человек с предпринимательской жилкой и умением рисковать и брать на себя всю ответственность + умение строить команду и искать источники финансирования.
То есть быть тем, кем боятся быть примерно 99% из нас всех. Искренне по-доброму завидую тем, кто смог построить банки вроде Plata и Т-Банк, другие финтехи или местечковые сети аптек, магазинов, грузоперевозок...
Мои советы: Читайте Архитектуру компьютера, Компьютерные сети, Изучайте алгоритмы, структуры данных, дискретную математику, решать задачи на LeetCode
а для подвоза результата к сроку, на который босс забился с заказчиком
А ещё если босс пообещал конкретный срок заказчику - это проблемы самого босса. Даже если вы сами сказали ему эту дату.
Потому что разработка - это не упаковка конфет на конвейере со строго регламентированной скоростью. Тут каждая задача - уникальна. И в каждой попадаются свои подводные камни. И чем больше задача - тем больше в ней встречаются камушки.
Если босс не знает про специфику разработки - это его проблемы. Если он пытается перевесить свои договорённости на вас - это его проблемы. Вы продаёте своё время за его деньги, о чём и был трудовой договор.
Риски не успеть - это риски босса. Это он владеет бизнесом, он управляет обещаниями клиентам, он управляет методами решения этих проблем. Он ДОЛЖЕН разбираться в специфике работы своих сотрудников. Он ДОЛЖЕН брать риски на себя и понимать, чем он рискует.
Со всеми пунктами согласен, кроме 10го. Очень спорный. И я не про бросание говна в оппонента, а про велосипедостроение и про "сперва добейся".
Вот прям со всеми пунктами согласен полностью!
Ещё пара ценных советов:
будьте заметны. Вы можете быть сколь угодно великим разработчиком и пилить гениальнейшие решения, но для остального мира вы примерно никто, так как ни ваших решений, ни ваших умений никто, кроме вашей команды, и не видел. Пишите мелкие (или крупные) статьи, пишите пет проекты, отвечайте на стековерфлоу и линкедине.
Учитесь презентовать себя. Соберите в большой текст все ваши умения, переработайте чтобы получился внятный рассказ о том какой вы молодец. Это не просто перечисление где работали и что делали, а что решали и как и чем помогло капиталисту. Сделайте короткую и расширенную версию и научитесь их рассказывать легко и непринужденно.
Не бойтесь ошибаться.
Хороший текст. Помимо того, что я согласен с содержанием, мне ещё очень понравился язык. От него веет конкретностью.
Не стесняйтесь в выражениях, травите и унижайте глупых критиков, доводите до психоза и депрессии[...]
Вы тут поосторожнее, чтобы не пришлось знакомиться со статьёй 110 УК РФ или эквивалентом в вашей юрисдикции (доведение до самоубийства).
Советы новичкам в карьере программиста