Тогда можно в ответ сформулировать, что не бывает квалифицированных инженеров, которые закончили курсы в несколько месяцев. Так ведь, логично? На самом деле бывают, и именно в айти таких много -- но только такие которые энтузиасты. А вот если нет ни профильного полноценного образования, ни увлечения-хобби, то вот тогда чудес не бывает.
Да понятно что в айти хорошо. Но большие зарплаты потому что случайные люди с улицы не могут работать -- закон спроса и предложения. Если бы можно было после месячных курсов набрать хороших работников, уже бы давно набрали и зарплаты в айти были бы как в пятерочке и магните у продавцов. Но оказывается, чтобы работать в айти нужно много учиться, а не просто курсы оплатить. У меня несколько знакомых интересовались, что им нужно изучить чтобы стать программистами и тоже на удаленке смузи попивать. Я давал им книжки, советы и так далее -- все через пару месяцев бросили, устали.
Как же врачи например, в 17 поступил в мед, и до 60 лечит людей. Или юристы, или бухгалтера, инженеры и так далее -- люди десятками лет, обычно всю жизнь, работают по одной профессии. А программист по вашему более 10 лет не выдерживает, переключаются на другие какие то вещи? Спора нет, потом уже приедается, уже не интересное хобби, а просто способ заработать. Но в первые годы, когда происходит основное обучение, человек действительно увлечен этим -- об этом я написал. А насчет того что я далек от разработки -- сначала 20 лет в айти, программистом, PM, несколько сот тех собеседований поступающих на работу, десятка полтора людей которых персонально менторил, потом да, надоело, 8 лет просто жил в удовольствие, ходил в походы, ездил по миру, занимался ребенком, и вот снова 2 года в разработке. А у вас какой опыт?
А так ли всем подряд нужно в айти, особенно если душа к этому не лежит. Ну как бы, если программирование было интересно, то подросток мог начать им заниматься уже лет в 14-16, а к 20 вполне обладать каким то знаниями даже без всяких курсов. А если человек, что то там закончил, на компьютере до этого 10 лет только в игры играл и качал курсовые, и тут в 25 лет решил побыстрому войти в айти и посидеть на курсах каких то, то может это и не должно получаться у 90%, может это нормально? вон какая востребованность в рабочих специальностях, не всем дано каждый рабочий день решать сложные логические задачи, читать на английском, и постоянно дообучаться.
Ну в рекламных проспектах Аджайл рекомендуют стенд-ап митинги умещать в 15 минут. Ок, в реальной жизни это часто пол часа .. час. Если один-на-один PM будет обзванивать, то будет тот же час в день (для него), при этом с одними подчиненными можно будет спокойно обсудить их вопрос, не беспокоясь что остальные ждут своей очереди, а кого то можно легко пропустить. На самом деле каждый день каждого человека какой вообще смысл опрашивать? Таски есть в JIRA, там же люди отмечают прогресс, если это квалифицированный товарищ то можно и раз в 2-3 дня общаться голосом, а в промежутках просто в чате пингануть типа "вопросы есть?". А какой нибудь джуниор -- так с ним с одним можно минут 15 беседовать о том что он и как делает. Так что никакого целого дня тут нет. А коммуникации с командой это и есть работа PM. Плюс планирование и коммуникации с заказчиком. Если на каждую из этих трех активностей выделить по 2 часа в день, еще и 2 часа на смузи останется.
По моему наблюдению, де факто, эти созвоны в большинстве команд являются вредной и не эффективной активностью. А куда более эффективно определить примерное время в которое PM обзванивает коллег в команде и они один-на-один выясняют как дела, и при необходимости могут ситуацию обсудить подробнее, не отвлекая еще десяток человек в команде. Рассказы в маркетинговых материалах по Аджайл, что всей команде полезно слушать что там творится у коллег, по факту в большинстве команд не работают -- все тупо ждут чтобы оттарабанить о своем прогрессе, а остальное время просто в пустую тратят время, слушая в пол уха (или не слушая вовсе, если уже отчитались).
Правильно отметил автор в пункте 2 про DRY. Расширю мысль -- программирование как инженерная задача столь сложна, что она не сводится к набору примитивных аббревиатур и принципов. Пытаемся убрать дублирующий код, т к заметили сходства в двух алгоритмах, а потом нас просят что то изменить в первом, но не трогать второй, и сходства уже меньше, а проблем от объединения кода в один класс или метод все больше. Так же SPR из SOLID, на который некоторые молятся -- и доходят в этом до абсурда, превращая 50 рационально разработанных классов в 500 микро-классов. Да, каждый из этих 500 классов конечно стал проще, но в целом каша из 500 микро-классов стала сложнее чем 50 нормальных. А корень всей этой проблемы в одном -- программирование это сложно, опыт нужно набирать годами, и все равно каждый раз думать головой -- где нужно разбить на два класса, где нужно два объединить в один, а где оставить как есть. Многие же люди, особенно которые недавно "вкатились в айти", думать не хотят, хотят следовать простым принципам, находят их в разных книжках, и потом пытаются найденным молотком забить все, как будто кругом только гвозди.
Дело ни в курсах, и ни в ВУЗе (хотя с высшим профильным шансы в разы больше). Самое главное -- чтобы программирование было реальным увлечением человека, чуть ли не главным хобби. Тогда и просто на самообразовании можно обучиться, чтобы начать хотя бы джуниором. А если не интересно, только отсидеть и получить корочку, то мало что поможет, ну разве что вышка по специальности, там то все таки 5 лет штаны просиживал -- какую то информацию за такой срок впитал даже без особого энтузиазма.
Несколько человек возрастом 30+ спрашивали меня совет с чего начать и что изучать чтобы стать программистами. Я советов, давал списки литературы, книжки и так далее. Всех хватило на 1-3 месяца, а потом они забили. Очевидно, что люди которые не сталкивались с программированием питают иллюзии, что они месяцок что то поизучают и можно уже пробовать работать. Реальность же в том, что нужен год минимум плотного изучения, а без реального интереса к такой деятельности, только за длинным рублем, мало у кого хватает мотивации учиться.
Очень хорошо если человек готов помочь, подсказать и научить. Главное, это отсечь нахлебников, которые по любой мелочи, в которой они и сами могут разобраться, сразу хотят от кого то получить готовенькое. Если же вы тратите 10 минут, а кому то экономите пол дня, то вы очень ценный специалист и хороший человек. Это заметят и коллеги, и менеджеры (если в компании здоровая корпоративная культура).
Robert Martin, автор SOLID и Clean Code, инженер? какой софт он написал, поищите в интернете. Товарищ уже 30+ лет зарабатывает на курсах, треннингах и книжках. Я посмотрел пример рефакторинга из его книжки, и там нормальные совершенно методы в классе разбиваются на какие то микро-методы по 3 строки, и куча локальных переменных выносится на уровень полей класса -- большего говно-кода сложно представить, и этот человек чему то будем учить настоящих инженеров? Чтобы учить каким то хорошим принципам, нужно понимать где они применяются, а где нет, т к любую хорошую идею можно довести до абсурда. Такие как Robert Martin, которые занимаются курсами, а не разработкой, не понимают где хорошие идеи превращаются во вредные, поэтому у них чем больше тем лучше, и те кто начинают слепо следовать их проповедям зачастую не знают где остановиться, просто потому что их кумир сам это не знает и этому не учит.
Самый главный совет -- гора в 5640 метров это не игрушка, не очередной веселый забег на 5 км или еще какая та увлекательная спортивная развлекуха для офисных работников. Прежде чем идти на 5600, сходите сначала на 3000, потом на 4000, 4500, 5000, и тогда уже на Эльбрус или Килиманджаро (как товарищ Варламов недавно сразу после кафех и урбанистики пошел на Килиманджаро с акклиматизацией всего в 3 дня и сделал глубокомысленный вывод что треккинг в горах это полный отстой и мазохизм).
Абревиатуру SOLID выбрал один американец как красивое словосочетание, после того как тасуя первые буквы разных полезных принципов и идей наткнулся на красивое с точки зрения маркетинга слово. А теперь авторы разных статей и блогов разжёвывают именно эти 5 принципов и так и этак, объясняя нубам великое искусство "чистого кода" :)) Это очень забавно. Такое впечатление, что программирование из инженерной дисциплины превратилось в религию, со скрижалями с заповедями, проповедниками и паствой :))
И как же модно поддерживать непротиворечивость данных и атомарность транзакций в системах, где структуры данные не укладываются в пару десятков таблиц?
Ну так если Waterfall был описан как плохая практика за 30 лет до Agile Manifesto, зачем тогда во всех маркетинговых материалах по Agile и Скраму написано какой он плохой и как они с ним борятся?? Ну это как если бы создатели Питона или C# писали что они создали свои языки чтобы девелоперы не писали на ассемблере -- абсурд же, да?
Бывало задумывался над тем какой уровень изоляции правильно использовать с практической точки зрения, но все никак не мог изучить этот вопрос на должном уровне. Теперь все понятно :) Спасибо за статью!
Отличная статья! Наконец видно, что пишет разумный человек с опытом, а не обчитавшийся маркетинговых материалов товарищ с каким то монолитом страшилкой в голове и микросервисами спасением от всех бед.
Waterfall описанный адептами Аджайл и Скрам и прочих -- не более чем маркетинговая страшилка. Этот вариант когда сначала ТЗ писали год, потом программировали два и т д конечно был, в случае разработки софта для спутников и самолетов и аналогичного оборудования, а разве там можно по другому? Так вот, вместо того чтобы работать рационально, как собственно люди делают зачастую даже интуитивно, менеджерам продали эту идею, что ну вообще не нужно ТЗ, документации и т д -- есть же великий Аджайл и прочее, все как то отрефакторят по ходу дела. Естественно, когда без качественного осмысления как правильно делать задачу, начинают делать что то, а потом переделывают, а потом снова переделывают, и в итоге тратят в пять раз больше времени, чем если бы было потрачена может всего 1 неделя на обдумывание архитектуры. А уж не описывать структуры БД может только оптимист, который никогда не работал с БД с сотнями таблиц. В общем, автор понял с опытом -- модные менеджерские технологии которые утверждают что ТЗ или документация не нужны, и все можно на следующем шаге отрефакторить и поменять -- не более чем набор красивых слоганов.
Требование чтобы все было в одном файле, и ни в коем случае не было DLL -- выглядит как произвольное и не имеющее практической ценности. Если бы автор не выдумывал себе ограничений, то легко бы воспользовался например описанным им вариантом с WPF.
Тогда можно в ответ сформулировать, что не бывает квалифицированных инженеров, которые закончили курсы в несколько месяцев. Так ведь, логично? На самом деле бывают, и именно в айти таких много -- но только такие которые энтузиасты. А вот если нет ни профильного полноценного образования, ни увлечения-хобби, то вот тогда чудес не бывает.
Да понятно что в айти хорошо. Но большие зарплаты потому что случайные люди с улицы не могут работать -- закон спроса и предложения. Если бы можно было после месячных курсов набрать хороших работников, уже бы давно набрали и зарплаты в айти были бы как в пятерочке и магните у продавцов. Но оказывается, чтобы работать в айти нужно много учиться, а не просто курсы оплатить. У меня несколько знакомых интересовались, что им нужно изучить чтобы стать программистами и тоже на удаленке смузи попивать. Я давал им книжки, советы и так далее -- все через пару месяцев бросили, устали.
Как же врачи например, в 17 поступил в мед, и до 60 лечит людей. Или юристы, или бухгалтера, инженеры и так далее -- люди десятками лет, обычно всю жизнь, работают по одной профессии. А программист по вашему более 10 лет не выдерживает, переключаются на другие какие то вещи? Спора нет, потом уже приедается, уже не интересное хобби, а просто способ заработать. Но в первые годы, когда происходит основное обучение, человек действительно увлечен этим -- об этом я написал. А насчет того что я далек от разработки -- сначала 20 лет в айти, программистом, PM, несколько сот тех собеседований поступающих на работу, десятка полтора людей которых персонально менторил, потом да, надоело, 8 лет просто жил в удовольствие, ходил в походы, ездил по миру, занимался ребенком, и вот снова 2 года в разработке. А у вас какой опыт?
А так ли всем подряд нужно в айти, особенно если душа к этому не лежит. Ну как бы, если программирование было интересно, то подросток мог начать им заниматься уже лет в 14-16, а к 20 вполне обладать каким то знаниями даже без всяких курсов. А если человек, что то там закончил, на компьютере до этого 10 лет только в игры играл и качал курсовые, и тут в 25 лет решил побыстрому войти в айти и посидеть на курсах каких то, то может это и не должно получаться у 90%, может это нормально? вон какая востребованность в рабочих специальностях, не всем дано каждый рабочий день решать сложные логические задачи, читать на английском, и постоянно дообучаться.
Ну в рекламных проспектах Аджайл рекомендуют стенд-ап митинги умещать в 15 минут. Ок, в реальной жизни это часто пол часа .. час. Если один-на-один PM будет обзванивать, то будет тот же час в день (для него), при этом с одними подчиненными можно будет спокойно обсудить их вопрос, не беспокоясь что остальные ждут своей очереди, а кого то можно легко пропустить. На самом деле каждый день каждого человека какой вообще смысл опрашивать? Таски есть в JIRA, там же люди отмечают прогресс, если это квалифицированный товарищ то можно и раз в 2-3 дня общаться голосом, а в промежутках просто в чате пингануть типа "вопросы есть?". А какой нибудь джуниор -- так с ним с одним можно минут 15 беседовать о том что он и как делает. Так что никакого целого дня тут нет. А коммуникации с командой это и есть работа PM. Плюс планирование и коммуникации с заказчиком. Если на каждую из этих трех активностей выделить по 2 часа в день, еще и 2 часа на смузи останется.
По моему наблюдению, де факто, эти созвоны в большинстве команд являются вредной и не эффективной активностью. А куда более эффективно определить примерное время в которое PM обзванивает коллег в команде и они один-на-один выясняют как дела, и при необходимости могут ситуацию обсудить подробнее, не отвлекая еще десяток человек в команде. Рассказы в маркетинговых материалах по Аджайл, что всей команде полезно слушать что там творится у коллег, по факту в большинстве команд не работают -- все тупо ждут чтобы оттарабанить о своем прогрессе, а остальное время просто в пустую тратят время, слушая в пол уха (или не слушая вовсе, если уже отчитались).
Правильно отметил автор в пункте 2 про DRY. Расширю мысль -- программирование как инженерная задача столь сложна, что она не сводится к набору примитивных аббревиатур и принципов. Пытаемся убрать дублирующий код, т к заметили сходства в двух алгоритмах, а потом нас просят что то изменить в первом, но не трогать второй, и сходства уже меньше, а проблем от объединения кода в один класс или метод все больше. Так же SPR из SOLID, на который некоторые молятся -- и доходят в этом до абсурда, превращая 50 рационально разработанных классов в 500 микро-классов. Да, каждый из этих 500 классов конечно стал проще, но в целом каша из 500 микро-классов стала сложнее чем 50 нормальных. А корень всей этой проблемы в одном -- программирование это сложно, опыт нужно набирать годами, и все равно каждый раз думать головой -- где нужно разбить на два класса, где нужно два объединить в один, а где оставить как есть. Многие же люди, особенно которые недавно "вкатились в айти", думать не хотят, хотят следовать простым принципам, находят их в разных книжках, и потом пытаются найденным молотком забить все, как будто кругом только гвозди.
Дело ни в курсах, и ни в ВУЗе (хотя с высшим профильным шансы в разы больше). Самое главное -- чтобы программирование было реальным увлечением человека, чуть ли не главным хобби. Тогда и просто на самообразовании можно обучиться, чтобы начать хотя бы джуниором. А если не интересно, только отсидеть и получить корочку, то мало что поможет, ну разве что вышка по специальности, там то все таки 5 лет штаны просиживал -- какую то информацию за такой срок впитал даже без особого энтузиазма.
Несколько человек возрастом 30+ спрашивали меня совет с чего начать и что изучать чтобы стать программистами. Я советов, давал списки литературы, книжки и так далее. Всех хватило на 1-3 месяца, а потом они забили. Очевидно, что люди которые не сталкивались с программированием питают иллюзии, что они месяцок что то поизучают и можно уже пробовать работать. Реальность же в том, что нужен год минимум плотного изучения, а без реального интереса к такой деятельности, только за длинным рублем, мало у кого хватает мотивации учиться.
Очень хорошо если человек готов помочь, подсказать и научить. Главное, это отсечь нахлебников, которые по любой мелочи, в которой они и сами могут разобраться, сразу хотят от кого то получить готовенькое. Если же вы тратите 10 минут, а кому то экономите пол дня, то вы очень ценный специалист и хороший человек. Это заметят и коллеги, и менеджеры (если в компании здоровая корпоративная культура).
Robert Martin, автор SOLID и Clean Code, инженер? какой софт он написал, поищите в интернете. Товарищ уже 30+ лет зарабатывает на курсах, треннингах и книжках. Я посмотрел пример рефакторинга из его книжки, и там нормальные совершенно методы в классе разбиваются на какие то микро-методы по 3 строки, и куча локальных переменных выносится на уровень полей класса -- большего говно-кода сложно представить, и этот человек чему то будем учить настоящих инженеров? Чтобы учить каким то хорошим принципам, нужно понимать где они применяются, а где нет, т к любую хорошую идею можно довести до абсурда. Такие как Robert Martin, которые занимаются курсами, а не разработкой, не понимают где хорошие идеи превращаются во вредные, поэтому у них чем больше тем лучше, и те кто начинают слепо следовать их проповедям зачастую не знают где остановиться, просто потому что их кумир сам это не знает и этому не учит.
Самый главный совет -- гора в 5640 метров это не игрушка, не очередной веселый забег на 5 км или еще какая та увлекательная спортивная развлекуха для офисных работников. Прежде чем идти на 5600, сходите сначала на 3000, потом на 4000, 4500, 5000, и тогда уже на Эльбрус или Килиманджаро (как товарищ Варламов недавно сразу после кафех и урбанистики пошел на Килиманджаро с акклиматизацией всего в 3 дня и сделал глубокомысленный вывод что треккинг в горах это полный отстой и мазохизм).
Абревиатуру SOLID выбрал один американец как красивое словосочетание, после того как тасуя первые буквы разных полезных принципов и идей наткнулся на красивое с точки зрения маркетинга слово. А теперь авторы разных статей и блогов разжёвывают именно эти 5 принципов и так и этак, объясняя нубам великое искусство "чистого кода" :)) Это очень забавно. Такое впечатление, что программирование из инженерной дисциплины превратилось в религию, со скрижалями с заповедями, проповедниками и паствой :))
Ну да, я согласен с автором :)
И как же модно поддерживать непротиворечивость данных и атомарность транзакций в системах, где структуры данные не укладываются в пару десятков таблиц?
Ну так если Waterfall был описан как плохая практика за 30 лет до Agile Manifesto, зачем тогда во всех маркетинговых материалах по Agile и Скраму написано какой он плохой и как они с ним борятся?? Ну это как если бы создатели Питона или C# писали что они создали свои языки чтобы девелоперы не писали на ассемблере -- абсурд же, да?
Бывало задумывался над тем какой уровень изоляции правильно использовать с практической точки зрения, но все никак не мог изучить этот вопрос на должном уровне. Теперь все понятно :) Спасибо за статью!
Отличная статья! Наконец видно, что пишет разумный человек с опытом, а не обчитавшийся маркетинговых материалов товарищ с каким то монолитом страшилкой в голове и микросервисами спасением от всех бед.
Waterfall описанный адептами Аджайл и Скрам и прочих -- не более чем маркетинговая страшилка. Этот вариант когда сначала ТЗ писали год, потом программировали два и т д конечно был, в случае разработки софта для спутников и самолетов и аналогичного оборудования, а разве там можно по другому? Так вот, вместо того чтобы работать рационально, как собственно люди делают зачастую даже интуитивно, менеджерам продали эту идею, что ну вообще не нужно ТЗ, документации и т д -- есть же великий Аджайл и прочее, все как то отрефакторят по ходу дела. Естественно, когда без качественного осмысления как правильно делать задачу, начинают делать что то, а потом переделывают, а потом снова переделывают, и в итоге тратят в пять раз больше времени, чем если бы было потрачена может всего 1 неделя на обдумывание архитектуры. А уж не описывать структуры БД может только оптимист, который никогда не работал с БД с сотнями таблиц. В общем, автор понял с опытом -- модные менеджерские технологии которые утверждают что ТЗ или документация не нужны, и все можно на следующем шаге отрефакторить и поменять -- не более чем набор красивых слоганов.
Требование чтобы все было в одном файле, и ни в коем случае не было DLL -- выглядит как произвольное и не имеющее практической ценности. Если бы автор не выдумывал себе ограничений, то легко бы воспользовался например описанным им вариантом с WPF.