Если вы начинаете с нуля, то существуют три основные дороги в IT:
- высшее образование;
- самостоятельное обучение;
- профессиональные курсы.
У всех трёх дорог есть свои плюсы и свои минусы. Давайте попробуем максимально объективно рассмотреть и то и другое.
Начнём с высшего образования. На мой личный взгляд у высшего образования в IT есть несколько очень серьёзных минусов. Первый минус – это срок обучения. Учёба на бакалавра в IT в высшем учебном заведении займёт 3-4 года. По меркам современной жизни 3-4 года это огромный срок.
Во-вторых, учёба на IT в высших учебных заведениях зачастую оторвана от реального мира IT, учёба происходит в академической теоретической плоскости. А мы помним, что IT это сугубо практическая сфера. Очень часто получается так, что человек отучился в институте на IT, выходит в реальную жизнь, а тут как специалист он никому не нужен. Так как на рынке IT не исследовательские компании, которые занимаются научными разработками, а компании, которые создают реальные IT проекты, решая задачи реального бизнеса. А для таких компаний нужны люди, которые умеют делать реальные вещи, а не те теоретики, которые витают в облаках и которые никогда не брали в руки языки программирования и не писали реальный промышленный код.
Я слышал один простой пример, подтверждающий мои слова. IT компания для проверки знаний кандидатов устроила тестирование. Тест содержал набор практических вопросов. Для компании было важно выяснить имеют ли кандидаты реальные практические знания или нет. На тест пришли два кандидата. Первый только что закончил магистратуру, отучившись в высшем учебном заведении 5 лет. Второй кандидат оказался самоучкой, выучивший основы IT на практике, он в домашних условиях пилил свои проекты. По результатам тестирования компания выбрала второго кандидата, предпочтя самоучку магистру компьютерных наук, который потратил на учёбу долгих 5 лет. Почему так произошло? Да потому, что первый кандидат провалил этот практический тест. Он не смог правильно ответить на большинство практических вопросов в тесте. Почему? Да потому, что его 5 лет учили теории, а реальной практики за это время практически не было. Компания выбрала самоучку, потому что он обладал пусть и не идеальными, но вполне реальными практическими знаниями, которые он приобрёл в процессе практических экспериментов у себя дома.
Приведённый выше пример во всей красе демонстрирует проблему современного высшего образования в сфере IT. Оно очень часто совершенно оторвано от практики. И если во время учёбы студент не находит возможности получить практику, то результат обучения в высшем учебном заведении по специальности IT может оказаться очень плачевным. Я очень хорошо знаком с этой ситуацией. В своё время мне удалось получить степень магистра компьютерных наук. Мне сильно повезло с несколькими преподавателями. Они были молодые практикующие специалисты. Они смогли заразить меня практической красотой IT. Благодаря им я сам много занимался и экспериментировал, изучал на практических примерах новые вещи. Так со временем мне удалось накопить практический опыт, который позволил попасть в реальное IT и начать там работать. К сожалению, эти классные преподаватели ушли из института, ушли в реальное IT, ушли зарабатывать деньги, создали свои компании. К сожалению, в академической среде зарплаты маленькие по сравнению с реальным IT, поэтому преподаватели практики просто уходят из академической среды IT компании. А в академической среде остаются преподавать те, кто практически не видел реального IT, те, кто выучил IT по книгам или курсам на Udemy. Такие преподаватели не могут показать студентам, как выглядит реальное IT, не могут передать студентам тот практический опыт, который приобретается с годами практики. У них этой практики просто нет. Отсюда и получаются такие студенты, которые отучившись 3-5 лет в высшем учебном заведении на практике ничего делать не умеют.
Если говорить начистоту, то у высшего образования есть и свой плюс. Этот плюс заключается в широте получаемых знаний. В высшем учебном заведении стараются дать широкие теоретические знания в сфере IT. Да, широта знаний и хороший кругозор иногда помогают, особенно когда речь идёт о задачах, лежащих на границах областей знаний. При решении таких задач у человека с высшим образованием будет преимущество.
В реальном IT крутизна специалиста мало коррелирует с наличием у этого специалиста высшего образования. Я знаю большое количество IT специалистов, достигших очень высоких должностей (сеньоры, архитекторы и т.д.), которые в своё время просто бросили и не закончили высшее учебное заведение по IT направлению. На 95 и более процентов крутизна IT специалиста зависит от его практического опыта и практических знаний, от его реальных возможностей. И только менее 5% его крутизны – это наличие у него корочки о высшем образовании.
Запомните одну истину – в реальной жизни корочки никого не интересуют. Работодателя интересует только практические навыки и опыт работника.
Самостоятельное обучение это ещё одна дорога в IT, на которую стоит обратить внимание. Сразу оговорюсь, что самостоятельное обучение в IT, особенно на начальной стадии, подходит далеко не всем. Во-первых, человек должен быть очень организованным и уметь самостоятельно направлять свои действия в продуктивное русло. Ведь когда ты занимаешься самостоятельно, тебя никто не контролирует, никто не направляет, никто не заставляет что-то делать. Всё придётся делать самому: составлять план учёбы, искать и выбирать материал для изучения, мотивировать себя на учёбу, контролировать свой прогресс, оценивать результаты своей учёбы и т.д.
Мир IT очень большой, что учить, зачем учить, в каком порядке осваивать темы – на первых порах вопросов будет намного больше чем ответов. В мире IT очень много информации и знаний для изучения. Большая проблемы для новичка заключается в том, что информация и знания в IT быстро устаревают. IT очень динамическая сфера, знания актуальные ещё в прошлом году, в новом году могут запросто потерять свою актуальность и начать постепенно выходить из моды. Вы можете изучать старую технологию, которую уже никто не использует на производстве, но сами об этом вы ничего знать не будете. Вы просто потратите на её изучение много своего времени и сил.
Актуальность изучаемых знаний это только одна проблема, с которой сталкивается человек при самостоятельном изучении. Вторая большая проблема заключается в качестве изучаемого материала. К сожалению, интернет наполнен миллионами статей индусских программистов, которые дают совет так сказать на каждый случай жизни. Качество этих советов зачастую оставляет желать лучшего. Вместо хороших и полезных навыков вы можете научиться плохим и неправильным решениям. В шутке, что индийским программистам платят зарплату не за решение бизнес-задачи, а за количество написанных строчек кода, есть большая доля правды. Чему вас может научить человек, который вместо краткого изложения основных тезисов, пишет поэму на 100 страниц?
Полки книжных магазинов завалены толстыми книгами по IT тематике. Если вы думаете, что купив одну/две такие книги, вы научитесь программированию, то вы глубоко заблуждаетесь. В начале своего IT пути я тоже был таким же наивным. У меня до сих пор (вот уже почти 20 лет) на книжной полке стоят с десяток таких толстенных книг, каждая по 500+ страниц. Я осилил максимум 50-100 страниц каждой книги и ничего не помню из того, что прочитал. Если книга в IT содержит 500+ страниц, то скорее всего эта книга написанная в стиле справочника, которая абсолютно непригодна для обучения. Из моего личного опыта в IT очень мало действительно толковых и ценных книг, в которых разбираются и описываются фундаментальные вещи.
Третья проблема, с которой сталкивается человек при самостоятельном изучении IT – это оценка своих результатов. Напомню, что IT это сугубо практическая сфера. В ней ценятся только практические знания и опыт. Только делая практические вещи можно реально освоить IT. Проблема заключается в том, что в IT одну и ту же задачу можно решить по разному. Каждое из возможных решений может быть правильным с точки зрения конечного результата (то есть выдавать один и тот же правильный результат при одинаковых входных данных). Но помимо конечного результата в IT-решении ценятся и другие вещи, такие как простота, расширяемость, производительность, возможность тестирования, архитектурные принципы. Все эти характеристики играют огромную роль при создании большой, стабильной, легко поддерживаемой и расширяемой IT системы. Все эти моменты настолько же ценны, как и конечный результат. Если ими пренебречь, то будет практически невозможно создать и поддерживать эффективную работу более менее серьёзной IT системы.
Давайте попробуем разобраться в чём же тут дело. Что скрывается под простотой решения? Рассмотрим этот вопрос на примере программирования. Программирование это процесс создания (написания) компьютерной программы. Конечным продуктом процесса программирования являются текстовые файлы, которые содержат последовательности команд. Любая IT программа это по сути автоматизация какого-то бизнес-процесса. Это определённая последовательность инструкций (команд), которые должен выполнить компьютер для решения поставленной задачи. Эту последовательность команд (набор инструкций) можно составить по разному. Прелесть и сложность процесса программирования состоит в том, чтобы составить как можно более простую последовательность команд, такую которую легко поймёт другой человек. В процессе написания программы можно очень легко усложнить решение, сделать его сложным для понимания другим человеком. Да, такое решение будет в конечном итоге правильно решать поставленную задачу, но его будет практически невозможно поддерживать. В любую серьёзную IT систему со временем вносятся изменения. Это происходит потому, что требования бизнеса меняются и IT специалисты должны адаптировать компьютерные системы к новым жизненным реалиям. А для того, чтобы внести изменения в IT систему нужно сначала разобраться как она устроена и что она и как делает. А для этого другой человек (программист) или же сам автор системы (или её части) должен открыть программный код (набор инструкций) и разобраться (понять) как он на данный момент решает задачу и куда нужно внести изменения. Поверьте мне на слово, что даже автор системы по прошествию месяца с момента окончания работы по созданию IT системы уже не помнит многих её деталей. Тем более через год или два. А это далеко не редкость, когда изменения в систему надо вносить по прошествию нескольких лет. У реальных IT систем срок службы обычно 5-10, а то и более лет. И в течение всего этого срока в них вносятся изменения. Процесс улучшения и доработки не прекращается всё время службы IT систем. Простота созданного решения играет тут ключевую роль. Авторы системы приходят и уходят, со временем меняется состав команды, которая работает над системой. Но если система написана просто и понятно и в ней могут разобраться другие люди, то её эксплуатация остаётся экономически выгодной для бизнеса и система продолжает свою работу.
В истории IT было много случаев, когда сложно написанные системы приводили к банкротству целые компании. Сложную систему невозможно быстро адаптировать к новым реалиям современного мира, невозможность эффективно и быстро вносить изменения в IT системы, связанные с изменениями бизнес процессов, в конце концов приводит к плачевным последствиям для бизнеса.
Новичок не в состоянии самостоятельно оценить насколько его решение простое или сложное. Новичку сложно придумать и реализовать альтернативное решение для того, чтобы было возможно сравнить два решения между собой. Чувство простоты приходит к разработчикам с годами реальной практики. К сожалению, далеко не все IT профессионалы осваивают навык создания простых и надёжных решений. Новичку, при самостоятельном обучении, не с чем сравнить своё решение, ему никто не может дать советы. Новичку будет казаться, что его решение идеальное (оно ведь работает, а он на него потратил много времени), но в действительности решение будет сложным, таким, в котором другие не способны будут разобраться за разумное время.
Что скрывается под понятием расширяемости IT системы? Представьте, что ваша IT система выдаёт страховки на машины. Бизнес у компании идёт хорошо и компания принимает решение начать бизнес в сфере страхования недвижимости. К вам приходит представитель бизнеса и задаёт следующий вопрос: сможете ли вы добавить в вашу IT систему (которая на данный момент способна выдавать только страховки на машины) возможность выдачи страховок в сфере недвижимости? Сколько на это потребуется времени и средств? Помните, что за работу IT платит бизнес. Ему нужно оценить экономическую сторону, рентабельность изменений. От ваших ответов на эти вопросы будет зависеть ваше будущее. Если вы скажете бизнесу, что добавить в вашу систему возможность выдачи нового типа страховки невозможна (ваша система не расширяема) или это слишком дорого и долго, то бизнесу ничего не останется, как искать вам замену. И поверьте, бизнес быстро найдёт вам замену, так как за дверями уже толпится толпа ваших конкурентов. Среди них точно найдётся тот, кто сможет выполнить поставленную бизнесом задачу за разумное время. Вам и вашей системе просто укажут на дверь.
И наоборот, если вы и ваша система будете способны реализовать новые требования бизнеса, то у вас появятся новые возможности и более крепкие и тесные связи с вашими бизнес партнёрами.
Возможность или невозможность внесения больших изменений в IT систему зависит в первую очередь от того как она создана. Были ли при её создании учтены потенциальные возможности её расширения в будущем или о таких возможностях вообще никто не думал. В больших системах именно технические моменты реализации играют ключевую роль. IT системы бывают настолько большими и сложными, что простое расширение штата IT специалистов не способно решить поставленную задачу. Давайте мы наймём ещё 10-15 программистов и они всё сделают за разумное время. Такой подход с большими системами не работает. Увеличение команды вдвое не приводит к ускорению работы в два раза. Парадокс в том, что со сложными и не готовыми технически к расширению системами может получиться всё с точностью до наоборот, когда увеличение штата вдвое только замедлит работу, а не ускорит её. Больше сотрудников, больше коммуникации между ними, больше менеджмента, митингов и т.д., а реальных дел всё меньше и меньше. Систему, которую создавали годами невозможно переписать за неделю, месяц или даже год. Вот и получается, что возможность расширения IT системы играет одну из важных ролей. А расширяемость в свою очередь зависит от технических решений, принятых в момент разработки. В систему на стадии создания можно заложить возможность расширения в будущем. Если это было сделано, то вы на коне, если нет, то под ним.
Возможность расширения системы это набор технических и архитектурных решений, а также общее видение и подход всей команды к разработке IT системы. Новичок не способен самостоятельно оценивать и принимать такие решения.
Производительность IT системы это ещё один важный её аспект, который играет важную роль при эксплуатации.
В современном мире компьютерные системы имеют дело с огромным объёмом данных. Просто представьте себе, что надо сохранить персональные данные каждого жителя страны. А потом представьте, что нужно сохранить каждую транзакцию (в банковской системе), которую совершил каждый житель в стране за месяц, за год, за 10, 20 лет и так далее лет. Это огромное количество данных, миллионы, миллиарды, а то и более записей. Да, современные компьютерные системы довольно быстрые, но даже они сталкиваются в очень большими проблемами при обработке таких гигантских объёмов информации. Хуже того, объём данных, которые сохраняются в IT системах, неумолимо и очень быстро растёт.
Говоря простым языком, есть большая разница когда мы имеем 10-100 записей в своей системе или 10-100 миллионов или даже миллиардов. При обработке 10-100 записей скорость работы системы будет похожа на ракету (ей для этого потребуются доли секунды), а при обработке 10-100 миллионов записей скорость работы системы будет напоминать черепаху (ей для этого потребуются уже минуты, а то и часы). А если количество записей в системе перевалит за миллиард, то системы может и вовсе перестать работать. Все эти примеры конечно же условны и имеют целью показать наличие проблемы производительности в IT системах.
Новичок, да и умудрённый опытом программист при решении задачи просто не задумывается о вопросе производительности. Проблема производительности очень часто остаётся скрыта от глаз до тех пор, пока функциональность не будет запущена на реальной продакшн среде (там где в системе хранятся те самые реальные данные пользователей, миллионы и миллиарды записей). И вот тут начинается самое «интересное». Система начинает на глазах превращаться в черепаху или попросту выкидывать ошибки и не работать. Проблемы на проде- это всегда стресс для всех и в первую очередь авторов функциональности. Вот отсюда и появляются «байки» про работу программистов по ночам и в выходные. Во всём этом есть своя доля правды.
Почему так происходит? Потому что при разработке функциональности не были учтены моменты, связанные с производительностью. В систему не были заложены архитектурные решения, помогающие справляться с такими проблемами. На этапе тестирования проблемы, связанные с производительностью, не были обнаружены потому, что на локальном компьютере программиста или даже на тестовом сервере, где происходило тестирование, попросту нет такого большого объёма данных. А на маленьком объёме тестовых данных функциональность просто летала. Вот и получается, что очень просто написать функциональность, которая просто работает, но далеко не просто создать систему, которая будет готова справляться с обработкой большого объёма данных. Конечно, вопрос производительности системы это не тот вопрос, за который несёт ответственность новичок. Но всё же без учёта этих вопросов нельзя создать надёжную IT систему.
Возможность автоматического тестирования программного обеспечения и наличие самих автоматических тестов играет ключевую роль в разработке качественного программного обеспечения. Современные программы стали настолько большими и сложными, что их тестирование вручную становится просто невозможным. Для тестирования больших и сложных систем нужно много тестировщиков и времени. Оба эти ресурса (время и персонал) очень дорогие. Поэтому при тестировании современных программ стараются использовать автоматизацию, в которой ручной тестировщик (тот, кто тестирует программы руками, повторяя работу простого пользователя) заменяется маленькой программой – тестом. Программа-тест автоматически (без участия человека) повторяет заданный сценарий и проверяет полученный результат. Программа-тест делает это очень быстро, во много раз быстрее ручного тестировщика, тем самым экономя важный ресурс – время. Где ручному тестировщику для тестирования могут понадобиться недели и месяцы работы, там автотесту потребуются минуты или часы. Автоматическое тестирование при правильном использовании экономит время на разработку и поддержку, а также снижает стоимость за счёт уменьшения штата тестировщиков.
Сам программист тоже должен применять тестирование в процессе создания программ. Обычно тестировщик тестирует всю программу целиком. Программист в свою очередь тестирует части программы. Что это за части программы? Давайте попробуем описать как происходит процесс программирования. Большинство думают, что программист просто сидит и пишет какие-то закорючки в текстовом редакторе (набирает код программы, команды, которые потом будет выполнять компьютер).