+

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

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

и оформление по кзот..? или все таки фоп сотрудничество?..)

если говорить о юнит, то допустим прилетает тикет разрабу — он должен понимать что реализация 80-85% импл логики и 15-20% тесты. Как показывает практика, чем лучше прогр пишет (чистый код с точки зрения граммотности) тем лучше он вписывается в это 15-20%. Чем топортнее разраб тем больше у него времени на тестирование уходит (сюда особенно показательно вписываются любители методов на 100 условных строк). Если говорить про интеграционные — это отдельная парафия, и хорошо бы их не рассматрить с точки зрения работы программиста при имл фичи — их хорошо рассматривать отдельной работы и они прямопропорциональны сложности выбранной логики и кол-во сценариев (интерграционными тестами по хорошему должен заниматься вообще другой человек) — это как раз и есть работа для AQA+DevOps на интересные нетривиальные кейсы в ходе пользовательского тестирования. Еще не стоит забывает про АПИ и лоад тесты — их можно и разрабу поручить — это как показатель стабильности работы кода, особенно последние — порой ребята совсем не задумываются как бд будет рыгать на кучу неоптимизированных запросов и даже немного усложненная кверя может дать значительный просак на уровне 100юзеров допустим. В моей практике хорошая импл получается когда разраб при разработке пишет юниты, покрывает АПИ кейсы (это можно и покрыв контроллер слой, или банально в постмане наколотить коллекцию с тестами), и делает допустим каким то jmeter ом нагрузочное тестирование, и к тикету прикладывает результаты — на ревью все это барахло видно, тогда есть более менее реальный шанс, что если баги и будут зарепорчены, то только в профтыке или недопонимания по реализации бизнес-логики, но не корявости импл.

тут скорее идеологический подход команды (читай тимлида или дев отдела в целом) : время на написание юнит тестов заложено в разработку. и все. Заказчик аксептит время — и если оно его устраивает, то остальное вопрос уже 3ий. Юнит тесты это прежде всего ДЛЯ РАЗРАБОТЧИКОВ, для их уверенности в заврашнем дне (в плане работы имплементации) и для тимлидов — дабы быть уверенным что новый разраб на проекте не сможет задеплоить, если логика будет сломана после его правок (во всяком случае вероятность этого дела возрастает прямо пропорционально качественному написанию юнит тестов...можно же и такие тесты написать, что все будет работать несмотря ни на что:) ).

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

Ты женат или так, чисто свои 5 копеек вставить?

Примеров тьма. И вопрос реально большой что считать «равным». Чисто вот с точки зрения опыта и жизни (жена не в ИТ, зарабатывает меньше — все тратит на себя, немного иногда на дом/семью/знаки внимания мужу...типа там шейкер в зал купить «потому что твой совсем древний» — з-забота (приятно, ужасно) ). Итак, это идельно. ТК нормальный, славянский мужик, в моем понимании, совершенно не хочет чтоб ему девушка/жена рассказывала как жить, и чувствовала себя там сильно равной. Царь и Бог должен быть один. И от этого выигрывают все — тк основная если не вся ответственность на мужчине — он в почете, ему в радость баловать жену, зарабатывать больше, иметь за собой последнее слово (пусть и использовать это крайне редко) — но сам факт!
По этому честно...не верю в офигенные отношения (в славянских национальностях) где бытует равноправие --- с течением времени оно переходит в матриархат и это ужасно как по мне.
Ну и плюс...разговаривать айтишные темы дома...пффф.
А вот когда дома рассказать о своем и послушать что то из области юриспруденции — очень интересно и никогда не надоедает. С женой гуляем каждый день по вечерам и всегда есть что обсудить.

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

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

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

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

Вот именно так и есть

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

 — именно так! 2 реальные, ежедневные ситуции:
1) идем на базар за клубникой
— трещим с бабулькой, пробуем, и думаем берем или нет(условно выполнение тестового задания — тк продавец дал клиенту покушать бесплатно), но когда клубничка красиво выложена пирамидкой в приличном лотке — тетка помоложе бабульки обычки кричит — «проба только через весы»: разбираем — качественная сортовая большая и красивая клубника стоит бабла (ситуация «джуниор вс опытный специалист» на лицо) — итого, для того чтоб купить клубнику во втором случае мы можем помимо того что посмотреть на красоту клубники еще спросить откуда она и тп вещи — но узнать развела ли тетка на водяную клубнику уже можно исключительно после того как ее купим. в 99% эта новомодная наливная клубника будет стоить > той что можно бесплатно попробовать у бабушки.
2) компания разработчик софта хочет втащить свой софт новому клиенту — можно вести долго переговоры и тп — но расширенную версию, а порой даже просто полностью рабочию в отличие от демо (которое работает на 10%) клиент получит только после внесения определенной суммы.

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

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

Именно. Или есть у вас инсайд что им просто робота нехватает для «рутинной» работы?)
Распределение времени на кодинг be посидеть/подумать/погуглить/почитать — весьма и весьма продукт сенситив. И именно по этой причини нельзя просто взять и измерять труд инженера/архитектора по затрэканному вождению мышкой и клацанием кнопки. Задача разработки: получить задачу-> оценить ее время выполнение-> получить подтверждение на выполнение -> сдать в срок (с попаданием с точностью 15%): включая разносного рода, покрытие тестированием/ревью. А не вождение мышкой. Тем более что в преобладающем большинстве (берём ИТ сферу) это сотрудничество с инженерами оформленными как ФЛП..какой может быть трекинг когда оплата идёт по актам выполненных работ.

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

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

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

Трекер реально позволяет помочь оцененить качество мануальной-повторяемой работы- например, фасовщика рыбы на заводе или сотрудника колл-центра того же. Задача разработчика — получить таску, и закоммитить решение — в каких то ситуациях это реально клацание IDE + stackoverflow, в каких то (соотношение 50 на 50 в зависимости от позиции и сложности проекта в целом) — 5% коддинг — 95% рисование алгоритма на доске/бумаге. И честно говоря, качественные условные 5% коддинга и 95% мышления будут приносить больше пользы чем исполнения настроек трекера и борьбы с ощущениям себя в клетке, рамках.