Безробітні кияни зможуть безкоштовно навчатися у приватних IT-школах столиці, - міністр цифрової трансформації Федоров

Та ну. Такое говорите. Куда проще на программера выучиться. И айтишникам больше платят и тяжелую плитку таскать не нужно. Я в айтишники пойду - пусть меня научат.

Как гордо звучит: безработные киевляне. Может ленивые киевляне? или просто может настал?

Есть конечно же правильно. Гораздо хуже не есть. С голоду помереть можно.

Тут нечего возразить.

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

А если по вечерам начнёт шапки с людей сбивать и дрянь всякую нюхать то и до президента может дойти!

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

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

В фейсбуці пишуть, що будуть після тестування відбирати.
Бо інакше - гроші на вітер.

пойдут в IT Security - будут сканировать сервера и сетки и требовать поставить последние патчи - знаний нужно ноль, ответственности тоже ноль а денежки капают

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

Синий экра-аа-ан,
Похож на обмаан,
Похож на обмаа-ан.

Ну мне ближе не BSOD а PSOD, но я даже и не вспомню когда последний раз его видел. Дай Бог шоб и не видеть. .

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

Ну в такому разі приклад. Є два художники. Закінчили одну й ту саму школу. Тільки один стіни в дідсадках розмальовує, а інший свої роботи виставляє в престижних художніх салонах. Якось так.

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

Странник,есть такой бородатый музыкальный анекдот :

Почему соловей поёт, а воробей чирикает?
Ну так соловей закончил консу на стационаре, а воробей - заочно.

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

Не совсем, современное программирование куда больше гуманитарно-ориентировано. В том же веб-программировании, например, уровня знания математики на уровне 7 класса вполне хватит для 99% разработчиков, поскольку всё более-менее сложное и алгоритмическое уже реализовано в виде библиотек. А что не реализовано, с приемлемым качеством можно написать после пары лет практики со знаниям математики на уровне простого гуманитария.

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

Я сам в особенностях конкретно веб-разработки не силён. Но, как завсегдатай программерских конференций вроде того же Сайберфорума или раздела /pr на Дваче, заметил, что в целом веб-программеры (что похапешники-бекэндщики, что жабаскриптеры-фронтендщики) алгоритмически и математически подкованы заметно слабее, чем крестовики и даже, чем некоторые жабокодеры. Просто потому, что для их задач это не надо.

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

И ещё один анекдотец...
Хороший дирижёр держит партитуру в голове, а хреновый - голову в партитуре.

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

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

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

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

Хех, смотря чем смажут стену. Я думаю, что Вы поняли о чем я.

В Киеве будет выгоднее обучать "мертвые души", а деньги украсть.

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

Может и есть: просто не всегда они озвучиваются.

Где бань для всех парильщиков напасемся?

профессирнальный баньщик это тебе не айтишник задрипаный..это Маг! Волшебник! все шо угодно достанет и как надо сделает епта!..вот ты кто? Странник..цыган перекати поле..настранствуешся и куда придеш? правильно! в Баню!

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

"так как это требует интеллект выше среднего и хоть немного математический склад ума"

ну это вы загнули конечно. есть специализации в ИТ где это не нужно.

Например?

техникал врайтеры, HR , всякие люди выполняющие нудную но простую работу, типа шаблоны для сайта и т.п.

HR - це "відділ кадрів" на радянській мові.
До чого тут IT?

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

и "відділ кадрів" это совсем другое. HR не занимаются приемом и увольнением с работы. их задача организовывать дурацкие ивенты, поздравлять с ДР и прочая хрень

И бухгалтер есть в каждой IT фирме, и HR, и уборщица - абсолютно в каждой.
Только к сфере IT эти три профессии не имеют никакого отношения.

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

фронтэнд, дизайн и веб-дизайн, QA...

Дизайн и вёрстка -- это не программирование, а Дмитро писал именно о нём.

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

Будет условие: Или выплата пособия или обучение. Фактически обучать будут за ваши деньги. Одно время практиковали на старт бизнеса всю сумму выдавали одноразово.

Географія - це не гуманітарій. Це - технарь 100%. Це добре для інформатиці. Він вміє кожну технічну особливість враховувати та має добре абстрактне мислення.

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

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

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

Я сам лично убеждался , как прекрасный разработчик low-level для embedded плевался и не мог понять логику графического интерфеса VB-6 ... А разработчик скриптов и VB вообще может прийти к летальному исходу , если дать ему разрабатывать драйвер на Kernel Linux , хотя это просто многопоточный Си .
Я сотни программеров перевидел и даже кандидатов и докторов наук . Сказать кто из них лучший не берусь .

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

Глупость несусветная . Потому шо где Вы освоите Linux Embedded , если для программирования под ним нужно недешёвое устройство от Самсунга ?!

Про друга Горацио слышали ?
Так есть на свете много разных специализаций , который самоучкой изучать займёт в 10 раз больше времени . Эт как раз по основам программирования есть куча бесполезных курсов и полезных книг , сайтов и т.д.

По тонким ньансам каждой конкретной специализации -- вот где курсы могут съекономить много времени . Основы WPF можно освоить самому . Но тонкие ньюансы с MvvM , с Prism осваиваются медленно . Усредненный работодатель никогда не будет рад , если "за его счёт" кто-то будет осваивать новую для себя технологию методом проб и ошибок . Можно месяцами тыкать ища нужное решения . А я бы подготовил бы так курс , шо за два занятия все ньюнансы и плюс неделя практики .
А с WCF ещё сложнее , там код и логику освоить несложно (если есть база по протоколам TCP и Http) там настройка своего же веб-сервиса -- ******* осваивать . Если не иметь чёткий алгоритм и быть уверенным , что он верный . Алгоритм настройки IIS ... Но для сисадминов такой инфы море в сети , а вот для разработки софтвера -- зась .

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

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

Опять же неточность .
1. Не алгоритма , а алгоритмов .
2. Только в процедурных языках таких как SQL или Си .
3. В ООП это описание объектов из связи и их интерфейсов .
4. Есть ещё АОП (аспектно ориентированное прог.) .

Смешно слышать , шо кто-то где-то и что-то подбирает . Программист , тем более не начальник R&D точно сам ничего не подбирает . 99% работодателей берут и даже программеров с опытом лидера группы уже на конкретный язык и конкретную платформу .
На С++ (Qt , Direct-X, Open-GL) никогда не возьмут с другого языка . Даже супер-дупер крутого . Раньше лет 10 назад можно было устроиться на С# имея большой опыт С++ . Но не наоборот .
Так шо базовый язык это не ИМХО , а один другому не ровня .
На сегодня в языке C# 10 тысяч только классов . И в каждом классе с десяток методов и свойств . А в SQL токо 50 инструкций ... И то и то язык . Правда SQL относится к классу скриптов . Программер скриптов это неполноценный программер . Ему никогда не дадут писать код больших и распределённых систем . Писать на С драйвера .
Но он может попасть в какую-то нишу , и 30 лет отрубить до пенсии на неплохих деньгах думая , что он безмерно крут . Бо просто не видел других фирм , других прог . И не понимает даже необходимость других задач . Даже реально крутого спеца в прогах Real time трудно убедить . что инфу нужно хранить в базе данных (простейшей и бесплатной) , а не окрывать 50 разных файлов от бинарных , до экселовых в сотне строчек кода . Бо он 20 лет не работал с базами данных и те были в универе .
Оне горят мол просто у нас система сложная и много разных людей писала . Как в той басне про петуха которому штаны укорачивали 20 раз ... А выходит , что не сложная , а искусственно запутанная . Потому шо прога это не набор алгоритмов , а система объектов и разделённых функционалов .

Я говорил вобщем в данном контексте. Вы говорите о работе айти фирмы, которая выпускает и реализует основную продукцию софт. Или иначе как делают сейчас интегрируют решение заказчику. Но существуют еще айти отделы промышленных предприятий. И там далеко не работодатель в лице Генерального директора определяет язык на котором будет происходить реализация проекта. Это делает именно руководитель айти отдела. Именно он подбирает продукт по заказу бизнеса, на котором будет это реализоваться. Специфика несколько иная. С первым утверждением тоже наверное не соглашусь. Понятие алгоритм есть последовательность действий в моем понимании. К примеру для включения телевизора нужно взять пульт и нажать кнопку. Это алгоритм включения телевизора или таки нет? Т.е. есть задача, есть цель, есть последовательность действий (этапы) выполнения задачи для достижения цели. Дальше этот алгоритм разбиваем на алгоритм взять пульт и алгортм нажать кнопку. Получаем два уже подалгоритма или иначе говоря дочерние алгоритмы. На мой взгляд тут все зависит от угла зрения. Я вижу это так. Относительно ООП тоже наверное не со всем соглашусь. Определенные алгоритмы уже заложены в классах на основании которых объекты создаются и наследуют свои свойства,и методы. То что эти алгоритмы объект получает в фоне неявно тем не менее не исключает наличия таковых в них. За АОП ничего не скажу. С сией парадигмой т.с. не знакомился. Ну и если прога это не набор алгоритмов, то мне любопытно на основании чего и при помощи чего объекты реализуют свои методы. И что есть вообще понятие метод объекта. Заранее говорю, что я не гуру и не супер программист. Я вообще бы себя программистом не назвал. Скорее настройщик программной бизнес логики предприятия. Так наверное правильней будет.

И еще наверное одно, что я не понял. Вот этот посыл что означает?
Даже реально крутого спеца в прогах Real time трудно убедить . что инфу нужно хранить в базе данных (простейшей и бесплатной) , а не окрывать 50 разных файлов от бинарных , до экселовых в сотне строчек кода . Бо он 20 лет не работал с базами данных и те были в универе .

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

Ну и еще одно ИМХО. Конечному заказчику откровенно все равно что у Вас там под капотом у Вашего софта крутится, на каких принципах построено и какими регалиями лично Вы обладаете или Ваша фирма. Есть ограниченное число принципов по которым он будет судить о качестве предлагаемого Вам программного решения и о квалификации фирмы, которая его предлагает:
1. Адекватная цена решения.
2. Разумные сроки внедрения решения. В идеале в соответствии с договоренностями, но в жизни это крайне редко получается.
3.Приемлемая заказчику скорость и стабильность работы данного решения.
4.Максимальное соответствие заявленному функционалу. Что в жизни так же получается чаще всего с определенными компромиссами с обоих сторон.
5. Интуитивно понятный дружественный пользовательский интерфейс.
6. Потенциал к возможному масштабированию.
7. Скорость реакции на инциденты, возникающие на всех этапах внедрения и дальнейшего сопровождения, если таковое оговорено.
8. Доступность и адекватная затратность расширения функционала.
9. Степень зависимости в дальнейшем от поставщика данного решения. Т.е. имеется в виду на сколько будет заказчик в плане сопровождения решения зависеть от фирмы, поставившей решение, после окончания срока действия договора на поставку и внедрение.
Вот собственно основные базовые критерии, которые собственно и будут определять совокупную стоимость владения данным решением для конечного заказчика. Я их максимально абстрагировал. И впринципе их можно применить практически к любому поставляемому продукту, а не только к программному.

Послушайте , уважаемый ... Вы серьёзно не знаете , что такое Realtime ?
Вот за это я не люблю чисто постсофковый термин IT , а предпочитаю HighTech бо последний больше охватывает область компьтерной инженерии . Бо Айти (по канотации)предполагает торговлю информацией , т.е. базами данных . Но Айти в разработке софтвера и хардвера только половина рынка . Другая половина не торгует данными из релятивистких баз . И у меня токо половина из фирм , где я трудился , имела вообще базу данных . Одна вообще в Аксесе - шо смешно . Однажды я писал прогу для фондовой биржи . Там база данных была абсолютно транспарентной и я к ней не подключался прямо , но через двух разных опциональных "агентов" (вот и объект) . Один на Шарпе - другой на Си . И там тоже было реальное время , бо 2 милисекунды решали судьбу утренних торгов , а также кто выиграет после торгов биржевой "арбитраж" . И быстродействие клиента не допускало вообще никаких обращений системам I/O - ни к файлам , ни к другим базам данных . Только процессор , кеш и память .
А в 2015-2016 я работал в филиале мировой корпорации (18 тысяч сотрудников) , проданной потом за 30 млд. баксов лидеру отрасли (70 тысяч сотрудников) . Но филиал делал прогу , шо помагает хирургу делать мелкие операции на сердце без полосные , а так же тесты .
Так вот там токо программеров было 20 человек и это самая крупная прога какую я видел и учавствовал . Из всех 20 я был один кто когда-либо писал даже обычный селект . не то шо встроенные процедуры и тем паче - динамические . Первые разработчики тогда решили , шо смысл в базе данных токмо , если она удалённая , а система distributed . А бизнес логика была категорически против этого . Не хотели сеть делать для системы . Вот и вышел stand-alone огроменных размеров с сотней тысяч програмных файлов на трёх языках С++ Native, С# , C++ managed . + Open GL , плюс технология OCR , плюс Image Processing ...
Там ещё присудствовали особые файлы формата JSon в которых писались не данные , а действия пользователя (т.е. хирурга) . В фирме было 4 кандадата наук - 3 физика и один профессор из универа , но у нас он писал графику на Open GL в обычном Си (даже без плюсов) . Тут миллисекунды не решали но вот точность в доли миллиметра - таки да . От этого жизни зависили пациента на хирургическом столе . Это и пытались продавать . Больницам похер была статистика , оне не занимались сбором анализом истории операции и какой-то выборкой . Я предлагал просто сделать код более модульным и системный , утойчивым к разного рода добавлениям и модернизациям . База данных в моём опыте это давала . И кроме того была куча тестовых прог - вот там была статистика и анализ . Но их писали студенты на VB-6 в 199... году . Я один там понимал этот допотопный язык и уродливый интерфейс разработки . И мне тоже не удалось их убедить перебить код на VB.Net и связать с базой данных . Так они все 15 лет 3 раза в год по несколько дней вручную анализировали данные из Эксела то , что встроенными процедурами SQL можно за 10 минут посчитать и вывести оптиму , найди закономерность и возможно (!) построить более точную модель измерения электромагнитного поля и учёта всех погрешностей внешних источников искажения поля . А так уволили 5 электронщиков только потому , что их прибор слишком высокую себестоимость имел и какой-то идиот купился на дешёвый "аналог" правда для немедицинских измерений . В том числе , ввиду сложностей оценки тестовой прогой погрешностей . Но оне требовали точные сроки . А я тогда ещё не знал, шо владея VB-6 и С# -- VB.Net можно освоить за пару недель . Поэтому не гарантировал точные сроки и точный результат , просто грустно заметил, шо сделав так лет 15 назад оне бы где-то 6 человеком-месяцев бы сэкономили бы .
Беда этого филиала была в том , что там были руководители -- военные резервисты . Офицеры технических служб . Не дураки - разумеется . Но опыт был лишь узкоспециального руководства и это было их первое и единственное место работы на гражданке. Хуже всего начальник , шо проработал год-два программистом , а потом его двинули , бо он в армии был офицером , Офицер без опыта даже лучше , чем вот с таким . Бо без опыта не мнит себя крутым спецом и прислушивается .

Все что Вы описали это специфика Вашей сферы, где Вы трудитесь. Я больше занимаюсь учетными системами предприятий. В этой сфере время не настолько критично, но критична надежность хранения данных и относительно быстрый выбор необходимого набора данных. Что значит работа в реальном времени я тоже как бы представляю. Ну и ничего не вижу особого в джейсон формате. В настоящее время это как бы стандарт обмена днанными. К примеру внешний API того же телеграмм именно его использует в качестве пакетов обмена данными.Ну а на счет плюсов, си шарпа, пайтона, джава скрипт, основ ИИ, плюсов связке с ардуиновсскими библиотеками и контроллеров это Вам с мелким моим наверное поговорить интереснее бы было. Он у меня сим увлекется и занимается. Правда ему всего 15 лет, но в нашей сфере возраст не играет особо большого значения. По плюсам он хотя и на базовом уровне но сертифицирован у цискарей. Скоро по плюсам адвенсед там же на серт опять ему сдавать. А так его хобби сейчас ИИ. Им же и по жизни заниматься хочет. Мечта в Бостон дайнамикс работать.

Открою страшную тайну - у меня нет т.н. "сферы" . К величайшему сожалению моя карьера сложилась так , шо фортуна "змусила мене" променять тишину и покой узкопрофильного спеца с десятками лет на одном рабочем месте и однотипными solutions и архитектурами , на полную универсальность . "Сожалению" , бо моя знакомая вот уже 18 лет копается в мозгах 16-битного процессора борясь за селикон (удешевление себестоимости embedded system) . И замечу - это для встроенных устройств типичная задача . Она один раз мой CV прочла и обзавидовалась разнообразию десятков сфер и языков . А я завидую её спокойной и томной рутине . Каждый года 2 раз тура за кордон в отпуск. Правда я не рекондсмен , мой бывший босс за 20 лет 22 компании поменял . Просто тупо второй у него был MS и не где-то , а самом Сиетле . А 22-й компанией -- https://www.mcafeefree.com/ McAfee(Intel) . И я его понимаю про Мелкософт знаю сто пудов , что там кто не имеет опыта в программирования , тот не принимает технические решения , не может уволить сотрудника , не определяет технические задания . Менеджеры низшего звена и даже среднего там просто интеграторы . Похожая ситуация в Гугле . И вообще - взгляните на статистику -- средний период работы программера в мире на одном месте - 2-3 года . Кому-то удаётся найти работу в похожей области . А когда у меня вышло уже после 2-х лет стажа стать техническим рук. группы клиентской части наш босс начал меня кидать в авральные дни в помощь серверной группы ... Потом кинули на видео , потом на аудио .
Вот и вышел вроде "универсал" - сейчас смешно , бо тогда знал и имел опыт лишь десятую того , что сейчас . Но рынок он такой , когда в CV фигурируют разные языки , OS , базы данных , протоколы связи и GUI (причём нестандартные) , вероятность найти работу с похожим профилем резко снижается , но скорость устройтсва , когда компания разоряется важнее . Ненавижу интервью с идиотами , особенно с кадровиками 25 лет . А универсальность опыта даёт возможность отсеивать те компании , где кадровики (или просто менеджеры) что-то решают , я хожу только туда , где первое интервью оно же и профессиональной . Лучше вообще -- тестовое задание вместо бла-бла-бла .
А до программирования я в двух местах работал инженером-механиком . Причём пришлось быть и конструктором на заводе и проектантом . Конструктор и проектант -- два разных мира и две реальности . Даже в механике . Там трубопроводы , компрессара и насосы , теплобменники и актуаторы . Тут болты , гайки , подшибники разные передачи -- от зубчатых до кулачковых . Потом автокад , автолисп (скрипт под автокад) , Си , С++ и поехало . Крутой вираж . Но первая прога это плагин под автокад , рисующий стандартные детали (потшибники , болты , гайки , сварные конструкции . Потом сделал плагин для отрисовки трубопроводов -- муфты , фланцы , тройники и отводы , краны , вентили и задвижки -- короче фитинги и арматура , но уже трубопроводная ... Эт я ещё и к тому веду , что у как минимум 50% рынка любого производства нет никакого заказчика ... Эт институтский курс по экономике . Mass-production , Serial production не имеет заказчика и только там есть настоящий классический рынок . Заказчики есть токмо у штучного производства и мелко-серийного . Есть ещё переходные продукты , т.е. пишется системы в которые добавляются "технологии" . Каждая тенология реализуется тысячами разных связанных алгоритмов , которые кроме разработчика этой конкретной технологии никому не интересны . Интересны интерфейсы .
Например я работал по тенологиям VMD с ObjectVI (US) , Agent-VI (Isr.) , CVA (GB) . Интерфейсы у них соизмеримые -- алгоритмы совсем разные и их внутренняя кухня . Оне типичные представители Mass Production . Мы интегрировали эту технологию в систему , которая тоже не была заточенна под конкретного какого-то "заказчика" . 50% тендеров выигрывались без единого внедрения , бо требуемые там технологии были уже внедренны для других . Клиентский интерфейс там был с рюшечками - крутейшая графика в стиле офиса . Но ввиду универсальности кода , максимум компромиса с заказчиком - это одно диалоговое окну для одной технологии и не более . Там был средний срок интеграции одной технологии - месяц . За 3 года 40 технологий , список сокращений на целый абзац . RFID , Badge Ctrl , Access control , OCR , Image Processing ,radar control разных штук пять . Управление разными PTZ Camera , инкодеры , декодеры , видео-граберы , системы переметральной защиты критических инфраструктур (эл. забор) , ALPR (это штрафы на дорогах за нарушение ПДД) - видео система . Для австралийцев и Сингапура . Тут я специализировался на серверной части по протоколам связи межды дивайсами или прогами 3-й стороны . Уже через 4 года ближе к 2015 писал системы видеонаблюдения код , токо уже с UI , т.е. клиента : тюрьмы : в Лат. Америке , аэропорты в Передней Азии . Потом опять , хирургия сердца - прога для хирурга . А 2012 год полтора пахал на несчастных скупердяев , решивших зайти в нишу дешовых проектов , для мелкого бизнеса и малобюджетных мерий . 20-50 тысяч баксов весь проект . Т.е. более 2х недель на проект и он нерентабельный . Весь судествующий код на тяп-ляп написан . Одна мерия заказывала статистику освещения по амперам и вольтам , которые меряются примитивным контроллером - там и PLC протокол Modebus , а с другой стороны 3 разных базы данных -- у какого-то заказчика заказ на Oracle , у другого My-SQL - у большинства SQL server . Тысячи файлов уже написанны , одне на Си , другие на Шарпе . Бо замглавного знал только Си , а племянник главного токо Шарп и хотел работать только на базах данных . Ту система включения фонтанов в городе , там учёт коров в стаде (таги на них вешали) , ещё где-то -- система спа и сауны . Температура , влажность .
Были контроллеры скорости ветра . И пришлось даже физику вспоминать , бо некоторые разработчики не утруждали аналоговый сигнал в цифру преобразовывать ...
Моё общение с сотнями работодателей сложившихся и потенциальных со всей очевидностью говорит , шо 99% из них думает как и Вы -- та область , в которой он дока она доминантная на рынке и все лучшие программеры должны знать в первую очередь её .
Мой начальник уже 2018 года 20 лет протрубил в фирме и ничего , кроме баз данных не видел . В его понимании - хороший программер это кто встроенные процедуры быстрее всех пишет и без ошибок . Но сам не заствил себя и разработчиков написать документацию к коду . И таким образом будь ты хоть вундеркиндом и 30 лет стажу , но если ты там год работаешь у тя ноль шансов понравиться боссу , шо разумеется кто 8-15 лет работает он бизнес-логику на память знает . И поля 2 тысяч таблиц и 5 тысяч процедур . Но не дай Бог министерство этот проект прикроет и оне выйдут на рынок труда , который совсем иной . А там 80% мест не требуют знаний баз данных и кодеры токмо SQL никому нахер не нужны .

Я просто всем предлагаю , кто думает шо язык не важно , а важне т.н. "математический склад ума" и всюду возьму . Просто порыться в сети . видео проглядеть про методы и системы отбора кадров . Почитать истории кандидатов . И Вы поймёте , шо специфика "отбора с улицы" такова , шо за 10-15 минут может потенциальный работодатель выносит "вердикт" (внутри ся) . Это обычно . И там не знания важны , потому шо это лишь проекция многолетнего опыта на эти 15 минут . Лгуну и артисту проще , чем суровому логику , шо врать не умеет . Брехать нужно уметь , а не алгоритмы щелкать уметь . А секретарши и компании по hiring там сидят чайники полные . И если написала фирма , шо им нужен дот-нет программер, то всех с C# оне смело в корзину отправляют . А если напишешь MvvM - 10 лет стажа , а забудешь про WPF -- опять корзина . Оно до профессионала даже не дойдёт .
Рынок он совсем другой и алгоритмами соотвествие никто не оценивает . Ну на отдельных интервью дают . И редко кто заранее не зная конкретный алгоритм его за 10-20 напишет .
А один алгоритм я встретил в 35 лет через 23 года после того , как выиграл районную мат олимпиаду по математике в 7-м классе . Вот в 7-м классе я его честно решил , не будучи программистом , не зная , что такое алгоритм и методов его описания Просто на словах описал . Думаю , что мне в 7-м классе просто пофартило . Ну и полтора часа эт не пол часа на интервью и на нервах .
А программирование алгоритмами сейчас считают только сложные куски кода бизнес-логики .
Внутренние и простейшие "алгоритмы" так никто не называет . Кого ипёт , как реализуется в машинном коде оператор ветвления ?! Понятно что в общем виде через джампы , пуши и мувы . Но сегодня даже программеры драйверов не мыслят категориями ассемблера .
Чтобы решать более комплесные задачи нужно мыслить более обобщёнными категориями .
Так вот ещё 2002 году одна банда имени четырёх в которой Эрик Гамма вожак описали 23 шаблона проектирования . Так вот там "алгоритм" эт всего лишь один из шаблонов , а точнее второе названия шаблона "стратегия" . Но он все равно один из 23-х .
И это объясняет почему современное ООП на порядок сложнее , чем набора алгоритмов .
И почему Пайтон не ровня С++ . Хотя бы потому , шо С++ универсален и на ём можно писать систему , драйвера , и огромные приложения . Поэтому 60-70% программистов Си и плюсов знают и понимают , как работает операционка , а половина , может в Kernel шарить и не только винды , но и линукса . Изучение С даёт такие возможности .
А Пайтон и скрипты ни на йоту не приближают возможности понимать работу операционки . Даже может запутать .

Все Ваши посты безумно интересны и дискуссия -- тоже . Путь и только лично мне .
Но нет времени ... Завтра допишу , если будет интерес .
В общем Ваша схема очень красивая и особенно тем , что допускает нестыковки . Но главный просчёт , что Вы идеализируете условного "заказчика" и вообще его как бы обязательное присутсвие в схеме разработки . И недооцениваете разработчиков . Как раз если разработчик не заведомый лгунишко , то сразу скажет "заказчику" что реализуемо , а что нет . Чаще даже выходит с избытком features .
Что вот действительно нереально гарантировать , так это точные сроки . Вот это всегда бывает как горицо "пальцем в ...." . Бо чтобы при любых раскладах гарантировать срок , нужно , как говаривал мой босс (самый мудрый и всех) шо нужно сроки программера умножить на 3 . Но тогда высока вероятность , что будет ну очень рано . Другая беда это экспотенциальный рост количества фитчеров заказчика по мере разработки . И если руководство соглашается постоянно с заказчиком со словами , мол шо тут делать - тебе на пару часов . Обычно с босами на проект никто договоров не подписывает и количество и сложность фитчеров начальных и добавленных по ходу не огововаривает .

Ну я описал базовые принципы. Т.с. абстрактная модель, без учета среды проблематики. Зато она в таком виде применима практически к любой сфере деятельности. Естественно эти принципы могут быть расширены с учетом специфики среды исполнения и индивидуальных требований заказчика. В любом случае это определяется SLA. И я не недооцениваю разработчиков, но зачастую разработчик не до конца понимает проблематику и особенности бизнес процессов, которые необходимо алгоритмизировать. Посему участие постановщика задачи со стороны заказчика как бы не лишне и приветствуется. Кроме того тот же самый постановщик задачи как правило и принимает результат работы. Ну и относительно разработчика-лгунишки. Как правило на лбу у разработчиков не написано каков он. Относительное понимание может дать перечень реализованных им решений и возможность пообщаться с прежними его заказчиками. Но даже это не сильно снижает степень риска заказчика при выборе решения. Потому как в каждом проекте существует так называемая точка невозврата, когда средства, вложенные в проект на столько велики, что заказчик не может от них отказаться в случае возникновения проблем при реализации проекта. Ну и избыток фич также должен соответствовать пожеланиям заказчика. Ибо излишне перегруженный фичами функционал может сказаться на удобстве работы с прикладным софтом. Ну и не всегда на старте заказчик понимает что конкретно он хочет реализовать. Апетит приходит обычно во время еды. Поэтому не удивительно что в ходе реализации и тестирования проекта у заказчика появляются идеи о расширении функционала. Это нормально и обычно это оговаривается. Соглашусь, что со своими босами Вы обычно договор на проект не подписываете и собственно это нормально и объясняется тем, что Вы на них работаете, у вас есть зона ответственности, а у босов есть инструменты Вашей мотивации (в абстрактной форме кнут и пряник ). Однако в случае с заказчиком это обязательный элемент. Ибо именно им и дополнениями к нему определяются, цена, сроки, условия процесса внедрения и процесса сдачи проекта заказчику, этапы внедрения, чекпоинты и контрольные метрики, позволяющие судить в каком процентном отношении реализован заявленный функционал.

А веб дизайн как вручную делать? Тэг за тэгом в текстовом редакторе набирать?
Или надо выучить фреймворк "bootstrap" и на его базе что-то делать?
А как понять фреймворк "bootstrap" без технического склада ума?
Как создать dummy страницу без математических способностей?

Не другое дело, что это должно быть интересно, а именно у человека должен быть склад ума и характера. К примеру есть расхожий анекдот:
"Прораммист когда ложится спать на тумбочку ставит два стакана. Один пустой, другой с водой. С водой на случай если он захочет ночью пить, а пустой на случай если не захочет". Этот коротенький анекдот собственно и определяет суть айтишника. И можно подробнее где айтишнику не нужен технический склад ума и математика (под математикой так же я имею в виду и матлогику, и булеву алгебру, и теорию множеств и математическую статистику). Любопытно было бы узнать. Может я чего пропустил в своей жизни и не тем занимаюсь.
Или Вы сюда причислили торгашей-манагеров которые впаривают ПО потенциальному покупателю? Они тоже безусловно нужны. Но они такие же айтишники как формацевты врачи.

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

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