Comments 67
Я бы в дворники пошёл,
Пусть меня научат
А дальше оказывается двор то мести нужно, и в холод, и в грязь, и в снег по макушку. И тяжело это.
Всегда было интересно, вот эти вот профессиональные "учителя разработки и вхождения в IT" сами когда-нибудь работали в IT и представляют что это такое в целом? Потому что ни один из них никогда не пишет о своем профессиональном пути в IT, только о пути "обучатора".
Ну потому что тема статьи не о моей автобиографии, а о советах новичкам. А обо мне можете у меня в профиле по ссылкам на телеграмм и линкедин почитать, если очень интересно )
Но ведь хочется понять компетенцию того, кто даёт советы. Так-то, я тоже могу подавать советов по астрофизике, за советы же не бьют. Но мои знания в этой области — видосики на ютубе, пусть и в течение пары лет.
Вы знаете да, почитал. И, как и предполагал, промышленного опыта разработки я там не нашел. Хотя вы вроде как учите и питону, и в целом бэкенд-разработке.
Это как если бы инструктор по вождению авто сам никогда не водил автомобиль.
Почему-то в голове всплывает наименование «инфоцыгане».
@Morlena106, у вас на сайте досадные грамматические ошибки.
(с) тренер не играет
Если вам хочется "забросить изучение %WHATEVER%", это сигнал что, пожалуй, вам туда и не надо.
многие школьники хотят забросить школу\институт и гулять, играть и отдыхать - это сигнал, что им туда всем не надо?
Ну, в целом, да, образоваться удаётся не каждому. Некоторые через силу отпосещают школу, потом пишут в интернетах про лунный заговор, заговор учёных, фундаментальную силу отталкивания.
"Не надо", думаю, тут понимается не в смысле "нет потребности", а "всё равно ничего не получится". Мне объективно надо пропылесосить, но я лучше почитаю книгу, потому что не чувствую желания пылесосить прямо сейчас.
"всё равно ничего не получится"
This! Больше заработаешь будучи ТОП и не в особо денежной сфере, чем посредственным айтишником.
Почему вы думаете, что тот, кто стал так себе айтишником мог бы стать ТОПом в какой-то другой сфере?
Ну в разных областях деятельности нужны разные способности. Если у человека есть трудолюбие и целеустремленность, то он скорее всего сможет найти себе отрасль, где добьется успеха. И весьма возможно, что вне айти добьется большего.
Среди моих знакомых самого большого успеха добились не айтишники. Один дослужился в РЖД до реально высокой должности. Другой стал большой шишкой в энергетике. Оба без блата и без родственных связей. Просто за счёт жесткого трудолюбия (ну и наверное обладали определенной гибкостью и пониманием где перед кем надо выслужиться, ну на высоких должностях это в любой сфере это имеет место быть, в том числе и в айти).
А ещё бывший одноклассник открыл свою строительную фирму. Тоже немало. Конечно у него не ПИК и не Самолет, но коттеджи и небольшие магазины строит.
И вот смотрю я на их карьеру, сравниваю со своей айтишной и на ум приходит строчка из песни "А тому ли я дала?.."
Почему вы думаете, что тот, кто стал так себе айтишником мог бы стать ТОПом в какой-то другой сфере?
Можно вообще нигде ТОП не стать. Но айти это вам что, default job, какой-то центр социальной помощи чтоли?
Если мама отдала сына на шахматы, и он стал чемпионом мира, то сын будет жить с мамой.
Если мама отдала сына на футбол, и он стал чемпионом мира, то мама будет жить с сыном.
Не моё, но суть, думаю, ясна: идти лучше туда, где есть деньги
Предлагаете отдать шахматиста в футбол?
Мама Перельмана сейчас мудро улыбается
Это не так работает.
Шахматы и футбол - это "экстримистан". Там есть деньги. Но они будут у 0...001% людей. Остальные на этом ничего не заработают.
И есть "медиокристан". Тут тоже есть деньги. По сути любая работа на дядю (то же программирование, хотя оно может переместиться в экстримистан при определенных условиях). Тут вы заработаете практически точно, но будет предел по максимальному доходу.
Есть вариант похуже. Я недавно спорил с серьезным челом, который нашел интересные аргументы и формулы по теории плоской земли. И это был спор на уровне 1-2 курса физфака. Так что склонность к теориям заговора не зависит от знаний
Асфальт тоже кто-то класть должен. Заниматься этим после института как-то даже обидно, а после 9 классов вполне себе норм. Я даже после первого курса летом на кирпичном заводе подрабатывал и не считал это каким-то позором. А вот потом как возомнил себя инженером, как ощутил прелести работы за валюту, вот тогда понеслась другая жизнь. Но это не делает прошлого меня каким-то второсортным, и я до сих пор отношусь с уважением к любым людям, добросовестно делающим свою работу вне зависимости от того, что это за работа, какое у них образование, и сколько за это платят.
А можно узнать какие знания высшей математики вам нужны в it? Ну просто для понимания.
В айти не нужны знания высшей математики. В айти нужны знания предметной области. Бухучёт, складской учёт, делопроизводство, если вы занимаетесь автоматизацией этой деятельности. Схемотехника и знание аппаратных платформ для ембеддера. Линейная алгебра и прочий матан, наконец, если вы занимаетесь скажем геймдевом или моделированием. По-хорошему, в айти хорошо зарабатывают за совмещение этих должностей. 100К за спеца в банковских АБС, плюс 100К за жава-программиста. А просто кодер это 100К и меньше, нынче их как грязи, и как таковые без знаний предметной области они особо и не нужны.
По вашему простой программист, который без всех вами перечисленных нюансов нормально зарабатывать не сможет? Ну тот который там архитектуру красиво разделяет, но ни в матан (линейную алгебру же в школе проходят, ну как минимум вектора и системы уравнений), ни в бух учёт не лезет. Странно это звучит, если честно. Потому что сервер можно писать без глубокого понимания складского порядка, а прося непосредственных работников проконсультировать. И, о боже, даже в каких-то особых специфичных вопросах, алгоритм могут запросить на стороне, например в университете. А программист МК может вообще в схемотехнику фильтров не лезть.
Так что можно развернуть вашу мысль про специфические знания?
По вашему простой программист, который без всех вами перечисленных нюансов нормально зарабатывать не сможет?
Простой программист порой не замечает как становится экспертом лучше всех этих приставленных аналитиков. Потому что зачустую проще самому разобраться что к чему там на самом деле и сразу сделать правильно.
Ну иногда да, а иногда просто использует сдк и ничего не знает о внутрянке. Те же платежные шлюзы свое сдк дают, о платежах не известно ничего, но задача выполнена. Так что это как минимум не всегда так. А ещё часто проекты могут не совпадать от слова совсем - к примеру сегодня делаю интернет магазин, а завтра графический редактор. И что, программист на одном проекте хороший специалист, а на другом нет?
Ну примерно так, да. Для магазина достаточно уметь лазить в базу и json парсить, а для графики на низком уровне неплохо бы знать, как работает DCT и прочие фишки дискретной математки и тензорной алгебры, тот же ЦОС.
Ну т.е. вы считаете что json спарсить кратно легче? А свой парсер generic типа написать легче?
А какая вам нужна тензорная математика и что вам надо знать о dct? Что вы с цос делать собираетесь? Если вы мне хотите за фильтры и свертку рассказать, то их как минимум могут выполнять библиотеки. Но даже без них свёртка не очень сложная штука например.
Ну т.е. вы считаете что json спарсить кратно легче? А свой парсер generic типа написать легче?
Дело не в легче или сложней, а в специфике конкретной области.
Спец по разработке движка 3Д редактора или 3Д игрового движка и спец по разработке ядра Linux могут быть одинаково крутыми в своих компетенциях, но поменяй их местами - будет полный провал, потому как специфика совершенно разная и наверстать эту разницу может занять не один год.
Притом оба могут быть шикарными программистами, отлично знать C или C++, алгоритмы, паттерны проектирования, и прочие buzzwords. Так и получается что платят не столько за программирование, сколько за экспертизу в предметной области.
Ну другими словами вы считаете, что если у вас есть хороший сотрудник, который доделал интернет магазин, а следующий заказ у вашей студии графический редактор (возьмём для удобства мобильное приложение, чтобы нельзя было утверждать, что это разные платформы), то первого сотрудника мы увольняем и ищем нового, с компетенциями в графике? Я верно вас понял?
Если сотрудник спец по веб-разработке, а новый заказ мобильное приложение, то да, вполне возможно что вам нужен на него другой сотрудник с соответствующей квалификацией.
Вы же не пойдете удалять аппендицит к стоматологу, а лечить сердце к травматологу? Почему в медицине не удивляет наличие стольких специализаций, ведь каждый врач учил и анатомию и биохимию и имеет представление о функционировании организма в целом - пусть все делают все... Но в реальности врачу, чтобы перейти в другую специализацию нужно дополнительное образование, экзамены и еще и пару лет опыта набраться, прежде чем нормальный специалист будет.
Ну иногда да, а иногда просто использует сдк и ничего не знает о внутрянке.
Это не про тех, кто на уровне АБС работает. Для разработчиков всяких "внешних систем" типа мобильных приложений - да. На уровне АБС эти самые "СДК" делаются чтобы внешние системы ими могли пользоваться.
Те же платежные шлюзы свое сдк дают
А кто эти платежные шлюзы пишет?
Да кто угодно их пишет. Вы же понимаете что это машина состояний покрытая тестами со всех сторон. Ну и изначальный посыл автора был что платят не за навыки программирования а за знания в предметной области. Что я и пытался выяснить, что именно нужно какому-либо разрабу для iOS/Android пишущий интернет магазин к примеру от платежного шлюза? Ему(или специалистам сервера) дадут сдк и будут все с ним работать.
Я понимаю что писать систему управления платежами сложно, но насколько я понимаю основные проблемы в отсутствии багов и куче тестов, т.к. ошибки дороги, а не в сложной логике. Какая-нибудь СУБД будет посложнее, но это мое мнение, на ?% правильность не претендую.
Ну и изначальный посыл автора был что платят не за навыки программирования а за знания в предметной области
На мой взгляд не совсем верный посыл.
Что я и пытался выяснить, что именно нужно какому-либо разрабу для iOS/Android пишущий интернет магазин к примеру от платежного шлюза? Ему(или специалистам сервера) дадут сдк и будут все с ним работать.
Ну вот на примере банка. Как это реализовано у нас (скорее всего, будет упрощенно т.к. я не в курсе всех подробностей того, что происходит за пределами АБС и центральных серверов).
Вот пишет человек мобильное приложение. Что ему нужно? В первую очередь - уметь писать эти приложения. Т.е. навыки разработки. Во вторую - знание REST API, которое ему предоставлено для работы с конкретными банковскими сервисами. Это его "предметная область". Но она специфична для данного конкретного банка.
Далее. REST API тоже не висит в воздухе. Оно основывается на вебсервисах. Которые тоже кто-то пишет. И ему тоже важны навыки разработки (но уже иные) и немножко "предметной области". Вебсервис штука тупая - фактически это преобразователь интерфейсов, который преобразует типы данных, используемые в REST API в типы данных, используемые в АБС. И обратно. Т.е. тут знания в предметной области ограничены пониманием как эти типы туда-сюда преобразовывать. Ну и как вызвать нужный сервис-модуль на стороне АБС.
Еще далее. Есть некто, кто уже работает на самом центральном сервере и пишет эти самые сервис-модули. И тут опять первичны навыки разработки - основная цель реализовать сервис-модуль максимально эффективно т.к. запросы от вебсервисов валятся на сервер "стремительным домкратом" (с) и должны обрабатываться максимально быстро и с минимальными затратами ресурсов. Саму логику сервис-модуля разработчику распишет аналитик, глубоких знаний предметной области тут не требуется, достаточно общего понимания что где лежит и что с чем связано.
Я понимаю что писать систему управления платежами сложно, но насколько я понимаю основные проблемы в отсутствии багов и куче тестов, т.к. ошибки дороги, а не в сложной логике.
Ну... Логика может быть достаточно сложной на нижних уровнях. Но за нее в большей степени отвечает аналитик - он расписывает что с чем как связано и все условия "если то, то так, если это, то этак". Для разработчика важнее понимание специфики и тонкостей работы платформы на которой все это работает и инструментария. Конечно, общее понимание того, с чем работаешь и как оно устроено дает преимущества, но не является приоритетным. Хотя, несомненно, позволяет более эффективно использовать имеющиеся ресурсы.
Так и я веду к тому же. Что 1с программист получает больше бухгалтера не потому что разбирается в предметной области лучше, а потому что кодить умеет. А тут рассказывают, что знание предметной области чуть ли не то, за что платят деньги.
Ну я бы так сказал - умение ориентироваться в предматной области, конечно, плюс, но первичны навыки разработки.
Ну и предматная область - это не столько тонкости бизнес-процессов, сколько понимание среды в которой работаешь (для нас - внутреннности АБС, ее стандарты, exitpoint`ы, струкдуры таблиц, их связи и т.п.). Вот это нужно знать, конечно.
Нет. В тех же банках разработчик мало контактирует к бизнесом. Он работает по ТЗ, которое написано аналитиком. И все непонятные вопросы обсуждаются с ним, а не с конечным заказчиком.
А программист МК может вообще в схемотехнику фильтров не лезть.
Просто потому, что схемотехника фильтров это лишь один из способов реализации. Зато, в ЦОС, векторную алгебру и прочие квадратуры - очень даже придется лезть.
Ну и будем честны, во внутреннюю схемотехнику портов и прочего фарша серьезный программист МК тоже нередко лазает. Собственно, устройство GPIO - первая контрольная по курсу "программирование микроконтроллеров".
Я не специалист ни в цос, ни в МК, но насколько я знаю цос на МК не самая частая задача. Ну т.е. оно конечно считается, но вот не каждый разработчик этим занимается. Да и библиотеки уже должны быть, но это мое предположение.
За фильтр признаю, т.к. это линейная система, чисто в теории он и цифровым может быть, но могут быть и не линейные системно схемотехнические решения.
Да и не думаю что рядовой программист МК будет антенну или трансформатор рассчитывать.
Что касается внутренней схемотехники, ну так она цифровая и да туда много кто лезет, но я уже встречал мнение что ассемблер знать например не надо, а он как раз к той самой схемотехнике прямо относится.
Ну вы написали про фильтры. Фильтры это ЦОС. Ну то есть да, их чаще на DSP делают, но по большому счету простой DSP это МК со свёрточным блоком.
Почти все современные радио системы работают так или иначе на базе SDR решений. А это сплошной ЦОС. Сигнал с антенны оцифровывают в квадратурах, и дальше же что хотят там делают - делят на каналы, фильтруют и тд. Захотел - BLE, захотел - WIFI. Ну в первом приближении. Аналоговый фильтр там только чтобы артефакты оцифровки убрать (теорема Котельникова-Найквиста).
Ассемблер не надо знать до тех пор, пока не надо оптимизировать код. И хотя на первый взгляд кажется, что компилятор оптимизирует всё сам, на практике конкретная реализация функций будет влиять на то (например), будут у вас хвостовые вызовы или не будут и тд. Хотя сама функция делает одинаковый результат, она может занимать на 5 (машинных) слов больше или выполняться на 10 тактов дольше. Программист, умеющий в ассемблер хотя бы немного, может посмотреть промежуточный вывод компилятора и посмотреть, что там куда транслируется, и как нужно исправить код.
То же самое со внутренней схемотехникой - например, для некоторых задач нужно знать, что происходит с портами, регистрами или память. при перезагрузке, в каком порядку оживают модули ядра, можно ли на это повлиять в коде и тд.
Да, это всё не самые шерпотребные задачи - согласен полностью. Но за более редкие скилы и платят больше. И конкуренция за таких специалистов выше. А просто собирать лего из либ для ардуины ума много не надо - на это можно и студентов нанять.
А разве подавляющее большинство rf устройств не строится по одной из следующих схем:
Ядро МК общается с внешним по отношению к нему устройством, находящемся в одном с ним корпусе - nrf24xxx
Вместе с МК поставляются скомпилированные библиотеки реализующие протокол, насколько я знаю nordic так делае
Если это так, то рядовой разработчик все равно не работает со всем этим матаном и типовая его задача это максимум pid
Что касается компилятора, то вроде хвостовые вызовы он оптимизировать умеет неплохо. Но я понимаю что вы имеете ввиду. Но в любом случае патчить код после компилятора мало кто будет, если он с регистрами не напорьачит какими-нибудь - к примеру нестандартный адрес списка векторов прерываний, который в программе надо перенести.
Ну если вы хотите готовый шерпотребный протокол на потребительском уровне, то так и строится. Более того, можно сразу взять nrf52x/53x, и ни каких там даже внешних устройств нет - какой softdevice накатил, такой протокол и реализуется. Но если вы вдруг хотите свой протокол, то добро пожаловатль писать свой softdevice. Хотя тут еще пока может обойдется без ЦОС наверное, но не факт.
Что касается компилятора, то вроде хвостовые вызовы он оптимизировать умеет неплохо.
При условии, что архитектура ваших функций соответствует логике автора компилятора. Но, в целом, согласен по конкретно этому пункту, хотя это просто пример - при написании же совсем low level вещей бывает важно знать, что в какие регистры он складывает, а еще не дай бог у вас требования к строгому реалтайму и надо написать функцию с константным временем выполнения вне зависимости от того, по каким веткам IFов оно пошло.
Впрочем, я допускаю, что современные IDE и компиляторы это всё за людей порешали, но верится с трудом.
Ну т.е. обычный неплохой разработчик вполне может за всю свою долгую карьеру не столкнуться с цос, я же верно понял, что свой sofdevice - я так понимаю, это что-то типа интерфейса в ООП - никогда писать не придется?
Не подумайте что я против знаний, вовсе нет. Но среднестатистическому неплохому разработчику решающему задачи бизнеса все это может же не понадобиться, судя по нашей беседе.
Любой реалтайм (а есть ли он в МК с конвейерами?) можно или на прерывании таймера написать, или сделать ассемблерную вставку - вроде у компиляторов для МК с этим проблем нет.
Ну тут дело в том, что "обычный неплохой разработчик" это arbitrary definition (как там по русски лучше написать?). Его всегда можно так подобрать чтобы оно соответвовало любым утверждениям.
Если вы хотите сказать, что просто чтобы быть в IT и неплохо жить, достаточно просто знать свой какой-то язык и библиотеки к нему, то это разумеется, правда. С этим я никогда бы не стал спорить.
Любой реалтайм (а есть ли он в МК с конвейерами?)
По-моему, да. Вроде, достаточно чтобы не было предсказания переходов во время исполнения. Но будем честны, это не сильная моя сторона. У меня вообще нет сильных сторон - пишу помаленьку то тут, то там.
или сделать ассемблерную вставку - вроде у компиляторов для МК с этим проблем нет.
А для этого надо знать ассемблер, о чем и был пойнт. На прерываниях в общем случае, кстати, нельзя - у вас будет, как минимум, неопределенной длительности манипуляция со стеком при входе и выходе из прерывания (а как максимум, какие-то условно атомарные функции нельзя прерывать).
Спасибо за ответы, это была интересная беседа :)
Взаимно.
Ктати, в догонку. Если вы вдруг соберетесь писать под nrf52x, то вот как раз там жесткие тайминги и реалтайм невозможны ни в какой сборке, использующей softdevice, под собственные прерывания которого зарезервирован наивысший приоритет. Если бы не DMA, вообще ничего бы нельзя было интересного сделать.
При этом сам softdevice настолько чувствителен к реалтайму, что вы не можете ставить брэйкпойнты в дебаггере при отладке на макетке. Любая остановка приводит к крашу BLE стэка (хотя допускаю, что с другими протоколами может прокатить).
Потому что сервер можно писать без глубокого понимания складского порядка, а прося непосредственных работников проконсультировать.
Как человек, имеющий обширный опыт и пользования складскими программами, и администрирования их, и составления ТЗ для разработки этих самых программ, скажу следующее:
1. Практически все ядро программ пишется без понимания процессов, происходящих на складе, что абсолютно всегда создает проблемы с доработками и оптимизациями. Например, простая функция по учету упаковок на стоке упирается в то, что архитектурно в базе заложено, что упаковка - это не объект, а просто коэффициент, а потому сделать отбор со стока упаковками и подобрать только нужную упаковку в некотором соотношении превращается в цирк с конями
При этом непосредственных пользователей банально не спрашивают. Например, при разработке шаблона пользователи считают поле А в качестве определящего уникальность записи, а фактически взяли непонятно какое поле, потому что информацией об этом никто не интересовался, и уникальность разработчик определяет по невидимым для пользователя ID.
И даже спрашивая, не слушают. Я только с пятого раза добился у разработчика признания факта того, что настройка размера текста в одном окне сбивает стили во всех остальных. Причем уже не на тестовой, а на рабочей базе. Причем сам разработчик, признав это, ответил, что "в стили лучше не лезть, а то будет еще хуже". В результате пользователь видит наименование того, что подбирает, 2-м размером шрифта, который разглядеть можно только через лупу :) Самое интересное, что такая фигня у всех клиентов.
Доработки если и делаются, то локально под клиента за отдельную денежку, и даже если они нужны и применимы для всех клиентов, в коробку не идут. В результате одну и ту же доработку компания может продать десяток раз, но коробка все равно как была кривой и уродской, так и остается.
Коробка вообще дорабатывается обычно не с учетом пожеланий клиентов, а в зависимости от того, что там наваяли конкуренты, и то если продажи от этого не идут, ну, или добавляются какие-то неведомые хотелки архитекторов проекта, как они представляют себе складские процессы.
Только тогда, когда клиент отказывается платить деньги, начинают спрашивать на складе, что там хотят.
То есть, представление, что если что не знают по предметной базе - спросят, то оно достаточно наивно, особенно когда дело касается не банковской сферы. Если спросят, то спросят чаще всего даже не тех, кто работает, а начальничков.
Достаточно фееричный бред. Не про матан, нет. А про то, что кодер обязательно должен быть со знанием предметной области. Он наоборот не должен, для этого есть аналитики, которые переводят знания предметной области в понятные программистам термины. Ну, это в целом по айти, в какой-то ООО "Рога и копыта" с 10 человеками в штате может и не так, но сами понимаете
Он наоборот не должен, для этого есть аналитики
В теории да. Но на практике, если хотите много зарабатывать, если хотите быть ценным и восстребованным, то придётся совмещать и должность аналитика. Увы, но конкуренция на современном рынке такая. Просто кодеры нафиг не нужны, их нынче как говна за баней.
Да что-то рынок как-то не нацелен на поиск "человеков-оркестров", это раз. И два - просто кодеров что-то тоже не "как говна за баней", недобор кадров все еще достаточной большой.
Я еще могу понять, если бизнес ищет тим/техлида с пониманием конкретной предметной области (искать, правда, будет очень долго), но чтобы еще линейных программистов с этими знаниями - это уж, извините, ваши фантазии. Или опять же "Рога и копыта"
Да что-то рынок как-то не нацелен на поиск "человеков-оркестров", это раз.
Пока да. Пока это просто конкурентное преимущество чтобы выделяться на фоне толпы и торговаться за большее денежное вознаграждение. Но вот например в американском финтехе нынче без предыдущего опыта в этой сфере ваше резюме летит прямиком в мусорку. Хотя я помню времена когда обещали всему научить, ты главное приходи со своим голым С++ или Жавой.
И два - просто кодеров что-то тоже не "как говна за баней", недобор кадров все еще достаточной большой.
Недобор только у людей не умеющих проводить собесы.
Но вот например в американском финтехе нынче без предыдущего опыта в этой сфере ваше резюме летит прямиком в мусорку
Ага, а еще в Америке негров линчуют, слыхали?
Недобор только у людей не умеющих проводить собесы.
Ну наконец-то решение всех проблем индустрии найдено, и снова в комментариях на Хабре, ура!
Да ладно? Мой опыт говорит об обратном...
По-хорошему, в айти хорошо зарабатывают за совмещение этих должностей. 100К за спеца в банковских АБС, плюс 100К за жава-программиста.
"Спец в банковских АБС" - это больше про системных аналитиков и архитекторов.
Для разработчика важнее хорошо знать платформу на которой эта АБС работает и средства разработки (и там очень вероятно будет на джава, а что-то более специальное).
И хороший разработчик там будет те же 200к иметь безо всякого "совмещения". Просто потому что их немного и дешевле платить тому, кто уже все это постиг, чем искать и готовить нового.
А просто кодер это 100К и меньше, нынче их как грязи, и как таковые без знаний предметной области они особо и не нужны
В банках, на уровне АБС, это не совсем так. Предметную область, конечно, в общих чертах представлять нужно, но глубокие ее знания - прерогатива аналитиков.
И хороший разработчик там будет те же 200к иметь безо всякого "совмещения". Просто потому что их немного и дешевле платить тому, кто уже все это постиг, чем искать и готовить нового.
Что постиг? Жаву? Постишних Жаву вон как собак нерезанных. Только кинь клич, уж на 200К со всех щелей сбегутся точно.
А в каком банке АБС на джаве работает? Просто интересно...
А о чём вы? Если о вашем специфическом ЯП, то ежу понятно что спецов по нему в природе не водится. К чему такие аргументы?
Я не про наш конкретный ЯП. Просто спросил - в каких банках центральные сервера, где крутится АБС, работают на джаве.
Вроде бы, простой и конкретный вопрос.
Центральные сервера банков - вообще тема специфическая. Со специфическими требованиями и специфическим выстраиванием процессов разработки. Поэтому я не стал бы приводить их в качестве примера.
В каждом курсе бы такое писали. А то начал с С++, а по итогу нужно было начинать с вышей математики =(
Несколько советов как новичкам не забросить изучение IT