Сейчас программистам хорошо платят за узкопрофильные задачи, будь это разработка под одну платформу или приложений одного вида. Но отрасли, которые называют самыми перспективными, требуют более глубокого изучения смежных областей, понимания как естественных, так и гуманитарных наук. Я считаю, что широта знаний вновь становится важнее узкой специализации, а скоро в программировании вообще все будет по-другому.«Программистов» лучше называть инженерами
Я в своей работе никогда не пользуюсь словом «программист». Когда я обращаюсь к людям своей профессии, я всегда стараюсь называть их инженерами. Сугубо узкая формулировка «программист» — точно так же, как и «тестер», например, — плохо отражает специфику нашей профессии. И чем дальше, тем хуже эта формулировка работает.
Возьмём такой пример. В классическом понимании есть «программисты», «тестеры», «менеджеры проекта» и другие специализации. С точки зрения ролей это разделение имеет смысл, ведь исторически любое разделение труда возникало из-за того, что средства ведения труда требовали особых знаний. Грубо говоря, чтобы стать тестером, мне надо изучить определённые инструменты — как и инженеру, который разрабатывает под определённую платформу.
По мере того как течёт время, порог входа становится ниже. Например, в Microsoft сейчас нет такой роли, как «тестер» — у них есть developer in test. При этом всех людей, которые занимаются разработкой, называют инженерами программного обеспечения (software engineers), просто они задействованы в немного разных сферах. Сейчас освоить инструменты стало настолько просто, что границы между конкретными специализациями стираются. В будущем вряд ли останется разделение, скажем, на JavaScript-программиста, Python-программиста и .NET-программиста — как и разделение между фронтэндом и бэкэндом.
Правда, пока что остаётся проблема со средствами выражения. На фронтэнде есть JavaScript, а на бэкэнде удобнее выбрать другой язык. Из этой мысли возник весь тренд с Node.js. Благодаря этому упрощаются стандартизация и формирование команды, знание и экспертиза которой будут примерно равны. Да, у Node.js сейчас есть проблемы, но куда важнее, что мы получаем тот же набор инструментов во фронтэнде и бэкэнде.
Знать язык программирования недостаточно
Всё важнее становится понимание технологического стэка — технологий, которые лежат в основе того, что использует человек. Встречаются люди, которые программируют на JavaScript, и на вопрос, как работает протокол TCP, они отвечают, что это слишком низкоуровневое и они не хотят с таким разбираться. Вот это страшно: исходя из моего опыта, понимание базовых принципов, которые лежат под тем, что ты используешь, очень важно. До поры до времени это может не сказываться, но, как правило, зашоренность в одной технологии не позволяет делать нормальные решения по всему технологическому стэку.
Вот пример того, что я имею в виду под технологическим стэком в случае с браузером. Есть JavaScript, есть представление о том, что такое HTML, протокол HTTP. JavaScript-программисту никуда от этого не деться, он должен его понимать — как и то, откуда взялись правила изоляции и кроссдоменной безопасности, как работает протокол SSL, как работает безопасность, основанная на сертификатах. Дальше, если мы идём в бэкэнд, то человек обязательно должен понимать организацию структур данных. В любом более-менее сложном приложении, когда речь заходит о визуальном отображении сложных структур данных, объединении таблиц и организации выборок, интерфейс и бэкэнд становятся непосредственно связаны. Очень сложно сделать эффективное приложение, если люди, которые делают интерфейс, не понимают хотя бы базовых проблем, о которых нужно думать в бэкэнде: шардинг, организация данных, структура запросов. И наоборот: очень сложно сделать правильный API в бэкэнде, правильно предусмотреть возможность шардинга и горизонтального масштабирования, если человек, который пишет бэкэнд, не понимает проблем, которые есть на фронтэнде.
Можно опускаться ниже — и долго говорить о том, что вы не хотите думать, как устроены процессы и потоки в операционной системе. Но, когда вы, например, выбираете, как запустить своё приложение в вебе, тут же возникает вопрос процессов против потоков: нужно понимать, чем они отличаются, плюсы и минусы, как это работает. Люди, которые не понимают этого, в какой-то момент упираются в потолок профессионального роста. Это происходит часто: людей, которые думают широко, системно и изучают новые области, всегда было мало. Можно всё время делать сайты одного и того же уровня, не задумываясь о сложных вещах, но сделать сайт с большим количеством клиентов и динамическим контентом — это принципиально другое. Часто этот шаг невозможно сделать, не построив у себя в голове фундамента базовых знаний.
Грань между дизайнерами и инженерами останется
В будущем Заготовки, созданные дизайнерами, начнут быстрее превращаться в программы. Это уже во многом случилось в программировании под настольные платформы, где есть набор готовых элементов с визуальным редактированием. Что касается программистской части, то она, безусловно, останется, хотя и будет использоваться реже и, скорее всего, станет более высокоуровневой — но простой однотипной работой будут заниматься не люди, а инструменты.
Сейчас, если я хочу сделать хороший сайт, то, наверное, имеет смысл нанять JavaScript-программиста. С другой стороны, я могу пойти на Wix или другой билдер и сделать там сайт, близкий к тому, что мне нужно. Мне кажется, что этот тренд продолжится. Возможность сделать свой сайт с неплохим динамическим контентом, просто подвигав ползунки и покидав кнопочки, появится у любого человека. Необходимость в людях, которые будут писать такие сайты, сама по себе отомрёт. Скорее всего, JavaScript-программисты не исчезнут — кому-то ведь нужно будет создавать высокоуровневые средства визуального моделирования. Но от специалистов потребуются более глубокие знания.
На уровень выше можно выходить бесконечно. Когда-то были средства низкоуровневого программирования: люди писали в байткодах, и их это не очень беспокоило. Потом появились средства того же ассемблера, следом за ними — средства уровнем выше. Если фантазировать, через 50—100 лет всё можно будет автоматизировать и дойти до полуискусственного интеллекта — вопрос во времени и сложности следующего технологического витка. Если посмотреть на историю разработки, то на каждом новом технологическом витке увеличиваются суммарный объём и широта знаний, которые нужно держать в голове, — хотя и доступ к ним упрощается. То, что можно просто взять и изучить JavaScript — это иллюзия. Реально нужно знать JavaScript и всё, что под ним. Переходя на следующий виток, нужно иметь хотя бы основные представления о том, что было до этого.
Инженерам нужны и естественные, и гуманитарные науки
Чем дальше, тем более сторонними оказываются затрагиваемые сферы. Возьмите хотя бы развитие компании Apple, которое во многом было продиктовано увлечением Стива Джобса и людей, которые его окружали, гуманитарными науками: в частности, маниакальной любовью к красивым шрифтам и иероглифам. Все запоминающиеся изменения в информационных технологиях очень часто происходят на стыке наук. Это почти всегда синтез, потому что IT — просто способ представления и обработки информации, который лишается смысла в вакууме. Так, сложно назвать «программистами» людей, которые придумали графический пользовательский интерфейс, — это как сказать, что iPhone стал успешен благодаря только «железу» или только «софту».
Ещё 10 лет назад фронтэнд-разработчику казалась бы дикой мысль о том, что нужно прочитать книги о восприятии и психологии людей. Сейчас это уже само собой разумеющееся: если человек разрабатывает сайты, то он прочитал все возможные книги по UX, UI, тому, какой объём информации люди способны воспринимать, как её лучше подавать. И это ведь смежная технология, пришедшая к нам чуть ли не из медицины — и то же самое будет касаться физики, химии и биологии.
Сегодня много говорят о квантовых компьютерах, но мало кто понимает, что это такое. Когда удастся создать первый действующий квантовый компьютер, готовый к запуску в массы, это радикально поменяет весь технологический стэк. При этом выбрасывать всё не придётся. Люди будут искать средства совместимости: условно, как Parallels Desktop решает задачу совместимости между Windows и Mac, но в гораздо большем объёме.
Рассматривают и возможность построить биологические вычислительные машины. Когда это получится, они радикальным образом поменяют не только вычислительные технологии, но и устройство медицины и всего общества. Сейчас массовая медицина отслеживает здоровье людей всего по нескольким показателям: грубо говоря, это пульс, давление, биохимический анализ крови. А что, если создадут устройство, которое будет «жить» в организме человека и выдавать все эти данные в реальном времени по каждому человеку на Земле? Представьте последствия, которые это повлечёт за собой: продолжительность жизни увеличится не на жалкие проценты, а на очень заметные цифры.
Я предполагаю, что поэтапный рост пойдёт и вширь. Чтобы создавать новые средства разработки и новые платформы, потребуются знания не только в IT. Тот же Илон Маск создаёт эффективные способы транспортировки и консервации энергии. Всё это предполагает очень широкий набор технологий и знаний. Если удастся сделать батарейку, которая будет помещаться в некое маленькое устройство, и её не нужно будет перезаряжать хотя бы год, то это будет безумная точка роста, которая вызовет следующую технологическую волну. В каждой сфере есть пограничные районы, где неминуемо появится такая точка роста — вопрос только, когда и кому это удастся. Есть и те, кто во время очередного перехода остаются в прошлом: они не вымирают, но там уже нет такого роста, денег и чего-то интересного.
Получайте базовые знания, которые не устаревают
Что бы вы ни начинали учить сейчас, через 5–10 лет оно устареет. А потому, как бы глупо это ни звучало, нужно учиться учиться. Если есть запас времени, лучше посвятить его тому, как работает то, чем вы собираетесь пользоваться, — начиная от курса физики и математики. Без базовых знаний пресловутым умением учиться сложно воспользоваться. Фазовый переход на следующий уровень всегда намного проще для людей, которые понимают, как работают компьютеры на физическом уровне, — пускай они даже этим не пользуются и работают на гораздо более высокоуровневых языках. Они не просто пользуются автомобилем и включают передачи, а понимают, как автомобиль работает. Когда эта штука становится чем-то вроде электромобиля, им сделать этот переход намного проще.
Если мы ставим на стратегию долгосрочного развития и роста, то важнее не прикладные, а фундаментальные знания. Не банальное представление, как послать GET-запрос, а понимание HTTP-протокола: почему он был так сделан, какие идеи в него были заложены. Когда мы перейдём на условный SPDY (Разработанный Google протокол, предлагаемый как замена частей HTTP. — Прим. ред.), вы сможете понять, как произошло это изменение. Нужно общее понимание того, когда эти запросы посланы на сервер, как работает процессор, который делает эти вычисления на сервере. Слишком углубляться во всё не надо, но для широты знаний нужно понимать, как это всё работает.
Источник: моя колонка на портале LookAtMe
Комментарии (45)
maisvendoo
23.07.2015 18:45+2С. М. Тарг на КДПВ — это из моей библиотеки.
Инженерам нужны и естественные, и гуманитарные науки
Но не за счет сокращения программ технических дисциплин
tacit_one Автор
23.07.2015 20:13+2Согласен. Хотя речь в первую очередь не про вузовское образованию. БольшАя часть того, что рассказывали в вузе ещё лет 5-10 назад уже и не имеет смысла преподавать. Вопрос в том, как мы продолжаем развиваться после вуза. И здесь очень важно 1) никогда не останавливаться 2) обеспечивать широту покрытия знаний 3) каждодневно получать удовольствие от процесса. ;-)
SirEdvin
23.07.2015 18:55+2На фронтэнде есть только JavaScript
Это немного равносильно тому, что сказать: «На бекенде есть только ассемблер».
Да, в итоге все приходит в JavaScript, но есть куча вещей, которые скрывают его от нас (GWT, ASP.NET, ...), есть куча других языков, которые потом собираются в JavaScript без существенных потерь в скорости.
Есть куча языков, для которые существует возможность запуска в браузере через JavaScript, например, Javatacit_one Автор
23.07.2015 20:16+2Слово «только» закралось как-то ненароком. Убрал от греха. Посыпаю голову пеплом и вообще. :-)
NickKolok
25.07.2015 01:06К слову: а можно ли интерпретировать в браузере классические C++? Слышал про asm.js, но как-то не понял, что там и к чему. И возможно ли использовать внешние, js-ные функии?
deniskreshikhin
23.07.2015 19:31+16Не надо называть программистов инженерами, программирование это отдельная дисциплина.
Ларри Уолл по образованию лингвист, занимался исследованиями Библии и заодно придумал язык Perl.
Джон Маккарти математик и исследовал проблемы искусственного интеллекта, в итоге придумал LISP.
Алан Кей занимался молекулярной биологией и подрабатывал джаз-музыкантом, но потом придумал SmallTalk и ООП.
Ричард Столлман начинал тоже с биологии, потом получил бакалавра по физике, проучился год в MIT и забросил образование, перключившись на работу исключительно программистом.
В конец-концов, Ада Байрон не была инженером)) И она не представляла до конца как работает то на чём она программировала, но она первая написала прикладную программу для нахождения чисел Бернулли.
Всё что объединяет этих людей это любовь к программированию.
Так что программирование это самодостаточная дисциплина. То что сейчас программистам приходится идти учится на инженерные специальности это огромная ошибка.
yusman
23.07.2015 19:49+8Не согласен, сам работал инженером после Универа и побывал в двух ипостасиях. Как был постоянный поиск компромиссов, так он и остался. Как было конструирование системы из более простых систем — так и осталось. По сути современный «высокоуровневый» программер — инженер-конструктор.
Ты можешь писать стихи, рисовать картины, но в душе быть инженером. Одно другому не мешаетdeniskreshikhin
23.07.2015 20:06+5Конечно не мешает, например, советский композитор Александр Зацепин был радиолюбителем и сам паял, собирал звуковое оборудование.
Но ценен он как композитор, а не как инженер.
Так и с программистами. Да, программист может быть инженером, или его работа может требовать быть инженером. Но может и не быть.
И от этого его ценность не уменьшается ни сколечки. Можно быть программистом одного языка и вообще забить на низкоуровневое программирование, и всё равно это будет программирование. Например, многие либы для javascript написаны на самом javascript и решают проблемы javascript с помощью абстракций javascript. И при этом имеют сотни тысяч скачиваний.
Программирование само по себе ставит очень серьёзные задачи — чистота кода, управление поведением сущностей, развитие абстракций, проблемы семантики и синтаксиса. И это совершенно не инженерные проблемы.Rumlin
23.07.2015 22:18Зависит от языка программирования, если будущее будет как описывает автор, то «чистота кода, управление поведением сущностей, развитие абстракций, проблемы семантики и синтаксиса» — это будет заботой искусственного интеллекта, а человек будет взаимодействовать с какой-то вариацией визуального алгоритмического языка программирования и моделирования (например).
deniskreshikhin
23.07.2015 23:19+6А это не зависит от искусственного интеллекта. Будущее больше зависит от того верен ли тезис Тюринга-Чёрча?
Если верен, то никакие искусственные интеллекты качественно ничего не изменят. Т.к. всякая задача в итоге будет сводиться к написанию программы, вне зависимости от предметной области.
В 50-е программисты оперировали регистрами, в 60-е массивами, потом стали создавать структуры данных, теперь передают объекты и замыкания. Но принцип записи программ совершенно не изменился.
Вот если будут открыты какие-то физические процессы, которые будут производить не-тюринговые вычисления, тогда да. Возможно потребуются какие-то другие сущности. Но скорее всего это будет уже за гранью современной цивилизации.
Другими словами, пока человечество будет писать алгоритмы для машин Тюринга, человечество будет использовать и языки программирования. Может изменятся грамматики, синтаксис, семантика. Но это всё равно будут языки, и принципиального отличия не будет.
Вообще это вопрос довольно серьёзный, касается не только программирования, но и вообще основны основ.
Поэтому я хотел бы привести тут отрывок из воспоминании математика Романа Михайлова о математике Гильберте Баумслаге, они оба занимались гомотопической теорией групп:
На группу можно смотреть по-разному, у каждого свой взгляд. После ГТГ на группу смотрят как на метрическое пространство. А для многих «группа» сразу понимается с дополнительной структурой, или вместе с пространством, на котором она действует. Для меня же было неслыханной радостью встреча с человеком, который, так же как и я, смотрит на группу как на текст, который читает группу как рассказ, беседует с группой на языке абстрактных алфавитов. Это очень несовременно, даже уже маргинально. Красивые аномалии текста — это радовало его. Гильберт видел текст очень глубоко, детально. Не представляю, кому еще могу написать письмо с каким-нибудь странным копредставлением и получить через полчаса ответ типа «очень интересное копредставление, группа хитра, сегодня изучу, завтра тебе отвечу». Мы работаем с текстом в основании которого лежит умная природа = топология. Пространство звучит через текст, и мы изучаем этот текст, читаем его.
В общем, не стоит недооценивать возможности текста. Так что если искусственный интеллект будет создан, он так же будет управляться программами и существовать по законам которые будут описываться программами.Rumlin
23.07.2015 23:41Будут языки, будут «переводчики» с человеческого на машинный, вопрос в том, что много рутинных не творческих вещей следует максимально передать машинам, которые лучше всего делают однотипные задачи с известным решением.
RouR
24.07.2015 01:16+4Не согласен, сам работал инженером после Универа и побывал в двух ипостасиях. Как был постоянный поиск компромиссов, так он и остался. Как было конструирование системы из более простых систем — так и осталось. По сути современный «высокоуровневый» программер — инженер-конструктор.
А я согласен с тем что не надо называть программистов инженерами, программирование это отдельная дисциплина. Я тоже побывал в двух ипостасях. И разница больше в мышлении. Инженер-программист предпочитает использовать готовые блоки и инструменты. «Настоящему» программисту всё неймётся написать свой велосипед. На собеседовании тоже можно заметить разницу. У инженеров больше знание предметной области (инженер всегда в какой-то области, а не вообще) и опыт работы с инструментарием, у программистов знание внутрянки самих инструментов-фреймворков-спецификацй и алгоритмов.
В нашем безумном мире поисков нематериальной мотивации, часто название должности не отражает её изначальной сущности — курьер, который «менеджер по логистике», «менеджер по продажам» который продавец, вот и майкрософт вместо тестировщика перешёл к «developer in test». Вакансию ведь надо закрывать, бюджет ограничен, а на «красивую» должность больше шансов поймать соискателя и больше шансов согласовать с руководством смену обёртки, чем смену бюджета. Конечно оно не везде так, но я веду к тому что есть элемент хаоса и неадекватности должностей. Так давайте хотя бы в сфере образования оставим разделение на инженеров и программистов.
zo_oz
23.07.2015 19:38+10Написано очень узко, только относительно веба и фронтэнд разработчика. (достаточно проследить хотя бы именование абзацев)
«Программистов» лучше называть инженерами
Всю жизнь всегда называли software engineers, а не только сейчас, как вы пишете.
Знать язык программирования недостаточно
Абзац не соответствует названию, тут вы пишете, что знание языка программирования — не главное, дескать тру программист всегда сможет легко обучиться другому языку, ведь взаимодействие со стеком технологий ниже остается одинаковым на логическом уровне. Ну давайте возьмем человека без опыта в функциональных языках и посмотрим как он будет строить экспертные системы на прологе сходу.
Грань между дизайнерами и инженерами останется
Ну что за бред? это всё только про веб, а помимо веба ведь кто-то пишет этот стек технологий, который вы так усердно советуете изучать, но почему-то не упоминаете, что его еще надо и писать. Ну и что дизайнеро-программист захотфиксит в коде СУБД? Ну или другой пример — я пишу графический движок, я отлично знаю все алгоритмы компьютерной графики, параллеливание на GPU, все матрицы преобразования и тд — это значит, что я могу смоделировать модель автомобиля для своей игры? смогу, если при этом я еще и крутой дизайнер, но вряд ли моя модель будет крутой тогда. (ну да, есть исключения, но все понимают, что дизайнер, рисующий постоянно, сделает это гораздо лучше человека, который рисует раз в месяц)
Очевидно что информация постоянно устаревает, очевидно что надо постоянно учиться, капитализм вообще не терпит зоны комфорта, очевидно, что надо знать на базовом уровне широкий спектр областей, однако при этом, на мой взгляд, гораздо важнее узконаправленно упираться в одну область и быть в ней экспертом, чем быть недодизайнером-недопрограммистом.SirEdvin
23.07.2015 21:58посмотрим как он будет строить экспертные системы на прологе сходу
Если он понимает основы математической логики, то достаточно легко.
Все-таки, Пролог — язык логического программирования.
Mixim333
23.07.2015 19:45+2>Если фантазировать, через 50—100 лет всё можно будет автоматизировать и дойти до полуискусственного интеллекта — вопрос во времени и сложности следующего технологического витка
Советую прочитать книгу Гласса — «Программирование и конфликты 2.0» — там он рассказывает, что в 80е были примерно такие же мысли, считали, что вот-вот и программы начнут «реализовываться сами собой»…
А вообще, лично мне очень интересны не только технические науки, но и искусство — живопись, скульптура.
mbait
23.07.2015 20:44+18Немного подташнивает от инженеров, если честно. Когда я учился, то программирование было обычным делом, как и множество других профессий. И вдруг все набежали: инженеры, тимлиды, сеньоры-помидоры, собеседователи 80-го уровня со своими задачками, стартаперы… И мы пришли к тому, что сейчас имеем. А ЧСВ всех, кто что-то там пишет на клавиатуре, переполнило счётчик два раза.
В моём понимании инженеры строят дома. Или коммуникации. И этим потом ещё пользуются много десятков лет. И инженеры ещё отвечают за свою работу. Все смеются над Коболом, а программы, написанные на нём «до революции», продолжают работать. А теперь преимущественно какое-то гавно пишут, попутно что-то бормоча про сингулярность, устаревание, хайлоад и бигдата. И дабы не кормить троллей — пример с Коболом утрирован.
Antelle
23.07.2015 23:09Мечты, мечты…
Пока один человек сможет вот так сесть и сделать целую систему, от UX до хранилища, в одиночку, т.е. заменить целую команду машиной, оставив пару гениев с широким кругозором для управления ей — ещё не один десяток лет пройдёт.
BalinTomsk
24.07.2015 02:08----Когда я обращаюсь к людям своей профессии, я всегда стараюсь называть их инженерами
есть software developer и есть software engeneer.
Nubus
24.07.2015 02:59А можете предметно, на пальцах, обьяснить разницу между этими понятиями, пожалуйста?
Ununtrium
24.07.2015 12:07Нету этой разницы. Кодеры, инженеры, программисты — кто как хочет, так и называет. Остальное субъективно, например кодерами обычно называют низкоквалифицированных или неопытных программистов (тех, которые пишут код, не обременяя себя дизайном — «машинистки», вообщем).
POPSuL
24.07.2015 16:38Инженер это тот человек, который полностью понимает что за проект находится перед ним, он продумывает архитектуру проекта, как все в нем должно работать, взаимодействовать. А девелопер это тот, кто реализует то, что выдумал инженер.
Не скажу что часто, но иногда инженер набрасывает рабочий прототип того, чего надумал, а девелоперы уже допиливают все части этого прототипа. Ну а хороший инженер — пилит некоторые части вместе с девелоперами, поясняя почему именно так, а не иначе.
BalinTomsk
24.07.2015 18:06-2Программирование сейчас изучают и в школах и в ПТУ и на курсах по программираванию.
Это и есть уровень software developer — или по-русски кодер. Основное предназночение — закодировать предложенные алгоритм, выданный аналистом.
Человек окончивший computer science и имеюший степень M.Sc. in Applied Computing или PhD, способный модифицировать сушествуюших компьютерные алгоритмы под конкретную задажу — software engineer.
Поэтому компании, входяшие в десятку лучших, при наборе тестируют знания в computer science. Они довольно просты, поэтому уже на конечных этапах проверяют способность кандидата модифицировать стандартные алгоритмы к текушей задаче.
Подавляюшее число software developers не проходят даже первый этап.
И конечно software engineer использует инженерные подходы к проектированию софта, знает методологию и принципы разработки в создании програмных продуктов — это наука и человек просто умеюший переводить словесное описание в код, как правило далек от всего этого.
iviv
24.07.2015 17:04+4Кажется, что никто не замечает простой вещи, говоря о постоянном повышении уровня абстракции. А именно того, что это повышение не является бесконечным и заканчивается общедоступным сервисом. Где о программировании уже говорить не приходится.
К примеру, сайты-визитки вначале пилились индивидуально вручную, затем появились шаблоны, затем конструкторы, а сейчас это страничка в Фейсбуке, которую может создать и обслуживать любой человек.
Тенденция понятна: от высокой стоимости и низкой эффективности система эволюционирует к низкой стоимости и высокой эффективности. В итоге из области компетенции профессионалов задачи уходят к непрофессионалам, а повышение уровня абстракции больше не требуется.tacit_one Автор
24.07.2015 23:24+2Ой как жаль у меня тут нет кармы, чтобы Ваш комментарий плюсануть… Собственно, всё интерсвью в конечном итоге и крутится вокруг этой мысли. Только она, видимо, оказалась смазанной.
Только всё ведь не останавливается одним каким-то рынком/бизнесом. И когда в какой-то сфере система приближается к оптимуму, как правило зона роста через некоторое время переходит в другую (часто смежную) область.
Грубо говоря, как бы банально всё не звучало, процесс всегда волнообразный. И да, к концу каждой волны система приближается к оптимуму. А потом переходит в новую систему координат.
evocatus
25.07.2015 00:38Насчёт квантового компьютера. Хватит уже приплетать его не к месту. Даже теоретически он не сможет заменить существующие компьютеры, потому что работает по другим принципам, по другой логике. Это будет максимум сопроцессор для специализированных задач типа шифрования.
tacit_one Автор
25.07.2015 00:46-1Оборудование и алгоритмы работы с кубитами имеют все шансы оказать не меньшее влеяние на индустрию, чем то же пресловутое оборудование и теория работы с полигонами и матрицами в видео-картах. А скорее всего и гораздо большее. Видео-карты тоже сначала воспринимались как «сопроцессор для специализироавнных задач». А сейчас уже не всегда очевидно, кто из них имеет больше влеяния в системе.
FreeMind2000
25.07.2015 01:19Зачем противопоставлять инженер vs программист?
У нас например, на работе есть такая должность: Инженер-программист. И все довольны :)
michael_vostrikov
25.07.2015 08:19+2В будущем вряд ли останется разделение, скажем, на JavaScript-программиста, Python-программиста и .NET-программиста — как и разделение между фронтэндом и бэкэндом.
Ну разве что javascript, python и .net вытеснятся одним универсальным супер-языком. Разделение на фронтенд и бэкенд разработку применительно к веб появилось не так давно, и пока они только отдаляются друг от друга. По крайней мере, лет 8-10 назад вакансию «фронтенд-разработчик» мало где можно было встретить. Даже если писать бэкенд на node.js, все равно там другие задачи, и поэтому другая специализация.
Встречаются люди, которые программируют на JavaScript, и на вопрос, как работает протокол TCP, они отвечают, что это слишком низкоуровневое и они не хотят с таким разбираться. Вот это страшно: исходя из моего опыта, понимание базовых принципов, которые лежат под тем, что ты используешь, очень важно.
Зачем останавливаться на 4 уровне OSI, и почему именно на нем? Давайте будем напрямую из браузера с сетевой картой работать. Уровни абстракции для того и нужны, чтобы не вдаваться в детали реализации. Все знать невозможно, и даже общее представление обо всем иметь невозможно.
Но, когда вы, например, выбираете, как запустить своё приложение в вебе, тут же возникает вопрос процессов против потоков
За несколько лет веб-программирования у меня ни разу не возник такой вопрос. Либо это был хостинг, либо настройкой занимались другие (более опытные) люди. Да, чтобы достичь уровня и зарплаты этих других людей, это надо знать, но для веб-программирования как такового это не нужно. И уж тем более это не свидетельствует о конце эры айтишников.
Возможность сделать свой сайт с неплохим динамическим контентом, просто подвигав ползунки и покидав кнопочки, появится у любого человека.
Несмотря на наличие кучи генераторов сайтов или wordpress/joomla, программирование пока никуда не делось. И не денется. Потому что, чем сложнее система, тем больше потребуется таких ползунков и кнопочек для ее представления. Настолько много, что это будет аналог языка программирования.
Если есть запас времени, лучше посвятить его тому, как работает то, чем вы собираетесь пользоваться, — начиная от курса физики и математики.
Как может помочь в изучении SPDY знание умножения матриц? А знание процессов, происходящих в атоме? Такие общие фразы в целом правильные, но они не дают ответ на основной вопрос — как найти границу, стоит ли изучать дальше, или уже можно начать изучать что-то другое.
Они не просто пользуются автомобилем и включают передачи, а понимают, как автомобиль работает. Когда эта штука становится чем-то вроде электромобиля, им сделать этот переход намного проще.
Вообще-то, абстрактной девочке-блондинке, которая умеет переключать передачи, но не понимает, как работает автомобиль, будет проще. Единственное отличие, которое она заметит — это что больше не надо ездить на заправку, а надо воткнуть провод из машины в розетку в гараже.
Вообще, мне кажется, главное — это не знания, и даже не умение учиться. Главное — это умение разбираться. Умение строить предположения и проверять их. Недостаточно просто прочитать документацию к новому фреймворку, сделать несколько примеров и запомнить основные возможности. Надо проанализировать информацию, определить взаимосвязи, подумать, как это может быть реализовано внутри, и на что такая реализация может повлиять.
man4j
27.07.2015 00:09+6Давно такой херни не читал. Вот зачем JS-программисту знать про, скажем, TCP/IP? Пусть лучше качественно делает свою работу. Ну а если у него возникнут проблемы при программировании веб-сокетов, ну ничего страшного, я ему помогу, разберемся вместе. Тоже самое и во всем остальном. Короче, уважаемый автор, чаще общайтесь с людьми, меньше раскладывайте пасьянс.
varnav
27.07.2015 11:51+1У меня гуманитарное образование, хотя я всю жизнь проработал в ИТ. Однако этот факт приводит к тому, что моё резюме часто отправляется прямиком в корзину. Хотя как мне при администрировании Active Directory могут помочь сопромат и диффуры — не понятно.
Toshiro
27.07.2015 23:51+2Давно мне не приходилось читать настолько феерического бреда.
Судя по тому, что я прочитал, и по заголовку, автор в жизни никогда не пользовался на компе чем-то сложнее браузера и ворда. Он совершенно не в теме того, что происходит в IT-отрасли последние 20 лет. И он не представляет, что означает быть программистом.
Настрочил пару страниц тупой херни, не приходя в сознание и непонятно на что надеялся. Уберите это позорище на гиктаймс, специально же его сделали, чтобы хабр оставался именно техническим ресурсом.
ekapinos
28.07.2015 22:54Во-первых — спасибо!
Мне Ваша статья очень понравилась. Я анализировал её в разрезе миграций айтишников в «другие» страны. Пока окно открыто. Вопрос, что будет дальше, остается открытым. Чему учить детей и что сделать чтобы оставаться востребованным? Это серьезная тема. Думаю что учиться нам до пенсии. Это четко и жестко сказал мой преподаватель в ВУЗе еще 10 лет назад:Вы обречены учиться — Доценко С.В.
Так же должен согласиться — «чистый» программист — вымирающий вид. Без понимания предметной области перспектив нет.
ИМХО: веб будет заполнен «автогенерилками» по типу wordpress и т.п. Для бизнеса в 80% случаев это достаточно. Опять вопрос в какую предметную область уходить. Мне кажется каждому поколению своя ниша. Но все же надеюсь мы, ай-тишники, найдем ответ по-лучше.
P.S. Без «хэйтеров» тут не обойтись. Не обращайте на них внимания, по инвайтам видать пет.хи прошли.Toshiro
29.07.2015 03:59+1Откудаж вы беретесь, несчастные апостолы 90-ых? «Чистому программисту», как вы их называете, необходимо каждый божий день эволюционировать, чтобы его навыки котировались на рынке, мир никого ждать не будет. Каждый день приносит в IT что-то новое. Новые структуры данных, алгоритмы, языки, фреймворки, технологии, паттерны. Тысячи новых явлений возникают и тысячи становятся неактуальны и умирают. И это без учета железа и связи. И тебе нужно не только обо всем этом прочитать, и разобраться что это и как им пользоваться. Но и применить на практике, в разных вариантах. Осознать и проникнуться.
Когда ты осознаешь, будучи веб-программистом, что на бэкенд и фронтенд тебя уже не хватает физически — ты резко ограничиваешь себя, определяешься с конкретным направлением и начинаешь точить именно его. Спустя время ты понимаешь, что даже органичившись только бэкендом, ты все-равно должен выбирать — уровень приложения или уровень БД, на все тебя опять же не хватит. Это может продолжаться бесконечно, поскольку все эти ответвления постоянно развиваются и усложняются. Таков путь узкого специалиста, и чем дальше ты по нему зайдешь, тем быстрее работа начнет искать тебя, а не ты работу. Для прогеров-системщиков то же самое с поправкой на ветер.
Безусловно, можно учить «все по чуть-чуть». Ты будешь примерно представлять себе всю кухню, но ни в чем из этого ты не будешь даже средненьким спецом. Таков обычно путь менеджера, в какой-то момент собственно разработка заканчивается и начинается руководство отделом — бэктреккеры, VCS, базы знаний, методологии управления, планирование, управление рисками, ресурсами и временем. А еще собственно управление людьми, координация, подбор персонала, оснащение. Не дай бог еще разруливание конфликтов — искать время на инфу по психологии или тренинги ты точно не хочешь, но в крупной корпорации без этого вообще никак. В малом бизнесе «мы банда» пока еще прокатывает. Учить там для хорошей квалификации не меньшие тонны инфы, чем в разработке. И это все тоже постоянно развивается. И да, разумеется тебе постоянно будут полоскать башку политикой! +)))
Еще бывает путь аналитика. Data mining, классификация, кластеризация, онтологии, экспертные системы, предпроеткное обследование объектов. Хорошо если аналитик умеет писать техническую документацию… иначе вам нужен еще и отдельный тех-пис)) Да к слову, чтобы все это работало безотказно нужны тестировщики, у которых свои тонны материала. Проектируют все это добро системные архитекторы и просто чтобы выучить, и осознать что такое IDEF, ARIS, UML, паттерны проектирования нужна чертова тонна времени.
Давайте еще добавим к этому «знание предметной области», в которой все так же не стоит на месте — и шаблон среднестатистического персонажа попадает в полную сансару разрывов)) У него итак тотальный кризис гештальта из-за стресса, ибо как бы быстро он не учил новый материал — он не успевает. А если еще и предметную область добавить, то каким бы специалистом человек ни был, он начнет жоско косячить не приходя в сознание.. И не забывайте, что каждый отдельный специалист несет вполне ощутимую ответственность за свою часть работы — и это еще одна причина, почему он хочет быть в этой части максимально хорош.
Для того, чтобы уберечь сотрудников от шизофрении кто-то однажды придумал, что в разработке чего-либо должен участвовать не только IT-персонал, но и консультанты — которые как раз знают предметную область.
И ситуация на рынке сейчас именно такая, что среди представителей старшего поколения консультантов-предметников выше крыши, и они знают свое дело мастерски. А вот среди IT-молодняка специалистов нужного уровня приходится искать месяцами. Вы видимо не представляете как мало людей могут за 2 часа на Python/Django выполнить тестовое задание, заключающееся в банальной выборке записей из Postgres для построения хлебных крошек текущего объекта. Хорошо если кто-то из них просто знает, что есть стандартные структуры данных и алгоритмы работы с деревьями и иерархиями, или что есть такая аббревиатура MPTT (Modified Preorder Tree Traversal), или что для многих задач с деревьями допускается денормализация БД, или что в том же Postgres с недавних пор можно WITH RECURSIVE… SELECT…
Если в современном университете преподаватель что-то из этого знает (по стране в среднем, без учета топовых ВУЗов коих по-пальцам пересчитать) это сопоставимо с высадкой инопланетян на красной площади. Я закончил универ в 2009 и обучали нас тому, что уже лет 30-40 нафиг никому не нужно. В аспирантуре ситуация не менее плачевная — там кстати очень жоско ощущается как специалист в предметной области ни черта не может сделать, ибо внезапно оказалось, что программирование не освоить за 3 недели с наскока.
Спецов-предметников полным-полно. Узких специалистов, из которых можно собрать команду, которая сделает то, что нужно заказчику в упряжке с предметниками — очень мало. Грамотных руководителей, которые могут сделать это все реальным — просто единицы.
Так что у «Эры айтишников» не то что не конец… это даже еще толком не начало. Эра началась, а вот айтишники пока еще не выросли и не осознали.
P.S: А все авто-конструкторы типа WordPress, Drupal, Joomla. modX, Yii, Bitrix, Sharepoint и т.д. — годятся лишь для определенного круга задач. Они сформировали рынок сайтов-визиток, магазинов, корпоративных порталов, но это все очень мелкие задачи. Однако даже они регулярно вызывают дьявола проблемы, и бесконечное тестирование, оптимизацию, провоцируют изобретение новых инструментов, развитие железа и фундаментальной математики. Одна только эпопея с маленькими и простыми Class-Based Generic Views в Django длится без малого 11 лет. И сломала мозги не одному десятку высоко квалифицированных Python-разработчиков.
P.P.S: И мы сейчас говорим о приземленном. Не о системах управления войсками, орбитальными группировками или АЭС. Не о прошивках самолетов, боевых дронов, кораблей или космических аппаратов. Не о системах сопровождения экспериментов на коллайдерах, в естественнонаучных или медицинских лабораториях. Даже не о информационно-поисковых системах. Мы говорим о банальной тупой херне!Rumlin
02.08.2015 16:11Так что у «Эры айтишников» не то что не конец… это даже еще толком не начало. Эра началась, а вот айтишники пока еще не выросли и не осознали.
Каждое новое поколение специалистов считает, что до них ничего не было и никто ничего не делал. Пару лет назад довелось мне полистать советский ежегодник «Наука и человечество» 1970 года. Задержался взгляд на статье о проблемах разработки ПО для ЭВМ — с тех пор ничего не изменилось, только машины стали маленькими и быстрыми, а так читал статью практически пригодную для публикации и сейчас.Toshiro
02.08.2015 17:16+2Каждое новое поколение считает так вполне обосновано, т.к. у каждого поколения — свои вызовы. Это естественно в прогрессирующей цивилизации, которая развивается и движет свою науку и технику вперед. Ведь основа этого прогресса в том, чтобы обучить следующее поколение за 10 лет тому, на изучение и развитие чего ты лично потратил лет 50. Чтобы у них был запас времени двигать это дальше.
Многое из того, что было придумано старыми академиками серьезно опережало время. Например если почитать статьи Ю. А. Шрейдера и Ю. К. Орлова, на тему семантического анализа с конца 50-ых по начало 70-ых прошлого века, можно обнаружить, что они фактически придумали язык гипертекстовой разметки за 30 лет до Тима Бернерса Ли. Не их вина, что придурки объявили кибернетику лженаукой, уровень технологической базы не был готов воспринять такие идеи, а условия в союзе в принципе не располагали к стартапам талантливой интеллигенции.
В то же время, 40-50 лет назад еще не стояли остро проблемы высокой нагрузки, параллельных вычислений, распределенного хранения данных или безопасности — поскольку никаких сетей общего пользования еще в природе не было. Реляционные БД, ООП, не говоря уже о браузерах и вебе — все это было придумано намного позже. И вызовы у придумавшего это поколения были совсем другие. У моего поколения они снова изменились.
И они изменяются у каждого нового поколения — хотя естественно зависят от того, справилось ли предыдущее поколение со своими вызовами или нет. И это никак не отменяет того, что каждому новому поколению, прежде чем приступить к вызовам, нужно вырасти.
Эра айтишников начинается. У нас уже есть глобальная сеть. У нас еще нет, но потихоньку приходит «интернет вещей». Мы царапнули поверхность темы с искусственным интеллектом. И с нейроинтерфейсами. Но такими темпами работы «чистого айтишника» еще на сотни и тысячи лет.Rumlin
02.08.2015 20:25Еще раз плюсану, всё так, и IoT устройств скоро будет больше чем интернет пользователей 10 лет назад и это будут другие задачи, которые изменят «рынок», но, имхо, есть одно «но» — и оно в «Ведь основа этого прогресса в том, чтобы обучить следующее поколение за 10 лет тому, на изучение и развитие чего ты лично потратил лет 50» — прогресс не линеен, а скорее экспоненциален. Если не будет найдено какое-то решение, то скоро каждая кухарка должна будет научиться программировать, чтобы как-то сдерживать спрос на разработку и поддержку ПО. Огромное количество людей должно будет постоянно учиться, работать и переучиваться. И интервал между этими состояниями будет отсутствовать, скорее даже всё будет происходить одновременно. То что преподается в университетах устаревает на момент разработки методичек.
lockywolf
Обидно не то, что грань между дизайнерами и инженерами останется, а что не стирается грань между программистами и писателями.
Жутко обидно, что несмотря на колоссальный технологический прогресс, веб так и не стал по-настоящему «динамическим текстом», а остался всего навсего набором статей/презентаций, скреплённых ссылками.
По-настоящему динамической генерации контента как не было, так и нет, также как и, например, древовидных книг или по-настоящему интерактивных учебников.
lockywolf
Минусующим: habrahabr.ru/post/263479
stardust_kid
И на Альфу Центавра мы не летим.