Здравствуйте, Ikemefula, Вы писали:

V>>Специалист одинаково хорошо думает на любом уровне, бо каждый уровень важен.
V>>А если какой-то уровень не важен — то он лишний в системе, т.е. это ошибка проектирования.
I>Такого не бывает. Никто не работает на любом уровне одинаково. Архитектор лучше понимает свой уровень, и хуже понимает мелкую моторику.

Невозможно.
Иначе это не архитектор, в лучшем случае прикладной постановщик задачи.

Да и нет такой специальности "архитектор", есть такая должность в конкретной конторе.
По образованию ему лучше бы быть системным аналитиком (не важно, в ВУЗ-е профильное или самообразовывался потом).

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

А тебя послушать, так архитектор как программист на Дельфи — если нужного ТКомпонента нет, то задача не имеет решения. ))


I>Разработчик лучше понимает свой уровеь и хуже понимает архитектуру, т.к. он не архитектор, что очевидно.

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


I>Это элементарно — 80% времени разработчик сидит в коде, и только от силы 20 в архитектуре.
I>У архитектора ровно наоборот.
I>Соответсвенно степень владения пропорциональна расходу времени.

Архитекторами не рождаются.
Еще лет 5-10 назад он был одним из лучших программистов среди коллег, хорошо владеющим как своей технологией, так и соседними.

Да и не бросают архитекторы программирование никогда, о чём ты?
Они, наоборот, зачастую сначала сами испытывают чужие или макетируют свои новые технологии (или плотно курируют макетирование оных, если ему придали обезъянок для экспериментов) и только потом "это" может попасть или не попасть в живой проект.


V>>Абстракции любого уровня вкачиваются за несколько занятий всего, бо для абстракций не важно, какого она уровня.
I>Здесь не про вкачивание, а про запоминание. Это разные вещи.

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


V>>Постарайся понять — современное повышение роли сетецентричных приложений (кому как не тебе об этом знать) требует от веб-разработчиков навыков системных инженеров, т.е. междисциплинарных навыков, исследовательских, конструкторских, управленческих, социальных.
I>Индустрия давно пошла по пути разделения труда.

И по пути разделения зарплат, не забыл?

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

Но если кто-то не тянет сию почётную роль, то он не может претендовать и на почётную ЗП, верно?


I>Ясно, что сама разработка требует всего этого. А вот каждому разработчику это не нужно, т.к. есть разработчики постарше, есть архитекторы, и тд.

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

Я же прекрасно помню, что в 98-м году любое приличное приложение на 95% состояло из внутренних библиотек, функциональность которых не связано была напрямую с решаемой задачей, но автомтизировало сотни сугубо технических/вычислительных/отобразительных и т.д. задач.

Сейчас в точности наоборот — объем внутреннего библиотечного кода смехотворен в сравнении с задействованными готовыми третьесторонними или "платформенными" либами (которые с т.з. проекта все-равно третьесторонние, пусть даже являются неотъемлимой частью "платформы"/"технологии")


I>Ровно так же было и в медицине — ктото терапевт, ктото хирург, а ктото медсестра. Что характерно, без медсестер доктор не может работать, от слова вообще, т.е. 99% его времен будет тратиться непойми на что.

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

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


V>>Но ты малость не понимаешь, что именно тебе отвечают — высмеивают не возрастающую роль, высмеивают чудовищный дилетантизм, поселившийся в этой области IT.
I>20 лет назад было ровно то же, когда все объявления были заполнены вакансиями на MS VC MFC. Тогда масштабы были поменьше. То есть, это особенность мейнстрима, а не конкретной технологии — в мейнстриме всегда не хватает квалифицированых специалистов.

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

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

Т.е., к сожалению, Гугл не учёл социального аспекта несвоевременности принятия решения запретить NAPI.
Или наоборот — на это был и расчёт, т.к. Гугл собрал у себя сливки веб-разработчиков (которым не в падлу даже новый язык Дарт придумать, а их корешам придумать WASM), а остальная отрасль оказалась в той ситуации, как описал выше.
Т.е. Гугл сам себе подстроил конкурентное преимущество.

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


I>Собственно оно и понятно — мейнстрим всегда рождает специальности, переход количества в качество.

Я не сомневаюсь, что рано или поздно в вебе тоже будут адекватно оценивать программистов, будут перебирать носом, как и везде.
Потому что сегодня, ввиду аврала и нехватки ресурсов, критерии совсем уж незамысловатые "можете хоть что-нибудь? вы нам подходите!" ))

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

Когда напишут квинтиллион строк кода в вебе, то так просто уже не скажешь: "да фигня, в вебе принято всё выкидывать и писать заново".
В 80-е и в первой половине 90-х тоже было принято в обычном программировании...
А сегодня не принято.
Банально однажды не найдётся столько людей, чтобы "всё переписать".

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

Сегодняшние ангулары, react.js, vue, TS и прочее — это как ассемблер поверх голого железа.
Бедные выразительные ср-ва, катастрофически большая трудоёмкость каждого незамысловатого чиха.
На отладку уходит куча времени, но все-равно уровень багов впереди всей индустрии.

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

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

Думаю, рано или поздно некоторые из них наберут необходимый вес/функционал, чтобы начать считаться полноценной CAD-системой для веб-разработки.
Вернее, за год-другой до этого их купит какая-нить из акул, вложит бабла, причешет, потом выдаст за собственный продукт, как Гугл выдал купленные docs за свои. ))


I>>>Общие тендеции в том, что даже университет на дает внятного уровня владения абстракциями.
V>>Даёт.
I>Нисколько. Математики несмотря на свои абстракции пишут жутко императивный код без какой либо внятной структуры. Простыня на 1мб кода — это оно и есть.

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

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

Здравствуйте, Ikemefula, Вы писали:

V>>Специалист одинаково хорошо думает на любом уровне, бо каждый уровень важен.
V>>А если какой-то уровень не важен — то он лишний в системе, т.е. это ошибка проектирования.
I>Такого не бывает. Никто не работает на любом уровне одинаково. Архитектор лучше понимает свой уровень, и хуже понимает мелкую моторику.

Невозможно.
Иначе это не архитектор, в лучшем случае прикладной постановщик задачи.

Да и нет такой специальности "архитектор", есть такая должность в конкретной конторе.
По образованию ему лучше бы быть системным аналитиком (не важно, в ВУЗ-е профильное или самообразовывался потом).

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

А тебя послушать, так архитектор как программист на Дельфи — если нужного ТКомпонента нет, то задача не имеет решения. ))


I>Разработчик лучше понимает свой уровеь и хуже понимает архитектуру, т.к. он не архитектор, что очевидно.

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


I>Это элементарно — 80% времени разработчик сидит в коде, и только от силы 20 в архитектуре.
I>У архитектора ровно наоборот.
I>Соответсвенно степень владения пропорциональна расходу времени.

Архитекторами не рождаются.
Еще лет 5-10 назад он был одним из лучших программистов среди коллег, хорошо владеющим как своей технологией, так и соседними.

Да и не бросают архитекторы программирование никогда, о чём ты?
Они, наоборот, зачастую сначала сами испытывают чужие или макетируют свои новые технологии (или плотно курируют макетирование оных, если ему придали обезъянок для экспериментов) и только потом "это" может попасть или не попасть в живой проект.


V>>Абстракции любого уровня вкачиваются за несколько занятий всего, бо для абстракций не важно, какого она уровня.
I>Здесь не про вкачивание, а про запоминание. Это разные вещи.

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


V>>Постарайся понять — современное повышение роли сетецентричных приложений (кому как не тебе об этом знать) требует от веб-разработчиков навыков системных инженеров, т.е. междисциплинарных навыков, исследовательских, конструкторских, управленческих, социальных.
I>Индустрия давно пошла по пути разделения труда.

И по пути разделения зарплат, не забыл?

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

Но если кто-то не тянет сию почётную роль, то он не может претендовать и на почётную ЗП, верно?


I>Ясно, что сама разработка требует всего этого. А вот каждому разработчику это не нужно, т.к. есть разработчики постарше, есть архитекторы, и тд.

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

Я же прекрасно помню, что в 98-м году любое приличное приложение на 95% состояло из внутренних библиотек, функциональность которых не была связана напрямую с решаемой задачей, но автомтизировало сотни сугубо технических/вычислительных/отобразительных и т.д. задач.

Сейчас в точности наоборот — объем внутреннего библиотечного кода смехотворен в сравнении с задействованными готовыми третьесторонними или "платформенными" либами (которые с т.з. проекта все-равно третьесторонние, пусть даже являются неотъемлимой частью "платформы"/"технологии")


I>Ровно так же было и в медицине — ктото терапевт, ктото хирург, а ктото медсестра. Что характерно, без медсестер доктор не может работать, от слова вообще, т.е. 99% его времен будет тратиться непойми на что.

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

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


V>>Но ты малость не понимаешь, что именно тебе отвечают — высмеивают не возрастающую роль, высмеивают чудовищный дилетантизм, поселившийся в этой области IT.
I>20 лет назад было ровно то же, когда все объявления были заполнены вакансиями на MS VC MFC. Тогда масштабы были поменьше. То есть, это особенность мейнстрима, а не конкретной технологии — в мейнстриме всегда не хватает квалифицированых специалистов.

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

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

Т.е., к сожалению, Гугл не учёл социального аспекта несвоевременности принятия решения запретить NAPI.
Или наоборот — на это был и расчёт, т.к. Гугл собрал у себя сливки веб-разработчиков (которым не в падлу даже новый язык Дарт придумать, а их корешам придумать WASM), а остальная отрасль оказалась в той ситуации, как описал выше.
Т.е. Гугл сам себе подстроил конкурентное преимущество.

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


I>Собственно оно и понятно — мейнстрим всегда рождает специальности, переход количества в качество.

Я не сомневаюсь, что рано или поздно в вебе тоже будут адекватно оценивать программистов, будут перебирать носом, как и везде.
Потому что сегодня, ввиду аврала и нехватки ресурсов, критерии совсем уж незамысловатые "можете хоть что-нибудь? вы нам подходите!" ))

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

Когда напишут квинтиллион строк кода в вебе, то так просто уже не скажешь: "да фигня, в вебе принято всё выкидывать и писать заново".
В 80-е и в первой половине 90-х тоже было принято в обычном программировании...
А сегодня не принято.
Банально однажды не найдётся столько людей, чтобы "всё переписать".

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

Сегодняшние ангулары, react.js, vue, TS и прочее — это как ассемблер поверх голого железа.
Бедные выразительные ср-ва, катастрофически большая трудоёмкость каждого незамысловатого чиха.
На отладку уходит куча времени, но все-равно уровень багов впереди всей индустрии.

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

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

Думаю, рано или поздно некоторые из них наберут необходимый вес/функционал, чтобы начать считаться полноценной CAD-системой для веб-разработки.
Вернее, за год-другой до этого их купит какая-нить из акул, вложит бабла, причешет, потом выдаст за собственный продукт, как Гугл выдал купленные docs за свои. ))


I>>>Общие тендеции в том, что даже университет на дает внятного уровня владения абстракциями.
V>>Даёт.
I>Нисколько. Математики несмотря на свои абстракции пишут жутко императивный код без какой либо внятной структуры. Простыня на 1мб кода — это оно и есть.

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

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