Изобрёл США прям. Ну и все нормальные федерации. Тут есть здравая мысль. Итак, проблемы.
Система получается неравновесная. Ресурсы ограничены. Сами контейнеры должны быть сменяемы! Т.е. если где-то правит какой-то царёк, то все местные люди могут сказать - он нам не нужен, да и вообще такая система гавно, ну и сменить тип контейнера. И всё равно нужна общая среда, в которой будут работать эти контейнеры, их сменяемость, т.е. некоторая система для контейнеров.
Именно так. Частично, верные управленцы заменяют компетентных управленцев, частично компетентные становятся верными, теряя компетентность. А именно управленцы на самом деле и задают работу системы, саму её суть.
1) Это для совсем других людей и целей. Политик - как манагер, а не разраб. Его задача - показывать или выбирать куда работать, а не самому реализовывать проекты.
2) Его работа начинается не с 0. Он приходит уже окунувшись в это. Т.е. в норме сначала становится политиком, а только потом президентом.
3) Как правило, ему не нужна производительность. Его задача - чисто регуляторная, переговорная. В идеале, вообще без прямой власти на происходящее. И количество решаемых проблем хоть и велико, но система работает и вовсе без него. Достаточно решать основные проблемы, чтобы система развивалась.
Эффективность вот, пожалуй, нужна. Но её вообще трудно измерить, но по некоторым исследованиям видно, что политик приходит, делает что может/сказал до выборов, а помимо этого занимается своими проблемами, причём, чем дальше, тем больше именно этих "своих" проблем, меньше реальных проблем общества. Т.е. эффективно их не просто сменять, а сменять как можно чаще. Возможно, вообще выдавая полномочия для конкретных целей.
Совсем свежий пример. Как там с потерянными $, которые ни снять, ни перевести нельзя было, а за хранение списывали? Советские/новорусские деньги - так же "обеспечили"
Потому что подавляющее большинство айтишников этого не делают. Ну или точнее делают это примерно в такой же степени как и люди других профессий.
Звучит примерно как - большинство бегунов не бегают. Так, ходят порой, как и все прочие. Или игрок в керлинг бегает столько же, сколько и бегун. Это представление о приблизительном равенстве легко опровергается анализом действий в различных профах. Но это я уже опровергать не буду) Для меня это является прописными истинами, которые весьма сложно объяснять, так же как объяснить что такое бег.
А мне сложно понять, что в этом такого особенного? Тебя же не удивляет, что атлет имеет отличную физическую форму? Или что бегут быстро и долго бегает? Почему ты считаешь, что работа, в которой часто нужно думать о чём-то новом и решать новые задачи, не приводит к развитию разума? А катализатором здесь является то, что можно много раз ошибаться и пробовать, т.е. учиться.
Современная медицина не больше IT, вот ни разу. Да, огромные справочники, различные направления и т.д. Но они, все - почти стоят на месте или переписываются. А IT вбирает в себя в т.ч. и эти сферы. Вот биология - согласился бы. Но знания биологии от медиков? Такого зверя крайне сложно найти.
В медицине не просто кто-то профаны, а большинство. Сейчас, вообще самому приходится изучать медицину. Да, я ориентируюсь на слова лучших, но даже эти слова чуть не из учебника, я получаю именно от лучших, а не от тех, кто по программе ВУЗ-а должен разбираться - в этом нет ничего действительно сложного. И я ещё не говорю о доказательной медицине - попробуйте хотя бы узнать компетентен врач или нет и его методики работы, они часто даже не знают что это такое. В одной трети случаев они прямо противоречат логике и медицине, а в других случаях разброд, всякая эзотерика, 3 разных диагноза от 3 врачей по результатам исследований, а при одном диагнозе 3 кардинально отличающиеся стратегии лечения. По некоторым исследованиям 70% диагнозов не верны. Не считая тех кто действительно получает обратную связь, например, хирургов, реаниматологов, анестезиологов. И вот у них то чаще с соображалкой хоть всё хорошо.
Бухучёт - это знание... бесполезной чепухи для разума. Тут даже про знания законов - чушь. Это только небольшой раздел чего как делать, который разбирается вместе со взаимодействием с налоговой, но даже знание реально - это базовая логика и справочник. Это никак не делает их умнее. А наличие программ упрощает до совсем ничего не значащих величин.
У программистов ЗП выше совсем не из-за работы за рубежом - это всё же всё равно малый %. У них ЗП выше, т.к. их деятельность легко тиражируется, в т.ч. на западный рынок, а так же легко начинается из-за низких стартовых трат.
Узкий кругозор - недостаток знаний. Непонимание базовых вещей относительно. Умение думать, у программистов, в среднем значимо выше. Это никак не говорит, что в других местах в этом люди все хуже. Но знания сейчас можно легко получить при желании. А научиться думать крайне не просто без посторонней помощи или внешних обстоятельств
Я так же думаю о специальностях, но "в вакууме". Можно так же сказать о топовых специалистах сфер. В целом то и многие программисты не могут, например, в концепции, некоторые абстракции, даже после 5 лет опыта. Но есть кое-какая разница. Обратная связь на действие очень сильно влияет на обучение. Поэтому опытных инженеров с проблемами логики я не встречал. А вот в той же медицине полно профанов. А ведь их специальность требует оперировать вероятностями, да и системами, находить связи. Но нет, я таких в работе только в кино видел. Большая часть не может ничего за рамками очевидного любому с простейшей системой справочника по симптомам, даже с 10+ летним опытом. Бухучёт вот не знаю, не общался по рабочим темам с очень хорошими спецами. Но пока что, всё что видел - простейшая математика и логика. Системного мышления не встречал. Не редко наоборот - шаг в сторону и сядут в лужу.
А всех под одну гребёнку - ни чуть не лучше недооценки. Так что особо сложно для тебя?
Я пользовался несколько лет назад. Проблем вообще не было. Не понимаю, что у вас там бажного вообще могло быть? Некоторые особенности производительности могли стрельнуть, но не особо критично. Всё ядро работало без проблем. Некоторые особенности работы с файловой системой может? Вся запись обычно через БД. С портами и сетью тоже без проблем. С правами запуска всё ок было.
Тут ещё вопрос, кого кем считать. Сейчас всё чаще просто по стажу идёт подгон. Так мидл почти в любом случае будет через года два-три из середнячка-джуна. А когда наймом занимаюсь, часто вижу с опытом в 3 года и всё ещё джуны, которые знают не многим больше меня, когда я только-только начинал. До мидла то многие растут. Но на 1 мидла, ощущение, что 10 джунов на мидловой позиции. А джунов вообще без счёта, да сейчас не редко они уже и много знают, т.к. много всего надо изучать, но с другой стороны и мало, потому что глубина никакая, много пробелов. Может мало фундамента? Раньше глубокие, а то и полные знания на сеньора нужны были. А сейчас что? Поболтать то часто не о чем. Умеешь кое-как тяп сделать - значит сеньор) Самого спрашивают - так то же самое. И ещё больше нетерпения к тем, кто знает больше тебя, но за то не знает новую фичу X в фреймворкке Z от позавчера. Ну, реально, сеньоров встречаю не так уж часто.
Я в галере работал, где были почти все джуны, и всего несколько спецов, которые могли бы считаться мидлами или сеньорами лет 10-15 назад. Для заказчика то по разному. Многих гордо звали мидлами и даже сеньорами внутри компании, но сейчас всех так зовут просто по стажу или желанию. Реально глубоких знаний у таких сеньоров нет, а мидлы ваяют лютое непотребство, как только надо сделать шаг в сторону от привычного + почти все попадают в стандартные ошибки новичков. Да, работы было много, и много именно разгребать косяков, тушить пожары, обучать, договариваться. Но выгода была, в т.ч. за счёт низких зарплат и плохих условий труда. И это не эникей 1С и прочее, а сфера развлечений, игр, мобилок, сайтов с беком. И даже там джуны справлялись при некотором контроле, а то и сами делали кое-как, не вытягивая только некоторые аспекты. Джуны обучали джунов. Делать это эффективно, конечно, не получалось. Но "и так сойдёт" работало - дёшево и сердито же)
А галеры такие есть в несколько уровней. Есть и много хуже по уровню, и много лучше. И везде то же самое со званиями.
Я таких умников видел мало) Чаще только болтать могут, но не делать. Можно внедрить KPI. Только продукты разные бывают. На каждый нужен свой. Все пытались внедрять ещё 10+ лет назад. Тогда ещё встречались очешуенные метрики по подсчёту количества строк кода и премии за них же) И даже про обратное слышал, т.е. меньше строк кода - больше премия. Вот только пока такие умники пилят систему KPI их конкуренты уже продают продукт. В моей сфере это пол года. А через пол года новый продукт, уже другой, к которому и метрики нужны будут новые. Или может ты тут готов ответить за свои слова показав мастерство и указав метрики для всей IT?
Тогда, весьма вероятно, что вы наткнётесь на те же грабли, которые были в других подобных сервисах. Ваш сервис будут использовать для таких целей скрытно, и вы даже далеко не сразу это поймёте. А какая-то из целей(комбинация) станет пристанищем для тех кто ищет именно таких отношений.
Если, конечно, популярность сервиса будет достаточно высокой. На сколько знаю, чтобы решить эту проблему делают премодерацию из человеков, а иначе не выходит.
Но понятно, что если сроки поплыли, либо они были не релеванты - то дело явно не в методологии
Ровно наоборот. Если она применялась правильно и оказалась не эффективна, то дело в методологии.
а потом оно вместе не собирается
Это вообще у меня редкая проблема. Каждый спринт - должен быть рабочий продукт и фичи в рамках спринта.
когда за плечами 20+ лет, можно промазнуться со сроками
Ну даже если с опытом в 20+ промахи, то что уж говорить про менее скилловых рядовых разрабов?
Нет особого контекста. Просто скрам для Agile разработки ПО не подходит. И поэтому провалы по срокам я вижу везде. А смириться с таким положением дел и рулить тем, что есть, не могут. Особенно низкоскилловые управленцы/владельцы/манагеры.
А про типовые говорю, т.к. есть сфера с 1С, где делают на платформе много раз повторяемые вещи. Там все считают работу в часах... Но! Тратят на часовую работу в один раз 20 минут, а другой 90, фактическое время постоянно скачет. Т.е. оценка всё так же наобум.
В целом, пожалуй не соглашусь с частью "не осознали". Таких не осознавших почти все, а вылетают далеко не все. К концу ВУЗ-а чётко знали что будут делать - треть в лучшем случае. Ещё треть так и не знала. По специальности не горело примерно 80-90%.
Насчёт трояков иногда и так. Но всё же не сильно любого и любой специальности.
Впервые меня занесло на микроэлектронику. 45 человек в группе на старте, 10 на втором курсе. У половины не прошедших долг по программированию, у половины долг по матану. У четверти по химии, как и по физике. Причины, которые я вижу: химия была в объёме 2 лет умещена в урезанный годовой курс(меньше пар, меньше практики, больше теории, нужно сдать 2 лабы за 1 пару). Матан преподавал г*****, беседуя о птичках, а потом оказалось часть лекций не была даже не дочитана. Программирование в принципе было сложным - лекции становились полезными уже после того как научишься код писать, а курсач в виде вывода динамического графика переходного процесса, при этом пар меньше, чем в аналогичной ситуации у IT специальности, а спрос такой, что ошибкой считалась неоптимальная программа как по памяти во время выполнения, так и по объёму кода. А вот физика была что надо! После того 1 курса ЕГЭ сдавали на 100 баллов при минимальной подготовке, хотя ранее было около 50 у всех.
А если преподу не понравится(в т.ч. тем, что не занёс, это тоже традиционно по разному), то ты не сдашь на 3 с минимальным желанием. Придётся изучать примерно на 5 ради той же тройки, не редко рискуя сдавать уже комиссии.
Мы же об оценках в т.ч. и объективности. Нельзя просто сказать - исследуй это. Нужны сроки. И они всегда есть на каком-то уровне проекта. И они очень часто не работают ожидаемо на любом не типовом проекте)
Что делает аналитик/дизайнер? Очевидно копают вперед.
Дизайнер исследует и получает +- полную картину объёма работ. Это вообще самый плохой пример. Даже в геймдеве предсказать объём выходит крайне точно, на месяцы вперёд с ошибкой в неделю. Проблема может быть только с не достаточно опытными, но дешёвыми дизайнерами.
Аналитик не знает ситуацию, но так же имеет представление. И сроки исходят так же из представления. Он является постановщиком и передаёт задачи вниз. И в случае чего, за сроки работы программистов не отвечает, а часть анализа благополучно сливает на конечных исполнителей - программистов. Анализ того, что и как должно быть в целом же более-менее постоянен. Т.е. можно ошибиться в некоторых аспектах, в некоторых недоработать, пропустить что-то. И они ошибаются и сроки так же едут. Только вот ошибка при поверхностном анализе так же велика. И многие проекты так же затягиваются и/или выполняются не полностью) Т.е. проблема с аналитиками такая же и не решается. Помню в ВУЗ-е ещё про интеграцию длиной аж в 10+ лет говорили! А план в 2 был, и оставался примерно таким же все годы) ----- В нашем примере берётся скрам, из него выдёргиваются спринты, пытаются как-то прикрутить, оно не работает. "Не особо умный" менеджер бесится, руководители бесится. Сделать ни черта не могут, в худшем случае винят разрабов и на этом конец) Пару раз видел как команды/компании валятся из-за этого. Сейчас такого поменьше стало, но раньше было частым явлением.
Тут не про трекер времени, а про оценку срочного(т.е. у которого есть дедлайн) проекта. Проблема в том, что надо это не только ПМ-у, но и всем отвечающим за проект в целом. А они просираются из-за своих ошибок, но видят в этом ошибку программистов. Иногда начинается с установки оценки, а заканчивается тем, что сроки не сходятся и в ответе за сроки оказываются программисты, лиды, а не менеджер. ----- Вот как раз одна из основ скрама - инструмент со спринтами и менеджментом задач. Убрать краеугольный камень скрама - получить хромую лошадь. Многие то не могут это заставить работать в принципе, и получается урод, что только маскируется под скрам, а на деле является старой концепцией с 5 ногой.
Я там писал как сам нанимаю) Уже на уровне мидла литкод не работает вообще.
Ну кстати не такой уж плохой фильтр. "Свой" – это вообще полезный критерий для построения команды. С "чужими" работать как-то сложнее.
В целом, это удобно для быстрой работы, но для слабых команд. Дело в том, что абстрактные "чужие" - это те, у кого компетенции не сходятся внутри команды. Т.е. он знает то, что вы не знаете, либо то же, но с иной стороны. А нанимая таких же людей компетенции не увеличиваются. Впрочем, не редко они и не нужны) Тут главное не путать социальное и навыки. Потому как несходимость по социальной составляющей не решается, в отличии от рабочих навыков.
Да, такой подход весьма хорош для джунов и отчасти мидлов. Люди со знанием теории и без практики не смогут это делать вообще или хотя бы эффективно. А любой человек с реальным опытом в год уже +- спокойно справится. И почти никакого стресса) Но малый объём проверки, компетенции будут не выяснены. Впрочем, если они не особо важны, то и ладно
PS: возможно, что я несколько завышаю требования по мидлам. Считаю, что сейчас рыночек даёт это звание авансом) Т.е. опытным джунам.
ВУЗ тоже не по щелчку. А хороший ВУЗ вообще проблемно. Если со школой не повезло, то куда проще любой вариант сразу. И в хороший колледж/техникум попасть проще, чем в хороший ВУЗ.
Ментора сейчас найти не проблема. Проблема с доверием тут есть. И вот ВУЗ проблем с недоверием не испытывает, отчего легко попасть в плохой ВУЗ.
После ВУЗ-а всё так же, как после 16 или 18. Взрослым человек становится не от учёбы и не от возраста.
Не наблюдается, т.к. система работает, получает финансирование, перераспределяет его на IT. Государству нужны дешёвые IT, оно их получает как умеет. Для человека это значения не имеет.
Я знаю на личном опыте, какое качество выдаёт даже не плохой ВУЗ, что выше среднего. И колледж такой же. Разницы, кстати, особо и нет. Из преподов там я всего один раз встречал человека прям хорошего программиста уровня Senior. Это качество достигается за год интенсивной работы при не плохих стартовых знаниях(не по программированию). И вот потом уже эффект от ВУЗ-а был бы в разы лучше. Без умения писать/читать программы обучение в ВУЗ-е не несёт значимой пользы, которую как раз ВУЗ должен давать.
Из своего опыта. Как 0, т.е. всегда. Пилишь игру, получается плохо, переписываешь. Так повторяется до хорошего результата. Получается плохо в любом случае. Дизайн кривой - переписываешь. Поменяли геймплей(а это по ходу разработки норма) - переписываешь. Иногда под релиз уже нет времени переписывать, тогда неудачные решения просто удаляются. Какой объём будет и как будет работать толком никто не знает. Потому как игры ещё нет, дизайн со старта целиком в работе. Даже если 2 часть, очень похожая на первую.
1) Надо быстро, команда маленькая изначально, не успеваешь в срок, но вытягиваешь качество, делаешь конфетку. В результате получаешь по шапке, часть команды потребуют уволить и все без премии. И пох, что игра на 1 месте в сторе с миллионами продаж, что на много лучше других команд. 2) Финансирование по ходу проекта прекращается по независящим причинам. Нужен новый инвестор, но игры ещё нет - надо либо выпускаться, либо новый инвестор. В любом случае игра должна быть готова уже вчера. Я так в 1 проект с 3 крупными издателями... хотел бы сказать поработал, но они так ни черта и не сделали! Обидно, ведь каждый требует своих изменений, впендюрить свой суперкрутой велосипед и т.п., а в результате время потрачено впустую. 3) Проекты длятся очень мало, но слишком велики, чтобы сделать быстро. То же тестирование в отрасли не особо прижилось, т.к. долго. Местами можно и нужно, но проще потерять даже 5-10% пользователей и сделать гораздо быстрее, очевидные ошибки будут поправлены в любом случае. А баги мб потом поправят, если деньги будут. Длина проекта в 6 месяцев - нормально. В 2 года на ~ ААА - более чем. Нет, может быть и много дольше, но это обычно растянутое переписывание) 4) Изначальная идея и оценка не соответствует тому, что в итоге требуется. Потому что проверить идею и реализацию сразу не выходит. Прототипы помогают и позволяют найти хорошее. Но это хорошее умирает чаще(не интересно игрокам при расширении прототипа), чем живёт. Хотели обычный платформер. Довольно примитивная штука же? Что там делать даже 1 прогеру пол года? А получилось так, что переписывали всё прямо до релиза. А игра поменяла концепцию по ходу разработки пару раз. А релиз остался там же, где был.
Так то оно в теории так. На деле это смотрел и даже несколько применял, как раз в рамках теста - была попытка решить проблему таким способом, для чего задачу прямо в процессе разбирали на части. Буквально в тот же день и выяснили, что это не работает, записав решение нескольких задач на условные несколько часов. Выходили цепочки в несколько задач для решения, чаще 3-5, но порой и цепочки в несколько десятков. Изредка совсем простые в 1 шаг, типа багов, которые уже знали как починить, а если не знаешь - то же самое. Каждую надо описать как задачу, согласовать, затем Заново делать, т.к. из контекста уже выпадаешь. Ну и смысл? По скраму, как уже писал, вообще работать невозможно, т.к. нужен новый спринт на каждую задачу в цепочке
Ну вот лид. Литкод не пользую. Стресса полно на собесе, задаю вообще базовые вещи, ни черта не знают, не могут обсуждать темы по программированию - очень часто. При этом явно сами пишут код, хоть и плохой, но работающий(у них). Проверять реверс строки не вижу смысла даже на джуновую вакансию, т.к. она не даст ответа о компетенции. Если решит, то и что? Этого всё равно мало. А если не решит, то за 15 минут можно задать вопросов на много больше, которые скажут куда больше. Можно, например, дать прочитать код и поспрашивать по нему. Это куда быстрее. А тестовые вот подойдут для первичного отсева.
Для мидла простые задачи уже не подойдут. А сложные делать долго и время может быть сильно неопределенно + появляется специфика. И тут действительно сложно, потому как компания то мб и сэкономит, потребовав ТЗ, но соискателю это зачем? Это уже полноценная работа на день, а иногда и неделю-две. А ведь нормально сделать без контекста очень сложно, а по качеству кода всё равно будут определять уровень. Чтобы была приписка, типа, реши любым способом, не важно качество - такое всего раз видел. Чтобы была готова среда для написания - ни разу. Ну конечно, это же работать надо, потратить пару дней на подготовку) А меж тем стартануть проект, просто пустой, но запускающийся, у меня уйдёт как раз 1-2 дня. Как и среду скачать/настроить пару дней.
А ещё выше уровнем вовсе бесполезны, и литкод, и тестовые. Тут нужно уже на словах решать задачи, может даже десятками-сотнями за час. Что-то вроде блица. Иначе скорость просто не достаточна для оценки. Мы же хотим не своё эго потешить, а узнать о возможностях кандидата? Если так, то темы должен выбирать кандидат
Проблема часто в том, что многие наниматели и сами не далеко ушли от кандидатов. Не так уж редко иду на собес, а там лид не может обсуждать проект в технической реализации, даже если зацепишься за что-то. Всё больше налегают на какие-то редкоиспользуемые мелочи. А как насчёт проектирования поговорить? Вообще ни разу не было именно такой постановки на собесах) ООП ограничивается - "а знаешь ли ты принципы ***?" Ну и о чём с такими работать?) На деле это работает не как фильтр знаний/умений, а как фильтр вовлечённости в сферу - если человек изучил, то "свой", а не мимокрокодил. Только из-за этого совпадения это всё ещё работало. До курсов)
Кстати, именно "свой" - определяющее в таких компаниях. Т.е. если делаешь как им хочется, говоришь, что им хочется, то добро пожаловать. И пофиг, что они называют DTO моделью в MVC/MVP, а свой процедурный стиль ООП. Вопросы стиля кода поднимать в таких вообще нельзя - это сразу крест)
1) Сам задаю вопросы, очень много вопросов. Заранее предупреждаю, что на большинство кандидат может не ответит, и что даже такой результат - это нормально. Но каждый ответ это небольшой +. Да и если кандидат не отвечает несколько раз подряд - сильно дизморалит, так что ещё и поддержка нужна. Спрашиваю не по синтаксису, а как сделать то-то или то-то. Что можно сделать с тем-то и тем-то? Как работает то и другое? Может особенности работы чего-то, знаешь? Что-то ещё подобное знаешь? А про то знаешь? Как сделать то и почему? И по таким вопросам реально за пол часа пробежаться по всему курсу программирования верхами, а несколько пропуская можно и за 15 минут. После универа знания могут быть на уровне что-то слышал по всем темам - это уже хорошо. 2) Ещё за пол часа углубится в дебри и особенности. Тут я не спрашиваю как и что делается. Я спрашиваю о чём человек знает. Спрашиваю, чтобы определить границы того, что он не знает о своём не знании, а так же найти то, что я не знаю. Всё нужное, в т.ч. как сделать, программист найдёт сам - это обычная рабочая задача. Вопрос только, увидит ли он проблему, или спокойно рекурсией будет парсить мегабайты+ данных. И, что характерно, так и выходит - отсутствие знаний не мешает программировать, а вот пустое самомнение и повторение стековерфлоу без понимания работы и даже попыток понимания, приводит к проблемам. На уровень мидла требую как минимум уметь общаться на техническом языке. Обсуждать всё, что касается работы. И ведь большая часть не может это делать полноценно, потому как опыт работы в команде весьма мал, ну или большой только условно, т.к. опыта обсуждений решений там мб вообще нет. 3) А на высокий уровень уже по другому. Если ранее я веду разговор, задаю вопросы и всячески "пытаю" на разный лад, пытаясь выяснить, что же знает человек, то тут наоборот, спрашиваю о различном опыте, пытаясь получить диалог об абстракциях, обсудить опыт проектирования, решений, обосновать их.
Самая большая проблема - вообще не подготовится, потому что запара, проблемы и т.д. Это сложнее даётся. И, походу, так почти у всех)
PS: Всего раз просили спроектировать на словах что-то. Вроде, "А как бы ты сделал?" именно по проектированию системы. И... диалога не было. Зачем? Как я думаю, они просто не в состоянии сами его были поддерживать и такой конкурент им не сдался) Никто не знает как нанимать спецов высокого уровня, кроме банального - отсеять кого придётся и доверится тем, кто останется
Изобрёл США прям. Ну и все нормальные федерации. Тут есть здравая мысль. Итак, проблемы.
Система получается неравновесная. Ресурсы ограничены. Сами контейнеры должны быть сменяемы! Т.е. если где-то правит какой-то царёк, то все местные люди могут сказать - он нам не нужен, да и вообще такая система гавно, ну и сменить тип контейнера. И всё равно нужна общая среда, в которой будут работать эти контейнеры, их сменяемость, т.е. некоторая система для контейнеров.
PS: рынок является частным от такой системы
Именно так. Частично, верные управленцы заменяют компетентных управленцев, частично компетентные становятся верными, теряя компетентность. А именно управленцы на самом деле и задают работу системы, саму её суть.
Тут ошибка в самом сравнении, сразу в 3 местах.
1) Это для совсем других людей и целей. Политик - как манагер, а не разраб. Его задача - показывать или выбирать куда работать, а не самому реализовывать проекты.
2) Его работа начинается не с 0. Он приходит уже окунувшись в это. Т.е. в норме сначала становится политиком, а только потом президентом.
3) Как правило, ему не нужна производительность. Его задача - чисто регуляторная, переговорная. В идеале, вообще без прямой власти на происходящее. И количество решаемых проблем хоть и велико, но система работает и вовсе без него. Достаточно решать основные проблемы, чтобы система развивалась.
Эффективность вот, пожалуй, нужна. Но её вообще трудно измерить, но по некоторым исследованиям видно, что политик приходит, делает что может/сказал до выборов, а помимо этого занимается своими проблемами, причём, чем дальше, тем больше именно этих "своих" проблем, меньше реальных проблем общества. Т.е. эффективно их не просто сменять, а сменять как можно чаще. Возможно, вообще выдавая полномочия для конкретных целей.
Совсем свежий пример. Как там с потерянными $, которые ни снять, ни перевести нельзя было, а за хранение списывали? Советские/новорусские деньги - так же "обеспечили"
Звучит примерно как - большинство бегунов не бегают. Так, ходят порой, как и все прочие. Или игрок в керлинг бегает столько же, сколько и бегун. Это представление о приблизительном равенстве легко опровергается анализом действий в различных профах. Но это я уже опровергать не буду) Для меня это является прописными истинами, которые весьма сложно объяснять, так же как объяснить что такое бег.
А мне сложно понять, что в этом такого особенного? Тебя же не удивляет, что атлет имеет отличную физическую форму? Или что бегут быстро и долго бегает? Почему ты считаешь, что работа, в которой часто нужно думать о чём-то новом и решать новые задачи, не приводит к развитию разума? А катализатором здесь является то, что можно много раз ошибаться и пробовать, т.е. учиться.
Современная медицина не больше IT, вот ни разу. Да, огромные справочники, различные направления и т.д. Но они, все - почти стоят на месте или переписываются. А IT вбирает в себя в т.ч. и эти сферы. Вот биология - согласился бы. Но знания биологии от медиков? Такого зверя крайне сложно найти.
В медицине не просто кто-то профаны, а большинство. Сейчас, вообще самому приходится изучать медицину. Да, я ориентируюсь на слова лучших, но даже эти слова чуть не из учебника, я получаю именно от лучших, а не от тех, кто по программе ВУЗ-а должен разбираться - в этом нет ничего действительно сложного. И я ещё не говорю о доказательной медицине - попробуйте хотя бы узнать компетентен врач или нет и его методики работы, они часто даже не знают что это такое. В одной трети случаев они прямо противоречат логике и медицине, а в других случаях разброд, всякая эзотерика, 3 разных диагноза от 3 врачей по результатам исследований, а при одном диагнозе 3 кардинально отличающиеся стратегии лечения. По некоторым исследованиям 70% диагнозов не верны. Не считая тех кто действительно получает обратную связь, например, хирургов, реаниматологов, анестезиологов. И вот у них то чаще с соображалкой хоть всё хорошо.
Бухучёт - это знание... бесполезной чепухи для разума. Тут даже про знания законов - чушь. Это только небольшой раздел чего как делать, который разбирается вместе со взаимодействием с налоговой, но даже знание реально - это базовая логика и справочник. Это никак не делает их умнее. А наличие программ упрощает до совсем ничего не значащих величин.
У программистов ЗП выше совсем не из-за работы за рубежом - это всё же всё равно малый %. У них ЗП выше, т.к. их деятельность легко тиражируется, в т.ч. на западный рынок, а так же легко начинается из-за низких стартовых трат.
Узкий кругозор - недостаток знаний. Непонимание базовых вещей относительно. Умение думать, у программистов, в среднем значимо выше. Это никак не говорит, что в других местах в этом люди все хуже.
Но знания сейчас можно легко получить при желании. А научиться думать крайне не просто без посторонней помощи или внешних обстоятельств
Я так же думаю о специальностях, но "в вакууме". Можно так же сказать о топовых специалистах сфер. В целом то и многие программисты не могут, например, в концепции, некоторые абстракции, даже после 5 лет опыта.
Но есть кое-какая разница. Обратная связь на действие очень сильно влияет на обучение. Поэтому опытных инженеров с проблемами логики я не встречал. А вот в той же медицине полно профанов. А ведь их специальность требует оперировать вероятностями, да и системами, находить связи. Но нет, я таких в работе только в кино видел. Большая часть не может ничего за рамками очевидного любому с простейшей системой справочника по симптомам, даже с 10+ летним опытом.
Бухучёт вот не знаю, не общался по рабочим темам с очень хорошими спецами. Но пока что, всё что видел - простейшая математика и логика. Системного мышления не встречал. Не редко наоборот - шаг в сторону и сядут в лужу.
А всех под одну гребёнку - ни чуть не лучше недооценки. Так что особо сложно для тебя?
Я пользовался несколько лет назад. Проблем вообще не было. Не понимаю, что у вас там бажного вообще могло быть? Некоторые особенности производительности могли стрельнуть, но не особо критично. Всё ядро работало без проблем. Некоторые особенности работы с файловой системой может? Вся запись обычно через БД. С портами и сетью тоже без проблем. С правами запуска всё ок было.
Тут ещё вопрос, кого кем считать. Сейчас всё чаще просто по стажу идёт подгон. Так мидл почти в любом случае будет через года два-три из середнячка-джуна.
А когда наймом занимаюсь, часто вижу с опытом в 3 года и всё ещё джуны, которые знают не многим больше меня, когда я только-только начинал. До мидла то многие растут. Но на 1 мидла, ощущение, что 10 джунов на мидловой позиции. А джунов вообще без счёта, да сейчас не редко они уже и много знают, т.к. много всего надо изучать, но с другой стороны и мало, потому что глубина никакая, много пробелов. Может мало фундамента? Раньше глубокие, а то и полные знания на сеньора нужны были. А сейчас что? Поболтать то часто не о чем. Умеешь кое-как тяп сделать - значит сеньор) Самого спрашивают - так то же самое. И ещё больше нетерпения к тем, кто знает больше тебя, но за то не знает новую фичу X в фреймворкке Z от позавчера. Ну, реально, сеньоров встречаю не так уж часто.
Я в галере работал, где были почти все джуны, и всего несколько спецов, которые могли бы считаться мидлами или сеньорами лет 10-15 назад. Для заказчика то по разному. Многих гордо звали мидлами и даже сеньорами внутри компании, но сейчас всех так зовут просто по стажу или желанию. Реально глубоких знаний у таких сеньоров нет, а мидлы ваяют лютое непотребство, как только надо сделать шаг в сторону от привычного + почти все попадают в стандартные ошибки новичков. Да, работы было много, и много именно разгребать косяков, тушить пожары, обучать, договариваться. Но выгода была, в т.ч. за счёт низких зарплат и плохих условий труда. И это не эникей 1С и прочее, а сфера развлечений, игр, мобилок, сайтов с беком. И даже там джуны справлялись при некотором контроле, а то и сами делали кое-как, не вытягивая только некоторые аспекты. Джуны обучали джунов. Делать это эффективно, конечно, не получалось. Но "и так сойдёт" работало - дёшево и сердито же)
А галеры такие есть в несколько уровней. Есть и много хуже по уровню, и много лучше. И везде то же самое со званиями.
Я таких умников видел мало) Чаще только болтать могут, но не делать. Можно внедрить KPI. Только продукты разные бывают. На каждый нужен свой. Все пытались внедрять ещё 10+ лет назад. Тогда ещё встречались очешуенные метрики по подсчёту количества строк кода и премии за них же) И даже про обратное слышал, т.е. меньше строк кода - больше премия. Вот только пока такие умники пилят систему KPI их конкуренты уже продают продукт. В моей сфере это пол года. А через пол года новый продукт, уже другой, к которому и метрики нужны будут новые. Или может ты тут готов ответить за свои слова показав мастерство и указав метрики для всей IT?
Тогда, весьма вероятно, что вы наткнётесь на те же грабли, которые были в других подобных сервисах. Ваш сервис будут использовать для таких целей скрытно, и вы даже далеко не сразу это поймёте. А какая-то из целей(комбинация) станет пристанищем для тех кто ищет именно таких отношений.
Если, конечно, популярность сервиса будет достаточно высокой. На сколько знаю, чтобы решить эту проблему делают премодерацию из человеков, а иначе не выходит.
Ровно наоборот. Если она применялась правильно и оказалась не эффективна, то дело в методологии.
Это вообще у меня редкая проблема. Каждый спринт - должен быть рабочий продукт и фичи в рамках спринта.
Ну даже если с опытом в 20+ промахи, то что уж говорить про менее скилловых рядовых разрабов?
Нет особого контекста. Просто скрам для Agile разработки ПО не подходит. И поэтому провалы по срокам я вижу везде. А смириться с таким положением дел и рулить тем, что есть, не могут. Особенно низкоскилловые управленцы/владельцы/манагеры.
А про типовые говорю, т.к. есть сфера с 1С, где делают на платформе много раз повторяемые вещи. Там все считают работу в часах... Но! Тратят на часовую работу в один раз 20 минут, а другой 90, фактическое время постоянно скачет. Т.е. оценка всё так же наобум.
В целом, пожалуй не соглашусь с частью "не осознали". Таких не осознавших почти все, а вылетают далеко не все. К концу ВУЗ-а чётко знали что будут делать - треть в лучшем случае. Ещё треть так и не знала. По специальности не горело примерно 80-90%.
Насчёт трояков иногда и так. Но всё же не сильно любого и любой специальности.
Впервые меня занесло на микроэлектронику. 45 человек в группе на старте, 10 на втором курсе. У половины не прошедших долг по программированию, у половины долг по матану. У четверти по химии, как и по физике. Причины, которые я вижу: химия была в объёме 2 лет умещена в урезанный годовой курс(меньше пар, меньше практики, больше теории, нужно сдать 2 лабы за 1 пару). Матан преподавал г*****, беседуя о птичках, а потом оказалось часть лекций не была даже не дочитана. Программирование в принципе было сложным - лекции становились полезными уже после того как научишься код писать, а курсач в виде вывода динамического графика переходного процесса, при этом пар меньше, чем в аналогичной ситуации у IT специальности, а спрос такой, что ошибкой считалась неоптимальная программа как по памяти во время выполнения, так и по объёму кода.
А вот физика была что надо! После того 1 курса ЕГЭ сдавали на 100 баллов при минимальной подготовке, хотя ранее было около 50 у всех.
А если преподу не понравится(в т.ч. тем, что не занёс, это тоже традиционно по разному), то ты не сдашь на 3 с минимальным желанием. Придётся изучать примерно на 5 ради той же тройки, не редко рискуя сдавать уже комиссии.
Мы же об оценках в т.ч. и объективности. Нельзя просто сказать - исследуй это. Нужны сроки. И они всегда есть на каком-то уровне проекта. И они очень часто не работают ожидаемо на любом не типовом проекте)
Дизайнер исследует и получает +- полную картину объёма работ. Это вообще самый плохой пример. Даже в геймдеве предсказать объём выходит крайне точно, на месяцы вперёд с ошибкой в неделю. Проблема может быть только с не достаточно опытными, но дешёвыми дизайнерами.
Аналитик не знает ситуацию, но так же имеет представление. И сроки исходят так же из представления. Он является постановщиком и передаёт задачи вниз. И в случае чего, за сроки работы программистов не отвечает, а часть анализа благополучно сливает на конечных исполнителей - программистов. Анализ того, что и как должно быть в целом же более-менее постоянен. Т.е. можно ошибиться в некоторых аспектах, в некоторых недоработать, пропустить что-то. И они ошибаются и сроки так же едут. Только вот ошибка при поверхностном анализе так же велика. И многие проекты так же затягиваются и/или выполняются не полностью) Т.е. проблема с аналитиками такая же и не решается. Помню в ВУЗ-е ещё про интеграцию длиной аж в 10+ лет говорили! А план в 2 был, и оставался примерно таким же все годы)
-----
В нашем примере берётся скрам, из него выдёргиваются спринты, пытаются как-то прикрутить, оно не работает. "Не особо умный" менеджер бесится, руководители бесится. Сделать ни черта не могут, в худшем случае винят разрабов и на этом конец) Пару раз видел как команды/компании валятся из-за этого. Сейчас такого поменьше стало, но раньше было частым явлением.
Тут не про трекер времени, а про оценку срочного(т.е. у которого есть дедлайн) проекта.
Проблема в том, что надо это не только ПМ-у, но и всем отвечающим за проект в целом. А они просираются из-за своих ошибок, но видят в этом ошибку программистов. Иногда начинается с установки оценки, а заканчивается тем, что сроки не сходятся и в ответе за сроки оказываются программисты, лиды, а не менеджер.
-----
Вот как раз одна из основ скрама - инструмент со спринтами и менеджментом задач. Убрать краеугольный камень скрама - получить хромую лошадь. Многие то не могут это заставить работать в принципе, и получается урод, что только маскируется под скрам, а на деле является старой концепцией с 5 ногой.
Я там писал как сам нанимаю) Уже на уровне мидла литкод не работает вообще.
В целом, это удобно для быстрой работы, но для слабых команд. Дело в том, что абстрактные "чужие" - это те, у кого компетенции не сходятся внутри команды. Т.е. он знает то, что вы не знаете, либо то же, но с иной стороны. А нанимая таких же людей компетенции не увеличиваются. Впрочем, не редко они и не нужны) Тут главное не путать социальное и навыки. Потому как несходимость по социальной составляющей не решается, в отличии от рабочих навыков.
Да, такой подход весьма хорош для джунов и отчасти мидлов. Люди со знанием теории и без практики не смогут это делать вообще или хотя бы эффективно. А любой человек с реальным опытом в год уже +- спокойно справится. И почти никакого стресса) Но малый объём проверки, компетенции будут не выяснены. Впрочем, если они не особо важны, то и ладно
PS: возможно, что я несколько завышаю требования по мидлам. Считаю, что сейчас рыночек даёт это звание авансом) Т.е. опытным джунам.
ВУЗ тоже не по щелчку. А хороший ВУЗ вообще проблемно. Если со школой не повезло, то куда проще любой вариант сразу. И в хороший колледж/техникум попасть проще, чем в хороший ВУЗ.
Ментора сейчас найти не проблема. Проблема с доверием тут есть. И вот ВУЗ проблем с недоверием не испытывает, отчего легко попасть в плохой ВУЗ.
После ВУЗ-а всё так же, как после 16 или 18. Взрослым человек становится не от учёбы и не от возраста.
Не наблюдается, т.к. система работает, получает финансирование, перераспределяет его на IT. Государству нужны дешёвые IT, оно их получает как умеет. Для человека это значения не имеет.
Я знаю на личном опыте, какое качество выдаёт даже не плохой ВУЗ, что выше среднего. И колледж такой же. Разницы, кстати, особо и нет. Из преподов там я всего один раз встречал человека прям хорошего программиста уровня Senior. Это качество достигается за год интенсивной работы при не плохих стартовых знаниях(не по программированию). И вот потом уже эффект от ВУЗ-а был бы в разы лучше. Без умения писать/читать программы обучение в ВУЗ-е не несёт значимой пользы, которую как раз ВУЗ должен давать.
Из своего опыта.
Как 0, т.е. всегда. Пилишь игру, получается плохо, переписываешь. Так повторяется до хорошего результата. Получается плохо в любом случае. Дизайн кривой - переписываешь. Поменяли геймплей(а это по ходу разработки норма) - переписываешь. Иногда под релиз уже нет времени переписывать, тогда неудачные решения просто удаляются. Какой объём будет и как будет работать толком никто не знает. Потому как игры ещё нет, дизайн со старта целиком в работе. Даже если 2 часть, очень похожая на первую.
1) Надо быстро, команда маленькая изначально, не успеваешь в срок, но вытягиваешь качество, делаешь конфетку. В результате получаешь по шапке, часть команды потребуют уволить и все без премии. И пох, что игра на 1 месте в сторе с миллионами продаж, что на много лучше других команд.
2) Финансирование по ходу проекта прекращается по независящим причинам. Нужен новый инвестор, но игры ещё нет - надо либо выпускаться, либо новый инвестор. В любом случае игра должна быть готова уже вчера. Я так в 1 проект с 3 крупными издателями... хотел бы сказать поработал, но они так ни черта и не сделали! Обидно, ведь каждый требует своих изменений, впендюрить свой суперкрутой велосипед и т.п., а в результате время потрачено впустую.
3) Проекты длятся очень мало, но слишком велики, чтобы сделать быстро. То же тестирование в отрасли не особо прижилось, т.к. долго. Местами можно и нужно, но проще потерять даже 5-10% пользователей и сделать гораздо быстрее, очевидные ошибки будут поправлены в любом случае. А баги мб потом поправят, если деньги будут. Длина проекта в 6 месяцев - нормально. В 2 года на ~ ААА - более чем. Нет, может быть и много дольше, но это обычно растянутое переписывание)
4) Изначальная идея и оценка не соответствует тому, что в итоге требуется. Потому что проверить идею и реализацию сразу не выходит. Прототипы помогают и позволяют найти хорошее. Но это хорошее умирает чаще(не интересно игрокам при расширении прототипа), чем живёт. Хотели обычный платформер. Довольно примитивная штука же? Что там делать даже 1 прогеру пол года? А получилось так, что переписывали всё прямо до релиза. А игра поменяла концепцию по ходу разработки пару раз. А релиз остался там же, где был.
Так то оно в теории так. На деле это смотрел и даже несколько применял, как раз в рамках теста - была попытка решить проблему таким способом, для чего задачу прямо в процессе разбирали на части. Буквально в тот же день и выяснили, что это не работает, записав решение нескольких задач на условные несколько часов. Выходили цепочки в несколько задач для решения, чаще 3-5, но порой и цепочки в несколько десятков. Изредка совсем простые в 1 шаг, типа багов, которые уже знали как починить, а если не знаешь - то же самое. Каждую надо описать как задачу, согласовать, затем Заново делать, т.к. из контекста уже выпадаешь. Ну и смысл? По скраму, как уже писал, вообще работать невозможно, т.к. нужен новый спринт на каждую задачу в цепочке
Ну вот лид. Литкод не пользую. Стресса полно на собесе, задаю вообще базовые вещи, ни черта не знают, не могут обсуждать темы по программированию - очень часто. При этом явно сами пишут код, хоть и плохой, но работающий(у них). Проверять реверс строки не вижу смысла даже на джуновую вакансию, т.к. она не даст ответа о компетенции. Если решит, то и что? Этого всё равно мало. А если не решит, то за 15 минут можно задать вопросов на много больше, которые скажут куда больше. Можно, например, дать прочитать код и поспрашивать по нему. Это куда быстрее. А тестовые вот подойдут для первичного отсева.
Для мидла простые задачи уже не подойдут. А сложные делать долго и время может быть сильно неопределенно + появляется специфика. И тут действительно сложно, потому как компания то мб и сэкономит, потребовав ТЗ, но соискателю это зачем? Это уже полноценная работа на день, а иногда и неделю-две. А ведь нормально сделать без контекста очень сложно, а по качеству кода всё равно будут определять уровень. Чтобы была приписка, типа, реши любым способом, не важно качество - такое всего раз видел. Чтобы была готова среда для написания - ни разу. Ну конечно, это же работать надо, потратить пару дней на подготовку) А меж тем стартануть проект, просто пустой, но запускающийся, у меня уйдёт как раз 1-2 дня. Как и среду скачать/настроить пару дней.
А ещё выше уровнем вовсе бесполезны, и литкод, и тестовые. Тут нужно уже на словах решать задачи, может даже десятками-сотнями за час. Что-то вроде блица. Иначе скорость просто не достаточна для оценки. Мы же хотим не своё эго потешить, а узнать о возможностях кандидата? Если так, то темы должен выбирать кандидат
Проблема часто в том, что многие наниматели и сами не далеко ушли от кандидатов. Не так уж редко иду на собес, а там лид не может обсуждать проект в технической реализации, даже если зацепишься за что-то. Всё больше налегают на какие-то редкоиспользуемые мелочи. А как насчёт проектирования поговорить? Вообще ни разу не было именно такой постановки на собесах) ООП ограничивается - "а знаешь ли ты принципы ***?" Ну и о чём с такими работать?) На деле это работает не как фильтр знаний/умений, а как фильтр вовлечённости в сферу - если человек изучил, то "свой", а не мимокрокодил. Только из-за этого совпадения это всё ещё работало. До курсов)
Кстати, именно "свой" - определяющее в таких компаниях. Т.е. если делаешь как им хочется, говоришь, что им хочется, то добро пожаловать. И пофиг, что они называют DTO моделью в MVC/MVP, а свой процедурный стиль ООП. Вопросы стиля кода поднимать в таких вообще нельзя - это сразу крест)
1) Сам задаю вопросы, очень много вопросов. Заранее предупреждаю, что на большинство кандидат может не ответит, и что даже такой результат - это нормально. Но каждый ответ это небольшой +. Да и если кандидат не отвечает несколько раз подряд - сильно дизморалит, так что ещё и поддержка нужна. Спрашиваю не по синтаксису, а как сделать то-то или то-то. Что можно сделать с тем-то и тем-то? Как работает то и другое? Может особенности работы чего-то, знаешь? Что-то ещё подобное знаешь? А про то знаешь? Как сделать то и почему? И по таким вопросам реально за пол часа пробежаться по всему курсу программирования верхами, а несколько пропуская можно и за 15 минут. После универа знания могут быть на уровне что-то слышал по всем темам - это уже хорошо.
2) Ещё за пол часа углубится в дебри и особенности. Тут я не спрашиваю как и что делается. Я спрашиваю о чём человек знает. Спрашиваю, чтобы определить границы того, что он не знает о своём не знании, а так же найти то, что я не знаю. Всё нужное, в т.ч. как сделать, программист найдёт сам - это обычная рабочая задача. Вопрос только, увидит ли он проблему, или спокойно рекурсией будет парсить мегабайты+ данных. И, что характерно, так и выходит - отсутствие знаний не мешает программировать, а вот пустое самомнение и повторение стековерфлоу без понимания работы и даже попыток понимания, приводит к проблемам. На уровень мидла требую как минимум уметь общаться на техническом языке. Обсуждать всё, что касается работы. И ведь большая часть не может это делать полноценно, потому как опыт работы в команде весьма мал, ну или большой только условно, т.к. опыта обсуждений решений там мб вообще нет.
3) А на высокий уровень уже по другому. Если ранее я веду разговор, задаю вопросы и всячески "пытаю" на разный лад, пытаясь выяснить, что же знает человек, то тут наоборот, спрашиваю о различном опыте, пытаясь получить диалог об абстракциях, обсудить опыт проектирования, решений, обосновать их.
Самая большая проблема - вообще не подготовится, потому что запара, проблемы и т.д. Это сложнее даётся. И, походу, так почти у всех)
PS: Всего раз просили спроектировать на словах что-то. Вроде, "А как бы ты сделал?" именно по проектированию системы. И... диалога не было. Зачем? Как я думаю, они просто не в состоянии сами его были поддерживать и такой конкурент им не сдался) Никто не знает как нанимать спецов высокого уровня, кроме банального - отсеять кого придётся и доверится тем, кто останется