Evvibris
Evvibris личный блог
23 сентября 2020, 08:33

И снова про ИТ-шников (или "Время - деньги").

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

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

Реальный, а не гипотетический человек обычно стоит перед выбором потратить время на изучение интерпретатора C# (в глубину) или ASP.NET? Изучать методы многопоточности C# (в глубину) или потратить это же время на изучение того как ОС распределяет потоки, или как процессор распределяет задачи по ядрам? Изучать архитектуру процессора или архитектуру программы (паттерны)?
На что нормальный человек потратит время, знание какой технологии принесет ему больше пользы и больше дохода? 

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

ИМХО люди, утверждающие обратное являются пожирателями времени, будьте осторожны с ними и с их идеями. 
17 Комментариев
  • Виктор
    23 сентября 2020, 09:01
    инженеры советской школы:  «могу в уме разложить ряд фурье, но не понимаю зачем». вообще не вижу предмета спора. в реальном мире как раз все еще более иначе. есть задача, можешь решить — велкам. а все эти «патерны», С# в глубину asp и ОС вдоль и поперек — не более чем религиозные мантры для эйчаров и теоретиков.
  • VIKTORRR
    23 сентября 2020, 09:06
    технологические прорывы делают люди обладающие широтой взгляда и багажа накопленных знаний, узкая специализация на это не способна — максимум отшлифовать плод творческого гения других. Обществу нужны и те  и другие, потому что оно в основном состоит из посредственных пользователей(потребителей)

  • Roman Ivanov
    23 сентября 2020, 10:45
    Что есть «интерпретатор C#»?
      • Roman Ivanov
        23 сентября 2020, 11:14
        Evvibris, ну даже если IL интерпретируется (что не верно), но причем тут «интерпретатор C#»???
          • Roman Ivanov
            23 сентября 2020, 11:21
            Evvibris, бред. Компилятор C# переводит (компилирует) сорцы в IL байткод. А дальше IL хоть интерпретируется хоть JITится хоть еще как.
  • Roman Ivanov
    23 сентября 2020, 10:53
    Чтобы просто говнокодить, много знаний не надо. Но когда занимаешься поддержкой работающей системы или когда внедряешь сторонний кривой софт, вот там чем больше знаний и опыта, тем лучше будет результат.
    Бывало, чтобы разработчикам описать суть проблемы, нужно было брать отладчик и ловить/изучать им место падения программы. Иначе бы не пофиксили.
      • Roman Ivanov
        23 сентября 2020, 11:19
        Evvibris, не понял как правила наименования повлияют на качество программы. (Мы же не обсуждаем работу в команде).
          • Roman Ivanov
            23 сентября 2020, 11:32
            Evvibris, нет, не хочу по качеству кода. Меня интересовало как приемы программирования будут влиять качество программы. Без учета особенностей работы в команде.
              • Roman Ivanov
                23 сентября 2020, 11:56
                Evvibris, 1) да, в моем понимании качество программы не связано напрямую с качеством кода. Качество кода важно, но по другим причинам.
                2) полно и обратных примеров, когда берут готовое а потом столько с ним «наедятся» (как правило уже в продакшне), что приходится переписывать. Сделать правильный выбор — исскуство.
                3) когда работал в интеграторе, часто делал небольшие проекты один. Такова специфика задач. Сейчас работаю в Enterprise и там по-разному, но процент сделанного только мной — велик. И уверен, что в среднем количество малых проектов сделанных одним человеком значительно превосходит количество крупных. Если применительно к трейдингу, то тут уж точно много что делается одним человеком.
  • Kapeks
    23 сентября 2020, 12:35
    Не ну это не спор. Слабенько как то. Программистишки даже поссорится как следуют не умеют. Жалкие людишки.

    А что касается триггеров и регистров, кто-то писал, что на последнем курсе их проходили, так я их ещё в школе прошёл, там проходить нечего.

    Знать как, в принципе, устроено железо и софт на всех уровнях, хотя бы и без деталей, нужно просто для общего развития, чтоб железка не была для тебя эльфийским артефактом, который работает при произнесении магического заклинания: «der parol».

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

Активные форумы
Что сейчас обсуждают

Старый дизайн
Старый
дизайн