Как Лена в 29 лет бросила успешную карьеру в финансах и решила «вкатиться в айти»
Как всем известно, айтишники без труда зарабатывают $300кк в наносекунду, а также способны молниеносно релоцироваться в любую точку планеты, просто моргнув левым глазом. В этой статье мы разбираемся, насколько легко стать айтишником с нуля, а также чему вас научат (и научат ли) на распиаренных программистских курсах.
Программистишкой стать не так просто. Если есть способности к логике и мат анализу - нет проблем. Если их нет, а хочется модную профу и много денежек - то это мучение и разбитые мечты. Не все могут стать программистами, к сожалению. Тем более, погромист - это сидение на жопе по 10 часов в день с глазами в экране и постоянное самообучение программингу - для этого нужен особый мозг. Поэтому и платят хорошо, потому что не каждый сможет программировать и оперировать виртуальными объектами качественно, а один из 10000.
Первое, что нужно перед всякими курсами - понять, есть ли способности к логике и алгоритмам. Если нет, то в итоге такой онанизм с неприспособленным к профессии мозгом приведет к депрессии и крушению розовых мечт.
Комментарий недоступен
Алгоритмы нужны на собеседовании чтобы собеседующий самоутвердился и смог понизить планку ЗП. А потом на рабочем месте нужно будет красить кнопки или перекладывать джонов
Было бы не так смешно, если бы не было правдой :)
Это не правда, алгоритмы - одни из ключевых знаний для профессии.
Умение вбивать код это примерно как для хирурга умение зашивать - т.е конечно надо и обязательно, но мягко говоря не самое важное.
Я не отрицаю нужность алгоритмов и прочего. Это тоже часть работы. Но и "перекладывание джонов" имеет место быть.
Про алгоритмы тоже отдельная история. Как часто используется именно написание алгоритма (с нуля) сортировка массива, например? Все равно же используются методы, которые реализованы уже для более простого использования.
Посмеялся просто с формулировки "перекладывать джонов"
Любая реализация бизнес логики - алгоритм, а на сеньорских уровнях вам нужно мигрировать и оперировать данными и как раз уже ПОНИМАТЬ как работают инструменты которыми вы пользуетесь. Сорян, на сеньорских позициях чтобы расти дальше без алгоритмов и структур данных вы не поедете никуда
Брехня.
До тех пор пока вы не писали алгоритмический софт: какие-нить индексы, деревья, поиски и т.д. можно считать, что алгосы вы не знаете.
Вы просто прочитали книгу.
Я вообще не понимаю дроча на алгоритмы, если нужны: возьми и разберись, а если не нужны, ну прочитай пару книг.
Мда... Интересная точка зрения. Прям даже вспомнился термин из юности - воинствующий ламер.
Алгоритмы и логика - это база. Без них невозможно предложить хорошее (элегантное, понятное и масштабируемое) решение путем унификации и абстрагирования логики и потоков данных.
Не зная методы оценки алгоритмов постоянно будут применять неправильные коллекции. И не правильные инструменты. Синхронизация потоков становится прям испытание. А некоторые задачи становятся просто не решаемыми.
Как-то сталкивался в кодом, который работает, вроде все правильно, но при работе с которым столько времени высасывает, а чувство тошноты не проходит. При этом сонар неистово матерится на безумные Cyclomatic Complexity. Один раз переписал небольшой класс, потому что невозможно было дальше с ним работать - количество строк снизилось раза в 2, а Cyclomatic Complexity раз в 5.
Комментарий недоступен
Вы видимо писали очень мало коммерческого софта. Если предметная область не предполагает написание чего-то алгоритмического - алгоритмы не нужны и знания о них практически бесполезны, т.к. там сложность и критерии оценки софта совсем другие.
Поделитесь сакральным знанием: это какая именно предметная область не предполагает использования алгоритмов?
Комментарий недоступен
Вы даете советы космического масштаба и космической же глупости, по таким заключениям можно сделать вывод, что коммерческой разработкой софта вы никогда не занимались. Если бы можно было ускорить отчет на два порядка просто его переписав - это все равно, что ничего не делать :)
Комментарий недоступен
Вы видимо не сталкивались с ситуацией, когда в коммерческом софте намечается успех и оказывается, что юзеров/данных становится на порядок больше.
И софт, писанный разрабом, знающим логику/алгоритмы такое переваривает, может с некоторыми допилами. А софт писанный разрабами без знаний математики - можно выкидывать на помойку, тк оптимизировать невозможно
Знание математики это сильно условно. Расскажите какие знания математики вы прям таки применяли в обычном софте, какие проблемы были решены конкретно вами?
90% проблем софта это дизайн, который не соотвествует вариантам использования, оверинженеринг, технический долг, ошметки от предыдущих переделок.
Если бы 80% проблем решались бы алгосами, не было бы такого количества говнософта.
И не факт что человек, который хорошо знает алгоритм может писать понятный и поддерживаемый код.
И да увеличение нагрузки решается маштабированием, и вот вам пример некорректного применения алгоритмов.
Ну во-первых, вы должны четко понимать когда нужно использовать джейсонов, а когда их использование приводит лишь к пустой трате ресурсов и времени на их перекладывание.
Во-вторых, "алгоритмы" это не сортировка массива. Это в общем случае образ мышления - как данную задачу решить наиболее оптимально.
Ну вот попробую описать ситуацию.
Есть задача поиска совпадений по 4-м параметрам. И есть сделанное когда-то решение - отдельные функции поиска совпадений по каждому из параметров (ну типа микросервисы такие).
Что характерно, каждая из четырех функций вызывает некую базовую процедуру (достаточно "тяжелую"), возвращающую некий набор идентификаторов с которыми потом идет работа.
Что делает джун? Он просто берет и пишет программу, получающую на вход 4 параметра, которая внутри последовательно вызывает все 4 функции - по каждому параметру проверяет отдельно. А в результате имеем 4 вызова "тяжелой" базовой функции и реакцию сопровождения - "да вы там офигели, все это ресурсы жрет как не в себя и тормозит".
Думающий же разработчик напишет все с нуля - один вызов "тяжелой" базовой процедуры, затем использование ее результатов для поиска совпадений по каждому параметру. А еще вникнет в то, в каком окружении все это будет работать, поймет что возможны последовательные вызовы при которых изменяется только один-два параметра (от предыдущего) и закеширует результат последнего вызова - если какой-то из параметров не изменился, то будет использовать результаты прошлого вызова.
В итоге получит примерно в 10 раз быстрее и во столько же экономичнее по ресурсам от решения джуна.
Но тут уже какая-никакая алгоритмизация потребуется.
Когда вы просто кликаете мышкой в браузере - отрабатывает алгоритм поиска оптимального активного блока, с учетом расположения элементов, слоев и тд.
Без понимания таких вещей вы не сможете например реализовать быстрый UI ни на каких технологиях.
'Все равно же используются методы, которые реализованы уже для более простого использования'
Потому что эти 'методы' далеко не кнопка 'сделать зашибись' , нужно четко представлять где и что применять.
А без О-нотации это нереально.
Вы явно не занимались коммерческой разработкой фронта, 99% фронт разработчиков не расскажут вам как работает алгоритм поиска оптимального активного блока, с учетом расположения элементов, слоев и тд, потому как это не нужно.
Кнопки красить и просто накидывать компоненты однотипные реальность для абсолютного числа разработчиков.
Комментарий недоступен
Если вы пишите фронт на WebAssembly, т.е. подключаете какой-нибудь С++, то, может быть, это и понадобится. Но в случае с тем же Реактом совсем другие компетенции нужны.
Никогда не понимал собеседующих программистов которые хотят занизить зп. Они же не из своего кармана платят. Наоборот, чем больше средняя тем выше они могут себе выбить. Но там реально больше желание самоутвердиться.
Сам я всегда ставил выше оценку и рекомендовал выше зп. Чтобы потом себе как старику больше выпрашивать
Комментарий недоступен
Плюсую. Знаю много примеров, как люди с далеко не математическим мышлением переходили в ойти. Не дата сайнс конечно. Но на фронтенде/бэкенде/автоматическом тестировании вполне комфортно себя чувствуют.
В программировании вообще больше гуманитариев, чем математиков. Где-то даже исследование проводили, что лингвистическое способности лучше коррелируют с успехами в разработке, чем математический образ мышления (если такой вообще существует).
Комментарий недоступен
Предполагаю, что люди просто путают алгоритмы и шаблоны проектирования.
Использование готовых библиотек - уровень джуна. Расти разработчик начинает тогда, когда начинает понимать как эти библиотеки устроены внутри, чем они отличаются по реализации и когда какую эффективнее использовать. С этим пониманием он становится мидлом.
Чтобы стать сеньором нужно сверх того уметь написать свою реализацию под конкретную задачу, если это потребуется с точки зрения эффективности.
Так не все становяться сеньорами.
Да и пастить готовые бибилиотеки - это все делают от джуна до сеньора.
Просто сеньор может выйти на 500К р
А большинство не сможет и будет получать сидя в сибири 150-250К и чуствовать себя милионером
логика в программировании на уровне детского сада - не все лендосы на реакте бахают, большая часть разрабов решают нетривиальные задачи чуть чаще чем каждый день. Алгоритмы это проверка:
а) на живость ума - не обязательно знать все структуры, чтобы показать собеседующему, что ты "могёшь"
б) на силу заинтересованности в работе - не каждый чел сможет сидеть (скорее всего после полного рабочего дня) и разбираться в деревьях и связанных списках.
Комментарий недоступен
Программирование это про создание абстракций и построение моделей из этих абстракций, такое далеко не все умеют, в следствие чего рождается говномодель реализованная говнокодом.
Чел, завязывай. Какой мат анализ? :) У меня 90% знакомых кодеров не знают производную от x^2 и что такое логарифм, я уже не говорю о матане, который выходит за рамки вузовской программы при решении практических задач. Те кто знает мат анализ работают на таких работах, где больше требуется низкоуровневое программирование, связанное с вычислениями или машин лёрнингом (по естественным причинам).
Для всяких реакт жс разрабов, бекендеров пишуших круды и отчеты - матан нахер не упал
Комментарий недоступен
работа специфичная но за компом по 10 часов сидит весь офисный планктон.
про постоянное самообучение - хз откуда берется этот галимый фейк возможно джуны его распространяют ) реально может у 10% програмеров есть нужда в _постоянном_ изучении. либо у кузнечиков которые меняют галеры постоянно, либо у аутсорсеров в которых проекты тоже часто меняются вместе со стэком.
но в продуктовых конторах я не вижу вообще чтоб прямо обучение какое-то струилось, ну так в меру что-то новое понятно юзаешь, точно как и автослесать новые тулзы осваивает с годами. но это вообще не приоритет. куча продукта написано на стэке так сказать "средней" давности, не старый но и не cutting edge и никто никогда его не переписывает полностью.
а уж сеньоры / лиды так и вообще... аналитические способности делают 80% работы.
Комментарий недоступен
не ненадо все так сложно
сидеть на шаблонных задачах - там нет математики
только копи-паста и немного мозгов
Комментарий недоступен
Эт оправдания) не везде в программировании нужен математический склад ума. В фронтенде где версткой занимаются вообще с математикой сталкиваться не приходиться. Нужно просто не полениться разобраться в синтаксисе
Про сложность работы и что она не всякому подходит я могу согласиться, т.к. работаю seo-специалистом и замахнулась на большее - изучение пайтон. Сначала все было норм, но потом начались жутко сложные задачи, что даже коллеги не могли понять, что от них хотят. Все еще продолжаю смотреть курсы пайтон для понимания что и как там работает. Нет уже желания менять сферу, но именно знать языки сеошнику все же будет +, особенно, когда в резюме идут требования по знанию бэкенд части (попадался php и я его не знаю, но думаю, разобраться на менее чем базовом уровне смогу, т.к. для остального будет помощь от программистов). В общем, я к тому, что не всем реально это дается + когда нет ментора или хотя бы того, кто мог бы объяснить - тоже сложно. Но изучить и работать можно, изменив мышление не в корне, но хотя бы на немного. Зависит от желания и собственных сил и помощи от реального человека, как по мне.
Для чего это нужно? Пусть сами и поддерживают проекты, они же с заказчиков за это деньги брали.
Разрабу лучше поддерживать только свои проекты.
Комментарий недоступен
Комментарий недоступен
Если бы деньги измерялись литрами просиженной жопы, вынужденному самообразованию и количеством итераций одной и той же работы, то проектировщики бы жили не хуже, как минимум. Увы, подобного не наблюдается.
ну уж и не рокет саенс точно
поменьше гонора