×Закрыть

Плюсы и минусы разных ІТ-компаний. Опыт циничного программиста

Здравствуйте. Меня зовут Владимир Кожаев. Программирую я профессионально (то есть получаю за эту работу деньги) с 2004 года — больше шестнадцати лет. Перед моими глазами прошло много всякого, поэтому с возрастом стал циничен как хирург. В этой статье хочу рассказать о разных программистских работах честно, без приукрашивания действительности — перед чтением налейте себе коньячку. Поскольку пессимист — это хорошо информированный оптимист, описываю я типичные проблемы.

Не нужно настраивать себя, что вот всё плохо и нижесказанное обязательно со мной произойдет (может и нет). Но знать о ямах, что могут встретиться на дороге полезно — можно будет их обойти. Сразу отмечу, что пишу я, во-первых, о работе — не о бизнесе, а во-вторых, о работе в Украине. В других странах может быть по-другому. Чтобы было понятнее, буду проводить аналогии с работой слесаря на производстве. Ведь программирование есть не что иное, как создание, ремонт и эксплуатация программного обеспечения. С другой стороны, хочу, чтобы мне хоть раз в жизни пригодились «заводские» дисциплины, которые программистов заставляли учить в Национальном университете кораблестроения.

Итак, начнем пожалуй.

Допустим, некто ищет работу и получил несколько офферов. Что выбрать? Универсального ответа не существует, как его нет и на вопрос: «Какой автомобиль мне купить?». Давайте пройдемся по возможным типам компаний на украинском рынке и попробуем определиться, что кому подойдёт.

Иллюстрация Ульяны Патоки

Маленькая аутсорсинговая компания

— Почему вы ушли с предыдущего места работы?
— Компания переехала, и мне не сказали куда.
© на собеседовании

Собрались однажды три однокашника и решили открыть своё дело. Вначале апворк, потом нашли одного-двух клиентов, и пошло-поехало. Работу свою они знают, клиент доволен — пришла пора расширяться.

И тут оказалось, что гуманитарные предметы в отечественных вузах преподают ещё хуже, чем программирование. Философию, психологию и педагогику путём переписывания учебника, менеджмент — в лучшем случае на примере обанкротившегося в начале 90-х колхоза «Дурь Ильича». Так что постигать премудрости бизнеса приходится на практике, набивая всевозможные шишки и одновременно накапливая жизненный опыт. Вот список самых распространенных бизнес-ляпов. В той или иной степени ими грешат все новообразованные конторы.

  • Невыплата или задержка зарплаты, невыполнение обещаний. Ну не понимают люди, что репутация — самое важное в бизнесе. Но ничего, жизнь быстро научит.
  • Автоматический перенос своей психологии на чужую: я готов программировать с утра до ночи и соискатель тоже готов. Я понял задачу — и работник понял.
  • Вера в свою исключительность, максимализм: в мою чудо-фирму я возьму только супермотивированных и пассионарных специалистов. Как ты не готов неделю делать тестовое задание без всяких гарантий? Нет... такой работник не нужен!
  • Общая неорганизованность и бардак. В одной фирме, где я работал много-много лет назад, при переезде забыли нанять в новый офис уборщицу. Пол не подметался три месяца (!!!), пока арендодатель не поставил вопрос ребром: уборка или на выход!

Кому подойдет такая работа? Правильно: студенту последних курсов программистской специальности. Что-то умеет, уже писал приложения «для себя», но коммерческого опыта (за который платят) мало либо нет вообще. Куда-то получше его вряд ли возьмут, а у вышеописанных товарищей выбора нет — денег поначалу не густо. Да, могут кинуть с последней зарплатой. Может статься ещё веселее: в понедельник приходишь на работу, а дверь закрыта. Подождал-подождал, пошёл узнавать и услышал: «Ваш начальник в субботу забрал вещи и отдал ключи». Такое случилось с одним из знакомых. Что это было, он не знает до сих пор.

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

У работы в маленьких компаниях есть ещё один плюс: их никто не знает.

Появляются и уходят в историю очень часто, поэтому врать в резюме можно не особо стесняясь: проработали год — пишем два, дописываем в резюме технологии, с которыми может и не работали, но читали книжки. Эйчар более серьезной конторы не станет звонить в «Три хлебных корочки»: «Что там джуниор Вася, работал у вас с Docker или только слышал о нём?».

И даже если оттуда уволили за плохую работу, никаких последствий для карьеры не будет. Ну ушёл ты из фирмы «Рога и копыта», никого не убил, ничего не украл и ладно — других дел по горло, чтобы ещё джуниора какого-то пристально проверять. Проведу аналогию, допустим, на завод принимают молодого слесаря. Напильник в руках держать умеет, не пьющий, приводов в милицию нет и особых проблем со здоровьем тоже. Станут в отделе кадров докапываться, что там произошло у него в маленькой мастерской и почему он оттуда уходит? Нет. «Хочу работать на большом заводе, расти профессионально, иметь спецодежду, положенный по закону отпуск, получать аванс и зарплату первого и пятнадцатого числа, без задержек. Я слышал у вас это всё есть», — такой ответ идеально подходит. Кроме него на работу устраивается единовременно человек 20. Собирать досье на каждого, как в контрразведке? Ага-ага, болты во время скрупулёзных проверок кто будет точить? Люди сейчас нужны — не через два года.

Гиганты рынка

«Умные нам не надобны, надобны верные» © Аркадий и Борис Стругацкие, «Трудно быть богом»

Их отцы-основатели начали работать ещё в 90-х, прошли огонь, воду и медные трубы, настроили процессы, отточили найм, поэтому бизнес цветет и пахнет. Озаботившись прибылью не только теперешней, но и думая стратегически, гиганты вкладываются в образование: создают курсы с последующим трудоустройством. Одна беда: конкурс на одно место больше, чем в космонавты, поэтому совсем без опыта, скорее всего, не возьмут. Количество мест на курсах ограничено — отбирают лучших. А так для людей уровнем до синьора гиганты полезны.

Всё вроде бы хорошо, но где ложка дёгтя? А вот она: лидеры рынка сами ничего не разрабатывают — только предоставляют персонал для иностранных фирм.

Соответственно, им важно чтобы:

  1. Заморский работодатель был доволен, то есть чтобы не сказал: «Этот Василий мне не подходит — несите следующего».
  2. Разница между расходами на человека и доходом была максимальной.
  3. Тратиться на найм как можно меньше. То есть чтобы на одном месте работник держался подольше и не воротил нос от устаревших технологий или переработок.

Что из этого следует: крупному аутсорсу люди с навыками сильно выше среднего не нужны. И платить такому следует больше, и увольнения высококвалифицированный работник не опасается, напротив, чаще смотрит по сторонам. А значит, добавить обязанностей за те же деньги не выйдет.

Например, в одной крупной конторе недавно сказали: «У нас коронакризис, сокращение персонала, американские сотрудники не справляются. Поэтому, кроме программирования, вы теперь будете выполнять функции поддержки. По вечерам и по выходным обязаны зайти в рабочий аккаунт и посмотреть, есть ли у клиентов проблемы. Если да — оперативно исправить». Естественно, без повышения оплаты. Что бы было, если бы там работали гуру? Стали ли бы они бесплатно тратить свои выходные на рутинные операции?

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

ПМ: Работа состоит в том, чтобы переписать какую-то подсистему банка с совсем древней технологии на Java 8 + servlets (то есть устаревшим этот код становится в момент создания). Зачем это делать? Потому что кто-то на стороне клиента так решил. Ещё у нас бывают разные митинги. Необходимость тебе там присутствовать сомнительна, но заказчик требует, чтобы были все. Денег средненько: по рынку для разработчика, но не выше. Будет ли комфортно работать в этом проекте?

Я: Программирую за деньги. Если мы договоримся, буду выполнять свою часть контракта.

Приходит отказ: «У Владимира отсутствует другая мотивация, кроме финансовой — не подходит».

И я прекрасно понимаю ПМ’а. Он же не может сказать: «Владимир, конечно, опытный разработчик, умеет не только код писать, но выяснять требования, думает о проекте в целом, а не так, чтобы сделать вот эту задачу и хоть трава не расти. И вообще, знает математическую лингвистику! Но, возможно, понадобится поработать на выходных. Он фрилансер, почти бизнесмен. Бесплатно перерабатывать не привык и откажется. Мне объяснять заказчику, почему все другие согласны овертаймить бесплатно, а Кожаев — нет. Потом есть не нулевая вероятность, что ему предложат за узкие знания денег в два раза больше. Повысить аж настолько я не смогу, даже на время, пока не найду нового, ведь бюджет не резиновый. Он свалит, а я должен придумывать причину, по которой я не удержал на проекте хотя и немного строптивого, но нужного нам программиста. Решать, кем его заменить, за короткий срок. Поэтому поищу-ка я пусть не такого опытного, зато послушного и без претензий».

Возвращаясь к нашему слесарю, давайте подумаем: стоит брать на опиливание типовой детали #1 слесаря высокого разряда, умеющего шлифовать лопатки турбин? Кто не в курсе, работа это сложнейшая и очень ответственная. Чуть оплошаешь — и турбине конец. Специалисты даже собственное тавро имеют, мол, шлифовал такой-то. Будет ли такой слесарь делать все, что скажут, в условиях далёких от идеальных? Можно его при необходимости запрячь на бесплатный субботник? Не скажет ли он, мол, мне за это не платят, и пойдет пиво пить?

Есть ли в лидерах рынка проекты, где требуются знания выше среднего? Да, но платят за них похуже, чем, скажем, за работу на банки с легаси-технологиями — не их профиль. Опять же мне недавно предлагали разработку трансляторов с одного языка программирования на другой. И в той же конторе банковский проект за сильно больше денег. Напирали: «Работа ну очень интересная! Разовьёт вас профессионально. Может, вы подумаете?». Когда выяснилось, что я уже написал таких трансляторов с десяток, для меня это рутина, что, возможно, это их разработчикам интересно у меня поучиться, рекрутерша погрустнела.

Выходит, получение новых знаний выше какого-то уровня не имеет смысла? Нет ведь, есть...

...Продуктовые и узкоспециализированные компании

Занимаются развитием одного, реже нескольких продуктов либо продают консалтинг в узкой области. Поэтому по оплате они не ограничены внешним рейтом (ради хорошего человека могут временно и в минус уйти) еще и заинтересованы в высокой квалификации программистов. Чем выше, тем лучше. Это всё плюсы, а минусы?

Дело в том, что для таких фирм лояльность важна ещё больше, чем для аутсорсинга. И не потому, что бюджет ограничен. Причина другая: их товар — экспертные знания разработчиков. Например, занимаетесь вы разработкой SIP-мессенджеров или развиваете OLAP-систему. Можно найти в одночасье специалиста с такими знаниями? Нет! Ещё хуже, если это архитектор, такого только готовить внутри компании. Причем несколько лет! Оплачивать конференции, давать пробовать разные подходы, терять на архитектурных просчетах. А как вы думали, не ошибается тот, кто ничего не делает. Особенно если речь об учебе.

И представьте, человек, которого вы натаскивали, увольняется. Сколько потеряно денег? Вот именно!

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

Вот вам пример: разработка культовой игры «Казаки». Вы помните, кто там отвечал за искусственный интеллект персонажей, игровые стратегии? Между прочим, добиться плавного повышения сложности уровней — задача тяжёлая. В условиях постоянной нехватки времени разработчику небось приходилось забить на личную жизнь и на хобби — буквально не спать ночами. А выхлоп какой лично для него? Платят, возможно, чуть больше, но стал ли он миллионером? Или, может, его узнают на улицах? Кричали женщины «ура!» и в воздух чепчики бросали? Не бросали!

Лет пятнадцать назад я ещё был таким вот восторженным идеалистом: нам хлеба не надо, работу давай. Сейчас лапша с ушей спала. Хочу просто денег и не слишком упахиваться в процессе их заработка.

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

Если вспомнить слесаря, можно сравнить с работой на экспериментальном заводе. Платят неплохо, но долго учиться, и если этот завод закроется, то на другом придется начать всё сначала.

И остаётся фриланс.

Фриланс и удалённая работа

«Не звоните нам, мы сами вам позвоним» © из собеседования актеров в Голливуде

Подходит только для опытных, которые могут не только выполнить задачу, но и рассказать заказчику, что именно и каким образом нужно сделать. При том так, чтобы он захотел заплатить и сделал это. Начинающим во фрилансе не место, зато опытный специалист может работать из любого места и сколько хочет, был бы интернет. Летом часть времени я живу на юге, и отпрашиваться у менеджера мне не нужно. При этом потолок оплаты выше, чем в офисе — с галерой-то не надо делиться. Технологии тоже какие хочешь. К примеру, я разрабатываю компиляторы, трансляторы, парсеры, IDE и прочее Rocket Science. Такой работы на Украине очень не много, всё больше CRUD и формошлёп.

Но есть и ложка дёгтя. Во-первых, проекты нужно искать самому и по окончанию никаких гарантий, что будет другая работа. Во-вторых, за работу ты конкурируешь на глобальном рынке труда. И внезапно оказывается, что для решения распространенных задач типа написать мобильное приложение или создать бэкенд на Java, или сварганить сайт, на Upwork можно найти исполнителей гораздо дешевле украинского рынка труда. Предположим, ты программист Java. Знаешь спринг, хибернейт, базы данных, работал с докером и ещё можешь пилить фронтенд.

В Киеве за такого орла-мужчину томные девы с чарующим размером груди будут буквально драться, лишь бы оффер принял. Но на сайтах фриланса гордых Full Stack разработчиков из Пакистана, Индии, Вьетнама etc больше, чем в Бразилии обезьян, и работать они согласны по очень сходной цене. На более-менее интересное предложение может откликнуться до тысячи (!!!) разработчиков. Готовы к такому конкурсу? Милости прошу во фриланс!

Можно, конечно, как я изучить совсем уж заумную штуку типа математической лингвистики, тогда конкурентов у вас не будет. Но и тут не без подвоха: как думаете, многим нужны новые языки программирования? То-то же! Я или нужен, тогда походи по рынку и поищи дешевле, либо не нужен вообще. Так что простои у опытного фрилансера — нормальное явление: нужно иметь кубышку на три-шесть месяцев. Для того чтобы перерывы были поменьше, необходимо шевелиться: писать статьи, выступать на конференциях и так далее. Вы думаете, зачем я эти статьи пишу? Потому что добренький — ага, сейчас!

Есть ещё одна проблема: сложную работу многие предпочитают делать у себя под боком. Я как-то подался на вакансию разработчика в дружественную компанию. Они читают мои статьи на английском, иногда обращаются за советом, но ... вакансия в Германии. Хочешь, говорят, приезжай. Из Украины мы не можем, чтобы ты работал: заказчики хотят наличия специалиста в их стране.

Более того, если вы захотите вернуться в офис, фриланс может оказаться минусом. Был такой случай: пригласили меня на работу, найдя по статьям. Поговорили, вроде всё здорово. Но потом тот, кто меня нанимал, пишет: «Извини, тебя взять не можем. Главный начальник против человека с длительным фриланс-опытом». Да, понюхавших свободы не все хотят — слишком уж независимые. Это ещё называют отсутствием командного духа, читай: прогнуть на бесплатные овертаймы нельзя.

Наш опытный слесарь может открыть свою лавочку и выбирать: чинить замки, прочищать унитазы или делать оптику разного рода. Второе, конечно, поинтереснее, в том числе и финансово, но это, если найдешь клиентов.

Ну что ещё можно: открыть свой бизнес, стать менеджером или уехать за границу. Но это уже совсем другая история.

LinkedIn

Лучшие комментарии пропустить

Спасибо за статью. В общем и целом согласен. Есть пару ремарок.

Лично я считаю, что не стоит до конца дней расти в гребле. После определенного уровня (10-15 лет) однозначно нужно уходить в архитектуру и экспертизу. Архитектура и экспертиза — это самые проблемные места в любой конторе, без исключений. Все хайповые ЯП и фреймворки — это пыль на ветру («Dust in the wind») и только построение сложных архитектур и экспертиза от очень опытного специалиста становятся все ценнее и дороже с годами, как выдержанный коньяк ))

При поиске новой работы не стоит себя позиционировать, как опытного гребца. Это и так понятно. Нужно себя «продавать», как опытного инженера и человека, который не код пилит от «забора до обеда», а еще и как специалиста, который решает проблемы бизнеса. Вовлекаясь в сам процесс.

Лично я бы не хотел за большие деньги разгребать какой-то древний легаси. От этого быстро выгорают. Поэтому лично для меня сам проект имеет большое значение не менее денежного вознаграждения.

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

При найме нужно сразу понимать, что из себя представляет заказчик и его бизнес. Это стартап или перевод офлайн бизнеса в онлайн. Если первое, то высока вероятность, что после MVP всех отправят по домам. Второй вариант — это самый идеальный. Реальная разработка продукта под готовую бизнес модель. С развитием и поддержкой. Если заказчик не особо адекватный человек и это сразу видно по первому разговору, то нормальной работы не будет. Нужно не соглашаться на офер и искать дальше.

Фриланс — это не свобода! Это очень длинная цепь на ноге. Вечный поиск, разные люди, разношерстый зоопарк технологий и т.д. — это явно не то, что нужно опытному специалисту.

Если при поиске работы встречаются одни неадекваты на конторах, то из этого автоматически не следует, что так везде и всюду. Нужно не отчаиваться и явно что-то менять в подходах поиска хорошего места.

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

Спустя многое годы нет никакого смысла распыляться и хвататься за разные технологии и разношерстные задачи. Как я говорил выше, нужно усиливать свою экспертизу. И усиливать в наиболее стратегических видах бизнеса (онлайн продажи товаров и услуг в любых их ипостасях). То есть взять средне узкую нишу и стать в ней сильным экспертом.

Итого, нет смысла конкурировать в гребле с молодыми — это путь в никуда. Но есть смысл уходить в архитектуру и экспертизу, так как каждый выполненный проект — это левел ап к скилам и экспириенсу независимо от технологий.

Желаю удачи и всех благ. Не выгорайте и получайте удовольствие от работы!

Кожаев Вова — молодец, политик, лидер и боец.

Люблю я статьи от Кожаева. Хотя бы потому, что хоть они и субьективные, но в них нет всего того булщита, который любят щедро наливать разные эйчары, менеджеры и всякие любители гештальтов, на этом ресурсе.

Я бы назвал бы этот материал «критический взгляд на отрасль без идеализации».
Материал хоть и не бесспорный, но очень важный — не хватает нам всем определенной доли здорового скепсиса, особенно в публичной плоскости.
Большое спасибо !

418 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Примеры надо было не на слесаре приводить, а на каком-нить барбере или барристе, чтоб местные синьоры 2000х годов рождения понимали

Вот прочитает твой внук этот комментарий, обидится, и в следующий раз откажется помогать, когда ты ему будешь звонить с вопросами типа «как в етом вашем смартхвоне в поликлинику записаться?» :(

Нехотелось бы переходить на конкретику, но ...
Рядом в топике статья — «Путеводитель по синдрому самозванца...»
Просто интересно, скольким читателям ДОУ этот трэш будет более интересен, чем данная статься, от Володимира?

Володя, спасибо за статью, все (почти все) как говорится, «в точку».
На самом деле приятно почитать статью, основанную на огромном опыте в ИТ, где нету всякой «околоайтишной» мишуры и бесконечного разжевывания проблем/успехов поуехавших товарищей.

Надо будет опять конкурировать с молодыми, а это в возрасте ой как не просто: и здоровье похуже, и голова уже варит не так.

Фігня повна. Голова варить дійсно не так, набагато краще та ефективніше ніж в молодших. Головне — не давати мозку мислити стереотипно. Це є найбільшою проблемою. У доросліших кількість зв’язків більша та ширша. Мозок дорослого, при умові, якщо він дійсно напружувався та намагався вирішувати складніші задачі з кожним разом, може оперувати вищими рівнями абстракцій та легше знаходить тотожності.

Но ты не можешь и не хочешь овертаймить, молодые готовы

Я чет не был готов овертаймить никогда, это скорее от человека зависит, ну и соблазн получить х2-х3 может сломать самых главных противников овертайма

Молодые часто готовы овертаймить бесплатно.

я, будучи студентом, отказывался овертаймить

Главное им не мешать — пускай овераймят, коль енергию некуда девать. Правда выгореть могут.

Можу й хочу. Але в цьому немає сенсу. Молоді за мною все одне не встигають.

Але, овертайм — неефективна бізнес-стратегія. Зазвичай овертайми — це наслідок недоліку знань, досвіду, переоцінки власних сил. А це все притаманне молодим, а не досвідченим. Вони не мають досвіду, який би зробив їх оцінки бюджету точнішими, тому постійно попадають в халепу. Немає й знань побудови різних архітектур, щоб передбачити факапи до їх появлення. Якщо мені запропонують овертайми, я запропоную у відповідь покращити оцінки та не перекладати відповідальність на кінцевого виконавця. Я краще зроблю так, щоб овертаймів більше ніколи не було.

Якби хтось наважився написати статтю з назвою приблизно

Плюси і мінуси різних ІТ-спеціалістів. Досвід цинічного власника галєри

То мабуть би в таких цинічних програмістів почало бомбити)))

PS: Мабуть дуже весело працювати з тіпом, який весь час думає, як тебе кинути або як тобі його кинути, щоб вже нарешті поїхати за граніцу в закат)))

А вот тут ошибка: мошенничать не выгодно. Я не смотря на весь свой цинизм никогда таким мне занимался

Та не завжди кидок це про гроші
Просто гроші в твоїй системі координат це найважливіша річ (ну так виглядає)

Мошенничество это всегда в конечном итоге о деньгах.

То мабуть би в таких цинічних програмістів почало бомбити)))

Не напишут. Бо потом будут иметь проблемы с наймом.
Программистам проще — можно писать практически что угодно, интересующие тебя компании всё равно тебя наймут. Потому что спрос на рабочую силу превышает предложение.

Не напишуть, але це і не означає, якщо є попит на цинізм серед працівників, то він не появиться серед роботодавців

то він не появиться серед роботодавців

Так он и есть.
Цель бизнеса — получение прибыли. Всё остальное — средства её достижения

PS: Мабуть дуже весело працювати з тіпом, який весь час думає, як тебе кинути або як тобі його кинути, щоб вже нарешті поїхати за граніцу в закат)))

Якось так :)

Кто и кого кидает?
Кидают лохов, рассказывая им про «высокую миссию» и «изменение мира». Взрослые люди прекрасно понимают друг друга и суть сделки. И никто ничего крамольного в этом не видит. Сделка продолжается, пока её условия устраивают обоих её участников.

Кто и кого кидает?

Працівники роботодавців, роботодавці працівників
В Україні цим пронизані мабуть усі види діяльності, починаючи від всяких заводів, закінчуючи айті, яке би мало на мою думку відрізнятися
Але спілкуючися з такими експонатами розумієш, що ще не почавши співпрацю (таке слово є, співпраця, коли двоє співпрацюють), вже хтось когось вважає лохом :)

Працівники роботодавців

Максимум чем рискует работодатель — заплатить за работу не соответствующего качества, после чего уволить сотрудника и нанять другого.

роботодавці працівників

Максимум — чем рискует работник — месяцем своей работы, за которую ему не заплатит недобросовестный работодатель.

Ни одно, ни другое не является катастрофой для того, кого кинули. Но запросто сможет стать долгосрочной проблемой для того, кто кидает. Посему, такое не распространено даже в Украине.

В Україні цим пронизані мабуть усі види діяльності

Давайте в рамках этого топика сконцентрируемся на айти?

вже хтось когось вважає лохом :)

Ну если человек сам себя обманывает, то нет ничего такого в том, чтобы нарисовать ему ту реальность, которую он себе видит. И на этом получить от него больше прибыли. Вполне ок.

Максимум чем рискует работодатель — заплатить за работу не соответствующего качества, после чего уволить сотрудника и нанять другого.

Я так розумію в тебе є досвід побудови компанії і ти знаєш чим максимум може роботодавець ризикувати. Я можу запросто сказати, що максимум чим роботодавець ризикує це представити клієнтові якогось мудака, який хоче переписувати архітектуру, коли хоче, хоча його наймали на інші задачі (скажімо писати фічі для якоїсь важливої демки чи тендера)
Поки цей геній шота-там пиляє тіпуля, який планував, що ця фічя буде готова, то втратив $суму-тендера (а це не $5k баксів, що рівне одній зпшці середнього сініора, як тут прийнято вважати)

Максимум — чем рискует работник — месяцем своей работы, за которую ему не заплатит недобросовестный работодатель.

Знову ж таки, можна запропосто уявити інакший максимум. Тіпуля вибирав між двома роботодавцями. Вибрав одного — він виявився мудаком. А другий виявився не мудаком, а поїзд вже пішов. Хоча працівнику подобалися два продукти і він жаліє за потрачений час і можливості (мабуть оцінити можливості буде складно, але це точно більше ніж одна зпшка). Але я більш ніж впевнений що в тебе вже бомбить від цього, бо ти скажеш щось в стилі «можливості-ко-ко-ко фігня то всьо» :)

Ну если человек сам себя обманывает

Усі професіонали розумію, що робота це про гроші
А ось такі українські професіонали вічно шукають десь падвох, хто там на кому заробляє, хто там кого хоче кинути і так далі. І атмосфера в такому колективі такоє.

представити клієнтові якогось мудака, який хоче переписувати архітектуру, коли хоче, хоча його наймали на інші задачі (скажімо писати фічі для якоїсь важливої демки чи тендера)
Поки цей геній шота-там пиляє тіпуля, який планував, що ця фічя буде готова, то втратив $суму-тендера

В такой ситуации сразу возникают два вопроса:

1) А менеджер проекта / тим лид в какую сторону смотрел в это время?

2) А в какую сторону смотрел тот, кто принимал решение нанять на ответственную должность молодого горячего «переписывателя» без должного контроля принимаемых этим «переписывателем» решений со стороны старших опытных товарищей?

В такой ситуации сразу возникают два вопроса:

Та багато виникає питань, просто я це пишу більше для Станіслава :)

А придумати відповіді не є дуже складно :)

1) А менеджер проекта / тим лид в какую сторону смотрел в это время?

Захворів. Коли як не зараз це може бути актуально. Понадіявся на професіоналізм чувака, якому платять 5к баксів :)

2) А в какую сторону смотрел тот, кто принимал решение нанять на ответственную должность молодого горячего «переписывателя» без должного контроля принимаемых этим «переписывателем» решений со стороны старших опытных товарищей?

На папері тіп виглядав добре
На співбесіді тіп виглядав добре
Але в душі був гнилий і прийшов бо тут платять 5к)) Притворитися на співбесіді в українських реаліях доволі просто :)
Плюс саме Станіслав десь тут описував свій досвід про те, як він прийшов, щось переписав і пішов з проекту :)

Захворів. Коли як не зараз це може бути актуально. Понадіявся на професіоналізм чувака, якому платять 5к баксів :)

Болезнь, разумеется, может и будет уважительной причиной.

А вот «понадеялся на профессионализм, положившись на уровень зарплаты» — точно нет.

На папері тіп виглядав добре
На співбесіді тіп виглядав добре
Але в душі був гнилий і прийшов бо тут платять 5к)) Притворитися на співбесіді в українських реаліях доволі просто :)

Именно поэтому ни один вменяемый менеджер не доверит свеженанятому сотруднику принимать какие-либо критичные решения без присмотра. Хоть каким бы соловьём тот не заливался на собеседовании.

А вот «понадеялся на профессионализм, положившись на уровень зарплаты» — точно нет

Зустрічав таке достатньо разів) Десь це було на високому рівні, десь на низькому

Именно поэтому ни один вменяемый менеджер не доверит свеженанятому сотруднику принимать какие-либо критичные решения без присмотра. Хоть каким бы соловьём тот не заливался на собеседовании.

Мені влом шукати камєнт Станіслава, де він написав, що він там щось нарефакторив, це комусь там не сподобалося і він сказав давай-дасвіданія))

Як на мене суті це не міняє)
Я більш, ніж впевнений, що є достатньо спеціалістів, які можуть n-місяців поводитися нормально, менеджер трошки більше делегує такому спеціалісту, появляються ще якісь обовязки, ньюнаси, проблеми і цей спеціаліст пів дня займається інженірінгом/дотою/ютубчиком, а потім спихає вину на менеджера і каже всім давай-дасвіданія і чеше на іншу роботу))
Якщо брати до уваги, що скажімо проект може бути на 1-2 людини, то вибір у менеджера невеликий, кому дати писати цю фічю/емвіпі/пруф для демки/тендера)

менеджер трошки більше делегує такому спеціалісту, появляються ще якісь обовязки, ньюнаси, проблеми і цей спеціаліст пів дня займається інженірінгом/дотою/ютубчиком

Делегирование не означает отсутствие контроля за происходящим. Это ошибка (порой, фатальная для проекта), которую допускают многие начинающие менеджеры.

проект може бути на 1-2 людини, то вибір у менеджера невеликий, кому дати писати цю фічю/емвіпі/пруф для демки/тендера

У менеджера, вместе с тем, есть выбор, вникать или не вникать в то, куда движется написание этой фичи/MVP/пруфа.

Равно как и обсудить со специалистом план действий в условиях жёстких ограничений по срокам / бюджету.

камєнт Станіслава, де він написав, що він там щось нарефакторив, це комусь там не сподобалося і він сказав давай-дасвіданія

Если этот рефакторинг не был заранее согласован, и на него было потрачено больше проектных часов, чем запланировано — естественно, руководителю проекта это могло не понравиться.

И люди, публично бравирующие позицией «я буду делать только так, как я захочу и сочту правильным, а если кому не нравится — давай досвидания» — делают себе медвежью услугу даже в условиях нехватки специалистов.

P.S. Если, конечно, речь о каких-то относительно глобальных изменениях, а не о «вынес вот эти повторяющиеся пять строчек кода в отдельный метод / функцию»

и на него было потрачено больше проектных часов, чем запланировано

Было потрачено 4 часа из одного дня, выделенного на ознакомление с проектом

Если этот рефакторинг не был заранее согласован, и на него было потрачено больше проектных часов, чем запланировано — естественно, руководителю проекта это могло не понравиться.

Ну ось про це і мова)
Менеджер більше ризикує (мені так здається) перед вищим менеджментом своєю репутацією, різного роду КРІ, всякими бонусами і так далі
Зазвичай менеджери більш склонні до того, щоб будувати карєру, особливо на великих компанія типу Серву, Епаму та й ж вашої Сігми
А девелоперу що? Сказали що він
а) мудак, бо зробив не те, що домовилися
б) мудак, бо тех-лід сказав, що його код такоє
в) будь-який варіант де наїхали на чсв сініора (в сучасних реаліях вже мабуть навіть не обовязково, щоб сініора)
він бідака обідився і пішов на іншу компанію, лишивши роботу на половині, створити репутаційні проблеми, коли менеджер має іти до замовника/вищого менеджмента і пояснювати цю тупарилу ситуацію
особливо мабуть неприємно, коли цей менеджер вкалував 9 місяців для бонусів, потім десь недогледів, що цей тіп мудак (був загружений) і цей супер архітєкт за 2 місяці створив проблем, як вся команда протягом останніх 9 місяців :)

бо цей тіп не «лох» і йому всьо по-барабану (читай він цинічно ставиться до такого роботодавця), зібрав манелі і пішов на іншу галєру))
і той місяць останній, який типу він має відпрацювати він запросто може вилізти на голову і пів дня грати теніс)))

Зазвичай менеджери більш склонні до того, щоб будувати карєру

Правдоподобно. И, вместе с тем, если менеджер склонен обзывать разработчиков мудаками — то с карьерой у него вряд ли сложится.

У тех лида, кстати, тоже.

Можно же и корректно объяснить, что мы ценим твои старания сделать код лучше, но есть вот такие-то реалии проекта, которые объективно очень сдерживают нас в этом желании.

Тут другое — на подобного рода проекты, возможно, изначально не нужно нанимать романтиков-перфекционистов.

цей менеджер вкалував 9 місяців для бонусів, потім десь недогледів, що цей тіп мудак (був загружений) і цей супер архітєкт за 2 місяці створив проблем

Если менеджер недосмотрел за деятельностью ключевого технического специалиста на проекте, то, чует моё сердце, говнокод — не самая большая проблема на этом проекте (а то и в этой компании)

Если менеджер недосмотрел за деятельностью ключевого технического специалиста на проекте, то, чует моё сердце, говнокод — не самая большая проблема на этом проекте (а то и в этой компании)

Чому він обовязково має бути ключовий?
Менеджер має скажімо тімку з 20 людей
Наймають ще двох під можливий ріст: сініор-памідор 5к, джун-обикновєнний 1к
Кидають їх на якийсь баг-фікс на 1-2 місяці на якийсь один з 5 старіших проект, ну так щоб роздуплилися
За той час тіпуля, який реально шарить цей проект звільнився, захворів, ще якась причина, яка обумовлює його недоступність
Клієнт просить напиляти демку для одного з потенційних замовників саме на базі цього старішого проекту, який собі працював, але його так толком знав один тіпуля
Так буває
Менеджер дає цьому сініорі-памідору карт-бланш зробити цю демку, причому сініор-памідор божиться, що він супер девелопер (в нього як не як 10 років досвіду і 5к зпшка)
Менеджер має мороки на основних проектах, які приносять зараз гроші (так само як і замовник)
Помідорчик декілька днів\тижнів дає інформацію, що все окей, вроді там щось робиться, навіть робить якісь інтернальні демки, де вроді є видимий прогрес роботи
Потім йому (памятаємо що це цинічний девелопер) щось зайшло і він вирішив прикрутити до демо версію OAuth2 як у фейсбука, бо йому цікаво і він сам собі вирішив, що він встигне :)
У менеджера вже є відчуття кредабіліті у цього помідора, адже до зараз все було ок
Демо-тайм...Звук барабанів...Щось не працює...
Девелоперу кажуть харе займатися фігньою з OAuth2, дороби демку, це зараз нікому не потрібно
Він обідився і пішов в закат) Це тривало хай 5-6 тижнів) До тендера лишилося 2 тижні)
Тендер програний
Цинічний девелопер вже працює в Грузії споглядаючи закат
Менеджеру в кінці року нічого не світить :)
Ось така байка))

Менеджер дає цьому сініорі-памідору карт-бланш зробити цю демку, причому сініор-памідор божиться, що він супер девелопер

Ну вот я же и говорю — если карт-бланш даётся только на основании «крест на пузе жёлтой краской», то менеджер сам себе злобный Буратина.

Это уже не говоря о том, что «супер-девелопер-сеньйор-помидор» в украинских реалиях, увы, ещё не означает врослого и ответственного отношения к делу — даже при безупречных hard skills.

Именно поэтому, «делегировать» (а, по факту, пускать на самотёк) ответственные задачи свеженанятым разработчикам без должного контроля — слабоумие и отвага.

По крайней мере, без очень тщательного входного контроля soft skills при найме. Но, в такой контроль мало кто умеет, и 100% гарантии «нежданчиков» всё равно нет.

Так відбувається не завжди, ой далеко не завжди
Це коли видаєш бажане за реальне
Можливо персональний досвід буде відрізнятися від людини до людини, але в час кадрового голоду компаній, коли по 100 відкритих вакансій на вже існуючі проекти, коли, що вже тільки не роблять для сініорів-помідорів, а вони далі крутять носами, девелопер може дуже просто стати в позицію цинічного девелопера і піти коли хоче

Можна звичайно набрати собі на 1-2-3 чи навіть 10 проектів ідеальних людей, зі всіма потрібними скілс, мати супер продуктивну і взаєморозуміючу тімку, але чомусь мені здається, що всі розуміють, про яких спеціалістів я зараз говорю

Робота сама не зробиться
І коли в тебе є тільки такі кадри, в тебе вибору може і не бути — ти робиш роботу з тими ресурсами, яких ти собі можеш позволити

В сферичному вакуумі звичайно такий менеджер всі ризики прорахує і все буде добре)) Але в житті часто стаються «нежданчики», хоча по факту це можуть бути план з самого початку, коли цинічний девелопер планував одразу кинути кантору-лоха :)

Одного не пойму — а какой смысл даже циничному разработчику заниматься именно целенаправленным «кидаловом»?

Капризничать и «крутить носом» — ещё могу понять смысл. Но и то, только в краткосрочной перспективе. Потому, что если эти капризы и неадекватное поведение приобретут массовый характер, то в Украину просто перестанут заходить проекты (тупо потому, что проектов, которые бы на 100% удовлетворили амбиции подобных синьйоров-помидоров, всегда будет меньшинство из отдаваемых на аутсорс)

какой смысл

Я мабуть частіше в житті спілкуюся з простими смертними (девелоперами). Бо в моєму отеченні є якась маленька закономірність, що коли менеджер будь-якого рангу починає більше спілкуватися з менеджерами, то не знає про якісь прості турботи девелоперів (або знає менше)
Мені здається це очевидно, але я спробую енівей
Цинічні девелопери (на мою думку з мого досвіду) не розуміють в корні слова співпраця. Вони розглядають співпрацю з роботодавцем, як з таким собі ворогом. В кращому випадку це power-games (хто кому більше потрібен: я галєрі чи галєра мені). І як тільки цинічний девелопер відчуває, що йому галєра стає більш потрібна, він одразу хоче отримати статус кво (чи це шантаж зп, чи якісь супер архітектурні рішення, щоб показати ось я 10+ років досвіду, 5к зп, дивіться)

то в Украину просто перестанут заходить проекты

Помоєму в статті автор дав зрозуміти, що його це не гребе. Він поїде або в Польщу, Грузію, ватевер. Він знає, що він собі роботу знайде, а тут після нього хоть потоп

удовлетворили амбиции подобных синьйоров-помидоров, всегда будет меньшинство из отдаваемых на аутсорс

Знову ж таки я говорю про цинічних програмістів
Вони філософствують так, що їм добре тоді, коли решті погано
Чим більше кругом дибілів, тим краще для них, бо вони тоді цінний спеціаліст :)

не розуміють в корні слова співпраця. Вони розглядають співпрацю з роботодавцем, як з таким собі ворогом.
Вони філософствують так, що їм добре тоді, коли решті погано
шантаж зп

Звучит как прямая дорога в чёрный список в любой уважающей себя компании. И ИМХО странно думать, что в Польше, Грузии или ещё где-то мудаков ждут с распростёртыми объятиями.

автор дав зрозуміти, що його це не гребе

Автор статьи, при всей его одиозности на ДОУ, не топит за откровенное мудачество.

За суровый прагматизм в отношениях с работодателем — да. За work-life balance, смещённый в сторону life — да. Но не за кидалово или откровенно свинское отношение (по крайней мере, если работодатель со своей стороны ведёт себя корректно).

Звучит как прямая дорога в чёрный список в любой уважающей себя компании

Який відсоток компаній робить попередній скринінг спеціаліста? 10%? 20%? Решта бачать вільного сініора, якого можна-треба застафити, вже біжать з оффером, бо скоро буде бонус і можна щось собі купити))
Десь тіпуля налажав (був мудаком), то він і не пише що там працював, а пише що працював на фрілансі або ще якусь байку вигадує. А це є відверта брехня.
Якщо чувак переїжає в нове місто, то можна сказати, що він все починає з нуля (крім топ10 контор, які тіпа мають чорні списки і то я сумніваюся, що вони їх шарять між собою).

Автор статьи, при всей его одиозности на ДОУ, не топит за откровенное мудачество

We could agree to disagree

За суровый прагматизм в отношениях с работодателем

Кожен спеціаліст в цей прагматизм буде вкладати зовсім інакший сенс

Все, що тобою (надіюся нічо страшного, що я перейшов на ти) написано є реальністю, але такою з «тих кращих». Але є багато випадків з «тих гірших». З мого досвіду ось ці цинічні програмісти, які працюють тільки у власних інтересах не є командними гравцями від слова взагалі. І не є так просто дізнатися чи вони насправді такими є) Скільки співбесід не проводь, можна казати одне, а в результаті робити зовсім інше.

свинское отношение

Я таке зустрічав 5+ разів на різних компаніях на різних на своєму шляху. Якщо брати ще історії, які мені розказують мені друзі, коли ми збираємося в барах, то там назбирається таких історій 20+. Я теж «за хороше, проти всього поганого», але такі люди є. Як з такими людьми працювати, щоб мінімізувати ризики — це справа кожного. І не просто так відписали на мій коментар ті спеціалісти, в яких від такого бомбить хоть чуть-чуть)))

Я можу запросто сказати, що максимум чим роботодавець ризикує це представити клієнтові якогось мудака, який хоче переписувати архітектуру, коли хоче, хоча його наймали на інші задачі (скажімо писати фічі для якоїсь важливої демки чи тендера)
Поки цей геній шота-там пиляє тіпуля, який планував, що ця фічя буде готова, то втратив $суму-тендера (а це не $5k баксів, що рівне одній зпшці середнього сініора, як тут прийнято вважати)

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

А другий виявився не мудаком, а поїзд вже пішов.

Есть только один способ это узнать точно — поработать с ним. Так что, поскольку он с первым работодателем поработать не успел, мы достоверно этого не знаем.
И да, в этой ситуации никто никого не кинул.

А ось такі українські професіонали вічно шукають десь падвох, хто там на кому заробляє, хто там кого хоче кинути і так далі.

Мне по барабану кто там на ком зарабатывает. Условия сделки просты: вот работа, вот деньги.

Если у клиента хватило ума нанять предыдущего пейсателя, который положил 1500 строк бизнес кода прямо во вьюху, то любой нормальный человек скажет :"или мы переписываем это дерьмо, чтобы с ним можно было работать, или я принимаю другой оффер, а вы с понедельника любитесь с этим как хотите«.

Большинство клиентов умеют считать деньги. И им в ряде случаев будет целесообразнее (а то и дешевле) нанять того, кто будет править 1500 строк бизнес-кода во вьюхе. Особенно, если исправления в обозримом будущем предполагаются не сильно глобальные, и объективно подход «переписать всё нафиг» не оправдан.

И им в ряде случаев будет целесообразнее (а то и дешевле) нанять того, кто будет править 1500 строк бизнес-кода во вьюхе.

Разочарую.
1500 строк бизнес кода во вьюхе — это приговор всему проекту.
Конечно он найдёт того, кто будет исправлять баги в этих спагеттинах. Только исправляя один баг, он будет укоренять по 3-5 новых. И 1500 строк сначала превратятся в 1700, потом уйдут за 2000. А когда придёт пора добавить в это какую-то фичу, полезет регрессия такая, что релизы будут переносить до бесконечности. Дальше они наймут ещё разработчиков. И количество говнокода будет увеличиваться ещё быстрее. Ожидания клиентов увеличатся ещё больше, результаты упадут ещё сильнее.
И тогда клиент начнёт искать архитектора. И найдёт. Архитектор посмотрит на всё это и скажет, что единственным решением накопившихся проблем будет... Та-дамм, переписать всё с нуля.

И тогда клиент начнёт искать архитектора. И найдёт. Архитектор посмотрит на всё это и скажет, что единственным решением накопившихся проблем будет... Та-дамм, переписать всё с нуля.

Хороший тру архитектор сможет разобраться в любом говнокоде. :)

Хороший тру архитектор сможет разобраться в любом говнокоде.

Конечно сможет. И насрёт туда ещё больше своего кода. После чего, уволится.

Хороший тру архитектор

в первую голову понимает, где действительно нужно «резать» переписывать, «не дожидаясь перитонита» — и умеет аргументировать это в понятных бизнесу терминах.

А где, пока, можно обойтись более консервативными методами лечения — наступив немножечко на горло своему внутреннему перфекционисту.

А вот излишне частое махание шашкой на тему «переписать всё нафиг» — это, скорее, признак молодого, горячего, и ещё не очень зрелого специалиста, чьё мировоззрение сформировано больше творчеством какого-нибудь дяди Боба / Фаулера / you name it, чем суровыми реалиями бизнеса.

чем суровыми реалиями бизнеса.

Суровые реалии бизнеса — это когда в конце спринта ПО ожидает, что то, что было на спринт запланированно, будет готово к релизу.
Когда проект состоит из говнокода, эта перспектива отдаляется всё дальше с каждым спринтом.

Стесняюсь спросить: а при планировании спринта фактор говнокода не учитывается?

Клиент при планировании спринта явно ожидает услышать что-то лучше, чем «ну мы попробуем успеть поменять местами эти 2 скрина в навигации до конца спринта, но не гарантируем, что к демо оно будет работать, говнокод, понимаете ли у нас тут».
Если такое сказать, менеджер позовёт на Ван ту Ван, на котором скажет, что ты что-то перформишь плохо и если не успеешь, придётся тебе влепить лоу перфоманс. Никто, естественно, не будет слушать сопли про тысячи строк бизнес логики во вьюхе. Посему, в такой ситуации нужно сразу ставить вопрос ребром. Даже до того, как эти тысячи строк там появятся. Если проект организован таким образом, что их появление там, это вопрос времени. Потому что архитектор решил там писать бизнес-логику.
В этой ситуации сразу можно предложить писать бизнес логику в другом месте. Можно даже отрефакторить один скрин и показать PR, как ты это видишь. Если и после этого архитектор будет защищать свой «артефакт», то нужно делать компании ручкой, не дожидаясь, когда там через полгода-год насрут полную вьюху бизнес-логики и при планнинге придётся жевать сопли, объясняя, что мы элементарную задачу попытаемся за один спринт решить, но ничего не обещаем.

Клиент при планировании спринта явно ожидает услышать что-то лучше, чем «ну мы попробуем успеть поменять местами эти 2 скрина в навигации до конца спринта, но не гарантируем, что к демо оно будет работать, говнокод, понимаете ли у нас тут».

Я правильно понял, что говнокод в данном случае был не осознанным решением клиента (или, по крайней мере, согласованным с ним решением с полным пониманием рисков), а исключительно «плодом творчества» архитектора той команды, в которую ты пришёл работать?

В этой ситуации сразу можно предложить писать бизнес логику в другом месте. Можно даже отрефакторить один скрин и показать PR, как ты это видишь. Если и после этого архитектор будет защищать свой «артефакт», то нужно делать компании ручкой

Если так, то да — в такой команде человеку с наличием профессиональной гордости делать нечего.

Но, опять же... а менеджер, что — не знал о такой позиции архитектора? И нанимал в команду не «гребцов», готовых месить любой говнокод, абы хорошо платили, а специалистов, чей профессиональный подход к работе явно несовместим с тем, как эту работу видит архитектор?..

исключительно «плодом творчества» архитектора той команды, в которую ты пришёл работать?

Именно. Американец, химик по профессии прыгнул в айти. И с 4 годами опыта был на позиции архитекта.

И нанимал в команду не «гребцов», готовых месить любой говнокод, абы хорошо платили, а специалистов, чей профессиональный подход к работе явно несовместим с тем, как эту работу видит архитектор?..

Слово «оффер» было произнесено менеджером на третьей минуте самого первого созвона. Сложилось впечатление, что ему нужно как можно быстрее закрыть дыры в команде теми, у кого достаточно для этого опыта.

1500 строк бизнес кода во вьюхе — это приговор всему проекту.

Далеко не всегда. Заявляю и как человек, видевший проекты с откровенным говнокодом, которые успешно жили и развивались годами, и как человек, один из рабочих интересов которого — это экономически целесообразные методы борьбы с тех. долгом.

Архитектор посмотрит на всё это и скажет, что единственным решением накопившихся проблем будет... Та-дамм, переписать всё с нуля.

Заметь, я нигде не говорил, что переписывание с нуля не случается вообще никогда и ни при каких обстоятельствах.

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

И тут уже задача бизнеса — вывести проект на достаточный уровень прибыльности, пока накопившиеся проблемы не похоронили его изнутри. И это вполне себе рабочая бизнес-модель.

Другой вариант — это «точечное» переписывание, когда с хирургической аккуратностью из говнокода вырезаются небольшие куски, затронутые исправлением бага или добавлением новой фичи, и переписываются более-менее по нормальному.

Но — в это нужно уметь; и люди, умеющие и желающие на таком уровне работать с говно-легаси — редкие и дорогие. С точки зрения бизнеса больше смысла может иметь выжимка максимума прибыли из первой версии с сознательным доведением оной «до ручки», и разработка второй версии с нуля на заработанные от первой версии деньги.

А, значит, приносимая проектом прибыль должна быть достаточной, чтобы оправдать инвестиции в переписывание.

Тут речь не о прибыли, а об отсутствии убытков.

Так и есть =) соискатели сразу бегут смотреть тебя на ДОУ и затем рассказывают что о тебе думают. 😬

Ну це погляд менеджерів, а не власників галєр, як це прийнято виражатися))
Та й сама стаття не цинічна, а просто якась байка про те, як тіпок ділить людей на якісь непонятні категорії :)

зайдите на курсы ейчаров — там такого полно, иногда даже полезно почитать.

Дякую кеп :)
Але

ейчари

!=

власник галєри
Маленькая аутсорсинговая компания. Невыплата или задержка зарплаты, невыполнение обещаний. Ну не понимают люди, что репутация — самое важное в бизнесе.

Ну это взгляд со стороны работника. А если попытаться влезть в шкуру владельца этой маленькай аутсорсинговой компании — ну нет у него финансовой подушки, а заказчик задерживает оплату. Так что репутация может быть не при чём.

нет у него финансовой подушки, а заказчик задерживает оплату.

Чьи проблемы?

А если попытаться влезть в шкуру владельца этой маленькай аутсорсинговой компании — ну нет у него финансовой подушки, а заказчик задерживает оплату.

Вот тут кроется важная проблема:
В чем вэлуе которое добавляет владелец? Зачем он нужен?
Вэлуе от владельца — это обеспечить финансовую подушку.

От вот этого непонимания у всяких вованов и складываются стереотипы о «маленьких аутсорсинговых конторах». При этом такие же ошибки допускают и аутсорсы побольше и они тоже могут задержать ЗП, потому что «заказчик не заплатил».

В маленьких компаниях зачастую владелец — точно такой же разработчик, как и наёмный работник. Работал в такой компании и поэтому понимаю проблемы владельца.

В маленьких компаниях зачастую владелец — точно такой же разработчик, как и наёмный работник.

Ніт

В чем вэлуе которое добавляет владелец?

- зачастую в том, что заказчик хочет работать с одним (юридическим) лицом, а не с толпой наёмных работников.Тем более если работа разовая и\или непрофильная

— зачастую в том, что заказчик хочет работать с одним (юридическим) лицом, а не с толпой наёмных работников

Прекрасно, то есть работники работают с юрлицом «владелец маленькой аутсорс конторы». Почему их должно волновать что это юрлицо не способно собрать бабло со своих заказчиков?

Еще раз:
проблема в том что «владелец» не умеет делать/строить бизнес. Подобные проблемы есть и в средних конторах (до 200 человеку) и в побольше (до 800), но уже реже. В больших это присутствует крайне редко в основном, потому что они уже на стадии когда __научились__ решать проблемы со сбором бабла по контрактах.
А есть и маленькие конторы, где умеют решать такие проблемы (это уже вопрос к детской классификации Вована)

в основном, потому что они уже на стадии когда __научились__ решать проблемы со сбором бабла

. По-моему причина другая: у большой компании заказчиков больше — от кого нибудь оплата да прилетит

По-моему причина другая: у большой компании заказчиков больше — от кого нибудь оплата да прилетит

Ніт.
Многие из наших ЛР плотно зависели от 1-2 заказчика и когда появлялись проблемы с платежами, то некоторые держали 1-3 месяца нормально, а некоторые срезали людей десятками, а то и сотнями.

В чем вэлуе которое добавляет владелец?

Будь-яка контора це, перш за все, сейлз який переконав замовника придбати саме їх послуги.
Більшість розробників не вміють або не хочуть шукати проекти самостійно і тому йдуть в контори, де ці проекти вже є.

Вэлуе от владельца — это обеспечить финансовую подушку.

Так, це аргумент № 2 чому йдуть в контори.

Будь-яка контора це, перш за все, сейлз який

Это вы описали ценность сейлза. Вопрос про ценность «владельца/директора».
Очень мало контор работают как партнерская связка «сейлз+разработчики» (тому миллион и одна причина). В такой связке претензий к «владельцу» нет, потому что разработчик получает не ЗП, а часть от дохода и часть рисков.

Так власник це такий-собі контролер, що виступає керуючим блоком між різними компонентами, розробники і сейлзи лише частина цих компонент.

Так власник це такий-собі контролер

Ніт. Це роль ПМа. За що власник отримує гроші?

ПМ керує безпосередньо проектом. Розробниками, куа, девопси, БА і т.д.
Власник керує сейлзами, ПМами, рекрутинговим відділом і будує бізнес-процеси. Якщо контора велика, то над кожним департаментом(делівері, ейчар, сейлз) свої керівники якими керує СЕО, він же, як правило, власник.
Якщо контора тільки стартувала і там всього 1-2 проекти, то власник може бути в якості ПМа або навіть виконувати якусь технічну роль.

Випадок коли власник тільки стриже маржу я можу уявити один: Власник найняв СЕО, СТО, решту топ менеджерів, які в свою чергу найняли всіх в ланцюжку нижче. В такому випадку власник всім платить зарплату, а собі все що лишилося, але в нашому ІТ я таке не зустрічав.

Тепер власне відповідь: Власник отримує гроші за підтримання життєдіяльності фірми. Яким чином це досягається, це вже його головний біль, його задача і його хліб це організувати роботу всього вищеописаного корпоративного механізму. Архітектор-Девопс-менеджерів, якщо хочете.

Репутация все равно должна быть. Мир ведь маленький. Я попадал в такую ситуацию (и не раз), но понимал что даже в случае развала всего буду обязан закрыть все фин вопросы перед командой и любыми вендорами.

Наконец-то кто-то честно об этом сказал. Кто-то, кого нельзя обвинить ни в свичерстве, ни в джуниорстве. И все эти овертаймы с горящими глазами из любви к технологиям ему нафиг не надо. Потому что «сливки» в любом случае будут снимать СЕО или акционеры

ну запили свою статью про другие критерии. После около 10ка компаний, пары знакомых СЕО разного пошиба, нескольких знакомых бизнесменов, я все равно бы с радостью ознакомился с альтернативной точкой зрения.

Наконец-то кто-то честно об этом сказал.

Что значит «наконец-то»?
Вован про это ноет с момента прихода но доу:
— хочу просто денег, и вписаться в общагу в Киеве
— хочу просто денег, и свалить за бугор
— хочу просто денег, и тратить время на драчки
— хочу просто денег, и русский мир (но так чтобы русские не ипали)
— хочу просто денег, и чтобы не ипали
— хочу просто денег, а если будут ипать сильнее чем раньше, то тогда уж точно уеду в Грузию

Хочу просто денег

Это не правда, потому что с большой вероятностью (судя по некоторым его фразам, то и норм синьорской-лидской ЗП у него нет) «без выпендрежа» вован бы получал больше будучи ПМ на ЗП в ЛР, но ему еще важно иметь определенную свободу.

Правда в том что деньги — это всего лишь способ получить то чего человек хочет, но школота (даже если по паспорту ему под сорокет) этого не понимает.

Правда в том что деньги — это всего лишь способ получить то чего человек хочет

Только с каких хренов ты взял, что я хочу делать кого то богатым?

Только с каких хренов ты взял, что я хочу делать кого то богатым?

Только с каких хренов ты взял, что я считаю, что ты хочешь делать кого то богатым?

Ну так не понятно чего ты хочешь услышать? Да, я сознательно зарабатываю немного меньше чем мог на галере, надрывая все жилы. Зато занимаюсь спортом и делаю что хочу

Правда в том что деньги — это всего лишь способ получить то чего человек хочет

Правда ещё и в том, что во многих случаях деньги ещё и единственный (из законных, как минимум) способ получить то чего человек хочет. Поэтому деньги — самое важное что есть в любой вакансии. И уже после идут интересность проекта/сферы, технологии и т.д.

Правда ещё и в том, что во многих случаях деньги ещё и единственный (из законных, как минимум) способ получить то чего человек хочет.

Вы выделили не то слово: нужно было «многих», а не «единственный». См пример про вовку-фрилансера.

А надо хотеть быть независимым от денег и не рассуждать «могу ли я себе это позволить»

Чтоб быть нзависимым от денег, надо быть независимым от социальной иерархии, в которой наверху олигархи, а внизу низкоквалифицированные рабочие.
Такое удается не только лишь всем

Настоящую независимость дают только очень большие деньги. И именно деньги, не бизнес. Бизнес — это наоборот — несвобода

Хочу просто денег

 — вполне достойная мотивация наёмного работника. И это совсем не значит, что он плохой работник.

Ты что? Сейчас тебе скажут, что нужно работать за идею. Правда в чем состоит идея не скажут

Ну какбы да:

Хочу просто денег и не слишком упахиваться в процессе их заработка.

А мы тут что, лекарство от рака ищем или другие глобальные проблемы человечества решаем? Думаю любой «серьезный чел» с 8 — 10 годами уже знает где можно срубить бабла, если сильно упахаться.
Проблема что у «серьезного чела» уже были визиты к кардиологу, куча проблем со здоровьем от жостких овертаймов и вообще на х** он крутил ваши копроративные ценности.

Якщо відкинути рожеві соплі, то виявиться, що кожен другий, якщо не 90% має таку мотивацію.
І це абсолютно нормально. Нормально робити роботу, створювати статапи, робити інвестиції і все це заради грошей.

Бо, внєзапна, гроші це свобода і можливості.

Я частково не погоджуся.
Само собою, що якась, хоча б мінімальна, зацікавленість і (далі слово російською, не можу придумати адекватне милозвучне слово українською) «Вовлеченность» повинна бути, без цього дуже швидко вигориш. Все ж таки, якщо працюєш над розробкою проекту, то це і твоє дітище також, як-неяк переживаєш.

Але у мене аргумент дуже простий: Якби зараз по якійсь фантастичній причині в ІТ платили в 3-4 рази нижче, то людей би тут працювало набагааааато менше.

Якщо гроші — це головна мотивація, то в голові завжди йде діалог. Може тут зарефакторити? Та ну нахєр, нам за це не платять. В результаті мотивація — 0, ownership — 0, еволюція проекта — 0.

А платить за рефакторинг не думали?

Такий співробітник нелояльний — втече відразу, як десь там замаячить зп на 100 євро більше.

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

Перефразируя работающий за деньги плох потому, что не делает часть работы бесплатно

Мне интересно сделать работу, чтобы меня пригласили ещё раз

Почему ты считаешь что «я работаю за деньги и ничего не делаю бесплатно» = «я всё делаю как-нибудь и ничего не хочу улучшать»?

В нормальних проектах платять за таски з tech debt. Саме тому, що є бажання зробити той проект кращим.
Питання в ініціативі.

Человек, который ценит своё время и для которого деньги первичны, в первую очередь заинтересован в написании чистого кода без технического долга. Потому что технический долг снижает скорость разработки и увеличивает затраты на поддержку. А поскольку в современном аутсорсе никто не смотрит, сколько ты отработал часов, но всех интересует, сколько ты заделиверил тасок, как основа для KPI, то получается, что чистота и простота кода, максимальное соблюдение всех принципов структурированного программирования — это наивысший приоритет для разработчика, потому что он коренным образом влияет на затраты его усилий по поддержанию приемлемого уровня перфоманса.

Та ну нахєр, нам за це не платять.

Це чудовий аргумент, якщо тебе хочуть прогнути на неоплачуваний овертайм або навісити додаткових обов’язків.

В результаті мотивація — 0, ownership — 0, еволюція проекта — 0.

Якщо кожен девелопер буде розвивати загальний прокт в тому напрямку, в якому йому ХОЧЕТЬСЯ, то буде дуже партизанщина, хаос і біда.
Всі хоча б мінімально важливі зміни повинні бути узгоджені та апрувнуті, інакше ви не побудуєте хорошого робочого продукту.

«Зарефакторити»...

...А от тут якийсь карявій індуський гамнокод, я його зараз ййак зарефакторю !
Зарефакторил — скомпілив, тести прогнав, спробував — все працюе ! Нешняк ! Я крутий чувак !!!

// Через тиждень.

На якомусь делекому мудрабайськму серваку почали фєйлитись пре-сабмішен тести, то му що воні були заточені під індуський гамнокод.

От і питання, нафіга на аутсорсі такий крутий рефакторщик ?
На думку багатьох це поганий працівник.

Дякую, Ваше суб’єктивне бачення кожного типу компаній в тому чи іншому світлі надихає на кристалізацію і своїх думок вигляді опусу, тому накину і з свого боку, в зворотному порядку.

Фріланс і віддалена робота

Маю абсолютно протилежний досвід. Починав з цього свою кар’єру, після того, як зрозумів що ходити в офіс і старатись переконати всіх не писати більше на третьому PHP пуста трата часу. Рекомендував би молодим спеціалістам спробувати хоча б два-три проекта зробити на фрілансі розуміння:

  • Для чого взагалі будь-що з програмами робиться. Працювати на фрілансі дає можливість поспілкуватись безпосередньо з людьми, які прийшли до певного бізнес-рішення самі і мають уяву як його реалізувати. В подальшому буде дуже підходяще зрозуміти, що ж саме ви програмуєте і що важливо, а що ні
  • Можливість познайомитись з різними технологіями, сформувати власне ставлення до випробуваних технологій, зрозуміти що подобається робити, а що ні. В майбутньому дає можливість вибрати правильний вектор технічного розвитку.
  • Можливість попрацювати самому і зрозуміти власні сильні і слабкі сторони, як то самоорганізація, вміння вчитись і розуміти ширину проблем.

Продуктова і вузькоспеціалізована компанія

Сюди варто подаватись після фрілансу і галери, коли маєш достатньо досвіду і розуміння. На цьому рівні треба розуміти мета-цінності компанії: чи компанія будує так, щоб всі розуміли, чи кожен працює в своєму сіло і обміну знаннями немає, яку проблему і як компанія вирішує для суспільства загалом. Моя порада не йти в продуктові компанії, які роблять абсолютно не цікавий для вас продукт.

Галєра

Сюди варто йти відточувати майстерність ритмічно, врівноважено і в такт з іншими махати веслом, читати кімнату в зум мітінгу і розуміти виробничі процеси, щоб потім будувати чи запроваджувати свої де інде.

Шхуна (або недогалєра)

Якщо є можливість не йти, то краще не йти. Такі компанії мають хоч якусь цінність тільки на самому старті кар’єри, де ви навчитесь запускати редактор і тайпати по клавіатурі. Теплі лампові і безтолкові.

В кінці цієї подорожі, якщо махати веслом по публічних і приватних хмарах, нормалізуючи і денормалізуючи бази даних вже надоїло, то треба або в менеджери, або в архітектори, або власну справу. Якщо вибрали останнє, то дивіться переконайтесь, що в шхуні не диряве вітрило.

Рекомендував би молодим спеціалістам спробувати хоча б два-три проекта зробити на фрілансі

Оно конечно понятно что нам всем на бизнес заказчика насрать, но не настолько же! Молодому специалисту нужно учиться у старых специалистов в команде, чтобы не научиться неправильным подходам. Это может быть и ремоут, но не классический фриланс когда сам пилишь весь продукт.

Молодому специалисту нужно учиться у старых специалистов в команде, чтобы не научиться неправильным подходам. Это может быть и ремоут, но не классический фриланс когда сам пилишь весь продукт.

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

Молодому спеціалісту, що тільки сунувся на ринок, нічого суперскладного не дадуть. Факапи, якщо будуть, то не від незнання підходів чи технік, а від відсутності почуття відповідальності і самоорганізації.
Не варто переоцінювати проекти на фрілансі. Це зазвичай, якщо наприклад веб, на вордпресі чи мадженті, на джанго чи на рельсах написати щось просте (а скоріше внести модифікацію в існуючий продукт). І тут, щоб знаменито запороти продукт, потрібно тисячі людиногодин.
Сильно має непощастити початківцю, щоб його нагородили проектом, де, не дай бог, треба проектувати сховище даних.

Люблю я статьи от Кожаева. Хотя бы потому, что хоть они и субьективные, но в них нет всего того булщита, который любят щедро наливать разные эйчары, менеджеры и всякие любители гештальтов, на этом ресурсе.

TL;DR
При удачном стечении обстоятельств, продуктовая фирма из экспериментального завода выростает в многонациональный концерн, и это уже совсем другая история.

Продуктовые и узкоспециализированные компании

Многие продуктовые компании, которые давно на рынке, не узкоспециализированные. Со временем они поглащают другие продукты, стремятся их интегрировать друг с другом и продать в связке.

Поэтому по оплате они не ограничены внешним рейтом

Работал в продуктовом стартапе. Его поглотил Оракл и начал сокращать расходы.

ради хорошего человека могут временно и в минус уйти

В минус? Они инвестируют в лояльных на перспективу. Это не минус, а цена которую бизнес готов платить. Вы же не настолько наивны.

заинтересованы в высокой квалификации программистов. Чем выше, тем лучше.

Крупная продуктовая фирма, да и вообще просто крупная фирма, так не работает. В начале пути фирма стремится отхватить кусок рынка пожирнее. Один из способов — высокое качество продукта. Со временем, когда рынок «захвачен», штат сотрудников разросся и уровень бюрократии зашкаливает — фирма стремится сократить расходы. Достаточно топорным способом, так как в каждом конкретном случае разобраться уже практически невозможно. На этом этапе высокая квалификация рядовых сотрудников уже не приоритет.

Ну и еще немного о продукте. Продукт этот как правило иностранный. И к оффшорным сотрудникам отношение не такое же как к своим. Это базовая особенность психики делить людей на своих / чужих. Если у человека другая речь, другой менталитет, другие условия жизни — он не воспринимается как свой. Можно тренировать толерантность, но это именно тренировка. Ларри Эллисон шутит на презентации про украинских хакеров, мотивируя потенциальных клиентов купить супербезопасную Autonomous DB. Сотрудники из Украины, стремящиеся к высоким должностям, усиленно учат язык, переезжают в Штаты и сокращают свои имена чтоб иностранным коллегам было легче их произносить. Если хочешь расти по карьерной лестнице — нужно быть «своим».

При удачном стечении обстоятельств, продуктовая фирма из экспериментального завода выростает в многонациональный концерн,

В 95% случаев этого не произойдёт. В лучшем случае экспериментальное КБ купит концерн «Фольксваген» и включит в свою структуру. Будут делать «обманки» для прохождения дизельными машинами тестов на токсичность выхлопов.

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

И еще такой момент, что если компания и не выростет до корпорации, ее вполне может поглотить другая корпорация. Может моя картина искажена из за того что я такое встречал несколько раз. Но вообще экономика глобализируется и такие тенденции присутствуют.

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

Нераскрытым остался вопрос «когда пора валить в Грузию»?

Это в следующей статье, ждите-ждите

томные девы с чарующим размером груди будут буквально драться, лишь бы оффер принял. Но на сайтах фриланса гордых Full Stack разработчиков из Пакистана, Индии, Вьетнама etc больше, чем в Бразилии обезьян

При всій повазі, Володимире, я думаю, Вам варто все-таки поїхати в ту ж Німеччину. Не за грошима, а для того, щоб навчитися толерантності. А то у вас прямо в двох сусідніх реченнях сексизм стоїть поруч з расизмом. Досить гірко, що у нас, як ви кажете,

на Украине

не всі розуміють такі нюанси. Це не текст із XXI століття.

При всій повазі,

Чомусь коли чую «Вельмишановний», то розумію, що будуть змішувати з лайном :)

Вам варто все-таки поїхати в ту ж Німеччину. Не за грошима, а для того, щоб навчитися толерантності.

Країна проживання нічого не вирішить. Є люди, що емігрують і живуть в «маленькому совку».

для того, щоб навчитися толерантності. А то у вас прямо в двох сусідніх реченнях сексизм стоїть поруч з расизмом.

Простите, а что плохого в том, чтобы называть обезьян обезьянами?
Мы в свободной стране, а не в этих ваших американо-европейских концлагерях и тут работает реальная, а не «политкорректная» свобода слова.

Когда обезьяна называет обезьяну обезьяной — в этом, действительно, ничего плохого нет ;)

Ілі, когда я віжу, молодой, культурний чєловєк бьйот кота, ето ж он сам сєбя обкрадиваєт, ето ж он нє кота бьйот, а сєбя! © Лесь

з чого ви взяли шо всі (чи принаймні значна частина) бразіли макаки? є такі шо українським сінйорам по скілан вставлять і не помітять

є такі шо українським сінйорам по скілан вставлять і не помітять

А кто сказал про «всех»?
Это вы обобщаете, не я.

В Бразилии не только программисты, обезьяны тоже есть

Особенно по скилу «чтение и понимание текста»

Фраза

больше, чем в Бразилии обезьян

подразумевает что в Бразили много обезьян. Но она не подразумевает что в Бразилии только обезьяны или что граждане Бразилии — обезьяны.

Це не текст із XXI століття.

так, текст з XXI століття це
Black Lives Matter
та #RIPJKRowling

Не за грошима, а для того, щоб навчитися толерантності.

Зачем мне, её едят?

Чтоб иметь возможность войти в цивилизованное сообщество.

Для того, чтобы с него могли там драть налоги и страховки?

Для того, чтобы с него могли там драть налоги и страховки?

Для того, чтобы он мог получить услуги за которые он платит налоги и страховку.

Предоставляем услуги. Дорого.

Для того, чтобы он мог получить услуги

А если ему эти услуги не нужны и он не хочет за них платить?

А если ему эти услуги не нужны и он не хочет за них платить?

1) Я уверен что он и многие посетители доу не понимают зачем им нужны услуги государства. Было бы у нас норм образование, то понимали бы.
2) Никто не хочет платить, но он и тут платит, просто не получает их в норм объеме.

Никто не хочет платить, но он и тут платит, просто не получает их в норм объеме.

В Украине самое лучшее соотношение затрат и выхлопа.
За 5% от дохода я имею несколько относительно ровных дорог, по которым могу кататься и достаточный уровень работы полиции, чтобы безопасно передвигаться по улицам. Ничего больше от государства мне не нужно. Ни копейки больше я платить смысла не вижу.

достаточный уровень работы полиции, чтобы безопасно передвигаться по улицам

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

Ничего больше от государства мне не нужно

У вас и вашых близких иммунитет от ковид? Просто в Киеве мест для больных в гос клиниках нет (не было сегодня утром).
А что будете делать, когда рашка прийдет в ваш населенный пункт?
И образование вы конечно же получали за бабло и на цену этого образования никак не влияла та система, которая поддерживается государством.

И еще вован напомнил: Что у вас по состоянию здоровья? Жрать всякий треш, который не приветствуется в норм странах, наверное гарантировано не повлияет на ваше здоровье.

Ни копейки больше я платить смысла не вижу.

Почему именно ни копейки? Будет 6% уйдете в тень и уедете в Грузию, как вован? А почему 5% приемлемо? Может надо 4.5%?

В Броварах бандюки устроили разборки среди белого дня. Кагарлык. Недавно несколько случаев когда бухие мусора совершали ДТП, но уверен что на вас наехать машиной не возможно.

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

У вас и вашых близких иммунитет от ковид? Просто в Киеве мест для больных в гос клиниках нет (не было сегодня утром).

Эта проблема была в США ещё летом. Она по всему миру.

Будет 6% уйдете в тень и уедете в Грузию, как вован? А почему 5% приемлемо? Может надо 4.5%?

Я эти копейки не считаю, для этого есть бухгалтер. Когда повышение станет заметным, тогда и буду думать, что с этим делать.

Только ездили бухими не полиция,

Вот именно, не полиция. Полиция их ловила.

Ну и разборки с огнестрелом устраивали чёрные каждый день и стабильно с трупами.

И происходило это в норм районах, а не где-то в гетто.

Эта проблема была в США ещё летом. Она по всему миру.

Угу, товарищ работает врачом в НЙ, жаловался на саплай все лето:
— запасов кислорода всего на неделю осталось;
— запасов саплая на 2 недели;
— приходится отказываться от палат для семей, туда ставят койки для больных.

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

Так ни копейки больше или станет заметным?
Сейчас небольшая новость про вас:
— до 15% вы будете только жужжать на форуме;
— где-то после 20-25% начнете смотреть на Польшу;
— где-то в 35 лет эмиграция уже будет сложнее и вы продолжите ныть на форуме что «ни копейки больше чем 25% вы платить не будете, и уйдете в тень или уедете в Грузию» (как это ноет вован)

Полиция их ловила

Это их проблемы и их адвокатов.
Факт — ездили регулярно. Одна наркоманка на пикапе на хайвее снесла машину помощницы шерифа, кстати. Помощница шерифа осталась инвалидом.

И происходило это в норм районах, а не где-то в гетто.

Я и в Украине живу в норм районах. И никаких проблем с этим не имею.
Когда я в Харькове жил на Госпроме, меня мало интересовали разборки на ХТЗ. В Одессе, живя в Аркадии мне насрать на охлос, который режет друг друга на Молдаванке и Поскоте.

Угу, товарищ работает врачом в НЙ, жаловался на саплай все лето:

Подруга жены работала медсестрой в приёмном отделении тоже в НЙ. Жаловалась, что поступающих некуда складывать и выходных не дают.

до 15% вы будете только жужжать на форуме

Возможно.

где-то после 20-25% начнете смотреть на Польшу

Каким идиотом надо быть, чтобы переехать в христанутую страну, где за аборты — уголовная ответственность?
Я просто закрою ФОП и буду работать за кэш/пайонир/карточку иностранного банка.

где-то в 35 лет эмиграция уже будет сложнее и вы продолжите ныть на форуме

Мне 34 и я уже пожил в США.
Где-то в 35 лет ты начинаешь понимать, что идеалы юности — полное фуфло и думать нужно только о себе. А в развитых странах — ты раб системы, потому что там сильные государственные институты и гражданское общество. Хорошо жить — лучше в Украине.
Нищенствовать — лучше в развитых странах, не вопрос. Там можно и водителем автобуса хорошо устроиться.

Ну якщо вони в 2014 бавилися в доту, над Донецькою та Луганською областями в них повний туман війни, а про Сирію нічого не знають, то хто ж їм дохтур, що вони досі не доперли, для чого потрібна держава.
Як казав сер Вінстон, програєте і тоді точно дізнаєтесь, за що ми воюємо...

Знаешь что будет, если в Киев придёт война? Я уйду отсюда просто

Знаешь что будет, если в Киев придёт война? Я уйду отсюда просто

Если война прийдет в Киев, то очень быстро прийдет и во Львов.
А в Польше и Грузии 35+ дядька нафик никому не надо.

Открою тебе маленькую тайну: в Киеве дядька +35 тоже никому не надо. Я нужен себе и умею находить работу в интернете, остальное не важно

Кожаєв, то всім, звісно, дуже цікаво, що буде робити така людина без сім’ї і батьківщини, але назвати це role model досить важко при всьому бажанні.
Зійдемося на тому що звичайна людина твого віку має:
— Свою постійну роботу;
— Своє власне житло;
— Дружину зі своєю постійною роботою;
— Дітей (одного чи більше), прив’язаних до школи;
— Батьків, своїх та дружини, не раз хворих чи немолодих, часом ще зі своїми батьками, але практично в 100% випадків проблемними (ми минулого тижня поховали останню нашу бабцю, матір тестя, з нею все було складно).
Тому так, я знаю, що ти летючий миколаєвець, дякую за черговий комент самолюбування, але «нам так не буде» ©

Так стань не нормальным, как я и инджой. Кто мешает? Я не нанимался оплачивать нужды «обычных людей»

И потом, ты надеюсь смотрел на карту и понимаешь, что если РФ пойдёт в наступление по настоящему, без того чтоб делать вид, что это шахтёры воюют надежда остаётся только на НАТО которое вмешается? Увы и ах, одним героизмом войны сейчас не выигрывают, это печальный факт.

Как сделать, чтобы стало по другому? Рецепты, их есть у меня: нужен экономический рост! Чтобы солдаты не бегали от призыва аки сайгаки хорошо — бы этих солдат кормить! Согласен? И тут то порылась собака: все правительства начиная с Януковича душат экономику в пользу социалистических бредней. Вспомни, с чего начался майдан в 2012-м? Правильно ,с наездов на ЧП. Какие инициативы выдвигались каждый год при Порошенко — порезать ЧП. Что сейчас делают зелёные — на ЧП нападают. А зачем, как ты думаешь? Потому, что на задабривание паттерналистски настроенного электората нужно бабло, а у себя его брать очень не хочется. Проблема только в том, что это всё равно что лечить рак постоянно увеличивающейся дозой наркотиков, вместо болезненной но необходимой операции.

И вот ты серьёзно думаешь, что мне нужно такое государство? Представители его озабочены только тем, чтобы уровень жизни плебса падал не слишком сильно и они-же воруют будущее у этих людей

Обичниє люді. Я звідси зникаю.

Колбаску барину принеси, а потом можешь уходить :)

что классику не знаешь? ты же с Вовой Кожаевым общался, нужно принести харчи, если простолюдин

Володю, я не знаю, що тут відповісти. Ми цієї теми торкалися сто разів і я не бачу сенсу знову повертатися до того ж самого, як і ти, власне, зараз не сказав нічого нового. Краще я напишу комент про власне типи контор, там хоч прикольно буде :-)

Нечего мечтать. Ты ж понимаешь: меня поставить под ружье задача не выполнимая

при чем тут ружье? (хотя спрашивать тебя особо никто не будет, а кулаками не отмашешься. и адвокат не поможет)
тебя просто не выпустят. убежать сможешь, наверное, но статус будет «беженец» со всеми вытекающими

хотя спрашивать тебя особо никто не будет, а кулаками не отмашешься

Конечно. Даже во вторую мировую дезертирам было лучше, чем воякам

Даже во вторую мировую дезертирам было лучше, чем воякам

Да ну? На лесоповале в тайге? Или в уютном рву расстрельного полигона?

Для того, чтобы попасть под амнистию 45 года, нужно было еще до нее дожить...

Ну да, на поле боя дожить оно конечно способнее

Воюющая армия, это не только поле боя. А вот какова вероятность у дезертира не попасться органам, не быть в результате расстреляным, или зарезаным уркаганами в лагере/загнуться от туберкулеза/голода/нужное вписать? И таки дожить до амнистии?

Воюющая армия, это не только поле боя.

Думаешь у тебя много шансов попасть на продуктовый склад вместо окопа?

какова вероятность у дезертира не попасться органам, не быть в результате расстреляным, или зарезаным уркаганами в лагере/загнуться от туберкулеза/голода/нужное вписать?

Гораздо выше, чем не стать пушечным мясом. Кроме того, я могу и сам стать уркаганом. Думаешь слабо?

Средняя продолжительность жизни бойцов РККА на передовой в ходе крупных операций (таких как оборона Сталинграда, например) составляла около суток.
И таки лучше быть расстреляным за дезертирство, чем валяться в окопе с простреленными лёгкими, или оторванными конечностями на морозе и истекая кровью ждать смерти.

Т.е. лучше сдохнуть бессмысленно?

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

И таки лучше быть расстреляным за дезертирство, чем валяться в окопе с простреленными лёгкими, или оторванными конечностями на морозе и истекая кровью ждать смерти.
Т.е. лучше сдохнуть бессмысленно?

Это написано про кейс, когда смерти не избежать. А не про то, что ты себе нафантазировал. Еще и комментарий не тебе адресован, а другому социопату))

Лучше сдохнуть быстро.

Не зовсім. Але це знову мій дискурс vs ваш із Кожаєвим.
Якщо вас чесно вбили, ваша сім’я в тилу мала пайок, а якщо ви дезертир — ні.

А если я занимаюсь грабежом складов в тылу и семья моя паёк на болту вертела? Реальные случаи

Можно подумать, что их где-то не дерут

В Украине то, что дерут — мелкие карманные расходы. Я бензина на покатушки на мотоцикле на больше сжигал.

Нет ничего более постоянного, чем временное решение.

Зачем мне это общество, его едят?

Кстати, да. В норм обществе нормальное качество еды.

Так и у меня нормальное.

Правильно говорить: Так и я думаю, что у меня нормальное.

Не хочу общаться со всяким гавном, хочу чтоб оно не липло к обуви.

Толерантність та цивілізація — речі несумісні. Цивілізація починається із норм та законів, обов’язкових для всіх. Коли цивілізацію вражає патоген толерантності — це початок кінця цивілізації.

Спробуйте перенести сучасний толерантний дискурс на програмізьм. Наприклад, що буде з розробником, який в проекті почне вимагати поваги до своїх культурних особливостей — до коду на іншій мові та з іншими АРІ та протоколами.

Её не едят, ею любуются

Цікаво скільки вам потрібно грошей, щоб нарешті вийти на наступний рівень піраміди Маслоу.

Не скажу за Владимира, но я на тех уровнях был. Тлён и эфемерщина, доложу я вам. Всё равно в итоге возвращаешься к главному.

Деньги, предложение не будет грамматически верным, если что-то другое

Або з’їсти або виїб*ти

Бабло.
И возможность его безнаказанно тратить на что хочешь

Не примитивно это как:видеть людей в грязных обезьянах? О толерантности обычно они и вопят, дескать как это вы не хотите дать мне денег за то, что я такой классный?

Вот пусть эти «не обезьяны» решают свои проблемы сами. Это цивилизованно, кто хочет чтобы я за него воевал, работал, думал тот макака грязная

три раза перечитал в поисках расизма, но так его и не обнаружил. сравнивается количество гордых разработчиков с несметным числом обезьян в бразилии. сами гордые разработчики ни с чем обидным не сравниваются.

Зараз модно вскукарекнути про расизм/сексизм, навіть там де його нема і ніби це показує який ти крутий, модний-молодьожний прогресивний.
В реальності всі на такого вкукарека дивляться як на довбойо*ба.

Ладно, я могу с большой натяжкой рассмотреть там сексизм. Расизм-то в чём?

Я: Программирую за деньги. Если мы договоримся, буду выполнять свою часть контракта.

Приходит отказ: «У Владимира отсутствует другая мотивация, кроме финансовой — не подходит».

Колись давно в універі викладач з економіки пояснював нам, молодим, що в статуті комерційної компанії має бути написано, що метою її створення і діяльності є заробляння грошей. Мене це тоді дивувало, я сперечався — а може ми хочемо просто створити крутий продукт і пишатися, або може врятувати багато-багато бобрів. Викладач мені пояснював, що крутий продукт може бути засобом досягнення мети, а порятунок бобрів — наслідком цього досягнення, а от сама мета у бізнеса завжди одна — заробити.

Колись давно в універі викладач з економіки пояснював нам, молодим, що в статуті комерційної компанії має бути написано, що метою її створення і діяльності є заробляння грошей.

Жаль что ему никто не объяснил что информация бывает «полезной» и «бесполезной».
Какую пользу получит из этой информации человек, который будет читать этот документ? Единственная польза от такой записи — это возможность быстро поменять поле деятельности, но это же является доп фактором риска для инвесторов и партнеров.

Если говорить про работников, то:
Профессиональный специалист работает за деньги, это и так понятно. Но если деньги единственная мотивация, то с такой работник пременим только для рутинных задач и ЗП выше средней ему явно платить не стоит.

Когда вы открываете или создаете свой продукт, вы хотите на этом заработать не лайки, и благодарности, а реальные деньги, другое дело если вы фонд по защите бабочек от разьяренных богомолов. Вы стараетесь найти волонтерствующих рабочтх, или работающих волонтеров. И за еду они делают вам все что вам нужно, но вы так и пишите в своей вакансии — работа ненормированная, график тоже, работать надо по выходным под открытым небом. Кто соглашается идти с вами в это поприще идет и не ждет от вас золотых гор, а когда вы техноконтора, со штатом в 200 чел, и у вас горят сроки, то проблемы у вас а не у работника, и он не должен разгребать менеджерское дер*мо за свой счет.

Когда вы открываете или создаете свой ...

Вы вот зачем все это словоблудие написали?

Ну коротко на вопрос почему бесплатная работа не ценится ответить невозможно... А кроме денег человек от бизнеса, тем более чужого получить чегото другого получить не может. А в рутину превращается все, даже самая креативная работа.

Ну коротко на вопрос почему бесплатная работа не ценится ответить невозможно

Так а зачем вы мне это отвечаете? Отвечайте тому кто спрашивал или делал утверждение что «бесплатная работа ценится».

Профессиональный специалист работает за деньги, это и так понятно. Но если деньги единственная мотивация, то с такой работник пременим только для рутинных задач и ЗП выше средней ему явно платить не стоит.

А от скажіть мені, якщо порівняти професіонала, який собаку з’їв в якійсь сфері і може зробити за тиждень, ну, наприклад, 20 якихось умовних середніх задач по проекту зовсім не напружуючись і іншого програміста, який ну дуже захоплений, але вперше бачить дану предметну область і може видати лише 5 умовних середніх задач в тиждень — то кого з них варто найняти ось тут і зараз? Кому варто платити більше грошей? Як визначити чи другий взагалі колись дотягне до рівня першого?

Вы задали 3 не связанных между собой вопроса:

то кого з них варто найняти ось тут і зараз?

Проведя собеседование, четко понимая кто нужен конкретному проекту.

Кому варто платити більше грошей?

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

Як визначити чи другий взагалі колись дотягне до рівня першого?

Тут снова же умение оценивать перспективность людей. И не понятно как вы оценили что первый «може зробити за тиждень, ну, наприклад, 20 якихось умовних середніх задач по проекту зовсім не напружуючись».
---

В общем проблема в том что вы придумали как вводную «крутого специалиста, которому пофик на свою работу и он мотивирован только деньгами» и пытаетесь на основании вашего допущения что он существует доказать что он сущетсвует.
На практике, классные спецы мотивированы, как правило, потребностью в самореализации, хотя и могут говорить «я работаю за деньги и это главное» (как правило это связано с тем что некоторые люди пытались эксплуатировать их интерес в той или иной области).

классные спецы мотивированы, как правило, потребностью в самореализации

С чего ты взял, что эта самореализация состоит в написании говнокода?

С чего ты взял, что эта самореализация состоит в написании говнокода?

Мы это обсуждали уже много раз:
зарабатывайте на том в чем ваша самореализация.
Другой вопрос что вы не способны, а в ИТ даже полные уо могут чего-то получать.

Нет, сэр. Дело в том, что не твоё дело как мне жить и чем заниматься. Для тебя главное «самореализация»? Ну реализуйся, кто мешает? А для меня важно хорошо жить: зарабатывать не особо упахиваясь, если уж не работать пока не выходит и делать что нравится.
Сейчас нравятся единоборства и наука. Но ни за первое ни за второе не платят. Никому не платят, з.п. в сборной Украины по самбо аж минимальная и ту задерживают. При этом Украина уже который год занимает первое общекомандное место и в Европе и в Мире. В науке тоже денег не дают, это я тебе как закончивший аспирантуру ИнКиб-а говорю. Меня даже не распределили после выпуска, хотя были должны. И вот жить впроголодь зато занимаясь «любимым делом» я считаю уделом лошар и неудачников

Дело в том, что не твоё дело как мне жить и чем заниматься.

Дело в том, что я не указываю тебе где твое дело и чем тебе заниматься.

Сейчас нравятся единоборства и наука. Но ни за первое ни за второе не платят.

Вот МакГрегор (и куча ребят по проще) как-то зарабатывает, а Вовка почему-то нет.
На науке в Украине можно офигенно зарабатывать (знаю людей из того же Кибцентра, которые очень хорошо получают финансирование, хоть и не от государтсва), но снова же тут надо не штаны просиживать и дисер 10 лет писать. Вы, кстати, уже защитились?

з.п. в сборной Украины по самбо

Так у программиста на каком-то заводе в Южном Забухрынске тоже ЗП не очень.

Вот МакГрегор (и куча ребят по проще) как-то зарабатывает, а Вовка почему-то нет.

Потому, что Мак-Грегор в другой стране живёт. Ваш К.О. А ещё потому, что когда я начинал выбор был у меня такой: учиться, или в бандиты. Опции «стать спортсменом и с этого жить» — не было. А сейчас дяде 40-к лет.

На науке в Украине можно офигенно зарабатывать

Офигенно это сколько?

Вы, кстати, уже защитились?

Увы нет. Научрук умер. Новый сменил тему.

у программиста на каком-то заводе в Южном Забухрынске тоже ЗП не очень.

А у чемпиона мира? Вот как ты думаешь: чемпион мира это хорошо, или как-то не очень?

А ещё потому, что когда я начинал выбор был у меня такой: учиться, или в бандиты. Опции «стать спортсменом и с этого жить» — не было.

Ты про свои драчки рассказываешь уже 10+ лет и результату 0. Но да во всем виноваты «привеледжет вайт», а ты простой парень из гетто.

На науке в Украине можно офигенно зарабатывать
Офигенно это сколько?

По разному:
у одного с патентов выходит синьорская ЗП.
у одного последние пару лет синьорская, но он гранты выбивает. А еще земельки себе под Киевом вымутил.

И это случаи 30-40 лет. Дедов мы пропускаем.

чемпион мира это хорошо, или как-то не очень?

Чемпион — это титул, его еще надо обналичить. И у чувака который хорош в своем деле проблем с этим нет. Например, тяжелоатлет (не самый модный вид спорта) как-то свои или 3,5, или 4,5 зарабатывал в Киеве, и это не чемпион.
Другое дело что у нас спорт кружки приучают учеников к тому что им государство должно все давать за то что они «представляют страну». Но я как-то не думал что у капиталиста Вована будут те же проблемы с пониманием мира.

А от скажіть мені, якщо порівняти професіонала, який собаку з’їв в якійсь сфері і може зробити за тиждень, ну, наприклад, 20 якихось умовних середніх задач по проекту зовсім не напружуючись і іншого програміста, який ну дуже захоплений, але вперше бачить дану предметну область і може видати лише 5 умовних середніх задач в тиждень — то кого з них варто найняти ось тут і зараз?

Это работает немного не так. Я в своей узкой области скорее найду как этих двадцать задач не делать достигнув при этом результата.

И даже если оттуда уволили за плохую работу, никаких последствий для карьеры не будет. Ну ушёл ты из фирмы «Рога и копыта», никого не убил, ничего не украл и ладно — других дел по горло, чтобы ещё джуниора какого-то пристально проверять.

А кого вот прям пристально проверяют ? Я про такое слышал, но чтоб вот массово кого-то проверяли. Может раньше таким фирмы занимались, но это наверное до поры взрывного роста вакансий в ИТ.

Смотря что от тебя зависит. Если ты замдиректора со стороны будут конечно проверять

Ну, не знаю, где как, а вот, например, в Samsung запрос на подтверждение моего диплома в университет отправляли, своими глазами видел.

дочитал, ушел чинить замки

чинить замки, прочищать унитазы или делать оптику разного рода. Второе, конечно, поинтереснее

Я, почему-то, проставлял индексы так:
1 — чинить замки
2 — прочищать унитазы
3 — делать оптику

И при таком счете фраза «Второе, конечно, поинтереснее» выглядит, ммм, интересной))

Две проблемы в программировании: выбор имен, сброс кеша, и переполнение

Есть варианты:

1 — чинить замки и прочищать унитазы; 2 — делать оптику

0 — чинить замки; 1 — прочищать унитазы; 2 — делать оптику

Интересно, как в голове автора уживаются эти два утверждения ))):
1:

Ну не понимают люди, что репутация — самое важное в бизнесе. Но ничего, жизнь быстро научит.

2:

поэтому врать в резюме можно не особо стесняясь: проработали год — пишем два, дописываем в резюме технологии, с которыми может и не работали, но читали книжки.

Соискатель — не бизнесмен. И при малом опыте работы репутация не играет, а при большом — репутация разная для разных целевых групп (например: ХР, со-девелоперы, владельцы галер и потенциальные заказчики).

И как работодатель проверит работал ты с докером за деньги, или только прочёл книжку и сделал тестовый проект?

Это выплывет при первой же задаче связанной с докером, которая сложнее тестового проекта. Вернее всплывет или в реализации или в эстимейтах.

Другое дело, что работодатели зачастую пишут такие техноологии, которые на проекте юзают к примеру только на продакшне, но с соискателя спрашивают так как " ну мы же это юзаем, он должен быть в курсе" или «а вдруг надо будет...» — но это такое себе, поэтому и соискатели пишут в резюме весь стек технологий что юзали за все время, пускай этот докер юзался фиг знает когда и то я только смотрел как девопс настраивал )))

Кажется в том разделе статьи идет речь про новичков. Которым подходят домашние шлюпки за неимением опыта...
А для новичков такой уровень уже лучше чем ничего

Это выплывет при первой же задаче связанной с докером, которая сложнее тестового проекта

Джуниору не дают таких задач, ему нормально ошибаться

Очень просто — Fake it until you make it.
Как минимум для того чтобы попасть на тех собес, как минимум для того чтобы прокачать навык прохождения собесов.

Чтобы пройти собеседование нужно на него попасть. Теперь представим барьер в виде хрю, которая не знает чем Java отличается от JavaScript и у неё задача — отсекать по формальным признакам. Дальше?

Что «дальше?». Я писал к тому что не раскрывать все карты в резюме норм...

Мммм, заводские аналогии ) Только вот «Специалисты даже собственное тавро имеют, мол, шлифовал такой-то» — это терминология именно судостроительных заводов? У нас такое называли «личное клеймо».

Хоть под. Я не страдаю патриотизьмом головного мозга

«хоть под» — це все пояснює.

Какаяразница головного мозга

Такое впечатление, что если у тебя патриотизм головного мозга у других должно быть то же самое.

Таке враження, що якщо у тебе комплекс неповноцінності, то у інших повинно бути те ж саме.

у Вовы свой вариант. Это все равно не победить

уехать за границу

Это не профессия

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

Думаю, открою свою оутсорсиноговую контору

В принципе, сейчас можно было бы открыть «канал» — контору, которая за 10% выступает фасадом между фрилансерами и заказчиками.

Заказчик перечисляет деньги на контору, а не на 100500 непонятных субконтракторов. Проще с бухгалтерией и с имиджем.

Программисты за минимальную сумму могут (дополнительной услугой) получить офисное место, бухгалтера и кофеварку.

Вообще, если надо экспертизу по эмбедед/телеком/С++ архитектуре, говори — у меня скоро проект заканчивается.

В принципе, сейчас можно было бы открыть «канал» — контору, которая за 10% выступает фасадом между фрилансерами и заказчиками.

Их уже много. Самый популярный Upwork

Не все хотят с ним связываться. С обоих сторон.

Аутсорсинговых контор тоже много — еще одна обычная контора может не взлететь.

А вот гибрид одного и другого — это почти как говорящая жабка в кармане.

наконец то нормальное чтиво на доу

Ага, в котором ни разу слово «софт-скилы» не упомянуто.

Спасибо.
Респект!

Спасибо за статью. В общем и целом согласен. Есть пару ремарок.

Лично я считаю, что не стоит до конца дней расти в гребле. После определенного уровня (10-15 лет) однозначно нужно уходить в архитектуру и экспертизу. Архитектура и экспертиза — это самые проблемные места в любой конторе, без исключений. Все хайповые ЯП и фреймворки — это пыль на ветру («Dust in the wind») и только построение сложных архитектур и экспертиза от очень опытного специалиста становятся все ценнее и дороже с годами, как выдержанный коньяк ))

При поиске новой работы не стоит себя позиционировать, как опытного гребца. Это и так понятно. Нужно себя «продавать», как опытного инженера и человека, который не код пилит от «забора до обеда», а еще и как специалиста, который решает проблемы бизнеса. Вовлекаясь в сам процесс.

Лично я бы не хотел за большие деньги разгребать какой-то древний легаси. От этого быстро выгорают. Поэтому лично для меня сам проект имеет большое значение не менее денежного вознаграждения.

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

При найме нужно сразу понимать, что из себя представляет заказчик и его бизнес. Это стартап или перевод офлайн бизнеса в онлайн. Если первое, то высока вероятность, что после MVP всех отправят по домам. Второй вариант — это самый идеальный. Реальная разработка продукта под готовую бизнес модель. С развитием и поддержкой. Если заказчик не особо адекватный человек и это сразу видно по первому разговору, то нормальной работы не будет. Нужно не соглашаться на офер и искать дальше.

Фриланс — это не свобода! Это очень длинная цепь на ноге. Вечный поиск, разные люди, разношерстый зоопарк технологий и т.д. — это явно не то, что нужно опытному специалисту.

Если при поиске работы встречаются одни неадекваты на конторах, то из этого автоматически не следует, что так везде и всюду. Нужно не отчаиваться и явно что-то менять в подходах поиска хорошего места.

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

Спустя многое годы нет никакого смысла распыляться и хвататься за разные технологии и разношерстные задачи. Как я говорил выше, нужно усиливать свою экспертизу. И усиливать в наиболее стратегических видах бизнеса (онлайн продажи товаров и услуг в любых их ипостасях). То есть взять средне узкую нишу и стать в ней сильным экспертом.

Итого, нет смысла конкурировать в гребле с молодыми — это путь в никуда. Но есть смысл уходить в архитектуру и экспертизу, так как каждый выполненный проект — это левел ап к скилам и экспириенсу независимо от технологий.

Желаю удачи и всех благ. Не выгорайте и получайте удовольствие от работы!

Касательно овертаймов. К сожалению, наша профессия их предполагает. Это неизбежно.

Пятый год работаю, овертаймил один раз, когда попросили с регрессией в субботу помочь. Лениво поклацал кнопочки, посоздавал баги, 10 оплачиваемых овертаймов из 10, would do again

Пару раз были сапорты и багфикс в 3 ночи. Оплатили нормально но, I never asked for this. Да и знаю людей с командировками в другое полушарие на завтра.

Да понятно, что такое бывает. «Это неизбежно» — вот спорная часть. У меня вот за 5 лет работы разработчиком в трех компаниях разной направленности (очень мелкий продукт, среднего размера аутсорс, среднего размера продукт) принудительных овертаймов не было никогда. Сам по своей инициативе мог иногда зависнуть, но очень редко и только потому, что самому хотелось вот прямо сейчас что-то допилить.

Дай плиз определение, чем гребля отличается, или в какой момент, она становится архитектурой и экспертизой?

IMO когда начинаешь отвечать за проект или подпроект.

гребля это когда ты кодиш. експертиза это когды ты говориш другим как надо кодить

Тоесть 8 часов в день, ты говоришь что делать, но:
По клавишам не стучишь и в монитор не смотришь?
Или ты только читаешь c монитора и ничего не вписываешь своего?
Или ты вписываешь, но только когда тебе захотелось?
Или ты пишешь только сниппеты кода?

Зависит от размера проекта. Мелкий/простой может эффективно задизайнить много кто (там и дизайнить особо нечего, и цена ошибки минимальная), а средние и, тем более, крупные — уже нет. Например, чтобы разбить систему на сервисы (если нужно), подобрать технологии в тему и смоделировать данные эффективно (а не как любят «примерно»), нужно сначала хорошо понять бизнес-логику... да и сам скилл задизайнить базу не всем дан изначально (здесь речь не столько о технических знаниях по базам, сколько об абстрактном мышлении). Про то, какой ужас у нас часто называют «микросервисами», вообще молчу. Потом идут нюансы со стороны инфраструктуры (после десятков собеседований я увидел, что мало кто понимает даже элементарные вещи, что в облаке происходит — какая там может быть архитектура...). CQRS путают с CQS; ES понимают единицы, а умеют готовить ещё меньше (к сожалению или к счастью, я пока не в их числе). Конечно, это всё справедливо, если архитектор сопровождает свою работу, а не теоретик-космонавт, который думает не о проекте и команде, а о своём резюме и амбициях. Мы вот запедалили ERP с нуля без девопсов, и удивительно, но с инфраструктурой дела сильно лучше, чем раньше были с девопсами, и архитектура сильно лучше, чем была практически на всех проектах в нашей карьере (у всей команды) — здесь уже могу и себя похвалить. Так вот, пока я выполнял эту роль, то первые месяцы кодил только инфраструктуру (наравне со всеми) и дизайнил систему практически (большую часть времени). Чаще кодить стал месяц на четвёртый, когда всё устаканилось относительно, но всё равно раза в два-три меньше остальных, т.к. уходит время на ревью, планирование, улучшения разные и т.д. С 90 процентной вероятностью, взяв средних сеньоров (хотя по тайтлам всё было бы идентично), результат был бы очень заметно хуже, поэтому разница на самом деле очень большая, и да, это уже совсем не кодинг.

Ерунда. В нашей профессии ты или «играющий тренер», или человек, на которого пишущие код коллеги смотрят как на говно.

вот к примеру, какой-нибудь эксперт по архитектуре — начинает утверждать, что он понял в чем корень зла и засыпает почту ссылками из Интернета по изменению параметров NFS, от таких же экспертов
а ты знаешь, что NFS-протокол на проекте — не используется, но это не имеет никакого значения, потому что ты — гребец

О, да. Не люблю такого, когда кто-то из вышестоящих нахватает случайных ссылок в гугле, скинет и такой типа он помог и всё уже просто сделать (а ссылки-то вообще не в тему проблемы)

Лично я бы не хотел за большие деньги разгребать какой-то древний легаси.

Это индивидуально.
Для меня работа по разгребанию спагеттин в приложении — полностью самодостаточная задача. Когда класс на 1500 строчек, в котором переплелись юай, стили, presentation logic, навигация, запросы в сеть и доменная логика, написанный на джаве 6 превращается в 4-5 коротеньких и аккуратненьких файлов на Котлин, каждый из которых делает только свою работу и ничего не знает об остальных, это слёзы радости под конец рабочего дня и желание пойти накатить в честь этого крафтового пивка.

Я бы не выдержал такое каждый день

Ну как сказать.
Понимание, что ты делаешь окружающий мир намного лучше — это отличная мотивация на каждый день. А ничто не сравнится по вкладу в улучшение окружающего мира с приведением кодовой базы в легко поддерживаемое состояние

Сравнится:
* помощь деньгами знакомому, которому хреново
* разработка и внедрение архитектуры, способной пережить изменения требований

Разве что второе.
Первое — ты всегда можешь быть обманут, даже знакомым

ты всегда можешь быть обманут, даже знакомым

Разве это важно при хорошей зарплате?

Разве это важно при хорошей зарплате?

Зачем тратить на посторонних хорошую зарплату. Ладно ещё на нуждающихся близких друзей. Но на знакомых — такое.

А куда ее тратить?

Дорогие хобби, путешествия, для любителей бетонометров — бетонометры на любой вкус и кошелёк. Всё, что делает жизнь лучше.
Люди, как правило, привносят в неё проблемы.

разработка и внедрение архитектуры, способной пережить изменения требований

Для этого существуют методологии и структурные фреймворки, воплощающие методологи на практике. И это должен знать и уметь непосредственно разработчик. Наивно полагать, что какой-то очень умный архитектор нарисует диаграммы и стадо обезьян все это запрограммирует.

Если бы методологии и фреймворки работали, не нужны были бы архитекторы.
На практике видим, что или «формошлепство», где все полуавтоматизировано, или думать надо головой.

А якщо таких класів в проекті 500+ і переписувати їх на щось модерне і прогресивне нема ні в кого бажання, окрім тебе і 10+ тасків постійно висять на вчора, займався б таким?

Нажаль, я декілька разів потрапляв на подібні проекти і це дно. Спочатку, перших пару місяців, розбираєшся і вигрібаєш на ентузіазмі від нової роботи, потім приходить усвідомлення реальності, апатія, униніє, вигорання, пошук нової роботи.

Особисто для мене тепер робота з давнім легасі це за великі гроші, вище ринку.

А якщо таких класів в проекті 500+ і переписувати їх на щось модерне і прогресивне нема ні в кого бажання, окрім тебе і 10+ тасків постійно висять на вчора, займався б таким?

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

Умение сделать так, чтобы твой проект не стал таким унылым легаси — один из важнейших скилов программиста. А так-то все любят и хотят «начать с нуля». Только через пару месяцев это «с нуля» превращается в «унылое легаси».

Это скилл не конкретного программиста, потому что не он задаёт общий стиль разработки. То есть, теоретически скилл у него-то может быть лучше всех, но толку от этого немного. Если не имеется в виду, собственно, человек, который выполняет роль тех лида, конечно. Если же общего стиля нет, и каждый сам себе молодец, то это совсем печально.

Конечно, надо работать вместе с хорошими программистами. Если работать с плохими, никакой «общий стиль разработки» не поможет. К слову, даже с хорошими «общий стиль» должен в значительной мере обеспечиваться build pipeline.

Ну вот, а потом все удивляются, откуда такое в проектах творится). «Хороший программист» — это вода. Каждый такой «хороший программист» будет предлагать разные стили и настаивать, что именно его — самый «хороший». Поэтому решает проблему именно порядок и консенсус по поводу этого порядка (в данном случае действительно хороший программист примет адекватные доводы и изменит собственные практики — самокритичность просто адски важна).

Например, вопрос, который просто обязан решаться как можно быстрее и постоянно пересматриваться — темплейт типичного аппликейшена/сервиса (структура папок, именование всего на свете, что где лежит, подход к валидациям, да вообще общий подход ко всему). Это офигительно важно, и никакой билд пайплайн здесь не поможет.

Конечно, надо работать вместе с хорошими программистами. Если работать с плохими, никакой «общий стиль разработки» не поможет. К слову, даже с хорошими «общий стиль» должен в значительной мере обеспечиваться build pipeline.

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

Давайте смоделируем ситуацию (которую, я уверен, видели очччень многие), но с одним нюансом — проект очень большой. Итак, мы имеем:
1. Есть какой-то аппликейшн (скажем, отдельный сервис) с типичной 3-layer архитектурой и кучей бизнес логики. В сервисном слое есть много-много классов на много-много строк. Также юзается любимый многими паттерн репозиторий (но не юзается паттерн спецификация, которую ни я, ни один мой знакомый в жизни не видели никогда, ибо все ж «хорошие программисты» вокруг), поэтому репозитории превращаются со временем в огромные кучи дерьма (ну или юзается «прекрасное» решение с передачей делегата а-ля «делай, что хочешь», которое валит всю идею репозитория на корню).
2. Но мы же молодцы, можем рефакторить? Можем, поехали! Отрефакторили 10 классов в 100, и что получилось? Наш Dependency Injection превратился в печальку, потому что на каком-то уровне (который просто не все видели) это замена большего зла меньшим. Да, можно заюзать фасад или ещё что в голову придёт в конкретных случаях, но что мы при этом делаем? Мы боремся с симптомами, мы тратим тонны времени, мы не убираем причину, и при этом заменяем полный трэш печалькой. При этом репозитории вида п. 1 по-человечески и не отрефакторишь даже — придётся использовать тот же подход, что и для сервисного слоя (нужно признать, что подход в целом искусственный, и, о чудо, бывает, что SRP вполне себе не нарушается даже в огромных классах по уже применённому дизайну бизнес логики, и разбивать их приходится фактически искусственно).

Предлагаю «хорошим программистам» предложить своё решение, а я потом своё, и сравним их.

которые задаются в первую очередь архитектурой

А архитектура является следствием закона Конвея

И если архитекторы об этом не знают, не понимают, то в итоге архитектура будет представлять собой сферических коней в ваккууме, ту самую архитектурную астронавтику.
А споры о ней будут холиварами богословов о догматах вероучения.

Предлагаю «хорошим программистам»

хороший программист знает что в пару абзацев невозможно описать архитектурные проблемы проекта

Наивный да, думает что он может предоставить всю значимую инфу в пару постов.

А архитектура является следствием закона Конвея

Следствием этого закона является взаимосвязь между объектами в системе. Это — не архитектура. Это — бизнес-логика.

А споры о ней будут холиварами богословов о догматах вероучения.

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

Следствием этого закона является взаимосвязь между объектами в системе.

А архитектура — это и есть правила о взаимодействиях :)
потому что взаимодействия есть всегда.
а вот порядок — не всегда.

Всё давно изобретено.

Да, дело за малым — просто применять изобретенное.
Почитал на первом курсе книжечку о лучших практиках — ну уже и архитектор, да.

Но программисты делятся на тех, кто ими владеет и тех, кто их не усвоил.

Конечно. у меня вот один из тестов такой и есть
понимает великий архитектор, знаток бест практик о том как работает закон Конвея и почему, или когда у него палатка заваливается от ветерка — начинает рассуждать о качестве брезента, покрое, требовать ТЗ на каменных скрижалях, план местности и розу ветров, и т.п.

а дело то в — колышках :)

А архитектура — это и есть правила о взаимодействиях :)

Это — доменная логика.
Архитектура — способ разделения кода разного назначения. И больше — ничего. Она никак не зависит от того, какую полезную задачу этот код выполняет.

Почитал на первом курсе книжечку о лучших практиках — ну уже и архитектор, да.

Нет. Смог на реальном проекте разделить код так, как описано в этой книжечке и стало меньше времени уходить на его поддержку и разработку — архитектор.

Это — доменная логика.

Если по серьезному то есть несколько определений архитектуры программных систем. И опеределения эти связаны с контекстом употребления этого термина.

Архитектура — способ разделения кода разного назначения.

Это всего лишь одно из определений.

А вот софистическое, от Фаулера (которое он услышал от другого консалтера его уровня)
Архитектура — это решения по дизайну системы которые сложно изменить в будущем.

Есть и определения дающиеся в рамках инженерного менеджмента.

Или вот:
Что же такое «архитектура», и почему это не «дизайн». Архитектура — это тот набор ограничений, специфичных для системы или проекта, набор своего рода «правил проектирования», которому вы следуете, когда делаете дизайн. В чем выражаются эти ограничения — используемые технологии, некоторые договоренности касательно структурирования кода (определенный набор слоев и/или сервисов например), и диктуемая этими ограничениями необходимость задействования некоторого кода (фреймворка, например), уже не так принципиально.
...
Принципиально то, что дизайн нацелен на реализацию конкретного набора требований, в то время как архитектура — на реализацию широкого класса требований. Архитектура — это «стратегический дизайн», общие принципы построения и структурирования вашей системы, ее философия. Архитектура — это то, что вы не сможете «отрефакторить», и из-за чего вы будете переписывать систему с нуля, если оно плохое. Дизайн — это мясо, архитектура — скелет. Архитектура должна удешевить разработку в долговременной перспективе, чтобы система не треснула по швам при добавлении очередной порции требований.

Короче говоря, «архитектура» — это когда вы думаете сильно вперед.
(Gaperton)

И они все, эти опеределения — правильные.

Но когда знаешь только одно — то конечно, все остальное ересь :)

Причем если взять ваше

Архитектура — способ разделения кода разного назначения.

и от Gaperton’а — то вы дали определение не архитектуре, а дизайну :)

а то и вообще высокоуровневому код стайлу.

Она никак не зависит от того, какую полезную задачу этот код выполняет.

А на практике — ого как зависит.
Но еще раз — есть «архитекторы» которые понятия об этом не имеют.
О том что
«В теории нет разницы между теорией и практикой. А на практике она есть!»

Смог на реальном проекте разделить код так, как описано в этой книжечке и стало меньше времени уходить на его поддержку и разработку — архитектор.

Еще нет :)
Что точно — что ты тот кто смог на одном конкретном проекте разделить код как в книжечке написано, и т.д.
но архитектор ли уже — вопрос :)

Но конечно — скопипастил код с стековерфлов — уже программист!

Если по серьезному то есть несколько определений архитектуры программных систем. И опеределения эти связаны с контекстом употребления этого термина.

Я понятия не имею, что происходит в айти за пределами мобильной разработки.
В мобайле архитектура — это разделение кода на классы задач.
Любое новое требование заказчика можно разбить на задачи класса «изменения в навигации», «изменения в юай», «новые запросы к сети», «новые логические условия».
И органично вписать в уже сформированную модель приложения, в которой определённые слои будут отвечать за определённые задачи этой новой фичи. В итоге, никакое новое бизнес-требование не сможет повлиять на логику этого разделения по слоям, т.к. эта логика не зависит ни от каких бизнес требований и ничего о них не знает.
Вот те решения, которые никак не зависят от той задачи, которую решает приложение, а просто трактуют какая подзадача к какому классу относится — и есть архитектура.
Более того, она не зависит не только от бизнес правил, но и от использованных на проекте технологий. Завтра я решу, что библиотека для запросов в сеть X мне нравится больше, чем библиотека Y, которую мы используем сейчас и заменю её. Это никак не скажется на принципе разделения задач по классам. Я просто добавлю новую зависимость в проект, удалю старую и перепишу логику всего одного класса, который отвечает за использование выбранной библиотеки.

Я понятия не имею, что происходит в айти за пределами мобильной разработки.
В мобайле архитектура — это разделение кода на классы задач.

ок, тогда нет предмета обсуждения :)

то что вы написали далее — обычная рутина кодера, даже не программиста.
да, и я тоже кодер, потому что пишу код.
но обсуждать эту часть работы — мне неинтересно.

В мобайле архитектура — это разделение кода на классы задач.
Любое новое требование заказчика можно разбить на задачи класса «изменения в навигации», «изменения в юай», «новые запросы к сети», «новые логические условия».

К какому из классов относится требования:
— приложение должно работать быстро
— данные должны хранится безопасно
— должна быть возможность восстановить действия пользователя в приложении
— приложение должно работать на определенных версиях ОС или устройствах
— должна быть возможность подключать новые языки к приложению, без переустановки
?

Те «классы» что вы перечислили — это классификация функциональных требований с позиции формошлепа. Архитектура сконцентрирована чаще вокруг НФРов и способов их достижения.

— приложение должно работать быстро

Ответы с сервера должны приходить быстро для этого.

данные должны хранится безопасно

Шифруем базу. А лучше — храним их на сервере.

должна быть возможность восстановить действия пользователя в приложении

Вьюмодел видит все действия пользователя. Она может дёргать соответствующие методы утилиты, которая будет их сохранять.
И что значит «восстановить»?
В текстовый формат экспортировать?
Зачем?

приложение должно работать на определенных версиях ОС или устройствах

Только на определённых?
Создаём класс утилит. В нём одна из них будет проверять нужные версии. Вызываться будет из слоя вьюмодел.

должна быть возможность подключать новые языки к приложению, без переустановки
?

Присылать строки с сервера тогда.
Это уже бизнес-логика. Её слой вытащит значения строк из ответа сервера, их подберёт вью-модель и прибьёт ко вьюхе.
Итого- ни об одной из этих задач архитектура ничего не знает. Они по-прежнему раскладываются по существующим полочкам шаблона без необходимости менять их местами.

Ответы с сервера должны приходить быстро для этого.

Они (ответы с сервера) у вас ничего не занимали, поэтому ничего вам не должны.
Задача архитектора в этом примере:
— определить что такое «быстро»
— определить окружение (хотя бы возможности сети)
— определить возможности сервера
— на основании всего выше перечисленного провести переговоры с бизнес заказчиком и принять правильное решение.
Кстати, а как тормоза в при отрисовке УИ будут решены быстрыми запросами? Еще одна из задач архитектора (технического, иногда его называют техлид) это направлять разработчиков на правильный путь и убедится что они не погрязли в собственной зашоренной классификации проблем.

Шифруем базу. А лучше — храним их на сервере.

Вот задача архитектора как раз принять/согласовать решение о том «шифруем базу или храним на сервере».

Вы по этим 2 примерам не смогли вложить их в свою «классификацию». Вместо того чтобы писать тактические решения, лучше задумайтесь о том чтобы немного проанализировать то что происходит вокруг вас.
Более прямая версия: ваша классификация — говно.

Задача архитектора в этом примере:
— определить что такое «быстро»
— определить окружение (хотя бы возможности сети)
— определить возможности сервера
— на основании всего выше перечисленного

Что архитектор приложения может решить на основании этого всего. Допустим, у нас слабая сеть, дохлый сервер и т.п. То есть, пользователь обречён ждать 10 секунд ответа на свой запрос. Ну в это время приложение может показать ему красивый порно-ролик, чтоб не скучал.

Кстати, а как тормоза в при отрисовке УИ будут решены быстрыми запросами?

В каких случаях отрисовка нативного УИ может тормозить?

Вместо того чтобы писать тактические решения, лучше задумайтесь о том чтобы немного проанализировать то что происходит вокруг вас.

Приложение не может влиять на вещи, находящиеся по ту сторону джсона. Более того, нет ни одного способа выяснить, действительно ли сервер присылает своё истинное состояние, или фейковое.

Вот задача архитектора как раз принять/согласовать решение о том «шифруем базу или храним на сервере».

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

Допустим, у нас слабая сеть, дохлый сервер и т.п.

Стандартные решения:
— локальное кеширование (сюда и прифетчинг, и изменение флоу чтобы зделать запросы раньше чем нужны данные)
— уменьшение пейлоада
— переговоры об изменении в работе сервера (чтобы не тормозил 10 сек)

Дальше не читал.
Вопрос:
почему человек который не работал с УИ лет 5 смог сходу придумать такие решения, а «Senior Android Developer» нет?

зделать запросы раньше чем нужны данные

То есть, подключить библиотеку, предсказывающую, куда нажмёт юзер? Дальше не читал

Вы же понимаете, что это решение хорошо только когда проблема в связи на строне пользователя? В случае со слабым сервером или узким каналом к серверу ситуация только ухудшится если клиент будет заранее запрашивать данные

Угу.
Это только один из возможных путей решения проблемы с получением данных на клиенте.
Изначально в комментарии Богдана было перечислено несколько направлений, в которых нужно копать.

— локальное кеширование (сюда и прифетчинг, и изменение флоу чтобы зделать запросы раньше чем нужны данные)
— уменьшение пейлоада
— переговоры об изменении в работе сервера (чтобы не тормозил 10 сек)

Мой комментарий лишь о том, что локальное кеширование это рабочий инструмент, а не

подключить библиотеку, предсказывающую, куда нажмёт юзер?
Мой комментарий лишь о том, что локальное кеширование это рабочий инструмент,

Локальное кеширование влечёт за собой подключение локальных DB в приложение, чего по возможности лучше избегать. На такое можно пойти только если от приложения требуется доступ к максимально возможному количеству данных пользователя в условиях отсутствия подключения к интернету. Это далеко не для всех приложений так.
Например, в приложениях вызова такси, доставке еды, мобильных интернет магазинах разумно при отключении от интернета просто выдавать сообщение об ошибке подключения, чем пытаться откуда-то взять кэшированные данные.
Почему лучше не использовать подключение к локальной БД.
Потому что все варианты её реализации (SQLiteOpenHelper, GreenDAO, Room, и т.п.) требуют ссылку на Context, являясь при этом data source. То есть, рушат архитектуру и иерархию зависимостей, заставляя передавать applicationContext из Активити при инициализации вью-модели конструктору репозитория/дата сорса, которые по определению не должны знать, что запущены в мобильном приложении.
Далее, слой БД будет невозможно покрыть юнит тестами.
Ну и наконец, обращение к БД требует уже настоящей реализации многопоточности, т.к. очень легко получить несколько выполняемых транзакций одновременно. Хоть сейчас связка Room+Coroutines и сильно упростила эту историю, но добавлять локальный кэш в приложение is a bad idea unless it is absolutely necessary.
Если ответ с сервера идёт долго, то это печаль кастомера, который экономит на сервере и бэкенд разработчиков, которые не позаботились о скорости риспонсов. Это точно не проблема клиентской части и нужно не бороться с последствиями этого явления, загружая весь сервер в локальные базы устройства в бэкграунде а потом запросе к этой локальной базе при нажатии на любую кнопку (хотя и такое решение бывает валидно, например, в приложении с базой персонала крупной корпорации), а делать сервер быстрым. Как? Ну вот для этого эти ваши литкоды вам и нужны. Мы в приложении не работаем с терабайтами данных и можем себе позволить забить на производительность алгоритмов. Вы на сервере — нет, у вас могут быть терабайты пользовательских данных и это ваша задача отдавать их клиенту быстро.

Ну вот для этого эти ваши литкоды вам и нужны. Мы в приложении не работаем с терабайтами данных и можем себе позволить забить на производительность алгоритмов

Ну, ща начнётся 😅

Ну, ща начнётся

Не, ну серьёзно. Мне плевать, обработаются мои 50 объектов в корзине интернет-магазина из объектов типа StoreItem в тип BasketItem за 1 или 15мс.
А вот если риспонс с сервера будет приходить не за 1 а за 15с, потому что бэкенд девелопер реализовал не самый эффективный алгоритм, то это п**ц.

Тем не менее, на доу такое мнение непопулярно. А вот что популярно — это стереотип о том что все фронтендеры и фуллстеки рукожопы, а бекенды боги

это стереотип о том что все фронтендеры

ну, префетчинг данных во многих случаях сооружается на коленке, без всякой великой науки.

и то что Senior UIщик понятия об этом не имеет, да, и приводит к мнению что фронтендеры — рукожопы.

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

кстати менеджемент обычно считает богами фронтендеров :)
потому что результат их работы виден. а вот чем там бекендеры занимаются — нифига не понятно

кстати менеджемент обычно считает богами фронтендеров

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

это надо ещё посношаться и доказать.

я и написал — пичалька у вас с командами, если надо сношаться.

Все баги заводятся на кого?

зависит от того как они заводятся, какие правила их детектирования и заведения.

Это вопрос к вашим пиэмам и лидам.

А если баг на самом деле на бэкенде,

зависит от того как спроектирована и написана система.
У нас сторона основной части багов замеченных пользователями — детектится даже тестировщиком.
Думать просто надо заранее — о будущем саппорте приложения в целом.
А то что вы воспитаны по обычным правилам где всем на все насрать, «моя хата с краю» — ну да. Обычное дело. «Аутсорс» же. Норма. «Индусы» не в Индии. Это стиль, почерк команд.

Помнится у нас с вами был на эту тему разговор.
Так выходит что это просто его продолжение, где вы демонстируете что ваш уровень — сугубый мидл, потому что вы даже теоретически не понимаете что бывает по другому, и как озвученные вами проблемы можно разрулить — что технические, что коммуникационные:)

У нас сторона основной части багов замеченных пользователями — детектится даже тестировщиком.

Откуда тестировщик может это знать, если он тестирует фронтенд?

Откуда тестировщик может это знать,

мдя...
а вы точно имеете отношение к программированию?

кстати менеджемент обычно считает

всех говном. Правда об этом в открытую никому не скажут. Как и программисты не скажут что считают менеджмент тем же самым.

ну, на деле да конечно, разницу в отношении менеджмента что к фронтендерам что к бекендерам можно опустить....

тут просто частный случай рассматриваем :)

В случае со слабым сервером или узким каналом к серверу ситуация только ухудшится если клиент будет заранее запрашивать данные

Если птице отрезать крылья,
если ноги отрезать тоже,
то птица умрет от скуки
— потому что сидеть не сможет

Проблемы с слабым сервером и узким каналом — обычно не проблемы. Если конечно не желать за 3 копейки создать конкурента фейсбуку или гугл клауду, и вот чтобы сразу хайлоад, 100к конектов каждый из которых запрашивает агрегации по терабайтным OLAPкубам, или запускает перемножение матриц, и распознавание лиц в FULL HD видео с помощью опен полузаброшенной либы на С++ писанной студентами в качестве дипломной работы.

Во-вторых под префетчингом данных обычно подразумевают подготовку, отсылку, и т.п. БЕЗ инициативы со стороны запрашивающей стороны.
Иначе это не префетчинг будет, а рукотворный DDOS

Я такой префетчинг вживую видел в локальной, 100мбит сети, когда ребяты на Дельфях наваяли «префетчинг» на клиентах: 5 активных клиентов и локалка легла :D

то есть путанница уже изначально, префетчинг это не запрос избыточных данных на всяк случай. и не перегонка терабайт на клиент, чтобы забить такими объемами канал

То есть, подключить библиотеку, предсказывающую, куда нажмёт юзер?

мдя. «Senior» :D

Ілі, когда я віжу, молодой, культурний чєловєк бьйот кота, ето ж он сам сєбя обкрадиваєт, ето ж он нє кота бьйот, а сєбя!

libastral.so

локальное кеширование (сюда и прифетчинг, и изменение флоу чтобы зделать запросы раньше чем нужны данные)

Поможет только если проблема в сети и не поможет в случае с многопользовательским крудом

Поможет только если проблема в сети и не поможет в случае с многопользовательским крудом

Угу. Для операций, которые мутируют данные, изменение флоу чтобы не ожидать ответ от сервера. Работа архитектора, как раз понять в чем та или иная проблема и предложить направление ее решения.

Посмотрите на начало обсуждения. Суть такая:
архитектура в мобильных приложениях есть, но формошлепы на аутсорсе не всегда знают о ее существовании, потому что их работа ограничена

«изменения в навигации», «изменения в юай», «новые запросы к сети», «новые логические условия».
Суть такая:
архитектура в мобильных приложениях есть,

Извините, но делать префетч данных которые не факт, что нужны будут и делать все запросы в фоне, потом предоставляя пользователю нужный — это не архитектура.
Это костыли, в которые оборачивается убого написанный бэкенд.
Архитектура — это принцип разделения кода на функциональные слои. И служит она простоте поддержки и дешевизне расширения кода. Это по сути основные задачи, которые решает программист. Все остальные задачи по UI/UX, business value, domain logic лежат в других плоскостях.

Архитектура — это принцип разделения кода на функциональные слои.

прекратите хотя бы использовать слово архитектура в убого кодерском смысле :)

тогда может и будет вам польза от того что вам пишут.

Прекратите гордиться костылями и называть их «архитектурой».

Извините, но делать префетч данных которые не факт, что нужны будут и делать все запросы в фоне, потом предоставляя пользователю нужный — это не архитектура.

Принятие решения о том нужно ли это делать и отображение этого решения — это часть архитектуры.

Архитектура — это принцип разделения кода на функциональные слои.

Слои есть в layered architecture, далеко не все архитектурные стили имеют слои :) А еще есть хотя бы евент-дривен и микросервисы.

И служит она простоте поддержки и дешевизне расширения кода.

Про maintainability вы догадались, молодец. Там еще несколько десятков QA :)

UPD: modifiability можно сказать вы тоже угадали.

Принятие решения о том нужно ли это делать и отображение этого решения — это часть архитектуры.

В мобайле почти всегда это решение очевидно — не делать.

Слои есть в layered architecture, далеко не все архитектурные стили имеют слои :)

Опять же, в мобайле архитектура, не имеющая функциональных слоёв — говно. По той простой причине, что в мобайле много специфичной для платформы логики, которую нельзя смешивать с доменной логикой.

А еще есть хотя бы евент-дривен

Она прекрасно сочетается со слоями.

микросервисы

Какие нафиг микросервисы в мобайле?:)
Это ж не сервер.

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

Вы так пишете, словно это всегда тривиальная задача.

Это инстаграм может в фоне обновлять фоточки (потому что пользователь обычно заходит в приложение именно фоточки смотреть) и пытаться отправлять пост/лайк/комментарий пока не получится (потому что одну и ту же сущность не могут редактироввать два пользователя).

А представьте например приложение для работы со складом или интернет-магазин. Если товар взяли, то желательно чтобы в базу попала запись об этом факте как можно скорее. А ещё желательно чтобы каждый пользователь (работник) видел актуальную информацию, а не что-то там закешированное неделю назад. А как вызвать убер без связи?

Я уж молчу о том, что в любом случае нужен запрос и желание платить от бизнеса, а не программисту уходить в бесплатные овертаймы чтобы решить проблемы о которых вы говорите

Вы так пишете, словно это всегда тривиальная задача.

в общем виде думаю задача вообще не решаемая. Хотя степени PhD нет, кто его знает...

а в частных случаях — любая оптимизация — это заточка под свойства конкретного проекта, данных, флоу, на которую накладывают ограничения еще и компетенции персонала. процессы разработки, порядок поступления требований и сдача компонент в прод, и т.п.

вона, чел даже с термином архитектура разобраться не может — а гордо заявляет что это у них в мобильной разработке такое убогое понимание термина.
Но берется задавать «острые вопросы» в духе
«Хорошо, а как вы объясните что телеграмма прошла по дну океана, и не промокла?» (случай на публичной лекции по прокладке 1го трансатлантического телеграфного кабеля)

А представьте

фантазировать можно много.
Можно понапридумать тьму невозможных ограничений.

А на деле — и сколько запросов в секунду приходит в базу по резервированию товара, что это стало узким местом?
И если их приходит ого столько — то у компании нет денег решить проблему? что накупив облаков, что наняв настоящих синьоров, а не рукожопов которые и словей то умных не знают?, а обычные обязанности грамотного кодера величают архитектурой?

А как вызвать убер без связи?

а как вообще программа будет работать без компьютера?
аха, вот вам!

а как вообще программа будет работать без компьютера?

Кому-то может и заходят такие шутки, только это уже давно не шутки. Большинство современных мобильных приложений без наличия нормального интернета — не функциональны. И их задача — отражать актуальное состояние сервера в реальном времени, а не какие-то его кэши непонятной давности, а потом писать сложные алгоритмы вычисления, какой из кэшей хранит правильный стейт в каждой конкретной ситуации.

Большинство современных мобильных приложений без наличия нормального интернета — не функциональны

надо же.

И их задача — отражать актуальное состояние сервера в реальном времени

ок, у нас что SPA, что мобильные приложения отображают реальное состояние.
Что ж мы сделали не так с префетчингом, который на порядки разгрузил сервер... при этом актуальность данных на UI ближе к реальному времени, чем если б делали рендеринг HTML на сервере..
(о самом реальном времени — даже клиенты брокеров подключенные к серверам фондовых бирж напрямую не отображают данные в реальном времени. ну да ладно, не буду занудой).

Но вы да, расскажите беку что это невозможно. И нашим фронтендщикам.

какой из кэшей хранит правильный стейт в каждой конкретной ситуации.

понимаете какое тут дело — мне кажется вы понятия не имеете даже не о научных, а о простых ремесленнических способах работы кеширований.

И именно поэтому задаете нелепые вопросы, в полной уверенности что посадили в лужу.

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

Проблемы на вашей стороне, в ваших командах, где вы понабрались апломбу, не зная элементарного.

Что ж мы сделали не так с префетчингом, который на порядки разгрузил сервер...

Мне вот тоже интересно как префетчинг может разгрузить сервер. Можно даже статью какую почитать на эту тему. Потому как определение префетчинга, в которое верю я, выгляди так:

Prefetching in computer science is a technique for speeding up fetch operations by beginning a fetch operation whose result is expected to be needed soon. Usually this is before it is known to be needed, so there is a risk of wasting time by prefetching data that will not be used.

И вот я не представляю как данная техника может сервер разгрузить. Или вы что-то иное понимаете под префетчингом?

Мне вот тоже интересно как префетчинг может разгрузить сервер

правда не понимаете?
а если подумать? это ж вопрос для собеседования, на 10 минут общения об общем подходе, направлениях для проработки.

причем это ж не первый мой проект, где именно с целью уменьшения нагрузки И, чудо! попутно улучшения реактивности UI я его — префетчинг применяю.

Не, видя как дико тормозят подборы товаров на большинстве сайтов эл магазинов или подбора шин авто, я понимаю что премудрость это великая... Там правда вторая массовая проблема — люди не понимают как работать с реляционными БД, хотя все ж на словах знают, расскажут, еластиксерчи прикручивают., бо тупая, ой тупая эта чертова реляционка. «У нас даже Окракл тормозит, такая нагрузка, вы не представляете, у нас столько посетителей, такой ассортимент, ... тыща посетителей в сутки и ажно 10000 артикулов, по 5 характеристик в каждом! Вам и не снилось! хайлоайд у нас!» монгу нам надо, вот!

Но честно, не хочу подсказывать.

как определение префетчинга, в которое верю я, выгляди так:

ну,
по вере вашей — да будет вам.
Невозможно, значит невозможно. Ничего не попишешь.

И вот я не представляю как данная техника может сервер разгрузить.

Префетчинг затем и нужен. Даже реактивность UI то уже такое, побочный эффект, следствие того что сервер и канал — разгрузили

У меня стойкое ощущение что вы называете префетчингом что-то не то, что обычно называют префетчингом, вот и всё. Потому что префетчинг — это подготовка (загрузка) ресурсов до того, как они понадобятся, без гарантии что они понадобятся. И это никак не может снизить нагрузку на сервер. В зависимости от того, насколько хорошо алгоритм будет угадывать нужды пользователя, нагрузка на сервер будет или такой же как и без него, или выше (если часто будут грузиться ресурсы, которые на самом деле не понадобились).

Префетчингом можно разгрузить сервер. Если фактически создать в начале сессии одним запросом его локальную копию, провести с ней все необходимые манипуляции на клиенте, а потом в конце сессии отправить на сервер.
Но это породит столько проблем, что я бы лично отрубил руки тому, кто бы так «разгрузил сервер» на мобильном приложении

просто нужно в начале сессии загрузить весь интернет, затем сделать в нём локально все необходимые изменения, а в конце сессии выгрузить весь интернет обратно!

Как только изобретут квантовые телефоны (после квантовых компьютеров), половина приложений примерно так и будет работать

И это, конечно, ни разу не костыль, а прорывная архитектура. Которая неслабо так разгружает сервер.
Правда, кому в этом случае нужен сервер с устаревшими данными — вопрос.
Если 100500 пользователей одновременно ведут 10-минутные сессии на своих телефонах и уже наклацали в своих локальных копиях товара больше, чем было на складе, то по завершению всех сессий будет облом большинству из них.
Кстати, именно такую ерунду в некоторых магазинах я и наблюдал. Таришься себе товаром, которого на сайте ещё завались, переходишь в корзину, оформляешь и в момент оплаты оказывается... Что какого-то товара на складе нет. Хотя 30 секунд назад его было полно.
Зато сервер разгрузили.

а потому что такие же синьоры как вы писали.

как в старом анекдоте
Гиви шпарит на красный
— Гиви, ты что?
— А я джигит!
Зеленый, Гиви по тормозам
— Гиви, зеленый же
— А там другой джигит может быть.

Тогда это не бекенд, а удаленный бекап. Для очень простых приложений может сработать (пока не найдется пользователь, могущий нагенерить ну очень много данных). По такой схеме можно использовать гугл доки (spreadsheets), правда заметно долго стартует приложение и сохраняет данные

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

по вере вашей — да будет вам.

Вы сейчас демонстируете как себя загнать рассуждениями в невозможность. причем если б вместо попытки убедить меня в неграмотности, и в том что у меня префетчинг неправильный — вы посмотрели б на собственные же рассуждения, то ответ бы нашли.

Не считал, и не считаю себя гением, и методики префетчинга — вычитал и увидел у других на проектах, а не сам такой весь из себя додумался.
Именно того самого, в опеределение которого вы верите, но не видите что в определении нет никакого запрета. Что это вы просто сложили так слова. так поняли.

насколько хорошо алгоритм будет угадывать нужды пользователя

да какой нафик алгоритм угадывания.
этим «великим» алгоритмам времени с досовского смартдрайва — кеширования файлов, из того что первым мне помнится как пришел в профессию. я тогда на Си писал, и не гнушался заглядывать в чужой код, чтобы поучиться. МS не публиковали свой, но были аналоги в DR-DOS кажется.
Сейчас да, читать чужой код не модно, надо ж свой писать! Сейчас каждый пейсатель норовит придя на проект фыркать как у вас все плохо то, а я то! Синьор не знающий что значит слово архитектура.

И это никак не может снизить нагрузку на сервер.

не может — значит не может.

но вопросом для собеседования вы поделились.
мне такое банальное как-то и в голову не приходило спрашивать.

мне такое банальное как-то и в голову не приходило спрашивать.

Вопросы вида "угадай о чем я думаю"/"угадай что я имею в виду под вот этим термином" были в индустрии всегда.

это не я думаю. он кругом, на пристойных проектах.
это вы его в упор не видите.

Так покажите. А то никто не видит, а вы видите

а вот про никто, не надо обобщать свою слепоту
Bogdan Shyiak вот тоже видит, и тоже не понял, «в чем проблема то?»
и еще раз, не верите как понял — это не я придумал. и даже не великие люди из computer science. это вообще просто хитрости ремесленника, если уж на то пошло.

прямо из древней статьи, которую никак не получается забыть, потому что уже синьоры вона, докатились до рубания рук, а статья все же о студентах:
Некоторые из нас, здесь, в Реальном Мире, были шокированы уровнем (если такое слово вообще применимо в данном случае) блестящих юных студентов-выпускников в области информатики
...
И в этот момент они осознают, или должны осознать, как мало в действительности они знают. ... И они еще не знают о такой штуке, которую все каменщики используют — о металлической проволоке, которая натягивается вдоль стены, чтобы все кирпичи лежали ровно даже на 100-метровой кладке. И они вообще ничего не знают о современных подходах в строительстве, вроде лазера который позволяет прочерчивать ровную линию вдоль стены. И они не знают как противостоять сильному ветру на высокой стене. Никто не говорил им о подкладках под стойку и о линии промерзания. Они даже не знают как пользоваться простым молотком, чтобы разбить один кирпич на два. И у них нет никаких, даже самых туманных представлений об эстетике, и поэтому они не знают что же слово «декоративный» обозначает в действительности.
«Специальность — каменщик»
Опубликовано: 25.12.2004
www.rsdn.org/...​e/career/BrickScience.xml

а готовых ответов я не даю.
давно и принципиально. либо вы влючаете мозг, либо открываете учебник с обратной стороны, и читаете ответы сами.
минимум потому что всегда найдутся что дадут.

Тогда это как в том анекдоте, «и вы говорите». Пока что есть голые слова от вас что префетчингом, в самом определении которого заложена лишняя нагрузка, вы разгружаете сервер.

У меня есть проект в проде с префетчингом. Причём я не вижу смысла даже статью писать, потому статей этих полно, и докладов тоже.

Прикол был даже когда взялся делать доклад, а на следующий день после доклада обнаруживаю в ленте доклад о том же, так же, от лида фронтендеров кажется альфа банка.

Но вам телепатам всегда виднее где голые слова, а где нет.

В определении префетчинга никогда не было заложено,что вы в голову себе вложили. Не,конечно,раз у вас в голове такая мысль,то можно нагуглить где она будет записана другими. Оригиналов не существует (исключения можно опустить)
Это все — ваш выбор, какое определение взять и главное как его истолковать. Знание не тождественно понимаю. Не моё тоже.

Вы хотите меня убедить что я неправильно понимаю.Ну ок. Зайдём с другой стороны.
Понял я неправильно и делаю работающие решения. И бек и фронт команды у меня не собачаться как у нашего синьора, и нагрузка на серваки меньше, и UI реактивный,и две внешние экспертизы прошли,и стейкхолдеры довольны их отчётами.Конечно замечания были.

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

Давайте я вам лучше о тренде расскажу, с которым встречаюсь все чаще. Молодые программисты все чаще не в состоянии прочитать собственный код. Я когда впервые столкнулс, лет 5 назад, не поверил. А потом... Садишься рядом,начинаем разбирать его код,он уверенно так

Здесь я написал сделать шаг вперёд,повернуть налево,и два шага.
Точно,говорю? Посмотри внимательнее. Смотрит, смотрит, а да, ошибка, тут полшага лишние.

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

Смешно, правда? Только вот через один пулреквест такие разборки

Ну,или пословно разбирать определения префетча.

Знаете, мы или используем общеупотребляемые термины в их оригинальном значении, или мэкаем-бэкаем и объясняем на пальцах. А называть картошку ананасом и утверждать что вы из ананаса вкусный борщ варите — можно, но вас никто не поймёт. Что сейчас и происходит.

Префетч не разгружает ничего, и это не его назначение. Префетч ускоряет работу софта ценой использования лишних ресурсов (в идеале — свободных ресурсов).

Кеш на стороне сервера ускоряет работу софта и может разгружать сервера, но тоже не бесплатно. Как правило — разгружается процессорное время и операции чтения/записи за счет оперативной памяти (где и хранится тот самый быстрый кеш).

Кеш на стороне клиента делает то же что и кеш на стороне сервера, но уже ценой памяти клиента. Звучит заманчиво, но чет клиенты бухтят на приложения, занимающие по пару гигабайт оперативы. Странные, жалко им что ли.

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

Ну вот и сложите 2+2. Я ж с этого и начал:

Как предзагрузка данных, которая может оказаться невостребованной, по аналогии с «cache miss» — разгружает сервер — на практике.
Вы себе внушили что между теорией и практикой нет разницы. А я постоянно цитирую что на практике она есть.
Что определение префетчинга НЕ запрещает использовать его для уменьшения нагрузки на сервер. НЕ в общем случае. НЕ во всех проектах. И даже не во всех схожих проектах которые сделала некая команда за условные последние 3 года.

А не цитируйте чеховское «Письмо к ученому соседу»
Этого не может быть — потому что этого то не может быть никогда.

Подумайте. Пораскиньте мозгами.

Возможно вы используете сокеты и зовете это префетчем

Сокеты, это о вы о Сетевая модель OSI — Транспортный уровень — TCP протокол?
И какая разница что там на транспортном уровне происходит?

вас никто не поймёт. Что сейчас и происходит.

сторонние аудиторы поняли. Потому что есть та самая предзагрузка данных, которая, в общем случае может оказаться избыточной, и как приводил в живом примере — положить 5ю клиентами даже не сервер, а локальную 100Мбит сеть.

Я не говорю что у вас нет опыта.
А говорю то что наблюдаю многие годы — догматизм, чисто религиозных, зазубривание — если и не норма, то обычное дело в нашем цеху. Программистов. И поэтому заразиться этой напастью как гриппом или ковидом — несложно.
«Индусы» не в Индии.

Поэтому кстати в спорах «Нужна ли математика программисту» я говорю что не нужна. Потому что программисту в первую очередь программисту нужны — мозги. А не теистические убеждения и поиски общих ответов на обобщенные, абстрактные проблемы.

Потому что программирование — не математика, и ее методы рассуждения могут и нередко играют злую шутку — на практике.
Для того чтобы это понять, конечно нужно — понимать математику :) Но кто ее изучает то с — пониманием. Сессию сдал — и радостно забыл все.

Но когда нет мозгов — то она бесполезна. И все готовые ответы беполезны, как в сказве братьев Гримм
«Смышлёный Ганс»
kidtale.ru/...​v-grimm/smyshljonyj-gans
(«синьор» привел пример от смышленных гансов, с корзиной покупок)

Вы мне скопипистатили базовые утверждения определения терминов и упорно показываете свою неспособность применять теорию на — практике. Неспособность работать собственной головой — рассуждать

Но не понял определения конечно я :)

«-Мы тут, молодой человек, готовим инженеров-практиков, а не физиков-теоретиков, прошу заметить. А инженер должен мыслить практически.»

Думайте, там нет никакой математики. А просто пресловутый здравый смысл. о котором
Что такое здравый смысл — сложно сказать.
Но когда его нет — видно сразу.

Если в споре кто-то кого-то считает кретином — то один из них точно кретин.
Возможно оба.

Можете меня записать. Я привыкший :)

Вы так пишете, словно это всегда тривиальная задача.

Вот сделать ее хотя бы не «писец это невозможно» — это задача архитектора.

Посмотрите на начало обсуждения. Суть такая:
архитектура в мобильных приложениях есть, но формошлепы на аутсорсе не всегда знают о ее существовании

Это уже вопрос к определению того, что есть архитектура, а что нею не является. Я не знаю какое определение точное

Я не знаю какое определение точное

да, у границы тумана тоже нет четких критериев — но где туман, а где уже его нет — как-то люди определяют.

суть то в другом, быстро названы многолетние архитектурные методы, а вопросы задаются как будто их названия впервые прозвували.

вот в чем прикол то :)

или вот, я просто не понял с чего начать ответ на вопрос о детектировании стороны ошибок.
с того как передаются байты по сети, или как прикрутить какой-нить забикс к нативному мобильному клиенту, или с практик обработки в — системе в целом.

а может с того что такое текстовые файлы, и чем они отличаются от логов? фик его знает как отвечать на вопрос
Да, согласен, но если Христа нет, то почему вампиры боятся распятья?

Дети вот мастера ставить в тупик такими вопросами.
Как один мальчик меня сразил на уроке по Питону
— Пишем вот print
— Так это каждый раз надо писать????

ну вот синьор меня сражает аналогично. что в прошлую с ним дискуссию, что вот сейчас :)

Предлагаю таки перечитать — там описана конкретная проблема, и кроме Вас пока в софистику никто не уходил). Вопросы обсуждаются вполне себе низкого уровня, про маппинг конкретного бизнеса говорить реально нет смысла (точнее, я предполагал возможность вскользь затронуть и этот вопрос потом, когда обсудим конкретный, но не обязательно). Поэтому желательно таки с аргументами — мне было бы интересно послушать по поводу обсуждаемого момента.

там описана конкретная проблема

ничуть.

там описано видение какой-то проблемы, и боль.
и попытки постановки себе диагноза. и намеки на правильное лечение.

причем сразу — неверные.
вот тут например:

поэтому репозитории превращаются со временем в огромные кучи дерьма

не-а, все превращается в кучи дерьма не потому что про какой-то паттерн забыли.
но пока вы уверены в обратном, в существовании серебрянной пули — то да, все пояснения будут софистикой :)

соответственно и варинаты решения проблемы.
Вы же уже знаете как правильно, верно? ;)

по второму пункту

Но мы же молодцы, можем рефакторить? Можем, поехали! Отрефакторили 10 классов в 100

заменяем одно слово, и
Но мы же молодцы, можем код педалить? Можем, поехали! Нафигачили 10 классов в 100.

Что такое — рефакторинг и чем он отличается от написания кода?

Мы боремся с симптомами, мы тратим тонны времени, мы не убираем причину,

да.
но говорить о причинах, искать их — софистика.

поэтому будем рассуждать о паттернах ООП, архитектурах. О математике и функциональщине — вообще будет правильно!
Искать потерянные ключи там где светло, а не там где потеряли — это мейнстрим подход.

кроме Вас пока в софистику никто не уходил

именно потому то я давно не участвую в таких холиварах всерьез.
незачем мешать архитекторам.
пусть побалуются и придут к

нужно признать, что подход в целом искусственный, и, о чудо, бывает, что SRP вполне себе не нарушается даже в огромных классах по уже применённому дизайну бизнес логики, и разбивать их приходится фактически искусственно

или, в разных источниках по разному цитируется:
Никакая проблема не решается на том уровне абстракции на котором она возникла(порождена, возникла) (приписывается Эйнштейну)

Помимо закона Конвея архитектуру формирует и предметная область.
И частота смены требований, плодовитость маркетологов и бизнеса. И много чего, что лежит вне «паттернов ООП». (что не говорит о том что они не нужны, и т.п.)

Архитектурная астронавтика возникает тогда, когда вся эта софистика игнорируется.

Так что — просто добавьте паттернов и «отрефакторьте» :)
Множество решений не бесконечно, вполне можете попасть в хорошее — и потом сделать доклад, как архитектура помогла.

Помимо закона Конвея архитектуру формирует и предметная область.
И частота смены требований, плодовитость маркетологов и бизнеса.

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

Помимо закона Конвея архитектуру формирует и предметная область.
И частота смены требований, плодовитость маркетологов и бизнеса. И много чего, что лежит вне «паттернов ООП». (что не говорит о том что они не нужны, и т.п.)

Архитектурная астронавтика возникает тогда, когда вся эта софистика игнорируется.

Сергей, а объясните мне плз, как относится конкретно вот эта вода в цитате к DAL->BL->UI (мы как бы обсуждаем BL и DAL)? Почему индустрия массово использует этот подход для типичных веб приложений? У всех же всё такое супер разное, но в подавляющем большинстве типичных веб проектов на .NET всё происходит именно так, как я описал. На других ООП языках, подозреваю, абсолютно подобная фигня для подобных же проектов (судя по многочисленным комментам на ДОУ, так и есть). При чём, я не рассматриваю даже кейс, где люди мешают эти слои (с этим всё и так очевидно), а рассматриваю кейс, когда люди пытаются делать вроде бы и хорошо, и при этом у них архитектура решения и дизайн баз даже адекватные (а-ля ну мы ж молодцы, всё вроде неплохо спроектировали уровнем выше, уровнем ниже разделяем слои в коде), а репозитории с бизнесом всё равно выглядят монструозно, и глобально для большого проекта эту проблему «типичным» рефакторингом не решить полностью (ой, у нас уже такие большие классы, надо что-то с этим делать, давайте как-то разбивать — оно ж так и происходит).

Говоря о конкретном вопросе, который мы обсуждаем, я заявляю о проблеме, которая появится на типичном большом веб проекте практически в любом случае, даже если всё остальное хорошо, и массовыми способами, с которыми к ней подходят, можно только её сгладить, но не решить. В случае, если что-то ещё нехорошо, эта проблема резко усугубится. Но есть способ, который позволит отказаться от типичного подхода вообще — он давно известен, и конкретную проблему предотвращает заранее на ура. Спойлер: не «хорошие программисты»). Я как бы начал разговор с ответа, что «хорошие программисты» и, прости Господи, статический анализ проблемы плохого кода сами по себе не решат.

Никакая проблема не решается на том уровне абстракции на котором она возникла
не-а, все превращается в кучи дерьма не потому что про какой-то паттерн забыли.
но пока вы уверены в обратном, в существовании серебрянной пули — то да, все пояснения будут софистикой :)

— Вы свеклу крошите кувалдой, ещё и не помыли её после арбуза, возьмите же нож.
— Вы не решите так проблему, нужен уровень абстракции повыше!
— Вас кто-то заставляет так делать, есть какие-то причины?
— Всё из-за нашей семейной организации, а Вы ничего не понимаете — буду так делать, Вы просто не туда смотрите!)
Без примеров всё это обо всём и ни о чём, а обсуждаемый вопрос очень сильно проще того, о чём Вы говорите.

именно потому то я давно не участвую в таких холиварах всерьез.

Прийти и сказать, что я в белом пальто и ничего говорить не буду — это мощный виток дискуссии).

Прийти и сказать, что я в белом пальто и ничего говорить не буду — это мощный виток дискуссии).

я всего лишь сразу предупредил что не считаю себя обязанным решать чьи-то проблемы.

и тригерюсь только когда вижу очевидные «очепятки».
или мне они мерещатся, тоже вполне может быть, выбирайте сами.

например

Вы хотели сказать, из-за постоянного хаоса в итоге делаем как-нибудь, потому что по-другому нельзя?)

это и правда очевидно.
а вот почему в большинстве случаев получатся кучи дерьма и при

я по дефолту принимаю, что здесь всё хорошо, и никто в шею не гонит.

да, совсем не очевидно.

Почему индустрия массово использует этот подход для типичных веб приложений?

потому что название индустрии
peopleware

Но общепринято считать нашу индустрию подразделом математики и видом инженерии сродни мостостроению или автопроизводству.

Кто не согласен — предать анафеме!
Не согласны правда и титаны типа Дейкстры, да кто ж и читает то. Хотя в вузах долбили ими студентов :)

ой, у нас уже такие большие классы, надо что-то с этим делать, давайте как-то разбивать — оно ж так и происходит

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

Но есть способ, который позволит отказаться от типичного подхода вообще — он давно известен

угу. просто мало кто о нем знает, а вы — знаете :)

не знают о нем и признанные авторитеты в нашей отрасли, которые по разному утверждают:
Невозможно написать(сделать) программу(инф систему) проще, чем задачи которые она решает.

Вы знаете. ок, делайте.

Я знаю всего лишь некоторые, и не универсальные способы как не делать ее сложнее задачи.

И мои способы все равно не превратят кривую роста трудозатрат каждой последующей фичи F, F+1 из экспоненты в прямую.
Мало того, (заочно, потому что и в километре не был), этого не умеют и в FAANGах.

Вы знаете. ок, сделайте.

Без примеров всё это обо всём и ни о чём

Повторюсь

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

а обсуждаемый вопрос очень сильно проще того, о чём Вы говорите.

Возможно да, я обратил внимание только на то что мне было интересно.

А если сильно проще, то ок, без меня обойдетесь.
Меня тут обрадовали что предстоит слияние и нашего бизнеса с партнерским и технологической части с их проектом... без поглощения, просто они нам данные, мы им алгоритмы, мы интегрируем часть их сервисов в наш, часть наших они в свои.
Все просто, мы не дураки, они тоже.
В пару абзацев сейчас напишу вам проблемки, и вы поможете мне их решить. Времени вагон, 5 этапов в первичном соглашении уже упомянуты, срок не озвучен...

Вот честно, без троллинга, я не понимаю почему тех задание на банальный импорт занимает не одну страницу, почему срок его выполнения будет сорван, хотя каждый день митинг, и я всегда готов ответить

но вот на форумах знают как более глобальные проблемы описать в пару постов, обсудить, и выродить вселенское решение, на века, на тьмы проектов :)

Я как бы начал разговор с ответа, что «хорошие программисты» и, прости Господи, статический анализ проблемы плохого кода сами по себе не решат.

Зависит от того кто такие хорошие программисты :)

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

и конкретную проблему предотвращает заранее на ура.

вопрос только является ли эта конкретная проблема хоть сколько то значимой в масштабах проекта, чтобы ее имело смысл решать.

а самое то главное — у всего есть цена.
и за любое решение придется чем-то платить.

можете не называя самого способа огласить стоимость способа, его риски?

угу. просто мало кто о нем знает, а вы — знаете :)

Та нет, я вот жду, когда все опытные и «хорошие» программисты назовут этот способ, который давно известен, просто он применяется гораздо реже, чем хотелось бы (а там, где применяется, иногда впедаливают его ортодоксальную версию «чтоб обязательно по книжке», хотя неортодоксальная банально удобнее — это как вечный спор про «это же не REST!111»). Но пока, увы).

вопрос только является ли эта конкретная проблема хоть сколько то значимой в масштабах проекта, чтобы ее имело смысл решать.

Ну... для каждого проекта по-разному (критичность), но в любом случае лучше не иметь огромных страшных классов, чем их иметь, а иметь тёплые ламповые понятные классы вместо них.

можете не называя самого способа огласить стоимость способа, его риски?

Он проще в поддержке и лёгок в понимании, поэтому рисков я лично не вижу вообще. Более того, когда его первый раз предложили, я чисто по психологическим причинам отфукался, как и большинство других разработчиков (был экстремально стрессовый проект, поэтому никто сильно не аргументировал и не объяснял — нет, ну и ладно, тот проект и так был обречён), а зря. Потом в более спокойной обстановке ребята выкатили мне простыню с аргументацией, показали, как использовали в другом проекте, я глянул внимательно и подумал, блин, а правда же, с точки зрения разработки и поддержки это на порядок круче стандартных «сервис + репозиторий». Принял их доводы и теперь доволен, как слон.

Он проще в поддержке и лёгок в понимании, поэтому рисков я лично не вижу вообще.

а они есть всегда.
и в моих любимых способах проектирования тоже.

Та нет, я вот жду, когда все опытные и «хорошие» программисты назовут этот способ,

их много вообще-то.

Если речь о DAL->BL->UI то наиболее долгий из известных мне холиваров это Rich Model vs Anemic Model

По крайней мере переход на Anemic приводит к резкому сокращению кода, слоев, абстракций.
но он не серебранная пуля

Причем с ним главная то проблема в сравнении с «сервис + репозиторий» — сложнее формализовать архитекторам, которые давно не пишут код :)
а в больших иерархических конторах таких много.

но интересно, о каком способе вы намекаете. их же много. даже простенькая коллекция(недавно наткнулся, закинул себе в покет) — насчитывает штук 20 архитектур для проектов на ООЯ
Причем в списке нет парочки моих способов. которые ессно не мои, «все мы карлики стоящие на плечах гигантов»

Наш разговор уже сподвиг меня найти релевантный топик на SO и написать это всё прям туда) stackoverflow.com/...​eeded-f/64295008#64295008

о, спасибо, пошел читать.
и извините что обознался. мне чаще оппоненты встречаются чем находящиеся на той же стороне баррикады :)

P.S.
Use Commands/CommandHandlers
да, старый способ
в зависимости от команды я его называю по другому
В нынешнем проекте обозвал Doingами :)

and Queries/QueryHandlers.
это как когда.

Но суть да, оказалась в холиваре

Rich Model vs Anemic Model

А она такая

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

1ый подход
Моделируем реальный мир, действительность. Классы и их объекты должны как можно более точно соответствовать моделированию домена. Так сказать — переписываем результаты бизнес аналитиков на язык программирования

2ой подход — «пишем микрофреймворк для этого класса приложений», лингвистический, «DSL», на уровень ниже требуемого уровня абстракции
А уж создав «язык», «кубики», «буквы» — собираем сущности предметной области, конечный функционал из них.
Новые требования? да легко, у нас же нет захардкоженых моделей — у нас есть инструмент для такого класса приложений в этой предметной области. пересобрали, да и все.

1ый подход — доминирует, ИМХО — его любят академические аналитики, преподаватели, менеджеры, он не требует высокой квалификации
(недавно в очередной раз встретил
Немецкий специалист пишет код для контроллера тормозной колодки автомобиля. Индийский специалист пишет код. Просто код. Какой запросили, такой и пишет)
то есть достаточно толпы кодеров, деятельность которых регламентирована суровой бюрократией.

2ой подход порождает меньше кода, но влечет более серьезную когнитивную нагрузку на разработчиков. и требует их понимания домена.
Настолько, что есть даже мнение у метров что Anemic — это вообще антипаттерн :)
По крайней мере я постоянно сталкиваюсь с этой проблемой:
переучить фигачить тысячи строк в день с «ООП головного мозга» очень тяжело на пару сотен тех что надо. часть из которых будет glue код между собственными ж компонентами.
У Алана Кея, его институт такой подход пытался довести до академической чистоты. но кажется не вышло.

Ну то есть мы вообще сервисы и репозитории в стандартном виде выкинули. Весь код лежит в хендлерах, которые из-за самой концепции не разрастаются, а просто добавляются новые на каждую операцию. Писать репозитории тоже нет смысла, т.к. тот же ORM EF Core в .NET и так даёт достаточно абстракций, чтобы работать с базой, и гораздо удобнее делать все вызовы в базу прямо в хендлере — и наглядно, и при этом не случится такого, что кода в этом файле слишком много. Для валидаций мы свою прослойку сделали, которая автоматически перед хендлером вызывается (готовых для MediatR’а, которые бы позволяли переиспользовать объекты, не нашли). А (если пойти «от обратного») был бы какой-нибудь а-ля «юзер сервис», то и «юзер репозиторий» бы понадобился, потому что в сервисе 100% будет слишком много кода, чтобы туда ещё и работу с базой запихивать, и пошла бы стандартная история с репозиторием «отдайМнеЮзераСИнклюдомТакимТо», «отдайМнеЮзераСИнклюдомДругим», с сервисом — через время тонна кода и т.п. Поэтому «хорошие» программисты со статическим анализом от подобных вещей ну никак не спасут, а вот CQS спасёт ещё и как.

Ну то есть мы вообще сервисы и репозитории в стандартном виде выкинули. Весь код лежит в хендлерах, которые из-за самой концепции не разрастаются, а просто добавляются новые на каждую операцию

да, это понятно :)
это и есть Anemic

см мой пост
skynin.blogspot.com/2012/10/blog-post.html
там есть, в
N.B.
Иллюстрация разницы для программистов::
Несколько слов в защиту шаблона «Анемичная модель предметной области» (Anemic Domain Model)

В нашем подходе репозитории discouraged by default (как и типичные классы сервисов) — для средних проектов они, скорее всего, вообще не понадобятся (нам не понадобились), а для больших количество кода на них сократится... даже не удивлюсь, если больше, чем в 10 раз. Сергей вот иронизирует, но мы уже на нескольких проектах обкатали этот подход, и везде он залетал просто на ура (даже на MVP залетал, хотя на больших проектах в нём будет больше всего смысла). Слава Богу, нашёлся человек, который вправил мне в своё время мозги по поводу premature abstraction и ООП (я был такой трушный ортодоксальный ООПшник). Опять же, подход давно известен, но мы используем неортодоксальную его версию, и она прекрасно решает типичные проблемы, которые возникают с кодом бизнес и дата слоёв.

нашёлся человек, который вправил мне в своё время мозги по поводу premature abstraction и ООП

когда я этим занимаюсь — меня записывают в еретики и водолеи :)
у мидлов от моего богохульства волосы дыбом и глаза наливаются кровью.

вам повезло, что еретик смог донести до вас иные, чем общепринятые взгляды.

вам повезло, что еретик смог донести до вас иные, чем общепринятые взгляды.

Там вообще талантливый человек — всего за 4 года вырос просто космически быстро, я таких больше не видел — кругозор очень широкий по многим вопросам, куда большинство даже и не собирается смотреть. Там, где обычным людям (и мне) надо читать, смотреть, думать, потом щупать, ковырять, пробовать, и так, пока не дойдёт, он как-то всё схватывает на лету прям сразу в том виде, в котором оно реально понадобится. Мало того, уже успел в другую технологию свитчнуться).

Я из Джавы ушёл когда понял что шанс найти команду под руководством еретика типа Антона Кекса маловероятно.
смотрел на и дотнет мир, но там та же история, описанная вами.
у пхп комьюнити правда другие проблемы.
может на ts уйду, хотя как мыслит среднеусредненный фронтендщик — то ой.

А куда ваш знакомый свичнулся?

Go. Ему и нравится, и целится потом напрямую на Запад работать (щас Go прям очень в моде).

В привычных мне доменах я ему особого применения не вижу... Семантически бедный ЯП. Но он ещё не добрал своей законной доли «на рынке». Так что да, вполне перспективный.

Конкретно мої випадки, про які писав вище, це були проекти, які передались в Україну на підтримку і доопрацювання після того, як над ними не один рік працювали «молоді прогресивні» чуваки і падруги з долини.
Після тих проектів, зробив багато цікавих висновків про каліфорнійських ІТ-шників не фаангівців.

В этом нет чего-то калифорнийского. Везде так.

А потом чувачок который писал эту кашу последние лет 5 деклайнит этот мерж реквест на код ревью.

Такое было.
Письмо на почту о том, что с понедельника мы прощаемся CTO и CEO улетело в тот же день.
На новой работе я запилил ещё лучше рефакторинг, в котором учёл ошибки того, прошлого рефакторинга. И его акспетнули

Если выбираешь enterprise, то с вероятностью 99% придётся работать с легаси. Но как по мне — нет лучшего метода выучить новый язык, чем разбираться с (хорошо написанным) чужим кодом

есть смысл уходить в архитектуру и экспертизу

Лично мне комфортно именно на позиции разработчика.

нет смысла конкурировать ... с молодыми

 — это почему же? В свои 58 успешно конкурирую.

В свои 58 успешно конкурирую.

Сижу я как-то на конторской кухоньке. Заходят 2 чувака и обсуждают кандидата:
— Ну он вроде чувак шарящий, опытный.
— Но ему где-то 27 судя по окончанию ВУЗа.
— Ну да, не факт что сработается с таким старым.
---
Мне тогда было 28, депресняк был до конца дня :)

Приличное образование на старте карьеры, как фактор успеха, никто не отменял, — проверено неоднократно ;)

Круті skills’n’experience працюють надійніше, ніж освіта та папірці про отримання освіти

ось так і з’являються senior angular 5.2 architect ;)

Йшлося про дещо інше. Можна перелічити у профілі кільканадцять десятків різнородних технологій, фреймворків і просто красивих акронімів, а візьмуть все одно людину, яка має профільну освіту, отриману не в найгіршому вузі, та кілька десятиріч досвіду.

Візьмуть того, хто зможе швидше та ефективніше приносити додану вартість. З освітою вона або він будуть, чи ні, нікого не хвилює.

Ще раз, читайте по губах: якщо є два кандидати з однаковим, плюс-мінус, результатом співбесіди/тестів, але в одного — диплом мехмата Московського університета й 30 років досвіду, а в іншого — Мухосранського технологічного коледжу і 5 років досвіду, кого візьмуть? Те, як людина ПРИНОСИТИМЕ У МАЙБУТНЬОМУ додану вартість, ще нікому не відомо.

але в одного — диплом мехмата Московського університета й 30 років досвіду, а в іншого — Мухосранського технологічного коледжу і 5 років досвіду, кого візьмуть?

А якщо мехмат МГУ і 5 років проти Мухосранськ і 30 років?

Дискусія вироджується, я відповідав конкретній людині на конкретний пост, тож, не маю бажання підтримувати цю гілку ;)

не маю бажання підтримувати цю гілку ;)

Интересный факт:
Люди, которые не хотят продолжать дискуссию, не продолжают ее.
Люди, которым не чем ответит, очень часто констатируют факт того что не хотят продолжать дискуссию ;)

Что ж, ответьте тогда на Ваш, чисто умозрительный, вопрос сами, как Вам нравится. А мне, в самом деле, стало скучно, да и не мне тягаться в убийстве времени со здешними профессиональными комментаторами ;)

А мне, в самом деле, стало скучно,
Люди, которым не чем ответит, очень часто констатируют факт того что не хотят продолжать дискуссию ;)

И Вам спасибо, не отвлекайтесь на меня, вокруг ещё столько неоткомментированного! ;)

не отвлекайтесь на меня,
Люди, которым не чем ответит, очень часто констатируют факт того что не хотят продолжать дискуссию ;)

дєдушку не візьмуть. нє впішєтся в молодой єнєргічьний калєктів.

нє впішєтся в молодой єнєргічьний калєктів.

Точнее, не будет с красными глазами овертаймить по 70-80 часов в неделю и не захочет менять мир и дисраптить маркет

Скоріш за все другого. Логіка наступна. Перший кандидат в два рази старший за другого, але навіть різниця в 6 разів в досвіді не дала йому показати кращий результат. Або другий настільки гарний, що зміг пройти однаковий шлях в 6 разів швидше.

Але, для легасі проектів візьмуть першого, але через вік, а не досвід. Бо він менш ризиковий з точку зору шансів на дострокове звільнення.

Як бачимо, в усіх логічних розсудах немає взагалі такої змінної як «освіта».

Про додану вартість. Спосіб принесення доданої вартості завжди відомий заздалегідь. Бо він є складовою бізнес процесу компанії. Тому люди підбираються під вимоги процесу, не навпаки.

різниця в 6 разів в досвіді не дала йому показати кращий результат

Вот тут важная ошибка, которую часто допускают при оценивание:
Почему-то не рассматривают случай, когда система оценивания не проверяет знания/опыт достаточно хорошо. В нашем случае, совсем не факт что наше собеседование было направлено на специалистов выше мидла (5 лет ОР).

Але, для легасі проектів візьмуть першого, але через вік, а не досвід. Бо він менш ризиковий з точку зору шансів на дострокове звільнення.

То есть середнячок с небольшым ОР менее напорист чем человек, который поступил в один из самых конкурентных ВУЗов в тогда еще своей стране? Или у 25-50-летнего мужика уже не может быть кризиса среднего возраста?
Ситуации могут быть очень разные, делать выводы на основании предубеждений — не эффективно (велика вероятность ошибки).

в Родине я возьму того который с опытом вообще не глядя на универ разве что это моя альмаматер причём потоки пересекались тогда только подумаю посмотреть на универ

в штатах я возьму того кто имеет диплом престижного университета селяви ничего личного просто бизнес

Шикарный комментарий! Спасибо! Прям копи-паст молодым в какой-нибудь Hitchhikers Guide to IT World ;).

Я бы назвал бы этот материал «критический взгляд на отрасль без идеализации».
Материал хоть и не бесспорный, но очень важный — не хватает нам всем определенной доли здорового скепсиса, особенно в публичной плоскости.
Большое спасибо !

Данная статья — исключительно видение ИТ компаний в Украине через призму автора, то есть субьективное мнение. Более того, я бы сказал, что мнение, знатно приправленное сборником шаблонов :) К примеру:

Мелкий атусорс — значит не более чем кузница кадров, условия жесть, нет налаженных процессов.

Крупный атсусорс / аутстафф: много говнопроектов, много говнокодеров, зарплата тоже говняная :)

Продукт: ищут только фанов дела ( мне кажется что пример списан с игростроя), быстрое выгорание

Фриланс: с одной стороны работа мечты с другой — ты себе и жнец, и на дуде игрец, да еще и конкурирующий с толпами голодных джамшутов стоимостью по 2 доллара пучок :)

В целом, часть описанного присутствует в мире украинского ИТ но также есть и адекветные ваканскии ( как и компании ) в любом спектре услуг

Не нужно настраивать себя, что вот всё плохо и нижесказанное обязательно со мной произойдет (может и нет). Но знать о ямах, что могут встретиться на дороге полезно — можно будет их обойти.

У меня немного меньше опыта, чем у автора (с 2007 года в QA), но работал и во многих крупных компаниях, и в небольших, и в продуктовых, и за границей.

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

Многое зависит и от человеческого фактора, который присутствует вообще везде. Во фрилансе могут и на бабки кинуть :)

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

При выборе работы галера имеет 10% значения, остальные 90 — это проект. Видел как в одном опенспейсе часть работала на потогонке, а часть с другого проекта лениво писала по 50 строчек в день.

лениво писала по 50 строчек в день.

Просто обожаю, когда трудозатраты оценивают в количестве строчек кода. Если б ещё платили за них сдельно, я бы уже на Феррари ездил

Лениво 50 строчек в день — это значит сначала пошли пить кофе, потом теннис/приставка, потом обед, после обеда 1-2 часа что-то поделали а там уже и домой пора.

А если 250 строчек в день — то это уже «целый день из IDE не вылезали»?
Если что, я могу и 1200 строчек закоммитить за час работы, получить за них денег, как средний гребец за неделю и пойти болтать с коллегами

Окей, для туподоходящих перефразирую: одни много работают и приносят большой результат, другие пинают *** и результат низкий. Так дошло или надо еще елементарней обьяснить?

Количество строчек кода никак не коррелирует с количеством работы. Я могу за час нагенерить тысячу строчек кода, вообще не устать и весь день бакланить. И можно весь день дебажить тысячи строк говнокода, упороться в аут и написать одну строчку кода, которая пофиксит все проблемы, когда поймёшь, в чём была первопричина. Так понятно, что разработка софта — это не ввод печатных символов с клавиатуры, а мыслительный процесс?

Як стосовно ремоуту на продуктову компанію? І раніше хайрили з Європи та Штатів, а зараз джоб борди взагалі вибухнули.

Проблема в том, что на эти вакансии подаются и из стран гораздо более бедных чем Украина. Зачем нанимать тебя, если можно какого-то Жуй Хуя из Вьетнама за 300 долларов?
Вывод? Нужно быть сильно лучше рядового Хуя, чтоб разница была на лицо

продуктову компанію

Ключове слово. Компанії які розроблять свій продукт, клон уберу наприклад. Які наймають віддалено. Якім треба досвідчені розробники. Не Хуї. На нормальну зп в євро/баксах.
Отут їх просто неміряна купа — remoteok.io

Их много, но по факту многие на ставке около 60к в год, что в принципе неплохо, если тебе просто нужна удалённая работа. .NET, например, там как-то плохо представлен.

remoteok.io

только хотел сказать — кто все эти люди? как сходу заметил 3 компании, продукты которых использую

Зачем нанимать тебя

Працюю на продуктову компанію яка хайрить на ремоут по всьому світу, женуться не за тим щоб заплатити 300 баксів, а за крутими спеціалістами своєї справи. Відповідно якщо є чудовий інгліш, експертиза, проактивність і живий інтерес робити роботу то забирають з руками і ногами.
Часто по пів року шукають нормальних кандидатів

Поэтому нужно стать крутым о чём и речь

проактивність і живий інтерес робити роботу

Хрюшей запахло ;-)

у вас просто хрюші нормальної ніколи не було! вони не пахнуть!

а якщо серйозно, то бісять пасивні чуваки в команді для яких вся робота це заасайнена таска в джирі, а щось самому головю подумати, запропонувати, підняти і вирішити питання — нима.

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

Ведь человек работает для того, чтобы домой денежку принести, и если он видит что его доп. активность на проекте дает ему профит, то он конечно будет делать вагон полезных дел. И идеи будут, и так далее

А если компенсации нет или она не соот. уровню предложений, то возникает обратный эффект — демотивация. Это если нет прямого наказания за активность (такое также бывает).
И специалисту в таком случае время проще заняться самореализацией в другом месте, к примеру — в open source проекте.

вся робота це заасайнена таска в джирі, а щось самому головю подумати, запропонувати, підняти і вирішити питання — нима.

За это не заплатят.
Я помню, были времена, в джире на тасках нужно было трекать время, затраченное на таску. Это очень быстро приучило к тому, что никакой работы, кроме той, что в джире, нет.
Инициативу нужно проявлять в том, как ты делаешь эту работу. А не в том, какую бы ещё работу сделать.

Читаючи такі коменти час від часу мені здається що аутсорс багато кому психіку поламав паскудним відношенням до працівника як до «ресурсу», настільки що переживши це ініціатива пропадає якщо не назавжди то надовго. Це кепсько. Я теж на таких проектах працював, теж час логував, і знаючи що я можу зробити таску за 6 годин на яку виділено 8, не брав нової.
Але не варто узагальнювати, не всюди так, і робочі місця де праця і ініціатива цінуються існують, і на апрайзелі баблішка досиплять якщо класно перформиш, і промоушин буде якщо лідитимеш тімку навіть без офіційної лички. Хоч можливо для декого це і звучить в стилі «ні синку, це фантастика» :)

, і робочі місця де праця і ініціатива цінуються існують, і на апрайзелі баблішка досиплять якщо класно перформиш, і промоушин буде якщо лідитимеш тімку навіть без офіційної лички

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

лишнюю копейку

виртуальную копейку

Давайте не будемо про крайнощі. Бо в протилежному куту знаходяться керівники, які не в змозі налагодити роботу, натомість добре співають пісень про проактивність та команди що організуються самостійно.

Посмотрел на открытые вакансии — с экспертизой хотят в США, на ремоут только в саппорт. А жаль, мне бы, наверное, подошло.

Можемо продовжити в лінкедін, дивлячись на ваш профіль думаю підійшла б вакансія про яку поки тільки були розмови в середині компанії, вакансії ще сформованої немає.
І так, ремоут 100% буде

Есть мнение, что поработавшие с Сунь Хуями за 300 долларов сильно переосмысливают подходы к найму.

Чем лучше Васыля Сынежопынко за 2000 баксов?

Так прикол же в тому, що є як толкові Жуй Хуї так і толкові Синьожопенки.
Але! Якщо є якийсь толковий Жуй Хуй або Рамшит Рамакрішна, то їх схайрить місцевий гугл чи, на крайняк, майкрософт, на геть крайняк Алібаба або Тікток.
А якщо ти толковий Синьожопенко, то в тебе Гугла поряд нема, тобі або на галеру або фрілансити або удальонка на нормальні контори першого світу.

От і виходить, що Сунь Хуїв багато, а толкових мало, а ті що є, можуть бути дорожчими за Синьожопенка, бо його треба перекупляти в гугла.

Английский — плохо, особенно когда говорят сами. Скилы — базовые. Плюс ещё национальные особенности:
— Как там ХХХ?
— Хорошо-хорошо, уважаемый господин!
...
— Алё, кагдила? Где?
— Ой, не бейте-не ругайте, уважаемый господин!
(вместо «у меня вот тут затык, помогите»)

Кожаев Вова — молодец, политик, лидер и боец.

Подписаться на комментарии