Миграция между языками и технологиями в IT

Всем привет!

Стало интересно как часто в жизни простого украинского разработчика происходит смена сферы деятельности. Например, работал в web, потом перешел на C++ или куда-нибудь еще. Бывает такое вообще? Или первый опыт становится клеймом на всю жизнь? Я имею ввиду не хэлоуворды конечно, а серьезный опыт.

Я, если что, из соседней с IT сферы, поэтому своего такого опыта нет.

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

C++ ŽŽŽŽŽŽŽ> Delphi > C# Это что касается языков.
Ну а С, Java, F# - были потыканы палочкой в свободное время
FireBird > MySQL > Oracle > SQL Server — так сменялись базы на моём пути
В начале пути попал в интересную нишу- промышленное моделирование(Математика, Геометрия, генерация 3D моделей из облаков точек, расчет напряжений в материалах, толщинометрия, виброметрия, прогнозирование разрушения труб, двигателей, котлов и тд) Всё это было жутко интересно- но по деньгам сильно проигрывало попсе веб разработке.

Много раз подходил к Питону- ну похоже я еще не достиг дзена программирования- не нравится мне не сиподобный синтаксис.

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

та я бы с удовольствием на GUI приложениях остался.
в веб уходят по двум причинам
1. нравится
2. а остальные сегменты медленно, но уверенно сужаются, маргинализируются.

ИЛИ вымирают, да.

некоторые дойдут до какого-то уровня маргинальности и будут «вечны».

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

Все в веб уходят.
 и бегут от embedded подальше

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

Я пока никуда не убежал :) На счет «сложно точно определить», я имел ввиду, что там есть большой диапазон задач. Кто-то пишет код на python для одноплатника для заказчика с запада, а кто-то на ассемблере для маленького микроконтроллера для автоматизации на украинском заводе. И все это эмбедед.

Еще недавно, каких-то 20 лет назад, полноценные операционки были на процессорах, которые слабее нынешних самых примитивных микроконтроллеров :)

нет, все таки встаиваемая система должна быть частью какого-то объекта, которым она управляет и решать специализированную задачу

если этот PC прикручен к спине этого робота, то формально — да, эмбедед.

Так вы опять один из главных критериев эмбедеда выбросили, так не честно :D Система должна быть специализированной, а если игруху поставили, то можно и кино посмотреть, следовательно комп становится общего назначения. Вот ЧПУ или ПЛК, по вашему, это эмбеддед или нет?

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

Вот и получается, что понятие эмбедеда очень размытое, у всех свои подходы и видение ситуации. Не то, что, к примеру, frontend, сказал и все поняли о чем речь :)

Например, я после перехода в IOS, на позицию джуна сходу получил зп фактически такую же, какая была у меня в бытность embedded-разработчиком с более менее приемлемым опытом. Это было ключевым фактором, который сподвиг меня сменить специализацию))

не можу погодитись... просто можливо компанії починають більше спеціалізуватись...
в нас Embedded процвітає)

так, сам деякий час був там)
перейшов у автоматизацію тестування того ж таки

Embedded

На самом деле веб — это больше чем веб. Этим термином злоупотребляют, иногда имея в виду веб-окружение (в противовес десктопу), иногда — веб-технологию (в противовес «устаревшим» c++/c#/java), а иногда и просто не к месту.

Интересное видео о будущем технологий:
Developer Roundtable: What does HTML5’s future lo...: youtu.be/FlRZZB3NoBI

C + asm -> FoxPro -> Borland Pascal + asm(gamedev) -> 1C -> Java EE -> web (php + троица, хотя все больше заглядываюсь на мир Ruby) — общее время пути — 20+ лет

Перешел из embedded (Си, ассемблер) в IOS разработку, до сих пор немного скучаю за первой специализацией, но точно не жалею

C++ (embedded) -> Python (enterprise) -> JS/Rails (web)

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

С повышением зп. Я индиффирентно отношусь к титулам.

наверное в эмбеддеде просто мало платили :D

А это не другая область. Область та же — программирование.
Каждый увлеченный программист должен изучать по одному языку программирования в год. А предметная область уникальна в каждом проекте.

Боюсь года не достаточно чтобы выучить яп.

Это смотря что вы вкладываете в понятие «яп». Если вы в это понятие включаете стандартные библиотеки — то да, недостаточно. Но их никто и не учит.

без стандартных библиотек, а также стандартных практик и подходов, это называеться не «выучить яп», а так, баловство...

Где я написал «без практик и подходов»?

А если человек гордится знанием наизусть API стандартных библиотек одного языка — флаг ему в руки. Мне достаточно знать как сформулировать запрос в google.

Насчет чисто всех апи — тут я кагбэ согласен.
Тем не мение некоторый базис АПИ нужно знать.
Ну например сидит такой себе сишник «область — это программирование», и на джаве, чутку погуглив, на полном серьезе пишет используя масивы, и сортирует пузырьком... прям хочеться взять и у****.

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

Если брать коммерческий опыт, то C# (desktop) -> ASP.NET MVC -> Perl.

бывает конечно. начинал с 1С автоматизации, потом C++ и C#, последние несколько лет Java.
вообще не важно на чем программировать, если есть базовые знания (алгоритмика, архитектура, ООП, теория БД) + опыт работы в различных предметных областях. технологии в программировании меняются раз в несколько лет, а опыт остается и приумножается.
вообще главное не язык а наличие интересных задач, и востребованность на рынке труда и следовательно зарплата :-) это причина почему я перешел в Java

программист вообще должен уметь меняться и приспосабливаться. это основа нашего выживания.

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

Например, работал в web, потом перешел на C++ или куда-нибудь еще. Бывает такое вообще?
В теории возможно абсолютно всё. На практике, имхо, первые пару лет у веб-программиста будет получаться веб-приложение даже на C++. Допустим я знаю как реализовывается MVC в PHP-фреймворках и не могу разобраться с MVC в Java-приложении. Мне непонятно как разделять контроллеры с моделями и видами, что в случае ява-приложения есть контроллер/вид/модель и т.д. Это не значит что я не могу написать приложения на Java. Но это значит, что я не могу написать приложение профессионально, которое сможет поддерживать другой разработчик. Я молчу уже о незнании кучи разных технологий и библиотек.
Допустим я знаю как реализовывается MVC в PHP-фреймворках и не могу разобраться с MVC в Java-приложении.
боюсь тут не в миграции проблема, а заскорузлости сознания. Надо срочно что-то делать!

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

сколько во вашему функций пользуется в среднем проекте ?

какие сотни, там всего сотня функций.

а еще предметную область иногда нужно знать или нет?

А то кто не знает берётся, через год фэйлит, но деньги потрачены, зарплаты заплачены всем хорошо.
Повезло Вам с наивными заказчиками. А если попадутся пацаны реальные? Тазик с цементом приволокут?
В IT таких не бывает.
Если им сайт сделать надо будет?
Зная область, ты знаешь, что можно, а что нельзя сделать.
пример не сложно привести?

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

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

Определение удовлетворенности сервисом клиентом по телефону разговору
" превращается в перезвон и опросник с помощью автоменю, а
Распознавание слитной речи, независимое от диктора в любом окружении — еще не решена в мире.
в тысячный отдел «субтитреров» :)
ну, я к тому, что примеры — то когда клиент ставит задачи, а не описывает проблемы. потому что не доверяет исполнителям или переоценивает собственные возможности. согласны?
2. Идентификация диктора за 2 месяца.
Если кандидатов мало, почему бы и нет? Наивный байесовский классификатор на кого-нибудь да укажет. Вопрос, как всегда, в качестве.
по сути не будет работать
Совсем не обязательно. Реальный проект — это компромисс между принципиально достижимым уровнем качества и доступными ресурсами — деньгами, сроками, наличием базовых разработок и тд. Два месяца для прикладника на прототип конкретизированной задачи классификации звучит не так уж фантастично c учетом использования готовых университетских алгоритмов и вычислительных сред типа R. С другой стороны, описанная тобой ситуация существовала всегда и на всех уровнях. Сетовать на нее все равно, что жаловаться на закон всемирного тяготения. Те же проблемы были и у средневекового оружейника, и у любого добросовестного исследователя, результаты которого никак не поспевают за обещаниями коллег-чудотворцев. Число нулей в суммах, которыми оперируют, может быть различным, но базовый сценарий воспроизводится постоянно.

зависит от величины проекта. На проекте может быть команда бизнес аналистов которые документируют требования и переводят требования с языка «проводка на 343 счет» в что то типа «форма ввода для дробного числа, по нажатию кнопки „проводка“ запрос в базу с апдейтом таблицы 343, таблицы все проводки, таблицы логов»

Какоето жуткое заблуждение :-)

один старый джавист после перехода на пайтон на полном серьезе писал свою орм, считая что в пайтоне она если и есть, то точно кривая

При нормальной базе (алгоритмы и опыт) вы можете на любом языке писать серьезный код через месяц.
Это реальность lurkmore.to/Индус

ну покажи кусок своего кода, строк на 40. Мы посмотрим кто из нас индус.

Давайте же вывалим сюда свои коды и посмотрим у кого сантиметров-то больше!

К сожалению мой лучший код под NDA, пока не хватает сил вести что-то дельное на гитхабе для себя. Но уже хватает опыта говорить, что врядли у меня через месяц получится серьезный код на другом ЯП, а не копипаста или helloworld (MVC).

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

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

Согласен с утверждением про базу.

Я б ещё отметил знание такой интересной фигни под названием «модели данных» и «паттерны проектирования».

Про модели: в каждом языке используется свой немного разный набор абстракций. Например, в PHP есть «array» — это такой универсальный объект, который одновременно double linked list и hashmap. Но он «небыстрый», как вы понимаете. Для ПХП-быдлокодера вроде меня знать различия между ними полезно конечно, но некритично, ибо на быстродействие такие вещи влияют редко. А вот в Java придётся это учить. А в C++ ещё и самому иногда строить (насколько я помню).

Про паттерны: то, что придумал Gang of Four для Явы, не везде подходит для PHP, зато у нас тут есть MVC, HMVC, PGR и ещё много разных радостей. Что там в сях сейчас, не знаю, самому интересно. Но какие-то аналоги наверняка есть. И без их знания понимание сложной архитектуры превращается в ад.

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

задача должна достичь определенной величины что бы появился смысл решать ее через ООП и паттерны.
Та не, тут другая зависимость. Если не решать задачу через патерны, она не сможет достичь определённой величины.

Это такая же утопия, как написать Facebook на Ассемблере.

Facebook на Ассемблере
і паттерни не мають нічого спільного...
Теоретично Facebook міг бути написаний і без них (можливо так воно і є)...
Так само можна реалізувати ООП на Асмі, але це вже зовсім інша історія)...
задача должна достичь определенной величины что бы появился смысл решать ее через ООП и паттерны.
+1, бо якщо використовувати паттерни аби вивести “Hello world”, то це не рентабельно...

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

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

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

В этом основная идея. Невозможно создать Facebook на Ассемблер. Нужно сначала на Асме написать C, на C написать PHP, после чего браться за Facebook. Иначе получится не поддерживаемый кусок дерьма (если ваще получится).

Собственно, изначальный мой посыл в том, что если не использовать паттерны (читай высокоуровневые блоки-конструкции), то будет невозможно вырасти выше определённой величины.

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

ООП и паттерны это в основном не про «переиспользовать кусок кода». «Переиспользовать кусок кода» можна и процедурным способом.

+1, бо якщо використовувати паттерни аби вивести “Hello world”, то це не рентабельно...

Топікстартер одразу зауважив,

Я имею ввиду не хэлоуворды конечно, а серьезный опыт.

тому я й написав про паттерни.

Також, часто фреймворки використовують паттерни усерединi.

Хз, мне не так давно довелось поковырять (по просьбе) студенческую подделку на пыхе для внутреннего использования.
Ну там хранение, листинг, редакторование и запись заявок и чегото там в базу.
Там пару файлов классической чистой пхпешной лапши на > 500 строк каждый с хаотичной массой пхп, хтмля и скля, переходящих друг в другу.
Моей первой фразой было «Б***ь, что это?».
Уж лучче МВЦ, дао, и прочие «паттерны» на «простой задаче», чем подобная лапша.

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

В PHP, а именно в Yii есть такая штука как Behaviour. Это когда вы создали экземпляр класса A, а потом в рантайме одной строчкой добавили ему все методы из класса B. Как множественное наследование, только в рантайм и только для одного объекта. Это тоже паттерн, кмк. Но я не уверен, что в Java такое можно делать так же просто.

PHP4
Штаааа? Посравнивайте тогда ещё с Java 1.0

От того что у вас в руках только PHP4 или только старая Java, у вас бизнес-область стала проще? Имхо, если у вас у клиента сложная бизнес-модель, придётся строить абстракции и как-то их реализовывать теми средствами, что у вас есть, иначе вы просто не сделаете продукт и нагенерите море спагетти-кода :) Поэтому даже тогда что-то пытались делать с переменным успехом.

есть ли в современной джаве аналог Yii-шных behaviors
аннотации ж.
кроме того, все, что я смог придумать под реализацию с помощью
Yii-шных behaviors
или нативных PHP traits, вполне можно реализовать композицией.
Динамичность всё-таки накладывает оттенок, имхо.
ага, делает некоторые паттерны overcomplicated: как если заменить иерархию классов-стратегий на обычный маппинг. или создание объекта по имени класса вместо фабрик.
ага, делает некоторые паттерны overcomplicated:
Ага, причём человек, который понимает принцип «создания объекта по имени класса», скорее всего поймёт и абстрактные фабрики в джаве. И наоборот. Но понять и изучить его всё равно надо.

это не сравнение, а иллюстрация тезиса, что применимость конкректных паттернов отталкивается от возможностей языка.

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

Паттерн — это абстрактное описание типового решения. Оно не имеет ничего общего с конкретной реализацией, а тем более, с языком. Это подсказки, как поступать, чтобы иметь минимум проблем в будущем. Странно, что некоторые относятся к ним, как с куску кода на ПХП 4.

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

На самом деле имеет.
Например паттерн «интерфейс» встроен в джаву на уровне языка, и не нуждаеться в дополнительных объяснениях. В це++ «интерфейсов» нет, нужно для подобного использовать класы. Что не мешает ушлым программистам туда еще и реализации методов повставлять.
Паттерн «иммутейбл» на какойнить скале реализуеться легко и просто, на джаве нужно много много бойлерплейта, на це++ впринципе тяжело реализовать. И так далее и тому подобное.

Ну так в том то и разница! Паттерн один, а реализуют его везде по-разному. Это уже реализация, а не абстракция, т.е. более нижний уровень. Сам же патерн — абстракция, которая даёт типовое решение типовой задачи проектирования.

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

Списки, массивы, деревья, хэши. Необходимый минимум.

Delphi -> FoxPro -> VB -> PHP -> JS
Это за 12 лет.

Практически аналогично, правда на первых двух до работы так и не дошёл — баловался тем, что логические компьютерные игрушки писал :)

А как же потеря в зарплате при переходе, пока переучишься, вряд ли ж получается на ту же позицию попасть сразу?

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

Уже вижу миграцию верстальщика в Linux Kernel hell :D :D

думаю, що не у всіх верстальщиків Windows чи Mac)

Вы меня в верстальщиках заподозрили? :D Мне вот как раз такие случаи интересны —

верстальщика в Linux Kernel hell
Такое бывает?

Нет, это апогей какого-то *здеца :)

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

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

Когда появился iPhoneOS на него можно было перейти перейти без потерь, т. к. спецов еще не было. Когда появился Android, на него можно было перейти без потерь, т. к. спецов таких еще не было. Также иногда попадаются смешанные проекты (например, Java и C++ via JNI, к слову, они есть не только на Android).

Иногда получается даже с повышением.

Прошел дорожку C# (desktop) —> PHP(backend) —> C#(backend) —> Javascript (frontend) за 6 лет.

Началось с мобайл дева, им же и продолжается.
J2ME->P2K(j2me based платформа моторолы)->Blackberry->Android
Иногда думаю расширить специализацию Windows Phone каким, но на него катастрофически нет заказов, да и сама приятность разработки очень и очень низка.
Just for fun в свободное время были всякие лисповые языки типа Racket.

C#->VB6+SQL(MS Reporting Services)->J2ME (BlackBerry)->Java (Android)->Objective C (iOS)
як на мене, перехід з однієї технології на іншу найбільш поширений саме в IT, і це зрозуміло: програміст (чи тестер) має певні загальні навички, абстраговані від технологій (алгоритми, ООП, патерни, UML, revision-control, мікроменеджмент) — і це його найцінніший багаж умінь. А технології в IT приходять та відходять досить швидко.

Delphi (пол года) -> FoxPro (6 лет) -> PHP (год) -> 1C (2 года)
Принципиальной разницы не заметила.
Идеология везде одна и та же.
Переключение на полноценную работу на другой язык грубо говоря год. Из них 2 недели — изучение синтаксиса языка, остальное время — наработка опыта с основными фреймворками.

а что сподвигло перейти с php на 1С?

Я выбирала область, в которой хочу работать, и задачи, которые хочу решать.
Под них уже язык программирования.
На 1С программирование гораздо более высокоуровневое. Не нужно так подробно, как в PHP, описывать все мельчайшие операции. Т.е. больше внимания логике работы алгоритмов, меньше внимания низкоуровневым операциям.
Реально PHP у меня не был основным направлением работы. Несколько лет занималась сайтами, SEO. Т.е. с PHP работала на уровне исправления ошибок и небольших доработок CMS Joomla и osCommerse. Плюс писала с нуля несколько простейших сайтов на PHP + MySQL. В общем PHP банально «не зацепил», не хотелось в нем развиваться дальше.

Perl->PHP->C#->PHP->C#->PHP->Python->PHP
А вообще, уже столько раз обсасывали вопрос миграции — ну это ж такое дело — наживное :)

В мене виглядало десь так:
HTML -> Pascal -> VB6 -> C -> Java -> Embedded C -> PHP, JS -> Python -> Qt

Бывает такое вообще?
угу ;)

Починав з бейсіка, зараз на пихі пишу)))

Foxbase -> Access -> Foxpro -> Delphi -> Perl + PHP — > 1C -> Java (Android) + Objective C ( iOS)

Как-то так у меня получилось c 1996

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

С другой стороны есть примеры людей успешно устроивших свои предметные скилы.

Я подозреваю, что и на вашем рынке должно что-то такое быть. Может как говорится у соседа всегда небо зеленее.

Меня вот тоже в Минск зачем-то зовут активно.

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

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

Ну, например, мое знакомство с ИТ началось еще с ZX Spectrum. Я думаю, вполне очевидно что мигрировал я не один раз. Миграция — вполне естественный и нормальный процесс.

100%.
Я еще с МК61 начал %)
Если кратко по языкам — Mk61 (коды, середина 80х) -> Asm (конец 80х-начало 90х, еще немного в начале 200х) -> Pascal/Delphi (начало 90х) -> C/C++ (90е — начало 2000х, включая Borland/Turbo/Builder/MSVC) -> management (последние 5-10 лет) (и Network administration как отвлечение от основной деятельности %). По технологиям — одной строкой не выйдет. Что будет через 5 лет? Кто знает? Может отпущу бороду, куплю бубен и отвлечение станет основным занятием %))). А может опять кодить будем. Или... да мало ли — главное — движение.
ПС: а если не ИТ — то сейчас вообще вспомнил, что в начале/середине 80-х был радиолюбетелем — сейчас упал в детство и начал опять ковыряться %) Цикличность в природе.

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

Ну вы же мк61 и спектрумом деньги наверное не зарабатывали, так что это не совсем то)

Я Вектор-06Ц деньги зарабатывал %) Это практически тот же период, что и Спектрум.

А при чем тут зарабатывание денег?

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

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

Java Mobile Edition > Java EE > android (тоже java). Все имеет какое то отношение друг к другу, но java поднадоела и хотелось бы поменять. С радостью пошел бы на data mining, но я тупой немного поэтому скорее всего если и буду менять то на javascript fullstack.

Clipper -> C (микроконтроллеры) -> PHP -> Delphi + PL/SQL -> Java

А переход от микроконтроллеров к PHP болезненно прошел или нормально?

Не помню, это было очень давно, но раз в памяти не отложилось каких то болезненных воспоминаний/шрамов и т.п., то подозреваю что переход прошел нормально. :)

Работал в веб — php и asp, потом перешел на pl-sql . в паралель халтурил Delphi и c++
потом перешел в веб Java, там и застрял крайние лет 10

Java всем устраивает или молодость прошла и ничего менять уже не хочется?

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

работаю в англосфере в финансовой сфере- жава себя чуствует очень уверенно и явно лидирует

всегда подозревал что все кто программирует на Java, делают это ради денег :-))))

если кто то говорит что занимается JEE по любви — я бы его привинтивно закрывал в дурку

тут скорее козел самого Люцефера любит jee программиста во все дыхательно пихательные

И чем вам JEE так не угодил? Как по мне, так отличнейший инструмент, когда вам надо написать что-то большое.

кто видел интерпрайз стек IBM в цирке не смеется

Ну кроме дремучего стека от ИБМ и прочих подобных «ужасов», вполне есть жбос 7(8) с жее6(7), достаточно легковесны, применимы и полезны.

да я тут писал про свой опыт с ee6/7
на бумаге — фсе как спринг хайбернейт
в реале — почти так но регулярно какие то мелочи не сделаны или что то глючит и это пофиксят только в ee7 потому что f#ck you dear EE user.
но да- применимо и полезно, толко руки мыть перед едой надо

какие то мелочи не сделаны или что то глючит и это пофиксят только в ee7 потому что f#ck you dear EE user.

Помойму подобное применимо к over 50% жаба фреимворков, а не только к ЕЕ.

О нет, исключительно ради идеи. Но если за нее еще и деньги дают, не выбрасывать же их, в самом деле.

А как с интересностью проектов или только

Гарантия стабильной, высокооплачиваемой работы, уверенности в обозримом будущем.
?

Для тех, кто любит бэекнд, проекты — супер!

Да и вообще, вакансий так много, что можно выбрать проект на любой вкус и цвет.

Підписатись на коментарі