Category: Студентам

Программерия - это алхимия

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

Как стать программистом? Что учить программисту?

Наша профессия одна из сложнейших и каждая программа по своему уникальна. Кроме самого программирования как такового нужно обязательно знать множество других смежных вещей которые помогают конструировать ПО. Мы ещё плохо понимаем как правильно разрабатывать программы и каждый раз мы пытаемся предугадать её будущее изменение и много экспериментируем переосмысливая свой опыт. Всё это очень похоже на Алхимию.
И подобно как из Алхимии родилась Химия, также из Программирования рождается новая наука Программерия. Что это, и как она помогает современному программисту читайте в моей статье Программерия, или что нужно знать программисту.

Похожие статьи

Итак, вы решили стать программистом
Что нужно знать каждому программисту по версии Google! (eng)
Программирование — занятие не для каждого
Писать код уже не достаточно: обязанности современных back-end разработчиков
Как стать программистом?
Путь программиста: через что придется пройти джуниору, чтобы стать синиором
Путь программиста
Карта программиста
Что должен знать html-верстальщик?
Почему разработчик — не инженер

Хороший институт не даёт хорошего образования

Где лучше учат, в Стенфорде или в академии ШАГ а может и вовсе на дешёвых курсах?

Не имеет никакой роли. Вот прям совсем. Как бы тебе не разжёвывали, тебе всё равно придётся самому это «проглотить». Чему бы тебя не учили — почти невозможно придумать идеальную программу которая подходит всем. Как бы хорошо ты не запомнил — ты всё равно забудешь без практики.
Невозможно сказать что факультет плохой или хороший. Может быть хороший преподаватель — но его «хорошовизна» может определятся только его способностью определить что нужно студенту и подогнать обучающую программу под него. Это то что называется «объясняет».
Более того, может быть реально прекрасный преподаватель, но его стиль обучения не совпадает со стилем обучения студента.
Давайте я объясню подробнее что я имею в виду. Например у меня стиль обучения такой: я не читаю никаких книжек и вообще ничего. Я тупо «интуитивно» пытаюсь угадать как должно быть и пытаюсь это сделать.
Я делал довольно сложные программы, и при этом неплохо написанные и удачно декомпозированные при этом вообще не понимая ООП. Более того, у меня даже книжки не было по Делфи.
Но со временем у меня вдруг включается другой режим — и я вдруг вчитываюсь в матчасть и подробно её изучая. При этом когда читаю документацию я её как бы сканирую и пытаюсь найти «потаённые» штуки которые могут мне пригодится.
Я пытаюсь первым делом понять как и для чего использовать эти знания, а потом уже изучаю их глубже только ради того чтобы узнать как можно ещё лучше их использовать. Сами по себе мне эти знания не очень-то интересны.
Т.е. мой стиль обучения мне помогает в моей работе программиста — я так быстро осваиваю технологии и перехожу с одной на другую. Но мне бывает очень тяжело изучить что-то в деталях.
И я прям совсем не могу быть, что называется, учёным. Мой мозг бунтует и отказывается принимать знания если я не понял как конкретно их применять. И я бы никогда бы не смог заниматься наукой ради науки. Люди вроде Буля, который придумал дискретную алгебру, для меня какие-то прям супергерои — они придумали что-то, что нашло применение только столетия спустя.
Теперь смотри, я такой студент, я мотивирован, я что-то там может даже соображаю. Но мой преподаватель даёт информацию подробно разжёвывая с объяснением. Например мы проходим побитовые операции. Мне они не интересны, но мне подробно и очень хорошо рассказывают все эти нюансы. Я начинаю скучать и тупо вырубаюсь на лекции.
С формальной точки зрения — я получил отличное образование. С практической полный ноль.
Я был бы неуспевающим и меня бы отчислили.
Я не очень ковырял эту тему но видел какие-то более менее вменяемые объяснения что такое Стиль обучения в соционике и на Википедии.
В действительности я насколько понимаю эта область граничит с нейробиологией, психологией и педагогикой и довольно слабо изучено.
Поэтому нужно просто признать — сегодня наверное никто не знает как правильно учиться и учить.
Это настолько индивидуально и требует длительного наблюдения что с этим смогут справляться только когда технологии Big Data помогут проанализировать и делать какие-то статистически подтверждённые утверждения как эффективно учить.
А теперь умножьте это на компьютерные науки которые сегодня являются во многом синтетическими а не природными, а значит могут сильно меняться и отличаться. И во много являются «алхимией», «шаманством» или «искусством», т.е. мы признаём что тупо не знаем как оно работает и должно проектироваться.

Как определить что вы учите примерно правильно и примерно оптимально, по крайней мере для определённой категории людей? Очень просто — если вам платят значит вы в правильном направлении. Если вам платят значит ваши студенты всё таки имеют больше шансов на устройство. Если они устраиваются значит они могут справляться с работой.
Рынок, рынок всё решает.

По мотивам обсуждения на форуме Стремительный рост КА ШАГ

Скринкаст: Пишем калькулятор на Java, JavaFX, Groovy, Spock, Kotlin

Несколько вечеров за которые я написал калькулятор на Джаве с тестами на Груви а потом переписал на Котлин. Интересно будет только для Stong Junior’ов

Это не туториал! В обычных туториалах всё хорошо и сразу получается, но как только начинающий программист сталкивается с ошибкой то не знает как дальше двигаться. Здесь все по настоящему — часть я знаю, часть изучаю сразу же. На ваших глазах появляются и фиксятся баги, гуглится и копипастится с СтекОверфлоу. Это может быть вам полезно для того чтобы ощутить эвристики которые помогают мне.
Скучно, занудно — но именно так примерно мы и программируем целыми днями. Если вы думаете связать свою жизнь с этим ремеслом, можете прочувствовать себя в моей шкуре 😉

Исходный код:
https://github.com/stokito/javafx-calculator

P.S. Да, я знаю звук отвратительный, винда неудачно обнволялась и с драйвером звука какая-то ерунда.

Как быстро можно стать Java Junior?

Максим Педич поделился опытом: для того чтобы изучить Джаву с нуля нужно пол года активного вкалывания.

Макс Криворучко дополнил

Чтобы стать программистом (читай освоить Java core) нужно пол года. Чтобы стать интересным для компаний программистом нужно знать кроме Java Core как минимум еще и тулы (maven/gradle, svn/git), jdbc, Servlet API, Spring (IoC). Было бы хорошо знать еще и html, sql, xml на базовом уровне.

В случае знания Java Core светить может интернатура,

во втотом случае — могут взять джуном.

Самое главное: по каждой теме иметь практику. И чем ее больше — тем лучше. Даже читая книгу, в которой примеры кода — нужно как обезьяна его перепечатать в IDE и запустить.

чтобы стать джуном нужно год-полтора


Не поленитесь, и почитайте ещё несколько очень важных моих статей для начинающих программистов, студентов и джуниоров.
Также не забудьте вступить в группу IT Juniors куда я пытаюсь собирать ссылки на другие полезные статьи для вас и анонсы курсов и интернатуры в компаниях.

Частые вопросы Java Juniors

Ко мне в последнее время было много вопросов от Джава Джуниоров, запишу по памяти что отвечал:

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

У меня нет, а если бы и были то не дал. Это не честно, это всё равно что на экзамен прийти зная что за билеты.
Каждая компания старается задавать свои вопросы чтобы лучше узнать уровень соискателя. Они их придумывают, они не хотят чтобы эти вопросы другие знали, это их авторские права в конце концов.
Эта информация практически с грифом для служебного пользователя и не распространяется. Точно также как не распространяется информация о том какие грейды разработчиков (уровни Мидл, Синьёр) потому что в каждой компании разный уровень и по этой информации можно определить насколько в целом уровень профессионализма в ней.

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

Есть часть вопросов которые практически стандартные, и их легко найти в интернете.
Например: «Чем отличается абстрактный класс от интерфейса?»
И даже если вы ответите на этот вопрос, то его можно немного перефразировать или усложнить.
Например на вопрос «Чем List отличается от Set?» можно задать следующий вопрос «А почему Set не наследуется от List если он по сути похож, разве что не позволяет сохранять дубликаты?».
Ответ уже на этот вопрос потребует от вас именно полного понимания темы.

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

Большинство вопросов идут из сертификации OCJP их легко найти и есть книги для подготовки по теме.

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

А пример проектика?

Опять таки, нельзя. Вам вышлют тестовое задание или вы можете в резюме указать ссылку на свой проект с исходниками. Если интервьюеру будет интересно он сам зайдёт посмотрит какой код вы пишите, оценит уровень и будет спрашивать уже более предметно.

Как правило, если это вакансия для веб разработчика, вас попросят написать простое CRUD приложение, например TODO лист с использованием БД.

а сколько по времени должно примерно уходить на его выполнение?

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

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

Что учить?

Только то что востребовано на рынке и за что больше платят. Например, может Ruby on Rails или какой нибудь Python и кажутся вам самыми модными, но вакансий намного меньше чем на Java или PHP. А из Java и PHP больше платят за Java. Следовательно её и нужно учить (по крайней мере сегодня).

Походите по сайтам работы, посмотрите вакансии, почитайте в Википедии что за технологии там описаны. Зайдите на сайт indeed.com и посмотрите какие там тренды.

Что сегодня на рынке востребовано я точно не скажу. Что будет востребовано в будущем вообще никто точно сказать не может. Может новую версию PHP доведут до ума, а может все вообще перейдут на MPS.
Всё меняется, елси раньше Хибернет был «маст хэв» то сегодня уже, насколько я могу судить, работодатели уже интересуются знанием NoSQL баз данных, в частности MongoDB. А Hibernate им уже может быть не принципиально.

На сегодняшний день в принципе ещё актуальная моя старая статья. Её может и стоит переписать или дополнить, но в целом там описывается подход по которому вы сможете немного сориентироваться на рынке, а он не меняется.

1) Какими веб технологиями должен обладать хороший программист на Java? Sping, JDBC, Hibernate? Что еще? Есть ли смысл читать книги по этим технологиям или хватает спецификации / туториалов?

Точно нужно вникнуть в базовые технологии. Если с БД то в Java вы не опуститесь ниже JDBC, если делайте веб то ниже уровня JSP и Servlets вы не уйдёте. Поэтому с ними нужно точно разобраться. Поэтому может быть лучше вместо знаний Hibernate и Spring вникнуть в базовые JDBC и Servlets.
Скорее всего вас будут их спрашивать. Но тем не менее Хайбернейт и Спринг нужно тоже как минимум потрогать чтобы знать что это и куда его пихать.
Есть ли смысл читать книги — да. В книгах обычно пишут почему спроектированно именно так, т.е. передают некую инженерную мудрость которая намного ценнее чем даже знание самой технологии. Вы можете прочесть книгу по Спрингу и применить знания если вы нашли работу в ASP.NET где те же самые контроллеры.
Поэтому одна из самых важных книг по Джаве так и называется — Философия Java.

Туториалы нужны для того чтобы быстро и пошагово развернуть у себя проект с их использованием и чтобы вы могли сами прощупать как это делается. Это тоже важно — это мышечная память, без этого знания не зафиксируются в голове.
Вот недавно был выпуск подкаста Разбор полётов где как раз гуру давали рекомендации. И смысл такой: знаний Спринга у тебя может и не быть, это нормально для джуна, даже было бы удивительно если бы они были.
Но фундаментальные знания которые написаны в книгах у тебя должны быть, потому что интервьюверы хотят прежде всего понять насколько ты вообще обучаемый.
Если ты не смог прочесть и понять книжку, то как же ты будешь разбираться с кодом на работе?
Некий мифический параметр «Обучаемость» это то что они хотят вычислить прежде всего. Но это практически только интуитивно можно определить.
Есть и другие параметры, например знание конкретной технологии. Например работа на которую тебя рассматривают требуют чтобы ты занимался больше фронтендом и нужно там разобраться с CSS3 и HTML5. Может даже быть что в той команде никто их не знает толком и ты как джун там будешь их же обучать.
Я знаю такой реальный случай, там даже было неловко тимлиду который собеседовал джуна потому что он не знал что спрашивать по CSS3 (как там анимации делать, например), потому что он сам не знал, но на проект такой человек был нужен.
Ты может даже не очень обучаем и тебе сложнее въезжать в тему, но зато ты очень прилежный и исполнительный. И тебя могут взять вместо другого более «обучаемого» и опытного джуна. Или ты может просто прикольный весельчак и тебя возьмут разбавить команду нердов. Знаю случай когда девочку взяли в команду из девяти пацанов чтобы они хоть бриться начали 🙂

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

2) Посоветуйте литературу по архитектуре / паттернам. По паттернам читал книгу headfirst, но она, видимо, не очень глубоко описывает все. Есть ли альтернатива банде четырех не с кодом на С++?

Тут сразу нужно разделить два понятия: ты либо имеешь опыт программирования на других языках, например ПХП, а теперь учишь Джаву либо ты вообще студент и толкового опыта программирования у тебя нет.
В первом случае, тебе лучше взять книгу по языку программирования который ты лучше знаешь, просто ищешь по запросу, например «Шаблоны проектирования в PHP». И вникаешь на одном языке.
Паттерны практически не зависимы от языка программирования, поэтому главное понять их суть, а там уже на Джаве напишешь и сам. Но опять таки, половина шаблонов проектирования нафиг не не нужны в функциональных языках программирования где всё делается простой кложурой
Functional programming patterns

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

Опять таки, для базовых ООП языков C++, Java, C# и даже PHP реализации шаблонов будут одинаковы. Но в отличии от PHP в Java все вообще представлено объектами и в ней без шаблонов не выжить.

Изначально само понятие «паттерны проектирования» и их классификацию ввели GoF в своей книге. Соответственно те шаблоны которые они в ней описали называют «паттерны по Гофу».
Просто потом всем так понравилось понятие паттернов что каждый поупражнялся в интеллекте и напридумали ещё потом тысячу других паттернов и даже антипаттернов.
Но больше ничем примечательным их книга не отличается — ни доступностью материала, ни даже полнотой. Именно поэтому есть более поздние книги где лучше разжёвано с большим числом примеров и с конкретными особенностями платформы.
Иногда может хватить статьи на Хабре, благо их валом.
Лично мне ещё было проще: мне мой ментор сказал «ну вот помнишь как Xml парсер ты создаёшь? Ну вот, это абстрактная фабрика» или «ну вот тебе нужно получить неизменяемый List, для этого есть метод Collections.unmodifableList(myList) который вернёт тебе декоратор myList с скопироваными элементами который на самом деле будет подклассом UnmodifableArrayList с заглушками на методы add() и remove(). Но это от тебя скрыто за методом unmodifableList() и тебя вообщем и не интересует какой там класс реально будет.».
И всё стало сразу мне понятно: «Тю, так я эти шаблоны постоянно использовал! Просто не знал что у них есть названия».
Вот в том и смысл: шаблоны, точно также как и рефакторинги — это классификация для программистов чтобы им было проще общаться между собой: «Слушай, а давай здесь выделим интерфейс и сделаем фабрику?».
Поэтому вся ценность паттернов — это то знают ли их. А все остальные шаблоны можно смело выкидывать потому что пользы от них нет. Это обычные структурные конструкции которых может быть безграничное количество и смысла им давать свои имена нет.
Поэтому когда говорим паттерн — подразумеваем паттерны ГоФ, и то только ту часть что используем.

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

Поэтому отнеситесь к книге Head First как к комиксу «как сделать коронарное шунтирование сердца».

А вот что намного важнее понять, это когда именно нужно применять и какой именно шаблон. К этому можно только прийти постепенно изменяя код с помощью рефакторинга.
И соответственно самые лучшие книжки про шаблоны проектирования — это книжки не про паттерны, а про рефакторинг.
Я уже повторял неоднократно и не постесняюсь ещё раз повторить, что лучшая книга для того чтобы разобраться как лучше проектировать архитектуру, писать код, писать тесты, и сопровождать его, это бестселлер Матрина Фаулера «Рефакторинг — улучшение существующего кода».
Рефаткоринг

Более полезной, монументальной, теоретической и практической одновременно книги я ещё не видел. Она сразу выводит на новый уровень профессионального мышления.
Даже нет смысла искать работу пока вы её не прочли и не осознали.

Для чуть опытных программистов есть более продвинутая книга Джошуа Кириевски которая так и называется Refactoring to Patterns. Я её сам правда как-то так и не прочёл, но все знакомые кто читал были в восторге.

А вообще я не понимаю почему джуны так сильно зацикливаются на паттернах. И зачем их спрашивают на интервью. Когда я искал себе работу и меня спрашивали по шаблонам то вопрос звучал примерно так «расскажи хоть какой нибудь шаблон». И я просто заучил их и по очереди называл их названия всех 23х шаблонов. И каждый раз интервьюеры офигевали «ого, это их столько? А можешь хоть один объяснить». И я рассказывал про один из трёх которые я реально понял. Интервьюер как правило знал столько же.

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

Поэтому у нас есть такие наумняченные программисты которые могут отличить Прокси от Декоратора, а при этом не знают комбинацию клавиш в IDE для форматирования когда.

Так что вы поймите хоть парочку шаблонов, желательно из разных групп, например структурный — Декоратор, creational — Singleton и behavioral — Observer. Это реально, остальные просто знайте что есть. Для джуна это нормально.

3) Как вы относитесь к различным онлайн курсам типа: курсера. юдасити. У меня начинает складываться впечатление, что там знания дают довольно поверхностные и много воды. Что Вы используете в большей степени при самообучении? Возможно посоветуете ресурсы?

У меня тоже впечатление, но это впечатление. Тут довольно сложная и большая тема возникает о самом формате обучения, у меня по этому поводу очень много мыслей но не все ещё сформулировал для себя. Если в двух словах то примерно такие мысли:
* Курсера — это всё таки курсы солидных унверситетов, это уже вызывает доверие. Это годами отработанные обучающие материалы, и они там не зря. Зарплаты преподавателей огромны, и это люди как правило имеющие отношение к реальной индустрии.
* Качество курсов от чуть ниже нормального до хорошего. Отлично сделать практически невозможно, всегда будет какая-то вода, всегда будут недостаточно хорошие примеры. Всегда может быть по теме более интересная книга или туториал на ютубе, всегда можно найти чувака который лучше расскажет, но на курсе всегда будет некая усреднённая доведённая до занудства «академичная» информация.
* Что ещё важно там есть вопросы для самопроверки и определённая сертификация. Это очень важно, а просто книга такого не даст.

Всё. Больше никаких особо преимуществ нет и быть не может. На курсере невозможно получить практическую пользу и интерес большую чем от реального проекта или видео на ютубе.
Это всё равно что сравнивать статью в Википедии и статью на Хабре.
Но если взять статью на хабре и дописать к ней то что в ней опустили, и убрать то что может меняться со временем, попытаться вывести из материала какие-то общие законы и убрать субъективный и упрощённый научно-популярный стиль, то получится та же статья с Википедии.
Например, вот одна из самых первых статьей про Юнит тестирование за 2008й год к тому моменту это уже докатилось до нас и было отхоливорено со всех сторон и эта статья была подведением черты.
А вот какая статья в Википедии на сегодня.
А вот все курсы на Курсере где тебя обучат рефакторингу.

Например я бы мог в сто раз лучше базы данных чем на курсере, но я бы два года составлял курс прорабатывая материал, отбирая что важно что не важно, прийдя к выводу что всё важно, тестируя эффективность на студентах и он бы у меня разросся в пять раз больше и я бы стал его сокращать а на выходе получилось бы почти тоже самое что сейчас на курсе Introduction to Databases.

Нужно чётко осознать важный закон: кто не знает, но умеет — делает, кто знает, но не умеет — учит, кто не знает и не умеет — руководит.

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

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

Но где же найти тех кто реально шарит, и рассказать может хорошо и правильно, и самый свежий опыт?
Собственно мы программисты постоянно и много обучаемся, поэтому уже всё сформировали для себя:
* Блоги, правки в документации, меил листы, форумы, StackOverflow, скринкасты, туториалы, и напрямую чтение спецификаций. Написать более менее толковую развёрнутую статью занимает ну просто дофигища времени, сколько точно не знаю, зависит, но четыре часа минимум. А теперь представь что ты синьйор с загруженным графиком, у тебя семья, как ты выдыхаешься и при этом найти время и силы написать статью. А потом ещё переругаться с тролями в каментах.
* Конференции с докладами по часу-два с презентацией или мастер классом с живым кодированием. На подготовку одного часового доклада может уйти почти столько же времени как на статью, но, статью нужно писать и это напрягает, а презентацию к докладу накидывать как-то намного приятнее и там рассказывать можно голосом по ходу подстраиваясь под публику.
* Книги, программисты читают много их.

Итак, наиболее эффективными и ценными являются именно конференции с докладами. Там можно получить самый свежий опыт, и даже зачастую от самих создателей технологии.
Там же разворачиваются самые интересные дискуссии.
Но проблема в том, что как правило новичкам это совсем не подходит, это наиболее ценно для мидлов.
Рассказывать какие-то основы для джунов им не интересно. Это всё равно что если Шекспира попросить стать учителем английского. Да он сам создавал этот английский.

Так что пока вы джуны и вы учитесь, вам просто придётся всё время искать самим хорошую информацию по кускам и смирится что та полная что есть «академическая» скучная и с множеством воды. И постоянно искать себе менторов и спрашивать у них что нужно именно на практике. На примере шаблонов я это показал. Ваша задача — как можно быстрее устроится на работу, а там уже будет точно видно что нужно а что нет.

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

Я сам почти не проходил никаких курсов на Курсере (где же взять 8 недель на это?), но из того что видел считаю самым полезным и вменяемым курс основам вычтехники The Hardware/Software Interface. Тут вам расскажут как работает булева алгебра, как устроен компьютер, как считаются и складываются числа внутри, что такое указатели, освоите основы Си и перейдёте к высокоуровневым языкам. При этом это полноценный курс с множеством классных заданий.
Это очень и очень правильный курс который закрывает огромный пробел знаний и почти полностью имеет практическую пользу. Всё остальное что на курсере по компьютерам, имхо можно выкинуть нафиг. Разве что по алгоритмам может адекватный курс, но не смотрел.

4) Хочу начать делать какой-то пет проект, но не очень представляю с чего приступить.

блядь, просто начни

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

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

Могу дополнить только что у вас должна быть личная мотивация и интерес сделать проект. А такое может быть только если вы делаете программу для себя.
Например мой знакомый когда учил английский сделал себе программу под 1С с тестом слов. Потом когда он учил Джаву он себе написал фотовьювер как ему нравился.
Напиши любую программу например свой броузер. Джаст фор фан, пофигу что такое уже есть. А вдруг в твоей программе будет (или не будет) такой функционал который кому-то нужен. Твоя программа может найти своего пользователя и вырасти в полноценный продукт, как это было например с операционной системой Linux которую написал школьник а теперь используется многомиллиардными корпорациями.

Тут я могу ещё посоветовать не зацикливаться на технологиях. Просто некоторые начинают: о блин, мне тут нужно всё делать со Спрингом и Хибернейтом потому что их требуют при устройстве на работу. Забей. Сделай просто для себя программу на чём сможешь. Опять таки, парень который написал себе фотовьювер потом прошёл туториал по спрингу и нашёл себе работу.

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

Но.
Есть очень много софта который поддерживает плагины. И вот тут получается ситуация что ты делаешь свой проект в рамках другого, т.е. разбираешься с их кодом и у тебя есть примеры других плагинов, но при этом то что ты напишешь это твой отдельный проект.
Это такой симбиоз и очень классно работает на практике. Более того, у меня в университете один более менее вменяемый препод прямо так и давал задание написать плагин в Тотал Командеру.
Я например так когда-то написал плагин для Pidgin где мне пришлось изучить Си, программирование под Линукс и много ещё чего.

Ещё советуют брать заказы на фрилансе, но это тоже бред. Никто вам ничего нормального не доверит.

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

Что реально ещё работает: у Гугла есть программа Summer of Code и в её рамках можно поконрибьютить в опенсорс проекте под присмотром менторов. Опенсорс проекты готовят задачи для студентов и вместе их фигачат.
Вот например есть интересная программа для чата и онлайн звонков Jitsi и её страница с идеями для GSoC.
Задачи довольно интересные и в меру сложные.

5) Посоветуйте проекты с открытым кодом на Java, чтобы посмотреть как строиться архитектура и тд.

Опять таки, берите проект с плагинами и пишите свой плагин. А так, я не знаю что посоветовать, но есть например книга The Architecture of Open Source Applications и в ней же есть и описание тай же Jisti.
Вот посмотри исходники проектов из этой книги.

6) Как вы совмещаете изучение теории и практики? Предпочитаете читать только то, что в данный момент необходимо или же изучаете наперед?

Сначала немного наперёд, точнее обзорно по сторонам, потом углубляюсь. В принципе сейчас я знаю что есть что кругом и теперь точно знаю что мне именно нужно. Так что моя теория теперь почти полностью совпадает с практикой.

P.S. Статью написал под эту песню


Не поленитесь, и почитайте ещё несколько очень важных моих статей для начинающих программистов, студентов и джуниоров.
Также не забудьте вступить в группу IT Juniors куда я пытаюсь собирать ссылки на другие полезные статьи для вас и анонсы курсов и интернатуры в компаниях.

Что главное чтобы устроиться на работу программистом студенту? Законченный проект!

Я заметил что у студентов и джуниоров которые ищут себе первую работу программистом обычно возникают такие вопросы и проблемы:

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

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

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

Так что если вы думаете что вы тупой и не гений то не надо боятся идти в программирование. Даже наоборот, лучше и проще код писать будете 😉

Точно так же частый вопрос: «мне уже %ВАШ_ВОЗРАСТ% не поздно ли заняться программированием? Или уже идти на кладбище?».
Эта тема регулярно всплывает на форумах, и раскрыта там вполне. Будет тяжелей, но всё возможно.

Самое главное чтобы вам было просто интересно программировать. Остальное вторично.

1. Что учить? Какие языки программирования?

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

Обычно с первого языка ты всё равно скорее всего будешь переходить на другой язык.
Но лучше всё таки начать обучение с более классических языков типа C, C++, C# и Java, и которые более менее спроектированы а не такой язык в который всё навалено в кучу как в PHP или Basic. Но не парьтесь особо.

В любом случае, вам главное сначала научится программировать вообще, а потом уже посмотрите что там на рынке и выучите другое. Но если вы не хотите терять время, то лично я советую всё таки учить Java.

3. Учится, учится, и ещё раз учится, а потом учится, учиться, учиться….
И вот ребята уже учит и даже могут пописать код, и вот уже как бы пора бы работу искать.

Я заметил у студентов и джуноров которые ищут себе первую работу программистом одну проблему.
Почти все из них штудируют книги и учебники, даже уже читают шаблоны проектирования, но не знают когда остановится и как же всё таки найти себе работу.
И часто меня спрашивают что-то такое от чего я в шоке, например «А стоит ли учить шаблоны GRASP?».
O_o о боже, да я вообще про них в первые слышу 🙂 Нафига оно тебе?

Ребята, не перезатягивайте.

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

Как можно научится танцевать по книгам? Как можно понять шаблоны проектирования не написав тонны быдлокода и не пересмотрев гибибиты исходников библиотек?

Никак

4. Придумайте себе проект, ёпта!
Иногда джуны в этот момент подвисают и говорят: «та у меня фантазии нет чтобы придумать программу».
Я просто в шоке от такого. Это как это «нет фантазии»? Приятель, а ты уверен что правильно выбрал профессию?

Да блин, я когда дорвался до компьютер мне так и хотелось творить нон стоп. И пофигу что. Мне не понравился калькулятор — я написал свой калькулятор с преферансом  и куртизанками. Свой арканоид, свой сайт итд.
Я обычно даю такой совет: напишите программу для себя. Лично мне понравилось в университете все задачи по математике решать своей программой. Мат алгоритмы прекрасно программируются.
Например решение системы линейных уравнений методом Гаусса — там вам и циклы, и работа с динамическими массивами или вот вам прям задачи для начинающих Java программистов.
Такие задачки отлично тренируют умение структурного программирования.

5. Что нужно уметь программисту?

По сути, вся эта алхимия программирования на самом деле состоит из таких компонентов:

  1.  Собственно структурное программирование: как объявлять переменную, функцию, как писать условный оператор if, приоритет операторов, как организовать цикл, как получить ввод от пользователя и как ему вывести. Это легкотня на самом деле: 15ть операторов, учатся быстро. Почти все языки программирования наследуются от Си (C++, Java, C#, PHP) так что переучивать их не придётся. Это как базовая грамота.
  2. Алгоритмизация: линейный поиск перебором, бинарный поиск, пузырьковая сортировка, быстрая сортировка итд.
  3. Организация и проектирование программы: объектно ориентированное программирование, шаблоны проектирования.
  4. Знание платформы, библиотек и технологий: Java Core, XML, работа с файлами, работа с сетью, работа с массивами, строками и коллекциями.
  5. Умение писать чистый код: как правильно называть переменные и классы, как форматировать код, как правильно писать комментарии, ну то есть как их. не писать 🙂 Понимание приходит после прочтения книги Clean Code
  6. Умение работать с кодом: рефакторинг (книга Фаулера), хоткеи IDE для рефакторинга.
  7. Инженерные практики: юнит тесты, экстремальное программирование (XP), непрерывная интеграция, системы управления версиями (Git, SVN)
  8. Управление проектом и организация процесса: Agile, RUP, SCRUM, Kanban
  9. Умение общаться с закачиком и ладить в команде.
  10. Знание английского языка, умение чётко и лаконично писать документацию.

Как видите этот список можно продолжать, но вы должны понять главное: именно само программирование это совсем чуть-чуть. Все остальные пункты приходят с опытом и постоянным чтением правильных книг.

Не зависайте. Вкалывайте, делайте проекты и ищите работу.
Успехов!


Не поленитесь, и почитайте ещё несколько очень важных моих статей для начинающих программистов, студентов и джуниоров.
Также не забудьте вступить в группу IT Juniors куда я пытаюсь собирать ссылки на другие полезные статьи для вас и анонсы курсов и интернатуры в компаниях.