Vasilii Petrov
Выглядит красиво! Надо бы затестить этот Webflow для интерактивных презентаций. Вроде не сложнее, чем в PowerPoint набросать, но смотрится красивее.
Мне кажется, сложный backend - это про большие компании с огромными продуктами, но у них уже есть разработчики. А небольшие компании как правило работают с чем-то простым (чем вы, наверное, не хотите не заниматься, потому что раз просто - то и денег мало). Получается парадокс. Найти середину, где есть заказчик сложного проекта, но нет команды - сложно, к сожалению.
Странные цифры озвучены для разработки. Мне кажется, что сгенерировать 10к картинок по макету художника скриптом на питоне и загрузить их автоматически на готовую платформу (как представлено в посте) - дело часов на 20 разработки джуна максимум.
"Главная особенность NoCode-разработки в том, что сайт или приложение не пишется кодом с нуля." - Если дело отдается вменяемой студии как разработка некоего "стандартного приложения" (ниша No-Code), то обычно эта студия тоже не пишет ничего с нуля, а использует готовые наработки и выкатывает по приложению в неделю.
Особой разницы, какие складывать кубики (no code, или наработки в коде), нет. Идея переиспользования в разработке не нова.
На моей практике большинство компаний, сильно увлеченных созданием "Бренда работодателя", совсем забывают, что прежде всего для любого работника важен не "фантик" компании, а реальный профит от работы на эту компанию. "Фантик" работает только до первого собеса/месяца работы.
Реальный профит - грамотно выстроенные процессы внутри компании, медицинская страховка, достойная оплата труда. Значит для того, чтобы в компанию приходили люди, нужно им показывать не "креативную энергию", "айдентику", "дизайн", а дать им понять, что работая в компании, они будут улучшать качество своей жизни. Тогда кандидаты сами потянутся - не смутит и отсутствие инстаграмма или "кофе с печеньками".
Ведь если человек придет в компанию, а там все не так радужно, как обещано - он непременно поделится своими ощущениями с коллегами по профессии. И "фантик" станет еще менее эффективен.
Вывод - не "креатив и ритуалы", а показать явные улучшения жизни работника (зарплата, страховка, обучение, отсутствие "эффективных" менеджеров, адекватность коллектива).
Не исключен вариант, что, может быть, дополнительным фактором встраивания "голосового ассистента" является желание отдела разработки занять себя на N времени и получить ЗП за фичу, а может даже и премию выдадут менеджеру :)
Вот и странно, что присутствует такая ситуация по данным языкам (спрос и предложение), что зарплаты такие высокие.
Ведь, на мой взгляд, за счет хорошей экосистемы, детальной документации и стабильных фреймворков можно произвести намного больше качественных программистов, тем самым покрыв с лихвой спрос на рынке.
Намного быстрее обучить человека ASP.NET, чем заставить разбираться в тонкостях современного фронтенда (со всеми транспилерами, сборщиками, историческими костылями, костылями поверх костылей, различием поведения среды исполнения и кучей всего другого).
del. не в ту ветку
Похоже на то, что составили объявление не очень ответственно, может быть даже в спешке, может быть даже чтобы было много откликов, а потом предложить менее высокооплачиваемые вакансии.
Честно - не понимаю такого распределения язык/зарплата. Казалось бы, работа на более легких и удобных языках разработки (или технологиях) должны оцениваться дешевле, но выходит наоборот.
Java и C# одни из наиболее удобных языков программирования во многих сферах, по ним много литературы, фреймворки написаны, паттерны описаны. Плюс к этому понятная экосистема.
На мой взгляд, работа на них может и должна оцениваться дешевле, чем работа на языках или в экосистемах, которые бурно развиваются или не предоставляют таких удобств (например, зоопарк фронтенда или embedded системы).
Также различие ЗП на практике в регионах и Москве слишком высокое, чтобы вообще задумываться на секунду о работе в регионе. (Бывало в частных случаях, что за одни и те же задачи на одной технологии в регионе платили 40к, а в Мск 170к на удаленке).
А что настолько сложного в реакте и его экосистеме, что за него дают 700к?) Там весь стек React, Redux и Saga выучивается за месяц так, что уже можно расширять, контрибутить и оптимизировать.
Интересный опыт, спасибо.
Возник вопрос: "Lead закупки fb" и "lead по контекстной рекламе" - звучит очень громко и солидно за счет конечно "lead", но мне кажется, что "емкость" этих специальностей довольно небольшая и сводится к очень базовым знаниям матстата, исторической сводки и управления (настройки) кабинета на заранее запрограммированной платформе. Собственно, зачем так много специалистов?
PS. Я не очень разбираюсь в Вашей сфере, не сочтите за негатив. Если буду больше про это знать, мб. будет иное восприятие.
А причем тут "парсинг"? На мой взгляд, там играет роль сам факт создания базы данных, а не способ, каким они были получены.
Еще один раздражающий пример: откройте любую группу вконтакте не заходя в аккаунт и пролистайте вниз. Через пару секунд вылезет сообщение с предложением о входе и кнопкой "Не сейчас". Но вот когда вы на нее наведете и уже соберетесь кликнуть - вместо кнопки появится "Войти через Facebook", а "Не сейчас" сдвинется вниз. Отвратительно!
Визуальное программирование хорошо там, где оно уместно. Например формулу создать приличную с помощью диаграмм - неудобно, и неудобно читать.
А вот трансформацию потоков данных, где какие-то данные расщепляются, сливаются, анализируются и т.п. - это уже нагляднее (но автор не предоставил такой случай) - такие инструменты активно применяются в анализе данных. Что-то специфическое сделать всегда быстрее на питоне с tf, но для "быстро потыкать" нормально.
NO-CODE ≠ NO-PROGRAMMING. Ну и судя по скриншоту с теми же for циклами это выглядит как визуальный редактор логики бизнес процессов. Just another visual DSL. Для любой отрасли можно сделать некий DSL, который будет решать некое подмножество этих бизнес задач более лаконичнее, чем язык программирования общего назначения.
Более того, существует множество визуальных систем программирования, которые оперируют потоком данных, а не императивной логикой (особенно они проявили себя в обработке данных, напр. orangedatamining).
Сам этот подход "No-Code" давно применяется при разработке шейдеров например (как для игр, так и для визуализации в пакетах 3D моделирования). Однако даже там приходится своего рода "программировать", только мышкой.
В результате заменили печатание буковками c помощью яп общего назначения на DSL для конкретной задачи.
Кода нет, программирование есть :)
Выглядит как визуальное программирование в котором задание алгоритма идет через DAG. Точно такое же, как например в Unreal Engine. Как его не назови, это все равно программирование.
Для таких больших компаний проще написать свое решение, реализующее все "хотелки". К тому же не сомневаюсь, что там работают разработчики не хуже чем те, которые пилят "отраслевые решения".
Они переписали приложение не для сиюминутного увеличения KPI, а для того, чтобы его можно было нормально поддерживать и быстрее изменять под требования бизнеса в будущем.
Из приведенного поста, на мой взгляд, не видно "космической" технической сложности программной части продукта. Могу предположить, что основная часть расходов - это совсем не программисты, а робототехника, корпус, логистика, аренда и всякое такое.