Комментарии 157
Еще есть уровень неопределенности — среднеквадратичное отклонение текущей точки по многим параметрам (соответствие скоупу, бюджету итд) от целевой.
В нормальных условиях второе должно уменьшаться от времени (процесс должен сходиться) — за счет первого. Если недодадите тяги на старте — проект не будет сходиться, если дадите постоянную большую тягу — вероятность попасть в цель по техническим критериям будет, ясно, выше — но получите перерасход ресурсов и снижение мотивации, и как следствие, потерю удельной производительности на финише (условно у вас сеньоры будут тупо фиксить элементарные несоответствия спеке и баги).
Пройти по бритве Оккама, динамически управляя нагрузочным профилем — задача менеджера. Правильно распределить ресурсы на старте, заменить в миттельшпиле на линейных разрабов (миддлов или джунов), втянув их в процесс и позволив им получить опыт, дальше несколькими импульсами ориентационного двигателя (короткими привлечениями сеньоров) скорректировать орбиту, и плавно приземлиться, дав порулить миддлам, когда процесс уже на финише расчетной траектории. Как-то так
PS — продолжая космические аналогии — хорошие менеджеру умеют использовать «гравитационный маневр» — силу гравитации, которую дает энтузиазм новичков втянуться и желание зрелых членов команды делиться знаниями тоже на волне энтузиазма. Это позволяет получить функционал дешевле и качественнее, чем просто по Вашей формуле выше. Но здесь нужно внимательно смотреть, кто способен и желает научить, а кто — учиться — против воли ничего не получится (т.к. КПД обучения < 1, то денежная компенсация не будет иметь смысла).
PS. Есть еще определенная граница сложности самого проекта Y, выше которой задача вообще не может быть решена программистами уровня X ни за какое время. Это правда сейчас скорее исключение (современный процесс разработки в 99% случаев — это комбинирование известных фреймворков, библиотек, тулов и технологий)
Чудес не бывает — экономия на этом сразу не дает о себе знать — но зато когда дает — кариес лечить уже поздно — если повезло, не дошли до сепсиса, то помочь может разве что протезирование.
Пресловутый Боинг уже 10^6 раз пожалел о том, что расплодил у себя «эффективных менеджеров», отдавших ключевой для управления самолетом функционал в руки непрофессионалов — а перед этим, наверное, провел 10^3 митингов на разных уровнях с демонстрацией веселых графиков текущей и ожидаемой экономии.
Между сеньором и джуном может быть и 1:100Это что, типа сравнение спеца с 20-летним опытом в родной для него области с «притёртым» инструментарием и обкатанными методиками против «войти в IT», который клавиатуру вчера первый раз увидел? Каким ещё способом можно получить разницу «1 день к 5 месяцам»?
Я упёрся и сделал себе скрипты которые за меня работали, другие ручками писали.Такое себе сравнение. Сравниваем копателя с лопатой против копателя с экскаватором. Рационализация — это конечно здорово, но если у вас канает рационализировать ТОЛЬКО СВОЙ рабочий процесс, и хвастаться, какой вы производительный, значит процессы на проекте уже построены фигово.
А вот и джун.
Который даже за 5 дней не поймёт сути комментариев выше.
Ещё я завистливый лентяй, и если кто-то на проекте сделал нормально работающую автоматизацию, но вместо того, чтоб внедрить её на всём проекте и увеличить производительность ВСЕЙ КОМАНДЫ в десяток-другой раз, занимается хвастовством вида «смотрите, какой я умный, а вы все жалкое нубъё», то это либо позёр, которому повезло с удобной для автоматизации задачей, либо крыса, для которой личный KPI важнее успеха команды в целом.
Тут есть нюанс: в комментариях выше написана ахинея.
Все вокруг почему-то исходят из гипотезы, что продуктивность т. н. сеньора — величина константная. Что чушь (либо тут сеньорами называют кого попало).
В задаче условного перекладывания джейсона производительность всех будет примерно одинаковой, тут достаточно квалификации бабы Нюры, которая моет пол в офисе по вечерам.
А в тех задачах, ради которых вообще нужны сеньоры (настоящие, не самоназванные по принципу «уже три года за баранка сижу, э») — и которые хоть сто мидлов не решат никогда — КПД колеблется от «треть джуниора» до «пять мидлов». Поэтому очень странно говорить о какой-то констатной производительности. Я могу две недели просто думать, как решить ту, или иную задачу. 0 строк [рабочего] кода на выходе. Это в ∞ раз хуже любого джуна. И наоборот.
Есть понятные физиологические вещи и тесты на скорость чтения и понимания информации, тесты на скорость набора текста и тесты на уровень IQ. Есть люди, которые читают и печатают быстрее, но есть и техники, чтобы увеличить эту скорость. Если все будут применять эти техники во время исследования — насколько велика будет дельта между ними?
У меня например было на моём проекте настроено всё для генерации кода.
Это тоже техника, если ее внедрить на уровне всего проекта для всех — насколько конкретный программист окажется быстрее других?
Так что в итоге измеряют эти исследования? Может ли программист применять различные техники? Так это не то, надо всех поставить в одинаковые условия. Насколько быстро программист читает и осознает спеку, соображает и печатает на компьютере? На это тоже есть отдельные тесты.
Пожалуй задачки на hackerrank и аналогичных ресурсах наиболее близки к тестам производительности? Задачи однотипные, четкое условие выполнения задачи (тесты уже написаны, и должны все проходить). Но в начале у каждого программиста-не-олимпиадника будут проблемы, по мере накопления опыта — он такие задачи будет щелкать все быстрее и быстрее. Тогда выходит производительность зависит от опыта в конкретных видах задач? Ну это и ежику понятно. Без всяких исследований. Хотя, причем тут зарплата?
И еще вопрос — а что насчет реальных задач бизнеса вместо сферических в вакууме?
Есть конкретный пример.
Работали как-то с другом на одном проекте и нам дали задачу исследовать как можно кастомизировать форму тикета во Freshdesk и другой аналогичной системе (название уже не помню, тоже популярное, конкуренты). Я взял фрешдекс, друг — вторую систему. Я типа сеньиор, он джун. У нас были созданы тестовые учетки и тестовые тикеты. У нас была документация с сайта этих систем. Надо было закодить тестовый виджет, который обращался бы к нашему серверу и внедрить на форму тикета. Т.е. бизнес задача совершенно одинаковая и начальные условия тоже близкие к одинаковым, насколько я могу судить.
Мы начали одновременно, часов в 12 дня. Я справился за пару часов, друг не справился до конца рабочего дня (до 19 ч). Я решил посмотреть в чем дело. Он показал на затык в документации. Он делал все по ней, но оно не работало так, как написано в документации. Т.е. что-то в ней упустили. Надо было копать. Если бы я взял вторую систему, я точно так же бы запнулся на этом моменте и возможно раскопал бы, но потратил бы больше времени чем на фрешдекс.
Какие итоги? Задача, одинаковая с точки зрения бизнеса, оказалась совершенно разной с точки зрения программирования. И причина не в сениористости или джуновости, а в качестве документации самой внешней системы. Т.е., чтобы понять разницу в производительности, нам нужно было решать одновременно эту задачу с использованием только фрешдеска. Но бизнесу это не выгодно, он не будет платить два раза за одно и тоже.
Вообще, Ваш пример идеально показывает разницу между разными уровнями. Условно, джун выбирает между малым числом возможных реализаций (например, для задачи web server'а — только java+spring, ибо тут есть опыт), а сеньор — между бОльшим (например: java (и несколько разных серверов), .Net (Framework/Core), Python (и несколько фреймворков), NodeJS, Scala, Kotlin, Go, etc.).
И исходя из разницы между реализации, можно остановиться на более удобной (у нас тысячи параллельных запросов? значит синхронный вариант не подойдет; у нас планируется интеграция с X? значит надо учесть наличие готовых модулей; нужен быстрый старт? значит jit-подобные системы менее эффективны; нужна высокая скорость? значит ручная работы в памяти и отсутствие интерпретатора в приоритете).
Дальше, исходя из принятых решений, продукт может быть или дешевле для расширения, или дороже. Его может быть легко поддерживать, или сложно. И так далее. И только после нескольких лет можно будет понять, насколько правильными были те или иные решения.
А скорость набора кода у людей все равно сопоставимая.
Более менее большой и сложный проект. Таск сеньору на 5 минут, джун будет день разбираться, вот вам и 1:100. Через полгода может снизится 1:50 или даже 1:20 если джун смышлёный
Эти цифры же совершенно условные. А на другой задаче может быть 1:2. А на третьей вообще 5:1, потому что задача нудная, решается легко, джун её быстро и радостно решит, а сеньор будет страдать два дня, прокрастинируя на Хабре.
Поправить — 5 минут.
А остальные 55 займёт бюрократия, не всегда пустая:
Прикинуть минимальный проявляющий ошибку тест, прикинуть (как разраб, т.е. с т.з. «белого ящика) нужен ли он в тестах. Отписаться по этому поводу в трекер.
Прогнать синхронные тесты, запустить асинхронные, создать ревью, отписаться там если будут вопросы.
Запустить свои правки в CI.
Закрыть таск и(или) ревью ещё и возможно сделать кросс-ссылки.
(в конце, вздохнув от бренности бытия — из часа реальной работы было 5 минут, пошёл пить кофе).
Легко, в тех случаях, когда инициативный джун начинает изобретать велосипеды и тонет в их отладке, а сеньор знает, какую готовую библиотеку заиспользовать. Сколько уже написано самодельных очередей, аутентификаций, шаблонизаторов, etc., etc.
45 лет в ИТ это несколько поколений изменений.
Несколько поколений изменения ПО.
Люди же физиологически и психологически не меняются и десятки тысяч лет.
Книга Брукса о людях.
Инструменты подтянулись. Установив какой нибудь решарпер, вы можете умножить эффективную производительность раза в полтора.
Не имеет ровным счетом никакого значения.
Ибо «какой-нибудь решарпер» доступен всем одновременно.
И такая же разница между разными людьми сохраняется, что с решарпером, что без.
P.S.:
Да и вы как-то наивно полагаетесь в повышении производительности «аж в полтора раза» на решарпер.
Имхо, более опытный, или просто более настойчивый чел будет более эффективен в более привычном ему notepad, чем неумеха на решарпере.
Один из самых производительных коллег, на вовремя сданные результаты работы которого можно всегда положиться — еще с прошлого века программирует исключительно в FAR. И из вспомогательного разве что раскраску кода использует.
При временно-вынужденном переходе в IDE производительность у него на 3 месяца упала. Он был настойчив. Но 3 месяца!!! Плюнул. Вернулся обратно в FAR.
Был бы ящик — книг бы не было.
Это все советская система распределения — тираж книг распределялся по республикам и областям. Соотв. подобные книги в Москве, Питере, Новосибирске и пт улетали зачастую не дойдя до прилавков, а в какой нибудь солнечной Молдове лежали и никому не были нужны.
1) Джуниор занимает время не только куратора (опытного человека из своей команды), он занимает еще очень много времени у остальных — QA, девопсов, просто более общительных людей, чтобы выяснить довольно банальные вопросы. В сложных проектах простой онбоардинг может занять в 10 раз больше времени, потому что джун не всегда способен самостоятельно пройти newcomers guide
2) С другой стороны, сейчас джуниор это совсем не джуниор 10-20 лет назад, до возникновения этого безумия с инфобизнесом и курсами, когда на должность джуниора претендует человек вообще без ИТ бэкграунда, у которого за плечами только несколько месяцев интенсива. Даже банальное программирование кликеров в школе, какие-нить читенжины или артмани для сапера — уже дают прирост к тому, что такой человек после курсов будет лучше, чем тот, у которого до курсов было разве что пару формул в экселе.
Понятно, что действительно непросто собеседовать джунов, если отдать это на откуп в HR отдел, но есть вполне адекватные джуны, которые быстро вырастают в полноценных специалистов и окупаются гораздо быстрее, чем за год. Тут вопрос есть ли ресурсы у компании на отфильтровку.
сеньор с зарплатой 3 попугая решит задачу за 1 день
джун с зарплатой 1 попугай не решит задачу за 3 дня
более того, он ее ВООБЩЕ НИКОГДА НЕ РЕШИТ
так что сэкономить (заголовок статьи) не получится, и всю статью можно свести к одной мысли, высказанной в ней: баланс в 3 сеньора + мидл + джун
именно!!!
поэтому и соотношения такие, 1:3 а не 3:1
Я своими глазами видел полную команду джунов без единого синьора :)
Для очень многих случаев высокая квалификация и не нужна.
Знаю, что бытует такое заблуждение, что «нужно нанимать крутых перцев и тогда будет крутой результат», но это верно только с технической точки зрения.
С точки же зрения бизнеса, то есть с точки зрения зарабатывания денег технически крутой результат далеко не всегда нужен.
Ну как пример:
Зачем делать «сайт-визитку из десятка статических HTML-страничек на кластере Kubernetes»
Многие нужные для зарабатывания денег вещи вполне способен сделать и джун. Задач уровня сайт-визитки у бизнеса полным-полно.
А использование сеньора только увеличит себестоимость проекта в разы без увеличения дохода.
оставшиеся джуны стали тянуть проект на себе, пользуясь хорошим заложенным фундаментов от старых разработчиков.
Да, это нормально.
Сначала проект создают более квалифицированные разработчики, а потом разработчики попроще уровнем этот проект благополучно поддерживают.
И, можно сказать, делали это довольно успешно (с точки зрения руководителей), пока спустя 6 лет проект окончательно не сдох под грузом костылей и технического долга.
Если проект все эти 6 лет приносил прибыль — разумеется он был успешен.
Ну а через 6 лет бизнес-требования могли измениться более чем значительно. Не факт, что с этим справились бы на старом ПО и старые высококвалифицированные разработчики.
И, к слову, за 6 лет, если ты не совсем дурак, то ты уже далеко не джун, даже если 6 назад пришел в эту фирму джуном.
А в отношении твоего глубокого знания этого конкретного проекта — пожалуй даже что и более сеньорист, чем тот, кто видит этот проект первый раз в жизни, независимо от исходной квалификации того новичка.
И, к слову, за 6 лет, если ты не совсем дурак, то ты уже далеко не джун, даже если 6 назад пришел в эту фирму джуном.
Как человек, наблюдавший все это изнутри и бывший одним из этих джунов много много лет назад, могу сказать, что к сожалению это не так. Потому что когда джуны варятся в собственном соку, им некому рассказать и показать как правильно и как неправильно
Если к каждому джуну приставить индивидуально сеньора, который будет его тянуть, то джун уже через год может и миддлом стать
Но если джун самостоятельно за 6 лет не стал хотя бы начинающим миддлом — то это профнепригодность. Чай не в 20-м веке живет. Полно информации по ИТ вокруг над и в интернете всегда можно спросить.
В зависимости от структуры проекта это это могут быть вспомогательные задачи на которые слишком дорого ставить сеньора
Технологии написания CRUD меняются каждый год. Наоборот, очень сложно подключить джуниора. Или ещё best practices на технологии не наработаны, либо это такое говно мамонта, что лишняя опечатка приносит кучу времени на поиск и отладку.
CRUD программировать тоже надо с умом. Допустим, что база данных у нас на SQL Server, а Front-End, который с ней работает, написан на C#. Для программирования CRUD-функциональности можно для каждой CRUD-операции создать хранимую процедуру в базе данных и вызывать эти процедуры в C#-коде.
Сейчас, конечно, в связи с широким распространением ORM типа Entity Framework или Hibernate так уже не делают. Но 15 лет назад такая манера имплементации CRUD была типичной.
Допустим, что у нас в базе данных 100 таблиц. Для каждой таблицы нужно вручную написать 4 хранимых процедуры + код на C# для вызова этих хранимых процедур.
Допустим, что для создания кода для одной хранимой процедуры нужно полчаса (а может быть и больше, если вместе с тестированием). Тогда для написания всего кода нужно 200 часов. Джуниору наверняка еще больше времени понадобится. Допустим, что ему понадобится примерно 340 часов (2 месяца работы).
Как эту задачу будет решать Senior? Можно написать программу, которая читает структуру таблиц базы данных и на основе этой информации генерирует как код хранимых процедур, так и C#-код для их вызова. Для написания такого кодогенератора нужно потратить где-то неделю времени.
Собственно, я так и поступил в одном проекте в 2005 году.
То есть получаем неделю работы вместо двух месяцев.
Далее, при изменении структуры БД Junior будет опять вручную имплементировать все изменения, а Senior просто запустит свой кодогенератор и сгенерирует весь код. При этом вручную написанный код надо еще тестировать, а сгенерированный нет.
Сейчас у меня ушло бы на это еще меньше времени. У меня сейчас есть мной написанная программа на C#, которая считывает все метаданные из базы данных SQL Server (структуру таблиц и т.д.). На ее основе такой генератор кода можно написать за 1-2 дня (что я и делал для другой задачи в прошлом году).
Итого получается, что даже на простых задачах типа CRUD производительность Senior в 20 раз выше производительности Junior.
Итого получается, что даже на простых задачах типа CRUD производительность Senior в 20 раз выше производительности Junior.
Если мы говорим не о 2005-м годе, то сейчас задача джуниора — нажать «New Controller», выбрать модель, и придумать ему название. Я не уверен, что для этих действий ему понадобится в 20 раз больше времени, чем сеньору.
А если мы говорим про 100 таблиц, и даже если там процедуры используются, то обычно делают так: сеньор даёт образец для одной таблицы, джун делает остальные 100 по образу и подобию. Да, первые две-три он будет делать долго. Потом — быстро.
Junior будет опять вручную имплементировать все изменения
получается, что даже на простых задачах типа CRUD производительность Senior в 20 раз выше производительности Junior
Ага, придумали такого джуниора, который подходит для доказательства идеи, и доказали идею.
Джуниор на 10-й однотипной функции тоже возьмет и напишет генератор. Потому что это задача уровня лабораторной в универе. Собственно, я так и сделал на своей первой работе для разметки интерфейса формочек на Delphi, для того самого CRUD.
Притом, что я далеко не самым способным джуном был. Чувак, которого брали вместе со мной, написал софтину для обхода корпоративного файрвола. А когда его за это уволили, бизнес на ней открыл. Так что как по мне, возможности замотивированных джунов тут слегка преуменьшают.
Вы говорите об редких исключениях.
А «преуменьшают возможности» — совершенно среднего джуна.
P.S.:
Даже то, что вы здесь завсегдатай-писатель — это уже исключение из основной массы ИТ-шников.
Но при этом не такое уж и исключение, если рассматривать множество таких же как и вы многопишущих здесь в комменты.
Вы говорите об редких исключениях.
А «преуменьшают возможности» — совершенно среднего джуна.
Ну что такое «средний джун»? Из тех, которые приходят на собеседования? Ну да, средний из них в «Hello, World» сделает семь ошибок, двадцать предупреждений. Если же брать тех, кто после собеседований остаётся работать, там далеко не всё так грустно.
Даже то, что вы здесь завсегдатай-писатель — это уже исключение из основной массы ИТ-шников.
Даже читатель Хабра — исключение из основной массы ИТшников. Но полагаю, у подавляющего большинства из нас есть какой-то любимый сайт (или два-три), и какой-то любимый способ отвлечься за компьютером.
Нужно иметь несколько своих сеньёров и кучи джунов которые должны быстренько расти под присмотром сеньёров, из тех же универов каждый год кучи способных джунов выходят, нужно просто отсеивать их и оставлять тех кто эволюционирует, ну и не забывать зп поднимать, а то научившись они свалят.
В конечном итоге, нет сеньора, можно взять мидла, нет мидлов, ну тогда джуниоров. На безрыбье и рак рыба.
Имею опыт по 100 откликов джунов за 2 дня на вакансию, среди них достойных очень не большой процент.
Расскажите, как именно вы определяете достойных?
Тем не менее используем стандартный подход задающейся целью лучше не взять достойного, чем взять не достойного.
Начинается все с простейшее тестовое скриниг задание в HH тестах. На результат не смотрим (отсеиваем тех, кто не готов потратить 5 минут, а не просто веерно рассылает), смотрим на другое.
У человека в резюме только полгода онлайн курсов и стандартный гитхаб с курсов(калькулятор, mvc что-нибудь)? Скорее всего не достоен.
Профильное образование среднего вуза, но больше ни слова? Даже какая выпускная работа была или средний бал? Ну хотя бы, что то, что могло отличить резюме среди миллиона других безликих — скорее всего тоже не достоен.
Ок, есть профильное образование/хороший вуз/подходящая специальность/резюме цепляет чем то другим, даем простое тестовое задание с возможность выполнить дома с ориентировочным временем выполнения 40 минут — 2 часа. Описываем ожидания от консольной программы(Что бы запускалась и выдавала правильный результат в первую очередь).
Запускается, выполняет правильный результат? Зовем на собеседование. Обсуждаем, уже то, как написано, почему, какая мотивация, говорим за жизнь и технологии. Если не сразу нет уже на собеседование — то достоин.
Тем не менее используем стандартный подход задающейся целью лучше не взять достойного, чем взять не достойного.Так может в этом и проблема отрасли? Может никакого дефицита кадров не будет, если компании перестанут бояться нанимать людей?
У человека в резюме только полгода онлайн курсов и стандартный гитхаб с курсов(калькулятор, mvc что-нибудь)? Скорее всего не достоен.То есть человек умеет пользоваться гитом, имеет опыт написания своих мелких проектов, пусть и стандартных, но все равно «не достоен» быть джуном в вашей компании.
Советую вам поумерить свой гонор.
Но есть человек умеет пользоваться гитом, имеет опыт написания своих мелких проектов, пусть и стандартных, но все равно «не достоен» быть джуном в вашей компании.
Проекты конечно же не свои, а те что на курсах сделал. По ним нельзя определить совершенно ничего. У всех стандартные Spring. Перелицовка стандартных демо примеров.
Извините, бомбануло.
Много у кого бомбануло Вы безумны, остановитесь пока не поздно
Такая позиция взялась не просто так, а на основе опыта общения. Да, среди них могут быть изумительные программисты и в моих командах есть такие примеры, когда человек без профильного образования и даже без высшего образования стал хорошим программистом. Но у меня нет ресурсов, что бы таких людей выявлять. Из 100 кандидатов — 80 клонов после курсов. Да и как сравнивать? Знаний у них нет, есть только то, что успели впихнуть за полгода. Пишут все одинакового плохо. Да и сколько времени потребуется, что бы достичь хотя бы уровня из ВУЗа? Одно время давали задачи вообще не связанные с программированием. Но особой точности в выборе не добавило. Зачем их рассматривать если их обработать я всех все равно не могу, но за то могу уделить внимание тем, кто хоть как то привлекает внимание.
Профильное образование среднего вуза, но больше ни слова? Даже какая выпускная работа была или средний бал?
А какие слова там должны быть у джуниора? Это нормально, когда у выпускника вуза кроме вуза ничего нет. Даже если он полгода назад выпустился, потому что без опыта не берут никуда. Я вот даже про год армии в резюме писал на всякий случай, чтобы не возникало вопросов, почему я больше года назад вуз закончил и еще нигде не работал.
Тему диплома я указывал, но нам еще в универе говорили "ваш диплом никому не нужен". Вполне возможно, что кто-то ее поэтому и не пишет в резюме. А уж средний балл мне и в голову не приходило указать. По программированию отл., по философии трояк, среднее четыре. А если наоборот, то тоже получается четыре.
Про средний вуз это вообще смешно. От места обучения языки и принципы программирования меняются? Толковый джуниор отличается от нетолкового тем, что сам в этом может разобраться, ему не требуется чтобы учитель из хорошего вуза это показал.
Ну хотя бы, что то, что могло отличить резюме среди миллиона других безликих
Ну вот тут у вас и есть основная ошибка. Толковые джуниоры они как раз по резюме ничем не отличаются от других. Опыта же еще нет, что там писать. Вы ищете каких-то особенных джуниоров, потому и процент у вас небольшой.
даем простое тестовое задание с возможность выполнить дома с ориентировочным временем выполнения 40 минут — 2 часа
Раз можно делать дома, то можно сразу указать его в вакансии и не проверять вручную миллионы безликих резюме.
Что бы запускалась и выдавала правильный результат в первую очередь
Тут согласен, для джуниора нет большого смысла проверять красоту кода и архитектуру. Он так пишет не специально, а потому что не знает как надо. Если есть сомнения, можно указать на ошибки и попросить доработать. Но все-таки надо напоминать, что главное не только "чтобы работало". Для меня вот это в первое время было неочевидно. Не всегда в задании пишут про нормальное оформление. Работает же, чего еще надо.
На мой взгляд, толковых/достойных джуниоров отличает интерес к разным областям и к программированию в целом. Надо спрашивать, чем интересовался во время учебы, какие программы писал самостоятельно, не связанные с учебой. Это я по себе пишу, опыта найма у меня нет, но мне сложно представить, чтобы тот, кого называют толковым джуниором, никогда не писал программки для себя, просто потому что интересно.
А какие слова там должны быть у джуниора? Это нормально, когда у выпускника вуза кроме вуза ничего нет. Даже если он полгода назад выпустился, потому что без опыта не берут никуда. Я вот даже про год армии в резюме писал на всякий случай, чтобы не возникало вопросов, почему я больше года назад вуз закончил и еще нигде не работал.
Нет. Не соглашусь. Это не нормально. Исключения бывают. Но если человеку вообще нечего сказать в резюме кроме [X]ГУ, 2020. Это не нормально. Тут не только опыт, но и логика говорит, что не эффективно на таких кандидатов тратить время. Чаще всего я не представляю вообще, какая у человека была учебная программа, что он знает, что не знает. С скорее предположу, что звезд с неба не хватал, активности не проявлял, в программисты попал случайно.
Про средний вуз это вообще смешно. От места обучения языки и принципы программирования меняются? Толковый джуниор отличается от нетолкового тем, что сам в этом может разобраться, ему не требуется чтобы учитель из хорошего вуза это показал.
Мне не смешно, а грустно. Бывает даже грустно за ИТМО.
Раз можно делать дома, то можно сразу указать его в вакансии и не проверять вручную миллионы безликих резюме.
В вакансии есть простой тест. Тут конечно можно поиграть с вариациями, сложностью и автоматизацией проверки результатов.
Но если человеку вообще нечего сказать в резюме кроме [X]ГУ, 2020
С скорее предположу, что звезд с неба не хватал, активности не проявлял, в программисты попал случайно.
Тогда повторю вопрос, который вы проигнорировали — какие слова там должны быть у человека, которых звезд с неба хватал, активность проявлял, в программисты попал из интереса, учился в вузе и не забивал на учебу?
Бывает даже грустно за ИТМО.
Ну так ведь это и доказывает, что от вуза ничего не зависит.
В вакансии есть простой тест.
Я говорю не про простой тест, а про тот, который вы даете после поиска цепляющего резюме. И предлагаю его давать до поиска. Выполненное задание и позволит отличить резюме среди миллиона других безликих.
С скорее предположу, что звезд с неба не хватал, активности не проявлял, в программисты попал случайно.Повторюсь: поумерьте свой гонор. Вы не фаанг и даже не Яндекс, чтобы отсеивать «не хватавших с неба звезд».
Повторюсь: поумерьте свой гонор. Вы не фаанг и даже не Яндекс, чтобы отсеивать «не хватавших с неба звезд».
С формулировками вашего оппонента не согласен, он него за километр разит… гм… ошибками во мнениях, проще говоря он полный дилетант в сфере про которую написал статью, сам только только начинает «входить в HR для айти»…
Но и ваши слова про гонор и Яндекс также не имеют связи с реальностью.
Я вас уверяю — в публично не известную мелкую фирму в российской глубинке приходит по 60 человек претендентов на одно место. Из моего опыта.
И, по большому счету, это никакой не строгий отсев, так как из 60 человек — 55 являются просто «желающие войти-в-айти на халяву без каких-либо даже намёков на знания», а вовсе не потому что отбор слишком жесткий.
Жёстким конкурс делает только количество желающих.
Ну а так чтобы уровень был «из кого можно выбирать» — это 2-3 человека из 60.
Цифры взяты из реального поиска на реальную вакансию.
Вам тот же вопрос — по каким критериям вы отсеиваете и как определяете, из кого можно выбирать? Вы ниже пишете "беседа", но это слишком общий ответ, интересны детали.
Вам тот же вопрос — по каким критериям вы отсеиваете и как определяете, из кого можно выбирать? Вы ниже пишете «беседа», но это слишком общий ответ, интересны детали.
Ваш вопрос неконкретен.
Какая должность, какие функциональные обязанности, кого мы ищем?
В общем и целом на беседую на темы непосредственно вокруг того, с чем ему предстоит работать и сопутствующие вещи.
Причем это не означает, что меня интересуют все непременно верные ответы.
Интересуют рассуждения.
Ибо наличие абстрактного мышления и умение производить декомпозицию — это всенепременная необходимость для работы разработчиком.
Допустим ищем джуниора-программиста после вуза на проект, в помощь текущим разработчикам.
А можете какой-то пример привести, ну там вопрос который обычно задаете, какой ответ хороший, какой плохой?
Допустим ищем джуниора-программиста после вуза на проект, в помощь текущим разработчикам.
Полностью я никак не приведу вам всю беседу. Это же должен быть именно что диалог. Но попытаюсь хотя бы частично идеи изложить.
Ну начнём с того, что я вообще не буду искать программиста именно в такой формулировке «после ВУЗа» и «в помощь»…
Мне всегда нужен именно программист, который делает свою часть работы. Какую-то свою конкретную часть. А не абстрактный «помощник».
А уж после ВУЗа ли он — как показала моя практика — гарантий квалификации никаких не дает.
Во-вторых, очень часто путают понятия «джуна» и «стажера». Вот типичный «после ВУЗа» как раз будет ничего не умеющим стажёром. Есть небольшое число исключений — тех, кто программированием увлекается со школы.
А можете какой-то пример привести, ну там вопрос который обычно задаете, какой ответ хороший, какой плохой?
Джун:
Для начала прошу рассказать о конкретных аспектах использования технологии, про которую джун рассказал, что знаком с ней (в разговоре или резюме). Причем не о каких либо тонкостях, а именно о базовых вещах этой технологии — это важно. То есть о вещах, с которыми ты 100% сталкивался, если реально имеешь хоть минимальный опыт работы с упомянутой технологией.
Cкажем, если речь идет о каком-то фреймворке с жестким расположением или определенном формате файлов — спрашиваю об этом формате файлов/расположении. Ну скажем для React это был бы вопрос про JSX.
На подобных нюансах запросто прокалываются те, кто названия технологии только слышал, но в реальности с ними не работал.
При этом неправильные ответы по началу даже не указываю, это важно. Просто продолжаем беседу. В конец концов, ошибиться может любой. И я в том числе.
Но вот когда таких простейших нюансиков, которые человек 100% видел бы, если работал с данной технологией, накапливается много — делается вывод, что это не стресс, не отдельные пробелы в знаниях. Скажем, политкорректно — не совсем правда в резюме. Обратите внимание, при этом претендент не «гоняется» по сложным вещам.
Далее начинаем общие беседы о ИТ-технологиях. Цель — выяснить имеющийся кругозор.
Обратите внимание, всякие тесты «а запрограммируйте сортировку методом QuickSort» и вопросы «расскажите подробно об уровнях изоляции транзакций» — не используется вообще никак.
По стажёру:
Только беседы по кругозору как описано выше.
Не понятно зачем умерить гонор. Вы же не знаете ничего о команде и продукте. И далеко не все хотят в Яндекс. Я, например, совершенно к нему спокоен. Да, я беру одно из 300 и не вижу в этом проблемы. И собственно говоря нет проблемы взять джуниора, проблемы начинаются дальше.
Профильное образование среднего вуза, но больше ни слова?
Не влияет вообще ни на что.
Запросто приходят на собеседование люди без такового образования и они более квалифицированные, чем закончившие ВУЗ даже и профильный.
И я не против поговорить с такими людьми, но дайте в резюме хотя бы намек, что вы программист, а не человек решивший, что надо что то в жизни менять и побежал куда ветер дует.
Расскажите о ваших критериях и количестве откликов? Абсолютно всех зовете на собеседование или даете задание?
Профильное образование среднего вуза, но больше ни слова?
Не влияет вообще ни на что.
Раз в год и палка стреляет. Знаю такие случаи.
В разработке — наааамного чаще, чем «палка стреляет», люди без образования попадаются эффективные.
если каждый день по 50 откликов в небольшую команду и нет отдела надрессированных HR'ов
Выявление профессиональной квалификации — не дело HR.
HR может только черновой предварительный отбор произвести на предмет общечеловеческой адекватности.
А собственно профессиональные навыки могут проверить только будущие коллеги, а на HR.
Расскажите о ваших критериях и количестве откликов? Абсолютно всех зовете на собеседование или даете задание?
Самые никакующие резюме — в мусор.
Резюме сколько нибудь похожие (даже отдаленно похожие) на то, что нужно — на собеседование.
Никаких заданий и т.п. формальных тестов. Беседа. Только. Свободная беседа.
Имею опыт по 100 откликов джунов за 2 дня на вакансию, среди них достойных очень не большой процент.
Расскажите, как именно вы определяете достойных?
Легко по беседе.
Из моего опыта собеседования потенциальных коллег — из 60-ти претендентов — 2-3 адекватных, среди которых и осуществляется конечный выбор.
Остальные, такое впечателение, что просто случайно зашли на собеседование по профессии разработчик или админ.
Ну например:
Вакансия — «администратор удаленных серверных Linux-систем, командная строка только» (там было еще про удаленную настройку и диагностику оборудования на Linux-системах, но детально я вакансию тут уже не опишу, давно было). Оклад в пересчете на нынешние деньги около 120-160 тыс. рублей.
На вопросы уровня «Зачем нужен шлюз в настройках IP» не ответило 50 человек из 60 претендентов. Это без художественного преувеличения, так и было. У лучших был опыт «Установил Windows сам» (не Linux).
И нет, это не стресс. Мы же не звери, чтобы издеваться. Были заданы и другие столь же простые вопросы, прежде чем сделать выводы «человек ни в зуб ногой в администрировании».
Обратите внимание, речь еще не пошла о сколько нибудь сложных вещах, для которых нужна действительно квалификация. Речь шла о примитивном. Оно большая часть претендентов уже не годится.
Действительно знакомы «с администрированием Linux» оказалось что-то около 5 человек, но это с учетом того, что один из них «администрировал только через GUI, командную строку не видел никогда».
Из них относительно достаточной квалификации для вакансии по итогу всего 2 или 3.
На вопросы уровня «Зачем нужен шлюз в IP-адресе» [...]
На вопрос «Зачем нужен шлюз в IP-адресе» невозможно ответить правильно, потому что это вопрос из серии «Как давно вы перестали пить коньяк по утрам».
В IP-адресе нет «шлюза»; IP-адрес — это скучный набор битиков, 32 (IPv4), или 128 (IPv6), по которому IANA сопоставляет железяку — запросу. Или не сопоставляет, если битов 32, и они попадают в один из диапазонов 10.0.0.0/8, 172.16.0.0/12, или 192.168.0.0/16.
Шлюз тут вообще не в кассу, а в случае IPv6 — так и вообще не нужен..
На вопрос «Зачем нужен шлюз в IP-адресе» невозможно ответить правильно, потому что это вопрос из серии «Как давно вы перестали пить коньяк по утрам».
У меня не так написано, не нужно добавлять отсебятину, следует цитировать собеседника точно.
Вы добавили всего одно слово к моему тексту — и уже смысл совсем другой.
Работа с глупыми бесправными людьми всегда выгоднее с политической точки зрения.
Должна быть очень высокая норма прибыли, чтобы эту выгоду перебить.
В статье рассматривается способ экономии на джунах в который верят мечтательные неопытные руководители и сами джуны: «давайте возьмем человека в боевую команду разрабатывающую новый продукт, он там быстро вырастет». На моем опыте я нигде не видел чтобы это хорошо работало.
Подход же, в котором джуны выгодны, куда менее альтруистичный.
Это проекты на которых не стоит выбор «наем профессионала вс джуниора». Это проекты на которых стоит выбор «наем джуниора вс никого». Обычно это проект на последних стадиях жизненного цикла: лошадь, которая почти сдохла, но может еще принести денег, пока растет новая. Что-нибудь, что решено закопать и переписать. Но пока не закопали, иногда надо делать мелкие доработки.
Опытные разработчики, на то и опытные, они такое видели и сманить их на такие проекты очень тяжело и дорого. А джуны не знающие рынка (а и иногда и просто жизни), плохо понимающие актуальный техстек и измученные конкуренцией — на такое идут.
Для джуна это в общем-то не так плохо, если это первое место работы и продолжать нарашивать свою техкомпетенцию на стороне.
Менеджмент обычно понимает что идет: джуны дешевые, продукт приносит деньги. Матожидание положительно получается. Подержат его джуны на плаву — джек пот. Не подержат — невелика потеря.
Главный риск такого подхода для бизнеса — сложившийся продукт нередко содержит немаленькое чувствительной информации клиентов. Туда конечно неопытных бойцов допускать нельзя: добавив дырку в безопасности или напортачив в боевой базе джун обнулит всю экономию разом.
Джуниоров которые могут «вырасти во что-то за год» (подразумевая видимо миддла) на рынке труда чуть ли не меньше чем сеньеров.
.
Если человеку профа интересна и он сообразителен и заботится о проф. росте, то зачастую к моменту окончания (вуза, спецучилища, курсов) у него уже будет квалификация миддла, т.к. он уже будет иметь опыт работы, будет пройдена практика, будут свои пет проекты. А если и не будет еще, то у него будут интересные офферы в компании которые присматривают за этими учебными заведениями в целях отлова кадров.
.
Таким образом кто такой безработный джун?
Если это выпускник, то это человек которому не досталось оффера от серьезной компании и который не особо заботился о практике в учебном заведении. Какие основания ожидать, что найм на должность джуна что-то изменит в его отношении к программированию и у него внезапно попрет рост? Какой смысл нанимать такого человека?
Если это человек с опытом работы, то опять же — почему он до сих пор не вырос и какие основания ожидать, что он вырастет именно после найма вот сюда? Какой смысл нанимать такого человека?
.
Да, есть исключения. Самородки-самоучки без опыта работы, люди которым некогда было стажироваться т.к. они кормили семью, но в ИТ области это относительно небольшой количество людей и опять же — если они соображают, то через год-два они уже будут миддлами, поэтому в прослойке джуниоров они надолго не задерживаются и погоды не делают.
.
Поэтому имхо — для хоть сколько-нибудь важных проектов (а не текучки на от-сь и прочих, которые пусть тлеют, лишь бы не сдохли) больше смысла хайрить миддлов, т.к. шансы нанять хорошего джуна исчезающе малы в описанной ситуации.
.
p.s.: И да, то что сеньер работает в 10 раз быстрее — не согласны, лучше — да, но не быстрее Т.е. да, за 1 человеко час сеньер может сделать то, что джун не сделает и за 10. Но работа джуна не так утомляет, поэтому джун может тупить над кодом по 12 часов в день… а на уровне сеньора и 4 часа соображать достаточно тяжелое занятие. Поэтому сеньеры это все же больше о качестве, чем о скорости.
Таким образом кто такой безработный джун?
Да всякие бывают. На рынке навалом джунов, которые #вошливайти, проработав до этого где угодно, и либо разочаровавшись в предыдущей профессии, либо просто уйдя оттуда по финансовым соображениям. Мой товарищ стал программистом в 34 после того, как закрылся магазин, где он работал. Спустя пять лет, к слову, стал хорошим сеньором с соответствующей зарплатой.
Захардкодить текст сообщения это по книжкам?:)
Функция так-то вообще здесь отдельная не нужна, да и записать ее можно короче, но это реально зависит от стиля в проекте. Но зашить сообщение об ошибке прямо в js…
мои индусы все как на подбор сеньоры с более чем 10 лет опыта.DmitryLTL А не фиг индусам оплачивать исходя из количества строк кода:)
Захардкодить текст сообщения это по книжкам?:)
Если проект предполагает локализацию, то нет, не по книжкам. Если локализацию не предполагает, то представьте себе, хардкодить можно не стесняясь, а не тратить время и деньги на вынос текста куда-то, где его можно будет удобно и быстро править. А если вы считаете, что вот сейчас не нужно, а потом может быть нужно, то откройте для себя такое понятие как оверинжиниринг ;) И что в 90% случаев «потом» не наступает никогда, а потраченное время на создание более сложной, но «правильной» архитектуры — это бессмысленно потраченное время.
откройте для себя такое понятие как оверинжиниринг ;)С каких пор mvc это оверинжиниринг?:)
в 90% случаев «потом» не наступает никогдаУ нас другой опыт.
В 99% случаев заказчик на том или ином этапе начинает просить «а вот давайте delete на remove поменяем», поиграемся со шрифтами, поменяем цвета и так далее. И делать это в коде это треш по 100-500 разным причинам.
Вынести вшитый текст в переменную ресурсного файла — несколько нажатий клавиш, о каком времени и деньгах речь вообще?:)
А пятьсот строковых констант, и плюс ещё собственно какую-то либу для интернационализации под это дело настраивать?
С каких пор mvc это оверинжиниринг?:)
Текстовые константы в представлениях никак не противоречат паттерну mvc :)
В 99% случаев заказчик на том или ином этапе начинает просить «а вот давайте delete на remove поменяем», поиграемся со шрифтами, поменяем цвета и так далее. И делать это в коде это треш по 100-500 разным причинам.
Ну так мухи отдельно, котлеты отдельно. Стилям место в css, я ничего не говорил про их хардкодинг. А текстовые подписи — почему треш менять в коде, особенно если учесть, что в отличии от стилей, их переиспользуемость в приложении околонулевая? Наоборот, ткнул в нужное место, поменял. В случае ресурсов вы ведь делать будете ровно то же самое, только на один шаг больше — ткнул в нужное место, перешёл к соответствующей константе, поменял.
А пятьсот строковых констант, и плюс ещё собственно какую-то либу для интернационализации под это дело настраивать?Затрудняемся прокомментировать, т.к. не видим проблемы. Вынос в strings делается автоматом IDE, какая разница 500 их там или 1500 или 10? Либа для интернационализации? Просто нужный strings подключается.
Текстовые константы в представлениях никак не противоречат паттерну mvc :)Так мы и говорим что текст надо не хардкодить, а в константы выносить. Потому что текст это как раз view, даже если он без div/table и прочих cite
А текстовые подписи — почему треш менять в коде,Простая смена текста должна быть операцией не влияющей на работоспособность кода. Завтра ИТшник заказчика поменяет там delete на 'delete' и привет работоспособности фронта. Простые операции должны быть простыми и не влиять на работоспособность.
Ну так мухи отдельно, котлеты отдельно.Поэтому текст должен быть отдельно от кода:)
p.s.: Особенно доставляет работать с движками со вшитым текстом на арабском или китайском, полный алес капут.
А пятьсот строковых констант, и плюс ещё собственно какую-то либу для интернационализации под это дело настраивать?
Затрудняемся прокомментировать, т.к. не видим проблемы. Вынос в strings делается автоматом IDE, какая разница 500 их там или 1500 или 10? Либа для интернационализации? Просто нужный strings подключается.
А еще в правильное место положить этот файл при deploy или сборке и настроить соответствующий скрипт/конфигурацию.
Если вы начинаете работу с базового шаблонного проекта, где всё это уже реализовано — и нужно только прописать эти строки во ресурсном файле, что подцепится сам, то почему бы и нет.
Однако, если это нужно делать самому вручную — профессиональнее будет не делать, если согласно задаче это не нужно.
Совершенно согласен с вашим оппонентом — если это осознанно не нужно проекту, то это не нужно делать.
Основное преимущество это не интернационализация, а возможность безопасно менять текст, отдать эту функцию непрофессионалу и упростить деплой.
Окупает себя по времени это буквально за 3-4 правки текста, поэтому смысл имеет в абсолютно любом проекте, кроме пет проектов.
Вы так говорите, как будто это задача для сеньера на неделю:) Это простейшая задача решаемая преджуниором за полчаса… а если проект уже на mvc, то даже отдельное решение писать в общем не нужно.
Спроектировать deploy-то — полчаса? И вы доверите это преджуну?
Повторюсь: если вы стартуете проект с уже готовым шаблонным решением, где размещение ресурсного файла со строками уже решено за вас и процедура деплоя универсальная подготовлена — это может быть целесообразно.
Если писать все это самому — то нафиг это делать, если это делать не нужно? И такого ненужного усложнения не одно и не 10.
Не забывайте умножить все эти «мелкие» ненужные усложнения на их количество при оценке итогового срока на который увеличиться работа.
Основное преимущество это не интернационализация, а возможность безопасно менять текст, отдать эту функцию непрофессионалу и упростить деплой.
Окупает себя по времени это буквально за 3-4 правки текста, поэтому смысл имеет в абсолютно любом проекте, кроме пет проектов.
А если не нужно менять безопасно, а вообще никак не нужно менять?
Есть ситуации, где доводы прямо обратные:
Разработчику гораздо удобнее видеть смысл надписи тут, по месту, в коде. И косяк в формулировке вы заметите сразу. И надпись, перепутанную с другой — сразу заметите.
Разумеется, если вы имеете дело с надписями на языке который не знаете, скажем, на языке суахили — так делать не следует.
Но если вы пишете проект для российского рынка (а русский вы знаете) и у вас в проекте нет выделенного человека, что занимается UX, то какой смысл отдавать делать надписи отдельному человеку.
Чтобы непрофессионал мог корректно эти надписи делать — нужно ему подробно объяснить (пусть не лично, а письменно) в каких именно случаях эти надписи выдаются. Какие там нюансы с местом, выделенном под их размещение, и с включаемыми в них переменными. А это есть дополнительная работа.
Повторюсь:
Когда это надо, когда в этом есть смысл — в этом есть смысл.
А огульно, не вникая в особенности проекта делать это, когда надо и когда не надо — это делают джуны, которые просто делают потому что «так положено», не понимая еще зачем это нужно. И когда это не нужно.
Для джуна это не просто простительно, а даже и обязательно — не принимать настолько значительных самостоятельных решений.
Но мы то с вами достаточно квалифицированы, чтобы самостоятельно принимать решения когда некая best practics имеет смысл, а когда в данном конкретном случае это же самое вовсе не best.
Никакой деплой при использовании констант проектировать не надо потому что код не меняется, а вот как раз при хардкоде текста в код как раз нужен деплой — потому что меняется код.
Смысл при использовании вместо 'thank you' чего-нибудь типа _('thank you') никуда не исчезает.
Для джуна совсем не сложно написать функцию возвращающую значение по ключу.
Непрофессионалу объяснить как исправить опечатку значительно проще, если все текстовые надписи в одном отдельном файле, чем непонятно где в коде, да и файл в несколько кликов можно сделать редактируемым из админки.
Ну и так далее… переусложняете.
Когда это надо, когда в этом есть смысл — в этом есть смысл.Разумеется. Так-то и в mvc не всегда есть смысл и в тестировании кода и в отдельном классе для доступа к БД.
Вы дико переусложняете ситуацию.
Никакой деплой при использовании констант проектировать не надо потому что код не меняется, а вот как раз при хардкоде текста в код как раз нужен деплой — потому что меняется код.
Смысл при использовании вместо 'thank you' чего-нибудь типа _('thank you') никуда не исчезает.
Полным полно ситуаций, когда в коде внутри удобнее.
Ну скажем у меня сервер, что пишет в лог и выдает надписи в стандартном виде XML.
отдать эту функцию непрофессионалу
И что тут можно отдать непрофессионалу в изготовлении надписей?
За меня формулировать надписи в логе или формат XML?
Зачем выносить надписи в лог в константы? Чтобы поиск их усложнить при отладке?
Основное преимущество это не интернационализация, а возможность безопасно менять текст, отдать эту функцию непрофессионалу и упростить деплой.
Вы, наверное, себе не представляете, как много в мире коммерческих проектов, в которых напрочь отсутствует потребность безопасно менять текст, и делегировать эту функцию всяким там контент-менеджерам. А многие разработчики ещё и деньги на этом поднимают, к слову.
После перехода на 14 Node не хочет работать в React (без реакта — пожалуйста), пол дня уже разбираю откуда Error: Config file /config/runtime.json cannot be read. Error code is: undefined. Error message is: FileSystem.readFileSync is not a function, причем не важно — установлена ли библиотека — ругается на
const config = require('config')А пишут (позавчера один такой написал на JS, прямо вот так как здесь, один к одному):
function confirmmsg(msg) { if(confirm('Do you want to delete the ' + msg + ' data?')) return true; else return false; }
Не знаешь смеяться или плакать. Не выдержал его лиду отписал, какого?
Смысла всегда экономить байты кода нет.
Код должен быть легким для понимания. А уж компьютер-то как нибудь переварит лишние байты кода, тем более что сейчас в моде у JS код пропускать через три-шейкинг и транспиляцию.
Приведенный вариант вполне себе целесообразен:
Его удобно отлаживать. Что включая брейкпойнты на отдельных строках, что вставляя логгирование, что комментируя отдельные строчки при отладке.
Помимо этого вариант в одну строку, как раз хуже, с учетом того что это JavaScript без указания типа возврата. И нам придётся предпринять дополнительные телодвижения, если необходимо будет выяснить тип, придется слазать в определение функции
confirm.
Смысла всегда экономить байты кода нет. Код должен быть легким для понимания
Согласен. Нужно экономить время разработчика при чтении и разбое кода. Но по такой метрике четыре строки с завуалированным смыслом против одной строки с явным намерением проигрывают всухую.
Его удобно отлаживать
Эта функция ведь где-то вызывается, почему бы именно там не делать отладку?
Чтобы вставлять логгирование и комментировать, в данном коде придется добавлять скобки. Тогда почему не добавлять отладку также, а на постоянной основе оставлять код чистым?
дополнительные телодвижения, если необходимо будет выяснить тип
Для этого должно быть что-то еще кроме такого кхме… кода. Может быть JSDoc и нормальная IDE?
Да и такая запись добавляет небольшой процент ошибки, если перепутать возвращаемые значения.
PS: Возможно не раскусил тонкого сарказма/троллинга.
Я вовсе не утверждал, что всегда нужно писать код именно в несколько строчек вместо одной.
Я всего лишь понимаю причины, по которым программисту показалось целесообразным оставить код именно таким.
Смысла всегда экономить байты кода нет. Код должен быть легким для понимания
Согласен. Нужно экономить время разработчика при чтении и разбое кода. Но по такой метрике четыре строки с завуалированным смыслом против одной строки с явным намерением проигрывают всухую.
Гы.
Как раз одна строчка вуалирует смысл.
Давайте вы мне расскажите что происходит тут?
return MySuperFunction('a', 'b', 42)А ведь наш пример еще и на языке с динамической типизацией — что там по факту возвращается нам и IDE не подскажет так просто и по описанию возвращаемого типа функции confirm мы не поймем.
Отдельные строчки явно выделяют смысл, а не вуалируют. И прекрасно подчеркивают тип.
Я не скажу что так следует делать всегда, но в данном конкретном примере как раз можно понять зачем это. Или зачем так не делать.
И именно осознанный выбор способа самим программистом в зависимости от конкретной ситуации и означает вашу высокую квалификацию.
Бездумное «всегда нужно делать так» или простое подражание старшим товарищами — это удел слабых или начинающих программистов. Причем я ничего не имею против: таким низкоквалифицированным, не понимающим еще что и зачем они делают — как раз лучше именно подражать более опытным товарищам.
Эта функция ведь где-то вызывается, почему бы именно там не делать отладку?
Вы считаете, что всю программу можно отладить отладив только самые глубоко лежащие в стеке функции? Вы серьезно?
Внутри функции confirm вы отлаживаете эту функцию confirm.
А в обсуждаемом коде внутри функции confirmmsg вы отлаживаете работу функции confirmmsg.
Чтобы вставлять логгирование и комментировать, в данном коде придется добавлять скобки. Тогда почему не добавлять отладку также, а на постоянной основе оставлять код чистым?
После того как вы окончили отладку, то логирование вы можете со спокойной совестью удалить. Это легко.
Например делается так:
Shift-End
Del
И код остается чистым и ясным (в моем понимании, не в вашем, разумеется).
Вы же предлагаете сделать примерно так для такого кода:
function confirmmsg(msg) {
if(confirm('Do you want to delete the ' + msg + ' data?'))
log('user confirm delete, msg = ' + msg);
return true;
else
return false;
}Shift+Down, Down, Down, End
Del
Up
End
;
Это всё доводы за мой вариант.
Но это не означает, что мой вариант нужно выбирать всегда. Нет.
Выбирать нужно в зависимости от ситуации (например, множество подобных удлиненных конструкций в и так длинной функции могут быть уже нежелательны — ибо там это действительно мешает читаемости; но в данном конкретном случае — это не мешает, а помогает читаемости).
А вот если программист пишет код типа такого, то это уже неприемлимо и никаких доводов «за» быть не может:
function confirmmsg(msg) { if(confirm('Do you want to delete the ' + msg + ' data?'))
log('user confirm delete, msg = ' + msg); return true; else return false; }Не выдержал его лиду отписал, какого?
Если бы мне на глаза попалось такое отписывание «его лиду», я бы лично приложил все усилия к тому, чтобы автор воззвания к лиду был уволен вчерашним днем.
Вы бы еще в Гаагский суд написали: ведь это целый джун породил целый кусок кода, который целому вам не понравился. Расстрельная статья прямо напрашивается.
Профессионал в таком случае поговорил бы с джуном напрямую, выяснил причины, поделился своими.
это работа их лида за ними прибирать и следить чтобы не расслаблялись
К сожалению, вы вообще не понимаете, в чем заключается работа лида. Бывает.
Поддерживать стиль кода и стандарты именования надо, иначе расползётся всё в говнокод.
Говнокод — это не про стилистическое оформление, вообще-то.
Ну а для стилистики единой — просто:
Для этого есть Code Style Guide. Какие то из них нужно принять в вашей фирме (или придумать свои).
И существуют утилиты, которые проверяют соответствие кода этим Code Style Guide. В том числе, например, автоматически проверяются на git-сервере при получении очередного commit. И commit может быть автоматически отвергнут, если не соответствует Code Style Guide.
А то, что невозможно проверить автоматически — проверяется через code review.
Но это code review — обычная работа для рядового разработчика. А вовсе не всенепременная обязанность исключительно лида, как вы ошибочно полагаете.
Вот когда вы делаете code review и у вас есть Code Style Guide — вы можете лично
Причем обратите внимание — не потому что «лично вам так кажется правильным». А потому что это формально закрепленно в Code Style Guide.
Некоторые говорят что в таком стиле и надо писать, может «он так видит», но думаю это в основном любители разговора от «обратного», пооппонировать
Если вы про меня и тот ваш пример, то вы искажаете.
Я написал, что вполне себе существуют основания, чтобы написать именно так. Но из этого вовсе не следует, что всегда надо писать так.
Писать так или эдак — это уже ваш осознанный личный выбор в той или иной ситуации. Обратите внимание — осознанный.
Поэтому кроме прямой оценки — всего в два раза медленнее, имхо, стоит учитывать затраты на сопровождение и поддержку этого кода. И на дистанции сеньор действительно получает преимущество в 5-7 раз.
На рынке очень много компаний-соковыжималок, для которых вечный круговорот джунов — это единственный ресурс. Собственно они сами этот круговорот и создают.
А если человек самообучился и свалил на место покозырнее — ну правильно сделал. Как иначе?
2) Джун джуну рознь, хороший джун из профильного вуза (не все кто их закончил — хорошие, не все кто их не закончил — плохие), которого готовят топ компании — очень ценный кадр и, как правило, знает себе цену. Несколько лет назад наняли парня на третьем курсе, зп 40 т.р. за полдня + премии периодические. Джун оказался максимально перспективным и делал работу качественно и быстро — через 3 месяца сбежал, т.к. руководство не понимало как можно спустя 3 месяца существенно поднимать зп студенту, да еще и на пол ставки. Но в другой компании оценили по достоинству. Сейчас все у него замечательно, конечно.
За прошедший год сделали двум хорошим выпускникам офферы, по 100 — 120 т.р. (Екатеринбург). Я был абсолютно уверен в них, что они будут не просто полезными, а нести золотые яйца. Не приняли. Нашлись те, кто предложил больше, либо более именитые компании, которые открывают возможность попасть в «высшую лигу», либо Москва/СПБ/доллары. А почему мы не дали больше (бюджет был)? Потому что, «ну не может выпускник столько зарабатывать, найдем за эти деньги сеньора/крепкого мидла, а выпускник — по определению джун, сколько бы у него стажировок не было» — такова позиция менеджмента.
Но, на мой взгляд, «свежий» сотрудник может оказаться ценнее мидла и тем более сеньора за эти и меньшие деньги. Ибо не только скиллы и опыт важны, есть еще энергия, авантюризм и бесстрашие, которых многим коллективам не хватает.
Но, на мой взгляд, «свежий» сотрудник может оказаться ценнее мидла и тем более сеньора за эти и меньшие деньги.
Или не оказаться.
Или оказаться таким, что до вашего сеньора ему еще 10 лет вприпрыжку квалфикацию догонять.
Всяко может быть.
Вы сейчас про выдающихся написали.
Но, в среднем, большинство довольно средненькое.
Эм нет. В моем случае разница между зп с которой я начинал и нынешней — в 11 раз. Ну и помимо чисто меркантильных интересов компании есть еще такой момент. Чтобы компании расти (и соответсвенно расти доходам владельцев компании) нужны новые квалифицированные сотрудники. Качество нашего образования нынче таково, что людей после универа, которых можно было назвать мидлом просто нет — все обучаются в полевых условиях. Поэтому позиция «мы не берем джунов, это не выгодно» — крайне недальновидно. Да — джун прокачавшись может уйти на лучшие условия. Но если вы нормально относитесь к своим работникам он уйдет без плохих впечатлений от компании и вполне может вернуться позже. А вот если большинство компаний не будут брать джунов в принципе в результате в отрасли не откуда будет брать новых специалистов и никакого роста не будет.
Видимо стажеров уже совсем никто не рассматривает набирать?
например по принципу «франчайзи»:
берём на работу много джунов и «продаём» их в другую контору по цене сеньора — профит :)
Мелкой конторе тоже хорошо если хватает пол программиста.
Все франчайзи 1С так работают.
Можно ли сэкономить, набирая junior специалистов?
Ещё как можно. Джуны неплохо ищут баги, чинят верстку и всякие несложные штуки, пилят несложный CRUD и админки.
Ещё момент — толковых джунов вы нанять сможете. Толковых синьоров вы не найдёте. В качестве иллюстрации — все топовые разработчики, которых я знаю, искали работу не более 2-3х месяцев за 15 лет. Можете посчитать ваши шансы найти такого.
Ну и конечно, нужно признать, что есть задачи, которые джуны вообще сделать не могут.
Как отличить плохого программиста от хорошего. Спросить его про документацию. Грамотно составленная документация выдает уровень
Так себе критерий, в свете того, что составление документации никоим боком не входит в список должностных обязанностей большинства программистов :)
Как отличить плохого программиста от хорошего. Спросить его про документацию. Грамотно составленная документация выдает уровень. Человек, который умеет писать документацию понимает, что он делает и как он делает. Джунов надо брать которые готовы читать документацию и хотят учиться ее писать. А «писать код в вакууме» — это не программирование, это зашквар
Это не уровень программиста.
А культура программирования.
Вещи не связанные.
У меня есть парочка знакомых сеньоров — в их код лучше не заглядывать, страшно.
Не потом что он крутой, а потому что он примерно как у человека после трехнедельных курсов по программированию.
Но зачастую я к ним обращаюсь как к фриленсерам, когда есть избыточная работа, с которой сам не справляюсь — ибо код, который они пишут — отрабатывает совершенно корректно и задачи решает совершенно гарантировано, я в результатах их работы уверен.
Существуют задачи, где специалисту сколько-нибудь серьезной квалификации делать нечего, он там не нужен (есть даже такое понятие «слишком оверквалифицированный специалист»).
И таких задач довольно много. Более того: существуют фирмы, где иных задач и не бывает.
Кроме самих задач для ответа на данный вопрос необходимо учитывать как именно организованы производственные процессы в фирме. Если имеется система контроля результатов работы джунов — то джуны могут быть полезны не только на тривиальных задачах.
Другое дело, что зачастую мы имеем ситуацию, когда джун должен учиться сам.
Тут могу только повториться: задач, где никаких особо страшных рисков для предприятия сие не несет, — довольно много.
Возьмите хоть эникейство:
При наличии админа, который не подпускает джуна к серверам — рабочие станции джун вполне может обслуживать. И никакой более квалифицированный админ там и не нужен.
Один сеньор может распараллелить работу, нагрузив трех джуниров задачами не высокой сложности, беря на себя более высокоуровневые и сложные задачи. Тем самым сделаем продукт, а заплатим меньше, хотя может и не столь идеально и быстро.
Ну это идеалистично.
Если вам не хочется переделывать за джунами, то больше двух вы не осилите в наставничестве даже в предельном случае.
В идеале лучше одного — ибо слишком много времени уходит за обучение и контроль за ними, если вы хотите действительно воспользоваться результатами их работы в настолько сложном проекте, для которого нужен настоящий сеньор.
Джуниору можно мало платить… А еще беря джуниора на небольшую ЗП, мы не подрываем устоявшиеся зарплатные планки внутри компании.
То, что джунов беспощадно эксплуатируют, платя им копейки — миф.
На мало-мальски серьезных задачах джуны настолько неэффективны — что это не столько экономия, сколько убытки.
На простейших задача — и платить больше смысла нет. Так как такую задачу вполне может выполнить низкоквалифицированный специалист.
То есть мы имеем не беспощадную и бесстыдную эксплуатацию бедных джунов, а рядовую экономическую целесообразность в найме низкоквалифицированных специалистов на несложные работы.
Платя мидлу, половина платы уходит в упомянутый выше базовый набор, а остальное уже в продукт. Ведь условно ЗП мидла — это две ЗП джуниора, а сеньора — 3 зарплаты джуниора. Таким образом, вместо двух сеньоров можно взять 6 джунов или 3 мидла. В случае 2 сеньоров, 2/3 зарплатного фонда идет в продукт, а 1/3 в базовый набор. В случае 3 мидлов — 1/2 зарплатного фонда идет в создание продукта и 1/2 в базовый набор. А теперь вспомним про кривую роста эффективности.
График построен на моем опыте. Принимаем допущение, что уровень программиста соответствует ЗП. Конечно же он выглядит не справедливым.
Ну это суммы притянутые к выводам.
Разница на самом деле в разы больше.
Однако дело не только в этом.
Зачастую нет работы для сеньора вообще, не требуется его квалификация.
Бывает, что нужен миддл, но нет достаточно большого объема и для миддла и платить ему за весь месяц расточительно.
Привлечение же фрилансеров на разовые работы несет дополнительные организационные издержки (это не считая того факта, что фринаслер изначально дороже своего постоянного), иногда это целесообразно, а иногда нет.
Поэтому ситуация когда джун эксплуатируется там где миддл немного перебор, но для джуна задача слишком сложна — встречается сплошь и рядом.
«Мифический человеко-месяц»:
Руководители программистских проектов давно уже поняли, как значительны различия в производительности хороших и плохих программистов. Тем не менее результаты точных измерений этой величины просто поражают. В одной из своих работ Сакмен, Эриксон и Грант измеряли производительность группы опытных программистов. Даже внутри этой группы отношение максимальной и минимальной производительности в среднем составило 10:1, а для времени работы программы и затрат памяти — 5:1. Короче говоря, производительность труда программиста, получающего 20 тыс. долларов в год, может быть в 10 раз больше, чем у того, кто зарабатывает 10 тыс. долларов. Обратное также может быть справедливо. Статистические данные утверждают, что нет никакой зависимости между опытом и производительностью. (Сомневаюсь, впрочем, чтобы это было верно всегда.)
Производительность не тождественная квалификации.
Пример:
Я сеньор, порядка 20 лет опыта.
Но я крайне ленив и крайне низкопроизводителен. При моем уровне зарплаты могу пинать балду неделями, реально.
Джун конечно меня в производительности не переплюнет.
Но средний миддл — запросто более производителен, чем я.
И только в редких работах миддл просто не сможет сделать ту работу, что могу сделать я. Однако это не производительность.
Профессионалу интересно работать с профессионалами, они тянутся друг к другу. Синергия их качеств рождает верные решения. Работа в интересной команде с интересным продуктом может привлекать не меньше, чем высокая оплата труда.
Но не тогда, когда 50% зарплаты уходит на аренду квартиры. Еще 40% на еду. А 10% на проезд. Покупка одежды или тортика — это уже праздник.
Моя реальность в начале карьеры.
И тут из выбора: «платят больше» или «платят меньше, но работа интересная, бок о бок с профессионалами» — угадайте что выберет человек?
В среднем, все же, армия состоящая только из офицеров неэффективна.
Нужна пирамида в 99% случаев. Но конкретный процент джуниоров и сеньоров зависит от специфики проекта. Понятно что если проект — обычная рутина с формочками, то при поставленном процессе там можно обойтись и без сеньора (даже надзирающего), а проект с серьезным исследованием, научной работой потребует большого количества сеньоров, но все равно джуниоров должно быть как минимум столько же — они будут выполнять "грязную" рутину, которая есть всегда высвобождая дорогое время сеньоров для более сложных дел.
Это с точки зрения просто выполнения проекта без прочих.
А с прочими еще хуже для сеньоров — ведь для бизнеса важна предсказуемость, надежность и тп Понятно что это стоит денег, но бизнес готов за это платить. А это означает что команда из нескольких сеньоров, даже если она эффективнее с точки зрения создания продукта, но она сильно уязвима с точки зрения недежности и предсказуемости. Представьте что один сеньор ушел в середине проекта. Уволился, заболел и тп И что? Полный пэ, потому что только он обычно в курсе того что он делал и на вникание в работу другому сеньору уйдет много времени. Поэтому в идеале для надежности и тп под каждым сеньором должны стоять 2 и более миддлов, и под каждым миддлом 2 и более джуниоров. Тогда потеря бойца на любом уровне не так страшна — его место займет кто-то из его непосредственных подопечных. Такая структура дороже, но надежнее и более предсказуемая в работе.
Но тут опять же приходится выбирать что важнее — одно дело разработка какой-нибудь фигни, а другое — разработка прошивки для баллистической ракеты — разные приоритеты, разные подходы.
Честно говоря, мне очень сложно представить простые проекты, где очень много рутины и простейшего линейного формошлепства. Мне это уже представляется задачей пользовательско-прикладного уровня. Но даже если допустить существование такого варианта, тогда я не понимаю, что за сеньор там будет работать? Зачем ему там работать? Скорее всего это будет сеньор и соответствующей не высокой квалификации, ну то есть вовсе не тот человек, о котором думают на хабре.
Ключевой момент, простота задачи чаще все может стать очевидна, только после ее выполнения. "До", по опыту, эта очевидность иллюзорна. Но если не брать и этот "факт" во внимание, то я бы еще вспомнил про сильную не эластичность в возможность жонглирования разрабами по мере продвижения проекта. Простые задачи могут появлялся и исчезать, а менять оперативно набор квалификаций в команде обычной компании сложно.
По поводу bus-фактора.
Я не думаю, что брать джуниоров это способ решения басфактора. Он решается по другому: открытая среда, общее обсуждение проблем, ревью кода, парное программирование, митинги и ретроспективы, документация и спецификации.
только он обычно в курсе того что он делал
По правде говоря, я думаю, это сигнал, о том, что консерваторию надо править.
Ведь если посмотреть этим же взглядом, на предложенный вариант, то получить, что если выпадет из обоймы в середине проекта тот единственный сениор, и останутся только его несколько джунов и мидлов, то точно будет полный швах. В противном случае, ну выпадет из обоймы один из трех сеньоров — проблемы не случится, у нас еще два "взрослых" человека на проекте.
В среднем, все же, армия состоящая только из офицеров неэффективна.
Я не сторонник аналогий, очень легко натянуть одно на другое и не заметить. Можно углубится и утонуть в сравнение профессиональной контрактной армии против срочников, задуматься о разных родах войск и спецподразделениях, об эффективности использования технический пепелацев в зависимости от того, в чьих руках они находятся. И задуматься, является ли сеньор аналогом офицера в армии, сеньор про компетенции, и совсем слабо пересекается с вопросами управлениям или понятием командный игрок.
Но даже если допустить существование такого варианта, тогда я не понимаю, что за сеньор там будет работать? Зачем ему там работать?
Минуточку, но вариант, который вам очень сложно представить — это 95% всего софта, на который работает индустрия. Мы-то видим регулярно лишь верхушку айсберга, всякие там операционные системы, мессенджеры, IDE и прочие популярные рабочие продукты, которые технологичны и сложны. Но подавляющее большинство из нас делает либо программы, которые решают всякие производственные/бизнесовые задачи, либо делают всякого рода веб-сайты/интернет-магазины. И да, это в основном как раз рутина и линейное формошлёпство. И им занимается и большинство сеньоров в том числе.
Возможно это ошибка выжившего, моя или ваше. В моем круге общения таких примеров не так много. Я думаю все эти многочисленные сайты делаются чаще не программистами, а пользователями используя готовый CMS или конструкторы сайтов.
Но если там можно делать все джуниорами, то это уже не "большая" индустрия: нет денег и конкуренции, и говорить об этом как то не интересно. Примерно как соревноваться с тем, кто и не собирался соревноваться.
Оффтоп:
делают всякого рода веб-сайты/интернет-магазины.
А потом у них интернет магазины, в которых изменение одной позиции фильтра приводит к рефрешу всей страницы.
Вы конечно же можете сказать, ну и пусть, главное, что бы выполняло задачи бизнеса. Конечно, вершины у бизнеса разные. Это их выбор или цель.
Ведь если посмотреть этим же взглядом, на предложенный вариант, то получить, что если выпадет из обоймы в середине проекта тот единственный сениор, и останутся только его несколько джунов и мидлов, то точно будет полный швах. В противном случае, ну выпадет из обоймы один из трех сеньоров — проблемы не случится, у нас еще два "взрослых" человека на проекте.
то есть по вашему если из трех "взрослых" убрать одного то с проектом ничего не случится? А зачем тогда их изначально было 3, а не 2?
То что они "взрослые" не делают их доступными — у них своя работа, отнимающая все время (если это не так, то чем тогда занимается их руководитель ?).
Обычная группа из сеньора + пары мидлов и 2-5 джуниоров имеет обычно следующее распределение — сеньор больше архитектор и пишет ключевые сложные куски, раскидывая более простые вниз и заодно обьясняя что и как в придуманной им архитектуре. Таким образом миддл даже если сам еще не может придумать аналогичное решение, то в середине проекта прекрасно понимает принцип и устройство конкретной архитектуры, придуманной сеньором и в рамках данного проекта вполне способен довести все до завершения (и возможно в следующем проекте уже быть самым настоящим сеньором, а может и еще нет). А вот другой сеньор конечно сможет разобраться и тп, но это время, да и где взять мгновенно свободного сеньора знакомого с конкретной спецификой — а это все сроки, бабки — бизнес страдает.
В принципе если все грамотно и идеально — сеньора можно и так снимать в середине проекта — он задал архитектуру, написал ключевые куски и дальше мидлы и джуниоры сами все добьют — нужно лишь приглядывать тратя немного времени, а ценное время сеньора можно тратить уже на другие проекты где надо придумывать архитектуру и тп. Но так редко случается да и при таком режиме через пару лет сеньор отправится в дурку. Поэтому обычно сеньор сидит весь проект и имеет время отдыха от мозгового штурма, занимаясь рутиной.
P.S.
насчет простых и сложных проектов могу привести пару примеров из личного опыта
- сложный — софтверная реализация OpenGL ES для телефонов — 1 сеньор + еще один сеньор временно прикомандирован. Потом был взят еще мидл для рутины — подготовка конформант тестов, прохождение сертификации и тп. Джуниора тут вообще не припахать — разве что чай приносить.
- простой — разработка образовательных игр для Nintendo DS
один сеньор и толпа джуниоров. Сеньор написал фреймворк на котором джуниоры клепали "формочки", точнее "задания/тесты". В принципе после первых проектов сеньора можно было смело снимать — некоторые джуниоры подросли до мидлов, способных править фреймворк/добавлять фичи.
то есть по вашему если из трех "взрослых" убрать одного то с проектом ничего не случится? А зачем тогда их изначально было 3, а не 2?
Что бы делать "на треть" больше.
Обычная группа из сеньора + пары мидлов и 2-5 джуниоров имеет обычно следующее распределение — сеньор больше архитектор и пишет ключевые сложные куски, раскидывая более простые вниз и заодно объясняя что и как в придуманной им архитектуре.
Обычно, не значит правильно или лучше, если быть критичным.
Мне больше нравится команды построенные по принципу самоорганизации, где все равны с точки зрения прав и перед логикой, но есть арбитр в виде лида. А ревью той же архитектуры кто будет делать? И сеньор не значит архитектор, это две разные роли, которые конечно могут совпадать. Но архитектор может быть один на сотню человек. Архитектор вообще может плохо мочь в кодинг, а вот у сеньора в моем понимание такой преференции нет. А еще сеньоры могут возразить, указать на ошибке в архитектуре, предложить решение лучше, устроить мозговой штурм, до собственно говоря миллион аспектов в пользу сеньора.
- пары мидлов и 2-5 джуниоров
Как раз вся статья про то, что если "+ пары мидлов и 2-5 джуниоров" заменить на сеньоров за те же деньги, то получиться быстрее и лучше. Зачем платить больше, если можно меньше в случае если брать сеньров?
Безусловно, сеньор центризм (или брать лучших) наверно подходит не для каждого бизнеса, а только для тех перед кем стоят актуальные вызовы, в виде конкуренции на техническом и пользовательском уровне. Возможно это больше присуще продуктовым компаниям.
Сеньор написал фреймворк на котором джуниоры клепали "формочки", точнее "задания/тесты"
Звучит как приговор. Мне даже джуниоров в этом случае жаль, интересно как много из них потом станет программистами?
Такое конечно может существовать и даже быть эффективным, но статья уж точно не претендует на общую практику для всех. Собственно говоря бедные компании тоже должны быть, что бы могли существовать богатые.
Мне больше нравится команды построенные по принципу самоорганизации, где все равны с точки зрения прав и перед логикой, но есть арбитр в виде лида. А ревью той же архитектуры кто будет делать?
Извините, но звучит как мнение со стороны разработчиков, а именно озвучивание того как было бы приятно разработчику. Попробуйте посмотреть со стороны бизнеса — сроки, бюджеты, риски и тп.
В 95% реальных проектов ревью архитектуры которую создал текущий технический лид/сеньор/архитектор не делает никто — конечно нижестоящие(те кому это все реализовывать) могут критиковать, предлагать и тп.
Звучит как приговор. Мне даже джуниоров в этом случае жаль, интересно как много из них потом станет программистами?
Примерно половина стала маститыми сеньорами/лидами. С одним из них у нас сейчас совместный программерский бизнес.
Непонятно почему жаль — у них была отличная возможность поработать на реальных проектах(со всеми "прелестями" типа жестких сроков, меняющихся требований по проекту и тп — реальный бизнес он весьма непростой) с нормально организованным процессом и кодом — грубо говоря сразу познакомились с тем "как надо", а могли тратить годы в разных шаражках, занимаясь непонятно чем и как.
Попробуйте посмотреть со стороны бизнеса — сроки, бюджеты, риски и тп.
Я думаю бизнес должен быть доволен, если лид при бюджете отдела может выжать больше используя сеньоров как основу.
В 95% реальных проектов ревью архитектуры которую создал текущий технический лид/сеньор/архитектор не делает никто
Хорошо это и плохо?
Непонятно почему жаль — у них была отличная возможность поработать на реальных проектах(со всеми "прелестями" типа жестких сроков
Похоже я не правильно оценивал ваши слова. В любом случае я не знаю, что у вас там было, и не мне высказывать такое мнение. Все понимают, что джуниора можно пускать только в локальный функционал, там где он при всем желание не может повлиять из подсистемы. А оценивать на сколько это эффективно, я бы дал лидам, а не бизнесу. Очень часто наблюдаю недоверие между бизнесом и разработчиками. Возможно для этого есть почва.
Я думаю бизнес должен быть доволен, если лид при бюджете отдела может выжать больше используя сеньоров как основу.
В любом проекте есть работа, требующая высокой квалификации, есть работа, которой достаточно низкой квалификации. Если проект не наукоёмкий, второй будет больше. Намного больше. И вы никак не выжмете больше, если у вас дорогие специалисты будут заниматься низкоквалифицированным трудом. У дорогих специалистов в общем случае нет свойства «делать рутинные задачи очень быстро». Поэтому для «выжать больше» в команде всё-таки должны быть и сеньоры, и миддлы, и джуны, кроме каких-то редких кейсов.
Хорошо это и плохо?
Риторический вопрос. По-разному бывает. Как по мне, архитектура — не код, ошибки в ней чаще связаны не с невнимательностью/недостатком знаний, а недостатком информации о бизнес-требованиях, особенно информации о будущих бизнес-требованиях, которые, вероятно, всплывут через какое-то время. В таком ключе ревью не поможет. Есть ещё и другая проблема: there is more than one way to compute. Два архитектора могут иметь разные точки зрения на способ решения задачи, и к консенсусу не придут. Поэтому как по мне, ревью архитектуры — штука сугубо опциональная, и если вы доверяете вашему архитектору, то доверяйте и его архитектуре. А если не доверяете, то вашему проекту уже и так опаньки:)
В 95% реальных проектов ревью архитектуры которую создал текущий технический лид/сеньор/архитектор не делает никто
Хорошо это и плохо?
Это жизнь.
Далеко не всегда фирма нанимает как минимум 2 специалистов достаточно высокой квалификации, чтобы они могли бы это обсудить между собой на равных.
И зачастую это рационально нанимать их мало. Ибо кроме одного-этого единственного обсуждения больше второй старший и не нужен ни для чего. Держать второго старшего на случай болезни первого старшего, в фирме, скажем, из 3 разработчиков — убыточно, и страховка рисков в подобных случаях неоправдана.
Обсуждение же с младшими для целей оптимизации архитектуры несет мало полезного и нужно прежде всего в целях образования младших, чтобы они понимали почему именно опытный принял именно такое решение.
то есть по вашему если из трех «взрослых» убрать одного то с проектом ничего не случится? А зачем тогда их изначально было 3, а не 2?
Что бы делать «на треть» больше.
Вы в своих умозрительных перестановках забываете что люди не пешки, а проекты не однотипны.
На самом деле — можно или нет заменить — зависит от сложности проекта.
Если проект таков, что с ним справлялись бы и джуны, то сеньоры там изначально были не особо и нужны. И джунами их следует заменить давно.
Если проект сложен, то замена сеньора на джунов приводит к ступору, а не к повышению производительности.
Можно ли сэкономить, набирая junior специалистов?