Комментарии 242
Почему подобные статьи делает програмирование сложным ? Да потому что там 10005000 символов.
Особенно когда пишут про травмы от обучения. Ох уж этот травмирующий опыт того, что надо вкалывать
Тоже улыбнулся на этом моменте ;)
Особенно с уточнением "ОНИ ВСЕ СОЦИОПАТЫ!1!11"
Поржал) Бедные люди, надеялись войти в вожделенное айти на чиле и расслабоне. Оказывается, нужно вкалывать. Внезапно.
Люди забывают об одной важной вещи - они решили освоить новую профессию, далеко не самую простую, с нуля. Это сложно, это больно, это долго.
По своему примеру могу сказать следующее. Работаю в телекоме уже 10 лет. Сознательно выбрал соответсвующую профильную специальность, сознательно и добросовестно отучился 5 лет. Сразу после универа пошёл работать по специальности. И только спустя год работы я начал действительно вдуплять, что я здесь делаю и зачем, стал целостной и самостоятельной единицей. С тех пор неистово кайфую от того, чем занимаюсь 😁
В академии на одном из факультетов будут готовить специалистов по программированию.
Что это такое я толком не понимаю, но чувствую, что за этим стоит большое будущее и вам совет держать путь на второй факультет на специальность «Программирование».
Вот такие слова я выслушал 50 лет назад, и я последовал этому совету. И не разу с тех пор не пожалел.
А понять программирование и стать программистом мне помогли спичечные коробки:
Представь себе кучу пронумерованных/подписанных спичечных коробков, в каждом из которых лежит какое-то количество спичек. Коробок со спичками – это и есть ячейка. Адрес ячейки – это номер коробка или его название. Теперь предположим, что надо узнать, сколько всего спичек хранится в пятом и десятом коробках вместе, т.е. выполнить операцию сложения, и такое же количество спичек положить в коробок с номером 15. Заглядываем в коробок №5 и запоминаем сколько в нём спичек, затем аналогичным образом поступаем с коробком №10, складываем запомненные значения. Это и есть то количество спичек, которое нужно положить в коробок №15. ЭВМ делает тоже самое, только не с коробками, а с ячейками памяти
Воможно это будет смешно но меня сподвигли идти в программирование уроки информатики еще а советской школе.
Когда я сам выучил бейсик опережая школьный курс и написал на нем примитивный морской бой (кое в чем помог журнал Техника Молодежи).
Дальше: универ, СМ-4, ЕС 1810, ДВК, лично спаянный спектрум, первые ПК, паскаль, асм, С, С++ и так далее.
Мне никогда не было тяжело этому учиться, я всегда хотел заниматься имено этим.
На мой взгляд, если идти в АйТи по зову исключительно денег то и будет тяжело.
Мне никогда не было тяжело этому учиться, я всегда хотел заниматься имено этим.
Присоединяюсь
На мой взгляд, если идти в АйТи по зову исключительно денег то и будет тяжело.
И снова присоединяюсь!
Информатика это моя боль. У нас в школе не было толковой информатики, не помню чтобы мы изучали какой-нибудь язык программирования.
Из-за этого я в принципе не представлял себе что такое программирование, пока не столкнулся с этим случайно. Однокурсник предложил подработать, админы сайт. Через это уже постепенно начал верстать а дальше уже и кодить, нашел работу и далее стал учиться программировать.
Была бы в школе хорошая информатика с обучением программированию - весьма вероятно, был бы уже сеньором, не потеряв ~10 лет на поиски профессии.
Вам предложили админить сайт на 10-ом курсе?
у меня был знакомый, который после пту работал крановщиком.
Потом так как контора маленькая - начал помогал продажникам с сайтом, потом начал править хтмл, понял, что у него что-то получается, но базы нет.
Так что он женился, пошел на курсы пхп (или джаваскрипта?), искал и нашел работу (все это время жил на деньги жены :) ), и теперь он уже лет пять как фронт+бек - программист, все дела.
У вас нет английской раскладки?
Простите великодушно, но как-то глаз режет вот это вот - хтмл, пхп, джаваскрипт.
Мне вспомнился случай... искали мы в организацию программиста, получили много много всяких резюме. И тут, вдруг, появляется резюме, в котором прописаны все существующие языки и технологии.
Ну, мы, естественно, вызвали к себе этого чудо-специалиста. Пришел молодой мальчик, лет так 20, не более.
Сидим, разговариваем. Вроде проблем в разговоре нет.
А потом я спрашиваю, - а ты эйч-ти-эм-эл на каком уровне знаешь?
Чего?, - спрашивает он.
Ну, эйч-ти-эм-эл, - повторяю я и пишу на бумажке аббревиатуру HTML.
Аааа! - с восторгом прокричал он, - Ха-тэ-мэ-лэ! Конечно знаю!
Конечно, мы его не взяли.
Ну, произносить букву "L" как "лэ" и правда странно, но в чём, собственно, проблема произношения HTML как "ха-тэ-эм-эль"?
Нет, если у вас международная команда, разговаривающая на английском — тут всё понятно, неправильное произношение просто не позволит работать в команде. Но если это не так, то какое вообще дело до того, как программист произносит аббревиатуры?
Я вот на слух одинаково легко что "Эйч-ти-эм-эл", что "Аш-тэ-эм-эл", что "Ха-Тэ-Эм-Эль" воспринимаю.
я вам рассказал историю успеха - про знакомого программиста, который начинал после пту крановщиком,
а вы мне рассказали историю - как вы не взяли кого-то только из-за того что он не читает акронимы по-английски (кстати, не все учили английский в школе, я знаю пару коллег, которые учили французский)
но, я рад что вы следите за чистотой русского языка на хабре, полезное дело делаете, продолжайте пожалуйста ещё
Мы его не взяли совсем не из-за того, что он не читает акронимы по-английски. А совсем по другой причине - он просто ничего толком не знал.
А историю я эту вам рассказал потому, что во всем нужна красота. И чем грамотнее у человека речь, чем связнее у него фразы, тем большая вероятность того, что он действительно специалист, а не просто погулять вышел.
А в вашей истории меня шокировало именно написание английских аббревиатур русскими буквами.
И, да, за минусы спасибо! Толком не разобрались, а минусов мне накидали. Воля ваша.
У нас в школе не было нормальной информатики, да и программировать нас тоже не учили. Но я интереса ради открыл в 11-м классе последние страницы учебника по информатике, где объяснялся базовый синтаксис visual basic) Вот таким нехитрым образом я открыл для себя мир программировния :)
Повезло, что на УПЦ (учебно-производственный цех) была специальность Оператор ЭВМ. Программировать там не учили, но общее понятие об алгоритмах дали. А уже перед самым окончанием школы повезло — в институте открыли «факультет юного программиста». Фортран, СРВ (а вот какая именно-вылетело из головы прямо в процессе написания этого сообщения) на СМ-1 и СМ-3.
Воможно это будет смешно но меня сподвигли идти в программирование уроки информатики еще а советской школе.
Информатика - как много в этом слове!
Ненавижу, на самом деле, это слово! О чем оно? Что это?
Это как кибенематика - смесь кибернетики и математики!
Можете минусовать, но я именно так воспринимаю это слово.
Я программирование изучал еще в советское время с помощью волшебной машины СМ-2 - правда, мы доступа к телу этой машины не имели, и писали программы на листочке бумаги, чтобы потом девочка набивала эти тексты для формирования перфокарт - мы потом сидели и проверяли правильность набивки с линеечкой - код EBCDIC. Да - это был 1982 год.
Затем у меня была дипломная работа с использованием того же Фортрана-4 - там уже была IBM360/370 (она же ЕС-1045) - не получалось - не хватало разрядности переменных (у меня были плохообусловленные матрицы 25-30 порядка - задача из области систем ориентации высокоманевренных объектов в шести степенях свободы), пришлось выучить язык PL/1 - также не помогло - в итоге все решилось с помощью ассемблера для этих могучих монстров.
Затем IBM PC (сначала XT, потом AT), соответственно языки C, Pascal, Asm (кстати, с ZX Spectrum, тоже своей сборки (точнее пайки - рисование битумным лаком дорожек, травление в ванночке с хлорным железом, пайка и т.п.), я также активно использовал Asm - но там я и в кодах работал - особенно, когда работал на одну контору, которая адаптировала игры под свои автоматы - ночами сидел и правил циклы программы, чтобы игра останавливалась по прошествии времени и ждала очередную монетку от игрока).
Затем отошел от программирования. И снова к нему вернулся лишь через 10 лет - это был уже C++.
Потом снова перерыв в 10 лет - и вот я уже веселюсь с C#.
Так что - программирование и только программирование!
Мне никогда не было тяжело этому учиться, я всегда хотел заниматься имено этим.На мой взгляд, если идти в АйТи по зову исключительно денег то и будет тяжело.
Один в один так же
Представь себе кучу пронумерованных/подписанных спичечных коробков, в каждом из которых лежит какое-то количество спичек. Коробок со спичками – это и есть ячейка. Адрес ячейки – это номер коробка или его название.
Отлично, а теперь на том же уровне про монады, внедрение зависимостей и TDD.
монады - для начала нужно понять, что это неизменяемые коробки спичек, то есть такие коробки спичек, из которых мы не можем ни достать ни положить спичек (считайте, что они там приклеены намертво эпоксидкой). Так что если мы "добаляем спичку", то на самом деле, мы берем со стеллажа готовый коробок, в котором на 1 спичку больше, старый коробок выкидываем, а новый кладем на его место: "вуаля! в коробке спичек №123 теперь на 1 спичку больше!" (а если мы "вычитаем спичку", то на самом деле - мы заменяем коробок новым коробком, в котром на 1 спичку меньше)
внедрение зависимостей - это когда вместо того, чтобы хранить все кучи коробок спичек (и разбираться что где лежит, доставать, смотреть, и т.д.), хранишь только фотографию номеров коробков сзади которой написано "у Пети". Если надо достать спичек или положить спичек - подзываешь Петю и показываешь пальцем по фотографии - в какой коробок что брать\ложить. Такие же фотографии есть для всех других внешних зависимостей - для Маши, Коли и Васи.
(Таким образом Петя вместо конкретного Пети, превращается в курьера доставки сети спичек "у Пети" - любой кто умеет работать по этой фотографии, вам подойдет)
TDD - сначала вы составляете "фотографию с номерами коробков", а потом по ней правила работы этой фотографии: "если сюда положить 10 спичек, то при открытии воон того коробка, там должно лежать 100 спичек" или "если сюда положить 0 спичек, то загорится зеленый, если 1 - желтый, если 2 - красный, а если 3 - и больше, то красный мигающий" и т.д.
Потом убедиться, что все они НЕ ВЫПОЛНЯЮТСЯ (фотография же - ничего не работает еще на самом деле). Только после этого начинать по этой фотографии и правилам делать такую систему коробков, чтобы все правила стали выполняться.
там был такой длинный текст, что я оставил от него только первую часть :)
а вам действительно интересно про монады на коробках от спичек ?
а нормально, по-взрослому, с полиморфизмом, конструкторами типов и вот этим всем.
воу воу, палехче!
вы точно темы для джуников айти предлагаете ?
Да. Это всё не сильно сложнее того же ООП, возможно даже что проще. Особенно если не применять на практике (впрочем, ООП без применения на практике тоже довольно простое).
ха! если не применять на практике (и без реальных предметов) - так я готов написать объяснение для чего угодно!
(а то, что не его/не поймут/не все - "это уже проблемы индейцев")
PS: но если серьезно, то насколько я вижу - процесс "обьяснения на пальцах" идет в сторону "сверху-вниз", от абстрактного к практическому - т.е. сначала рассказываются/показываются формальные правила, а потом уже демонстрируется поведение железа "на спичках" (как одной из реализаций формальной системы).
Объяснять в обратную сторону "снизу-верх", т.е. - сначала показать страшно сложную машинерию из спичек, чтобы потом выводить оттуда сравнительно простые формальные правила (собственно физики и биологи так природу изучают. Уже который век) - это ИМХО занятие не на один год и не для слабых духом ...
"коробки спичек" - так это же и есть int.
Вы хотите "ограничиться системами типов на int" и при этом получить "с полиморфизмом, конструкторами типов и вот этим всем" ? :)
Во-о-от, вы уже осознали проблему. Только почему-то ещё не поняли, что это ваша проблема, а не проблема оппонента…
ЭЭэээ... какая проблема?
если у меня и есть какая-то "моя проблема" - то я ее вижу только в том, что я согласился помочь объяснить хоть что-то "на коробках от спичек" и потратил на это свое время :)
Других моих проблем я как-то не наблюдаю.
UPD: да, кстати, запросы вида "нарисуйте мне красные линии зеленым цветом" - я тоже считаю проблемами не исполнителя, а просителя :)
Вы не просто согласились помочь объяснить хоть что-то, вы попытались оспорить утверждение о невозможности полноценно объяснить ФП "на коробках от спичек" (а Xeldos, когда просил это сделать, явно задавал риторический вопрос, в расчёте что все сами догадаются что это невозможно).
А теперь, когда сами согласились что это невозможно, почему-то продолжаете спорить. Зачем?
1) для начала - хотелось бы увидеть мнение самого Xeldos (а то у нас с вами - только интерпретации "как можно прочитать текст". Ну, или вы его второй аккаунт или читаете мысли и можете квалифицированно сказать - чего именно просил Xeldos)
2) извините, что я вас разочаровываю, но я даже не пытался что-либо оспорить :)
Я искренне думал, что кому-то будет интересно почитать описание монад+внедрение зависимостей+ТДД "на коробках спичек", и что будет забавно это попробовать сделать.
Про монады кстати я могу дописать, если Xeldos попросит-таки. А вот уже запросы от товарища 0xd34df00d
Желательно — не только в итоге выучить, что Maybe — монада, но и понимать монадическую структуру, скажем, парсеров или вероятностного программирования
или
нормально, по-взрослому, с полиморфизмом, конструкторами типов и вот этим всем.
это уже я пас.
Как я уже написал в комментрии выше, спички - они все-таки про реализацию, а не "понимание монадической структуры", для иллюстрации частного примера для детей т.н. "младшего школьного возраста". И во-вторых - краткий пример "на абзац текста" у меня пока не придумывается, а писать длинные тексты - это уже работа получается, а не комментарии на хабр :)
Я скорее хотел показать, что современное программирование капельку сложнее, чем то, что можно объяснить на "коробках от спичек".
Выше приведённое "объяснение"... Ну первый пункт - он просто неверен, как уже укзаали.
Второй пункт - вроде верен, но непонятен. Какие-то фотографии, пальцы, Пети...
Третий пункт - объяснение верное, понятное, но, увы, бесполезное. Уровня "мышки, станьте ёжиками".
В контрасте с этим аналогия "номер коробки спичек" - верная, понятная, полезная. Потому что поясняет простую, но незнакомую вещь.
Я скорее хотел показать, что современное программирование капельку сложнее, чем то, что можно объяснить на "коробках от спичек".
при том, что я с вами согласен,
но "там внизу" сидит машина тьюринга, и ее всегда можно будет объяснить "на короках спичек".
Да, современное программирование от той машины тьюринга отделяет не один десяток абстракций, тем не менее - почему сдаваться сразу?
первый пункт - он просто неверен, как уже укзаали.
первый пункт - неполон. Если вы хотите - то распишу полностью.
Какие-то фотографии, пальцы, Пети...
"фотография" - это же аналогия "интерфейсу", когда реально ничего нет, но есть только "вид сверху".
(Еще можно использовать не "курьера + фотографию коробок спичек", а официанта и меню)
Так что "инъекция зависимости" - это когда вместо чего-то реального - есть интерфейс (ака фотография номеров коробок) и есть ссылка на реализацию этого интерфейса (ака "Петя", которому можно ее показать и попросить "я хочу вот сюда положить\забрать спичек").
но "там внизу" сидит машина тьюринга, и ее всегда можно будет объяснить "на короках спичек"
Во-первых, ни за одним современным компьютером машина Тьюринга не "сидит".
Во-вторых, изучение программирования "с низов" с постепенным повышением уровня абстракций — это очень сложный и больной путь, к тому же чреватый грубыми ошибками. Это совершенно не то, что стоит рекомендовать всем, да ещё и пряча за простотой "коробков спичек".
Во-первых, ни за одним современным компьютером машина Тьюринга не "сидит"
https://ru.wikipedia.org/wiki/Машина_Тьюринга
хотя, возможно, вы пишете алгоритмы для не-пошагового исполнения (или не алгоритмы?), тут может быть всякое.
Во-вторых, изучение программирования "с низов" с постепенным повышением уровня абстракций — это очень сложный и больной путь
разумеется можно начинать с любого уровня абстракции, но когда-то ведь наступает момент "а что такое алгоритм вообще?" Так что "коробки спичек" - вполне работающая промежуточная (между кремнием и браузером) аналогия.
тому же чреватый грубыми ошибками.
???
Скажите, а почему проблемы стандарта одного языка, считаются проблемами программирования вообще?
хотя, возможно, вы пишете алгоритмы для не-пошагового исполнения (или не алгоритмы?), тут может быть всякое.
Нет. Но я пишу алгоритмы, которые работают с жёстким диском, сетью, монитором, клавиатурой и мышью в конце концов, а бесконечной ленты я как-то среди периферии не наблюдаю. И математическая эквивалентность ещё не означает что машина Тьюринга и правда находится где-то внутри.
Да блин, даже асимптотика алгоритмов на реальных компьютерах, абстрактных машинах с памятью и на машине Тьюринга различаются!
Скажите, а почему проблемы стандарта одного языка, считаются проблемами программирования вообще?
Это общая проблема изучения абстракций снизу вверх. Высокоуровневые вещи от такого обучения перестают восприниматься как абстракции, и начинают восприниматься как что-то вроде макросов для написания низкоуровневых. А отсюда до ошибок с UB полшага, независимо от языка программирования.
даже асимптотика алгоритмов на реальных компьютерах, абстрактных машинах с памятью и на машине Тьюринга различаются!
хм, а можете показать пример ?
А то я до сих пор был уверен, что они отличаются на константу, но асимптотика у них одинаковая (т.е. если бинарный поиск работает за K*log2(n) то он везде так работает, только если писать алгоритм на эмуляции машины тьюринга, то К будет - на пару порядков больше, чем у реального процессора)
А отсюда до ошибок с UB полшага, независимо от языка программирования.
... достаточно много языков программирования ловят свои UB на этапе компиляции, а во время исполнения - на встречу с UB реагируют выбрасыванием "ошибки времени исполнения" (остановка исполнения и\или порождение исключение и т.д.),
вместо "Renders the entire program meaningless" после чего среда исполнения делает странные вещи
хм, а можете показать пример ?
Да любой алгоритм посмотрите. Тот же бинарный поиск на машине Тьюринга работает за линейное время, а последовательный поиск — за квадратичное. Доступ к памяти-то строго последовательный...
достаточно много языков программирования ловят свои UB на этапе компиляции, а во время исполнения — на встречу с UB реагируют выбрасыванием "ошибки времени исполнения"
Если UB можно поймать в обычном (не отладочном) режиме — это вообще не UB.
И UB вовсе не обязательно должны быть языковыми, его могут добавлять библиотеки. Например, во фронтенде UB будет при одновременном управлении элементом через два разных фреймворка или через фреймворк и библиотеку/DOM.
Доступ к памяти-то строго последовательный
"лента" - это внешнее хранилище, его линейность доступа ничем не хуже линейности доступа ленточных накопителей.
(Зато переход по состояниям - мгновенный. Такой скорости нет даже в регистрах процессора!)
И UB вовсе не обязательно должны быть языковыми, его могут добавлять библиотеки.
и что - в других языках при встрече с UB - играет музыка и пишутся стихи в логах ?
Например, во фронтенде UB будет при одновременном управлении элементом через два разных фреймворка или через фреймворк и библиотеку/DOM.
и где там UB ? Как обычно: "кто последний /пишет данные/ - тот и папа".
Монады можно воспринимать как робота. Вы ему даёте команду обработать коробки со спичками и всё.
Может ему вообще не достанется коробка, или придется обрабатывать целый ящик коробков. Или он будет ждать, пока ему этот коробок принесут, или человек даст ему этот коробок.
Класть. Простите, не сдержался.
Вот кстати да, уже давно понял что программирование нужно объяснять прям реально на игрушках, впору книгу писать "Программирование для самых маленьких", без сарказма.
А мне врезалась в память фраза "компьютер — это такой савант: по жизни — полнейший идиот, но считает ОЧЕНЬ-ОЧЕНЬ быстро". Из чего вытекает, что считать должен он, а думать, как ему считать (включая ситуации "бумага закончилась", "карандаш сломался", "в комнате свет погас", "на таблицу логарифмов сел мотылёк", "уборщица у него под стулом протереть пытается" и т.д.) — я.
Ребята, переставайте идти в IT, сейчас джунов перебор
Джунов много не бывает, пусть ребятки работают, может хоть вырастим и сохраним пару спецов нормальных в пределах нашей страны
Причем часть джунов сейчас совершенно не мотивированная. На днях с таким пришлось чуток поругаться. Джун с почти полугодом опыта пришел за помощью с багом, само собой я за него дебажить его простыню кода не стану, посоветовал ему сначала отрефакторить свой класс, привести к принятым в компании стандартам, плюс постараться разбить методы на более мелкие с рассчетом на то, что он при рефакторинге сам увидит косяк, как это происходит в 90% подобных ситупций, либо тогда уже я присоединюсь и читать хоть будет удобно. На что в ответ получил замечательную фразу "Ай не, тут все работает по большому счету, а как код выглядит - плевать". Сам не являюсь адептом красивого кода, из тех что нейминг переменных продумывают полдня и отступы ровняют под линейку, но подобное пренебрежение code style и советом старшего более опытного сотрудника немного подожгли пятую точку
Предположим что есть один хороший матерый кот. И есть тысяча котят.
А нам надо ловить крыс. Какую конкуренцию коту составит тысяча котят?
Что за мода пошла совать везде идиотские (ох простите мою токсичность) аналогии, не задумываясь, отражают ли они реально суть ситуации, которую пытаетесь показать с помощью аналогии.
Ну давайте проще.
Вам нужно выполнить некоторую работу. У вас на эту работу есть определенный бюджет и определенный срок сдачи. Не уложитесь в срок - не получите денег.
Кого выберете - человека, который заведомо может эту работу выполнить, или того, кого вам придется обучать, контролировать и результат все равно не гарантирован.
И да. От того, выполните работу в срок или нет напрямую зависит будет вам на что покушать купить или нет.
Вот так вот просто. Сотрудника нанимают не "чтобы было", а чтобы он работу работал и приносил прибыль.
Да, когда у вас есть перспективы развития, вы можете взять пару джунов "на будущее" (не под текущие задачи) и потихоньку вводить их в курс дела, обучать в расчет что через какое-то время он начнет давать отдачу. Но и тут есть риск что как только вы джуна обучите, он от вас уйдет в другое место где ему пообещают на три копейки больше. И в результате вы потратитесь впустую. А кто-то за ваш счет выиграл.
Ну и учитывайте что "вайти" идет много шлака. Не потому что им интересно, а потому что им из каждого утюга в уши льют "заплатите нам 50тр сейчас и через три месяца вам гарантирована работа с оплатой 100500 в час". А по факту там ни базового образования, ни зачатков алгоритмического мышления, ничего. Полная профнепригодность. Им даже все это неинтересно и скучно, они сюда исключительно за деньгами пришли и больше им ничего не надо.
Кого выберете - человека, который заведомо может эту работу выполнить, или того, кого вам придется обучать, контролировать и результат все равно не гарантирован.
вы будете смеяться - но если это второй-третий проект из серии (ака "формошлепство"), а что-то уникальное и новое - то ни джун ни синьор гарантировать ничего не смогут. В жизни всегда есть место удивительному.
Единственное что можно будет гарантировать - что синьор сможет сравнительно быстро разобаться - можно или нет это сделать, сделает если "да", и если "нет" - то предложит варианты - как можно что где обойти, если таки что-то сделать невозможно.
С джуном вы будете делать проект долго, нудно и если будет фейл - то не сможете разобраться, толи это был фейл задумки (ака "звезда с неба"), то ли фейл инструментария (ака "на санках по асфальту ездить можно, но мотор слабоват") или фейл самого джуна (без комментариев)
Ну честно скажу что с формошлепством дел никогда не имел.
В нашей ситуации джуну можно поручить что-то совсем простое и совсем типовое на что нет смысла отвлекать более "серьезных" разработчиков. Но при этом надо закладывать какое-то время "старших товарищей" на код ревью и разъяснение простых вопросов "почему так нельзя". Примеры приводить не стану т.к. они очень специфичны в силу ряда причин.
Когда на задачу ставится более опытный разработчик, заведомо известно что совсем косяков по эффективности и производительности там точно не будет. Потому что у человека опыт и понимание как не надо делать (именно "как не надо" приходит с опытом). И человек готов написать лишние пару-тройку десятков строк кода ради эффективности там где это нужно, а не просто воткнуть туда первый попавшийся компонент, не понимая как но работает внутри (опять же - конкретные примеры слишком специфичны). Это как раз тот самый пример "на санках по асфальту" - джун просто не знает что можно иначе.
ну пример "формошлепства": есть фронт+бек, есть формочка для описания человека (фио, телефон).
задача типовая: Нужно добавить еще одно текстовое поле телефон2. Берем почти любого джуника, говорим "копипасть существующий контрол, копипасть поле phone на phone2, и в БД тоже". Там могут быть какие-то мелкие проблемы, но в целом он справится.
задача не такая типовая: Нужно сделать переменное количество таких полей. Ее тоже можно сделать, но джуник уже может сломаться во многих местах.
И совершенно нетиповая задача: портировать ваше приложение на новое устройство (напрмиер Win->android).
Собственно мой (почти риторический) вопрос был такой: гарантирует ли там что-то синьор, если ваше приложение использует что-то из DirectX, у чего нет порта в OpenGL на целевом устройстве?
PS: заранее соглашусь с вашим "заведомо известно что совсем косяков по эффективности и производительности там точно не будет". Программист с опытом и в тестах еще что-нить добавить, чтобы проверяло что "ответ от системы пришел быстро".
задача типовая: Нужно добавить еще одно текстовое поле телефон2. Берем почти любого джуника, говорим "копипасть существующий контрол, копипасть поле phone на phone2, и в БД тоже". Там могут быть какие-то мелкие проблемы, но в целом он справится.
Ну собственно да. Такое (не точно такое, но подобное) есть везде. У нас тоже есть типовые задачи где особо не надо думать. Более того, они уже шаблонированы - существуют т.н. "скелетоны" - заготовки, которые надо взять и вписать туда свои структуры данных, таблицы, имена полей и т.п. А вся логика на 95% (5% оставим на какое-то вдруг нестандартное поведение в какой-то части) уже прописана в скелетоне. Опытный разработчик такие задачи (если вдруг приходится) делает по 2-3 штуки в день. Начинающий - пару дней на задачу (просто он медленнее видит что куда вставить).
Но у нас нет цели держать бригаду джунов, которые будут этим заниматься. Наша система подразумевает что берется стажер на 20 часов в неделю на полгода, сначала небольшой период обучения, потом такие вот задачи. Потом чуть посложнее. И еще сложнее. И еще... Т.е. человек должен расти постоянно. Рост слабо ограничен. Я, с 5+ лет стажа на этой системе и должностью главного разработчика (и частично обязанностями архитектора направления), часто дискутирую с главным архитектором направления по тем или иным решениям и порой приходится соглашаться с тем, что мои архитектурные решения не всегда оптимальны в каких-то случаях (хотя бывает что и свою точку зрения удается аргументированно отстоять). Т.е. еще есть куда расти.
Собственно мой (почти риторический) вопрос был такой: гарантирует ли там что-то синьор, если ваше приложение использует что-то из DirectX, у чего нет порта в OpenGL на целевом устройстве?
Ну 100% гарантии никто не даст, конечно. Просто есть задачи, которые для джуна непосильны для реализации в конечное время. Просто в силу недостаточности кругозора. Как правило, это очень нетипичные задачи. Например, прилетает письмо от сопровождения:
Коллеги, сервис *** за последние 5 недель увеличил потребление процессорных ресурсов в 3 раза!!!
Он уже является 2-м по величине сервисом после *****.
В качестве альтернативы мы рассматриваем перенос запуска сервиса на резервный сервер, но там есть лаг по отставанию до 10 мин.
Заказчикам сервиса это может не понравиться :(
Т.н. "задача на оптимизацию". Начинаем разбираться и видим, что в основе сервиса лежит 3-4 независимых функции, частично похожих одна на другую. Причем, все из них имеют одну базовую процедуру, достаточно тяжелую. И при их последовательном вызове эта базовая вызывается несколько раз. Т.е. налицо дикий оверкод.
Выхериваем все напрочь, делаем одну универсальную процедуру с набором параметров. На входе смотри что из парамтеров передали, что не передали и понимаем стратегию работы для данного набора параметров. Смотрим что из параметров дублируется с прошлого вызова и определяем что можно использовать из кеша прошлых вызовов, а что нужно переделать заново.
Т.е. полностью избавляемся от оверкода + добавляем кеширование всего что только возможно. Плюс немножко (насколько возможно) дорабатываем индексы БД. И в результате имеем
Коллеги, доброе утро!
Спасибо!
Уже утром видим очень хороший результат!!!
Доработка сокращает потребление процессорных ресурсов почти в 10 раз!
на следующий день после вкатывания в бой.
Но это две недели копания, разборок что где как, выстраивания архитектуры и алгоритмов, тестирования (в т.ч. нагрузочного).
И такого предостаточно. Вплоть до того, что сначала аналитик набрасывает черновик ТЗ с общими положениями что пришло и что надо получить, потом впрягается разработчик и вдвоем выстраивается архитектура и алгоритмический каркас, потом все это реализуется и тестируется, а только потом уже по готовому коду описывается в ТЗ (оно же является документацией по задаче - нужно для последующих доработок).
И вот разработчиков такого уровня нехватает. Тех, кто напишет, потом посмотрит, увидит "лишний" код, который можно упростить, доработает и получит максимально эффективное решение. И да, интерес в том, чтобы джуны вырастали со временем именно в таких разработчиков. Не просто "я человек маленький, хожу сюда за деньгами", а были проактивны, кроме проектных задач брали еще "технические", для саморазвития (декларируется что ты имеешь право 80% времени заниматься проектными задачами и 20% - техническими, которые выбираешь себе сам).
Вы всего лишь описали возможные частные случаи. Кого брать зависит от конкретной ситуации. Частично об этом я сказал ранее здесь: https://habr.com/ru/post/682250/comments/#comment_24626034
В части аналогий я хотел сказать только то, что надо или посмотреть на ситуацию с разных сторон и привести нормальную аналогию, которая действительно помогает разобраться, а не уводит еще дальше от сути.
Кого выберете
Смотря из кого выбирать, сколько можно/нужно платить, что по срокам.. Иногда за неимением гербовой бумаги пишем на клозетной ;)
От количества джунов, которые пришли с месячных курсов, их качество никак не меняется. А те, котоые были мотивированы заранее, они более-менее подтянутся и без курсов.
Потому, что котята на полном серйозе не понимают, что если они принесли бабочку — это не крыса. И нет, оно не «почти крыса», а вообще не крыса.
А также не понимают, что если они принесли одну и в процессе выпустили 10 крыс — это никому не надо.
А нам надо ловить крыс. Какую конкуренцию коту составит тысяча котят?
Вы про zerg rush никогда не слышали?
Где это разработка ведётся методом zerg rush? ;)
Во-первых, речь была про крыс и котят. Котятам вполне по силам рашнуть крысу.
Во-вторых... Вы будете смеяться, но в конце 1990-х в моей практике был один товарисч, который работал методом, чем-то напоминающим нейросети и TDD в одном флаконе: приписывал к своей программе пару случайных (ну, такими они, как минимум, выглядели) строк кода и смотрел, ближе ли выдаваемый программой результат к желаемому, или нет. Поддерживать ЭТО, естественно, было совершенно невозможно — и наше счастье, что это были просто сервисные скрипты, а не продукт для клиентов. Так вот, как мне кажется, его метод — самое то для зерг-раша.
он работал рекуррентной нейронной сеткой еще до того, как это стало мейнстримом!
В Индии ? )
Чем больше джунов, тем больше конкуренция среди нихИ тем труднее выбрать работодателю, что приводит к отсеву методом «а зачем нам неудачники» (это где часть присланных резюме сразу отправляется в корзину без просмотра)
больше сил нужно приложить, чтобы быть замеченнымвместо того, чтобы приложить усилия к освоению разработки
вместо того, чтобы приложить усилия к освоению разработки
Согласен отчасти. Чтобы заметили где-то нужно будет показать еще какие-то качества, кроме непосредственно разработки, но в идеале кандидат должен как раз обладать нужным набором качеств. Вопрос в части выбора оптимального кандидата из имеющихся по большей части не проблема кандидатов. Ну, в идеале.
Вот смотрите. Ситуация на самом деле где-то такая.
У нас есть какое-то количество учителей. Им, как правило, платят мало или вообще не платят за обучение. Потому что основная работа у них — не учитель. У нас есть какое-то количество специалистов(это те или другие люди) которые работают и получают денги, но учить им некогда, развечто могут дать пару советов или натолкнуть на идею ЕСЛИ учащийся правильно сформулировал вопрос.
Допустим учителей Х, у них есть по 3 часа в день и консультантов Х*4, но у каждого по 15 минут в день.
Внимание, вопрос. Какое качество обучения будет, если обучаться будет Х человек по сравнению с вариантом, когда обучаться будет 10*х(на каждого — 0.3часа учителя и 6минут в день косультантов).
А еще ведь есть курсы, где «учителя» получают по 200 долларов, и подразумевается, что они имеют ту же квалификацию, что и программисты с зарплатой 4000+. Понятно, что рынок так не работает и на курсах преподают мягко говоря не лучшие профессионалы.
Просто в IT сейчас идут, начитавшись об офигительных зарплатах. При этом, практически никто не представляет себе путь в программисты. В статье весьма неплохо описано разочарование программистов в те или иные моменты времени. Жаль только, что там только одна пустыня отчаяния - у меня лично таких пустынь было уже около пяти.
Тут ведь как - never give up - я лично придерживаюсь этого подхода.
А молодежи подавай сейчас огромную зарплату сразу.
Кстати, обратным проявлением этого являются и требования со стороны нанимателей - им тоже подавай программиста 10 лет опыта, знающего все что можно и что нельзя, и не старше 20 лет от роду.
И тут возникает интересный момент в стиле "рыночек порешает". В условиях, когда "благодаря" многочисленным курсам и рекламам ютуберов джунов становится как собак нерезанных, что-то мне подсказывает, что это неминуемо приведёт к снижению зп на уровне тех же самых джунов. К тому же у работодателя появляется возможность отбора кандидатов.
И в этом будет неприятный сюрприз для всех. В первую очередь для тех, кто пришёл в IT за деньгами.
Он начал с изучения Ruby, а затем пробежался по другим языкам, таким как Scala, Clojure и Go
Ничего себе, пробежечка. А потом он поразмялся в освоении Rust, Haskell, Coq и Prolog? Да этот Коля, мать его, гений!
Потому, все псевдопсихологические рассуждения в статье не имеют смысла, так как изначально произведена подмена объекта обсуждения.
И подавляющее большинство «онлайн курсов» изучить программирование тоже не помогут: они дрессируют писать типовой код, решающий типовые рутинные задачи, но не дают знания основ программирования.
Но 90% разработчиков и пишут типовой код, решающий типовые рутинные задачи. Потому что, собственно, решение типовых рутинных задач и есть основная задача автоматизации и программирования.
Проблема в том, что 90% современных разработчиков не понимают, как работает код который они написали. В этом отчасти виноваты дешевая электроника, "облака" и прочие факторы - когда "купить инстанс побольше" гораздо быстрее и дешевле, чем оптимизировать что-то "тормозящее" - но и нежелание разбираться тоже присутствует, поддерживаемое известным определением Аджайла "slap shit together and deploy".
80% сеньоров не знакомы с основами микроэлектроники и у них нет понимания архитектуры процессоров. И что с того?
Вообще, «до какой глубины нужно знать» — вопрос тоже весьма непростой. как и вопрос «по каким критериям нужно оптимизировать систему»
Основы микроэлектроники тут ни при чем. А вот незнание основ архитектуры - приводит к созданию чудовищно тормозных систем, жрущих гигабайты памяти и уходящих в астрал при переносе в VM или просто на другой компьютер.
Как можно понимать архитектуру не зная микроэлектронику? Там вообще-то одно вытекает из другого.
/sarcasm
я вот как-то на Яндекс.помойке спорил с «олд радиолюбителями». Так вот, там часто слышал: мы вот сами на пентоде радиоприемник делали, а нонешние назакажутЪ на алиэкспресссах кубиковЪ, да соединяют их проводами по схеме и все. ну и по клавишам тыкают… и вот справшивал их, а почему соединить «пентод с» «по схеме» — это истинное радиолюбительство, а «заказаные кубики» — уже нет? а почему «кубики» нужно обязательно «паять самому из микросхем», а вот тот же пентод самому почему-то делать из стекла и палок не требуется…
Архитектура процессоров это один из подразделов по основам микроэлектроники. Если в школе физику не прогуливал, то этого достаточно чтобы освоить данный курс без знаний физики твердого тела.
Т.е. — зачем осваивать курс микроэлектроники?
Кроме того, я повспоминал то, что преподавали нам, не вспомнил там никакой «архитектуры процессоров», сделал скидку на то, что я древний как ГМ, и полез смотреть более современные учебники…
Введение 3
1. Основные принципы и понятия
микроэлектроники
5
1.1. Основные термины и определения 5
1.2. Интегральные микросхемы (ИМС) и их
классификация. Серии ИМС 11
1.3. Система обозначений ИМС 21
2. Активные элементы интегральных микросхем 27
2.1. Методы изоляции элементов 28
2.2. Интегральные транзисторы 36
2.3. Интегральные диоды 43
2.4. Транзисторные структуры специального
назначения 49
2.5. Элементы полупроводниковых постоянных
запоминающих устройств (ПЗУ) 58
2.5.1. МНОП-транзистор 59
2.5.2. МДП-транзистор с плавающим
затвором 61
2.5.3. Двухзатворный МДП-транзистор 62
2.6. Приборы с зарядовой связью 64
3. Пассивные элементы интегральных схем 72
3.1. Интегральные резисторы 72
3.2. Интегральные конденсаторы
и индуктивности 77
3.3. Коммутационные соединения 83
4. Современные тенденции в развитии
микроэлектроники 88
4.1. Закон Мура как основа оценки темпа
развития микроэлектронных технологий 89
4.2. Развитие технологий «Больше Мура»
4.3. Развитие технологий «Больше, чем Мур»
104
111
4.4. Направленность «За пределами КМОП» 114
5. ИМС диапазона СВЧ 115
5.1. Элементная база электроники СВЧ 117
5.2. Интегральные транзисторы СВЧ-диапазона 121
5.3. Монолитные арсенид-галлиевые ИС 124
6. Гетероструктуры в современной
микроэлектронике 127
6.1. Основные свойства гетероперехода
6.1.1. Сверхинжекция неравновесных
носителей заряда в гетеропереходе
127
129
6.1.2. Понятие о двухмерном электронном
газе 130
6.2. Гетероструктурные полевые транзисторы 132
6.2.1. Транзистор с высокой подвижностью
электронов 132
6.2.2. Псевдоморфные и метаморфные
структуры (р-НЕТ и m-НЕТ) 134
6.2.3. НЕМТ на подложках из GaN 137
6.3. Гетеропереходные биполярные транзисторы 138
6.4. Интегральные микросхемы
на гетеропереходных полевых транзисторах 140
— Учебное издание
Свистова Тамара Витальевна
ОСНОВЫ МИКРОЭЛЕКТРОНИКИ
В авторской редакции
Подписано к изданию 30.10.2017.
Объем данных 2,6 Мб.
ФГБОУ ВО «Воронежский государственный технический
университет»
394026 Воронеж, Московский просп., 14
И ни в одном из них ни слова про архитектуру процессоров.
Отсюда я сделал вывод, что микроэлектроника с архитектурой процессоров связана достаточно слабо, т.е. архитектуру можно изучать и без изучения микроэлектроники.
А вот в знаменитой книге Харрис(ов) по архитектуре — тому, что можно хоть как-то назвать «микроэлектроникой» внимание уделено аж на 14 страниц из 750. И это — в специализированном учебнике по архитектуре, причем только одного процессора! Если добавить их же дополнение по АРМ, еще 350 страниц, то получаем 14 страниц из 1100.
Архитектура может быть успешно абстрагирована от микроэлектроники. Универсальные процессоры c архитектурой RISC и CISC, специализированные DSP и GPU, ISP и DLA - все они делаются на тех же фабриках и по тем же нормам, при абсолютно разных архитектурах.
Конечно можно абстрагировать. Правда не совсем понятно зачем это делать. Там не так уж много требуется усвоить информации. Как по архитектуре процессоров, так и по основам самой микроэлектроники.
Изучение абстрагированных вещей без понимания истории появления вещей обычно дается труднее и сложнее.
Видимо, у нас разное понимание "микроэлектроники". Для меня - это все те знания, которые необходимы для появления на кристалле достаточного количества логических элементов с нужными частотными/тепловыми/электрическими/радиационными характеристиками, и соединений между ними. А архитектура - оперирует абстрактными логическими элементами и базируется на математической теории автоматов. VeriLog, используемый для проектирования микросхем - ничего о микроэлектронике не знает.
Например, в СССР выпускались несколько вариантов процессора 580ВМ80 - по МНОП, КМОП и ЭСЛ технологиям, с несколько отличающимися выводами - т.е. разной "микроэлектроникой". При этом архитектура у них - одна и та же.
смотрите, у нас есть архитектор, который проектирует мосты. он чертит не на бумаге, а в программе. его главный инструмент – это компьютер, на котором крутится, скажем, SolidWorks. есть бухгалтер. идеально знает 1С и все возможности Экселя. дизайнер интерьеров, который делает рендер готовой квартиры для заказчика. надо ли им знать ширину запрещённой зоны кремния или отличать гетерструктуру от металлизации полупроводника. или основы квантовой механики ? думаю, что нет. а надо ли это знать сеньёру ? имхо, ему даже не надо знать, как работают прерывания системы, если это не его компетенция.
мне в руки одна книга попала, типа известная. там на обложке был стол на курьей ножке. и автор говорит, "раньше я экзаменовал студентов на имя_языка и сразу видел их способности. а потом появился Си, и все обленились." в защиту студентов хочу сказать, нельзя всем знать всё. если я мастер Java и алгоритмов, кто меня обвинит, что я не знаю, как сделать бинарное дерево или парадокс Тьюринга halting machine ? кто-то операционные системы пишет, кто-то компиляторы или новые методы сортировки.
одним словом, надо знать свой инструмент, который меня кормит. а смежные знания – как плюс.
Дело в том, что "знают свой инструмент" очень немногие. Самый простой пример - паттерн "прокси" можно реализовать в виде двух очередей (запросов и ответов), при этом система будет очень надежной и не выйдет (при ограничении длины очереди) за заданное потребление ресурсов.
Но почему-то его почти всегда реализовывают в виде (запрос, ожидание, ответ)*100500 тредов, да еще и с авто-масштабированием - точно в соответствии с теорией приводящим к отказам в обслуживании при малейших пиках нагрузки.
Вы так пишете, как будто с двумя очередями отказов в обслуживании быть не может. Особенно при ограничении длины очереди.
Отдельный вопрос — как вы собрались делать прокси на очередях когда находящаяся за прокси система работает без очередей.
С двумя очередями состояние будет всегда детерминировано. В худшем случае клиент получит сообщение о переполнении очереди - и как-то на него прореагирует. А в системе на тредах - она лихо смасштабируется вверх и зависнет, тихо шурша этими самыми тредами и продолжая долбить апстрим запросами, ответа на которые уже никто не ждет (клиент отвалился по таймауту).
Как работает апстрим - с очередями или без - совершенно не важно, но если прокси работает с очередями - он может контролировать время обработки и не посылать одновременно слишком много запросов, демпфируя пики.
Неа, всё прямо наоборот. Если делать на тредах — ещё есть шанс не забыть отменить запрос к апстриму и освободить ресурсы, а вот в случае с очередями вы задачу из очереди не вытащите. В итоге при неудачном стечении обстоятельств под нагрузкой в очереди будут лежать, главным образом, задачи которые никто уже не ждёт. Не просто так иногда и вовсе рекомендуют срочные задачи складывать в стек, а не в очередь.
Отмена запроса к апстриму в тредах - требует весьма нетривиального "самопрофилирующегося" кода. Плюс - никто не гарантирует, что между проверкой условия валидности запроса и собственно отсылкой в апстрим не пройдет значительное время.
В очереди же - ничто не мешает снабдить запрос при добавлении в очередь временной меткой, проверить ее перед отсылкой в апстрим, и не отсылать если запрос "протух". Да и запросы в очереди могут быть разными, к разным апстримам и т.п.
Насчет стек vs очередь - да, это правда, телефонные станции, например, так работают. Но логика добавления новых задач здесь вторична - при работе с тредами вы не сможете управлять приоритетами вообще.
Отмена запроса тривиальна, лишь бы только используемые библиотеки её поддерживали.
Проверять метку времени в очереди — идея здравая, но это не спасёт от переполнения очереди устаревшими задачами. Каждый запрос, пролежавший в очереди и выброшенный из-за устаревания, напрасно занимал в этой самой очереди место.
Вы ошибаетесь насчет отмены. Если соединение открыто, и туда записаны какие-то данные - поздравляю, вы уже потратили ресурсы апстрима. А если вы записали все и ждете в каком-нибудь read() - то его вообще прервать не получится, да и не понятно, кто это должен делать - у вас же нет никакого "арбитра", просто тред на каждый запрос.
Очередь запросов - ничто по сравнению, например, со стеком и памятью, выделяемыми каждому треду. Да и проблема как правило не в обьеме чего-нибудь - а в неконтролируемом его изменении.
Плюс - в тред-модели вам будет намного сложнее передавать сразу несколько запросов по одному соединению (HTTP2) или просто повторно его использовать (Keep-Alive), экономя время, дескрипторы и память.
Если соединение открыто, и туда записаны какие-то данные — поздравляю, вы уже потратили ресурсы апстрима.
Но это не повод продолжать тратить их дальше.
А если вы записали все и ждете в каком-нибудь read() — то его вообще прервать не получится
Вы сейчас про read из прикладной библиотеки или про системный вызов? В первом случае надо внимательнее выбирать библиотеку, во втором — закрытие сокета отменяет любые операции ввода-вывода над ним, если вы не знали.
Очередь запросов — ничто по сравнению, например, со стеком и памятью, выделяемыми каждому треду.
Ну да, поэтому и переходят массово с потоков на сопрограммы, горутины там или свежие виртуальные потоки в Java. Но ни один из этих способов не означает автоматического добавления очереди.
Плюс — в тред-модели вам будет намного сложнее передавать сразу несколько запросов по одному соединению (HTTP2) или просто повторно его использовать (Keep-Alive)
Вообще ничего сложного. Это забота фреймворка.
Алгоритмы тоже не являются программами, примерно как наваленная груда кирпича ещё не здание)
Оказалось, самое сложное - доносить о том, что надо писать программы, а не код или алгоритмы. И исходить надо при проектировании из программы, используя алгоритмы и код лишь как инструменты. Не редко выходит иначе даже после 5 лет работы программистом.
Оказалось, самое сложное - доносить о том, что надо писать программы, а не код или алгоритмы.
Самое сложное - таки алгоритмы. Для чего-то нового и что достаточно быстро решать не умеем. Смотри всякие алгоритмы оптимизации и поиска. Да, те самые, которые потом еще доказать надо, почему они на 0.05% быстрее работают, чем то, что уже известно. Но на практике большая часть работающих в индустрии людей придумыванием таких не занимается. И, вообще, оно не программирование уже, а Computer Science.
В реальных коммерческих проектах редко нужно это все. Как пример - у нас есть шелл, который данные из одного микросервиса сбрасывает в кафку, шелл работает 20 часов ориентировочно, его реально ускорить если сделать batch отправку, но тут уже есть нюанс - для этого надо выделить ресурс команды, которая писала либу транспорта в кафку, а они занимаются не только этой либой и бизнесу важнее продуктовый выхлоп команды чем какое-то там ускорение какого-то скрипта, который на юзеров не влияет и прибыль не уменьшает. Угадаете когда этот техдолг будет решен? А я подскажу - скорее всего никогда, если только не пропихнуть в спринт в нагрузку к остальным задачам когда есть небольшой запас по времени
Кафка не такая и сложная, там можно и стандартными либами самой кафки обойтись. Это я к тому, что помощь другой команды на самом деле не требуется, нужно лишь знать какие-нибудь языки кроме того "шелла".
Кстати, забавно что в плюсы микросервисов обычно записывают то, что разные микросервисы могут писаться на разных языках разными командами, которые друг от друга не зависят. А потом какой-то скрипт на 20 часов не получается ускорить только из-за того, что понадобились действия от другой команды...
отличный коммент. что почитать чтобы вот Коля стал в программировании чуть больше понимать?
Сегодня индустрии вообще уже не нужны живые кодеры?
Разве "хочу написать такую же игру" не выглядит, как что-то одноразовое?
За первой тут же следует вторая.
Краткое содержание статьи:
1) Всё новое сложно.
2) В конце концов вы справитесь, если будете этим заниматься.
Мне, как учителю, однозначно в избранное.
Забавно, а я в айти так и не зашел, хотя прошло уже 8 лет - как я пытаюсь выучить хоть что-нибудь
За 8 лет можно стать сеньором если учить системно и упорядоченно, плюс практика. Ну или эти 8 лет можно потратить чтобы 5 лет отучиться в вузе по специальности, и еще 3 года останется чтобы устроиться на работу и дорасти до middle+ спокойно. Вы что-то делаете не так
Забавно, а я в айти так и не зашел, хотя прошло уже 8 лет - как я пытаюсь выучить хоть что-нибудь
Всё ОК, не вы один такой :)
Я в ИТ официально с 1998 года. свой первый сертификационный экзамен от IBM сдал ещё в 2005. После уже сдал несколько экзаменов от Microsoft и AWS.
До сих пор джуном себя считаю, перед собой вижу бездонное море :)
Если говорить в терминах этой статьи, то почему производство ПО не может извлечь пользу из тех, кто прошел первичное обучение и попал в «пустыню отчаяния». Ведь если бы их удалось задействовать, то эти специалисты — достаточно дешевые благодаря их низкой уверенности — могли бы приносить немалую прибыль производителям ПО. А
То есть, если говорить в терминах цехового ремесленного производства, почему индустрии IT обязательно требуются мастера, а не подмастерья? Ведь, как известно, в процессе развития от цехового ремесленного к промышленному производству промышленная индустрия научилась эффективно задействовать подмастерьев в рамках мануфактуры — ещё до массового внедрения машин. Почему же индустрия IT не может проделать то же самое?
Связано ли это с недостаточной зрелостью индустрии, или же с особенностями производства ПО, не позволяющими выделять сколько-нибудь массово простые задачи, доступные специалистам прошедшим базовое обучение? Последнее мне странно, ибо тот же CRUD, которого почти на любом проекте пруд пруди, прост до безобразия, делается стандартными средствами и не требует каких либо продвинутых умений, типа знания алгоритмов.
PS Это — вопрос: в этом комментарии я ничего не утверждаю, а лишь выражаю свое непонимание. И я с радостью прочитаю любые попытки ответить на эти вопросы.
По той же причине, по которой не выйдет задействовать недо-хирургов, прошедших курсы или недо-пилотов самолётов, посидевших за штурвалом.
Спрос на миддл-разработчиков, которые могут заниматься тем же самым CRUD, достаточно высок. Но он требует знания, например, паттернов, с которым у джунов плохо.
По той же причине, по которой не выйдет задействовать недо-хирургов, прошедших курсы или недо-пилотов самолётов, посидевших за штурвалом.
Практически во всем IT эта причина — ошибка опасна для жизни других людей — отсутствует. Так что на правильный ответ это не похоже. Ну и чисто мануальных навыков — которые важны и для хирургов, и для пилотов — для разработчиков не требуется: там достаточно только нажимать на кнопки, и не обязательно — в нужный момент.
Но он требует знания, например, паттернов, с которым у джунов плохо.Ну, джуну тут потребуется скорее знание стиля написания кода (AKA codestyle). Но даже и паттерны — это вещи вполне формальные, на выполнение которых вполне себе можно натаскать.
Так что, все равно непонятно.
Я вам больше скажу. Человек выше привел еще одну кривую аналогию, которая не имеет ничего общего с действительностью и даже искажает ее.
И пилоты и хирурги получаются из недо-, которых хотя бы попробовали сделать пилотами и хирургами, посадив в какой-то момент за штурвал и дав скальпель, под присмотром естественно.
Мое сообщение впрочем не отвечает на ваш вопрос, но возможно причина того, что ищут сразу опытных в том, что многим проще не возится с недо-, а сразу взять специалиста, пусть это будет и дороже.
Если свернуть немного в частности, то с разработчиками действительно скорее всего так, а вот с другими направлениями ИТ несколько проще и я знаю примеры организаций, где берут вчерашних студентов и даже на последних курсах, обучают за счет опытных сотрудников и оставляют наиболее успешных. Полагаю, что это выгодно, т.к. такая практика там многолетняя.
Полагаю, что это выгодно, т.к. такая практика там многолетняя.
конечно выгодно - но только если владелец бизнеса строит долгосрочные планы.
Основные выгоды - увеличение лояльности (текучка все равно происходит, но меньше + реклама "тут набирают студентов"), увеличение компетентности синьоров ("пока им рассказывал - сам уже понял"(с)), подержка инициативности (выросшие работники гораздо более активны, чем "готовые"), внедрение новых практик и фреймворков (а на ком еще, как не на студентах??)
Практически во всем IT эта причина — ошибка опасна для жизни других людей — отсутствует.
Да, но есть другая - ошибка в ПО может стоить бизнеса. Или просто очень больших денег. Так что тут всё плюс/минус корректно.
Так и в медицине так-то риски вполне себе оцениваются. И хуже того, пациентов обязаны с ними ознакомить, а значит и финальное решение принимают сами пациенты.
Так что мне сложно отстаивать точку зрения, которую я не разделяю, но которая, тем не менее, объективно является доминирующей. Так что я всего лишь ограничусь упоминанием о ней (в предыущих комментариях).
Дам совет на своем опыте начинающим, скорее даже самоучкам. Как с этим у дипломированных специалистов хз, я таких не встречал.
Не старайтесь применять паттерны, ООП и прочие модные слова, потому что так кто-то говорит.
Применяйте их по надобности.
Ну смотрите, минимум один факт.
Джун пишет код на 1000 строк за Nчасов, который местами некорректно, медленно (вставить нужное) работает. Синьор пишет функционально соответствующий код на 100 условных строк за N/10 часов, с которым все ок.
Вот и выходит, что джун крайне не выгоден на ближней и с редней дистанции. И куда выгоднее и дешевле нанять мастера, чем ораву джунов.
Типовые задачи - это миф. Задачи становятся типовыми только тогда, когда специалист достаточно высокого уровня организует рельсы для этой "типовости", по которым можно пустить вагоны с джунами.
Ну, а уж медленно и местами некорректно — это, жалуются, вообще болезнь нынешнего ПО.
Типовые задачи — это миф. Задачи становятся типовыми только тогда, когда специалист достаточно высокого уровня организует рельсы для этой «типовости», по которым можно пустить вагоны с джунами.
Вот это уже больше похоже на причину. То есть, вопрос можно даже переформулировать: почему специалисты высокого уровня не организуют эти самые «рельсы» в рамках своего проекта? Их этому не учили, или это объективно невозможно?
Если хотят организовать, то организовывают. Достигается это унификацией стека и внедрением проверок на всех уровнях - автотесты, мониторинг и прочее. Далее разработка становится проще и может быть выполнена менее квалифицированными разработчиками.
Также частично можно сократить сложность понимания бизнеса, например, составить словарь терминов.
Их этому не учили
Да, не учили. Потому что индустрия еще не понимает, как этому надо учить. Все получается только у случайно дошедших до такого умения.
Вот реально каждый второй коммит, и так уже два года.
Толку то, что рейт этих джунов в 5 раз меньше, если они на каждые 4 часа требуют моего одного часа?
+ еще простой команды из 15 человек пока я пойму, что они сделали не так в данный момент.
Вы скажите — тесты, dev environment. Ну так с тестами у них та же петрушка, и на деве они не находят ничего, а тестеров в бюджете — нету, мелкий бизнес.
Потому когда задача критическая — ее просто дают мне и через день оно работает без всяких проблем и косяков для бизнеса.
Вы скажите — тесты, dev environment
Нет, я скажу, что вы много джунам позволяете в плане доступа к ядру: по уму тут нужна защита от дурака в виде ограниченного набора вызвовов, которыми джунам дозволяется пользоваться, и которыми они ничего не смогут напортачить, а все остальные способы доступа запретить (технически или под страхом наказания).
Но это — однозначно, не для вашего мелкого бизнеса, делать такое ради пары джунов неоправдано. Разве что, взять готовую либу — но где они, такие либы?
Так что ваш случай по моей классификации идет, похоже, по категории незрелости: нет удобный средств разграничения доступа для разработчиков.
Потому, что код с рельсами писать вдвое дольше, а иногда и больше. И не факт что это окупиться. Часто причём большой проект вырастает из маленького, который может быть вообще писал миддл не совсем стандартно/оптимально.
Тут вопрос не столько про код с рельсами, а про создание артефактов в виде "вот тут проложить дорогу/рельсы/электрокабель в соответствии с <отсылка на кирпич документации>". После чего оно по цепочке разворачивается и в результате кабель прокладывает тот, кто никакого понятия, как устроена вся электросеть города/завода/дома, не имеет и не может иметь потому что никогда этого не учил и не захочет.
Вот почему-то в достаточно старых индустриях так делать (в достаточно многих вещах) научились, а в нашей индустрии -- как-то не очень.
1) Джун пишет код на 1000 строк за N часов, который местами некорректно, медленно (вставить нужное) работает. Ему надо платить 1000. Эффективность = 1000 / 1000 / N * 1 = 1 / N.
2) Синьор пишет функционально соответствующий код на 100 условных строк за N/10 часов, с которым все ок. Ему надо платить 10000. Эффективность = 10 000 / 100 / N * 10 = 1000 / N.
3) Синьор в тысячу раз эффективнее. Однако зарплата 700 или 850. Следовательно, синьора нанять в принципе невозможно, а джуна можно нанять с неполным рабочим днём, или можно доплачивать ему из зарплаты директора.
Предложенная вами модель хорошо работает, когда есть много денег. Однако она ломается, если имеется лишь «мало денег» или ещё меньше.
А супер синьор пишет код из 3 строк за полчаса и который работает в 10 раз быстрее. Просто он знает название библиотеки - "Сделать хорошо и быстро" и где ее найти. Патерны однако. :) Все чень просто.
В принципе можно. Писать тесты отправить, к примеру.
Но если смотреть именно о задачах программирования, то это всегда новая задача, не похожая при первом приближении на прошлые. Это сами по себе задачи которые не поддаются простой автоматизации, т.к. если поддаются, то эта автоматизация и есть задача.
Не для стажёров, настолько, что если это может сделать стажёр - значит это можно автоматизировать и заменить другим спецом(тестером, админом, манагером, техподдержкой и прочими).
С джунами получше, но они крайне неудобны. Там где мидлу надо поставить задачу в 10 слов, для джуна надо писать абзац или страницу, в которых он ещё и запутается, либо поддерживать и проверять по ходу, а лучше всё вместе. Получается, что задачу именно по разработке в нужном качестве джун не выполнит сам в большинстве случаев. Т.е. можно дать только те задачи, которые вполне автоматизируются, но на которые нет времени, или жалко его тратить. Ну или по принципу применения - дать обособленную вещь, которую в случае проблем проще переписать, чем править и следить в большей части за рамками работы. Но так не достичь высокой эффективности.
В соседней ветке был пример с DTO - это вообще мелочь по времени, больше возьни с объяснением что и для чего это и как этим правильно пользоваться, да и зачем. Для мидла это минуты, а для джуна - часы. Хотя тут и можно применить, только вот и это автоматизируется аж несколькими способами.
А когда натаскаешь он будет уже мидлом)
И ещё одна вещь - с сеньорами можно обсуждать программу свободно, не касаясь языка программирования вообще.
Связано ли это с недостаточной зрелостью индустрии, или же с особенностями производства ПО, не позволяющими выделять сколько-нибудь массово простые задачи, доступные специалистам прошедшим базовое обучение
На мой взгляд - именно так. Никого из нас не учат и индустрия не умеет целенаправленно получать людей, которые "прокладывают рельсы", как тут рядом пишут. Причина, мне кажется - как раз в том, что настоящей инженерной специальностью (со всем принятым для нее обучением) наша профессия не является. Мы тут все наполовину самоучки и ни томов документации (c миллионом наименований нужных деталей, сборок, конструкций или что там еще бывает), ни нужных практик, которые требуются, например, для строительства какой-нибудь электростанции или буровой платформы -- не знаем. Да у нас даже нормальных справочников "хочешь артефакт с такими-то параметрами - делай его из того-то" нет.
Я много читаю про нынешнюю индустрию IT, и одна вещь мне до сих пор кажется непонятной: почему индустрия не может задействовать специалистов, так сказать, низкого уровня — прошедших определенный курс обучения, умеющих делать простые задачи, но не ставших полноцеными специалистами высокго уровня?Может, просто предложение на порядки превышает спрос.
Как раз по причине зрелости индустрии все проблемы. Раньше более точная квалификация была не джун-миддл-серьор, а хеллоувордщик-быдлокодер-программист. Так вот быдлокодер этот тот, кто в целом может выполнить задачу, но неоптимально, его код трудно поддерживать и т.д. Когда проекты маленькие, быдлокодер может , сделав несколько задач, потом стать программистом. Когда проекты становятся большими, то быдлокодер не нужен индустрии, а нужен джун, то есть тот , кто может сделать узкую и типовую задачу , но относительно качественно . То есть быть подсобным рабочим.
Если проводить аналогии с медициной как это делают выше, нужна хорошая медсестра. А плохой врач , не нужен.
Их как минимум задействуют во всяких студиях в которых клепают шаблонные сайты или мобильные приложения. В этих аутсорс компаниях обычно продают джунов под видом миддлов или синьеров
почему индустрии IT обязательно требуются мастера, а не подмастерья?
...
тот же CRUD, которого почти на любом проекте пруд пруди, прост до
безобразия, делается стандартными средствами и не требует каких либо
продвинутых умений, типа знания алгоритмов.
Подмастерья будут хорошо работать при условии что у вас есть непрерывный поток задач для них и организация работы, позволяющая большую задачу постоянно декомпозировать до мелких и ранжировать их по требуемому опыту исполнителя. Собственно, так работают галеры и, возможно, крупняк типа гуглософта.
В "обычной" же лавке нет возможности джуну сидеть и ждать пока для него появится задача по силам. А когда появится, синьор не будет ждать пока джун будет пол-дня ковыряться с кругом, постоянно подбегая с вопросами. Он просто возьмёт +/- подходящий кусок кода с прошлого проекта и втиснет его в текущий.
Конечно, хорошо если в лавке есть процесс воспитания смены, я бы даже на это посмотрел... Но пока: сам, всё сам :)
То есть, если говорить в терминах цехового ремесленного производства, почему индустрии IT обязательно требуются мастера, а не подмастерья?
Не совсем уверен, что всегда "обязательно требуются мастера, а не подмастерья", но этому есть причины.
Порог вхождения больше. Научить забивать гвозди и не попадать молотком по пальцам можно за день, а программирование требует как минимум знания арифметики, булевой алгебры, устройства и принципов работы компьютера, знания лексики и семантики языка программирования (быть может, список даже неполный). Сначала "подмастерью" надо это всё понять, а только потом можно брать в руки редактор кода. Одна арифметика примерно год или два в школе изучается (благо, все с ней в итоге знакомы), а остальное, хотя и есть в курсе школьной информатики уже лет 15, чаще изучается менее ответственно, а ведь это всё за день не объяснишь. С другой стороны, если стоит задача научить сварщика сваривать любой сплав с любым другим сплавом, тут тоже всё сложно...
Другая причина - задачи, выполняемые "подмастерьями", легко автоматизируются. Пишутся фреймворки (тысячи их!), и в итоге решения типовых задач не требуется, т.к. для решения проблемы достаточно подключить фреймворк.
Не совсем уверен, что всегда «обязательно требуются мастера, а не подмастерья»Это — краткое описание нынешнего состояния рынка труда в IT, так сказать, объективная реальность, данная на в ощущениях.
Порог вхождения больше.Но и времени на его прохождение отводится больше: большинство вайтишников — они ведь после каких-то там курсов, не так ли? И они — взрослые люди, учить их можно куда большими темпами, чем младшеклассников — арифметике.
Другая причина — задачи, выполняемые «подмастерьями», легко автоматизируются.Тем не менее, задач таких все равно много. Тот же CRUD после автоматической генерации (если таковая предусмотрена) обычно требует, как минимум, «доработки напильником».
Пишутся фреймворки
Фреймворк — это не само решение, а средство для упрощения написания решений. И решение с помощью этого средства кто-то должен написать.
Фрейворки, идеале, должны убирать «под капот» все сложности реализации, так чтобы специально обученный фрейворку младший программист (он же — джун) мог писать на нем несложные куски приложений и даже несложные приложения. И я видел, как это может выгдлядеть на практике. Сейчас это уже давняя история, но я в ней тогда жил и ее видел целиком. Видел, как в Windows произошел переход от ужасов цикла обработки сообщений окна «по Петцольду»(это был автор чуть ли не единственной на тот момент книги по программированию в Windows) через фрейворки, все более упрощающие программирование: промежутоный вариант такого фреймворка — MFC для Visual Studio можно увидеть и сейчас. И, в конце концов появился Delphi с VCL, который сделал написание десктопных приложений доступным для новичков, зачастую и до уровня младшего программиста не доросших. При этом Delphi был вполне пригоден и для написания «серьезных» программ (я, к примеру успешо реализовывал на нем сервисы Windows).
Проблема в том, что современные фрейворки часто пишутся, по чьему-то меткому выражению, «Чужими для Хищников». Взять тот же ASP.NET Core: в более-менее пригодный для использования новичками вид, чтобы они могли писать прывычные императивные программы, а не таинственные заклинания, он был приведен только недавно, в версии 6.0. (и, кстати, посторонним лучше не знать, на каких костылях это держится). А до этого для простейшей задачи создания веб-приложения несчастному младшему программисту нужно было вызывать процедуры, помещающие некие вызовы(«ламбды»), в свою очередь помещающие некие процедуры (тоже «ламбды») в некие списки, откуда они неведомо когда должны быть вызваны, и/или писать методы некоего класса, которые тоже неведомо когда вызываются и которые проще только в том, что в нем сразу можно было писать те самые процедуры.
да заели вы со своим айти, в каждой дыре уже, айти айти айти, больше нет ничего что ли? да схлопнется это все через 2 года, как обычно, реально уже раздражает
Чтобы ИТ схлопнулось этому должны быть предпосылки. Например уход от цифровизации, уход от электронного документа оборота, уход от цифровых схем контроля, уменьшение количества гаджетов у людей, уход от использования компьютеров в работе учёных и так далее.
Пока нет ни одного намека на то, что что-то там в ИТ схлопнется.
10 лет читаю этот комментарий
Странно на ИТ-ресурсе жаловаться, что тут про ИТ. Не находите?
Ничего не увидел про конечную задачу, которую этот программист хочет решать. Язык программирования - это только инструмент. Мало кому нужен джун, который хорошо знает ЯП и фреймворки. У него ещё и мозги должны иметься. А это означает, что он должен быть специалистом в той области, для чего пишет ПО. И чем дальше, тем больше. От частного к общему. Овладевать инструментом, не имея задачи - бессмысленная трата времени. Именно поэтому у Коли столько проблем и выгорание.
Сегодня огромное заблуждение про программирование как про что-то простое и доступное, а это не так.
Я очень хотел программировать в 80-е и я это делал на Atari, в 90-е на 80286, Clipper, Fox Pro, Turbo C, потом Delphi и потом заметно позже (20 лет) на C#, и я понял только одно - мне не нравится быть механическим кодером и долбить код ради кода или автоматизации какой-то фигни. И да, я плохой кодер, потому что у меня плохая память, если я неделю не пишу на C# то я не могу прочитать собственный код. А нравится мне творческий процесс, поэтому я занимаюсь теперь простой административной работой, а для души пишу на ASM 6502 для Atari. Чтобы это понять - понадобилось 30 лет.
Коля молодец раз за три месяца прогнал через себя столько информации, я только вводную книгу по Питону читал 8 месяцев и понял что он мне не нужен, так как я уже пользуюсь C# которого мне хватает.
И он всё делал зачем? Ради денег? Чего я в жизни тоже понял - если ты устраиваешься на работу ради денег и не получаешь удовольствия от процесса, это будет адом и не важно сколько платят, так как депрессия гарантирована.
Большинство людей работают ради денег, а сама работа им не нравится. Удовольствие от процесса получают единицы. Мне кажется наивным предположение, что все должны обязательно найти "что-то своё", так не получится.
Да ничего, вроде последние года 4 справляюсь. Точнее как. Я поначалу это дело любил, потом возненавидел, потом перегорел. Сегодня программирую с нулевым интересом к процессу. Мне плевать что программировать, на чем программировать, и уж тем более плевать на то, меняю я мир или не меняю. Лучшая работа та, на которой надо меньше делать за больше денег.
И, внезапно, такой подхол к работе сделал меня куда более ценным сотрудником, чем я был. Теперь я смотрю на задачуэи по принципу: "как мне из А получить Б", а не "как классно, можно будет поковыряться во фреймворке Х, пока я делаю задачу". Я делаю задачи не так, как мне нравится, а так, как понравится тем, кто эти задачи будет принимать, чтобы потом больше не делать нечего. Я автоматизирую вещи, которые меня откровенно достали (а достает мне многое), а не те, которые весело автоматизировать.
Поставил Вам +1 в карму за 6502, но так и не понял, что в вводном курсе по питону изучать 8 месяцев. Зная некоторое количество других языков и купив нормальную книгу по питону (формальное описание, а не “Питон для чайников”, которое я выделил из других книг по наличию разделов с названиями вроде “Лексическая структура языка” в содержании), я смог писать на нём практически применимые программы через 3 дня ненапряжного чтения. Это вам не предындексная косвенная адресация с индексацией по X, в питоне всё проще.
Другое дело, что вообще кодирование в нашем возрасте уже обычно не очень торкает.
купив нормальную книгу по питону
Чем хуже официальный стандарт описывающий язык?
Обложки нет.
А так вообще стандарт не является учебным материалом.
Так вы же находитесь на таком уровне, когда и куча языков в бэкграунде и опыт как-никак, зачем вам какие-то разжёвывающие книжицы?
Это я вот к чему:
но так и не понял, что в вводном курсе по питону изучать 8 месяцев
Потому что неайтишник работает на основной работе, у него ещё есть жена, дети, ипотека, друзья, родственники, пожилые родители, а на изучение языка в качестве хобби остаётся хорошо если часик-другой в неделю.
Торкает! Возрастные изменения, как и интересы, индивидуальны.
Спасибо за карму, сразу скажу что мои познания в 6502 на уровне junior если не ниже, я наметил план повышения скилла и думаю что тут будут статьи об этом с блэкджеком и картинками. Поэтому отталкиваться от моего скилла для понимания моей крутости в целом не совсем правильно.
8 месяцев я читал книгу, чтобы в голове сформировалось общее представление о языке, синтаксисе, возможностях, как правильно написали ниже - читал я когда на это было время. И проблема в целом в том, что чтение этой книги ни капли не продвигает меня в возможностях программирования на питоне. Например после 10-ой страницы я вообще не помню что было на 1-ой и это не возрастное, я такой по жизни. Например сейчас когда пишу на C# я полагаюсь на подсказки IDE или сижу в MSDN, но написать что-то просто по памяти я не могу. Поэтому после прочтения я только понял что язык для меня неудобный во всём, а чтобы что-то на нём написать - это у меня должна быть конкретная задача и я бы ковырял, курил маны и опять ковырял, а потом наговнокодил.
Сам процесс кодирования меня никогда не интересовал, это скучно и очень долго, мне нравится гибкость инструмента, когда одна железка и один набор команд могут делать всё что угодно - игра, таблицы, музыка и т.п. Это как волшебная палочка. И чтобы само кодирование не утомляло слишком, я полюбил придумывать косвенные задачи - например написать функцию с минимумом переменных или с минимальным потреблением памяти и что интересно, одна и та же задача решается разными способами. Когда решение найдено я не всегда даже код дописываю, как я говорил выше - это скучно, но иногда довожу до конца если увидеть результат тоже интересно, или это практическая утилита, которая для меня что-то делает. Например при кодировании LZ мне нужны были генерируемые файлы разного размера и содержимого, написал программу, пользуюсь регулярно и для других задач.
У меня есть лазерный гравёр, управляется через COM порт, перехватил с порта наборы команд и потом на питоне написал свой контроллер гравёра, так как из подручных языков он оказался самым простым для работы с COM портом, там буквально пару строк. Но для этого мне учить питон не потребовалось, просто погуглил синтаксис и всё. Утилитарное применение.
А не понравился в основном тем что половина хороших библиотек под 2 версию и половина под 3, писать своё нет ни желания ни времени, и нет нормального GUI для софта, а мне нужно часто что-то рисовать на канвасе. На C# всё очень просто, много примеров, хорошо всё гуглится.
Надеюсь несколько разъяснил по поднятым вопросам.
А почему научиться рисовать так сложно? А почему научиться строгать так сложно? А почему научиться быстро бегать так сложно? А потому что, у кого-то это получается легко и просто и есть возможность и расположенность, а у кого-то нет? Посадите меня рисовать с циркулем и линейкой и дайте 10 лучших наставников, но не выйдет Айвазовский. Может не надо заниматься ремеслом, к которому не лежит душа?
Это прям про меня, спасибо за статью! Я за полгода изучения пайтона на супер разрекламированных курсах дошел до скалы растерянности. Понял, что все "слишком сложно" и надо "опустить планку". Начал копать фронтенд самостоятельно. За год дошел до пустыни отчаяния, причем даже получил стажерскую позицию в одной компании, промучившись месяц с первым заданием, бросил, так как срок "вхождения в it" в целом , уже пугал. Теперь изучаю тестирование, очень жаль потраченного времени, но, надеюсь, знания пригодятся в автоматизации.
Ну если вы год продержались, значит у вас безусловно есть определённые способности к программированию.
Создайте какой-то проект для себя, так видно будет. Может вам не фронтенд нужен, а бекэнд, а может desktop. Или разработка мобильных приложений. На самом деле не так много надо времени , чтобы по каждому направлению что-то наваять, уж точно не год.
Очень много букв и цветных рисунков для пояснения обычной S-образной кривой применительно к процессу обучения.
1) какая еще S-образная кривая??
там показана только первая волна неуверенности в море изучения и практики языков программирования.
Таких S-образных кривых : выходит новая версия фреймворка, новая ОС, новый язык программрования, новое устройство (или вы думали что андроид и айфон - были всегда?), новая процессорная архитектура - тут просто на каждом углу.
2) лично меня в той кривой больше всего смешит что этап "работать в команде" стоит до "готов к работе". ИМХО если человек работает в команде и приносит своей работой пользу этой команде - то он уже готов к работе.
Ну правильно, S-образные кривые сопрягаются между собой. Хотя вообще по поводу перечисленных вами событий особых заморочек у опытного специалиста уже не возникает.
Не могу себе представить, чтобы квалифицированный программист испытал “пустыню отчаяния” по случаю появления нового фреймворка или процессорной архитектуры.
По поводу работы в команде. Если процесс сложный, то сотрудник некоторое время работает в команде, не принося ей пользы. Больше ресурсов тратится на его обучение, чем приобретается в итоге его труда.
А я считаю что это сложно потому что нет нормальных туториалов и курсов. Все они построены по одной схеме, знаете, мем такой ещё есть:
2+2=4, понятно?
понятно!
ну тогда f(x)=sqrt(sin*4/9)… и дальше зубодробительная формула.
То есть все объясняют что такое if, что такое else, несколько уроков выделены под for, ещё несколько — под while. А менеджеру пакетов — дай бог половина урока. А такие насущные вопросы как делать стейт менеджмент, как сделать нормальную асинхронную очередь — вообще никто не говорит. Не, серьёзно, если знаете — скажите, плиз.
Личный пример — я вот решил выучить scala и написать на ней консольный загрузчик музыки из вк. И что, открываю я курсы, там уруру, утю-тю, val var и вот такая хрень. Я начинаю делать, понимаю что мне чего-то нехватает, лезу читать, оказывается надо брать akka, а там вообще нет этих ваших if then else var val, там блин акторы какие-то и прочая хрень, про которую я уже нормальных курсов не нашел.
Или вот я решил вместо autohotkey сделать себе скрипты на питоне чтобы в майнкрафте не жать все время вперед и копать — нажал клавишу, он сам копает. Внутри я себе это представлял как словарь с горячими клавишами, где значение это функция которая стартует/останавливает тред. и таких тредов много.
в итоге у меня до сих пор говнокод типа
def onStop():
global Autokill, AutokillThread, Autotorch, AutotorchThread
print("onStop")
Autokill = False
Autotorch = False
keyboard.release('w')
if (AutotorchThread):
AutotorchThread.terminate()потому что я не осилил сделать dictionary с потоками
Так блин, даже до такой "средней" технологии типа "давайте сделаем менеджер потоков" курсы не доходят.
В общем эти ваши впадины отчаяния вызваны тем, что обеспечивается шикарная поддержка начальных навыков логики типа "если Х, то У", а вот уже не начальные, но всё равно базовые навыки почему-то нигде не объясняются.
ну, это уже не совсем "базовые вещи", но акторы, или потоки, или машина состояний - это можно изучать в вашем основном языке программирования - не нужно залазить в скалу или питон.
Учебники. Как следует из их названия, они придуманы, чтобы учить. Обычно, они качественно и систематизировано дают исчерпывающий материал по некоторой теме. В большинстве случаев старательное изучение учебника по одному только языку даёт достаточно глубокое понимание базовых концепций, чтобы на их основе разобраться со всем остальным. Но так же есть учебники по структурам данных, алгоритмам, шаблонам проектирования, конкурентности и прочему, после которых не может быть ни малейших проблем с реализацией асинхронной очереди и конечного автомата. Менеджеры пакетов и тому подобное - это темы на столько примитивные, что по ним всегда достаточно документации.
P.S. Не нужна akka для написания консольного загрузчика музыки из VK.
low-code/no-code вытеснит всех джунов.
не всех джунов, а джунов программирования
на их место придут джуны low-code/no-code , из которых будут вырастать синьоры low-code/no-code !
(а еще раньше были джуны машинных кодов, потом были джуны ассемблеров)
Я 25 лет назад также слышал, что Delphi вытеснит нормальных программистов, будут все формочки клепать.
Кстати
Вроде ещё Хайнлайн об этом писал.
Оффтоп:
На самом деле результатов не 3M+, а максимум 300, и то в конце нерелевантный мусор
Как раз встал на этот путь, поэтому интересно было почитать статью. Надеюсь не застряну на скале и не останусь в пустыне :)
True story, bro.
Статья заявлена как перевод, но это какой-то странный перевод. С "адаптацией к местным рыночным условиям", видимо.
Оригинал:
On the other, the "Learn to Code" movement has done a fantastic job of breaking down barriers and showing people that code is actually quite harmless. Tools like Codecademy and Treehouse reach out with the gentlest of touches to assure you that you too (nay, anyone!) can not just learn to code but become a full-fledged developer as well.
Перевод:
С другой стороны движение «Войти в АйТи» проделало фантастическую работу, разрушая барьеры и показывая людям, что код на самом деле совершенно нестрашен. Такие курсы как Яндекс.Практикум и Skillbox самым нежным прикосновением убеждают тебя, что ты тоже (кто угодно!) сможешь не только научиться программировать, но и стать полноценным разработчиком.
Именно! Я тоже офигел. Это пересказ, а не перевод. (В лучшем случае; а в худшем — это намеренный продакт-плейсмент.)
движение «Войти в АйТи» — the "Learn to Code" movement
такие курсы как Яндекс.Практикум (!) и Skillbox (!) — tools like Codecademy and Treehouse
поищи «Научиться программировать» — search for "Learn to Code"
каждое посещение Google или Хабр — every trip to Google or Hacker News
возможно, ты запишешься на пару МООК курсов от Яндекс.Практикума (!), Степика или Скиллбокса (!) — maybe you sign up for a couple MOOC courses from Coursera or Udacity or edX
(По-моему, одна из полезных сторон подобных статей состоит в том, что человек может по хожу узнать, какие ещё есть полезные ресурсы — а тут его намеренно загоняют в пузырь Яндекс.Практикума и Скиллбокса.)
P.S.: А на десерт, персонаж Quincy Larson (который в переводе стал Колей) — это, судя по всему, не просто абстрактный имярек, но и ещё отсылка к конкретному человеку — основателю freeCodeCamp.org (по крайней мере в оригинале фраза о том, что Квинси Ларсон получил работу в разработке, является гиперссылкой на статью именно того Квинси Ларсона, где он в том числе вспоминает, как впервые получил должность разработчика).
Это та самая безалаберность и всеобщая условность, из-за которой на плакате к 9 Мая, не заморачиваясь, лепят фотки тогдашних условных противников, и про которую так яростно говорил капитан (Виталий Хаев) в фильме «Изображая жертву».
Этот график "уверенность-компетенция" назойливо переползает из одной тренировочной статьи в другую, причём в разительно отличных друг от друга предметных областях. И складывается ложное впечатление, что он правдивый хотя бы из-за того факта, что, благодаря прогрессу, необходимые компетенции бесконечно растут, и, фактически, крестик "готов к работе" не стоит на месте. Более того, люди, осуществившие революционные инновации, включая редкие выстрелившие стартапы в ПО, очевидно обладали 100% уверенностью вне зависимости от компетенции - "все знали что так нельзя, а они не знали и получилось".
Программистов я не учил, я по тестировщикам. Но ключевые принципы одни.
Проблема курсов ВООБЩЕ как раз в том, что они делают только первый этап (заботливый медовый месяц, или как вы там придумали), затем говорят «муахаха!», пинают под зад и оставляют в одиночестве преодолевать все дальнейшие падения и взлёты. Да, в Спарте всех слабых младенцев сбрасывали со скалы, это делало их смелыми и сильными. Но мы не в Спарте.
Ученика надо провести по всем этим холмам и долинам уже в контексте курса. Надо дать ему ощутить себя сильным (заботливый медовый месяц, my ass), не мешать ему испугаться дальнейшего, быть рядом, когда он начнёт хныкать или реветь, помочь подняться и шагать вместе с ним дальше, пока он не начнёт идти самостоятельно и без страха.
Учить этому не очень-то и легко, но можно и нужно. И под «учить» подразумевается не рассказ о том, что есть, например, всякие техники тест-дизайна, но это вы сами когда-то сможете узнать, «если на проекте понадобится»… Надо учить думать и не бояться неизвестного, а не техникам тест-дизайна отдельно или как писать репорт о дефекте отдельно. Человек даже в среднем не дурак, сам придумает, как репорт написать, если сперва будет понимать, что это и зачем это нужно.
Минус в том, что мозг начинает перестраиваться только через три месяца токсичного принуждения занятий, и надо как-то умудриться не потерять ученика за это время. Некоторые таки теряются.
сложно или не сложно - сильно зависит от источника знаний, имхо. В школьные годы увлекался паянием электорнных поделок по схемам в "Юном Технике" (светлая ему память!), и всё ждал, когда смогу подложить теорию под практику, и понять - почему мультивибратор так работает и как придумать схемы самому. Как же меня взбесило, когда я понял, что фраза из учебника по физике "транзистор усиливает сигнал" не верна по сути! Усилие - это когда я, откручивая ржавую гайку, наваливаюсь на гаечный ключ всем телом. А транзистор не усиливает, а повторяет сигнал с большей амплитудой!!! и только в таком варианте становится понятен принцип работы. или я один такой придирчивый? )))
Но ведь повторение с большей амплитудой — это же и есть усиление...
Проблема с этой фразой — в другом. Сигнал — это вообще не физическая величина, в электроцепи нет никаких сигналов, а есть токи и напряжения. Одна из этих величин на наш выбор может стать носителем сигнала, но транзистор про этот выбор не знает, и работает по своим законам.
Ну почему усиление считать только механически? Тем более и в механике усилие и усиление две разных вещи. Усиление, это когда с помощью рычага человек может поднять груз в тонну и больше.
Меня лично усиление сигнала всегда ломало мозг, ведь у нас есть закон сохранения энергии. Раз в замкнутой (!) цепи сигнал усилился, значит где-то он должен был взять энергию, но где?
В таком случае на источнике энергии должен формироваться такой же сигнал, но инвертированный по фазе, но этого не происходит
Но вообще да, на блоке питания будет картина зависящая от сигнала и в некоторых схемах типа военных ставятся два БП и дополнительные конденсаторы-соленоиды чтоб убрать зависимость, которую кто-то может считать.
Вообще-то, ещё как происходит, и на этом даже основано направление атак на аппаратные криптотокены.
так ведь сигнал - это же абстракция, сигналом может быть может быть 1)ток 2)напряжение 3)частота 4) что-то еще
Это не так чтобы корректное объяснение.
У нас есть носитель сигнала (ток, напряжение), у которого есть характеристики (амплитуда, фаза, частота). Изменяя характеристики мы сигнал кодируем. Соответственно изменяя одну из характеристик, мы меняем и регистрируемый на другом конце сигнал.
Проблема в том, что изменение чего либо в цепи требует энергии. Но тут сразу прикол в том, что получается эту энергию надо откуда-то взять. Но чесслово из схемы транзистора не очень понятно откуда эта энергия берётся)
Совершенно верно. Я хотел подчеркнуть, что напряжение на входе и на выходе транзистора имеют разные источники, а термин усиление подразумевает действие над одним и тем же обьектом
К примеру, когда вы механически станком усиливаете управляющее воздействия от рук — источник — двигатель станка.
Нет, не совсем так. Руки и станок разные обьекты. Вы же не можете сверлить, точить или фрезеровать рукой. А обьяснение в учебнике говорило об усилении транзистором сигнала - одного и того же обьекта.получалось, как если бы река втекая под мост, была шириной допустим 5 метров а вытекала из-под моста уже 50 метров.
Усилитель — устройство для увеличения энергетических параметров сигнала с использованием энергии вспомогательного источника(питания)
В случае с копировальным станком или экзоскелетом это все тот же усилитель, почему нет. Вот если станок будет работать без начального сигнала или экзоскелет будет по программе работать(роботом), тогда уже будет НЕ усилитель.
А так токарный станок — классический усилитель. Ну и что, что сигнал с поступательного на руке переходит во вращательный, это просто «взаимно-однозначное отображение пространства».
Вот конь, к примеру, усилителем НЕ является. Поскольку сам своим мозгом решает, куда вообще ноги ставить и идти ли туда, куда вы направили. А обычный блок веревочный — является, с коэфициентом усиления 1 и коэфициентом преобразования от единицы.
программирование можно сравнить с проектированием полностью роботизированных заводов, мелкие программы - мелкие примитивные механизмы, большие - куча взаимосвязанных станков. Станки можно брать готовые, а можно проектировать самому. Да и даже в готовых иногда приходится ковыряться, что-то исправлять, разбираться как работают
Я поэтому , разрабатывая курс в самом конце сделал мини проект, чтобы человек так сказать прочувствовал.
А вообще падение "плотности информации" есть на любом уровне. Помню как-то надо было сделать ONVIF сервер. До этого не был знаком даже с SOAP. Первый вариант был реализовать на Delphi , в котором как казалось опыта достаточно. По итогу оказалось там есть достаточно мощные штуки вроде кодогенераторов, но в целом клиент можно было реализовать и неплохой, а сервер было не реализовать никак. По крайней мере в версиях до XE7, возможно сейчас они что-то улучшили, но на 99% нет. Возможно кто-то в мире и реализовал таки на Delphi и причём без обращения на совсем уж низкий уровень, но я об этом не знаю.
В то же время на gsoap конечно же всё получилось. Потому, что как раз по "плотности информации" это решение наилучшее.
Почему программирование путают с кодированием? Для программирования надо знать высшую математику, алгоритмику, основы дискретной математики, принципы построения ОС, основы и принципы работы сети и многое другое... Язык программирования - вторичен. А для кодирования первично и важно только язык программирования.
Сразу возникает два вопроса:
Неужели Вы не встречали довольно успешных программистов, которые не знают толком высшую математику, алгоритмику, принципы построения ОС и т.п. вещи?
Что Вы можете "закодировать", не зная "программирования"?
По-моему, это довольно формальное разделение и противопоставление. На самом деле, программирование очень часто оказывается довольно рутинным предприятием, но для этого существуют более глубокие причины. Во-первых, когда нужно решать задачу, её решают неким типовым методом и при помощи типового и программного обеспечения. Во вторых, в программистской рутине нет места для теоретических изысканий. Практика — отдельно, а наука — отдельно. (Даже на "Хабре" аналитических статей стало существенно меньше чем было раньше. По моим ощущениям, разумеется.) В-третьих, программисты сами превращают любимое программирование, в пресловутое "кодирование", потому как во главу угла ставится решение конкретной спущенной сверху задачи, а не творческое и увлекательное решение практической проблемы. Ведь, это это очень удивительно, что толпы программистов каждый день решают одни и те же задачи, которые, по идее, должны были быть решены уже -дцать лет назад. Вот и приходится кодировать, то есть использовать некий набор инструментов (построенных вокруг конкретного языка программирования). Хотя... было бы гораздо интереснее, например, написать один раз универсальный движок для всех торговых площадок и построить единую инфраструктуру для ведения торговли.
Ну вот просто они «не знали толком» основы БД. А так сильные были, сами написали систему работающую на уровне области(30+ предприятий).
Вас ждёт успех - если вы "фанат" программирования. И не будет никаких "далин". Будут только интрересные новыя открытия.
Как стать "фанатом"? ) Прежде всего найти специализацию своей мечты - AI, сайты (фронт или бэк), мобильные игры или приложения, Internet of Things, либо какая-нибудь крутая сфера, которая вас вдохновляет...
Если вы не "фанат", тогда будут "пустыни отчаяния" и тому подобное. В итоге максимум станете этаким трудоголиком с ограниченным креативом и ограниченным профессиональным развитием.
При изучении любого предмета всегда есть такой момент, когда Вы узнаёте что-то очень важное и существенным образом продвигаетесь в своём развитии. Знать бы это заранее. Можно было бы наломать меньше дров. Но, может быть, очень важно наломать дрова:
И опыт — сын ошибок трудных.
С другой стороны, вполне возможно, что без некоторых вещей можно было бы обойтись. Вот, Вы, специалисты, могли бы придумать более прямой и короткий путь познания Вашей специальности, чем тот извилистый путь, который был у Вас самих?
Тезискно:
в целом в обществе статус образования в целом просел относитеьно советского. Если в советское время обраование было делом статусным и реально открывало социальные лифты куда угодно, то в настоящих условиях образование никому ничего не гарантирует. Горизонтальной карьеры нет. Вертикальная ограничена. Частные собственники отбирают кадры не по компетенции в первую очередь, а по иным соображениям - непотизм, клиентелла, взятки (лично мне предлагали купить место в таможне) все как в Древнем Рима
в связи с этим падает и культура обучения. Школьник не может поднять свой статус в коллективе учебой, в резульате имеем эффект, что выпускники не имеют даже достаточного НАВЫКА ЧТЕНИЯ УЧЕБНОЙ ЛИТЕРАТУРЫ.
ЕГЭ открыла дорогу в ВУЗы для откровенно слабо подготовленных абитуриентов. Почему все регионы молятся на ЕГЭ? Именно потому, что с уровнем задрищенской средней школы в МГУ по релаьному конкурсу знаний в жизнь не попасть, а по баллам ЕГЭ - вполне можно. Отсекая личные усилия по подготовке к экзаменам в ВУЗ, отсекли и выработку навыка самообразования.
в обществе в целом в области духовной культуры господствует попса, то есть, воинствующий антиинтеллектуализм. Какой-нибудь очередной моргенштерн несет агрессивную глупую матерщину - и это считается нормальным. Критерием успеха является только куча бабла, и мы видим, что эта куча бабла оседает не в карманах самых умных, а в карманах самых пройдошливых. В таких условиях интеллектуал всегда в загоне, и не имеет авторитета, чтобы ему стали бы подражать.
Как итоговый результат мы имеем уже вполне свормировавшийся социум, где в основной массе люди НЕ УМЕЮТ УЧИТЬСЯ и не имеют общих знаний для базы.
логично, что трудно научить чему-либо того, кто учиться не умеет.
Боже мой, в 90-х не было никакого "загуглить", с которым, оказывется, сейчас испытывают сложности выпускники курсов. Брали хелпик по языку, брали книгу по теории - и вперед, решаем задачу. Не получается решать - идем в библиотеку и ищем еще книгу. Максимум читерства - это взять код друга, и, прочитав его, постараться понять, как можно повторить некоторые элементы алгоритма и какими методами.
Тут на днях спросили - а как я учился программировать? Да хрен его знает, как. Что-то читал. что-то гуглил, где-то что-то просмотрел. Да, не три месяца, а несколько лет тут-там хватал тчо где, решал задачи. Если бы были курсы, то сегодняшний уровень я бы имел за три-четыре месяца, потому что база раньше бы сформировалась, и на учебных задачах больше бы алгоритмов и методов обкатал. Но тут важно даже то, что я не заметил. как чему-то научился. И это абсолютно нормально. Потому что обучение - это НЕОТРЫВНЫЙ ОТ ЖИЗНИ ПРОЦЕСС. Нельзя сказать, что тут я учусь, а тут не учусь, потому что учеба идет постоянно.
Но у других по- другому Все чаще и чаще сталкиваюсь не с тем, что область знаний какая-то сложная, а скорее с тем, что люди - необучаемые обезьяны. Сколько книг желающим научиться программировать скидывал - ни один не прочитал. Зато потом от них вопросы: "а какие курсы лучше"? Самый лучший курс - самообразование.
Про поиск себя и пробовать что-то в процессе прям в точку, после универа устроился на фулстака с обучением(с********е курсы skillbox, выложенные на личном облаке руководителя, 2 курса python и html), через полгода понял что такое не совсем моё - вроде у тебя есть задача, вроде с командой декомпозировали ее и разобрали мелкие задачи, но усе равно нет какой-то что-ли конкретики, что зачем и для чего мы делаем, жа и с командой отношения не сложились. В итоге уволился перед НГ, потом по знакомству начал изучать саповский ABAP и понял-вот оно, моё! Никаких тебе библиотек и различных модулей, просто пишешь код и всё, при этом понимаешь что, где, как и для чего используется, а потом стартанули февральские события и не было уверенности, что абаперы еще будут нужны, хотелось свалить учить 1с, но упорство взяло своё и уже 2 месяца я абапер. Да, немного, зато интересно. Да и трофейное ПО надо кому-то поддерживать)
Прочитал статью, IMHO там не отражено ключевое - чтобы стать хорошим программистом, надо быть программистом в душе изначально.
Уметь аналитически сформулировать комплекс правил, связанных с решением поставленной задачи, потом разложить эту задачу на элементарные действия, "кирпичики", каждый из которых будет действовать в рамках правил. А для программистов, работающих в команде - еще и принять правила, сформулированные другими участниками, и оформить решение задачи по принятому стандарту.
Это реально дано не каждому - от уровня "Хочу получить оптимальный график отгрузки в магазины с центрального склада", спуститься на уровень "сложить А с С и проверить, не больше ли оно, чем Р".
А так, действительно, меняем в статье "программист" на "столяр" и ничего принципиально не изменится. :)
Почитал комменты и стало страшно вкатываться) Я подумал про айти, когда на собесе одном с меня пытались хотя бы циклы и типы данных вытянуть. Я же только на ассемблере смог их задачки порешать. Заманили туда озвучив зп со словами "нам бы хоть кого то заткнуть дыру". Начал после этого заниматься и понял, что испытываю кайф от того, что могу, как ни странно, "пощупать" результат своей работы - вот ты прочел задачу, накидал алгоритм в голове, а вот он уже реализован и крутится. На текущей работе с этим сложнее. Но комменты "нам тут не нужно, вас и так дофига, мест нет" очень пугают)
Я новичок во всём, но и статью и комментарии считаю очень полезными. Спасибо всем.
Показательно, что автор много рассуждает о выборе и постижении инструментария, и крайне мало - о принципах построения программ. Это, на мой взгляд, и есть самая большая проблема современного изучения программирования. Базы данных без представления о реляционной алгебре. Веб-приложения без знаний 2х и 3х звенной архитектуры. Общий смысл: выучи язык, разберись с библиотеками поддержки, и ты - программист! Таки-нет. Ты в этом случае максимум кодировщик, да и то не всегда.
Интересная трактовка эффекта Даннинга-Крюгера. Только в такой интерпретации он будет иметь фрактальный характер. Потому что вот эта стадия "готов к работе" - это по факту новый "пик глупости". Потому что человеку, который активно изучает программирование 3 года и уже даже работает программистом обманчиво кажется, что он всё понимает. А по факту он эдакий дилетант под прикрытием :)
Почему изучать программирование так сложно?