Comments 43
Вы не первый, от кого кто‑то пострадает, жизнь жестока, пусть поплачут. Не стесняйтесь в выражениях, травите и унижайте глупых критиков, доводите до психоза и депрессии, ибо они приносят очень много вреда в мотивации пытливых умов и людей, которые пытаются с грехом пополам делать хоть что‑то. Разговаривать — желающих много, пытаться делать — очень мало, делать так, чтобы хоть как‑то завелось — единицы. Что там реально нужно и что не нужно — покажет рыночек, а не вопли с диванов от тех, кто до рыночка со своим продуктом даже и не дошёл.
Жестко, но верно! За почти 60 лет в программировании не раз убеждался в верности сказанного!
Умение делать то, о чём договорились, осознавая всю ущербность договоренного в сравнении с тем, что «можно было бы, если бы», — это главное
Все подобного рода советы сводятся к тому что можно сделать ИЛИ в срок, ИЛИ хорошо. Возможность сделать И в срок И хорошо даже не рассматривается. Хотя она по смыслу является (должна являться) вариантом по умолчанию.
Чтобы хорошо и в срок должно совпасть много маловероятных событий навроде тщательного ТЗ, архитектура чтоб была проработанная и не пересматривалась кардинально за месяц до окончания проекта, да и вообще, чтоб были компетенции разрабов, компетенции руководства, компетенции заказчика. Совпадение всего этого настолько сферический конь в вакууме, что в природе не встречается.
Все подобного рода советы сводятся к тому что можно сделать ИЛИ в срок, ИЛИ хорошо.
Подобного рода советы может и сводятся к этому, но конкретно в этой статье я не нашел никаких или. Нашел - просто сделать в срок настолько хорошо чтобы заказчик принял работу, не стремиться делать лучше рискуя сроками. Мысль как бы банальная, но без наличия мозгов, умения ими пользоваться и опыта в текущих реалиях - нереализуемая, мне так кажется.
Да, даже не рассматривается. Потому, что элемент "сделать в срок" поддаётся бездушному менеджменту, а качество не поддаётся - элемент везения - нанятый специалист оказался ещё и супер-мастером. Но главная фишечка в технологичности управления этапами, которые делаются в срок. Множество операций, которые делаются чётко в срок, можно выстраивать в предсказуемые по времени технологические цепочки, а уменьшение объёма каждой операции повышает предсказуемость качества каждой. Нам не надо бороться за высокое качество итогового продукта как целого, а надо разбить техпроцесс на такие этапы, чтобы качество на каждом было легче достижимо среднестатистическим бухающим михалычем, измеримо, предсказуемо.
Сделать в срок - базовое требование к технологическому этапу, потому что если оно не сделано, то даже качество померять нельзя. А если сделано, то мы не превышаем расходы на зарплату и хотя-бы можем увидеть, где именно недостатки в качестве и что именно надо улучшать.
Нам не надо бороться за высокое качество итогового продукта как целого, а надо разбить техпроцесс на такие этапы, чтобы качество на каждом было легче достижимо среднестатистическим бухающим михалычем, измеримо, предсказуемо.
Чем дальше вы пишите - тем страннее это выглядит.
Именно качество продукта как целого интересует заказчика. А насколько хорошо сделан этап №10016 - его вообще не интересует.
При этом качество целого - не сводится к качеству составных частей "на конвейре".
Не исключаю, что это корявые формулировки и какое-то непонимание.
Возможно, одна из причин этого в том, что, если вам поставили срок, за который реально сделать хорошо, то это промах руководства - ведь можно было и раньше
Ещё добавил бы, что полно фанатиков различного толка: фанатики Александреску, фанатики "чистого" кода, функционального или объектного программирования, фанатики питона, раста, плюсов. Не надо вступать в эти секты. Нет серебряной пули, нет универсального решения на все случаи жизни. Надо подбирать инструмент под задачу
сейчас вам расскажут, что многостаночник - это тот, который плох сразу во всём, а не условно хорош, по трём-пяти направлениям.
А автор поста, похоже, фанатик пет-проектов. А дальше у программиста небогатый выбор, чем пожертвовать ради этих петов. Можно семьей. Можно физической активностью.
О, это отличная тема, которую надо было дописать отдельным пунктом. Главный интересный вывод, который я понял об этой теме - нет не только серебряной пули, а даже высказывание "каждый инструмент хорош под свою задачу" часто выглядит тупо, хоть и драматургически красиво. Потому что очень часто специалист в своей сфере достигает такого мастерства, что ему не сложно и не долго сделать этим инструментом то, для чего он "как бы не предназначен", причём иногда быстрее чем те, кто использует под эту задачу то, что под неё предназначено. Отсюда вытекает совет о том, "на чём мне делать NNN" - ответ чаще всего такой: что лучше всего знаешь, то и используй, быстрее получится. В жизни так же наблюдается это явление - часто в корпорациях какая-то технология, не предназначенная для NNN с некоторой порпоративной внутренней доработкой вовсю используется для NNN, потому что отцы-основатели искуссно этим микроскопом гвозди забивали, быстрее чем обладатели молотка. Просто допилили микроскоп немножко, сделали ему станину помассивнее и дело пошло веселее! Когда-то слышал такое: "чем выше мастерство, тем меньше инструментов у мастера" - но ссылок нет, может наврали конечно.
Однозначно так. При выборе технологического стека для проекта - в нормальной компании всегда отталкиваются от кадрового вопроса. Что лучше умеет та команда что есть + насколько легко найти на рынке специалистов нужного профиля.
Исключения бывают, но редко. И обычно такое как раз выгодно отдать на аутсорс. Как, например, разработку апплета для java card (если только это не ядро продукта типа cold wallet)
Не стоит думать, что работодатель — обманщик, если не индексирует зарплату
Индексация заработной платы - обязанность работодателя по ТК РФ. При наличии в компании премиальной системы есть возможность юридически это обойти, ну так и разработчик может тогда не впахивать 8 часов, а работать в режиме итальянской забастовки + например тот же удалёнщик может 4 часа не выходить на связь вообще без последствий
Яркий пример МВД им не составили индексацию в 2012 году, потом еще несколько лет, в 2024 году тоже не индексировали, очень громкая новость была, в 2025 году индексация даже не покрывает инфляцию... Кроме этого если смотреть сферу других людей, к примеру на заводах то ее опять нету либо ниже инфляции, в торговле на частника тоже индексация может быть или не может, там зп от продаж может зависеть. Самозанятые вообще сами за себя, ИП тоже и так далее...
Прочитайте же вы тот самый ТК РФ и укажите, где там написано,что индексация прям обязательна в негос организациях. Для негос указано,что индексация выполняется по правилам, установленным в нормативке тех самых негос организаций. А у них, обычно, в локальных нормативных актах, которые вы подписываете при найме, указано отсутствие индексации.
Нельзя всерьёз воспринимать нытиков «ты делаешь велосипед, это ненужно». Во‑первых вы им его и не предлагали, во‑вторых они и такого‑то не осилили. Нужно обязательно уметь кидаться вонючим калом, грубо насмехаясь, в человека, который пытается это делать с вами — баланс тупой критики важен. Нужно активно закидывать грязью авторов плохой критики, которой большинство.
Наказуемо вообще-то, вплоть до уголовной.
Нужно обязательно уметь кидаться вонючим калом, грубо насмехаясь, в человека
Мне моя брезгливость дорога,
мной руководящая давно:
даже чтобы плюнуть во врага,
я не набираю в рот говно.
Мир не помнит имён великих тимлидов, но мир помнит имена великих разрабов — Торвальдса, который до старости в коде копается
Великие разрабы, как правило, не только сами код пишут, но и лидируют в большой команде/сообществе, которые вокруг них и собрались.
Все помнят Джобса, но мало кто помнит Возняка, хотя он был великим инженером - электронщиком. Да и имя Видлара широко известно в довольно лишь узких кругах, хотя он, фактически, в одни руки создал всю современную аналоговую микроэлектронику.
Все по сути верно.
Минус один - когда работаешь часов этак 11 в день, и семья - на пет проекты не тянет ( воротит от вида компьютера).
Вроде платят хорошо, но идет постоянная переработка и не успеваешь вокруг посмотреть.
Я поработал за 25 лет в консалтинге, продукте, поддержке (L3) - более менее время было в консалтинге. Да, бывало что летаешь чуть ли не еженедельно, сидишь у заказчика на проекте, но там бывали перерывы для самоподготовки. Хуже всего конвейер в продукте - ты на максимально равномерной загрузке и растешь в узкой сфере, годами в одной нише, ведешь один два проекта
Еще дополнил бы вот чем.
Учитесь не только на пет-проектах. Учитесь на рабочих проектах. Обязательно извлекайте уроки из своих рабочих задач - как позитивные, так и негативные. И учитывайте в следующих задачах. Так вы будете расти даже быстрее чем на пет-проектах. В том числе - в грейдах и в зарплате.
Если сама компания вас еще и учит при этом - так вообще зашибись. А если нет - каждый сам кузнец своего счастья. Учитесь на любых задачах, даже на скучных. Именно так родилась автоматизация :)
В принципе, со многим согласен, кроме пет-проектов) Мне как будто больше делать нечего, чем пет-проектами заниматься))
Смешно и то, что я, ни разу ни одного пет-проекта не сделавший, в итоге с точки зрения капитализма оказался значительно успешнее всех из моего окружения, кто их делал и делает. Мерило простое - мой доход тупо выше.
При этом время, которое я не тратил на строение говна и палок я вполне успешно потратил на создание семьи, путешествия, на гитаре вот научился играть, ходил в спортзал, прошёл 100500 игр и посмотрел 100500 киношек и сериалов с женой и не только. С кайфом, в общем, провёл)
Просто я делаю работу и делаю её качественно. Любое обучение - в рабочее время. Или в процессе выполнения задач. Подход оказался вполне рабочим.
Отличная статья, согласен с большинством пунктов исходя из своего тоже немаленького опыта.
Страшная тайна: большинство успешных бизнесов‑проектов‑стартапов — велосипед. Но сделаный лучше конкурента, тем и ценится.
Всё так хорошо начиналось, но в этом месте вы сломались.
Большинство успешных бизнесов
1. найти нишу
2. Сделат свою "раму от велосипеда" - которая даст ключевое преимущество
3. Всё остальное - сделать из готовых компонент, чтобы сесть на "существующую инфраструктуру".
То есть говоря вашим языком метафор: "большинство успешных бизнесов - это удобные красивые креслица в стандартном РЖД-шном вагоне метро".
Объём завелосипеженого vs объём стандартного взятого просто даже близко не сравним.
Мои советы: Читайте Архитектуру компьютера, Компьютерные сети, Изучайте алгоритмы, структуры данных, дискретную математику, решать задачи на LeetCode
а для подвоза результата к сроку, на который босс забился с заказчиком
А ещё если босс пообещал конкретный срок заказчику - это проблемы самого босса. Даже если вы сами сказали ему эту дату.
Потому что разработка - это не упаковка конфет на конвейере со строго регламентированной скоростью. Тут каждая задача - уникальна. И в каждой попадаются свои подводные камни. И чем больше задача - тем больше в ней встречаются камушки.
Если босс не знает про специфику разработки - это его проблемы. Если он пытается перевесить свои договорённости на вас - это его проблемы. Вы продаёте своё время за его деньги, о чём и был трудовой договор.
Риски не успеть - это риски босса. Это он владеет бизнесом, он управляет обещаниями клиентам, он управляет методами решения этих проблем. Он ДОЛЖЕН разбираться в специфике работы своих сотрудников. Он ДОЛЖЕН брать риски на себя и понимать, чем он рискует.
Со всеми пунктами согласен, кроме 10го. Очень спорный. И я не про бросание говна в оппонента, а про велосипедостроение и про "сперва добейся".
Вот прям со всеми пунктами согласен полностью!
Ещё пара ценных советов:
будьте заметны. Вы можете быть сколь угодно великим разработчиком и пилить гениальнейшие решения, но для остального мира вы примерно никто, так как ни ваших решений, ни ваших умений никто, кроме вашей команды, и не видел. Пишите мелкие (или крупные) статьи, пишите пет проекты, отвечайте на стековерфлоу и линкедине.
Учитесь презентовать себя. Соберите в большой текст все ваши умения, переработайте чтобы получился внятный рассказ о том какой вы молодец. Это не просто перечисление где работали и что делали, а что решали и как и чем помогло капиталисту. Сделайте короткую и расширенную версию и научитесь их рассказывать легко и непринужденно.
Не бойтесь ошибаться.
Хороший текст. Помимо того, что я согласен с содержанием, мне ещё очень понравился язык. От него веет конкретностью.
Не стесняйтесь в выражениях, травите и унижайте глупых критиков, доводите до психоза и депрессии[...]
Вы тут поосторожнее, чтобы не пришлось знакомиться со статьёй 110 УК РФ или эквивалентом в вашей юрисдикции (доведение до самоубийства).
Советы новичкам в карьере программиста