Comments 13
уходи
В целом хорошая статья, чтобы отвечать на вопрос родственников куда посоветуешь идти в этом АЙТИ
классная статья, спасибо! всё по полочкам)
HabrGPT.
Немного непонятно, что же всё таки такое "бесконечное обучение"?
Бесконечное обучение – норма
Бесконечное обучение – это не недостаток, а часть профессии.
(Минусы) ❌ Бесконечное обучение
Норма это, недостаток или часть профессии? :) Позиция автора по данному вопросу тут не ясна.
На собственном опыте могу сказать, что участие в различных IT конференциях, как спикером, так и слушателем, общение с коллегами из разных IT-компаний — это не только полезно, но и очень интересно.
Сейчас участие в IT конференциях очень дорогостоящее мероприятие, в котором вы платите львиную долю за бренд, а не за какие-то умные технически глубокие доклады, коих на таких конференциях становится всё меньше. Часто доклады паразитируют на общем хайпе какой-либо темы (микросервисы или GPT, например), не рассказывая принципиально ничего нового и действительно интересного. Нетворкинг - это хорошо, как и любое взаимодействие с сообществом разработчиков, но современные IT конференции это скорее про индустрию развлечений, только развлекаются специалисты из разных областей IT, не более :)
Софт-скиллы — это то, что отличает просто хорошего кодера от сильного разработчика.
С этим я не согласен. Кодер, программист и разработчик - это практически одно и тоже. Как ты можешь написать код (кодер), без знания архитектуры, концепции, алгоритмов своего будущего решения? Под диктовку что ле? :) Меня всегда удивляло, что под определением "кодера" люди, в большинстве случаев, понимают человека, который "просто пишет хороший код". Но как он это делает? Да точно также, как и "программист" или "разработчик" - вкладываясь в решение алгоритмов, построения концептуальных моделей, абстракций, архитектуры решения. Иначе просто нельзя написать какую-либо программу или сложный алгоритм, чем кодеры (разработчики, программисты) и занимаются.
"Кодеры" в своё время, писали такие сложные программы и алгоритмы, которые редкий "разработчик" сейчас сможет хотя бы спроектировать, не говоря уже о написании кода :)
С кавычками я написал термины, которые в большинстве случаев трактуются по разному.
Основным отличием бы современного разработчика от кодера и программиста я бы назвал необходимость вникать в детали своего проекта, которые никак не связаны непосредственно с написанием программного кода, а именно:
Разработка дизайна клиентского приложения (выполнение части роли дизайнера). Часто разработчику приходится заменять роль дизайнера или совместно с ним работать, чтобы связать высокоуровневые функции своего приложения с интерфейсом;
Более тесное взаимодействие с бизнесом в целом. Например, разработчик может помочь в формировании технических или функциональных требований к разрабатываемому ПО заказчику;
Составление подробной технической документации проекта (программы, приложения).
Также разработчик, в основном, работает над высокоуровневыми задачами, которые не требуют большого углубления в сложные технические концепции и алгоритмы. Иными словами "для решения задачи A, я использую библиотеки, пакеты и фреймворки B, C и D, чтобы не решать задачу своим способом (т.к. на это будет тратится больше времени)". Ну и работать над низкоуровневым кодом (с ассемблером, например) разработчику не обязательно (да и приходится крайне редко, если вообще никогда). Ему достаточно поверхностных знаний о своём языке программирования (коих может быть много) и использовании фреймворков наподобие Nest.js, Spring, Laravel, Django, Angular, Vue.js, TensorFlow, PyTorch и прочие, которые упрощают разработку донельзя (превращая разработку ПО в конструирование высокоуровневых и абстрактных элементов). Если выражаться в современных терминах, то это типичный fullstack разработчик, в моём понимании :)
Также программисты делятся по направлениям
Собственно, даже автор термин "программист" употребляет в главе про "разработчиков", что совершенно нормально.
Фронтенд-разработчики – делают пользовательские интерфейсы.
Бэкенд-разработчики – отвечают за логику и серверную часть.
Мобильные разработчики – создают приложения для iOS/Android.
Embedded-разработчики – пишут код для микроконтроллеров и IoT (умный дом).
Вот такое типичное разделение по направлениям не даёт даже общего представления о них.
Фронтенд - это далеко не всегда про "делать пользовательские интерфейсы". Это не всегда про веб-приложения, веб-сайты, HTML и JavaScript. Фронтенд это куда больше. Например, в LLVM тоже есть свой фронтенд, который гораздо сложнее чем "делать пользовательские интерфейсы" (в контексте типичных задач). Или в Android SDK есть тоже свой фронтенд. У различных библиотек, пакетов и фреймворков есть также свой фронтенд (Django, Angular, Laravel и прочее - тоже обладают этой частью). Да даже в DirectX есть свой фронтенд, который можно использовать для написания графических движков. Было бы прекрасно, если бы автор раскрыл каждое направление более подробно (а не просто так, как принято делить специальности программистов в бизнесе (очень поверхностно)).
В целом, я бы в этот список добавил игровых разработчиков, потому что у них может быть на одном проекте намного больше программирования (именно написание сложного программного кода без высокоуровневых фреймворков и прочих "конструкторских обёрток"), чем во всех перечисленных автором направлениях вместе взятых. Там есть также свои фронтенды и бэкенды. Например, есть отдельная специализация - графический программист. Или программист физических, звуковых, графических движков. Это очень крутые специализации в которых программирования очень много (за что они мне сильно импонируют). Или разработка читов - это вообще наиинтереснейшая область, которая связана с реверс-инжинирингом (который, кстати, можно сюда также включить в виде отдельной специализации).
Также можно добавить сюда машинное обучение, потому что это тоже программирование, как и анализ данных. Без написания программного кода модель не обучишь и данные быстро не проанализируешь :) Всё это относится к разработчикам, программистам или кодерам одновременно.
Чтобы не просто «писать код», а стать профессионалом, необходимо разбираться в основах компьютерных наук
Чтобы "просто писать код" нужно, как минимум, разбираться в выбранном своём языке программирования. Изучение компьютерных наук уместно тогда, когда твои задачи начинают расти в свое сложности. Например, появилась задача разработать свой протокол прикладного уровня или драйвер. Для этого, естественно, нужно отправляться и изучать теорию о драйверах, работе ОС и низкоуровневом программировании. Однако, когда ты разрабатываешь веб-приложения и простой бэкенд (разработчик) нужен ли тебе такой бэкграунд? Умные люди уже придумали кучу готовых решений, а тебе остаётся лишь всё собрать в один большой конструктор. При этом редкий специалист усомнится, что его тимлид, техлид или fullstack-разработчик чего-то там не профессионал, потому что не знает основы компьютерных наук.
Тут нужна личная глубокая мотивация изучать компьютерные науки и разбираться в её тонкостях. В современном мире стать профессионалом или, по крайней мере, им казаться можно и без основ компьютерных наук. Однако поверхностность знаний может ограничивать действия разработчика и он рано или поздно прийдёт к тому, что ему необходимо подтянуть свои знания в каких-то областях. Компьютерные науки необязательны, чтобы стать профессионалом, но их знание и участие в их развитии дают более фундаментальные знания и понимание об устройстве разработки ПО любого уровня (от драйверов, до веб-приложений).
Хороший разработчик тратит годы на обучение, но получает невероятное чувство удовлетворения, когда его код начинает работать, а сложная задача оказывается решённой.
Совсем необязательно. Разработчик может потратить годы на обучение и относится к своей работе как к работе, а не идеологической концепции "программирование как образ жизни". И быть при этом хорошим разработчиком, основная мотивация которого работать в своей сфере - зарабатывание больших денег (крупные зарплаты или свой бизнес). И такие специалисты могут быть более технически подкованными чем те, кто в разработку пришёл ради идеи (у каждого эта идея своя). Я такие примеры знаю лично. В общем, стремление к быстрому заработку (или просто большому заработку) через становление разработчиком (хорошим или плохим покажет время) - тоже вариант и далеко не всегда плохой :) Главное отдавать себе отчёт в том, что вы делаете и чего хотите (мотивация, план). Тогда, возможно, через кучу времени просто работа с большой зарплатой станет ещё и привлекательной концепцией, идеей "программирование как образ жизни". А может и не станет, что тоже совершенно нормально.
Навязывать (пусть не явно) идеализацию программирования не стоит. У каждого здесь свой путь. Кто-то осуждает "вкатунов" (вместо того, чтоб пойти и написать свою технически сложную программу или сделать свой крутой проект), кто-то продвигает в массы идею о "чистом коде", а кто-то идеализирует о программировании и мечтает добиться успехов известных всем людей из данной отрасли. У всех свой путь и свои причуды. Зарабатывать кучу денег в IT тоже норма и неплохая. И зарабатывают много не только хорошие разработчики, но и нормальные разработчики. Да и плохие тоже :)
Я бы сказал, что в статье есть много шероховатостей и куча поверхностных вещей, которые до самого конца статьи не были раскрыты. Если бы статья была более содержательной, от этого выиграли бы все - и читатели (особенно новички), и сам автор (статья бы приобрела много "плюсов"). А в текущем её виде она не особо отличается от других подобных ей статей, где всё рассматривается также поверхностно, не раскрывая тему достаточно глубоко, чтобы появилось ясное понимание что и как тут у нас в IT устроено.
Таких статей в интернете полно (подобное написать очень просто), попробуйте её улучшить и сделать "той самой", которая углубиться в эту тему и даст читателю понять многие её аспекты (вот это уже сложно и таких статей немного) в развёрнутом виде.
Когда ответ на статью длиннее самой статьи.
К вашим комментариям для по тех блокам я бы ещё чисто структурных накинул:
1)Вообще к любой такой статье для "тех-кто-не-с-нами",т.е не знаком с жаргоном айтишников, надо бы добавлять глоссарий, по которому несведующий человек поймёт, что за скиллы, гит и тому подобное.
2) Надо бы приложить какую-то условную кривую обучения, хотя бы на основе своего опыта. А то так непонятно, в какой момент пути разработчиков разных мастей расходятся(и одинаковы ли они вообще) или как попасть в нужную сферу, чтобы не стать фронтендером вместо ML-щика.
3) Надо бы осветить "Обычный день Java-разработчика в Т-банке", потому что из текста понятны обязанности, но нет никакого объяснения, что будет из себя представлять монотонность и от чего ты будешь выгорать :)
4) Я бы докинул информацию по грейдам и по градациям в рамках одной сферы, т.к очевидно, что джуну расписывать архитектуру и право выбора технологий никто адекватный не даст. А то по статье выглядит, будто ты придешь в компанию и тебе на первом созвоне впихнут покер-планирование задач на след спринт и декомпозицию системы.
Ну и много тех загрузки в статье, особенно если она является обзорной на профессию.
Норма это, недостаток или часть профессии? :) Позиция автора по данному вопросу тут не ясна.
Ну, это как на собеседовании, при приёме на работу: «Соискательницу спрашивают: – Ваши достоинства? – Безотказная. – Ваши недостатки? – Не могу отказать!».
7 класс - меньше 10 лет назад?
Школа, универ ... итого рабочего стажа в разработке 1-2 года на текущий момент?
Рановато озвучивать плюсы и минусы, давать рекомендации и прочее.
Вот пройдет хотя бы еще лет 10 - тогда и попробуйте уже.
здесь не будет сложных технических термиов, а текст, который сможет понять совершенно не подготовленный человек
Фреймворк, jQuery, git, пулреквест, деплой... Неподготовленного такой набор неизвестных терминов, точно запутает от отпугнет от ИТ сферы.
Не стоит забывать в что в нашем мире разрабатывают не только ПО, от того разработчик === программист. В свою очередь процесс описания Архитектуры ПО (схемы документация без строчки кода) это тоже непосредственно участие в Разработке ПО. Программирование же ПО это лишь один из видов деятельности разработки ПО.
Хорошо бы упростить описание некоторых терминов, а некоторые технические блоки можно безболезненно убрать
Мой путь в программировании начался почти 10 лет назад
статья больше про backend разработку, т.к. в других направлениях я погружён не насколько глубоко
А я вот уже «почти 10 лет» жду, когда под программированием начнут понимать не только веб-программирование и веб-технологии, но и «обычное» десктопное программирование. Хочется уже почитать статьи на Хабре больше про разработку, чем про тестирование, про С++, чем Java. Хоть самому пиши статьи на эту тему… :)
Вообще статья больше похожа на восторженный писк неофита, чем на речи зрелого специалиста. А за 10 лет можно было уже и созреть. Расти пора, парень :)
Для начала предлагаю усвоить очень простую вещь: всякий программист — разработчик, но далеко не всякий разработчик — программист. Пример, чтобы понятнее было, о чём я: сын моего друга работает в модной геймдев-студии. Является ли он одним из разработчиков их игр? Да, безусловно, он имеет самое прямое отношение к созданию персонажей этих самых игр. Является ли он программистом? Нет, ничуть, ни на йоту — он никогда в жизни не написал ни строки кода, знать не знает, как это делается, он художник, он рисует персонажей этих игр. Рисует буквально — карандашами и фломастерами на бумаге. Даже оцифровка этих рисунков во всякие там спрайты, “вектора”, гифы и прочую цифру — вообще не его забота, для этого там есть другие разработчики, которые тоже, кстати, ни разу не программисты.
Короче, эти термины совершенно не взаимозаменяемы. Когда ты говоришь “программист”, более или менее (тоже есть нюансы) понятно, что ты имеешь в виду. Но когда ты говоришь “разработчик”, ты говоришь о сферическом коне в вакууме, который к коду может не иметь ни малейшего отношения.
Программирование: что это, зачем сюда идти и к чему быть готовым?