Комментарии 20
Вообще опасно заходить в JS топик на Хабре с рекомендациями, какие технологии изучать. Сообщество программистов достаточно четко разбилось по используемым фреймворкам и подходам, и явно многим не понравится то, что фокус ставится строго на определенные.
Я лично не советовал бы GraphQL, так как в реальном проекте не видел ни разу, и по собеседованиям в сотнях компаний только в паре он использовался — он создает большую нагрузку на бэк-разработчиков, в большинстве случаев ухудшает перфоманс и стабильность (права доступа, оптимизацию и кэш, стейт-машины по отдельным ручкам куда проще менеджерить), там сложно с валидацией, нестандартными данными. Также и от SC везде отказываются ввиду колоссального количества недостатков. Лучше бы посоветовать новичкам изучить CSS (+Modules) с PostCSS-плагинами, которые могут расширять его функциональность подо все нужды и классический REST + RPC с Socket, так как это намного более распространено и под те самые малые и средние проекты, о которых вы говорите, GraphQL интегрировать почти точно не будут. Если цель как раз зарабатывать деньги программированием, лучше учиться популярной классике, а не тому, что когда-то было на хайпе.
Вообще опасно заходить в JS топик на Хабре с рекомендациями, какие технологии изучать. Сообщество программистов достаточно четко разбилось по используемым фреймворкам и подходам, и явно многим не понравится то, что фокус ставится строго на определенные.
Не знаю на счет опасности, но вот говорить за многих — это как минимум странно. Или вы думаете, что я не отношусь к сообществам программистов? Или с каких-то пор стало запрещено высказывать свои предпочтения? Действительно странно…
Еще раз уточню: я нигде не сказал, что другие технологии плохие. С сказал, что я считаю (и это мое личное суждение), что данные технологии переспективны в плане освоения, потому что они будут востребованы. При этом я не сказал, что не будут другие востребованы.
Я лично не советовал бы GraphQL, так как в реальном проекте не видел ни разу, и по собеседованиям в сотнях компаний только в паре он использовался
Это еще более странно. При чем даже не столько утверждение как таковое, сколько статистика — собеседоваться в сотнях компаний. Это же сколько времени на это было потрачено. Может лучше было потратить время на программирование, а не на собеседования? Лично мне хватает 3-5 собеседований, чтобы заключить контракт.
он создает большую нагрузку на бэк-разработчиков, в большинстве случаев ухудшает перфоманс и стабильность (права доступа, оптимизацию и кэш, стейт-машины по отдельным ручкам куда проще менеджерить)
Отчасти соглашусь. Потому что специалистов, которые умеют работать с графом нормально — найти очень сложно. Но если его правильно готовить, то получается все ОК. Особенно радует скорость внедрения и легкость сопровождения, особенно в связке с apollo-client, nexus и т.п. Но повторюсь: мало кто это в рунете сейчас умеет. При это для простых сайтов суперпроизводительность и не нужна.
там сложно с валидацией, нестандартными данными.
Скорее всего вы тоже не умеете его готовить. К примеру, есть такая штука, как @graphql-codegen/cli, которая на гитхабе имеет 6.3к звезд, и упоминание которой на хабре гугл видит только одну страничку, и ту в вопросах. Так вот, она позволяет из граф-схемы сгенерить typescript-файлы, и сразу нагенерить реакт-хуки и т.п… Пример: github.com/freecode-academy/freecode.academy/blob/master/src/modules/gql/cli/generateTypes/types.ts#L23-L29
const scalars = {
DateTime: 'globalThis.Date',
Json: 'globalThis.Record<string, any> | globalThis.Array',
Long: 'number',
Upload: 'globalThis.File',
UserTechnologyLevel: '1 | 2 | 3 | 4 | 5 |null',
}
И все запросы будут типизированные. Пример:
export type UserTechnologyNoNestingFragment = { __typename?: 'UserTechnology', id: string, createdAt: globalThis.Date, updatedAt: globalThis.Date, components?: Types.Maybe<globalThis.Record<string, any> | globalThis.Array>, date_from?: Types.Maybe<globalThis.Date>, date_till?: Types.Maybe<globalThis.Date>, status?: Types.Maybe<Types.UserTechnologyStatus>,
level?: Types.Maybe<1 | 2 | 3 | 4 | 5 |null>
};
Обратите внимание здесь на level?: Types.Maybe<1 | 2 | 3 | 4 | 5 |null>
И все, если я в level захочу передать что-то кроме перечисленных вариантов, я получу TS-ошибку.
Про остальное писать не буду, там все в том же духе.
В целом ваше сообщение подтверждает ровно то, о чем я говорил: нам внушают, что надо учиться чему-то классическому, проверенному, надежному и точно крутому. Но сколько на это времени уйдет? Когда человек получит первую зарплату, когда пойдет по такому пути? Когда он дорастет до мидла? И вы готовы учить людей? Если готовы (не минутным сообщением, а создать проект учебный, или хотя бы написав сотню-полторы статей (как написал их я)), то конечно же учить можете чему угодно, на ваше усмотрение.
Я вот готов учить, и буду учить желающих. И тем, кто научится, обязательно помогу с работой (запросы ко мне прилетают довольно часто).
Высказывать предпочтения не запрещено, наоборот, плюрализм мнений — это прекрасно, как и то, что занимаетесь обучением других людей. На собеседования действительно трачу много времени, сотня в год как минимум набирается, и пара десятков в качестве интервьюера — каждый сам выбирает, по каким критериям подбирать работу, у меня они достаточно специфичные, поэтому редко устраиваюсь, а подбираю месяцами. Забивать свободное время программированием мне уже не интересно, если есть желание — занимаюсь пет-проджектами. У вас другая история, много говорите про деньги в статье — для меня же куда важнее идейная и архитектурная составляющие, так что цикл поиска работы разный.
Про GraphQL верно — все нюансы его работы не знаю, как и сопутствующие библиотеки, ссылаюсь на мнение коллег, анализ их юзкейсов и статистику использования. Исходя из этого и сказал, что не рекомендовал бы начинающим изучать эту технологию, что подтвердили ваши слова про "мало кто это в рунете сейчас умеет". Из TS моделей для реста формировать валидаторы несложно, достаточно типов запроса-ответа, обработка ошибок и вариантов ответа бэка тоже не сложна, так что я бы начал обучение с этого — явно в подавляющем большинстве проектов используется он и будет актуален еще долго. Сколько времени займет изучение реста? Точно не больше, чем графовой системы запросов, старт прост как fetch(url), дальше — типизация, валидация, обработка. Когда человек, изучающий рест, дорастет до миддла? Может завтра, а может никогда.
Как я понял, цель этой статьи скорее самореклама, так как статей типа "как войти в айти" огромное количество, и многие более обоснованны. И то, что вы с чего-то начали рассказывать в комментариях, что хотите обучать и у вас уже много учеников, подтверждает. В целом не имею претензий, сказал только что у GraphQL малое распространение и много нюансов, а SC хайп из прошлого, который неудобен и неэффективен.
Если так, то это радует.
<< На собеседования действительно трачу много времени, сотня в год как минимум набирается, и пара десятков в качестве интервьюера — каждый сам выбирает, по каким критериям подбирать работу, у меня они достаточно специфичные, поэтому редко устраиваюсь, а подбираю месяцами.
Если это осознанный путь, то извините за мой выпад. У каждого действительно свой выбор.
<< У вас другая история, много говорите про деньги в статье — для меня же куда важнее идейная и архитектурная составляющие, так что цикл поиска работы разный.
Поймите меня правильно. Для меня деньги — тоже не высшая цель в том плане, что я не пытаюсь заработать всех денег и не говорю, что все должны к этому стремиться. Но согласитесь — совсем без денег тоже не хорошо. То есть все-таки, это профессия, и она должна приносить прибыль, должна обеспечивать необходимым. Сейчас получается, что если ты уже опытный специалист с многолетним стажем, то проблем с работой практически нет (я сам видел как народ пачками устраивается в тот же СберТех и пачками же оттуда уходит, недовольные буквально мелочами и уверенные, что найдут и лучше). А вот новичкам очень туго сейчас.
>> Из TS моделей для реста формировать валидаторы несложно, достаточно типов запроса-ответа, обработка ошибок и вариантов ответа бэка тоже не сложна
Тут не совсем так. Проблема реста в том, что сам по себе он не сообщает в деталях что он умеет принимать, что отдавать, все наборы УРЛов и т.п. То есть условно, нужны дополнительные действия для того, что бы фронт смог узнать о всех методах API. Я не говорю, что в случае с REST этого нельзя сделать, я говорю про то, что требуются дополнительные действие.
В случае с GraphQL это все идет «из коробки». Видя открытое GraphQL-API, я вижу что можно вызывать, с какими параметрами и что получить в ответ. Это позволяет легко интегрироваться со сторонними API-провайдерами. Для примера, с того же гитхаба хочу какие-нибудь данные получить, иду на страничку docs.github.com/en/graphql/overview/explorer и пожалуйста, пиши запросы. И через тот же apis.guru/graphql-voyager можно довольно быстро пробежаться по всей схеме, посмотреть взаимосвязи и т.п.
Это работает из коробки и для все GraphQL API. Мне это нравится. И я вижу, что это набирает популярность.
Также и от SC везде отказываются ввиду колоссального количества недостатков.
Имеется ввиду Styled Components? Подскажите, кроме того что они вычисляются в рантайме, какие ещё есть недостатаки?
Поделюсь и своими мыслями по этому поводу.
Git… Без него вы просто не сможете в командную работу.
Я встречал достаточно опытных разработчиков, которые не особо могут в командную строку, а с гитом работают исключительно через интерфейс IDE, например, WebStorm. Они даже не особо помнят CLI команды GIt'а, так так IDE позволяют просто забыть их. Я не оправдываю и не осуждаю такой подход — он просто есть, и вполне эффективен.
Еще вы забыли упомянуть различные элементы экосистемы React. Точнее, то, что привычно используется в связке с React. Например, Redux, Mobx, Redux-thunk и т.д. Возможно, вы подразумевали их в разделе React, но явно не упомянули. Их тоже спрашивают на собеседовании и даже используют в реальных проектах. Отдельно стоит упомянуть Webpack. Хорошо бы знать, как он работает и хотя бы базовые настройки и правила. Также стоит обратить внимание на различные линтеры. Ну и (гулять, так гулять!) — про тесты тоже не стоит забывать, тот же Jest, например.
Ну а насчет GraphQL… Он безусловно упоминается в вакансиях. Однако мое мнение — это попытка экономии на бэкенде, когда на фронтенд разработчиков пытаются переложить часть API получения данных. Мол, дай нам всего один endpoint на бэке, а мы уже сами будем извлекать те данные, что нам нужны. Хотя чем плох REST API? Так давайте уж сразу пришлем всю БД в JSON через один эндпоинт GraphQL, чего уж там))
Они даже не особо помнят CLI команды GIt'а, так так IDE позволяют просто забыть их. Я не оправдываю и не осуждаю такой подход — он просто есть, и вполне эффективен.
Так и я не говорил, что обязательно надо в терминале работать (хотя считаю, что все же лучше). Тем не менее, кому как больше нравится. Гит от этого не меняется.
Еще вы забыли упомянуть различные элементы экосистемы React. Точнее, то, что привычно используется в связке с React. Например, Redux, Mobx, Redux-thunk и т.д.
Нет, эти компоненты я не использовал, и никому не советую. Опять же, если кому нравится, то пусть использует, но я не советую и в свои проекты их ни в коем случае не тяну. Я с Redux познакомился очень давно (больше трех лет назад) и для себя сразу отметил: он далек от совершенства, он делает проект громоздким, а компоненты перестают быть обособленными. Если делаешь проект с использованием Redux, то компоненты, написанные для такого проекта, становятся неотъемлемой частью его и тяжело переносимыми. В последствии я видел и на хабре не одну статью в духе «мы отказались от Redux и проект сильно полегчал». Пример: habr.com/ru/post/331088
А вот apollo-client обязательно советую и он отлично укладывается в экосистему TS+React+GraphQL.
Мол, дай нам всего один endpoint на бэке, а мы уже сами будем извлекать те данные, что нам нужны. Хотя чем плох REST API? Так давайте уж сразу пришлем всю БД в JSON через один эндпоинт GraphQL, чего уж там))
Тут не совсем так. Смысл в том, что с REST просто невозможно дать запросы на все случаи жизни. Ну никак. GraphQL позволяет гораздо проще организовать доступ к гораздо большему набору данных (именно набор имею ввиду, а не суммарный объем). Довольно подробно этот момент раскрывается здесь: habr.com/ru/company/jugru/blog/428517
Насколько конкурентноспособен человек без опыта работы с хорошим знанием только одного вектора проф.области?
Или это первый этап обучения? Освоил вектор, а все остальное — потом?
Сильно зависит от того, есть ли у этого человека выход на заказы. Как мне видится, в этом плане сильно должен помогать сам обучающий проект, в том плане, чтобы он не только обучал, но и давал платную работу. У нас там изначально вводились проекты и задачи и многопользовательская работа с задачами. Сейчас в основном эти задачи учебные (в рамках учебных проектов), но в дальнейшем будут задачи и платные. Практически в любом проекте, пусть даже он и очень сложный, есть простые задачи. Если архитектура заложена правильно, то такие простые задачи легко вычлинять и давать менее опытным специалистам выполнять и набивать скилы. При этом в задачах можно указывать, что по ним именно ожидается помощь (галочка ставится). Список таких задач: https://freecode.academy/tasks?needHelp=true.....
Я сторонник опен-сурс проектов, и расчет на то, что любой со своим опен-сурс проектом может вот так прийти и опубликовать задачу и в ней же перечислить какие технологии требуются и какой уровень.
Таким образом, новички могут чисто технически для себя подбирать задачи из расчета под свои скилы и свой вектор развития, а работа через гитхаб позволяет легко отправить решение для дальнейшего ревью и принятия.
И да, платные задачи появятся и со стороны нашего проекта. То есть как только учащийся начнет себя проявлять, он вполне может рассчитывать на платные задачи.
почему программирование пытаются возвести в какой-то мифический ранг? Почему, если программист, то надо быть богом, а вот простым чернорабочим нельзя быть?
Но этот человек вполне может получить работу и получать свою зарплату. А со временем человек будет получать опыт и расти профессионально дальше.
Только вот часто бывает, что человек осваивает необходимый минимум, свою зарплату получает, но о дальнейшем росте даже речи не идёт.
Я больше по бэку и буду говорить преимущественно о разработке на php. Но уверен, что во фронте ситуация примерно такая же.
У меня есть знакомый. Он быстро освоил WP, быстро вошёл в разработку и застрял на том уровне.
Да, код он пишет, зарплату получает. Но его код так и застрял на уровне новичка с двухмесячным стажем.
Это жуткие простыни без какой либо структуры, копипаста и прочее.
А если он в чём-то не может разобраться, ему проще позвонить мне, чем понять как оно всё работает и так далее.
Хотел я его сманить в компанию к другим своим знакомым. У них открывалась вакансия для джуна. Но они там серьёзно относятся и к качеству кода и к подходам относительно разработки.
Сказал, что могу порекомендовать, но придётся много учиться, т.к. сейчас он пишет крайне паршиво. На что он ответил: а мне это нужно, я себя и сейчас норм чувствую.
нам внушают, что надо учиться чему-то классическому, проверенному, надежному и точно крутому. Но сколько на это времени уйдет? Когда человек получит первую зарплату, когда пойдет по такому пути?
Да, именно так. Сначала изучаются основы, потом изучаются детали. Сначала изучается язык, потом изучаются инструменты.
В том и проблема, что сейчас сразу изучают Laravel, WP, Vue, React, etc. Но абсолютно забивают на основы языка, забивают на какие-то фундаментальные принципы программирования.
А используемый стек превращается в какой-то чёрный ящик.
Люди копипастят магические письмена из документации, не понимая как это всё работает, как оно взаимодействует одно с другим.
Был случай, когда один чувак мне заявляет: не пойму почему разработчики php не добавят в mysql вот эту штуку. Не помню уже о чём был разговор. И когда я его спросил о том, каким боком вообще php к mysql, он крайне удивился. Мол: ну я же использую mysql в php.
А когда-то давно я долго пытался втолковать другому чуваку, что апач это не часть php.
Т.е. люди тупо не понимают с чем они работают. Но да, свои задачи они выполняют и зарплату получают.
А что касается времени и его количества. Все воспринимают как норму, что на юристов, врачей, бухгалтеров нужно учится по 5 +- лет, а чтобы войти в IT достаточно посмотреть 60 часов видосиков на ютубе и этого достаточно. А чем IT в данном случае так уж отличается?
Нет, многие направления в IT действительно можно освоить самостоятельно, достаточно быстро и так далее. Пускай на это понадобится не пять лет, но и не пол года.
У меня тоже нет технического образования. Учился я преимущественно самостоятельно. Прежде, чем я взялся за первый проект, я потратил на обучение примерно около двух лет. Да, за первый год работы я изучил не меньше, чем за эти предыдущие два года. Но всё равно я не считаю, что потратил я их зря. У меня была уже достаточно неплохая база и многие вещи давались гораздо легче, чем если бы я наскоком потом их изучал с нуля в рамках рабочих проектов.
Только вот часто бывает, что человек осваивает необходимый минимум, свою зарплату получает, но о дальнейшем росте даже речи не идёт.
Люто плюсую. И к сожалению, так происходит гораздо чаще, чем наоборот. Более того, меня угнетает та мысль, что в большинстве случаев люди вообще не хотят учиться. И уверен, из-за этого и практически нет предложений для джунов. То есть любую компанию можно понять — она не хочет брать джуна и платить ему деньги уже сейчас, не зная, а будет ли он дальше расти или нет. К тому же, если и будет расти, то где гарантия, что он останется дальше работать в этой компании и вложения в этого специалиста будут сделаны нельзя. Гарантия как раз скорее в обратном: компания вырастит специалиста и почти наверняка его потеряет. Так что как это не грустно, но в бедах нынешних джунов виноваты предыдущие поколения, проявившие безответственность и здесь сделать практически ничего нельзя.
Моя же мысль в том, чтобы обеспечить не долгоиграющие отношения Работодатель-Специалист, а больше сиюминутные. То есть часто бывает так, что аврал, и надо быстро найти специалиста для решения тех или иных задач. И задачи разного уровня, не только сложные и важные, но и всякая мелочевка. И на сегодня механизмы быстрого поиска практически отсутствуют. То есть да, фриланс-биржи есть и их не мало. Но в них очень слабо прокачен репутационный менеджмент и очень сложно оценивать уровень кандидатов. Более того, совсем не учитывается текущий желаемый стек специалиста (то есть если я когда-то писал на php и довольно сильно в нем прокачен, это совсем не означает, что я хочу сейчас именно задачи по php и именно сложные и важные. Я вот решил на JS перейти и сейчас в поисках простых задачек). Так вот этого нет. И чаще всего за профилями специалистов прячутся манагеры всяких команд и агенств, а не конечный специалист. Как мне видится, надо иметь возможность видеть специалиста, видеть его какую-то активность (включая прогресс в обучении), видеть открыт ли он сейчас для предложений и какого рода. И именно сегодня (или хотя бы с указанием когда он планирует освободиться). Вот такое мысли.
И да, я этот проект не вчера придумал и не сегодня запустил. Моему проекту уже лет 10. Он как и я, менялся (иногда даже менял доменные имена). Сейчас вот у него такой вектор развития.
В том и проблема, что сейчас сразу изучают Laravel, WP, Vue, React, etc. Но абсолютно забивают на основы языка, забивают на какие-то фундаментальные принципы программирования.
А используемый стек превращается в какой-то чёрный ящик.
Повторюсь: я считаю, что нет смысла бороться с естественным ходом. Если такое имеет место быть и так происходит, надо думать что, с этим делать, чтобы было хоть как-то эффективней. Ведь все сильно еще зависит от задач. Кому-то надо, чтобы быстренько и не за дорого написали что-то и если оно работает, то почти не важно как.
Я здесь уточню, что сейчас мои слова сильно зависят от того, что расчет на TypeScript и командное программирование. Еще вот несколько месяцев назад у меня были только мысли, но не было никаких причин для утверждений. Сейчас мне есть на основе чего делать утверждения. Уже сейчас я имею вполне приличные достижения в учебе у одного из моих учеников чисто за счет того, что я его перевожу с чистого JS на готовый движок, а главное — на TypeScript. В связке в Eslint получается чисто технически обеспечить более качественный код. Ведь TS и Eslint как строгий старший напарник ежесекундно следит за его кодом и ругается, если он где-то полную чушь делает. А prettier еще и помогает формат к общему знаменателю приводить. Ежедневные задачи и код-ревью тоже дают ощутимый эффет. Так что мой расчет чисто на стандартизацию и сужение профиля. Да, потребуется время на то, чтобы специалист сильно вырос, если он имеет способности. Но такой подход должен обеспечить более быстрый выход на приемлемый уровень с дальнейшим трудоустройством.
У меня же тоже была довольно серьезная школа, и список технологий, которые я в той или иной степени освоил, довольно большой: freecode.academy/profile/Fi1osof
Но именно потому я ощущаю на себе, как важно, когда есть тот, кто подскажет с направлением. Я за свою практику освоил очень много того, что мне в итоге больше не нужно, и что не особо-то повлияло на мои успехи. Я освоил то, просто потому что оно подвернулось и тогда были задачи, и некому было сказать «Вот это тебе вряд ли понадобится, учи лучше вот это». Не все то, что мы осваиваем, обязательно нам надо, а время уже не вернуть.
Ваши комментарии напомнили баянистый текст:
"Тяжелые времена порождают сильных программистов.
Сильные программисты создают фреймворки.
Фреймворки порождают слабых программистов.
Слабые программисты порождают тяжелые времена."
Предложение обучать только надстройке, быстрее готовя человека к боевым задачам, делает из человека подмастерье, который копирует код не понимая как он работает и как должен работать.
Повторюсь еще раз: да, я согласен в том числе и с вами, здесь есть такие риски. Но цель: дать возможность начать зарабатывать как можно быстрее. Есть 100500 задач, за которые «крутые правильные программисты, прошедшие правильное обучение и умеющие правильно программировать» уже никогда не возьмутся. А кому тогда выполнять эти задачи? Может как раз этим подмастерьям?
Правильный подмастерья со временем начинает замечать, что он пишет неправильный код по сравнению с другими, и что ему не хватает знаний, и пытается и сам дальше правильно развиваться. А есть и такие, кто уже лет пять программируют, и не хотят развиваться дальше (подобный случай и выше человек описывал).
Таким образом риски и проблемы не в пути, а в людях. Если человек хочет правильно развиваться, он и здесь будет правильно развиваться. А если не хочет, то никакая правильная методика его не заставит. Я с палкой тоже ни над кем не планирую стоять.
Статья не про программирование и не обучающая, как Вы честно признались. Насколько я понял, это руководство, как по-быстрому поднять бабла с помощью JS Три топора. Однако она явно преследует цель мотивировать 25-летних ребят, которые уже 2 года как окончили ВУЗ, но занимаются не пойми чем, осваивать рынок ИТ по описанным принципам, которые обесценивают глубокое знание языков и технологий и даже стремление к этому.
И хрен бы с ними, кому-то надо клепать бесчисленные интернет магазины.
Но неокрепшие умы студентов начальных курсов тоже могут Вас читать вместо того, чтобы учиться программировать. Как ни отстраняйтесь от ответственности, говоря что проблема в людях, все же влияние на них Вы оказываете, тем более, публикуясь на Хабре, а не в личном блоге.
Тем временем, у нас в компании недобор штата, из-за чего реально полезные идеи по автоматизации медицины не могут быть воплощены. Мы готовы брать студентов без опыта и даже бесплатно учить их на реальных проектах. Но приходят хлопцы со словами "у вас слишком сложный стэк, а я хочу по-быстрому в сеньоры". Другие уходят со словами "архитектор не прав, я на Хабре читал по-другому". Убежден, что такой подход к работе приводит к стагнации отрасли и снижению уровня профессионализма, потому что воспитанные таким образом "программисты" неизбежно будут так же учить своих подаванов, которые уже ничего кроме интернет магазина создать не смогут, и таких будет все больше в силу простоты этого пути. А кому писать серьезный корпоративный софт, спрос на который тоже растет?
Я не утверждаю, что Вы фундаментально не правы, Вы добились своих результатов в своей нише. Но объявлять Вашу концепцию успешной считаю недопустимым.
Как ни отстраняйтесь от ответственности, говоря что проблема в людях, все же влияние на них Вы оказываете, тем более, публикуясь на Хабре, а не в личном блоге.
Как кто-то сказал, лучше я буду сожалеть о том, что сделал, чем о том, чего не сделал.
Ответственности с себя не снимаю, но и расценивать ее как причину не идти в этом направлении, тоже не буду.
Тем временем, у нас в компании недобор штата, из-за чего реально полезные идеи по автоматизации медицины не могут быть воплощены. Мы готовы брать студентов без опыта и даже бесплатно учить их на реальных проектах.
А можете ссылку на вашу компанию кинуть? Вакансии размещенные? Сколько денег платите? Это же тоже имеет смысл.
Но приходят хлопцы со словами «у вас слишком сложный стэк, а я хочу по-быстрому в сеньоры». Другие уходят со словами «архитектор не прав, я на Хабре читал по-другому».
Да, это есть сплошь и рядом. В том же СберТехе я видел как народ уходил пачками. Не потому что в Сбере плохо (наоборот, очень даже), но часто просто «Потому что». Кому смена обстановки нужна, кого еще что не устраивает. И не сделаешь с этим ничего.
Убежден, что такой подход к работе приводит к стагнации отрасли и снижению уровня профессионализма, потому что воспитанные таким образом «программисты» неизбежно будут так же учить своих подаванов, которые уже ничего кроме интернет магазина создать не смогут, и таких будет все больше в силу простоты этого пути. А кому писать серьезный корпоративный софт, спрос на который тоже растет?
Подождите, а я вот сейчас не понял. Вам не кажется, что вы хотите на кого-то переложить ответственность? Вообще-то, как вы сами говорите, ваша же компания не может нормально завлечь, а если и завлекает, то не может удержать. И вы что хотите сказать? Что кто-то виноват в этом? Пусть даже тем, что отвлек ваших ребят на более простую (и может более интересную для них, а еще может и более высокооплачиваемую) работу? А вы что хотите противопоставить?
Но объявлять Вашу концепцию успешной считаю недопустимым.
Можете считать. Но я имею право считать иначе. Имел практический опыт обучения. И пусть и не все, но некоторые в своей области стали вполне успешными специалистами. Нет, не научными. Но бизнесу задачи решают.
А еще я даже оффлайновый проект обучающий запускал. freecode.academy/topics/rabota-obuchenie-prozhivanie-pitanie-v-moskve-dlya-it-speczialistov-2160.html
Было более десятка человек.
Проект нельзя назвать очень успешным, но все же не провальным. Один специалист в итоге в x5 retails работает (кстати, осел плотно, уже более 1.5 года там и не планирует уходить). До сих пор дружим, сегодня в гости планирует заехать :)
Другой перепрофилировался с фронта на бэк, сейчас на Go плотно пишет, переехал в Польшу (недавно передавал привет).
Третий, хотя и разошлись наши пути, как я слышал, тоже в итоге стал хорошим специалистом, в Европу тоже перебрался.
Так что если вы меня хотите убедить, что я все делаю зря, извините, никак с вами не соглашусь.
Не зря. Вы укрепляете точку зрения, что успехом считается не быть профессионалом, а быть посредником между директором и заказчиком с минимальными вложениями и за высокую ЗП. И Вы правы, для многих людей этого действительно достаточно и, конечно, им не нужны несоразмерно великие цели.
Великое не для Вас?
Или вы считаете, что ваши ученики не про великое?
Цели новичка (в любой профессии) должны быть как раз великие — освоить новые месторождения, создать лучший в мире смартфон — а кто их не вывозит, идут писать сайты. Утопия, конечно, но чтоб хотя бы двигаться в эту сторону, статьи должны быть совсем другого толка, нежели Ваша. А иначе число обывателей будет расти непропорционально.
Про великое даже отвечать не хочу. Это действительно совсем утопия. Я больше как-то в реалии. Смартфонами пользуются, вероятно, миллиарды людей. Собирают их многие тысячи. Из них, дай Бог, 5% высококлассные специалисты. Создают лучшие (которые сейчас как две капли воды похожи друг на друга) — единицы. Стремиться быть лучшим? Такое… Путь к разочарованию…
Мои рассуждения на тему Как учиться программировать на JavaScript