Доу немчинский как учить java

Обновлено: 02.07.2024

Меня зовут Сергей Немчинский, я — руководитель и владелец учебной компании foxmindEd. Я также известен как спикер многих конференций по управлению проектами, блогер и много кто еще.

Вот несколько фактов обо мне.

Я — коренной москвич, как минимум в 4-ом поколении. С мая 2001 года живу в Киеве. Несмотря на полное отсутствие у меня украинской крови, после Революции Достоинства считаю себя украинцем. В Революции, кстати, я принимал весьма активное участие, после участвовал в самообороне. Если вам попадется моя фотография в военной форме — это я в патруле самообороны.

В 2016 году я создал первую компанию Смартерама, затем она трансформировалась и получила новое название foxmindEd. Я единственный владелец и директор. За несколько лет компания выросла и разделилась на два направления. Учебная компания FoxmindEd готовит разработчиков по направлениям Java EE, Android, Front-End, Automation QA, UI/UX design. Кроме того, мы занимаемся карьерным консультированием для IT-специалистов. Вторая компания, FoxmindEd Software, занимается разработкой качественного программного обеспечения по самым низким на рынке рейтам.

Я — почетный Президент (основатель) Suzuki клуба Украина

Я вел достаточно популярный блог по ММО играм

Чем я занимался до 2016 года (основание foxmindEd):

Более 20 лет работал программистом. Почти 15 из них — в Java. Примерно столько же — руководил программистами,в основном на позиции team leader или project manager. Я был Project manager в Ciklum, Team Leader в Luxoft, NetCracker и IntroPro, был начальником отдела веб-разработки в ЛигаБизнесИнформ. Параллельно преподавал в учебных центрах Luxoft, NetCraker и IntroPro, и даже работал учителем в школе. Уже лет 10 я Certified Scrum Master.

Я выступал с аналогичной темой на IT fest, и, судя по реакции зала, людям было интересно. Формат доклада сжатый, многое пришлось проговаривать уже потом, отдельно от выступления. Да и качество записи вышло не очень, не всё слышно. Поэтому решил написать статью.

Сначала о себе любимом. У меня достаточно большой опыт работы java-разработчиком (с 2001 года, даже считать страшно), а программистом и того больше — с 96-го. Большую часть из этих лет я работал тимлидом в разных аутсорсинговых компаниях Киева. Кроме того, более 10 лет я преподаю в учебных центрах Luxoft, NetCracker и вот IntroPro. И даже год вёл в школе информатику. В общем, обучать умею. Ну и с другой стороны, во многих компаниях я выступал как технический специалист, проводящий собеседование. Так что я еще и тот самый человек, который знает, о чем вас будут спрашивать на будущей работе. В этом году я принял участие в создании учебной программы по java в GoIT и преподавал в одной из групп. Большинство моих студентов уже работают.

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

Итак, начнем, и внезапно с конца — я соберу выводы, которые сделал из обучения молодых специалистов.

Первый вывод самый печальный — программистами могут стать не все. И нечего смеяться! Изначально я рассчитывал, что научиться программировать может любой. А чего там, программирование — откровенно не rocket science. Бери больше, кидай дальше. Но всё оказалось не так. Всё уперлось в мотивацию. Сейчас объясню.

Не бывает людей вообще без способностей к программированию. Но всё равно — все люди разные. Так вот, обучаясь (в том числе и программированию), вы тратите мотивацию. Достигая чего-то в процессе обучения — вы мотивацию восполняете. И чем меньше у вас способностей, тем тяжелее вам продвигаться до очередного достижения. Если у вас было не так уж много мотивации, вы рискуете просто до следующего достижения не доучиться. А другой человек, возможно с меньшей мотивацией, чем у вас, но с большими способностями просто будет щелкать задачи как орехи и доучится. Се ля ви.

Второй вывод. Учиться java-разработчику без ментора, работающего в этой сфере — невозможно. Наша индустрия полна огромным количеством невнятных и даже контр-интуитивных знаний о том, как надо поступать и как не надо. Сами вы в этом не разберетесь. Гарантированно.

После конференции меня спрашивали — так что же делать, если наставника нет? Отвечаю: найдите себе ментора. Понимаете, программистам тоже надо расти, из миддлов становиться сеньорами, из сеньоров — тимлидами и так далее. И для всего этого надо получить опыт руководства, общения с подчиненными. И где его взять? Тут проблема та же самая, что и у джунов — нужен опыт, чтобы получить определенную работу. А получить его можно только на этой работе. Так что помогите друг другу.

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

Что же должен знать java разработчик

Здесь я просто приведу список, а потом раскрою все пункты отдельно:

— Servers + Servlets +JSP;

— Web-services (SOAP, REST);

— SQL, HTML, JavaScript;

Core Java и ООП

Меня постоянно спрашивают, что я имею в виду под знанием ООП. Рассказываю. Прежде всего, это означает свободно ориентироваться в трёх принципах ООП. Понимать, как работает наследование и полиморфизм. То есть если один класс наследуется от другого, кого и к чему надо приводить, а что автоматически является экземпляром чего. Если у базового класса и у дочернего есть метод с одинаковой сигнатурой, то какие именно ограничения накладываются на типы принимаемых и возвращаемых значений, а также бросаемых исключений. Что будет в compilation time, а что в run time. Ну и так далее. Человек, который этого не понимает, нормальный код не напишет — это уже проверено. Лично мы таких просто не берем, даже если у человека хорошие знания фреймворков. Себе дороже будет потом его код поддерживать.

Из Core java нужно знать методы объекта Object и Collection Framework. Enterprise java — это на 90% ковыряние в разных коллекциях. От них никуда не уйдешь.

Так же часто спрашивают про concurrency. Отвечу несколько спорно, но по моему опыту так. Есть проекты, которые жестоко завязаны на многопоточность. Для найма в эти проекты вас буду жестоко гонять по concurrency. В других проектах многопоточности особо нет, и вас там про нее ничего не спросят. Думаю, общее представление иметь необходимо всем, учить ли глубже — сами решайте. Другой разговор, что есть множество собеседователей, которые страшно любят эту тему и будут вас по ней спрашивать, даже если для проекта это все нафиг не надо. Почему именно многопоточность пользуется у них такой большой любовью — тут я только руками развожу.

JDBC (Java Database Connectivity)

Зачем учить то, чем никто уже в чистом виде не пользуется? По двум причинам.

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

Во-вторых, под капотом у всех ORM-ов все равно лежит тот же самый старый добрый JDBC. И рано или поздно (скорее рано, чем поздно), когда у вас что-то сломается, вы увидите как раз ошибки JDBC. И с этим надо будет что-то делать

Servers

Тут все просто. Любой java разработчик должен знать Tomcat. Он самый простой, самый легкий и пожалуй, имеющий наибольшую knowledge base. Спрашивать на собеседовании о нем вас никто не будет — предполагается, что вы его и так знаете. Не знать томкет — это стыд и позор. Имейте в виду.

Дальше стоит изучать уже JBoss/WildFly — всё-таки многие J2EE технологии на томкете не работают (те же EJB или кластерное решение, хотя, может, я отстал от жизни). А вот JBoss/WildFly — как раз оптимален. Он бесплатен и вполне функционален. Никто не ожидает от новичка, что он взял и скачал где-то WebLogic и фигачит код под него. А вот знание JBoss/WildFly — самое оно. Более того, он частенько используется даже у серьезных заказчиков

Unix-like

Про знания юникса вас могут максимум спросить — владеете ли и на каком уровне. Сразу отвечаю — достаточно владеть на уровне пользователя. Запустить, остановить, воспользоваться SSH и SCP. Ну в общем-то и все.

Servlets + JSP

Этот пункт аналогичен пункту про JDBC. И встречаются они всё-таки иногда, и знание того, что под капотом более современных web фреймворков — очень полезно. Как минимум, сокращает время нахождения ошибки в разы. Лишним не будет. Да и спросить на собеседовании об этом вполне могут.

Spring

Знание спринга — ультимативно. Как минимум, потому что спринг — отраслевой стандарт. И не важно, нравится вам спринг или нет. Главное, чтобы вы его знали. С вероятностью 80% вы будете с ним работать уже на одном первых трёх проектов. Да и вообще, энтерпрайз разработчик не должен перебирать — это хочу, это не хочу. Взялись и работаем. Вот это как раз тот случай.

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

Объем знаний: уметь замепить отношения один-к-одному, один-ко-многим и многие-ко-многим. Написать HQL запрос и настроить лейзи загрузку.

Web-framework

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

Web-services (SOAP, REST)

Ну, с REST вообще всё просто. От джавера там нужно только аннотацию повесить. И в принципе представлять, как оно работает.

С SOAP сложнее — надо знать несколько ключевых слов, описать, для чего служит WSDL, ну и представлять общие основы протокола.

SQL, HTML, JavaScript

Знание SQL — ультимативно. Вы должны его знать на уровне джавы. Сейчас даже на проекты, использующие NoSQL базы, не берут без хорошего знания SQL. Что уж говорить об остальных. Почему он так нужен — объяснять не буду, но если вкратце — на SQL вы будете писать часто и много. Естественно, не хранимые процедуры (хотя это тоже не исключено, но это всё-таки экзотика), но запросы на вставку и проверку тестовых данных — очень часто.

Я не беру людей на должность в двух случаях. Если они заваливаются на первом пункте (Core Java и ООП) и на этом. Делайте выводы.

Знания скриптовых языков (sh, bash, perl &etc) — штука полезная. Как минимум, вы увеличиваете свои возможности по затыканию дыр — а это и есть основная суть работы на саппортовом проекте. Другой разговор, спрашивать вас об этом на собеседовании не будут, а выучить основы такого языка — дело пары дней. Так что я бы не советовал в это упираться.

Специфичные требования

Как выбрать специализацию

Очень советую всем начинающим программистам выбрать себе специализацию. Сейчас объясню, что я имею в виду. Мы все — java-разработчики. Ок, все знают джаву, все знают более менее полный стек наших фреймворков. Но, в любом проекте будет цениться человек, который реально хорошо знает один из нужных фреймворков. Например — гуру по Hibernate. Или гуру по какому-нибудь PrimeFaces. Или — мощный знаток Oracle DB.

В каком порядке всё это изучать

Значит так, сначала ставим цели. Мы должны добиться того, чтобы новичок не боялся чудовищного массива знаний и привык к тому, что всё он не будет знать никогда. И научился работать в ситуации неполного знания.

Пока методика выглядит следующей:

1. Погрузиться в сложные алгоритмические задачи. Главное, чтобы эти задачи еще не были реализованными в готовых библиотеках, и человек понимал, что задача относительно реальная. Например — вывести что-то отформатированное. Смысл: вызывать у человека понимание, что любая задача решаема. Просто нужно несколько дней подумать, покрутить задачу, и вот тогда все выйдет.

3. Научиться декомпозиции. Выбрать несколько предметных областей и порисовать по ним UML диаграммы. Это необходимо, чтобы просто понять — это и будет самым сложным в нашей работе. Единственное замечание — диаграммы должны проверяться опытным и толковым ментором. На этом этапе ментор просто необходим. Настроить свой мозг на вырезание скоупа проекта, на декомпозицию объектов и их взаимосвязей — это то, что само не придет, сколько не программируй.

4. Сделать код на основе результатов одной из декомпозиций. Этот код будет впоследствии нашим слоем бизнес-логики.

5. Начинать работу с базой. Освоить JDBC и все его части. Это будет существенно проще после предыдущего пункта. Код также необходимо показать ментору. Как показывает моя практика, многопоточность (которая в любом случае предполагается для этого кода) — штука не сразу лезущая в голову. Надо, чтобы вас направили.

6. Выучить основы веба и томкет. Надо сделать к вашей бизнес-логике и DAO layer последнюю оставшуюся часть — UI. Пока на сервлетах и JSP. Нужно сделать так, чтобы JSP обращались к бизнес-логике за ее данными. Та запрашивала данные из базы и возвращала их на View (JSP). По нажатию на кнопки в JSP управление передавалось в сервлеты, которые отправляли команды бизнес-логике на изменение состояния. А та, в свою очередь, меняла данные в базе с помощью DAO layer. И затем сервлеты отправляли управление обратно на JSP (например — редиректом), и затем все повторялось. Тут надо внимательно следить, чтобы никакие запросы от JSP не лезли в DAO layer.

7. Изучить возможности томкета. Создаем Data Source и работаем уже не с физическим коннектом, а с логическим, получая его через JNDI.

8. Освоить Spring. Все, что нужно сделать — проинжектить DataSource в нужные классы DAO Layer. Сначала — через XML конфигурацию, а потом — через аннотации. Этих знаний будет достаточно

9. Теперь можно вводить Hibernate через JPA аннотации. Смысла изучать меппинг-файлы я не вижу. Они уже почти нигде не используются. Заменяем весь код в DAO на HQL или Criteria. Что лучше пойдет.

10. Ну и наконец, самое веселое — выбираем фреймворк для морды. Я бы порекомендовал какой-то JSF или SpringMVC.

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

Обращаю внимание: перескакивать этапы крайне не советую.

Если у вас получится следовать этому плану, и ваш ментор окажется достаточно квалифицирован, всё будет отлично. И скоро на одного Java разработчика станет больше. Удачи вам!


Сергей Немчинский — разработчик с большим опытом и основатель учебного центра Foxminded. В мае он запустил короткий цикл из лекций о трех дорогах для развития программиста: эксперта, руководителя и основателя. В зависимости от того, по какой дороге идти, можно легко определять, какие решения принимать в работе и жизни, какие из них будут эффективны, а какие нет.

С разрешения Сергея мы публикуем все три видео и их текстовую расшифровку.

Дорога эксперта

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

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

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

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

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

Второй вариант — можно качать экспертизу в знаниях конкретных фреймворках или архитектуры в целом. В принципе, знания архитектуры в целом, к сожалению, у нас в стране [Украине] вообще пока не востребованы нигде. Это ужасно. Мне стыдно, мне кажется, что это кошмар. Более того, оно нихрена не востребовано на Западе практически, там больше требуется умение презентовать решения, может быть, даже не самые лучшие. Я надеюсь, это изменится, система становится все сложнее и потребность хорошей архитектуры рано или поздно возникнет. Так что вы вполне можете специализироваться на этом, изучая паттерны, изучая энтерпрайз-паттерны, изучая паттерны распределенных вычислений и чего-то еще, т. е. [от вас потребуется] понимание навыков построения сложных архитектур. Это классное направление, если вы в этом действительно станете офигенным экспертом, у вас и зарплата будет соответствующей, компании будут за вас бороться. Может быть, не прямо сейчас, но и вы не сможете это сделать за год, это несколько лет целенаправленной работы на прокачку своих знаний.

Знание конкретных фреймворков — это сейчас очень востребовано. Мега-специалисты, условно говоря, по Hibernate или по Spring Security и т. д. ценятся. Но там есть стеклянный потолок, больше определенной суммы вам все равно не заплатят в отличие от экспертизы в бизнес-анализе, где потолка практически нет. И вв отличие от экспертизы в архитектуре, где пока потолка нет, потому что мало людей, но рано или поздно, я уверен, должность солюшн-архитектора будет очень сильно востребована. Это будет человек, который строит всю огромную систему, всю огромную инфраструктуру. Я знаю, что во многих крупных компаниях такие должности есть, в том же Epam совершенно точно.

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

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

Дорога руководителя

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

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

Я увлекся на тот момент методологиями, начал изучать вопросы, связанные с методиками разработки: экстремальное программирование, скрам… Канбан на тот момент еще не появился. Меня настолько это все увлекло, я увидел, что на самом деле даже не связывал это с руководством людьми, я думал, что это просто приведение проекта к финальной точке.

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

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

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

Я видел много тимлидов, которые выгорели из-за того, что пытались на себе тянуть заодно и роль техлида. Это не реально, вы просто сгорите, не делайте так. Определитесь: техлид — человек, который идет потом в архитекторы, — это дорога эксперта; тимлид — человек, который потом идет в проджект-менеджеры, — это дорога менеджера.

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

Поэтому не обманывайте, говорите честно. Люди взрослые, люди все поймут. Это не значит, что если вас руководство попросило что-то не говорить команде, вы пошли и тут же рассказали. Иногда да, а иногда нет. Вы взрослый человек и должны понимать, что бывают ситуации, когда руководство не хочет доносить информацию, потому что оно слегка неправо, но команда нормально воспримет эту информацию. А бывают ситуации, где вы понимаете, что если эту информацию донести до команды, то она сейчас просто бросит работать.

Дорога основателя

Но сразу несколько дисклеймеров. Вы должны понимать, что в большинстве случаев как программист в найме вы заработаете больше, чем как руководитель собственной ИТ-компании. Как минимум вы будете меньше зарабатывать руководителем собственной компании на протяжение первых 2–3 лет. К этому надо быть готовым.

Если вы привыкли получать условные свои $3000 и они вам жмут, и на меньшее вы никак не готовы, то имейте в виду: скорее всего, дорога стать предпринимателем для вас будет очень тяжела. Я, например, первые полгода просто проедал свои запасы, а потом привык жить на существенно меньшую сумму. Если вы не готовы урезать свои интересы, то имейте в виду: вам нужно будет очень сильно [сначала] подкрепиться и проедать запасы существенно дольше. Т. е. на те самые $3000 в первое время выйти достаточно сложно.

Уровень стресса у владельца собственной компании в разы выше, чем у программиста или даже у проджект-менеджера. Этот уровень стресса будет вас преследовать всю вашу предпринимательскую жизнь, потому что сегодня у вас хорошо, завтра у вас плохо, тут поменялся рынок, там выпустили новый закон, который вас каким-то образом ограничил и создал ситуацию, когда вы вообще не можете работать. И, наоборот, возможно, что вам привалил какой-то дикий заказ, в который нужно срочно вцепиться зубами и как-то его выгрызть. Вы будете работать 24/7, падая, уставая, попадая в больницу с перенапряжением и т. д.

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

Говоря о том, как программисту стать предпринимателем, я бы выбрал тут два варианта, два способа того, как это может происходить.

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

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

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

Первые сотрудники, которых вы привлекаете, должны быть друзьями, которые вам доверяют, которым вы передаете заказ, может быть, даже полностью отдавая им их долю, чтобы выйти на рынок, чтобы вас запомнили. Но лучше все-так оставлять себе хотя бы 10, 15, 20, 30%. Причем, это не обворовывание людей. На вас будет очень большая ответственность, потому что именно вы будете выступать лицом вашей команды, которая впоследствии станет компанией. Именно вы будете отвечать перед заказчиками за то, что это исполнится. Именно вы вылетите с рынка, а не они — они пойдут к другим работодателям и будут там спокойненько работать. Именно ваша жопа рискует тем, что мечта не исполнится. Поэтому ваша доля там должна быть, пусть небольшая, но все равно должна.

Причем взять в штат и платить людям ежемесячную зарплату вы сможете очень нескоро. Только в тот момент, когда у вас будет постоянный приток этих заказов, и вы уже непосредственно сами не занимаетесь разработкой, а только поиском заказов, вот тогда можно брать людей в штат. Чтобы они постоянно находились у вас в доступе и решали за вас вопросы, связанные с работой вашего софта, вашей разработки. Но пока это достаточно сложная и тяжелая задача для вас.

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

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

1. Бездарная педагогика
"Даже если вы не можете связать двух слов, вы все равно можете продавать свои курсы в Интернете" - девиз JavaRush.
"Вроде и все делаю (бывает вообще легко), но вообще не до конца понимаю как это делаю, и почему" - комментарий одного из пользователей курса.

С первых же страниц курс JavaRush хвастливо заявляет: "Наш курс - это не какая-то там теория! Он на 80% состоит из практики, потому что лучший способ научиться программированию - это программировать!".

Что на самом деле кроется за этим маркетинговым слоганом?
Представьте на минутку, что вы никогда не пользовались автомобилем, не знаете как он устроен и как работает и вообще ничего в нем не понимаете.
И вот вы решили научиться водить авто.
Вы наняли инструктора, заплатили ему денег, пришли на занятие и спрашиваете его: "Расскажи мне как автомобиль устроен и работает? Как им пользоваться? Как вести себя на дороге? Как соблюдать ПДД и вообще какие ПДД есть?", а ответ слышите: "Знаешь, я не буду ничего тебе рассказывать. Лучший способ научиться водить - это водить. Вот тебе ключи, педаль газа слева, езжай сто километров в центр города, там я буду ждать тебя в кафешке, попивая лимонад".
Наверное, такого инструктора вы погоните поганой метлой, верно?
Ведь даже если вы не помрете по дороге в каком-нибудь ДТП (а попасть в него вероятность крайне высокая), ваш результат не будет воспроизводимым, то есть вам просто повезет, вы доедете по чистой случайности, а в следующий раз вам уже может не повезти.

Но именно на таком подходе обучения построен JavaRush.

Способ обучения, выбранный JavaRush - заведомо дефективный. Вас ничему не учат, а заставляют, как попугайчиков, повторять код или решать задачи наугад методом тыка, не объяснив, как их решать.

Правильный способ преподавания - это когда вам дают теоретический материал, нужный для понимания того, как что устроено и работает, а потом предлагают закрепить его на практических задачах (вспомните школьный курс математики, вам разве давали решать примеры, не объяснив формулу? Будь это так, решили бы вы хоть один пример в своей жизни?).
Почему же выбран такой заведомо неэффективный способ обучения? Потому что он самый легкий в реализации.
Чтобы объяснить неподготовленному читателю сложные вещи понятным языком на простых примерах, нужны недюжие педагогические способности.
Более того, информация должна подаваться строго последовательно, объяснять новую тему можно только понятиями, которые уже были объяснены раньше, ведь если объяснять новую тему терминами и конструкциями из других непройденных тем, человек же ничего не поймет. Представьте, что вы учите английский язык и вам объясняют правило грамматики, используя английские слова, которые вы еще не учили. Поймете что-нибудь? Нет, конечно.
Поэтому для правильного построения учебного курса нужны не только педагогические навыки, но глубокая проработка материала, его хорошее понимание, тонна времени и стараний.
А педагогических способностей у авторов JavaRush нет, время и старания они вкладывать не хотят, поэтому внятное изложение теоретического материала они обеспечить не смогли, и чтобы продать свой курс они просто вешают лапшу на уши, что так даже лучше.
Нет, не лучше.
Вы будете, как и многие другие пользователи, битый час ломать голову над решением задачи, которую решили бы за минуту, прочитав две строчки внятного объяснения в книге Хорстманна. А если все-таки решите, то не поймете, как вы ее решили, или, что еще хуже и более вероятно, поймете неправильно, но будете думать, что поняли правильно.
Все непонимание вы будете восполнять своими выводами о том, как что устроено и работает, а они будут неверными в большинстве случаев. И на эти неверные выводы вы потом будете пытаться нанизывать новые знания, формировать представление о языке, чтобы потом узнать, что, оказывается, вы всю жизнь прожили зря, были неправы и надо переучиваться.
В конечном итоге, за объяснением каждой темы вам придется обращаться к посторонним источникам. Постоянно. Так может лучше сразу по ним и учиться?

2. Если в мире кончится пресная вода, JavaRush решит эту проблему без труда!

Как мы выяснили в предыдущем пункте, внятного и детального изложения материала в этом курсе нет. А что же в нем тогда есть вместо него?
А вместо него вам просто суют в лицо какие-то имбецильные диалоги двух мертворожденных пингвинов сомнительной художественной ценности.
Большую часть времени вы будете читать всякую ерунду, типа "-Превед, Омиго! Каг дила? Пайдем кодить? - Йа Омиго и мине фсе панятна! Пасиба за апъяснения!" вместо того, чтобы читать материал по теме.
Писать глупые диалоги уровня недалекого школьника из 5 класса может любой и это гораздо проще, чем толково и лаконично объяснить учебный материал. Поэтому этим способом авторы JavaRush и воспользовались.

3. Бездарен в одном - бездарен во всем.

JavaRush хвастается тем, что у них более 1200 упражнений.
Если отбросить тот факт, что понимать, как их решать, вы не будете, потому что вам не дают нужный учебный материал, и предположить, что всю теорию вы будете брать в другом месте (например, в книгах Кея Хорстманна или книге Васильева А. Н. "Программирование на Java для начинающих", которую я могу посоветовать, хотя бы потому, что она написана довольно понятно, исчерпывающе, точно и на русском языке, то есть проблем из-за кривого перевода у вас не будет, плюс стоит всего рублей 700), то даже в этом аспекте JavaRush облажались.
Почему?
А давайте разберемся, что подразумевается под "1200+ задач".
Чтобы вы понимали, задачи: "Выведи на экран строчку "Курс JavaRush - пустая трата денег" и "Выведи на экран строчку "Я выбросил на ветер 18 000 рублей" - это две разные задачи.
То есть такое большое количество тренировочных задач достигнуто просто за счет того, что они сделали по 500 вариантов одной и той же задачи, лишь заменив некоторые значения.
Это настолько нагло, что уже совсем не смешно.

4. Решить нельзя помиловать

5. JavaRush – платформа для общения, в которой нельзя общаться.

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

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

В общем, все плохо и глупо и в этом аспекте тоже.

6. 45 - баба ягодка опять!

Курс JavaRush - устаревший.
Он не обновляется под изменения языка.
В курсе есть перевод цикла гарвардских лекций CS50 (неплохой курс), но:
1) Он тоже старый - 2015/2016 учебного года, а с тех пор произошло много изменений, многое из старой версии курса уже просто не работает.
2) Он доступен бесплатно в интернете.
3) В интернете есть бесплатно еще более крутой цикл лекций от российского преподавателя Тимофея Хирьянова (курс лекций "Алгоритмы на Python" ищите в Ютубе, их материал применим и для Java). Например, он на примере сказки про репку и матрешки объяснил что такое рекурсия, причем объяснил точно, а не скомкано и невнятно - это уровень педагогики, который JavaRush никогда не достичь. За одну часовую лекцию он рассказал о том, что такое системы счисления, какие они бывают, как устроены, объяснил как считать в двоичной, четверичной, восьмеричной, десятичной и шестнадцатиричной системах и на ходу переводить числа из одной в другую, а еще зачем это нужно и где используется. Чтобы вы понимали, для сравнения, в курсе CS50 за часовую лекцию объяснили только как нолики и единички подставлять в двоичной системе, зато сделали это так помпезно, будто эликсир вечной жизни у вас на глазах изобрели.

Так вопрос: зачем вам платить за старье? Еще и такие деньги, которые они просят?

Читайте также: