Всем привет. С Вами WiseMan.
Настало время затронуть тему которой интересуются многие.
Как стартануть в IT, возможно ли научиться программировать с нуля и стать разработчиком за пол года? Это возможно. За пол года вообще можно что угодно изучить. При желании даже за неделю всё что угодно изучить.
Можем ли мы научиться строить дома за неделю? Конечно. Почитали книги, посмотрели видео на YouTube, купили материалы, сколотили их по гайдам и дом готов. Через день этот дом унесёт ветром в Уругвай, но это уже другой вопрос. А так мы за неделю научились строить дом.
Можно ли за день научиться хирургии? Да. Взял скальпель, дырку в человеке проковырял, лишнее отрезал, зашил - ты хирург.
Программирование по сути тоже самое. За 6 месяцев или даже 1 неделю научиться программировать действительно можно. Заучил и написал несколько команд - программа готова - ты стал разработчиком. Но давай я буду называть вещи своими именами, тот код который ты напишешь с нуля поизучав что-то пол года - будет говнокодом.
Будет ли он как-то и в определённых условиях работать? Да.
Будет ли это надёжным? Нет.
Будет ли это безопасным? Нет.
Будет ли это эффективным? Нет.
Будет ли это поддерживаемым решением и можно ли будет с этим кодом работать дальше? Нет.
Но работать как-то и в каких-то условиях оно вообще-то будет. Можно ли считать, что вы научились программированию? Это вопрос...
Есть три ступени развития кодера как специалиста.
1 ступень:
В ней находится очень много людей на HeadHunter, а также других пободных площадках с вакансиями и резюме. Эти люди считают, что они уже стали разработчиками, познали дзен, прошли какие-то курсы. На этой ступени человек знает основные базовые конструкции языка программирования на котором он разрабатывает. Буду честным, с этими знаниями уже можно писать программы, и они уже как-то будут работать. В языках программирования таких как Python, PHP, Ruby, можно действительно очень быстро стартануть и начать писать программы которые будут работать. Но это всего лишь первая ступень, человек на ней пишет код который является говнокодом. Данный код ненадёжен, неэффективен, с ним невозможно работать, он абсолютно неподдерживаемый. Очень много таких людей считают, что они уже научились программировать и разрабатывать, хотя находятся лишь на первой ступени развития кодера.
На этом моменте я хочу передать "Привет" обучающим сайтам и чувакам которые обещают создать из любого человека - разработчика за 5-6 месяцев. Такие обучаторы молодцы, они наполняют рынок "правильными" людьми))))).
2 ступень:
Вторая ступень развития - это уже более обширное знание, в том языке программирования на котором вы разрабатываете и много чего ещё. Это знание стандартной библиотеки этого языка, окружающего мира, знание Linux, баз данных, знание SQL, знание общих базовых вещей которые выходят за рамки той технологии которую вы используете в качестве языка программирования.
3 ступень:
Третья ступень - это уже понимание архитектуры программных решений, понимание как правильно работать с api, понимание паттернов разработки, паттернов проектирования, понимание где лучше использовать исследование классов, где лучше использовать Dependency injection, это уже более глубокое понимание общей архитектуры программных решений когда вы знаете всю палитру возможностей, и можете из всей этой палитры выбирать именно те инструменты которые применимы и лучше всего подходят для какого-то конкретного программного решения. Это третья ступень развития вас как специалиста, как разработчика, как профессионала.
Ниже вернусь к тому с чего я начал: можно ли стать профессиональным разработчиком за 6 месяцев.
Давайте с вами представим такую ситуацию:
У вас колесо отвалилось на автомобиле и его на эвакуаторе привезли в автосервис. В автосервисе, вместо вашего колеса, вам поставили деревянный пенёк. Вы в этом ничего не понимаете, мастер при вас 5 метров проехал на этом деревянном пеньке, он почти круглый, и в целом машина как-то едет. И вы такие: "Ура! Я приехал на эвакуаторе сюда, а теперь машина едет, ну всё нормально. Проблема решена." Вы выезжаете на этой машине из автосервиса, проезжаете 100 метров, колесо в щепки рассыпается, пыль летит, вы врезаетесь в столб, вылетаете через лобовое стекло, вокруг дым, у вас шишка огромная на лбу. И вы такие: "А что это было?" А было следующее: Человек криво реализовал функционал, и вы не посмотрели как он его реализовал.
Именно такими "автомеханиками" являются разработчики на первой ступени. Это те самые люди которые ставят деревянный пенёк вместо настоящего колеса. На нём как-то ехать можно, но... вы понимаете о чём я? Правда здесь в том, что данная задача нереализована. Функционал может быть и стоит, но он реализован неправильно. Разработчик находящийся на первой ступени не сможет сам поставить вам настоящее колесо без внешней помощи и подсказки, без внешних направлений и глубокого изучения, он не может сделать хорошее решение и это нормально. Для того чтобы стать профессиональным разработчиком нужно больше времени. Нельзя стать профессионалом за пол года, нельзя стать профессионалом за год.
Сейчас есть всякие предложения для ультра быстрого успеха и результата:
"Построй бизнес с доходом 1 миллион рублей за год."
"Стань разработчиком за пол года."
"Похудей на 10 киллограм за неделю".
На всё нужно время. Для того, чтобы стать профессионалом нужно больше времени.
И если вы просто умеете пользоваться базовыми конструкторами языка, то нельзя сказать что вы разработчик, вы просто умеете пользоваться базовыми конструкциями языка и всё. На старте нужно готовиться к тому что вам придётся работать много и не 1 год.
Можно ли стать профессионалом за 1 год? Нет.
За 2 года? Нет.
За 3 года года? За 3 года упорной работы можно уже о чём-то говорить. У человека уже может сложиться понимание того чем он занимается если он упорно будет работать, понимание того что есть "хорошо" и что есть "плохо" в мире разработки.
Есть хорошая новость:
Если вам это в кайф, если вы занимаетесь с любовью тем чем вы занимаетесь, то этот процесс будет приносить вам удовольствие. Он не будет для вас работой. Это будет лёгким хобби, но вы будете ежедневно прокачиваться и ежедневно становиться всё ближе и ближе к третьей ступеньке, к настоящему профессионализму. Можно ли сказать что я профи, отношу ли я себя к профессионалам? Не знаю... Тема программирования, небольшого, каждодневного и непрерывного развития со мной достаточно долго, уже почти 10 лет, я получаю удовольствие от этого.
То, что я вам хочу донести - так это то, что готовьтесь к длинному пути, это не спринт, это марафон, но получайте удовольствие от вашего прокачивания, от вашего саморазвития, ежедневного, каждодневного и непрерывного самосовершенствования. Это действительно удовольствие, удовольствие это не конечная точка пути, удовольствие это процесс, поэтому будьте счастливы, цените дорогу которой вы идёте, а не саму цель и вы станете профессионалами.
Теперь поговорим об английском языке. Нужен ли он вообще для программиста? Расскажу свою историю отношения с английским языком и своё видение. Об использование английского языка в IT сфере, в разработке, в администрировании и всё что в общем связано с современным IT.
У меня английский язык, как у всех наверное, был в школе. Впервые я начала его использовать в 14 лет, в своей так скажем деятельности, когда я изучал Python. Там использовалась определённая технология, какая уже не помню точно, с которой я не был знаком и по которой информации на русском языке на тот момент не было вообще, какой-то фреймворк, я как раз тогда брал мелкие заказы уже для прокачки своего скилла, и в общем для того чтобы мне выполнять свои обязанности и успешно разрабатывать на том фреймворке нужно было его изучить. Поэтому в других вариантов не было кроме как найти книгу по нему на английском языке, скачать и начинать её изучать, что я в общем-то и сделал. И огромным удивлением для меня было то, что это не сложно. Я достаточно быстро прочел первые 50 страниц этой книги и смог успешно по этим 50 страницам начать разрабатывать на этой технологии, уже впоследствии углубляя свои знания в какие-то конкретные области этого фреймворка, и в общем-то успешно уже разрабатывая на нём, получая свои первые результаты. Какой вывод для себя я сделал из этой истории?
Во-первых:
Английский язык реально очень важен, потому что на русском языке вы можете попросту не найти информации по той технологии которая вам нужна и которую вы либо хотите изучить, либо которую вам просто нужно изучить по вашей профессиональной деятельности.
Во-вторых:
Это оказалось реально несложным. Я думал, что сейчас я скачаю эту книгу и мне придётся там каждое слово искать в словаре, ничего не будет понятно, обороты там деепричастные, причастные. Думал что мозг мой будет взрываться и выцедить оттуда ценную информацию будет очень сложно. На самом деле нет, всё оказалось достаточно просто.
Для меня было большим удивлением то, что словарный запас который реально используется в профессиональной литературе, он очень ограничен.
Это может быть несколько десятков, ну не десятков, наверное несколько сотен слов из которых профессиональные термины очень часто повторяются. То есть, изучив базовый набор слов, словосочетаний, который используются в вашей персональной теме, вы сможете абсолютно замечательно, успешно, без проблем, читать вашу профессиональную литературу и её изучать.
Вы должны знать английский язык и изучать литературу на английском языке. Информации на английском в десятки, может быть даже в сотни раз больше чем на русском. Я не преувеличиваю, на английском языке очень много информации которой на русском вообще ни в каком виде нет, по большему количеству технологий вы не найдёте ни в каком виде информации на русском языке. Моё глубокое убеждение в том, что для того чтобы изучить какие-то фундаментальные технологии: язык программирования, какой-нибудь большой фрейворк, нужно читать книги, просто потому что статьях и видео вы не найдёте много качественной информации, фундаментальной информации по языку программирования или по какой-то новой технологии. В книгах, как правило, приведён именно фундаментальный набор знаний которые позволят вам чувствовать себя уверенно и профессионально пользоваться инструментом, который вы изучаете.
В статьях и видео набор информации и инструментов очень маленький. Невозможно дать много информации в одной статье или в одном видео, даже в серии статей. Это выборочная информация, поверхностное погружение в технологию, но для того чтобы действительно глубоко изучить инструмент нужно читать книги.
Если вы посмотрите на книги которые выпускаются на русском языке, то вы убедитесь что, как правило, там присутствуют переводные материалы англоязычной литературы, и эта англоязычная литература была выпущена несколько лет назад. За эти годы технология уже изменилась скорее всего настолько сильно, что большая часть той информации которая приведена в этой книге, она вероятно уже неактуальна. Читая эту книгу будете получать неактуальную информацию. Да, безусловно, есть набор IT литературы которая была там 10 лет назад актуальна, и через 10 лет в будущем тоже будет актуальна, это литература по архитектуре, по каким-то основным принципам, паттернам и так далее. Но если мы говорим про конкретные технологии: языки программирования, фреймворки, то нужно читать свежую информацию этого года, максимум прошлого, не позднее, потому что за 2-3 года технология может измениться в достаточной степени. К тому же если мы говорим не про книги, то и статей в интернете больше на английском языке по любой технологии, видео на Youtube и на форумах, на всех обучающих платформах количество информации на английском языке больше. StackOverflow тот же взять, информации на английском языке там в разы больше, чем на русском. Поэтому для того чтобы нормально со всем этим работать, вы должны знать английский язык, это не сложно, это может быть психологически страшно, но нужно просто начать это делать, начать изучать английский язык, просто начать его использовать, начать читать, потом слушать, смотреть какие-то видео на ютубе, слушать и потом начать писать на английском языке. Это конечно если вы хотите ещё сильней прокачаться, и потом уже начать говорить на нём. Это моё мнение, я никому его не навязываю, не говорю, что оно единственное правильное, но мой подход был именно таким, то есть я сначала читал, потом смотрел и слушал, после этого я начал писать.
Поэтому это просто нужно начать делать и всё. Знать английский безусловно нужно, изучить английский для чтения профессиональной, технической литературы, ITшной литературы очень легко, словарный запас чрезвычайно ограничен, изучите его. Читаете, повторяете, изучаете, и начинаете погружаться в английский язык. Как дети изучают английский язык? Как любые дети изучают любой язык? Мы же, когда мы будучи детьми слушаем речь, начинаем какие-то слова произносить, мы же не изучаем какие-то правила грамматики, пунктуации и так далее. Это уже после, всему этому в школе нас учат, но мы уже умеем говорить и понимать. Поэтому для того чтобы изучить любой язык нужно погрузить себя в эту среду, нужно начать читать тексты, начать слушать видео на том же YouTube, слушать аудио. Этого будет достаточно для того чтобы в начальной степени изучить любой язык. Это не сложно и это обязательное требование для того чтобы расти в IT сфере, да в общем-то и не только в IT сфере. Я читал книгу "Краткая история человечества" автор Юваль Ной Харари, интересная книга, советую почитать, и я заинтересовался мыслями автора, нашел его блог. Отсутствие языкового барьера позволяет расширить границы очень сильно. Например, вы прочитали какую-то книгу, вас заинтересовали мысли автора, вы подписались на этого человека и вы можете общаться с этим человеком напрямую. Он пишет на английском языке, потому что английский это международный язык общения и коммуникации. Вы можете понимать что он пишет и соприкасаться с мыслями человека в реальном времени, вы их мгновенно можете изучить, понять, не дожидаясь пока их кто-то переведёт на русский язык, к тому же не все мысли будут переведены на русский язык, хотя они могут быть очень интересными и полезными.
Я надеюсь насчёт английского языка у вас больше не осталось вопросов. Поэтому далее я хотел бы рассказать одну притчу про исполнителя и заказчика. Она очень жизненная и поможет новичкам в IT сберечь много сил, времени и нервов.
Итак, встречаются исполнитель и заказчик.
-Мне нужно транспортное средство и очень важно, чтобы было синие, сделаете?
-Ну, да, мы как раз таким и занимаемся, 300 тысяч.
-Недёшево, но я согласен.
И вроде как все довольны. Исполнитель про себя думает: отлично, быстрый заказ и хороший заработок. Не совсем понятно зачем заказчику синий велосипед, но дело его, сделаю. Делает синий велосипед и показывает его заказчику.
Заказчик недоволен:
-Не, ну это фигня. Я вам заплатил 300 тысяч и я должен педали крутить чтоли? Так не годится.
Недобросовестный исполнитель уже на этом этапе ответит:
-Смотри, ты хотел транспортное средство, велосипед ездит. Ты хотел чтобы оно было синее, велосипед синий. Где мои 300 тысяч?
Ну ладно, недобросовестных исполнителей уберём в сторону. Представим, что наш исполнитель это честный человек который хочет сделать свою работу правильно и получить за неё свою честную оплату. Он ставит двигатель на велосипед, получается синий мопед, поливает этот двигатель тоже синей краской и показывает заказчику.
Заказчик говорит:
-Это уже получше, педали крутить не надо, но ведь получается, что я не могу товарища с собой взять, вещи погрузить некуда, сделай нормально.
Исполнитель:
-Ок.
Прикрепляет сбоку люльку, получается мопед с люлькой, показывает её заказчику. Заказчик говорит:
-Отлично, но есть проблема. Я когда еду, мне дождь на голову капает, это несерьёзно. Я вам деньги заплатил.
Исполнитель:
-Поправим.
Приваривает крышу, получается велосипед с мотором, сбоку люлька и крыша приварена, показывает это заказчику.
Заказчик:
-Теперь мне дождь на голову не капает, но я еду и мне в лицо ветер дует, а ещё шумно, где шумоизоляция?
Исполнитель выбрасывает это всё что он сделал в мусорное ведро, раздалбывает это всё в ярости, красные глаза у него, не спит сутками, кодит, получается автомобиль.
Заказчик смотрит на это и говорит:
-Я сразу это и хотел, сразу не могли нормально сделать? Какая-то ерунда до этого была. Но всё равно получается, что транспортное средство то не летает, я даже речку небольшую не могу на нём перелететь. Опять какие-то ограничения, урезанное транспортное средство. Смотри я тебе заплатил за нормальное транспортное средство, да? Ты мне обещал нормально сделать, говорил мне, что ты такое делаешь.
Исполнитель приделывает крылья к автомобилю, показывает снова заказчику.
Заказчик:
-Оно теперь действительно летает, но у меня друг работает на международной космической станции, и вот твой аппарат летает, но на МКС то я на нём улететь не могу правильно? Ну опять какие-то ограничения понимаешь? Ну снова что-то не так. Опять транспортное средство твоё не работает, в чём дело?
Исполнитель не выдержал, и послал заказчика куда подальше. Занавес :D
Я тут хочу заметить, некоторые из вас скажут, что заказчик чудак, он не знает чего он сам хочет, но на самом деле ситуация не столь однозначна, потому что заказчик может не знать разницу между велосипедом и ракетой, понимаете? Он может этого не знать, ведь речь идёт не о совсем очевидных вещах, речь идёт в нашем случае о IT системах. И разница между велосипедом и ракетой это может быть по факту разница между простеньким стиллером и сложнейшим автоматизированным ботнетом с ИИ который сам принимает решения по десяткам сложнейших алгоритмов с сотней различных функций. И кстати говоря на моём опыте как раз был такой ботнет который должен был взламывать сложные алгоритмы зашиты, но заказчик по прежнему называл это стиллером. Хотя там помимо собственно самих основных функций ботнета, был ещё огромный наболдашник в виде самообновляющегося криптора с обходом АВ, сложнейший набор различных функций, но для него всё это обычный стиллер. Тем не менее проект успешен, потому что на старте, мы как исполнители выяснили всё что нужно заказчику, и там было большое техническое задание на основе которого и велась впоследствии вся разработка. Именно поэтому этот проект в общем-то и был успешен, он функционирует насколько я знаю до сих пор, но для заказчика это попрежнему стиллер, хотя по факту там большая огромная система которая очень сильно выходит за рамки классического ботнета.
И да, это задача именно исполнителя, на старте работы выяснить какое именно транспортное средство нужно заказчику и почему оно синее. Нужно выяснить всё максимально подробно, в максимальных деталях. По хорошему и сам заказчик должен предоставить необходимое функциональное требование к своему проекту, пожелания, планы, наброски. Исходя из этого материала хороший исполнитель составит необходимое количество вопросов, обсудит эти вопросы с заказчиком, на основе ответов составит уже полноценное техническое задание: текстовый файлик в котором максимально подробно всё описано и уже по этому техническому заданию будет проводить оценку себестоимости проекта, оценку стоимости проекта для заказчика и сроки этого проекта, необходимое количество участников проекта и так далее.
Без этого текстового файлика, без информации что мы делаем, никакого успеха произойти в проекте не может, не для заказчика, не для исполнителя.
Нельзя начинать проект без чёткого понимания чего мы делаем, без конкретно и максимально подробного текстового файлика который называется техническое задание (ТЗ) в котором всё максимально подробно описано. Потому что без технического задания - это просто пустая потеря времени, сил, денег и нервов, ничего не выходе хорошего не получится, просто ноль шансов. Если заказчик в абсолютном большинстве случаев считает процесс написания технического задания не иначе как ерундой, то это задача именно исполнителя донести до заказчика всю важность, всю ответственность этого шага написания технического задания, наверняка все из вас знают такую фразу: без ТЗ - результат ХЗ. Но факту без ТЗ результат не ХЗ. Без технического задания результат абсолютно чётко предопределён - ничего не получится. Ничего хорошего в таком проекте быть изначально просто не может. Заказчик называет свою ракету транспортным средством, и это не его вина, он просто не понимает почему важно максимально чётко всё сформулировать на старте работы. Исполнители берутся за такие проекты, что-то как-то делают и по факту начинается банальная потеря времени, денег, сил и нервов, ничего хорошего на выходе не получается. А бывает ещё и другая ситуация, какие то люди по даркнету заплатили команде кодеров 3 миллиона рублей за разработку мобильного приложения которое будет с виду обычным и белым, но на самом деле там будет функция которая станет зазывать людей и собирать данные банковских карт. Настал день запуска - мобильное приложение не работает, то есть само оно работает, но процесс который должен проходить в этом мобильном приложении со сбором карт реализован только отчасти, там настолько много багов, что оно попросту не работает так как нужно, и исполнители говорят:
-Мы в процессе реализации этого приложения очень сильно отошли от изначального технического задания, очень много вещей вы просили сделать вне тех финансовых рамок которые изначально заложили и поэтому у нас сейчас просто кончился бюджет. Мы не будем продолжать делать это мобильное приложение, заплатите нам сверх изначально 3 миллионов и тогда мы вам доделаем.
И этот проект попросту сдулся потому что заказчики вложили все свои финансы, деньги затраченные на реализацию были потрачены впустую. В результате полученным мобильным приложением никто не пользуется, данные карт не собираются, функция по факту и не работает. Вот реальная история из реальной жизни. Если бы изначально все хотелки были заложены в ТЗ, то вероятность успеха этого проекта была бы сильно больше. Нужно сначала подумать что делаем, а потом это делать, всё просто.
И да, вот ещё моё любименькое от новичков: Agile (гибкая методология разработки). Им нафиг не нужно ТЗ, они гибкие... Могут начать одно, потом сделать из этого другое, потом сделать из этого третье, они даже не оценивают весь проект, они оценивают просто час работы. И вот они будут делать всё гибко и каждую неделю могут менять полностью вообще стратегию развития проекта и считают, что всё будет хорошо.
Мне очень нравятся слова Ричарда Столмана: "Я не настолько молодой, чтобы верить в Agile". Предлагаю всем об этом задуматься.
Каким образом гибкая методология поможет сделать из велосипеда ракету? Никаким. Если вы не понимаете что делаете, это потеря времени и денег заказчика. Если вы сначала не выяснили что по факту делать надо, и делаете велосипед, потом делаете мопед, потом делаете мопед с люлькой, потом делаете мопед с люлькой и крышей, потом делаете автомобиль, потом делаете автомобиль с крыльями в итоге так и не доходя до ракеты. Это не совсем то, что нужно в реальной жизни. В реальной жизни нужно сначала подумать что мы хотим сделать, сколько колёс у этого должно быть, как это должно работать и почему именно так, что мы с этим будем делать, какие сценарии использовать для того проекта который мы делаем и только после этого уже начинать что-то делать. Вот как-то так. Надеюсь что было полезно.