Что необходимо знать каждому новичку о предстоящем пути

Коля был простым «белым воротничком» в офисе и решил, что хочет научиться программировать, поэтому он поспрашивал вокруг с чего начать. Он начал с изучения Ruby, а затем пробежался по другим языкам, таким как Scala, Clojure и Go. Он изучал Emacs, затем Vim и даже раскладку клавиатуры Дворака. Он брался за Linux, баловался Lisp и кодировал на Python, живя в командной строке более полугода.

Советы, которые получал Коля, дёргали его сначала в одну сторону, потом в другую, и так далее, как лист в торнадо, пока он, наконец, не прошёл «каждый мыслимый и немыслимый онлайн-курс». В конце концов, несмотря на то, что в итоге он получил работу в разработке, Коля:

…был убеждён, что, казалось бы, нормальные программисты, на которых я натыкался, на самом деле были социопатами, которые испытали, а затем подавляли травму обучения программированию.

Ой. Звучит знакомо?

Этап I. Заботливый Медовый месяц

Действительно трудно кого-то обвинять в том, что он пришёл в программирование с завышенными ожиданиями.

С одной стороны, ты с детства слышал слухи о том, как сложно программировать, как сказки старых дев, предназначенные запугать детей, заставив их изучать социальные науки.

С другой стороны движение «Войти в АйТи» проделало фантастическую работу, разрушая барьеры и показывая людям, что код на самом деле совершенно нестрашен. Такие курсы как Яндекс.Практикум и Skillbox самым нежным прикосновением убеждают тебя, что ты тоже (кто угодно!) сможешь не только научиться программировать, но и стать полноценным разработчиком.

Внезапно проблемой стал не страх, а переизбыток надежд и завышенных ожиданий.

И, по большей части, эти вводные курсы отлично справляются со своей задачей, проводя тебя, как ребёнка, по пешеходному переходу мимо больших страшных переменных, условных операторов и ранние этапы освоения синтаксиса программирования. По мере того, как ты преодолеваешь одну за другой их геймифицированные задачки, твоя уверенность растёт. Возможно тебе это по силам! Что тут сложного? Да ты же уже практически разработчик!

Растущая уверенность в Заботливый Медовый месяц
Растущая уверенность в Заботливый Медовый месяц

Но вот в чём проблема — ты в том, что я называю этапом «Заботливый Медовый месяц». Хотя тебе может казаться, что конец уже за поворотом, ты всего лишь на небольшом участке пути туда. Это всего лишь начало…

Намечая путь к цели

Прежде чем мы погрузимся в Этап II, давай взглянем на более широкую картину.

В этой главе я проведу тебя через четыре этапа типичного пути в программирование и расскажу, что тебе нужно сделать, чтобы пережить каждый из них. Ты также увидишь, как два ключевых фактора — плотность источников и сфера необходимых знаний — определяют этот путь.

Путь к готовности к работе можно описать с точки зрения того, как меняется твой уровень уверенности в себе по мере увеличения твоих способностей:

Уверенность в программировании против Способностей
Уверенность в программировании против Способностей

Это взаимосвязанные вещи, потому что твоя уверенность тесно связана с удачей, а тот момент, когда твоя уверенность и способности совпадают, является лучшим показателем той приятной точки, когда ты официально «готов к работе».

Мы рассмотрим особенности оставшихся трёх этапов, вот что они содержат вкратце:

  1. Заботливый Медовый месяц — это весёлая возня с тщательно отполированными источниками, обучающая тебя вещам, которые кажутся сложными, но вполне выполнимыми из-за их интенсивной поддержки. В первую очередь ты изучишь базовый синтаксис, но будешь доволен своими достижениями.

  2. Скала Растерянности — это болезненное осознание того, что становится намного тяжелее, когда забота заканчивается, и кажется, что ты ещё ничего не можешь сделать самостоятельно. Твои основные проблемы — это постоянная отладка и смутное понимание, как задавать правильные вопросы, пробиваясь через очередную проблему.

  3. Пустыня Отчаяния — это долгое одинокое путешествие по бездорожью, где каждое новое направление кажется правильным, но ты часто ходишь по кругу и не хватает сил, чтобы пройти через него. Остерегайся «Миражей Соблазнов», подобных коварным соблазнительницам пустыни, которые сбивают тебя с толку.

  4. Взлёт Напуганного — это когда ты, наконец, нашёл путь через пустыню и собрал воедино понимание того, как создавать приложения. Но твой код по-прежнему разрознен и хрупок как карточный домик. Ты обретаешь уверенность, потому что кажется, что твои сайты работают, ты освоил несколько полезных паттернов, а твои друзья считают твои интерфейсы крутыми, но ты боишься заглянуть под капот и совершенно не знаешь как достичь «готового к использованию в работе» кода. Как преодолеть разрыв, отделяющий от реальной работы?

Я взял интервью у сотен начинающих разработчиков за последние несколько лет, снова и снова слыша отголоски одной и той же истории. Моя цель в этом посте состоит в том, чтобы ты подошёл к пути ученика с открытыми глазами и чётким планом, чтобы обойти грабли, на которые наступали те, кто был до тебя.

Давай вернёмся к Этапу II…

Этап II: Скала Растерянности

Итак, ты находишься на Этапе I — «Заботливый Медовый месяц» — смотря на свои достижения и выполняя задачки по программированию в то время как твоя уверенность и способности растут. Это не так уж плохо… в чём вообще проблема? Ты прибыл на «Вершину Неразумного Изобилия»…

Осторожнее! Ты вот-вот перешагнёшь в пропасть, разбившую много очень амбициозных учеников и отправила их в лагерь «программирование — это слишком сложно». Именно в тот момент, когда происходит этот скачок, ты впервые садишься за клавиатуру, открываешь текстовый редактор и пытаешься создать проект с нуля без каких-либо модных браузерных редакторов, шаблонов кода или полезных подсказок.

Ни фига.

Ты можешь немного растянуть этот этап, следуя инструкциям, но никто никогда не достигал неба, не покидая земли, и в какой-то момент тебе придётся создавать магию из пустого текстового файла. Ты только что перешёл на второй этап обучения, когда уверенность рушится об землю — «Скала Растерянности»:

Теряющаяся уверенность на Скале Растерянности
Теряющаяся уверенность на Скале Растерянности

Итак, ты программируешь. Ты отвоёвываешь и выцарапываешь дорогу к едва рабочему решению, но чего-то не хватает. Ты оказываешься на войне с такими багами (от англ. «жуками»), на фоне которых Звёздный Десант выглядит безобидным. Кажется, что каждая победа была достигнута лишь благодаря удачному гуглению, а твоя уверенность в том, что ты вообще когда-то разберёшься в этом резко падает.

Бааааааааг!
Бааааааааг!

Это особенно разочаровывающий этап для обучающих и всех участников нашей отрасли. Программирование может не подходить идеально всем, но мы хотим, чтобы ты добился успеха, потому что иногда самые безнадёжные случаи вырастают в величайшие успехи.

Когда учеников перестают водить за ручку и сталкивают со скалы с криком «лети», слишком много ранее отлично смотревшихся людей падают по спирали на камни разочарования, так и не научившись махать крыльями.

Ужас в том, что ты даже не добрался до основной части. Второй этап, Скала Растерянности, только начинается. Лишь только после того, как ты, наконец, устранил достаточно багов, чтобы положить конец восьмой казни в Египте, и реально завершил пару проектов — тем самым отметив конец Этапу II — ты всё ещё начинаешь.

Для тех, кто после этого действительно готов строить карьеру, выживание на Скале Растерянности часто является моментом, когда ты решаешь пойти ва-банк в своей новой жизни. Но слишком многие остались позади. И, к сожалению, ты только входишь в «Пустыню Отчаяния».

Два ключевых фактора

Так что же на самом деле отличает один этап от другого? Почему Этап II (Скала Растерянности) была такой ужасной по сравнению с Этапом I (Заботливый Медовый месяц)? Понимание этого поможет тебе осознать, что это вообще не твоя вина, что твой путь выглядит как мы только что описали.

По сути, на каждом этапе действуют две ключевые силы — Плотность Источников и Сфера Знаний. Давай разберёмся, что это перед тем как смотреть как они определяют Этап III.

Фактор 1. Плотность Источников

Как я сказал выше, когда ты только начинаешь, кажется, что есть миллион источников, пытающихся взять тебя за руку и тащить в программирование. Потому что так и есть!

Поищи «Научиться программировать» и обнаружишь вал полезных и годных инструментов, текстов, видео и учебных пособий. И, честно говоря, они великолепны! Никогда прежде не было так много способов начать обучение программированию.

К сожалению, на более поздних этапах плотность источников быстро падает. Любой, кто переходил от новичка к среднему уровню может подтвердить, что существует БОЛЬШАЯ разница между количеством доступных источников когда только начинаешь и когда впервые ищешь помощь в создании чего-то самостоятельно без особой поддержки за руку.

Эта проблема усугубляется по мере того, как количество знаний быстро увеличивается в переходе на Этап III, и это одна из причин, по которой мы называем этот этап «Пустыней Отчаяния». Как только ты преодолеешь это и начнёшь привыкать к тому, что именно нужно искать, источники вернутся и ты сможешь работать с более техничными инструментами, такими как отраслевые блоги и видео. Частью этого является просто понимание, какие вопросы задавать.

Вот как выглядит Плотность Источников на каждом этапе (большая плотность линий указывает на большее количество источников):

Плотность Источников на каждом Этапе
Плотность Источников на каждом Этапе

Фактор 2: Сфера Знаний

Теперь давай поговорим о связанном факторе — Сфере Знаний. Она представляет собой общую широту новых тем, которые тебе необходимо изучить на каждом этапе. Вот как это выглядит:

Сфера Знаний необходимых на каждом Этапе
Сфера Знаний необходимых на каждом Этапе

Когда ты только начинаешь, набор вещей, которые тебе нужно усвоить узок. Каждый, независимо от целей, языка или опыта, должен понять, что такое цикл for, как построить условную логику и другие базовые структуры синтаксиса программирования. В конечном счёте, этих фундаментальных понятий не так много, поэтому Сфера Знаний на этом этапе очень узкая.

Как только ты отходишь от основ, ты видишь быстрое расширение Сферы Знаний, поскольку тебе нужно начать разбираться в более сложных вещах, таких как понимание ошибок и когда использовать код, который ты знаешь как использовать. Это разные вещи, поскольку нет «правильного» ответа на конкретный вопрос… всё становится размытым.

Когда ты переходишь на третий этап, сфера знаний расширяется. Теперь тебе нужно понять, какие инструменты использовать, какие языки изучать, что лежит в основе компьютерных систем, как писать модульный код, объектно-ориентированный, в хорошем стиле и как попросить о помощи (и это только часть). Каждое посещение Google или Хабр заводит тебя в очередной набор кроличьих нор заваливает новыми вещами, о которых ты не знаешь, но чувствуешь, что должен.

Ты не знаешь о том, что ты чего-то не знаешь.

Только когда ты, наконец, нашёл какой-то способ и покинул пустыню, сфера снова начинает сужаться. К этому моменту, ты определился с выбранной технологией и её местом в экосистеме. Ты, наконец (в значительной степени) знаешь то, чего не знаешь и можешь проложить путь через это. Ты продолжишь увеличивать фокус по мере продвижения и к началу карьеры.

Этап III: Пустыня Отчаяния

Понимая эти факторы, ты сможешь увидеть, что Скала Растерянности является просто поворотной точкой. Боль, вызванная ядовитой смесью быстро растущей Сферы Знаний и падающей Плотности Источников, приводит к тому, что я называю «Пустыней Отчаяния».

По сути, это пустыня, в которой ты знаешь, что где-то есть конец, но не знаешь, как до него добраться:

Пустыня Отчаяния. рассредоточен, рассеян и потерян...
Пустыня Отчаяния. рассредоточен, рассеян и потерян...

Пустыня длинная и таит в себе опасности. По пути ты обнаружишь, что тебя тянет к «Миражам Соблазнов» — десяткам заманчивых источников, которые, кажется, содержат решения, которые ты ищешь, но снова и снова осаждают тебя на месте, где одинокий песок простирается до каждой линии горизонта.

Возможно, ты запишешься на пару МООК курсов от Яндекс.Практикума, Степика или Скиллбокса. Или найдёшь учебник, который претендует на то, чтобы пройти весь путь. Ты думал, что усвоил уроки Заботливого Медового месяца, что простых ответов не бывает, но искушение искать спасения слишком велико и ты попадаешься на обещание, что только это приведёт тебя к финишу и ничто иное.

Ты не сможешь обучиться этому за неделю, за месяц, за учебный год в универе, кто бы что ни говорил, так что перестань попадаться на эту уловку!

Тебе предстоит узнать НАМНОГО больше, чем ты, возможно, ожидал. Даже если ты можешь запустить некоторые приложения, тяжело не чувствовать себя потерянным в великом плане становления настоящим профессионалом. Сложно измерить свой прогресс. Откуда ты знаешь, что нужно изучить и изучаешь ли вообще нужное?

Даже если ты в верном направлении, тяжело измерить свой прогресс. Ты можешь чувствовать себя полностью потерянным до тех пор пока не сможешь сделать что-то, что выглядит и ведёт себя ровно так как ты ожидал. Но при достаточной настойчивости и хорошем компасе ты, в конце концов, запустишь несколько своих первых «настоящих» проектов и поймёшь, что ты, в итоге, начинаешь смекать.

Конечно, до сих пор было трудно, но, может быть эти ваши веб-разработки не так уж плохи… Всё налаживается!

Этап IV: Взлёт Напуганного

Ты прошёл через пустыню и твоя уверенность растёт. Твой Google-фу превосходен и ты, наконец, можешь понять эти подробные отраслевые посты и видео. Возможно, ты глубоко изучил определённый язык или структуру и уверен, что сможешь создать и запустить работающее приложение.

Это «Взлёт напуганного»:

Взлёт Напуганного
Взлёт Напуганного

Внешне всё может казаться, что всё хорошо, но в глубине души ты знаешь, что ещё не достиг цели.

Ты можешь заставить приложение работать, но что внутри? Твой код состоит из синей изоленты и подорожников, но хуже всего, что ты даже не знаешь, какие части ужасны, а какие действительно хороши. Твоим периодическим вспышкам гениальности противостоят нубские ошибки и, что ещё хуже, закрадывается подозрение, что ты до сих пор не понимаешь, что делаешь.

Это биполярный этап. Ты чувствуешь, что половина тебя — пуленепробиваемый разработчик, а другая половина — тонкая оболочка эффективности, прикрывающая новичка с дикими глазами, который слишком глубоко увяз. Чем дальше ты продвигаешься, тем больше нарастает мучительное чувство неуверенности, будто кто-то собирается «расколоть» тебя как мошенника.

Ты чувствуешь, что уже должен быть разработчиком, но расстояние между кодом, который ты пишешь и «профессиональным» кажется огромным как никогда…

В конце концов, однако, ты справишься. Слишком много причин сдаться! Пустыня Отчаяния позади тебя и Скала Растерянности осталась в далёком воспоминании. Ты в итоге, действительно, на взлёте. Ты учишься быстрее и эффективнее, чем когда-либо прежде и, в конце концов, усвоишь достаточно лучших практик, чтобы твои рыхлые знания срослись в набор навыков производственного уровня.

Взлёт Напуганного всегда занимает больше времени, чем ожидаешь и кажется бесконечным, потому что ты всегда так близко… но ты доберёшься до цели. Если ты достаточно настойчив в правильных направлениях, то убедишь кого-нибудь заплатить тебе за то, чтобы ты продолжал учиться. Работа твоя.

Как всё это выглядит

Итак, теперь ты увидел путь и причины, по которым он может быть трудным. Когда ты объединяешь все четыре этапа, которые мы рассмотрели, с факторами, которые их определяют, это выглядит примерно так, как показано на следующей диаграмме:

Одно дело знать путь, а другое — пройти по нему. Давай начнём с правильной ноги.

Как Справиться и Выжить

Путь кажется напряжённым и, честно говоря, так и есть. Важно понимать на что ты идёшь, особенно если идёшь в одиночку. Но ты не обязан. Существуют способы срезать большинство этих проблем. Учиться программировать редко бывает так просто, как это изображают люди, но также редко бывает настолько сложно, как это кажется в глубине твоего отчаяния.

В этом разделе, я познакомлю тебя с ключевыми тактиками, которые ты можешь использовать, чтобы держать себя в правильном направлении.

I: Выживание в Заботливый Медовый месяц

Избыток доступных источников в Заботливый Медовый месяц делает его очень увлекательным. Они проделывают большую работу, облегчая тебе логическое мышление, которое тебе нужно развивать на следующих этапах. Это прекрасное время, чтобы начать изучать программирование, поэтому постарайся получить от этого удовольствие и помни об этих двух советах:

  1. Начинай пробуя различные источники, чтобы определить, как ты учишься лучше и какие проекты тебе больше всего интересны. Возможно, это короткие задачки, упражнения в браузере или индивидуальное наставничество. Будь открытым ко всему в начале и не обращай внимания на всё, что тебе следовало бы изучить… на этом этапе весь код одинаков.

  2. Затем выбери один источник и придерживайся его, как только понимаешь, что он тебе подходит. Проработай до конца вводный курс, который должен дать тебе все базовые знания, необходимые для написания простых скриптов и приложений. Потом готовься начать программировать самостоятельно.

II: Выживание на Скале Растерянности

Почти каждый столкнётся со Скалой Растерянности, потому что единственный путь стать разработчиком — это, что уж там, разрабатывать. Ты можешь притворяться, что программируешь, регистрируясь на курсах (или уроках, которые выдают себя за «полные» курсы), но ты просто откладываешь неизбежное. Курсы — хороший способ уйти от более сложных вводных предложений, но в какой-то момент тебе придётся отучать себя от успокоительного и встретиться с реальным миром.

Три совета, как перейти к самостоятельному программированию:

  1. Работай с кем-нибудь ещё, даже таким же новичком. Ты удивишься, настолько проще отлаживать невыносимую ошибку, когда у вас две пары глаз.

  2. Читай код других людей, чтобы привыкать к хорошим шаблонам. Пытайся понять, почему автор сделал так, как сделал. Ты бы не пытался стать писателем, не читая книг, не так ли? Не спускай глаз с любых задачек или проектов, для которых другие люди написали решения.

  3. Начинай с малого и постоянно развивайся. Хорошо иметь интересные большие проекты в уме на будущее, но сначала привыкни к отладке и поиску источников для небольших задач. Здесь опыт ничем не заменишь.

III: Выживание в Пустыне Отчаяния

Как только ты привыкнешь к отладке, твоей самой большой проблемой станет поток требуемых знаний и полное непонимание, как это всё изучить… Пустыня Отчаяния. В этой ситуации, то что тебе нужно — это уверенный путь вперёд. Миражи Соблазнов представляют собой все интересные побочные пути, кроличьи норы и схемы быстрого получения навыков, которые в конечном счёте только тратят твоё время.

Итак, ключи к выходу из Пустыни Отчаяния:

  1. Имей чёткую цель того, чего ты хочешь достичь, потому что в противном случае ты, в итоге, будешь гоняться за своим хвостом, изучая все возможные интересные, но бесполезные вещи. Даже если у тебя много времени, не ведись…

  2. Найди чёткий путь, ведущий прямо к поставленной цели и убедись, что он действительно приведёт тебя к ней. Здесь тебе нужно копнуть глубже, чем маркетинговые слоганы и улыбающиеся лица на сайтах курсов или обложках книг, чтобы спросить: «Поможет ли это мне достичь цели, которую я поставил, или нет?»

  3. Фокусируйся и избегай отвлекающих факторов, потому что если ты относишься к тому типу людей, которые заинтересованы в обучении программированию, ты также относишься к тому типу людей, которым интересно изучать множество других замечательных вещей. Когда программирование становится трудным, ты должен быть в состоянии двигаться вперёд, а не просто пробовать следующую крутую вещь.

Если сможешь определить путь и придерживаться его, то в конечном счёте, перейдёшь к следующему этапу вместо того, чтобы тратить месяцы или годы на погоню за миражами по зыбучим пескам этой пустыни.

IV: Выживание при Взлёте Напуганного

Взлёт Напуганного — один из сложнейших переходов. Ты можешь разрабатывать, но хотелось бы стать разработчиком. Чтобы пройти этот этап и соответствовать требованиям работы, делай три вещи:

  1. Ищи и следуй лучшим практикам программирования. Ты должен понимать разницу между решением и лучшим решением. Лучшие практики — основное различие между самостоятельным хакерством и созданием качественного кода в реальной работе.

  2. Проверь свои предположения, потому что ты, вероятно, сталкивался с некоторыми зияющими дырами в своих знаниях, о которых ты даже не подозревал. Тебе нужно определить и залатать эти дыры.

  3. Займись непривлекательными навыками, которые редко используются, но очень важны для перехода в профессиональную среду. Это включает в себя такие вещи как: тестирование, моделирование данных, архитектуру и развёртывание, которые действительно легко пройти мимо, но которые абсолютно необходимы для хорошей разработки.

Ключом к достижению этих целей и продвижению через Взлёт Напуганного является получение обратной связи. Те кто учился полностью самостоятельно могут быть продуктивными, но редко имеют разборчивый модулярный и удобный для сопровождения код, который делает их привлекательными в профессиональной среде. Тебе нужно работать с другими людьми, которые будут подвергать сомнению твои предположения, задавать неудобные вопросы и заставят тебя исправить дыры в знаниях.

Итак…. Можно ли это сделать?

Всё это может показаться ошеломляющим, но я уверяю, многие выстояли и выжили на этом пути до тебя. Поняв предстоящий путь, ты уже находишься в хорошей точке, чтобы взяться за него с чётким планом и доступом к правильной помощи.

Комментарии (195)


  1. zorn_v
    12.08.2022 16:41
    +41

    Почему подобные статьи делает програмирование сложным ? Да потому что там 10005000 символов.


    1. Hrodvitnir
      15.08.2022 06:36

      Особенно когда пишут про травмы от обучения. Ох уж этот травмирующий опыт того, что надо вкалывать


      1. mianoki
        15.08.2022 09:22

        Тоже улыбнулся на этом моменте ;)

        Особенно с уточнением "ОНИ ВСЕ СОЦИОПАТЫ!1!11"


  1. saipr
    12.08.2022 17:30
    +2

    В академии на одном из факультетов будут готовить специалистов по программированию.
    Что это такое я толком не понимаю, но чувствую, что за этим стоит большое будущее и вам совет держать путь на второй факультет на специальность «Программирование».

    Вот такие слова я выслушал 50 лет назад, и я последовал этому совету. И не разу с тех пор не пожалел.
    А понять программирование и стать программистом мне помогли спичечные коробки:


    Представь себе кучу пронумерованных/подписанных спичечных коробков, в каждом из которых лежит какое-то количество спичек. Коробок со спичками – это и есть ячейка. Адрес ячейки – это номер коробка или его название. Теперь предположим, что надо узнать, сколько всего спичек хранится в пятом и десятом коробках вместе, т.е. выполнить операцию сложения, и такое же количество спичек положить в коробок с номером 15. Заглядываем в коробок №5 и запоминаем сколько в нём спичек, затем аналогичным образом поступаем с коробком №10, складываем запомненные значения. Это и есть то количество спичек, которое нужно положить в коробок №15. ЭВМ делает тоже самое, только не с коробками, а с ячейками памяти


    1. BoldDwarf
      12.08.2022 20:38
      +38

      Воможно это будет смешно но меня сподвигли идти в программирование уроки информатики еще а советской школе.

      Когда я сам выучил бейсик опережая школьный курс и написал на нем примитивный морской бой (кое в чем помог журнал Техника Молодежи).

      Дальше: универ, СМ-4, ЕС 1810, ДВК, лично спаянный спектрум, первые ПК, паскаль, асм, С, С++ и так далее.

      Мне никогда не было тяжело этому учиться, я всегда хотел заниматься имено этим.

      На мой взгляд, если идти в АйТи по зову исключительно денег то и будет тяжело.


      1. saipr
        12.08.2022 22:05
        +1

        Мне никогда не было тяжело этому учиться, я всегда хотел заниматься имено этим.
        Присоединяюсь

        На мой взгляд, если идти в АйТи по зову исключительно денег то и будет тяжело.
        И снова присоединяюсь!


        1. ioncorpse
          15.08.2022 11:14

          Да, за деньгами проблематично. Выгорают. А если твое — ок.


      1. Mist8
        13.08.2022 15:06
        +1

        Информатика это моя боль. У нас в школе не было толковой информатики, не помню чтобы мы изучали какой-нибудь язык программирования.

        Из-за этого я в принципе не представлял себе что такое программирование, пока не столкнулся с этим случайно. Однокурсник предложил подработать, админы сайт. Через это уже постепенно начал верстать а дальше уже и кодить, нашел работу и далее стал учиться программировать.

        Была бы в школе хорошая информатика с обучением программированию - весьма вероятно, был бы уже сеньором, не потеряв ~10 лет на поиски профессии.


        1. php7
          13.08.2022 15:13
          +1

          Вам предложили админить сайт на 10-ом курсе?


          1. vassabi
            13.08.2022 17:56
            +2

            у меня был знакомый, который после пту работал крановщиком.

            Потом так как контора маленькая - начал помогал продажникам с сайтом, потом начал править хтмл, понял, что у него что-то получается, но базы нет.

            Так что он женился, пошел на курсы пхп (или джаваскрипта?), искал и нашел работу (все это время жил на деньги жены :) ), и теперь он уже лет пять как фронт+бек - программист, все дела.


            1. Ellinist
              15.08.2022 12:15
              -1

              У вас нет английской раскладки?

              Простите великодушно, но как-то глаз режет вот это вот - хтмл, пхп, джаваскрипт.

              Мне вспомнился случай... искали мы в организацию программиста, получили много много всяких резюме. И тут, вдруг, появляется резюме, в котором прописаны все существующие языки и технологии.

              Ну, мы, естественно, вызвали к себе этого чудо-специалиста. Пришел молодой мальчик, лет так 20, не более.

              Сидим, разговариваем. Вроде проблем в разговоре нет.

              А потом я спрашиваю, - а ты эйч-ти-эм-эл на каком уровне знаешь?

              Чего?, - спрашивает он.

              Ну, эйч-ти-эм-эл, - повторяю я и пишу на бумажке аббревиатуру HTML.

              Аааа! - с восторгом прокричал он, - Ха-тэ-мэ-лэ! Конечно знаю!

              Конечно, мы его не взяли.


              1. mayorovp
                15.08.2022 13:37

                Ну, произносить букву "L" как "лэ" и правда странно, но в чём, собственно, проблема произношения HTML как "ха-тэ-эм-эль"?


                Нет, если у вас международная команда, разговаривающая на английском — тут всё понятно, неправильное произношение просто не позволит работать в команде. Но если это не так, то какое вообще дело до того, как программист произносит аббревиатуры?


                Я вот на слух одинаково легко что "Эйч-ти-эм-эл", что "Аш-тэ-эм-эл", что "Ха-Тэ-Эм-Эль" воспринимаю.


        1. ReadOnlySadUser
          14.08.2022 11:52
          +3

          У нас в школе не было нормальной информатики, да и программировать нас тоже не учили. Но я интереса ради открыл в 11-м классе последние страницы учебника по информатике, где объяснялся базовый синтаксис visual basic) Вот таким нехитрым образом я открыл для себя мир программировния :)


          1. DvoiNic
            15.08.2022 09:36

            у нас в школе вообще не было информатики :-) (еще не было)
            Повезло, что на УПЦ (учебно-производственный цех) была специальность Оператор ЭВМ. Программировать там не учили, но общее понятие об алгоритмах дали. А уже перед самым окончанием школы повезло — в институте открыли «факультет юного программиста». Фортран, СРВ (а вот какая именно-вылетело из головы прямо в процессе написания этого сообщения) на СМ-1 и СМ-3.


      1. Ellinist
        13.08.2022 15:27
        +8

        Воможно это будет смешно но меня сподвигли идти в программирование уроки информатики еще а советской школе.

        Информатика - как много в этом слове!

        Ненавижу, на самом деле, это слово! О чем оно? Что это?

        Это как кибенематика - смесь кибернетики и математики!

        Можете минусовать, но я именно так воспринимаю это слово.

        Я программирование изучал еще в советское время с помощью волшебной машины СМ-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#.

        Так что - программирование и только программирование!


      1. Rikkster
        14.08.2022 02:29
        +2

        Мне никогда не было тяжело этому учиться, я всегда хотел заниматься имено этим.На мой взгляд, если идти в АйТи по зову исключительно денег то и будет тяжело.

        Один в один так же


    1. Xeldos
      12.08.2022 23:10
      +12

      Представь себе кучу пронумерованных/подписанных спичечных коробков, в каждом из которых лежит какое-то количество спичек. Коробок со спичками – это и есть ячейка. Адрес ячейки – это номер коробка или его название.

      Отлично, а теперь на том же уровне про монады, внедрение зависимостей и TDD.


      1. vassabi
        13.08.2022 14:00
        +3

        монады - для начала нужно понять, что это неизменяемые коробки спичек, то есть такие коробки спичек, из которых мы не можем ни достать ни положить спичек (считайте, что они там приклеены намертво эпоксидкой). Так что если мы "добаляем спичку", то на самом деле, мы берем со стеллажа готовый коробок, в котором на 1 спичку больше, старый коробок выкидываем, а новый кладем на его место: "вуаля! в коробке спичек №123 теперь на 1 спичку больше!" (а если мы "вычитаем спичку", то на самом деле - мы заменяем коробок новым коробком, в котром на 1 спичку меньше)

        внедрение зависимостей - это когда вместо того, чтобы хранить все кучи коробок спичек (и разбираться что где лежит, доставать, смотреть, и т.д.), хранишь только фотографию номеров коробков сзади которой написано "у Пети". Если надо достать спичек или положить спичек - подзываешь Петю и показываешь пальцем по фотографии - в какой коробок что брать\ложить. Такие же фотографии есть для всех других внешних зависимостей - для Маши, Коли и Васи.

        (Таким образом Петя вместо конкретного Пети, превращается в курьера доставки сети спичек "у Пети" - любой кто умеет работать по этой фотографии, вам подойдет)

        TDD - сначала вы составляете "фотографию с номерами коробков", а потом по ней правила работы этой фотографии: "если сюда положить 10 спичек, то при открытии воон того коробка, там должно лежать 100 спичек" или "если сюда положить 0 спичек, то загорится зеленый, если 1 - желтый, если 2 - красный, а если 3 - и больше, то красный мигающий" и т.д.

        Потом убедиться, что все они НЕ ВЫПОЛНЯЮТСЯ (фотография же - ничего не работает еще на самом деле). Только после этого начинать по этой фотографии и правилам делать такую систему коробков, чтобы все правила стали выполняться.


        1. 0xd34df00d
          13.08.2022 18:28
          +4

          Вместо монад у вас получилось чистое программирование. Давайте теперь все-таки про монады. Желательно — не только в итоге выучить, что Maybe — монада, но и понимать монадическую структуру, скажем, парсеров или вероятностного программирования.


          1. vassabi
            13.08.2022 19:17

            там был такой длинный текст, что я оставил от него только первую часть :)

            а вам действительно интересно про монады на коробках от спичек ?


            1. 0xd34df00d
              13.08.2022 19:22
              +2

              Да, действительно.


              Но я готов ограничиться системами типов на коробках от спичек. Но только не там int/float/etc, а нормально, по-взрослому, с полиморфизмом, конструкторами типов и вот этим всем.


              1. vassabi
                14.08.2022 00:21

                а нормально, по-взрослому, с полиморфизмом, конструкторами типов и вот этим всем.

                воу воу, палехче!

                вы точно темы для джуников айти предлагаете ?


                1. mayorovp
                  14.08.2022 00:32

                  Да. Это всё не сильно сложнее того же ООП, возможно даже что проще. Особенно если не применять на практике (впрочем, ООП без применения на практике тоже довольно простое).


                  1. vassabi
                    14.08.2022 13:42
                    +1

                    ха! если не применять на практике (и без реальных предметов) - так я готов написать объяснение для чего угодно!

                    (а то, что не его/не поймут/не все - "это уже проблемы индейцев")

                    PS: но если серьезно, то насколько я вижу - процесс "обьяснения на пальцах" идет в сторону "сверху-вниз", от абстрактного к практическому - т.е. сначала рассказываются/показываются формальные правила, а потом уже демонстрируется поведение железа "на спичках" (как одной из реализаций формальной системы).

                    Объяснять в обратную сторону "снизу-верх", т.е. - сначала показать страшно сложную машинерию из спичек, чтобы потом выводить оттуда сравнительно простые формальные правила (собственно физики и биологи так природу изучают. Уже который век) - это ИМХО занятие не на один год и не для слабых духом ...


              1. vassabi
                14.08.2022 13:47

                "коробки спичек" - так это же и есть int.

                Вы хотите "ограничиться системами типов на int" и при этом получить "с полиморфизмом, конструкторами типов и вот этим всем" ? :)


                1. mayorovp
                  14.08.2022 13:54
                  +3

                  Во-о-от, вы уже осознали проблему. Только почему-то ещё не поняли, что это ваша проблема, а не проблема оппонента…


                  1. vassabi
                    14.08.2022 14:00

                    ЭЭэээ... какая проблема?

                    если у меня и есть какая-то "моя проблема" - то я ее вижу только в том, что я согласился помочь объяснить хоть что-то "на коробках от спичек" и потратил на это свое время :)

                    Других моих проблем я как-то не наблюдаю.

                    UPD: да, кстати, запросы вида "нарисуйте мне красные линии зеленым цветом" - я тоже считаю проблемами не исполнителя, а просителя :)


                    1. mayorovp
                      14.08.2022 15:29
                      +1

                      Вы не просто согласились помочь объяснить хоть что-то, вы попытались оспорить утверждение о невозможности полноценно объяснить ФП "на коробках от спичек" (а Xeldos, когда просил это сделать, явно задавал риторический вопрос, в расчёте что все сами догадаются что это невозможно).


                      А теперь, когда сами согласились что это невозможно, почему-то продолжаете спорить. Зачем?


                      1. vassabi
                        14.08.2022 17:07
                        +2

                        1) для начала - хотелось бы увидеть мнение самого Xeldos (а то у нас с вами - только интерпретации "как можно прочитать текст". Ну, или вы его второй аккаунт или читаете мысли и можете квалифицированно сказать - чего именно просил Xeldos)

                        2) извините, что я вас разочаровываю, но я даже не пытался что-либо оспорить :)

                        Я искренне думал, что кому-то будет интересно почитать описание монад+внедрение зависимостей+ТДД "на коробках спичек", и что будет забавно это попробовать сделать.

                        Про монады кстати я могу дописать, если Xeldos попросит-таки. А вот уже запросы от товарища 0xd34df00d

                        Желательно — не только в итоге выучить, что Maybe — монада, но и понимать монадическую структуру, скажем, парсеров или вероятностного программирования

                        или

                        нормально, по-взрослому, с полиморфизмом, конструкторами типов и вот этим всем.

                        это уже я пас.

                        Как я уже написал в комментрии выше, спички - они все-таки про реализацию, а не "понимание монадической структуры", для иллюстрации частного примера для детей т.н. "младшего школьного возраста". И во-вторых - краткий пример "на абзац текста" у меня пока не придумывается, а писать длинные тексты - это уже работа получается, а не комментарии на хабр :)


                      1. Xeldos
                        15.08.2022 10:50
                        +1

                        Я скорее хотел показать, что современное программирование капельку сложнее, чем то, что можно объяснить на "коробках от спичек".

                        Выше приведённое "объяснение"... Ну первый пункт - он просто неверен, как уже укзаали.
                        Второй пункт - вроде верен, но непонятен. Какие-то фотографии, пальцы, Пети...
                        Третий пункт - объяснение верное, понятное, но, увы, бесполезное. Уровня "мышки, станьте ёжиками".

                        В контрасте с этим аналогия "номер коробки спичек" - верная, понятная, полезная. Потому что поясняет простую, но незнакомую вещь.


        1. Deosis
          15.08.2022 08:26
          -1

          Монады можно воспринимать как робота. Вы ему даёте команду обработать коробки со спичками и всё.

          Может ему вообще не достанется коробка, или придется обрабатывать целый ящик коробков. Или он будет ждать, пока ему этот коробок принесут, или человек даст ему этот коробок.


      1. Acuna
        13.08.2022 19:09

        Вот кстати да, уже давно понял что программирование нужно объяснять прям реально на игрушках, впору книгу писать "Программирование для самых маленьких", без сарказма.


    1. Wesha
      13.08.2022 04:32
      +5

      А мне врезалась в память фраза "компьютер — это такой савант: по жизни — полнейший идиот, но считает ОЧЕНЬ-ОЧЕНЬ быстро". Из чего вытекает, что считать должен он, а думать, как ему считать (включая ситуации "бумага закончилась", "карандаш сломался", "в комнате свет погас", "на таблицу логарифмов сел мотылёк", "уборщица у него под стулом протереть пытается" и т.д.) — я.


  1. bungu
    12.08.2022 17:30
    +23

    Ребята, переставайте идти в IT, сейчас джунов перебор


    1. Primo_Talatelli
      12.08.2022 20:10
      +1

      Джунов много не бывает, пусть ребятки работают, может хоть вырастим и сохраним пару спецов нормальных в пределах нашей страны


      1. saboteur_kiev
        13.08.2022 13:17
        +7

        Нормальные потенциальные спецы и так достаточно мотивированы, чтобы идти в ИТ без рекламы и курсов. И даже если они будут идти чуть дольше, количество адекватных кандидатов среди таких джунов в разы увеличится.


    1. zaqqq13
      13.08.2022 08:54
      +15

      Причем часть джунов сейчас совершенно не мотивированная. На днях с таким пришлось чуток поругаться. Джун с почти полугодом опыта пришел за помощью с багом, само собой я за него дебажить его простыню кода не стану, посоветовал ему сначала отрефакторить свой класс, привести к принятым в компании стандартам, плюс постараться разбить методы на более мелкие с рассчетом на то, что он при рефакторинге сам увидит косяк, как это происходит в 90% подобных ситупций, либо тогда уже я присоединюсь и читать хоть будет удобно. На что в ответ получил замечательную фразу "Ай не, тут все работает по большому счету, а как код выглядит - плевать". Сам не являюсь адептом красивого кода, из тех что нейминг переменных продумывают полдня и отступы ровняют под линейку, но подобное пренебрежение code style и советом старшего более опытного сотрудника немного подожгли пятую точку


    1. TataSysueva
      13.08.2022 09:50
      +1

      Чем больше джунов, тем больше конкуренция среди них, тем больше сил нужно приложить, чтобы быть замеченным. В итоге "качество" джунов растёт, разве нет? Все плюсы здоровой конкуренции) Конечно, могу ошибаться, сама такой же недоджун даже, но мне просто нравится, а там как пойдёт. Но сама мысль, что таких как я толпа, подстегивает.


      1. saboteur_kiev
        13.08.2022 13:19
        +3

        Предположим что есть один хороший матерый кот. И есть тысяча котят.

        А нам надо ловить крыс. Какую конкуренцию коту составит тысяча котят?


        1. goga_kk
          13.08.2022 13:35
          +8

          Что за мода пошла совать везде идиотские (ох простите мою токсичность) аналогии, не задумываясь, отражают ли они реально суть ситуации, которую пытаетесь показать с помощью аналогии.


          1. SpiderEkb
            13.08.2022 16:06

            Ну давайте проще.
            Вам нужно выполнить некоторую работу. У вас на эту работу есть определенный бюджет и определенный срок сдачи. Не уложитесь в срок - не получите денег.

            Кого выберете - человека, который заведомо может эту работу выполнить, или того, кого вам придется обучать, контролировать и результат все равно не гарантирован.

            И да. От того, выполните работу в срок или нет напрямую зависит будет вам на что покушать купить или нет.

            Вот так вот просто. Сотрудника нанимают не "чтобы было", а чтобы он работу работал и приносил прибыль.

            Да, когда у вас есть перспективы развития, вы можете взять пару джунов "на будущее" (не под текущие задачи) и потихоньку вводить их в курс дела, обучать в расчет что через какое-то время он начнет давать отдачу. Но и тут есть риск что как только вы джуна обучите, он от вас уйдет в другое место где ему пообещают на три копейки больше. И в результате вы потратитесь впустую. А кто-то за ваш счет выиграл.

            Ну и учитывайте что "вайти" идет много шлака. Не потому что им интересно, а потому что им из каждого утюга в уши льют "заплатите нам 50тр сейчас и через три месяца вам гарантирована работа с оплатой 100500 в час". А по факту там ни базового образования, ни зачатков алгоритмического мышления, ничего. Полная профнепригодность. Им даже все это неинтересно и скучно, они сюда исключительно за деньгами пришли и больше им ничего не надо.


            1. vassabi
              13.08.2022 18:16
              +1

              Кого выберете - человека, который заведомо может эту работу выполнить, или того, кого вам придется обучать, контролировать и результат все равно не гарантирован.

              вы будете смеяться - но если это второй-третий проект из серии (ака "формошлепство"), а что-то уникальное и новое - то ни джун ни синьор гарантировать ничего не смогут. В жизни всегда есть место удивительному.

              Единственное что можно будет гарантировать - что синьор сможет сравнительно быстро разобаться - можно или нет это сделать, сделает если "да", и если "нет" - то предложит варианты - как можно что где обойти, если таки что-то сделать невозможно.

              С джуном вы будете делать проект долго, нудно и если будет фейл - то не сможете разобраться, толи это был фейл задумки (ака "звезда с неба"), то ли фейл инструментария (ака "на санках по асфальту ездить можно, но мотор слабоват") или фейл самого джуна (без комментариев)


              1. SpiderEkb
                14.08.2022 16:47

                Ну честно скажу что с формошлепством дел никогда не имел.

                В нашей ситуации джуну можно поручить что-то совсем простое и совсем типовое на что нет смысла отвлекать более "серьезных" разработчиков. Но при этом надо закладывать какое-то время "старших товарищей" на код ревью и разъяснение простых вопросов "почему так нельзя". Примеры приводить не стану т.к. они очень специфичны в силу ряда причин.

                Когда на задачу ставится более опытный разработчик, заведомо известно что совсем косяков по эффективности и производительности там точно не будет. Потому что у человека опыт и понимание как не надо делать (именно "как не надо" приходит с опытом). И человек готов написать лишние пару-тройку десятков строк кода ради эффективности там где это нужно, а не просто воткнуть туда первый попавшийся компонент, не понимая как но работает внутри (опять же - конкретные примеры слишком специфичны). Это как раз тот самый пример "на санках по асфальту" - джун просто не знает что можно иначе.


                1. vassabi
                  14.08.2022 17:25

                  ну пример "формошлепства": есть фронт+бек, есть формочка для описания человека (фио, телефон).

                  задача типовая: Нужно добавить еще одно текстовое поле телефон2. Берем почти любого джуника, говорим "копипасть существующий контрол, копипасть поле phone на phone2, и в БД тоже". Там могут быть какие-то мелкие проблемы, но в целом он справится.

                  задача не такая типовая: Нужно сделать переменное количество таких полей. Ее тоже можно сделать, но джуник уже может сломаться во многих местах.

                  И совершенно нетиповая задача: портировать ваше приложение на новое устройство (напрмиер Win->android).

                  Собственно мой (почти риторический) вопрос был такой: гарантирует ли там что-то синьор, если ваше приложение использует что-то из DirectX, у чего нет порта в OpenGL на целевом устройстве?

                  PS: заранее соглашусь с вашим "заведомо известно что совсем косяков по эффективности и производительности там точно не будет". Программист с опытом и в тестах еще что-нить добавить, чтобы проверяло что "ответ от системы пришел быстро".


            1. goga_kk
              13.08.2022 19:53

              Вы всего лишь описали возможные частные случаи. Кого брать зависит от конкретной ситуации. Частично об этом я сказал ранее здесь: https://habr.com/ru/post/682250/comments/#comment_24626034

              В части аналогий я хотел сказать только то, что надо или посмотреть на ситуацию с разных сторон и привести нормальную аналогию, которая действительно помогает разобраться, а не уводит еще дальше от сути.


            1. randomsimplenumber
              13.08.2022 20:44

              Кого выберете

              Смотря из кого выбирать, сколько можно/нужно платить, что по срокам.. Иногда за неимением гербовой бумаги пишем на клозетной ;)


          1. saboteur_kiev
            14.08.2022 04:14

            От количества джунов, которые пришли с месячных курсов, их качество никак не меняется. А те, котоые были мотивированы заранее, они более-менее подтянутся и без курсов.


        1. TataSysueva
          13.08.2022 15:23
          +10

          Кота кормить надо форелькой, чтобы он поймал две крысы. А пара котят, чтобы хозяин их заметил среди тысячи, на энтузиазме и за горсточку китикета поймают 3 крысы. Выхлоп не сильно больше, но на форельке сэкономили. Да и из котят коты вырастают, а если их любить и подкармливать, то они и не сбегут. Видите, я тоже могу в аналогии.

          На самом деле, тема срачная дискуссионная, так что я пас: отдаю победу в споре вам и другим комментаторам после. Мне пора идти и выделяться) Всего доброго!


          1. arheops
            14.08.2022 14:41
            +1

            Это вы забыли про четырех котов, которые должны ходить вокруг тысячи котят и следить, чтоб вместо крыс не поймали курей и заодно не разнесли нафиг ферму.
            Потому, что котята на полном серйозе не понимают, что если они принесли бабочку — это не крыса. И нет, оно не «почти крыса», а вообще не крыса.
            А также не понимают, что если они принесли одну и в процессе выпустили 10 крыс — это никому не надо.


        1. Wesha
          14.08.2022 08:57

          А нам надо ловить крыс. Какую конкуренцию коту составит тысяча котят?

          Вы про zerg rush никогда не слышали?


          1. randomsimplenumber
            14.08.2022 09:44

            Где это разработка ведётся методом zerg rush? ;)


            1. General_Failure
              14.08.2022 10:44

              Если посадить миллион обезьян джунов за печатные машинки компьютеры, то по теории вероятностей они напишут Войну и мир разработают Линукс


            1. Wesha
              14.08.2022 11:11
              +1

              Во-первых, речь была про крыс и котят. Котятам вполне по силам рашнуть крысу.

              Во-вторых... Вы будете смеяться, но в конце 1990-х в моей практике был один товарисч, который работал методом, чем-то напоминающим нейросети и TDD в одном флаконе: приписывал к своей программе пару случайных (ну, такими они, как минимум, выглядели) строк кода и смотрел, ближе ли выдаваемый программой результат к желаемому, или нет. Поддерживать ЭТО, естественно, было совершенно невозможно — и наше счастье, что это были просто сервисные скрипты, а не продукт для клиентов. Так вот, как мне кажется, его метод — самое то для зерг-раша.


              1. vassabi
                14.08.2022 13:51
                +2

                он работал рекуррентной нейронной сеткой еще до того, как это стало мейнстримом!


                1. 0xd34df00d
                  14.08.2022 23:02
                  +1

                  Вообще технически это эволюционные алгоритмы, и я в рамках диплома делал что-то подобное, что генерило достаточно близко описывающую наблюдаемые данные аналитическую формулу.


            1. CrashLogger
              15.08.2022 09:26

              В Индии ? )


      1. General_Failure
        13.08.2022 13:31
        +1

        Чем больше джунов, тем больше конкуренция среди них
        И тем труднее выбрать работодателю, что приводит к отсеву методом «а зачем нам неудачники» (это где часть присланных резюме сразу отправляется в корзину без просмотра)
        больше сил нужно приложить, чтобы быть замеченным
        вместо того, чтобы приложить усилия к освоению разработки


        1. goga_kk
          13.08.2022 13:40

          вместо того, чтобы приложить усилия к освоению разработки

          Согласен отчасти. Чтобы заметили где-то нужно будет показать еще какие-то качества, кроме непосредственно разработки, но в идеале кандидат должен как раз обладать нужным набором качеств. Вопрос в части выбора оптимального кандидата из имеющихся по большей части не проблема кандидатов. Ну, в идеале.


        1. TataSysueva
          13.08.2022 14:44

          1. Так и работодатели не отстают: в вакансиях указывают больше требований, тестовые дают тяжелее, на собесах больше спрашивают. И при всём этом работодатель не останется без кандидатов на позиции джунов.

          2. Кажется, возникло недопонимание между нами. Говоря "быть замеченным", я не имею в виду "надеть красный парик и танцевать сальсу на собеседовании". Быть замеченным за счёт своих хард и софт скиллов, если хотите, портфолио.


      1. arheops
        14.08.2022 14:39

        Не совсем так.
        Вот смотрите. Ситуация на самом деле где-то такая.
        У нас есть какое-то количество учителей. Им, как правило, платят мало или вообще не платят за обучение. Потому что основная работа у них — не учитель. У нас есть какое-то количество специалистов(это те или другие люди) которые работают и получают денги, но учить им некогда, развечто могут дать пару советов или натолкнуть на идею ЕСЛИ учащийся правильно сформулировал вопрос.
        Допустим учителей Х, у них есть по 3 часа в день и консультантов Х*4, но у каждого по 15 минут в день.

        Внимание, вопрос. Какое качество обучения будет, если обучаться будет Х человек по сравнению с вариантом, когда обучаться будет 10*х(на каждого — 0.3часа учителя и 6минут в день косультантов).

        А еще ведь есть курсы, где «учителя» получают по 200 долларов, и подразумевается, что они имеют ту же квалификацию, что и программисты с зарплатой 4000+. Понятно, что рынок так не работает и на курсах преподают мягко говоря не лучшие профессионалы.


    1. Ellinist
      15.08.2022 12:26

      Просто в IT сейчас идут, начитавшись об офигительных зарплатах. При этом, практически никто не представляет себе путь в программисты. В статье весьма неплохо описано разочарование программистов в те или иные моменты времени. Жаль только, что там только одна пустыня отчаяния - у меня лично таких пустынь было уже около пяти.

      Тут ведь как - never give up - я лично придерживаюсь этого подхода.

      А молодежи подавай сейчас огромную зарплату сразу.

      Кстати, обратным проявлением этого являются и требования со стороны нанимателей - им тоже подавай программиста 10 лет опыта, знающего все что можно и что нельзя, и не старше 20 лет от роду.


  1. GospodinKolhoznik
    12.08.2022 18:37
    +21

    Он начал с изучения Ruby, а затем пробежался по другим языкам, таким как Scala, Clojure и Go

    Ничего себе, пробежечка. А потом он поразмялся в освоении Rust, Haskell, Coq и Prolog? Да этот Коля, мать его, гений!


    1. Constanine
      12.08.2022 20:10
      +1

      Так в том то и дело что "пробежался". В оригинальной статье есть ссылка на другую статью, после ознакомления с которой становиться все более менее понятно. А Коля превращается в Quincy Larson.


  1. eandr_67
    12.08.2022 19:43
    +19

    Только вот «Коля» изучал не программирование. Он изучал лишь написание кода на языках программирования. Не то, как находить способы решения программистских задач (т.е. алгоритмы), а то, как записывать алгоритмы в понятной компьютеру форме — без понимания базовых свойств алгоритмов.

    Потому, все псевдопсихологические рассуждения в статье не имеют смысла, так как изначально произведена подмена объекта обсуждения.

    И подавляющее большинство «онлайн курсов» изучить программирование тоже не помогут: они дрессируют писать типовой код, решающий типовые рутинные задачи, но не дают знания основ программирования.


    1. Vassam
      12.08.2022 23:33
      +20

      Но 90% разработчиков и пишут типовой код, решающий типовые рутинные задачи. Потому что, собственно, решение типовых рутинных задач и есть основная задача автоматизации и программирования.


      1. Paskin
        13.08.2022 23:53
        +3

        Проблема в том, что 90% современных разработчиков не понимают, как работает код который они написали. В этом отчасти виноваты дешевая электроника, "облака" и прочие факторы - когда "купить инстанс побольше" гораздо быстрее и дешевле, чем оптимизировать что-то "тормозящее" - но и нежелание разбираться тоже присутствует, поддерживаемое известным определением Аджайла "slap shit together and deploy".


        1. kshirinskiy
          15.08.2022 11:14

          80% сеньоров не знакомы с основами микроэлектроники и у них нет понимания архитектуры процессоров. И что с того?


          1. DvoiNic
            15.08.2022 11:28

            некоторым эти знания помогли бы создавать более оптимальные системы. Но не всем и не всегда.
            Вообще, «до какой глубины нужно знать» — вопрос тоже весьма непростой. как и вопрос «по каким критериям нужно оптимизировать систему»


          1. Paskin
            15.08.2022 14:09

            Основы микроэлектроники тут ни при чем. А вот незнание основ архитектуры - приводит к созданию чудовищно тормозных систем, жрущих гигабайты памяти и уходящих в астрал при переносе в VM или просто на другой компьютер.


        1. stanislavskijvlad
          15.08.2022 11:44

          смотрите, у нас есть архитектор, который проектирует мосты. он чертит не на бумаге, а в программе. его главный инструмент – это компьютер, на котором крутится, скажем, SolidWorks. есть бухгалтер. идеально знает 1С и все возможности Экселя. дизайнер интерьеров, который делает рендер готовой квартиры для заказчика. надо ли им знать ширину запрещённой зоны кремния или отличать гетерструктуру от металлизации полупроводника. или основы квантовой механики ? думаю, что нет. а надо ли это знать сеньёру ? имхо, ему даже не надо знать, как работают прерывания системы, если это не его компетенция.

          мне в руки одна книга попала, типа известная. там на обложке был стол на курьей ножке. и автор говорит, "раньше я экзаменовал студентов на имя_языка и сразу видел их способности. а потом появился Си, и все обленились." в защиту студентов хочу сказать, нельзя всем знать всё. если я мастер Java и алгоритмов, кто меня обвинит, что я не знаю, как сделать бинарное дерево или парадокс Тьюринга halting machine ? кто-то операционные системы пишет, кто-то компиляторы или новые методы сортировки.

          одним словом, надо знать свой инструмент, который меня кормит. а смежные знания – как плюс.


          1. Paskin
            15.08.2022 14:17

            Дело в том, что "знают свой инструмент" очень немногие. Самый простой пример - паттерн "прокси" можно реализовать в виде двух очередей (запросов и ответов), при этом система будет очень надежной и не выйдет (при ограничении длины очереди) за заданное потребление ресурсов.
            Но почему-то его почти всегда реализовывают в виде (запрос, ожидание, ответ)*100500 тредов, да еще и с авто-масштабированием - точно в соответствии с теорией приводящим к отказам в обслуживании при малейших пиках нагрузки.


    1. SAWER
      13.08.2022 01:01
      +2

      Алгоритмы тоже не являются программами, примерно как наваленная груда кирпича ещё не здание)
      Оказалось, самое сложное - доносить о том, что надо писать программы, а не код или алгоритмы. И исходить надо при проектировании из программы, используя алгоритмы и код лишь как инструменты. Не редко выходит иначе даже после 5 лет работы программистом.


      1. inkelyad
        13.08.2022 12:01
        +1

        Оказалось, самое сложное - доносить о том, что надо писать программы, а не код или алгоритмы.

        Самое сложное - таки алгоритмы. Для чего-то нового и что достаточно быстро решать не умеем. Смотри всякие алгоритмы оптимизации и поиска. Да, те самые, которые потом еще доказать надо, почему они на 0.05% быстрее работают, чем то, что уже известно. Но на практике большая часть работающих в индустрии людей придумыванием таких не занимается. И, вообще, оно не программирование уже, а Computer Science.


        1. arheops
          14.08.2022 14:46

          Самое сложное — программы. Алготитмы в 99.99% задач известны или их можно найти в книгах.


          1. inkelyad
            14.08.2022 16:31
            +1

            Есть разница, использовать уже известные или придумывать новые алгоритмы. Я про то, что придумывать новые алгоритмы, из тех вот долей процента, что еще в книгах нет - посложнее будет. Но оно уже не совсем про программирование, как оно в отрасли понимается.


    1. zaqqq13
      13.08.2022 09:01
      +6

      В реальных коммерческих проектах редко нужно это все. Как пример - у нас есть шелл, который данные из одного микросервиса сбрасывает в кафку, шелл работает 20 часов ориентировочно, его реально ускорить если сделать batch отправку, но тут уже есть нюанс - для этого надо выделить ресурс команды, которая писала либу транспорта в кафку, а они занимаются не только этой либой и бизнесу важнее продуктовый выхлоп команды чем какое-то там ускорение какого-то скрипта, который на юзеров не влияет и прибыль не уменьшает. Угадаете когда этот техдолг будет решен? А я подскажу - скорее всего никогда, если только не пропихнуть в спринт в нагрузку к остальным задачам когда есть небольшой запас по времени


      1. mayorovp
        13.08.2022 11:49

        Кафка не такая и сложная, там можно и стандартными либами самой кафки обойтись. Это я к тому, что помощь другой команды на самом деле не требуется, нужно лишь знать какие-нибудь языки кроме того "шелла".


        Кстати, забавно что в плюсы микросервисов обычно записывают то, что разные микросервисы могут писаться на разных языках разными командами, которые друг от друга не зависят. А потом какой-то скрипт на 20 часов не получается ускорить только из-за того, что понадобились действия от другой команды...


        1. zaqqq13
          13.08.2022 13:03

          Проблема в том, что на уровне конторы требуют юзать эту либу. Я понимаю что можно без нее, но тут есть ограничения по процессам и они явно не с потолка взялись)


    1. aim
      14.08.2022 02:30

      отличный коммент. что почитать чтобы вот Коля стал в программировании чуть больше понимать?


    1. IgorDev
      14.08.2022 09:40

      Сегодня индустрии вообще уже не нужны живые кодеры?


  1. s_f1
    12.08.2022 20:45
    +7

    3.5 миллиона результатов по запросу «научиться программировать»? Открываем оригинал и понимаем, что на английском учиться программировать ещё в 370 раз сложнее

    Скрытый текст
    image


  1. da-nie
    12.08.2022 21:01
    +12

    Когда я начинал (1994 год), я хотел научиться делать игры, подобные тем, в которые играл на ZX-Spectrum. Посмотрев на 386 в школе и найдя там паскаль, я начал учить и его. Ну и QBasic заодно (после Spectrum-basic). Дальше, узнав про DooM и Quake и увидев их, я начал изучать C++ чтобы создать свою такую игру. Для того, чтобы тонко управлять компьютером (писать всякие обработчики прерываний и грабберы экранов в DOS) я начал изучать ассемблер x86 (зная уже асм Z80 с прерыдущей операции). Дальше — Open GL 1.x. А вот потом уже я пошёл работать (2005 год), где при разработке ПО к стендам и устройствам мне пригодилось всё, что я изучал на предыдущих шагах. Итак, была мотивация и интерес, заключавщиеся вовсе не в том, чтобы «войти в IT» (я формально в него и не вошёл) и загребать бабки. А какая мотивация у Коли? Ради чего Коля всё это пытался изучить? Ради получения работы в IT? Так может, Коле всё это было противно учить и, что самое интересное, он изученное нигде и никогда не применял?


    1. Metotron0
      13.08.2022 10:57

      Разве "хочу написать такую же игру" не выглядит, как что-то одноразовое?


      1. da-nie
        13.08.2022 11:55
        +1

        На то это и цель, чтобы достигнув её, достигать следующей. Иначе какой смысл в повторении уже пройденного этапа? Сделав DooM (а я его сделал, кстати в 2001 году), хочется сделать Quake (а вот тут я не смог в редактор карты — не представил, как в 3D всё это рисовать по полигонам, а потому осталась только софтверная 3D библиотека с текстурированием, но без 3D-BSP-дерева и физики), а не повторять этот DooM до бесконечности.


      1. saboteur_kiev
        13.08.2022 13:20
        +1

        За первой тут же следует вторая.


  1. Daddy_Cool
    12.08.2022 22:02
    +31

    Краткое содержание статьи:
    1) Всё новое сложно.
    2) В конце концов вы справитесь, если будете этим заниматься.


  1. nikolas78
    12.08.2022 22:05
    +1

    А все остальное значит легко?


  1. MAXH0
    12.08.2022 22:59
    +1

    Мне, как учителю, однозначно в избранное.


  1. AllKnowerHou
    12.08.2022 23:04
    +1

    Забавно, а я в айти так и не зашел, хотя прошло уже 8 лет - как я пытаюсь выучить хоть что-нибудь


    1. zaqqq13
      13.08.2022 09:04
      +2

      За 8 лет можно стать сеньором если учить системно и упорядоченно, плюс практика. Ну или эти 8 лет можно потратить чтобы 5 лет отучиться в вузе по специальности, и еще 3 года останется чтобы устроиться на работу и дорасти до middle+ спокойно. Вы что-то делаете не так


      1. IsUnavailable
        13.08.2022 14:14
        +7

        Возможно он работает ( ͡° ͜ʖ ͡°)


      1. AllKnowerHou
        14.08.2022 19:11

        Так я тогда и закончил учиться в вузе


    1. ArkadiyShuvaev
      13.08.2022 13:29
      +6

      Забавно, а я в айти так и не зашел, хотя прошло уже 8 лет - как я пытаюсь выучить хоть что-нибудь

      Всё ОК, не вы один такой :)

      Я в ИТ официально с 1998 года. свой первый сертификационный экзамен от IBM сдал ещё в 2005. После уже сдал несколько экзаменов от Microsoft и AWS.

      До сих пор джуном себя считаю, перед собой вижу бездонное море :)


      1. ReadOnlySadUser
        14.08.2022 13:49
        +2

        Да и я вот уже лет 6 в профессиии и 9 лет как впервые написал hello World. Работаю на какой-то работе, получаю свою сеньорскую зарплату, но чёт до сих пор в пустыне отчаяния нахожусь)


    1. wormball
      15.08.2022 00:41

      Это ещё что! Я свой хелло ворлд написал во втором классе (30 лет назад) и до сих пор даже до джуна не дорос. Хотя вроде как желание, об котором здесь так долго говорят большевики, было. И биолог я приблизительно настолько же квалифицированный, как и программист, несмотря на то, что закончил биофак МГУ.


  1. mvv-rus
    12.08.2022 23:14
    +3

    Я много читаю про нынешнюю индустрию IT, и одна вещь мне до сих пор кажется непонятной: почему индустрия не может задействовать специалистов, так сказать, низкого уровня — прошедших определенный курс обучения, умеющих делать простые задачи, но не ставших полноцеными специалистами высокго уровня?
    Если говорить в терминах этой статьи, то почему производство ПО не может извлечь пользу из тех, кто прошел первичное обучение и попал в «пустыню отчаяния». Ведь если бы их удалось задействовать, то эти специалисты — достаточно дешевые благодаря их низкой уверенности — могли бы приносить немалую прибыль производителям ПО. А
    То есть, если говорить в терминах цехового ремесленного производства, почему индустрии IT обязательно требуются мастера, а не подмастерья? Ведь, как известно, в процессе развития от цехового ремесленного к промышленному производству промышленная индустрия научилась эффективно задействовать подмастерьев в рамках мануфактуры — ещё до массового внедрения машин. Почему же индустрия IT не может проделать то же самое?
    Связано ли это с недостаточной зрелостью индустрии, или же с особенностями производства ПО, не позволяющими выделять сколько-нибудь массово простые задачи, доступные специалистам прошедшим базовое обучение? Последнее мне странно, ибо тот же CRUD, которого почти на любом проекте пруд пруди, прост до безобразия, делается стандартными средствами и не требует каких либо продвинутых умений, типа знания алгоритмов.
    PS Это — вопрос: в этом комментарии я ничего не утверждаю, а лишь выражаю свое непонимание. И я с радостью прочитаю любые попытки ответить на эти вопросы.


    1. Hardcoin
      12.08.2022 23:41
      +8

      По той же причине, по которой не выйдет задействовать недо-хирургов, прошедших курсы или недо-пилотов самолётов, посидевших за штурвалом.

      Спрос на миддл-разработчиков, которые могут заниматься тем же самым CRUD, достаточно высок. Но он требует знания, например, паттернов, с которым у джунов плохо.


      1. mvv-rus
        12.08.2022 23:50
        +3

        По той же причине, по которой не выйдет задействовать недо-хирургов, прошедших курсы или недо-пилотов самолётов, посидевших за штурвалом.

        Практически во всем IT эта причина — ошибка опасна для жизни других людей — отсутствует. Так что на правильный ответ это не похоже. Ну и чисто мануальных навыков — которые важны и для хирургов, и для пилотов — для разработчиков не требуется: там достаточно только нажимать на кнопки, и не обязательно — в нужный момент.
        Но он требует знания, например, паттернов, с которым у джунов плохо.
        Ну, джуну тут потребуется скорее знание стиля написания кода (AKA codestyle). Но даже и паттерны — это вещи вполне формальные, на выполнение которых вполне себе можно натаскать.
        Так что, все равно непонятно.


        1. goga_kk
          13.08.2022 14:22
          +3

          Я вам больше скажу. Человек выше привел еще одну кривую аналогию, которая не имеет ничего общего с действительностью и даже искажает ее.

          И пилоты и хирурги получаются из недо-, которых хотя бы попробовали сделать пилотами и хирургами, посадив в какой-то момент за штурвал и дав скальпель, под присмотром естественно.

          Мое сообщение впрочем не отвечает на ваш вопрос, но возможно причина того, что ищут сразу опытных в том, что многим проще не возится с недо-, а сразу взять специалиста, пусть это будет и дороже.

          Если свернуть немного в частности, то с разработчиками действительно скорее всего так, а вот с другими направлениями ИТ несколько проще и я знаю примеры организаций, где берут вчерашних студентов и даже на последних курсах, обучают за счет опытных сотрудников и оставляют наиболее успешных. Полагаю, что это выгодно, т.к. такая практика там многолетняя.


          1. vassabi
            13.08.2022 14:33
            +2

            Полагаю, что это выгодно, т.к. такая практика там многолетняя.

            конечно выгодно - но только если владелец бизнеса строит долгосрочные планы.

            Основные выгоды - увеличение лояльности (текучка все равно происходит, но меньше + реклама "тут набирают студентов"), увеличение компетентности синьоров ("пока им рассказывал - сам уже понял"(с)), подержка инициативности (выросшие работники гораздо более активны, чем "готовые"), внедрение новых практик и фреймворков (а на ком еще, как не на студентах??)


        1. ReadOnlySadUser
          14.08.2022 13:55

          Практически во всем IT эта причина — ошибка опасна для жизни других людей — отсутствует.

          Да, но есть другая - ошибка в ПО может стоить бизнеса. Или просто очень больших денег. Так что тут всё плюс/минус корректно.


          1. mvv-rus
            14.08.2022 15:09

            Нет, таки есть разница: бизнес в состоянии оценивать риски (по крайней мере должен: это прямая должностная обязанность бизнесменов), а простые люди — пациенты или пассажиры — с рисками иметь дело не должны.


            1. ReadOnlySadUser
              14.08.2022 15:35

              Так и в медицине так-то риски вполне себе оцениваются. И хуже того, пациентов обязаны с ними ознакомить, а значит и финальное решение принимают сами пациенты.


              1. mvv-rus
                14.08.2022 16:16

                Мне тут сложно с вами спорить. Потому что лично я считаю, что человек действительно сам, как может, отвечает за себя и все связанные с этим риски, но у многих других людей, и, главное — у государственных регуляторов мнение другое: за риски простые люди отвечать не должны, за них должны отвечать только специально обученные люди (ну, или не обученные, но выбравшие такой род деятельности, в котором риски являются неотъемлемой части). Короче, нынешнее общество сильно ориентированно на безопасность, и это факт.
                Так что мне сложно отстаивать точку зрения, которую я не разделяю, но которая, тем не менее, объективно является доминирующей. Так что я всего лишь ограничусь упоминанием о ней (в предыущих комментариях).


      1. php7
        13.08.2022 15:09

        Дам совет на своем опыте начинающим, скорее даже самоучкам. Как с этим у дипломированных специалистов хз, я таких не встречал.

        Не старайтесь применять паттерны, ООП и прочие модные слова, потому что так кто-то говорит.

        Применяйте их по надобности.


        1. vadimr
          13.08.2022 17:32
          +1

          Конкретно паттерны – это наименование для того явления, которое возникает в практической деятельности само по себе. Можно назвать просто знанием жизни.


    1. AlexSteelax
      12.08.2022 23:50
      +12

      Ну смотрите, минимум один факт.
      Джун пишет код на 1000 строк за Nчасов, который местами некорректно, медленно (вставить нужное) работает. Синьор пишет функционально соответствующий код на 100 условных строк за N/10 часов, с которым все ок.

      Вот и выходит, что джун крайне не выгоден на ближней и с редней дистанции. И куда выгоднее и дешевле нанять мастера, чем ораву джунов.

      Типовые задачи - это миф. Задачи становятся типовыми только тогда, когда специалист достаточно высокого уровня организует рельсы для этой "типовости", по которым можно пустить вагоны с джунами.


      1. mvv-rus
        13.08.2022 00:03
        +1

        Что-то я слабо представляю себе, откуда такая разница возьмется на задачах типовых: CRUD или перегонка JSON в DTO для ORM и обратно.
        Ну, а уж медленно и местами некорректно — это, жалуются, вообще болезнь нынешнего ПО.

        Типовые задачи — это миф. Задачи становятся типовыми только тогда, когда специалист достаточно высокого уровня организует рельсы для этой «типовости», по которым можно пустить вагоны с джунами.

        Вот это уже больше похоже на причину. То есть, вопрос можно даже переформулировать: почему специалисты высокого уровня не организуют эти самые «рельсы» в рамках своего проекта? Их этому не учили, или это объективно невозможно?


        1. awfun
          13.08.2022 00:17

          Если хотят организовать, то организовывают. Достигается это унификацией стека и внедрением проверок на всех уровнях - автотесты, мониторинг и прочее. Далее разработка становится проще и может быть выполнена менее квалифицированными разработчиками.

          Также частично можно сократить сложность понимания бизнеса, например, составить словарь терминов.


        1. inkelyad
          13.08.2022 12:11

           Их этому не учили

          Да, не учили. Потому что индустрия еще не понимает, как этому надо учить. Все получается только у случайно дошедших до такого умения.


        1. arheops
          14.08.2022 14:52

          Да все просто. Вот у меня есть проект, в котором два джуна. Кажды второй таск они «решают», после чего ядро виснет намертво(есть таблицы на 2+млн записей), работа останавливается и вызвают меня, чтоб я поправил код или сказал, что это вообще надо убрать и делать подругому.
          Вот реально каждый второй коммит, и так уже два года.
          Толку то, что рейт этих джунов в 5 раз меньше, если они на каждые 4 часа требуют моего одного часа?
          + еще простой команды из 15 человек пока я пойму, что они сделали не так в данный момент.
          Вы скажите — тесты, dev environment. Ну так с тестами у них та же петрушка, и на деве они не находят ничего, а тестеров в бюджете — нету, мелкий бизнес.
          Потому когда задача критическая — ее просто дают мне и через день оно работает без всяких проблем и косяков для бизнеса.


          1. mvv-rus
            14.08.2022 15:19
            +2

            Вы скажите — тесты, dev environment

            Нет, я скажу, что вы много джунам позволяете в плане доступа к ядру: по уму тут нужна защита от дурака в виде ограниченного набора вызвовов, которыми джунам дозволяется пользоваться, и которыми они ничего не смогут напортачить, а все остальные способы доступа запретить (технически или под страхом наказания).
            Но это — однозначно, не для вашего мелкого бизнеса, делать такое ради пары джунов неоправдано. Разве что, взять готовую либу — но где они, такие либы?
            Так что ваш случай по моей классификации идет, похоже, по категории незрелости: нет удобный средств разграничения доступа для разработчиков.


        1. nmrulin
          14.08.2022 17:01

          Потому, что код с рельсами писать вдвое дольше, а иногда и больше. И не факт что это окупиться. Часто причём большой проект вырастает из маленького, который может быть вообще писал миддл не совсем стандартно/оптимально.


          1. inkelyad
            14.08.2022 17:11
            +1

            Тут вопрос не столько про код с рельсами, а про создание артефактов в виде "вот тут проложить дорогу/рельсы/электрокабель в соответствии с <отсылка на кирпич документации>". После чего оно по цепочке разворачивается и в результате кабель прокладывает тот, кто никакого понятия, как устроена вся электросеть города/завода/дома, не имеет и не может иметь потому что никогда этого не учил и не захочет.

            Вот почему-то в достаточно старых индустриях так делать (в достаточно многих вещах) научились, а в нашей индустрии -- как-то не очень.


      1. PereslavlFoto
        13.08.2022 00:45

        Немного уточним модель.

        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. Следовательно, синьора нанять в принципе невозможно, а джуна можно нанять с неполным рабочим днём, или можно доплачивать ему из зарплаты директора.

        Предложенная вами модель хорошо работает, когда есть много денег. Однако она ломается, если имеется лишь «мало денег» или ещё меньше.


        1. vlad4kr7
          13.08.2022 03:25

          Еще есть фулстек - четыре синьера в одном флаконе!


      1. Z2K
        13.08.2022 19:18

        А супер синьор пишет код из 3 строк за полчаса и который работает в 10 раз быстрее. Просто он знает название библиотеки - "Сделать хорошо и быстро" и где ее найти. Патерны однако. :) Все чень просто.


    1. SAWER
      13.08.2022 01:35

      В принципе можно. Писать тесты отправить, к примеру.
      Но если смотреть именно о задачах программирования, то это всегда новая задача, не похожая при первом приближении на прошлые. Это сами по себе задачи которые не поддаются простой автоматизации, т.к. если поддаются, то эта автоматизация и есть задача.

      Не для стажёров, настолько, что если это может сделать стажёр - значит это можно автоматизировать и заменить другим спецом(тестером, админом, манагером, техподдержкой и прочими).

      С джунами получше, но они крайне неудобны. Там где мидлу надо поставить задачу в 10 слов, для джуна надо писать абзац или страницу, в которых он ещё и запутается, либо поддерживать и проверять по ходу, а лучше всё вместе. Получается, что задачу именно по разработке в нужном качестве джун не выполнит сам в большинстве случаев. Т.е. можно дать только те задачи, которые вполне автоматизируются, но на которые нет времени, или жалко его тратить. Ну или по принципу применения - дать обособленную вещь, которую в случае проблем проще переписать, чем править и следить в большей части за рамками работы. Но так не достичь высокой эффективности.

      В соседней ветке был пример с DTO - это вообще мелочь по времени, больше возьни с объяснением что и для чего это и как этим правильно пользоваться, да и зачем. Для мидла это минуты, а для джуна - часы. Хотя тут и можно применить, только вот и это автоматизируется аж несколькими способами.
      А когда натаскаешь он будет уже мидлом)

      И ещё одна вещь - с сеньорами можно обсуждать программу свободно, не касаясь языка программирования вообще.


    1. inkelyad
      13.08.2022 12:10
      +2

      Связано ли это с недостаточной зрелостью индустрии, или же с особенностями производства ПО, не позволяющими выделять сколько-нибудь массово простые задачи, доступные специалистам прошедшим базовое обучение

      На мой взгляд - именно так. Никого из нас не учат и индустрия не умеет целенаправленно получать людей, которые "прокладывают рельсы", как тут рядом пишут. Причина, мне кажется - как раз в том, что настоящей инженерной специальностью (со всем принятым для нее обучением) наша профессия не является. Мы тут все наполовину самоучки и ни томов документации (c миллионом наименований нужных деталей, сборок, конструкций или что там еще бывает), ни нужных практик, которые требуются, например, для строительства какой-нибудь электростанции или буровой платформы -- не знаем. Да у нас даже нормальных справочников "хочешь артефакт с такими-то параметрами - делай его из того-то" нет.


    1. Fenzales
      13.08.2022 14:39
      +2

      Я много читаю про нынешнюю индустрию IT, и одна вещь мне до сих пор кажется непонятной: почему индустрия не может задействовать специалистов, так сказать, низкого уровня — прошедших определенный курс обучения, умеющих делать простые задачи, но не ставших полноцеными специалистами высокго уровня?
      Может, просто предложение на порядки превышает спрос.


    1. nmrulin
      14.08.2022 17:08
      +1

      Как раз по причине зрелости индустрии все проблемы. Раньше более точная квалификация была не джун-миддл-серьор, а хеллоувордщик-быдлокодер-программист. Так вот быдлокодер этот тот, кто в целом может выполнить задачу, но неоптимально, его код трудно поддерживать и т.д. Когда проекты маленькие, быдлокодер может , сделав несколько задач, потом стать программистом. Когда проекты становятся большими, то быдлокодер не нужен индустрии, а нужен джун, то есть тот , кто может сделать узкую и типовую задачу , но относительно качественно . То есть быть подсобным рабочим.

      Если проводить аналогии с медициной как это делают выше, нужна хорошая медсестра. А плохой врач , не нужен.


    1. Vitaly48
      15.08.2022 08:04

      Их как минимум задействуют во всяких студиях в которых клепают шаблонные сайты или мобильные приложения. В этих аутсорс компаниях обычно продают джунов под видом миддлов или синьеров


  1. Rebeiro1976
    13.08.2022 08:07
    -19

    да заели вы со своим айти, в каждой дыре уже, айти айти айти, больше нет ничего что ли? да схлопнется это все через 2 года, как обычно, реально уже раздражает


    1. PrinceKorwin
      13.08.2022 08:47
      +8

      Чтобы ИТ схлопнулось этому должны быть предпосылки. Например уход от цифровизации, уход от электронного документа оборота, уход от цифровых схем контроля, уменьшение количества гаджетов у людей, уход от использования компьютеров в работе учёных и так далее.

      Пока нет ни одного намека на то, что что-то там в ИТ схлопнется.


    1. telpos
      13.08.2022 09:22
      +14

      10 лет читаю этот комментарий


    1. Hivemaster
      13.08.2022 09:30
      +24

      Странно на ИТ-ресурсе жаловаться, что тут про ИТ. Не находите?


      1. MTyrz
        14.08.2022 22:44

        После открытой регистрации — неа, не странно.


    1. General_Failure
      13.08.2022 10:22
      +33

      Пойду на порнхаб схожу и буду ругаться в комментариях, что там все трахаются на камеру, затрахали уже


  1. Borjomy
    13.08.2022 08:46

    Ничего не увидел про конечную задачу, которую этот программист хочет решать. Язык программирования - это только инструмент. Мало кому нужен джун, который хорошо знает ЯП и фреймворки. У него ещё и мозги должны иметься. А это означает, что он должен быть специалистом в той области, для чего пишет ПО. И чем дальше, тем больше. От частного к общему. Овладевать инструментом, не имея задачи - бессмысленная трата времени. Именно поэтому у Коли столько проблем и выгорание.


  1. Zara6502
    13.08.2022 09:32
    +7

    Сегодня огромное заблуждение про программирование как про что-то простое и доступное, а это не так.

    Я очень хотел программировать в 80-е и я это делал на Atari, в 90-е на 80286, Clipper, Fox Pro, Turbo C, потом Delphi и потом заметно позже (20 лет) на C#, и я понял только одно - мне не нравится быть механическим кодером и долбить код ради кода или автоматизации какой-то фигни. И да, я плохой кодер, потому что у меня плохая память, если я неделю не пишу на C# то я не могу прочитать собственный код. А нравится мне творческий процесс, поэтому я занимаюсь теперь простой административной работой, а для души пишу на ASM 6502 для Atari. Чтобы это понять - понадобилось 30 лет.

    Коля молодец раз за три месяца прогнал через себя столько информации, я только вводную книгу по Питону читал 8 месяцев и понял что он мне не нужен, так как я уже пользуюсь C# которого мне хватает.

    И он всё делал зачем? Ради денег? Чего я в жизни тоже понял - если ты устраиваешься на работу ради денег и не получаешь удовольствия от процесса, это будет адом и не важно сколько платят, так как депрессия гарантирована.


    1. oleg808
      13.08.2022 13:50
      +1

      Большинство людей работают ради денег, а сама работа им не нравится. Удовольствие от процесса получают единицы. Мне кажется наивным предположение, что все должны обязательно найти "что-то своё", так не получится.


      1. General_Failure
        13.08.2022 16:23
        +3

        Работа разная бывает. Махать лопатой или отбивать покупки на кассе можно делать с ненавистью к этому занятию. Прогать так не очень выйдет.


        1. ReadOnlySadUser
          14.08.2022 14:19
          +6

          Да ничего, вроде последние года 4 справляюсь. Точнее как. Я поначалу это дело любил, потом возненавидел, потом перегорел. Сегодня программирую с нулевым интересом к процессу. Мне плевать что программировать, на чем программировать, и уж тем более плевать на то, меняю я мир или не меняю. Лучшая работа та, на которой надо меньше делать за больше денег.

          И, внезапно, такой подхол к работе сделал меня куда более ценным сотрудником, чем я был. Теперь я смотрю на задачуэи по принципу: "как мне из А получить Б", а не "как классно, можно будет поковыряться во фреймворке Х, пока я делаю задачу". Я делаю задачи не так, как мне нравится, а так, как понравится тем, кто эти задачи будет принимать, чтобы потом больше не делать нечего. Я автоматизирую вещи, которые меня откровенно достали (а достает мне многое), а не те, которые весело автоматизировать.


    1. vadimr
      13.08.2022 14:12

      Поставил Вам +1 в карму за 6502, но так и не понял, что в вводном курсе по питону изучать 8 месяцев. Зная некоторое количество других языков и купив нормальную книгу по питону (формальное описание, а не “Питон для чайников”, которое я выделил из других книг по наличию разделов с названиями вроде “Лексическая структура языка” в содержании), я смог писать на нём практически применимые программы через 3 дня ненапряжного чтения. Это вам не предындексная косвенная адресация с индексацией по X, в питоне всё проще.

      Другое дело, что вообще кодирование в нашем возрасте уже обычно не очень торкает.


      1. Stronczzz
        14.08.2022 09:20

        купив нормальную книгу по питону

        Чем хуже официальный стандарт описывающий язык?


        1. vadimr
          14.08.2022 09:36

          Обложки нет.

          А так вообще стандарт не является учебным материалом.


          1. Stronczzz
            14.08.2022 09:58

            Так вы же находитесь на таком уровне, когда и куча языков в бэкграунде и опыт как-никак, зачем вам какие-то разжёвывающие книжицы?

            Это я вот к чему:

            но так и не понял, что в вводном курсе по питону изучать 8 месяцев

            Потому что неайтишник работает на основной работе, у него ещё есть жена, дети, ипотека, друзья, родственники, пожилые родители, а на изучение языка в качестве хобби остаётся хорошо если часик-другой в неделю.


            1. vadimr
              14.08.2022 14:26

              Все бы такие были неайтишники, со знанием ассемблера 6502.


              1. Stronczzz
                14.08.2022 22:22

                Тогда обычные кодеры были бы вообще не нужны ))


      1. oldbie
        14.08.2022 22:29

        Торкает! Возрастные изменения, как и интересы, индивидуальны.


    1. DvoiNic
      15.08.2022 09:46

      Бывает и наоборот — когда от административной работы воротит, и уходишь с руководятлов…


  1. Azrak
    13.08.2022 09:33
    +2

    А почему научиться рисовать так сложно? А почему научиться строгать так сложно? А почему научиться быстро бегать так сложно? А потому что, у кого-то это получается легко и просто и есть возможность и расположенность, а у кого-то нет? Посадите меня рисовать с циркулем и линейкой и дайте 10 лучших наставников, но не выйдет Айвазовский. Может не надо заниматься ремеслом, к которому не лежит душа?


  1. bmikhail
    13.08.2022 11:07

    Это прям про меня, спасибо за статью! Я за полгода изучения пайтона на супер разрекламированных курсах дошел до скалы растерянности. Понял, что все "слишком сложно" и надо "опустить планку". Начал копать фронтенд самостоятельно. За год дошел до пустыни отчаяния, причем даже получил стажерскую позицию в одной компании, промучившись месяц с первым заданием, бросил, так как срок "вхождения в it" в целом , уже пугал. Теперь изучаю тестирование, очень жаль потраченного времени, но, надеюсь, знания пригодятся в автоматизации.


    1. nmrulin
      14.08.2022 16:55

      Ну если вы год продержались, значит у вас безусловно есть определённые способности к программированию.

      Создайте какой-то проект для себя, так видно будет. Может вам не фронтенд нужен, а бекэнд, а может desktop. Или разработка мобильных приложений. На самом деле не так много надо времени , чтобы по каждому направлению что-то наваять, уж точно не год.


  1. victor79
    13.08.2022 13:31
    +1

    Программировать не сложно. Сложно делать это лучше чем другие. Чем дальше хочешь забраться, чем больше хочешь получать за это или от этого, тем сложнее.


  1. vadimr
    13.08.2022 14:04
    +1

    Очень много букв и цветных рисунков для пояснения обычной S-образной кривой применительно к процессу обучения.


    1. vassabi
      13.08.2022 14:16

      1) какая еще S-образная кривая??

      там показана только первая волна неуверенности в море изучения и практики языков программирования.

      Таких S-образных кривых : выходит новая версия фреймворка, новая ОС, новый язык программрования, новое устройство (или вы думали что андроид и айфон - были всегда?), новая процессорная архитектура - тут просто на каждом углу.

      2) лично меня в той кривой больше всего смешит что этап "работать в команде" стоит до "готов к работе". ИМХО если человек работает в команде и приносит своей работой пользу этой команде - то он уже готов к работе.


      1. vadimr
        13.08.2022 14:19

        Ну правильно, S-образные кривые сопрягаются между собой. Хотя вообще по поводу перечисленных вами событий особых заморочек у опытного специалиста уже не возникает.

        Не могу себе представить, чтобы квалифицированный программист испытал “пустыню отчаяния” по случаю появления нового фреймворка или процессорной архитектуры.

        По поводу работы в команде. Если процесс сложный, то сотрудник некоторое время работает в команде, не принося ей пользы. Больше ресурсов тратится на его обучение, чем приобретается в итоге его труда.


        1. vassabi
          13.08.2022 14:26

          это когда уже есть развитая инфраструктура и нет старого кода.

          А когда swift вышел вчера, а у вас куча кода на Objective-C , или когда одним махом переехали на arm64 (а у вас куча кода на arm32), или когда у вас годы кода на питоне2, а теперь пора переучиваться и переезжать на питон3 ...


          1. vadimr
            13.08.2022 14:34

            Ну проходят это всё много раз, в том и работа программиста. Импортозамещение вот ещё, с macOS на Astra Linux тоже неплохо заходит.


  1. Fen1kz
    13.08.2022 14:30
    +1

    А я считаю что это сложно потому что нет нормальных туториалов и курсов. Все они построены по одной схеме, знаете, мем такой ещё есть:


    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 с потоками


    Так блин, даже до такой "средней" технологии типа "давайте сделаем менеджер потоков" курсы не доходят.




    В общем эти ваши впадины отчаяния вызваны тем, что обеспечивается шикарная поддержка начальных навыков логики типа "если Х, то У", а вот уже не начальные, но всё равно базовые навыки почему-то нигде не объясняются.


    1. vassabi
      13.08.2022 14:37
      +2

      ну, это уже не совсем "базовые вещи", но акторы, или потоки, или машина состояний - это можно изучать в вашем основном языке программирования - не нужно залазить в скалу или питон.


  1. nikolas78
    13.08.2022 14:59
    -3

    Да не переживайте, скоро low-code/no-code вытеснит всех джунов.


    1. vassabi
      13.08.2022 18:19
      +4

      low-code/no-code вытеснит всех джунов.

      не всех джунов, а джунов программирования

      на их место придут джуны low-code/no-code , из которых будут вырастать синьоры low-code/no-code !

      (а еще раньше были джуны машинных кодов, потом были джуны ассемблеров)


    1. nmrulin
      14.08.2022 17:18
      +2

      Я 25 лет назад также слышал, что Delphi вытеснит нормальных программистов, будут все формочки клепать.


      1. mvv-rus
        14.08.2022 18:02

        Конкретно у Delphi было одно большое (на мой взгляд) достоинство по сравнению с другими тогдашними средствами RAD(так тогда программы для клепания формочек называли), типа PowerBuilder: универсальность — на нем можно было писать и куда менее визуальные программы. Я, например, на нем сервисы Windows(т.е. фоновые программы, работающие без участия пользователей) для работы с распределенной по филиалам БД на Interbase писал. Не на C — потому что bus-factor: мой единственный коллега был экспертом в Delphi, но вот C он знал очень приблизительно, и не любил его.


      1. nikolas78
        15.08.2022 12:17

        Кто знает… Если бы Хейлсберг не ушел в MS, то возможно большой процент разработчиков этим бы и занимались.
        Кстати холивара ради, учащающиеся сетования на ужасный код происходят как раз из-за того, что подходящего инструмента для «клепания формочек» у разработчиков пока нет.


  1. php7
    13.08.2022 15:04
    +2

    Оффтоп:

    На самом деле результатов не 3M+, а максимум 300, и то в конце нерелевантный мусор


  1. dvoeglazyi
    13.08.2022 20:44
    +2

    Прикололся с ваших талантов в области "локализации".

    "Он начинал с изучения 1С, но затем вернулся к истокам, пройдя беглым взглядом по другим языкам, таким как Рапира, ДРАКОН и КуМир."


    1. DvoiNic
      15.08.2022 13:01

      это откуда?


  1. Alpenveg
    13.08.2022 23:23

    Как раз встал на этот путь, поэтому интересно было почитать статью. Надеюсь не застряну на скале и не останусь в пустыне :)


  1. Mayari
    13.08.2022 23:27

    True story, bro.


  1. sappience
    14.08.2022 03:28
    +4

    Статья заявлена как перевод, но это какой-то странный перевод. С "адаптацией к местным рыночным условиям", видимо.
    Оригинал:

    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 самым нежным прикосновением убеждают тебя, что ты тоже (кто угодно!) сможешь не только научиться программировать, но и стать полноценным разработчиком.


    1. sasha1024
      14.08.2022 07:15
      +3

      Именно! Я тоже офигел. Это пересказ, а не перевод. (В лучшем случае; а в худшем — это намеренный продакт-плейсмент.)

      • движение «Войти в АйТи» — 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 (по крайней мере в оригинале фраза о том, что Квинси Ларсон получил работу в разработке, является гиперссылкой на статью именно того Квинси Ларсона, где он в том числе вспоминает, как впервые получил должность разработчика).


    1. astenix
      14.08.2022 10:05

      Это та самая безалаберность и всеобщая условность, из-за которой на плакате к 9 Мая, не заморачиваясь, лепят фотки тогдашних условных противников, и про которую так яростно говорил капитан (Виталий Хаев) в фильме «Изображая жертву».


  1. ryo_oh_ki
    14.08.2022 09:59

    Этот график "уверенность-компетенция" назойливо переползает из одной тренировочной статьи в другую, причём в разительно отличных друг от друга предметных областях. И складывается ложное впечатление, что он правдивый хотя бы из-за того факта, что, благодаря прогрессу, необходимые компетенции бесконечно растут, и, фактически, крестик "готов к работе" не стоит на месте. Более того, люди, осуществившие революционные инновации, включая редкие выстрелившие стартапы в ПО, очевидно обладали 100% уверенностью вне зависимости от компетенции - "все знали что так нельзя, а они не знали и получилось".


  1. astenix
    14.08.2022 09:59
    +1

    Программистов я не учил, я по тестировщикам. Но ключевые принципы одни.

    Проблема курсов ВООБЩЕ как раз в том, что они делают только первый этап (заботливый медовый месяц, или как вы там придумали), затем говорят «муахаха!», пинают под зад и оставляют в одиночестве преодолевать все дальнейшие падения и взлёты. Да, в Спарте всех слабых младенцев сбрасывали со скалы, это делало их смелыми и сильными. Но мы не в Спарте.

    Ученика надо провести по всем этим холмам и долинам уже в контексте курса. Надо дать ему ощутить себя сильным (заботливый медовый месяц, my ass), не мешать ему испугаться дальнейшего, быть рядом, когда он начнёт хныкать или реветь, помочь подняться и шагать вместе с ним дальше, пока он не начнёт идти самостоятельно и без страха.

    Учить этому не очень-то и легко, но можно и нужно. И под «учить» подразумевается не рассказ о том, что есть, например, всякие техники тест-дизайна, но это вы сами когда-то сможете узнать, «если на проекте понадобится»… Надо учить думать и не бояться неизвестного, а не техникам тест-дизайна отдельно или как писать репорт о дефекте отдельно. Человек даже в среднем не дурак, сам придумает, как репорт написать, если сперва будет понимать, что это и зачем это нужно.

    Минус в том, что мозг начинает перестраиваться только через три месяца токсичного принуждения занятий, и надо как-то умудриться не потерять ученика за это время. Некоторые таки теряются.


  1. Yukr
    14.08.2022 12:59
    +2

    сложно или не сложно - сильно зависит от источника знаний, имхо. В школьные годы увлекался паянием электорнных поделок по схемам в "Юном Технике" (светлая ему память!), и всё ждал, когда смогу подложить теорию под практику, и понять - почему мультивибратор так работает и как придумать схемы самому. Как же меня взбесило, когда я понял, что фраза из учебника по физике "транзистор усиливает сигнал" не верна по сути! Усилие - это когда я, откручивая ржавую гайку, наваливаюсь на гаечный ключ всем телом. А транзистор не усиливает, а повторяет сигнал с большей амплитудой!!! и только в таком варианте становится понятен принцип работы. или я один такой придирчивый? )))


    1. mayorovp
      14.08.2022 13:35
      +1

      Но ведь повторение с большей амплитудой — это же и есть усиление...


      Проблема с этой фразой — в другом. Сигнал — это вообще не физическая величина, в электроцепи нет никаких сигналов, а есть токи и напряжения. Одна из этих величин на наш выбор может стать носителем сигнала, но транзистор про этот выбор не знает, и работает по своим законам.


    1. nmrulin
      14.08.2022 16:38

      Ну почему усиление считать только механически? Тем более и в механике усилие и усиление две разных вещи. Усиление, это когда с помощью рычага человек может поднять груз в тонну и больше.


    1. ReadOnlySadUser
      14.08.2022 17:02

      Меня лично усиление сигнала всегда ломало мозг, ведь у нас есть закон сохранения энергии. Раз в замкнутой (!) цепи сигнал усилился, значит где-то он должен был взять энергию, но где?


      1. arheops
        14.08.2022 18:07
        +1

        Из цепи подкачки/батарейки.


        1. ReadOnlySadUser
          14.08.2022 18:45

          В таком случае на источнике энергии должен формироваться такой же сигнал, но инвертированный по фазе, но этого не происходит


          1. arheops
            14.08.2022 19:29
            +2

            Ну тут все просто. Эти все схемы питаются от постоянного тока и перед схемой накачки стоит конденсатор. Который сглаживает пики и вы получаете просто текущий ток.
            Но вообще да, на блоке питания будет картина зависящая от сигнала и в некоторых схемах типа военных ставятся два БП и дополнительные конденсаторы-соленоиды чтоб убрать зависимость, которую кто-то может считать.


          1. mayorovp
            14.08.2022 19:42
            +2

            Вообще-то, ещё как происходит, и на этом даже основано направление атак на аппаратные криптотокены.


      1. vassabi
        14.08.2022 18:32

        так ведь сигнал - это же абстракция, сигналом может быть может быть 1)ток 2)напряжение 3)частота 4) что-то еще


        1. ReadOnlySadUser
          14.08.2022 18:55

          Это не так чтобы корректное объяснение.

          У нас есть носитель сигнала (ток, напряжение), у которого есть характеристики (амплитуда, фаза, частота). Изменяя характеристики мы сигнал кодируем. Соответственно изменяя одну из характеристик, мы меняем и регистрируемый на другом конце сигнал.

          Проблема в том, что изменение чего либо в цепи требует энергии. Но тут сразу прикол в том, что получается эту энергию надо откуда-то взять. Но чесслово из схемы транзистора не очень понятно откуда эта энергия берётся)


          1. arheops
            14.08.2022 19:30
            +1

            Смотрите на это как на затвор в водном потоке. У вас есть поток, один сильный один слабый. Слабый нажимает на затвор и открывает сильный. По сильному не видно, ибо выше затвора — пруд накопитель(конденсатор).


            1. Yukr
              15.08.2022 00:20
              -1

              Совершенно верно. Я хотел подчеркнуть, что напряжение на входе и на выходе транзистора имеют разные источники, а термин усиление подразумевает действие над одним и тем же обьектом


              1. arheops
                15.08.2022 00:33
                +1

                Ну так у любого усиления тогда «разные источники».
                К примеру, когда вы механически станком усиливаете управляющее воздействия от рук — источник — двигатель станка.


                1. Yukr
                  15.08.2022 05:27

                  Нет, не совсем так. Руки и станок разные обьекты. Вы же не можете сверлить, точить или фрезеровать рукой. А обьяснение в учебнике говорило об усилении транзистором сигнала - одного и того же обьекта.получалось, как если бы река втекая под мост, была шириной допустим 5 метров а вытекала из-под моста уже 50 метров.


                  1. arheops
                    15.08.2022 05:34

                    Усилитель — устройство для увеличения энергетических параметров сигнала с использованием энергии вспомогательного источника(питания)


                    В случае с копировальным станком или экзоскелетом это все тот же усилитель, почему нет. Вот если станок будет работать без начального сигнала или экзоскелет будет по программе работать(роботом), тогда уже будет НЕ усилитель.
                    А так токарный станок — классический усилитель. Ну и что, что сигнал с поступательного на руке переходит во вращательный, это просто «взаимно-однозначное отображение пространства».
                    Вот конь, к примеру, усилителем НЕ является. Поскольку сам своим мозгом решает, куда вообще ноги ставить и идти ли туда, куда вы направили. А обычный блок веревочный — является, с коэфициентом усиления 1 и коэфициентом преобразования от единицы.


                    1. Yukr
                      15.08.2022 06:01

                      Хорошо, пусть так. Я привел пример того, как важна формулировка для понимания сути.это все-таки был учебник для 9 класса.

                      Кстати, еще напомнило: когда я учил геометрию, треугольники были "равны" между собой , а мой брат учился на 6 лет позже, так у него треугольники были " конгруэнтны". )))


  1. SensDj
    14.08.2022 16:46

    программирование можно сравнить с проектированием полностью роботизированных заводов, мелкие программы - мелкие примитивные механизмы, большие - куча взаимосвязанных станков. Станки можно брать готовые, а можно проектировать самому. Да и даже в готовых иногда приходится ковыряться, что-то исправлять, разбираться как работают


  1. nmrulin
    14.08.2022 16:49

    Я поэтому , разрабатывая курс в самом конце сделал мини проект, чтобы человек так сказать прочувствовал.

    А вообще падение "плотности информации" есть на любом уровне. Помню как-то надо было сделать ONVIF сервер. До этого не был знаком даже с SOAP. Первый вариант был реализовать на Delphi , в котором как казалось опыта достаточно. По итогу оказалось там есть достаточно мощные штуки вроде кодогенераторов, но в целом клиент можно было реализовать и неплохой, а сервер было не реализовать никак. По крайней мере в версиях до XE7, возможно сейчас они что-то улучшили, но на 99% нет. Возможно кто-то в мире и реализовал таки на Delphi и причём без обращения на совсем уж низкий уровень, но я об этом не знаю.

    В то же время на gsoap конечно же всё получилось. Потому, что как раз по "плотности информации" это решение наилучшее.


  1. SergeyProtector
    14.08.2022 19:05
    -1

    Почему программирование путают с кодированием? Для программирования надо знать высшую математику, алгоритмику, основы дискретной математики, принципы построения ОС, основы и принципы работы сети и многое другое... Язык программирования - вторичен. А для кодирования первично и важно только язык программирования.


    1. OlegZH
      14.08.2022 23:50

      Сразу возникает два вопроса:

      1. Неужели Вы не встречали довольно успешных программистов, которые не знают толком высшую математику, алгоритмику, принципы построения ОС и т.п. вещи?

      2. Что Вы можете "закодировать", не зная "программирования"?

      По-моему, это довольно формальное разделение и противопоставление. На самом деле, программирование очень часто оказывается довольно рутинным предприятием, но для этого существуют более глубокие причины. Во-первых, когда нужно решать задачу, её решают неким типовым методом и при помощи типового и программного обеспечения. Во вторых, в программистской рутине нет места для теоретических изысканий. Практика — отдельно, а наука — отдельно. (Даже на "Хабре" аналитических статей стало существенно меньше чем было раньше. По моим ощущениям, разумеется.) В-третьих, программисты сами превращают любимое программирование, в пресловутое "кодирование", потому как во главу угла ставится решение конкретной спущенной сверху задачи, а не творческое и увлекательное решение практической проблемы. Ведь, это это очень удивительно, что толпы программистов каждый день решают одни и те же задачи, которые, по идее, должны были быть решены уже -дцать лет назад. Вот и приходится кодировать, то есть использовать некий набор инструментов (построенных вокруг конкретного языка программирования). Хотя... было бы гораздо интереснее, например, написать один раз универсальный движок для всех торговых площадок и построить единую инфраструктуру для ведения торговли.


      1. arheops
        15.08.2022 00:36

        Я видел «сильных программистов» которые на полном серйозе доказывали, что их идея с поиском мини-макса в таблице на 100тыс в коде на php — крутая. Несмотря на то, что sql с той же задачей справлялся в 10000 раз быстрее.
        Ну вот просто они «не знали толком» основы БД. А так сильные были, сами написали систему работающую на уровне области(30+ предприятий).


  1. Aleks_ja
    14.08.2022 22:30

    Вас ждёт успех - если вы "фанат" программирования. И не будет никаких "далин". Будут только интрересные новыя открытия.


    Как стать "фанатом"? ) Прежде всего найти специализацию своей мечты - AI, сайты (фронт или бэк), мобильные игры или приложения, Internet of Things, либо какая-нибудь крутая сфера, которая вас вдохновляет...

    Если вы не "фанат", тогда будут "пустыни отчаяния" и тому подобное. В итоге максимум станете этаким трудоголиком с ограниченным креативом и ограниченным профессиональным развитием.


  1. OlegZH
    14.08.2022 23:32

    При изучении любого предмета всегда есть такой момент, когда Вы узнаёте что-то очень важное и существенным образом продвигаетесь в своём развитии. Знать бы это заранее. Можно было бы наломать меньше дров. Но, может быть, очень важно наломать дрова:

    И опыт — сын ошибок трудных.

    С другой стороны, вполне возможно, что без некоторых вещей можно было бы обойтись. Вот, Вы, специалисты, могли бы придумать более прямой и короткий путь познания Вашей специальности, чем тот извилистый путь, который был у Вас самих?


  1. IvanSTV
    15.08.2022 09:32
    -1

    Тезискно:

    • в целом в обществе статус образования в целом просел относитеьно советского. Если в советское время обраование было делом статусным и реально открывало социальные лифты куда угодно, то в настоящих условиях образование никому ничего не гарантирует. Горизонтальной карьеры нет. Вертикальная ограничена. Частные собственники отбирают кадры не по компетенции в первую очередь, а по иным соображениям - непотизм, клиентелла, взятки (лично мне предлагали купить место в таможне) все как в Древнем Рима

    • в связи с этим падает и культура обучения. Школьник не может поднять свой статус в коллективе учебой, в резульате имеем эффект, что выпускники не имеют даже достаточного НАВЫКА ЧТЕНИЯ УЧЕБНОЙ ЛИТЕРАТУРЫ.

    • ЕГЭ открыла дорогу в ВУЗы для откровенно слабо подготовленных абитуриентов. Почему все регионы молятся на ЕГЭ? Именно потому, что с уровнем задрищенской средней школы в МГУ по релаьному конкурсу знаний в жизнь не попасть, а по баллам ЕГЭ - вполне можно. Отсекая личные усилия по подготовке к экзаменам в ВУЗ, отсекли и выработку навыка самообразования.

    • в обществе в целом в области духовной культуры господствует попса, то есть, воинствующий антиинтеллектуализм. Какой-нибудь очередной моргенштерн несет агрессивную глупую матерщину - и это считается нормальным. Критерием успеха является только куча бабла, и мы видим, что эта куча бабла оседает не в карманах самых умных, а в карманах самых пройдошливых. В таких условиях интеллектуал всегда в загоне, и не имеет авторитета, чтобы ему стали бы подражать.

    • Как итоговый результат мы имеем уже вполне свормировавшийся социум, где в основной массе люди НЕ УМЕЮТ УЧИТЬСЯ и не имеют общих знаний для базы.

    • логично, что трудно научить чему-либо того, кто учиться не умеет.

    Боже мой, в 90-х не было никакого "загуглить", с которым, оказывется, сейчас испытывают сложности выпускники курсов. Брали хелпик по языку, брали книгу по теории - и вперед, решаем задачу. Не получается решать - идем в библиотеку и ищем еще книгу. Максимум читерства - это взять код друга, и, прочитав его, постараться понять, как можно повторить некоторые элементы алгоритма и какими методами.

    Тут на днях спросили - а как я учился программировать? Да хрен его знает, как. Что-то читал. что-то гуглил, где-то что-то просмотрел. Да, не три месяца, а несколько лет тут-там хватал тчо где, решал задачи. Если бы были курсы, то сегодняшний уровень я бы имел за три-четыре месяца, потому что база раньше бы сформировалась, и на учебных задачах больше бы алгоритмов и методов обкатал. Но тут важно даже то, что я не заметил. как чему-то научился. И это абсолютно нормально. Потому что обучение - это НЕОТРЫВНЫЙ ОТ ЖИЗНИ ПРОЦЕСС. Нельзя сказать, что тут я учусь, а тут не учусь, потому что учеба идет постоянно.

    Но у других по- другому Все чаще и чаще сталкиваюсь не с тем, что область знаний какая-то сложная, а скорее с тем, что люди - необучаемые обезьяны. Сколько книг желающим научиться программировать скидывал - ни один не прочитал. Зато потом от них вопросы: "а какие курсы лучше"? Самый лучший курс - самообразование.


  1. mikvollirik
    15.08.2022 11:16

    Про поиск себя и пробовать что-то в процессе прям в точку, после универа устроился на фулстака с обучением(с********е курсы skillbox, выложенные на личном облаке руководителя, 2 курса python и html), через полгода понял что такое не совсем моё - вроде у тебя есть задача, вроде с командой декомпозировали ее и разобрали мелкие задачи, но усе равно нет какой-то что-ли конкретики, что зачем и для чего мы делаем, жа и с командой отношения не сложились. В итоге уволился перед НГ, потом по знакомству начал изучать саповский ABAP и понял-вот оно, моё! Никаких тебе библиотек и различных модулей, просто пишешь код и всё, при этом понимаешь что, где, как и для чего используется, а потом стартанули февральские события и не было уверенности, что абаперы еще будут нужны, хотелось свалить учить 1с, но упорство взяло своё и уже 2 месяца я абапер. Да, немного, зато интересно. Да и трофейное ПО надо кому-то поддерживать)


    1. Keeper13
      15.08.2022 12:24

      Живой абапер по призванию, вот это да! Думал, на ABAP пишут исключительно ради бабла.


  1. Bedal
    15.08.2022 12:12
    +1

    «Сложно» — оценочная категория и имеет смысл в сравнениях. В сравнении с великим множеством других занятий, программирование — это просто. Или очень просто. Кто не верит — пусть освоит работу столяра за пару лет.


  1. YMA
    15.08.2022 13:00

    Прочитал статью, IMHO там не отражено ключевое - чтобы стать хорошим программистом, надо быть программистом в душе изначально.

    Уметь аналитически сформулировать комплекс правил, связанных с решением поставленной задачи, потом разложить эту задачу на элементарные действия, "кирпичики", каждый из которых будет действовать в рамках правил. А для программистов, работающих в команде - еще и принять правила, сформулированные другими участниками, и оформить решение задачи по принятому стандарту.

    Это реально дано не каждому - от уровня "Хочу получить оптимальный график отгрузки в магазины с центрального склада", спуститься на уровень "сложить А с С и проверить, не больше ли оно, чем Р".

    А так, действительно, меняем в статье "программист" на "столяр" и ничего принципиально не изменится. :)