Просто некоторая граница на освоение языка (можно же изучением заниматься бесконечно), многие справляются за неделю. Все же PHP и Python во многом похожи. Не в плане того, что у них под капотом, а в плане реального применения.
Ну, в какой-то момент мы начали писать на нем слишком сложную логику. А Lua неудобно отлаживать и как язык он, конечно, простой, но несколько обрезанный. Потом перенесли сложную логику на python. А вот об активном применении Lua в робототехнике и для микроконтроллеров я даже как-то не знал. Там его «легковесность» вместе с интерпретируемостью действительно огромный плюс.
Вот я сейчас посмотрел вилку зарплат (по вакансиям и резюме) по Новосибирску на HH.ru, для разработчика Delphi это 40-50 тысяч рублей. Вакансий мало, резюме - много.
Если человек совсем ничего не понимает, то его век в IT будет недолгим. Беда наступает, когда человек зависает между поверхностными знаниями и глубоким пониманием. То есть он вроде и может, но через постоянное усилие над собой. Вот это усилие и выжигает людей, медленно, лет за 15-20. В науке все где-то так же, но там немного денег, такого притока желающих нет. Поэтому остаются в основном те, кто может и любит свою работу. Плюс процесс защиты кандидатской и докторской очень долгие. Вот где-то к 40 годам человек будет считаться состоявшимся специалистом. Лишних людей почти не остается.
Наверное, вы все же разработчик. :о) Из написанного вами у меня только один вопрос возник, почему Lua? Это ж еще тот «мопед», иначе и не скажешь. Самое ужасное то, что я сам его знаю и мы реализовали не нем высоконагруженный сервис. Сервисом мы гордимся (архитектура красивая, скорость работы высокая, надежность уникальная), а вот то, что он сделан на Lua никому не говорим. А так, время идет, а проблемы остаются похожими друг на друга. Но для этого нужно достигнуть некоторого профессионализма в области, на это способны далеко не все.
В реальности у меня очень широкий круг общения, который захватывает большой спектр технологий. Можно сказать, что на Fortran сейчас пишут всё меньше и меньше, даже в научной среде, которая занимается численным моделированием. Даже оттуда его вытесняет С++. Для меня очень сомнительно, что на Prolog сейчас идет много разработок. Дело в том, что это отдельная парадигма программирования, которая имеет очень узкую нишу применения. Возможно, его еще где-то используют, но это должны быть специфичные задачи. Если коснуться PL SQL, то могу сказать что его сейчас его все так же активно используют. Иногда слишком активно, за что приходится очень больно бить по рукам. Размещать слишком много бизнес-логики в базе данных - плохая идея и известными последствиями. Тем не менее, язык все еще востребован, причем, как для диалекта Oracle, так и для диалекта PostgreSQL. А вот с Delfi все несколько сложнее. Нам приходилось консультировать компанию, которая реализовала внутри себя аналог 1С на Delfi, после чего людям захотелось упаковать это, как продукт. При таких инициативах всегда проводится анализ доступности разработчиков на требуемых языках. Нет программисты на Delfi есть, но стоят они меньше джуна на Python. Реалии рынка где-то такие.
Странно слышать от человека, который пишет про SPSS (ничуть не фу) и (кажется) понимает, что такое ML с точки зрения математики, о том, что он только-только собирается зайти в ойти. Скорее всего, у вас уже есть фундаментальные знания и системное мышление. Остается только немного актуализировать знания по технологиям дата-сатанизма и найти нормальную команду (не стартап). В стартапе может не получиться с горящими глазами делать какие-нибудь глупости, а в серьезной компании будут интересные задачи.
Наверное, я в своей жизни провел уже несколько тысяч технических собеседований программистам. Я видел много людей, которые не смогли «добежать», из-за чего очень сильно отстали от отрасли. Здесь я с вами согласиться не могу. А вот с тем, что многое из современных тенденций родом из 80-90 годов, я полностью согласен. Что-то является воплощением идей того времени, что-то просто повтором старого и хорошо забытого, но на новом уровне. Но вот есть одна беда. Людей, которые реально понимают, как оно работает под капотом и почему оно работает именно так, очень немного. Да, эти люди будут востребованы «всегда». Только их процент от общего числа «программистов» сейчас очень небольшой. Собственно об этом я и написал.
К слову говоря, мы не считаем месенджеры какой-то сложной задачей. Если бы мне предложили реализовывать его на базе С++, я бы такое запретил. Скорость разработки медленная, поддерживается плохо, преимуществ перед web-сокетами нет никаких. Ей богу, у нас месенджер в одного реализует фронтендер, просто взяв Flutter для клиентского приложения и Node.js для сервера. Кроме того, стоит заметить, что у Flutter нет никаких проблем в работе с камерой, а что такое выжимать производительность для нейросетей я себе очень плохо представляю. Может быть, просто нейросеть нормальную взять? И обучаете вы её, наверное, не на телефоне? Нет, у меня были коллеги, которые извращались с С++ на мобильных устройствах, но это были задачи из разряда запуска навигационной программы на китайском убогом планшете, из-за этого приходилось вписываться в те ресурсы, что есть. Кстати, первой из задач, что мы реализовали с использованием Flutter, это географически распределенная система на нестабильных каналах связи для пассажиров речных круизов. Мобильное приложение позволяло людям просматривать экскурсии, использовать аудиогид, смотреть контент из бортовой мадиа-библиотеки, делать заказы услуг, доступных на борту. Конечно, приложению приходилось работать с бортовым сервером, который при наличии связи соединялся с центральным сервером. В нашей стране мобильный интернет много где недоступен. Для нас это несложный проект. Когда дело дойдет до реальных проектов, скорее всего, вы серьезно проиграете по производительности. По производительности (скорости) разработки, по скорости внесения изменений и раскатки обновлений. И скорости работы приложения, не потому что С++ медленный язык либо ему не хватает каких-то средств, просто есть еще архитектурный уровень, который тоже очень не простой. P.S. Я бы никогда не стал отождествлять потоки и процессы, это как путать работу над общим и раздельным полем памяти.
Интересный инструмент, спасибо. Но дело даже не в деревьях. Если взять иерархию, которая выстраивается на контроле, то она свободно формирует граф с циклами. Они нужны, чтобы предотвратить отсечение головы иерархии от информации о том, что происходит снизу. Дело в том, что одновременно существуют несколько иерархий. Например, под юридической структурой, может находиться функциональная и корпоративная структура. На каждом слое свой граф, своя RACI-матрица, свои выходы на иные слои. Причём, каждый слой, на самом деле, двойной. На одной его стороне иерархия на контроле, на другой стороне иерархия на общей цели. Шести измерений тут не хватит, если честно. Но для описания формальных связей RACI-матрица выглядит очень неплохо. Особенно за счёт разделения «отвечает» на «делает» и «принимает».
В любой большой и технологичной. Любая большая компания это какая-то из вариаций ада, от бюрократичного ада до хаотичного ада. Мне больше нравился хаотичный. Ещё имейте в виду, что например на VC вчера была статья о найме топ-менджеров. В комментах было прямо написано, что выращивать руководящие кадры из линейных исполнителей нельзя. То есть в бюрократическом аду готовьтесь к стеклянным потолкам. Если вы не знаете, как их обходить, то лучше с ними не сталкиваться. То есть просто пойти в большую Ит-компанию у которой внутри большой бардак.
В той книжке было много других интересных мыслей. У нас есть направление «бодишопа», но там все сильно по другому. И это последнее место, где бы я стал искать таланты. Зачем может потребоваться много талантов. Только чтобы сделать что-то грандиозное, не иначе. )) Ну и нужно ещё помнить, что «много» каждый понимает по своему. Например, для компании из 50 талантов я просто не придумаю задачи. Они же сделают быстрее и больше, чем стандартная команда из 1000 программистов.
Ну, почему же. В статье об этом упоминается. Именно когда "золотая шестеренка" уже хочет стать "партнером" многие вылеты и случаются. Амбициозные цели и задачи могут сработать, но только для стартапов и маленьких команд. В остальных случаях будет все то же самое.
Трагикомедия ситуации в том, что у «золотой шестерёнки» практически никогда не получается занять стабильное место в иерархии. Позицию senior developer такой человек проскочит, техлидом не станет, так как умеет руководить людьми. Системным аналитиком тоже долго не сможет быть, так как умеет руководить людьми и работать руками. Архитектором может стать, но это будет необычный архитектор. Во-первых, он заставит понимать всех разработчиков почему стрелочки именно такие и другими не будут. Во-вторых, не будет давать от них отклоняться. В-третьих, башня из слоновой кости покроется пылью, так как он её будет очень редко посещать. Условно говоря, он быстро всем надоест, так как победил в себе лень и захочет победить лень в других. Такой человек со временем может стать CTO, возглавить департамент R&D, стать совладельцем в текущем бизнесе, стать совладельцем в новом бизнесе. То есть занять позицию, которая взаимодействует с внешним миром напрямую. Потенциала у внешнего мира много больше, чем у любого из людей. Только это все произойдёт не сразу, до этого придётся дорасти и приложить много усилий.
таНу, если мы на пару порядков поднимем уровень "высококвалифицированного разработчика" и "средненького менеджера", то где-то и в общих чертах ситуация будет похожа.
А так, высококвалифицированные разработчики обычно не доставляют проблем. За счет того, что не являются специалистами широкого профиля и не могут охватить все процессы целиком.
Их создает наш UI/UX-специалист. :о)
Просто некоторая граница на освоение языка (можно же изучением заниматься бесконечно), многие справляются за неделю. Все же PHP и Python во многом похожи. Не в плане того, что у них под капотом, а в плане реального применения.
Ну, в какой-то момент мы начали писать на нем слишком сложную логику. А Lua неудобно отлаживать и как язык он, конечно, простой, но несколько обрезанный. Потом перенесли сложную логику на python.
А вот об активном применении Lua в робототехнике и для микроконтроллеров я даже как-то не знал. Там его «легковесность» вместе с интерпретируемостью действительно огромный плюс.
Вот я сейчас посмотрел вилку зарплат (по вакансиям и резюме) по Новосибирску на HH.ru, для разработчика Delphi это 40-50 тысяч рублей. Вакансий мало, резюме - много.
Если человек совсем ничего не понимает, то его век в IT будет недолгим. Беда наступает, когда человек зависает между поверхностными знаниями и глубоким пониманием. То есть он вроде и может, но через постоянное усилие над собой. Вот это усилие и выжигает людей, медленно, лет за 15-20.
В науке все где-то так же, но там немного денег, такого притока желающих нет. Поэтому остаются в основном те, кто может и любит свою работу. Плюс процесс защиты кандидатской и докторской очень долгие. Вот где-то к 40 годам человек будет считаться состоявшимся специалистом. Лишних людей почти не остается.
Рисует наш UI/UX специалист, передам ей ваше спасибо. :о)
Нет, это сотка, она ежегодно проходит в Новосибирске.
Наверное, вы все же разработчик. :о)
Из написанного вами у меня только один вопрос возник, почему Lua? Это ж еще тот «мопед», иначе и не скажешь. Самое ужасное то, что я сам его знаю и мы реализовали не нем высоконагруженный сервис. Сервисом мы гордимся (архитектура красивая, скорость работы высокая, надежность уникальная), а вот то, что он сделан на Lua никому не говорим.
А так, время идет, а проблемы остаются похожими друг на друга. Но для этого нужно достигнуть некоторого профессионализма в области, на это способны далеко не все.
В реальности у меня очень широкий круг общения, который захватывает большой спектр технологий.
Можно сказать, что на Fortran сейчас пишут всё меньше и меньше, даже в научной среде, которая занимается численным моделированием. Даже оттуда его вытесняет С++.
Для меня очень сомнительно, что на Prolog сейчас идет много разработок. Дело в том, что это отдельная парадигма программирования, которая имеет очень узкую нишу применения. Возможно, его еще где-то используют, но это должны быть специфичные задачи.
Если коснуться PL SQL, то могу сказать что его сейчас его все так же активно используют. Иногда слишком активно, за что приходится очень больно бить по рукам. Размещать слишком много бизнес-логики в базе данных - плохая идея и известными последствиями. Тем не менее, язык все еще востребован, причем, как для диалекта Oracle, так и для диалекта PostgreSQL.
А вот с Delfi все несколько сложнее. Нам приходилось консультировать компанию, которая реализовала внутри себя аналог 1С на Delfi, после чего людям захотелось упаковать это, как продукт. При таких инициативах всегда проводится анализ доступности разработчиков на требуемых языках. Нет программисты на Delfi есть, но стоят они меньше джуна на Python. Реалии рынка где-то такие.
Странно слышать от человека, который пишет про SPSS (ничуть не фу) и (кажется) понимает, что такое ML с точки зрения математики, о том, что он только-только собирается зайти в ойти.
Скорее всего, у вас уже есть фундаментальные знания и системное мышление. Остается только немного актуализировать знания по технологиям дата-сатанизма и найти нормальную команду (не стартап). В стартапе может не получиться с горящими глазами делать какие-нибудь глупости, а в серьезной компании будут интересные задачи.
Наверное, я в своей жизни провел уже несколько тысяч технических собеседований программистам. Я видел много людей, которые не смогли «добежать», из-за чего очень сильно отстали от отрасли. Здесь я с вами согласиться не могу.
А вот с тем, что многое из современных тенденций родом из 80-90 годов, я полностью согласен. Что-то является воплощением идей того времени, что-то просто повтором старого и хорошо забытого, но на новом уровне.
Но вот есть одна беда. Людей, которые реально понимают, как оно работает под капотом и почему оно работает именно так, очень немного. Да, эти люди будут востребованы «всегда». Только их процент от общего числа «программистов» сейчас очень небольшой. Собственно об этом я и написал.
К слову говоря, мы не считаем месенджеры какой-то сложной задачей. Если бы мне предложили реализовывать его на базе С++, я бы такое запретил. Скорость разработки медленная, поддерживается плохо, преимуществ перед web-сокетами нет никаких. Ей богу, у нас месенджер в одного реализует фронтендер, просто взяв Flutter для клиентского приложения и Node.js для сервера.
Кроме того, стоит заметить, что у Flutter нет никаких проблем в работе с камерой, а что такое выжимать производительность для нейросетей я себе очень плохо представляю. Может быть, просто нейросеть нормальную взять? И обучаете вы её, наверное, не на телефоне?
Нет, у меня были коллеги, которые извращались с С++ на мобильных устройствах, но это были задачи из разряда запуска навигационной программы на китайском убогом планшете, из-за этого приходилось вписываться в те ресурсы, что есть.
Кстати, первой из задач, что мы реализовали с использованием Flutter, это географически распределенная система на нестабильных каналах связи для пассажиров речных круизов. Мобильное приложение позволяло людям просматривать экскурсии, использовать аудиогид, смотреть контент из бортовой мадиа-библиотеки, делать заказы услуг, доступных на борту. Конечно, приложению приходилось работать с бортовым сервером, который при наличии связи соединялся с центральным сервером. В нашей стране мобильный интернет много где недоступен. Для нас это несложный проект.
Когда дело дойдет до реальных проектов, скорее всего, вы серьезно проиграете по производительности. По производительности (скорости) разработки, по скорости внесения изменений и раскатки обновлений. И скорости работы приложения, не потому что С++ медленный язык либо ему не хватает каких-то средств, просто есть еще архитектурный уровень, который тоже очень не простой.
P.S.
Я бы никогда не стал отождествлять потоки и процессы, это как путать работу над общим и раздельным полем памяти.
Интересный инструмент, спасибо. Но дело даже не в деревьях. Если взять иерархию, которая выстраивается на контроле, то она свободно формирует граф с циклами. Они нужны, чтобы предотвратить отсечение головы иерархии от информации о том, что происходит снизу.
Дело в том, что одновременно существуют несколько иерархий. Например, под юридической структурой, может находиться функциональная и корпоративная структура. На каждом слое свой граф, своя RACI-матрица, свои выходы на иные слои.
Причём, каждый слой, на самом деле, двойной. На одной его стороне иерархия на контроле, на другой стороне иерархия на общей цели. Шести измерений тут не хватит, если честно.
Но для описания формальных связей RACI-матрица выглядит очень неплохо. Особенно за счёт разделения «отвечает» на «делает» и «принимает».
Была бы топом, не вылетала бы. )
Ну, у менеджеров и руководителей тоже шансов немного. Только у топ-менеджеров, если только.
В любой большой и технологичной. Любая большая компания это какая-то из вариаций ада, от бюрократичного ада до хаотичного ада. Мне больше нравился хаотичный. Ещё имейте в виду, что например на VC вчера была статья о найме топ-менджеров. В комментах было прямо написано, что выращивать руководящие кадры из линейных исполнителей нельзя. То есть в бюрократическом аду готовьтесь к стеклянным потолкам. Если вы не знаете, как их обходить, то лучше с ними не сталкиваться. То есть просто пойти в большую Ит-компанию у которой внутри большой бардак.
В той книжке было много других интересных мыслей. У нас есть направление «бодишопа», но там все сильно по другому. И это последнее место, где бы я стал искать таланты.
Зачем может потребоваться много талантов. Только чтобы сделать что-то грандиозное, не иначе. ))
Ну и нужно ещё помнить, что «много» каждый понимает по своему. Например, для компании из 50 талантов я просто не придумаю задачи. Они же сделают быстрее и больше, чем стандартная команда из 1000 программистов.
Ну, почему же. В статье об этом упоминается. Именно когда "золотая шестеренка" уже хочет стать "партнером" многие вылеты и случаются. Амбициозные цели и задачи могут сработать, но только для стартапов и маленьких команд. В остальных случаях будет все то же самое.
Трагикомедия ситуации в том, что у «золотой шестерёнки» практически никогда не получается занять стабильное место в иерархии. Позицию senior developer такой человек проскочит, техлидом не станет, так как умеет руководить людьми. Системным аналитиком тоже долго не сможет быть, так как умеет руководить людьми и работать руками.
Архитектором может стать, но это будет необычный архитектор. Во-первых, он заставит понимать всех разработчиков почему стрелочки именно такие и другими не будут. Во-вторых, не будет давать от них отклоняться. В-третьих, башня из слоновой кости покроется пылью, так как он её будет очень редко посещать. Условно говоря, он быстро всем надоест, так как победил в себе лень и захочет победить лень в других.
Такой человек со временем может стать CTO, возглавить департамент R&D, стать совладельцем в текущем бизнесе, стать совладельцем в новом бизнесе. То есть занять позицию, которая взаимодействует с внешним миром напрямую. Потенциала у внешнего мира много больше, чем у любого из людей.
Только это все произойдёт не сразу, до этого придётся дорасти и приложить много усилий.
таНу, если мы на пару порядков поднимем уровень "высококвалифицированного разработчика" и "средненького менеджера", то где-то и в общих чертах ситуация будет похожа.
А так, высококвалифицированные разработчики обычно не доставляют проблем. За счет того, что не являются специалистами широкого профиля и не могут охватить все процессы целиком.