Комментарии 24
Новый язык освоить не сложно, но современное программирование, это умение сочетать внешние библиотеки. В проекте десятки библиотек, каждая решает одну задачу, и у каждой библиотеки есть десятки аналогов. Знать всё это разнообразие, следить за тенденциями в рамках нескольких языков довольно сложно.
А уж знать бизнес-задачи, понимать клиента с полу слова и всегда помнить основную потребность клиента, это ещё одно наслоение необходимых навыков. К этому нужно стремиться, но не всегда получится.
В современных приложениях, перед тем как будет найдено «что программировать» и «куда программировать» должно пройти множество этапов согласований, дизайна, архитектуры, подбора библиотек, методов тестирования. Уметь делать это быстро, задача всей команды.
А уж знать бизнес-задачи, понимать клиента с полу слова и всегда помнить основную потребность клиента, это ещё одно наслоение необходимых навыков. К этому нужно стремиться, но не всегда получится.
В современных приложениях, перед тем как будет найдено «что программировать» и «куда программировать» должно пройти множество этапов согласований, дизайна, архитектуры, подбора библиотек, методов тестирования. Уметь делать это быстро, задача всей команды.
Может быть решать бизнес-задачи и важнее, но когда ищешь работу — тебе задают вопросы по поводу языков программирования.
Так может это и есть «red flag»? Конечно зависит от контекста, но если тебя гоняют только по задачам из серии «А что выведет данный код?» это повод задуматься, минимум о квалификации.
Но если это проходные задачи, а потом идут вопросы на тему «Какую бы вы сделали декомпозицию в такой-то задаче?», это уже совсем другое дело.
Но если это проходные задачи, а потом идут вопросы на тему «Какую бы вы сделали декомпозицию в такой-то задаче?», это уже совсем другое дело.
Эх, если бы эти вопросы ещё были бы адекватными, а то нередко бывает и такое:
1. как используется опция языка Х в случае У (притом малоизвестная фишка или же попросту опасная которая запрещена к использованию в отраслевых стандартах и сам ею не пользуешься)
2. что будет если число во флоате привести к инт16 вычесть Х, а потом сохранить эти бинарные данные побитово дабл заполнив оставшееся нулями, чему станет равен дабл?
3. как реализовать перемножение миллион битных чисел в реалтайме по мере получения бит из двух потоков?
Да и почему то прокатывает такое:
1. я, как инженер, обязан открыть стандарт ааа, а так же проверить ббб, т.к. использование ааа явно не стандартное.
2. я такой опасный код не пишу, и насколько помню язык ввв в совокупности с IEEE 754 запрещает такое
3. я не понимаю зачем это нужно, реализация может сильно отличаться поэтому пожалуйста ответьте на вопросы…
т.е. ответы по существу не даёшь вообще, а в итоге порой и оффер присылают…
вопрос: зачем этот цирк нужен был?
А когда хочешь показать свои проекты и или рассказать чего ты уже реально добился и какую пользу бизнесу принёс — никому дела до этого нет или попросту даже нет возможности рассказать об этом (собеседование «идёт по рельсам» — заполняешь анкеты без доп графов в залоченой пдфке например, обрывают связь сразу после того как задали все вопросы и тд).
В итоге я сам, и некоторые мои коллеги уровнем выше мидла, не получали работу по обычному пути из собеседований. Часто проще найти прозрачную и открытую к диалогу фирму, профиль которой совпадает с твоими навыками, видишь что ты можешь помочь тем то и тем то, связываешься с ними, докладываешь им об этом с доказательствами в виде уже выполненных публичных проектов.
Берут и с з/п в разы выше чем офферы по обычным собеседованиям где спрашивают про язык.
1. как используется опция языка Х в случае У (притом малоизвестная фишка или же попросту опасная которая запрещена к использованию в отраслевых стандартах и сам ею не пользуешься)
2. что будет если число во флоате привести к инт16 вычесть Х, а потом сохранить эти бинарные данные побитово дабл заполнив оставшееся нулями, чему станет равен дабл?
3. как реализовать перемножение миллион битных чисел в реалтайме по мере получения бит из двух потоков?
Да и почему то прокатывает такое:
1. я, как инженер, обязан открыть стандарт ааа, а так же проверить ббб, т.к. использование ааа явно не стандартное.
2. я такой опасный код не пишу, и насколько помню язык ввв в совокупности с IEEE 754 запрещает такое
3. я не понимаю зачем это нужно, реализация может сильно отличаться поэтому пожалуйста ответьте на вопросы…
т.е. ответы по существу не даёшь вообще, а в итоге порой и оффер присылают…
вопрос: зачем этот цирк нужен был?
А когда хочешь показать свои проекты и или рассказать чего ты уже реально добился и какую пользу бизнесу принёс — никому дела до этого нет или попросту даже нет возможности рассказать об этом (собеседование «идёт по рельсам» — заполняешь анкеты без доп графов в залоченой пдфке например, обрывают связь сразу после того как задали все вопросы и тд).
В итоге я сам, и некоторые мои коллеги уровнем выше мидла, не получали работу по обычному пути из собеседований. Часто проще найти прозрачную и открытую к диалогу фирму, профиль которой совпадает с твоими навыками, видишь что ты можешь помочь тем то и тем то, связываешься с ними, докладываешь им об этом с доказательствами в виде уже выполненных публичных проектов.
Берут и с з/п в разы выше чем офферы по обычным собеседованиям где спрашивают про язык.
Художнику, когда он рисует пейзаж, надо спуститься в долину, чтобы охватить взглядом холмы и горы, и подняться в гору, чтобы охватить взглядом долину
— Государь, Н. Макиавелли
— Государь, Н. Макиавелли
Умение решать бизнес-задачи — это на самом деле часть более глобальной сущности — всестороннего опыта работы.
Согласен, сам по себе код не генерирует прибыль для бизнеса.
в процессе этого погружения специалист просто забывает о том, что для бизнеса технологии — лишь инструмент для решения своих задач.
Моя точка зрения состоит в том, что конкретный язык программирования вторичен.
Слова не мальчика, но менеджера. Привели одну крайность и опустились в другую.
Есть бизнес, в котором можно на чем угодно состряпать решение. Есть бизнес, который строится на конкретной технологии и 100% погружением технарей в нее: Highload компоненты, ААА геймдев, ИИ — если вы думаете что там язык вторичен и как говорит inmater "Новый язык освоить не сложно" — то вы явно решаете бизнес-проблемы первого случая, где не важно — go, rust, рефакторинги, оптимизации — всё одно.
Я думаю, не стоит воспринимать автора слово в слово. Общая идея такова, что вы можете выбирать из множества инструментов, решающих вашу задачу, а не зацикливаться на каком-то одном, а не про то, что нет существенной разницы между направлениями в ИТ. Существует очень мало задач, для которых выбор инструмента однозначен, и даже в Highload или ИИ.
Кроме того, становясь специалистом одной платформы, вы сразу искусственно ограничиваете круг доступных вам проектов, и попадаете в зависимость от её жизненного цикла. Почему бы специалисту по геймдеву не владеть и Unity, и CryEngine, и Unreal Engine?
Кроме того, становясь специалистом одной платформы, вы сразу искусственно ограничиваете круг доступных вам проектов, и попадаете в зависимость от её жизненного цикла. Почему бы специалисту по геймдеву не владеть и Unity, и CryEngine, и Unreal Engine?
Я навидался «универсалов». И людей, которые думают что могут овладеть любой технологией за 21 день. Не бывает таких, человек может и должен знать другие стеки и языки для кругохора, но делать работу как полноценный сениор сможет максимум в одном, двух. В других — только как джун/мид.
Я видел и хорошие, и плохие примеры. Но в общем случае, если человек профессионал и понимает предметную область, на другой технологический стек он достаточно легко переходит при необходимости. Да и, собственно говоря, платформы все равно отмирают. Я за 20 лет их пять штук сменил. И знаете, подняться до уровня сеньора сложно только в первый раз. Даже если новая платформа и отличается, все равно, знание бэкграунда очень помогает.
Почему бы специалисту по геймдеву не владеть и Unity, и CryEngine, и Unreal Engine?
А на обеде по фану левой рукой на салфетке крафтить ai на основе нейронок, а правой моделькам текстуры запекать, запивая чайком.
Это вам не JS фреймворки чтобы можно было вот так взять и с легкой руки овладеть сразу тремя.
Вот так и с легкой руки — нет. Но поработать какое-то время и изучить на достаточном для профессиональной работы уровне, почему бы и нет?
Если считать профессиональным уровнем "всего понемногу и ничего хорошо", то да. На клепание типовых игрушек хватит.
Ну а серьезно, что там вообще есть в этих движках такого, что не поместится в голову одного человека?
Архитектура классов разнится, принципы построения взаимодействия в ECS отличается, объявление/регистрация классов, отличия в составе относительно встроенных классов/api, подходы к рендеринг-пайплайну, управление ассетами отличается и накладывают свои специфичные ограничения. Всякие нюансы скриптования, API, сетевой модели и т.д. и т.п. Плюс разницу C# и C++ добавьте. Ну и учитывать что простенькие хэллоуорлды минут по 15 могут компилиться преспокойно. То бишь за условный рабочий день 32 раза скомпилировать — не густо.
То есть со стороны кажется это довольно просто взять и выучить их всех, на деле же чтобы выучить на сколько-нибудь приличном уровне и понимать каким образом с этим работать на нормальном уровне необходимо довольно немало времени.
НЛО прилетело и опубликовало эту надпись здесь
"… Там спикеры делятся опытом, как они решили бизнес-проблему с помощью ИТ-технологий.." — я чаще всего наблюдал как спикеры рекламировали технологии/платформы/языки/инструменты, после чего часто спорил с коллегами, которые видели только одно решение задачи. К примеру был у нас один Пешо, который хоть тресни хотел бизнес правила записать в WWF. В итоге как-то убедил начальство перейти на WWF, перейти то перешли, но ненадолго, оказалось что это решение неудобное, Пешо ушел с работы, а мы переписали WWF на T-SQL.
НЛО прилетело и опубликовало эту надпись здесь
а давайте поставим вопрос иначе: что важнее, умение просто решать бизнес задачи, или умение решать бизнес задачи так, чтобы потом не приходилось доделывать/переделывать/рефакторить полгода? Для второго владение инструментарием таки понадобится
для бизнеса технологии — лишь инструмент для решения своих задачЭто очень популярное утверждение, но хотелось бы немного поспорить и поговорить о точности формулировок. Как мне кажется, во время мысленного переноса разработки ПО на привычные сферы и методы работы слово «инструмент» приобрело не совсем изначальное значение, что может достаточно сильно путать людей. Изначально оно достаточно часто вызывает ассоциации с тем, что это только средство обработки какого-то материала, его можно заменить (хотя часто замена инструмента требует денег, времени и подготовки специалистов). При этом «материал» — это то, что предоставляют мастеру, затем он обрабатывает материал и отдает его заказчику в виде продукта.
И в этом ключевое отличие инструмента от материала и продукта: различный инструмент при адекватном выборе и использовании позволяет достигнуть практически одинакового результата и не вносит свои «побочные эффекты», поэтому выбор инструмента часто доверяют мастеру. Утрированная аналогия: можно почистить картошку специальным инструментом для чистки овощей, небольшим острым ножом или гигантским тупым тесаком, будет довольно большая разница в скорости и удобстве, но готовый продукт, если он соответствует требованиям по потерям и качеству очистки, будет одинаковым, при этом выбор инструмента для чистки не влияет на то, что можно дальше делать с картошкой. Повар решает свою задачу, заказчикам очищенной картошки почти все равно, как повар будет ее готовить, если они получат то, что хотели.
Материал же оказывает очень большое влияние на результат: неправильный выбор материала в ряде случаем не компенсировать выбором специальных инструментов, даже если очень хочется. Я буду выглядеть дураком и не получу ничего разумного, если куплю хороший сосновый брус, принесу его печнику и скажу, что хочу хорошую печку из него. Именно поэтому адекватный заказчик участвует в выборе материала и рассказывает, что и почему он хочет получить в итоге. При этом хороший мастер должен знать свойства материала, преимущества и возможные проблемы.
Во многих случаях в IT-сфере разница почти незаметна: какая разница, продуктом или инструментом мы перекладываем данные из одной небольшой базы в другую. Но в ряде случаев это крайне важно: бизнес думает, что заказывает инструмент, но на самом деле он заказывает продукт, где язык программирования, база данных, система виртуализации — это один из многих материалов-компонентов. И в этом случае заказчик должен участвовать в выборе материалов, оценивать их стоимость, сильные и слабые стороны, в том числе, чтобы использовать и модернизировать эти системы в будущем. И при выборе и работе с материалом требуется как минимум один специалист (если его хватит, чтобы контролировать работу всех остальных, не нарушая при этом график), который знает возможные подводные камни данного материала и способов его обработки, а не только умеет выбирать материал по рекламным буклетам и делать так, как написано в инструкции к станку.
И в этом ключевое отличие инструмента от материала и продукта: различный инструмент при адекватном выборе и использовании позволяет достигнуть практически одинакового результата
Ну так и различный материал тоже, это от конкретного кейса зависит. Разница между инструментом и материалом в том, что материал становится частью продукта, а инструмент — нет. У вас сосновый брус не подходит для построения печки, но зато можно выбирать из глиняного кирпича, из силикатного кирпича и т.д., и во всех случаях результат будет одинаковый, по крайней мере, не отличаться по нужным вам потребительским свойствам. С другой стороны, дайте в качестве инструмента печнику не мастерок и киянку, а плоскогубцы, и тоже не получите разумного.
Становятся ли софтверные компоненты частью продукта в ИТ? Нет, т.к. вы одну и ту же СУБД, один и тот же язык или один и тот же гипервизор можете использовать для создания массы продуктов. Поэтому это инструменты, а не материалы.
С другой стороны, вопрос этой формулировки — это такая ерунда, которая не стоит времени, потраченного и вами, и мной на спор :)
Я согласна главное уникальная бизнесс идея и правильное движнени к цели. Хотя потом могут быть проблемы с поддержкой этих древних технологий. К примеру огоромные сервисы мастадонты на джаве
Правильный работодатель ищет специалистов, способных решать поставленные задачи. И решать их качественно, и за адекватное время. На каком языке программирования и с привлечением каких программных каркасов будет решена задача дело вторичное ( если полученный результат удовлетворяет всем критериям ).
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Что важнее: знать язык программирования или уметь решать бизнес-задачу?