Случайны выбор дневника Раскрыть/свернуть полный список возможностей


Найдено 514 сообщений
Cообщения с меткой

программисты - Самое интересное в блогах

Следующие 30  »
rss_rss_hh_new

Почему компании так упорно хотят иметь Fullstack разработчиков?

Воскресенье, 28 Августа 2016 г. 19:23 (ссылка)

image

Здесь уже написано множество статей о том, кто такой Fullstack, в чем его плюсы и минусы, в каких проектах есть смысл нанимать таких разработчиков, а где — нет. Я буду исходить из мысли, что Вы понимаете, что такое Fullstack и с чем его едят.



Мысль, которую я хотел бы выразить заключается в следующем — «Почему, даже большие аутсорсинговые и продуктовые компании, хотят нанимать Fullstack и/или развивать своих сотрудников в этом направлении?».



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



Возьмем управляющего большой компании, скажем, больше 500 человек, который получил следующую сводку от руководства: «Нам необходимо набрать 20 разработчиков для наших будущих продуктов/заказов».



Руководство не волнует, будут ли это BE или FE или Fullstack — им нужно сдать в срок заказ или выпустить продукт. Управляющий, начитавшийся многих статей о Fullstack, думает: «Вот же оно — Решение!» и начинает набирать Fullstack, исходя из мысли, что можно набрать 15 таких разработчиков и закрыть все вакансии да еще и денег сэкономить, ведь зарплаты таких разработчиков редко превышают зарплаты более узкоспециализированных разработчиков.



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



Это случается не всегда и не со всеми, но случается все чаще. Почему так? Потому что, первое, что необходимо сделать после утверждения MVP(минимального рабочего продукта) — это убедиться, что все стало на свои места и дальнейшее развития продукта пойдет максимально прогнозируемо с минимально возможным количество ошибок. И, как правило, спрогнозировать дальнейший путь приложения/продукта, может лишь квалифицированный специалист.



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



Это один из древнейших споров: «Широкий профиль из узкий?».



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

Судя по личному опыту проведения более сотни интервью, в основном с ребятами из ЕС и СНГ, часто приходиться идти на уступки руководству и нанимать хотя бы немного дотягивающего по уровню специалиста в огнем в глазах, в надежде, что он еще принесет пользу и станет «Rock Star». Все чаще видишь «Senior Dev / Senior Fullstack Dev», с миллиардом лет опыта, который не можешь решить FizzBuzz, посчитать сумму чисел Фибоначчи или написать пример рекурсии.



Сейчас сложно быть в топе, хотя бы в одном направлении, будь-то FE в Web, Android, iOs, разработке игр или же BE в

той же разработке игр, Data Science, Big Query, DB analyst, и т.д. Чтобы быть реально полезным, надо, чтобы не только «котелок варил», но и знать все тренды и иметь багаж практического опыта, а этого можно достигнуть, лишь изучая что-то новое ежедневно.



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



Да и, задумайтесь сами, с кем бы Вы хотели работать и обучаться — с Fullstack или умудренным сединами, FE, BE, GameDev, DevOps гуру?



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

Original source: habrahabr.ru.

https://habrahabr.ru/post/308686/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Любовь, похожая на код

Пятница, 22 Июля 2016 г. 14:15 (ссылка)

Женские вкусы — штука изменчивая. Судить можно хотя бы по популярным песням. Вспомните: «Парней так много холостых, а я люблю женатого», потом «Любите, девушки, простых романтиков, отважных лётчиков и моряков», в 90-е — «А я люблю военных, красивых, здоровенных...крутых и всяких деловых», в начале 2000-х — «Робот, робот, робот, я тебя люблю, мы так хотели…» Хотя, погодите, всё началось ещё в далёком 1965 году — тогда Алла Пугачёва пела «Неужели в две тысячи первом году нам заменят сердца на транзисторы?… Робот - это выдумка века. Я прошу, ну попробуй, стань опять человеком…»

И вот настала очередь создателей роботов и приложений — программистов и инженеров. «Мой парень-программист» из мемов и забавных записок в ЖЖ превратился в социальное явление. Попробуем разобраться, почему это произошло, на что способны программисты и какой он, идеальный мужчина XXI века? Читать далее

https://habrahabr.ru/post/306212/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Когда разработчику вредно совмещать программирование и техническую поддержку ПО

Четверг, 21 Июля 2016 г. 12:53 (ссылка)



Изображение сайта easywebstudio.ru



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



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



Одной из причин ухода программистов из компании, как ни странно, может стать именно необходимость совмещать техническую поддержку с разработкой. В одной из компаний, например, для разработчиков были введены своеобразные «дежурства»: каждый должен был отработать в поддержке определенное количество часов в неделю. Ситуацию усугубляло то, что это приходилось делать не каждый день, и психика разработчика не успевала выработать устойчивую привычку. Как рассказывал один из сотрудников этой компании, каждое дежурство превращалось в отбывание тяжкой повинности.



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





Изображение сайта stihi.ru



Еще один путь к упомянутому совместительству – это, как ни странно, повышение. Когда разработчика повышают до гордого звания «ведущего программиста», среди его новых обязанностей может оказаться и поддержка. По крайней мере, так заведено в некоторых компаниях. В довершении ко всему, этот человек становится негласной «службой поддержки» для младших по званию программистов.



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



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



Руководство допускает такие ситуации, в том числе, потому, что не относится к технической поддержке достаточно серьезно. На территории СНГ распространены две крайности – в поддержке работают люди, которые умеют общаться, но не обладают знаниями в предметной области; в поддержке работают квалифицированные специалисты, которые не умеют правильно выстроить общение с разгневанными пользователями.



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





Изображение сайта alexandrgilenko.com



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



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

Но если техподдержка призвана быстро решать конкретные проблемы пользователя, то разработчик при желании (это стоит подчеркнуть), может свернуть горы на этом поприще.



Чтобы не противопоставлять разные виды поддержки, отметим очевидный факт: они часто сосуществуют. Но, опять же, в силу различных причин не все умеют гармонично развивать эти направления. Кроме того, в зависимости от финансового положения компании руководство может сосредоточиться на том или ином виде поддержки, сэкономив на остальных.



Но если разработчик все-таки стал заложником такой «оптимизации» бизнес-процессов компании и на него свалилось тяжкое бремя техподдержки, у него еще остается надежда на спасение.





Изображение сайта videoforme.ru



Если в качестве инструментов применяются e-mail, специализированные helpdesk системы, чаты и социальные сети, то большинству программисту будет намного легче освоиться. Более того, если и пользователь, и разработчик умеют связно излагать свои мысли в письменном виде, они быстро найдут решение проблемы. Ведь в письменно зафиксированном запросе будут на виду детали, которые могут пригодиться для решение проблемы.



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



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





Изображение сайта journal.ib-bank.ru



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



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



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



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



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



А в каких-то случаях, к технической поддержке лучше привлечь менеджера проектов. Особенно, когда поддержка не «слишком техническая» – такая, где более важны общение и достижение каких-то договоренностей.



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



P.S.



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



А в среднем по больнице, с большим трудом можно найти жалобы (если они вообще есть) на принуждение сотрудников саппорта к программированию.





Изображение сайта joyreactor.cc



P.S.S.



«Ты ж программист» – эта фраза давно стала мемом. Так или иначе, каждый ИТшник периодически оказывает техподдержку своим родственникам, друзьям, друзьям друзей и так далее. Иногда это выполняется бесплатно или за «шоколадку» и иногда вызывает раздражение, когда такое происходит слишком часто. Так что, если вдруг на работе предлагают заниматься подобными вещами на постоянной основе, у многих «тыж-программистов» всплывает накопленный негатив.

Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/306120/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Автоматизация разработки ПО: сможет ли «программист» превратиться в «оператора ЭВМ»

Четверг, 16 Июня 2016 г. 20:33 (ссылка)

image

Изображение с сайта vse-temu.org



К чему ведет нас прогресс в области производства программного обеспечения? Средства разработки ПО становятся все более совершенными, некоторые этапы разработки полностью или частично автоматизированы. Консерваторы, конечно же, скажут, что программист в настоящее время – уже не торт, что подобная автоматизация ведет к упрощению задач и потере квалификации инженера-программиста. По их мнению, на фоне развития инструментария происходит деградация кадров.



Но если копнуть глубже, возникнут вопросы. О каких именно программистах речь? О тех, кто проектирует ПО? О тех, кто разрабатывает алгоритмы? О ведущих разработчиках или простых «кодерах»? В любом случае, одного мнения здесь быть не может.



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



Точка отсчета



Как сказал Михаил Густокашин на лекции в «Яндексе», давайте начнём с самого начала:

В самом начале у компьютеров не было даже клавиатуры! То есть всё было очень плохо — у них не было ни клавиатуры, ни экрана, были перфокарты (это такие штучечки с дырочками или с отсутствием дырочек).



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



Например, ассемблер (Assembler), который уже несколько облегчал жизнь. Ну, как он облегчал жизнь? Вместо запоминания того, что там какой-то «волшебный» код у команды, использовались всякие слова, похожие на «человеческий» английский язык — какие-нибудь add или mov — ну и затем перечислялись регистры или области памяти, переменные, с которыми нужно эти операции производить. Но понятное дело, что это в общем-то тоже требовало достаточно большого напряжения ума, чтобы держать у себя в голове, в каком регистре у нас что лежит, где какие переменные и что вообще происходит. Почему так происходило? Потому что компьютеры были «глупые» и ничего более «умного» понять не могли.


image

Изображение с сайта devdelphi.ru



На этом этапе порог вхождения в программирование был чрезвычайно высок.



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


Уровень выше — порог ниже



С появлением языков программирования высокого уровня жизнь программистов становилась легче, а производительность – выше. Программы не нужно было переписывать для каждой машины. Появились компиляторы, среды разработки. Fortran, Algol, а позже BASIC, PASCAL, C действительно были больше похожи на «человеческий» язык.



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



С появлением объектно-ориентированного программирования (С++, Object Pascal и так далее) тенденция повторного использования кода усилилась. Кроме того, со временем среды разработки становились более дружественными, и желающих освоить азы программирования становилось больше.



Программирование — в массы



Постепенно программирование перестало быть прерогативой хардкорных инженеров и математиков. Число проектов стремительно росло, программное обеспечение проникало в разнообразные сферы производства. Этому также способствовало и развитие систем управления базами данных. Появились даже такие специализации как «оператор СУБД».



Постепенно понятие «инженер-программист» стало многогранным: кто-то занимался алгоритмами, кто-то проектировал интерфейсы, кто-то просто занимался кодированием – то есть реализовывал в коде готовые алгоритмы своих коллег. Само программирование стали делить на две крупные группы – системное и прикладное: кто-то разрабатывал операционные системы и драйверы, а кто-то писал приложения для автоматизации бизнес-процессов на овощной базе.



Для каждой из специализаций требовались индивидуальные компетенции, поэтому переход от одной специализации к другой был затруднителен. Но минимальный порог вхождения в разработку ПО стремительно снижался.



Появление языков (Java, C#) и соответствующих фреймворков еще больше способствовало этому снижению, а также дифференциации специалистов по направлениям и уровням подготовки.



В результате у программистов закрепилась градация наподобие [Junior-разработчик, Senior/Middle, Team Lead, Software Architect]. С одной стороны, продвинутый инструментарий разработки позволял менее квалифицированным программистам успешно справляться с относительно простыми задачами, не имея глубоких знаний и серьезных навыков. С другой стороны, с каждой последующей ступенью карьерной лестницы порог вхождения также становился выше.



image

Изображение с сайта



Но если специалист задерживался в статусе начинающего, он мог заметить одну особенность: бурно развивающиеся технологии разработки ПО еще сильнее снижали порог вхождения, и среднестатистический Junior урожая N-го года знал и умел еще меньше, чем его старший товарищ — Junior (N — k)-го года.



Веб-разработка методом «тяп-ляп»



С развитием веб-разработки программистам потребовалось встать на другие рельсы (ассоциация с Ruby On Rails здесь тоже уместна), чтобы освоить новые языки и стек интернет-технологий разработки в целом.



После того как веб-разработка, начавшая набирать обороты только в 90-х годах, совершила огромный скачок в развитии, Михаил Густокашин может свободно пускаться в подобные рассуждения:

Допустим, вы хотите написать новый Facebook (социальную сеть). На чем вы будете это писать? HTML, CSS — это дизайн, а мы хотим, чтобы там можно было фотографии добавлять, друзей, комментарии оставлять.



Для скриптовой части — то есть то, что будет происходит на стороне клиента, — это JavaScript.



На удивление, он написан на PHP — и Facebook, и многие другие большие проекты. Пришлось, конечно, написать свои какие-то вещи, чтобы это всё-таки работало нормально, а не так как «тяп-ляп» было сделано, но они справились.



Здесь и сейчас, понятное дело, с нуля уже для веба никто ничего не пишет. Все ищут какой-нибудь фреймворк или ещё чего-то. Интернет-магазин? Скачали фреймворк для интернет-магазина — ну и всё, написали интернет-магазин.


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



На волне автоматизации



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



Все потому, что в чьи-то светлые головы пришла идея автоматизировать процесс веб-разработки. Хотя, на самом деле, идея не нова, так как она уже частично была реализована во многих инструментах разработки ПО под Desktop-платформы в виде автогенерации форм и целых слоев приложения – например, генерация классов по структуре базы данных.



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



Мы выяснили, что по этому поводу думают эксперты, представители ИТ-индустрии:





image

Алексей Бычко, старший релиз-менеджер (Percona), разработчик проектов Percona Server for MySQL, Percona XtraDB Cluster, Percona XtraBackup, Percona Server for MongoDB, PQuery, преподаватель курса «Системное администрирование» в ИТ- Академии Алексея Сухорукова:



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



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



По сути, это два подхода, которые выросли из факта наличия проективных Unix-подобных систем и процедурных Windows-подобных. Огромной корпорации, где всё разбито на мельчайшие подзадачки, важна воспроизводимость результата, а не оптимальное решение – если оператор ушёл, нужно, чтобы новый по инструкции делал то же самое и не хуже.



Но если у нас есть задача, которая конкретной процедурной системой, библиотекой или средой решается плохо или не решается вовсе (коллеги постарше помнят, что бывает, когда в написанный в C++ Builder или Delphi текстовый редактор попадает большой файл – ничего не листается и всё тормозит, и это никак не поправить), то нам нужно взять «чистую» систему, которая даёт больше свободы, и позвать программиста, который согласен не просто гуглить, а писать адекватное решение самостоятельно с нуля.


image

Олег Бунин, основатель компании «Онтико», организатор конференций Highload++, РИТ, FrontendConf, RootConf, WhaleRider, AppConf, Backend Conf.

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



С появлением автоматизирующих разработку инструментов ценность людей, которые понимают, что происходит под капотом таких инструментов, растёт. Требования, которые к ним предъявляются, растут. Объём знаний, который нужно освоить, растёт.



Конечно, речь идёт не о создании лендингов, а о разработке мало-мальски серьёзного проекта.


image

Макс Лапшин, создатель ErlyVideo, создатель Flussonic, разработчик многих известных решений в области стриминга видео.



Первый раз сообщения о том, что всё, что надо было написать, уже в целом написали, и теперь программисты просто будут собирать кубики из готовых компонент, и вообще, наверное, программировать мышкой, я услышал году примерно в 1995. Как несложно догадаться, с 1995 года по сегодня было написано безумное количество адского хардкорного системного кода, и возникло и умерло немало больших бизнес-платформ, на которых даже что-то было напрогано «мышкой».



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



Всё дело в том, что индустрия идет вперед. Да, на компьютерах больше не 640 КБ памяти, и программисту под Windows больше можно не волноваться о памяти вообще. Но на замену большим компьютерам пришли маленькие, и их много.



Сегодня всё равно приходится думать, как записать на прошивку IP-камеры софт, упихнувшись в 200 КБ на диске. Приходится думать, как упихнуть код в маленький IOT-сенсор, который должен на своей крохотной батареечке прожить год с радиообменом.



Индустрия очень стремительно расширяется, и в ней появляется место людям, которые не очень глубоко разбираются в деталях работы ЭВМ, но безусловно: сегодня людей, которые знают, как работает, например, DMA, нужно больше, чем 10 лет назад просто потому, что индустрия до сих пор растет.


image

Александр Лямин, основатель и CEO компании Qrator Labs, одного из ведущих мировых поставщиков в области защиты от DDoS-атак.



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



Так вот, программисты нужны в компаниях совершенно разного толка. Какие-то компании производят холодильники, какие-то — клепают скворечники, а некоторые, как SpaceX, действительно разрабатывают звездолёты. Поэтому пропорция 1:9, естественно, не догма, она везде будет своя. Где-то, действительно, достаточно нескольких кодеров в штате. Где-то нужны уже хорошие прикладные программисты — люди, обладающие алгоритмическим багажом и способные грамотно его применять.



В ряде случаев требуется уже даже не столько программист, сколько computer scientist — человек способный не только, как минимум, грамотно модифицировать алгоритмы под нужды конкретной ситуации и задачи. Следующий уровень — это data scientist, хороший прикладной математик. Продолжая аналогию, скворечник можно склепать из общедоступных стройматериалов, но сплавы для ракеты на строительном рынке уже не купишь. На этом уровне задача уже начинает выглядеть примерно так: вот проблема, вот массив данных, нужны гипотезы-алгоритмы-PoC и, как следствие, постановка задачи для реализации. И в процессе создания действительно хороших продуктов — рано или поздно, так или иначе — задачи нетривиальной обработки данных возникают неизбежно.



То есть человек-«кодер» решает лишь часть проблем, стоящих перед разработкой.



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



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



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



Поэтому вряд ли когда-нибудь кому-нибудь удастся превратить программиста в оператора ЭВМ окончательно.

Original source: habrahabr.ru.

https://habrahabr.ru/post/303486/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best

Комментарии (0)КомментироватьВ цитатник или сообщество
Сергей_Удачин

Хакерская банда, или Сетевые воры

Понедельник, 06 Июня 2016 г. 16:50 (ссылка)

СЕТЕВЫЕ ВОРЫ

http://earth-chronicles.ru/news/2016-06-05-92855

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





13 (373x31, 3Kb)

0_8b870_c5b98dc3_S (20x20, 1Kb)
Метки:   Комментарии (1)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

[Из песочницы] Правильный офер при устройстве программиста в офис

Вторник, 17 Мая 2016 г. 14:24 (ссылка)


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







У меня веб-студия в Москве, в подчинении более 70 человек. Опыт работы с 2001 г. Начинали с обычных веб-сайтов: друг делал дизайн, а я программировал по ночам. За все время прошел долгий путь от простых сайтов-визиток до сложных интеграционных решений.

Читать дальше →

https://habrahabr.ru/post/301022/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
Whitewinged

Сегодня было первое собрание всего отдела backend-разработки...

Пятница, 25 Марта 2016 г. 21:29 (ссылка)


Я пришла последняя. И как же я почувствовала себя странно! 40 человек - и я единственная девушка(

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
PogrebnojAlexandroff

Не боись... -- переживём и это.

Пятница, 05 Марта 2016 г. 02:55 (ссылка)

​Птичка по зёрнышку клюёт; так и статьи мои, или заметки -- как семена растений: расбросаны е в пространстве широком и во времени бесконечном. Кто-то раз бросает, а иной -- светом познаний, важных и значимых для кого-то, постоянно струится.

Комментарии (21)КомментироватьВ цитатник или сообщество

Следующие 30  »

<программисты - Самое интересное в блогах

Страницы: [1] 2 3 ..
.. 10

LiveInternet.Ru Ссылки: на главную|почта|знакомства|одноклассники|фото|открытки|тесты|чат
О проекте: помощь|контакты|разместить рекламу|версия для pda