НИИ битком забиты физиками и математиками - джунами которые неспособны открыть теорему или частицу а могут только писать водянистые документы из-под палки.
Действительно, вот лузеры. Я сегодня открыл 2 штуки пока на работу шел - делов-то.
Также - если заказчик самостоятельно внятно составил свои требования, которые понятны команде разработчиков, QA и дизайнеров, то зачем тратить деньги на аналитика?
А если младенец сам умеет готовить еду и гулять, то можно не тратить деньги на няню. Но увы. Часто вам такие заказчики попадались?
У меня есть опыт работы в команде без аналитика вообще. Жить-то, конечно, можно, но быстро приходим к тому, что аналитиком становится самый грамотный разработчик или QA. Естественно, без всяких доплат.
Хорошая практика: делать подробное описание, которое включает в себя причины, по которым нужна эта задача, и описание решения с пояснением, почему задача решалась именно таким путем.
Противоречит первому же пункту. Если изменения действительно вносятся атомарно, то их не приходится сопровождать портянкой чейнжлога. Иначе автоматически возникают или вопросы к декомпозиции задачи, или к невменяемому неймингу, или к оверхеду в решении.
Какая животрепещущая лично для меня тема. К сожалению, за 7 лет в разработке встретилось всего пара аналитиков, которым по итогу работы хотелось пожать руку. Остальные по факту оказывались джунами-копирайтерами, которые только и могли что переносить мысль "делайте хорошо, плохо не делайте" из головы заказчика в задачу в джире.
Для себя выделил 3 критических пункта:
В разработке ПО нет слова "подразумевается". Подразумеваться могут только стандарты вроде использования HTTP в рестовой архитектуре. Поэтому в ТЗ должны быть даже те вещи, которые лично вам кажутся трижды очевидными. Разработчик не имеет (пока) доступа к вашему разуму.
Нужно обязательно хотя бы в общих чертах понимать архитектуру современных систем, модели и протоколы их взаимодействия. Иначе в ТЗ гарантированно будет оторванная от реальности дичь и испорченные отношения с инженерами
В статье сказано про "энциклопедию проекта" - а я добавлю, что еще необходим и глоссарий проекта. Одна и та же вещь в разных местах проекта должна называться одинаково. Это должно быть закреплено на самом верху и строго соблюдаться повсеместно.
Негатив в комментах связан с тем, что обобщена частность. Сейчас действительно выделился класс систем, для построения которых скорее нужен бэкендер-аналитик нежели олдскульный бэкендер-хардкорщик.
Например, все мы наблюдали взрывной рост приложений, предлагающих доставку продуктов из супермаркета. Так вот соль такой системы в грамотно спроектированном домене и в архитектуре, заточенной под постоянное горизонтальное расширение. То есть сначала очень плотная работа по аналитике, а потом довольно рутинная, но аккуратная разработка (то самое перекладывание джейсонов). Прорывных алгоритмов тут ноль, инженерного новаторства ноль. Просто грамотный ремесленный труд и сборка продукта из готовых кирпичиков.
Другой полюс - это фреймворки, либы, высококритичные приложения. Тут софт-скиллы скромно уходят на второй план, и вылезает реальная потребность в computer science.
Важный нюанс: никогда в команде не взлетит культура ревью, если нет культуры декомпозиции задач. Если взято за правило бахать коммитами по 1000 строк в 50 файлах, то либо ревью по чек-листу будет занимать дни, либо все скатится в "ок, это код, ревью пройдено".
К сожалению, в таких условиях никто не смог придумать ничего лучше, чем проверять алгоритмы, так как это единственное...
Далеко не единственное. Было бы желание - систему оценки придумать можно. Иначе получается парадокс: человек придумал такие штуки как микропроцессор, смартфон, интернет - а вот систему оценки инженеров не могёт.
Проблема в том, что для большинства разрабов провести собес - это обязаловка и ярмо. Отсюда и такое отношение: "на тебе брейнфак с литкода, а я посмотрю на твои страдания"
Уже сам факт появление статьи оправдательной направленности о многом говорит.
Миф 2: В обычной работе знание алгоритмов не нужно
Господа, просто смиритесь с тем фактом, что сотни успешных продуктов пишутся совсем не олимпиадниками. Времена когда понятие "программирование" было тождественно "computer science" ушли безвозвратно. Теперь это по большей части ремесло. 90% вакансий требуют именно умелого цепкого ремесленника, который владеет приемами создания надежных приложений. Тождественны ли они умению из головы вспомнить или сочинить 10 алгоритмов сортировки и щелкать задачки с литкода? Ну можете и дальше уверять себя, что да.
Чтобы производители не ощутили резкого падения доходов, в компании предлагают ввести экологическую надбавку для потребителей.
Господа Deloitte, можете еще свою компанию продать и перечислить выручку в фонд голодающих корпораций.
Получается, что ни кто иной как потребитель уже много лет спонсирует разработку и выпуск девайсов. А когда имеем выход на плато надежности, то потребитель же и должен компенсировать убытки.
Боюсь, что производителю просто плевать. Я работал с оборудованием Honeywell в области HVAC и пришел к выводу, что контора тем и живет, что впаривает втридорога некачественные и морально устаревшие поделки. Зато прикрытые бумажками.
Возможно, люди года полтора-два назад приходили на те деньги, которые сейчас уже неприлично ниже рынка в силу дикой инфляции. Ну а организации, как водится, проблемы в этом не увидели. Ну и пошло поехало колесо увольнений. Жадность фраера сгубила.
Вы правы только если речь о сдельной работе или о фрилансе. Но если компания принимала в штат конкретное лицо, то она имеет все основания ожидать, что должностные обязанности будут выполняться именно этим лицом. А статье описано ни что иное, как багоюз системы.
Главный герой публикации, американский разработчик Сэм, нашел способ совмещать три работы. И в конечном итоге перепоручил одну из них своей сестре
Класс. Когда человек платит за айфон, а получает обломок плитки в коробке, то это называется мошенничество. А когда компания платит за Сэма, а получает сестрюню, то это называется Сэм молодец и вообще человек завтрашнего дня.
Значит в данной организации такие требования к синьору. Это не система СИ, единой шкалы тут нет. Этому "эксперту" следует испытывать стыд и посыпать голову пеплом?
То что ваша должность называлась Ведущий специалист не делает вас Senior developer
Вообще-то именно это и делает. Да, в мире розовых единорогов звание синьора выдается межгалактическим магистратом в присутствии представителей всех разумных цивилизаций. А в нашем реальном мире если контора вписалась платить тебе как синьору - значит для нее ты синьор. Если другая контора не готова на такое, то для нее ты не синьор.
и писать надо с первого раза в code style и без багов
Почему-то меня терзают сомнения, что вы сами всегда пишете с первого раза и без багов. Вам в таком случае на предприятии и тестовые среды не нужны - за ненадобностью.
Восьмое число после запятой в числе пи назовете по памяти? Так это же простой вопрос. При этом есть немало практических задач, где знание этих вещей необходимо.
Или все же оставим кесарю кесарево, а справочную информацию - справочникам?
Можно весь список сократить до тех, кому пофигу, и тех, кому нет.
Как по мне, первые 4 пункта - это ребята, которым пофигу. Компании нужен человек под конкретные задачи с конкретным набором скиллов. Если об этих задачах и об этом наборе скиллов на собесе речь не идет, то значит интервьюеру пофигу, что там компании нужно. Он или самоутверждается за счет накидывания всяких олимпиадных задач и вопросов на знание справочной информации, или просто тянет лямку обязанности провести собес.
Действительно, вот лузеры. Я сегодня открыл 2 штуки пока на работу шел - делов-то.
А если младенец сам умеет готовить еду и гулять, то можно не тратить деньги на няню. Но увы. Часто вам такие заказчики попадались?
У меня есть опыт работы в команде без аналитика вообще. Жить-то, конечно, можно, но быстро приходим к тому, что аналитиком становится самый грамотный разработчик или QA. Естественно, без всяких доплат.
Противоречит первому же пункту. Если изменения действительно вносятся атомарно, то их не приходится сопровождать портянкой чейнжлога. Иначе автоматически возникают или вопросы к декомпозиции задачи, или к невменяемому неймингу, или к оверхеду в решении.
Какая животрепещущая лично для меня тема. К сожалению, за 7 лет в разработке встретилось всего пара аналитиков, которым по итогу работы хотелось пожать руку. Остальные по факту оказывались джунами-копирайтерами, которые только и могли что переносить мысль "делайте хорошо, плохо не делайте" из головы заказчика в задачу в джире.
Для себя выделил 3 критических пункта:
В разработке ПО нет слова "подразумевается". Подразумеваться могут только стандарты вроде использования HTTP в рестовой архитектуре. Поэтому в ТЗ должны быть даже те вещи, которые лично вам кажутся трижды очевидными. Разработчик не имеет (пока) доступа к вашему разуму.
Нужно обязательно хотя бы в общих чертах понимать архитектуру современных систем, модели и протоколы их взаимодействия. Иначе в ТЗ гарантированно будет оторванная от реальности дичь и испорченные отношения с инженерами
В статье сказано про "энциклопедию проекта" - а я добавлю, что еще необходим и глоссарий проекта. Одна и та же вещь в разных местах проекта должна называться одинаково. Это должно быть закреплено на самом верху и строго соблюдаться повсеместно.
Вы математиков ищите? Или вы тоже исповедаете замшелую точку зрения, что программист == математик?
Согласен с основным тезисом, но уверяю вас, что тысячи приложений успешно пишутся даже без тени знания о перемножении матриц.
Негатив в комментах связан с тем, что обобщена частность. Сейчас действительно выделился класс систем, для построения которых скорее нужен бэкендер-аналитик нежели олдскульный бэкендер-хардкорщик.
Например, все мы наблюдали взрывной рост приложений, предлагающих доставку продуктов из супермаркета. Так вот соль такой системы в грамотно спроектированном домене и в архитектуре, заточенной под постоянное горизонтальное расширение. То есть сначала очень плотная работа по аналитике, а потом довольно рутинная, но аккуратная разработка (то самое перекладывание джейсонов). Прорывных алгоритмов тут ноль, инженерного новаторства ноль. Просто грамотный ремесленный труд и сборка продукта из готовых кирпичиков.
Другой полюс - это фреймворки, либы, высококритичные приложения. Тут софт-скиллы скромно уходят на второй план, и вылезает реальная потребность в computer science.
Важный нюанс: никогда в команде не взлетит культура ревью, если нет культуры декомпозиции задач. Если взято за правило бахать коммитами по 1000 строк в 50 файлах, то либо ревью по чек-листу будет занимать дни, либо все скатится в "ок, это код, ревью пройдено".
Далеко не единственное. Было бы желание - систему оценки придумать можно. Иначе получается парадокс: человек придумал такие штуки как микропроцессор, смартфон, интернет - а вот систему оценки инженеров не могёт.
Проблема в том, что для большинства разрабов провести собес - это обязаловка и ярмо. Отсюда и такое отношение: "на тебе брейнфак с литкода, а я посмотрю на твои страдания"
Уже сам факт появление статьи оправдательной направленности о многом говорит.
Господа, просто смиритесь с тем фактом, что сотни успешных продуктов пишутся совсем не олимпиадниками. Времена когда понятие "программирование" было тождественно "computer science" ушли безвозвратно. Теперь это по большей части ремесло. 90% вакансий требуют именно умелого цепкого ремесленника, который владеет приемами создания надежных приложений. Тождественны ли они умению из головы вспомнить или сочинить 10 алгоритмов сортировки и щелкать задачки с литкода? Ну можете и дальше уверять себя, что да.
Господа Deloitte, можете еще свою компанию продать и перечислить выручку в фонд голодающих корпораций.
Получается, что ни кто иной как потребитель уже много лет спонсирует разработку и выпуск девайсов. А когда имеем выход на плато надежности, то потребитель же и должен компенсировать убытки.
Боюсь, что производителю просто плевать. Я работал с оборудованием Honeywell в области HVAC и пришел к выводу, что контора тем и живет, что впаривает втридорога некачественные и морально устаревшие поделки. Зато прикрытые бумажками.
Возможно, люди года полтора-два назад приходили на те деньги, которые сейчас уже неприлично ниже рынка в силу дикой инфляции. Ну а организации, как водится, проблемы в этом не увидели. Ну и пошло поехало колесо увольнений. Жадность фраера сгубила.
Вы правы только если речь о сдельной работе или о фрилансе. Но если компания принимала в штат конкретное лицо, то она имеет все основания ожидать, что должностные обязанности будут выполняться именно этим лицом. А статье описано ни что иное, как багоюз системы.
Класс. Когда человек платит за айфон, а получает обломок плитки в коробке, то это называется мошенничество. А когда компания платит за Сэма, а получает сестрюню, то это называется Сэм молодец и вообще человек завтрашнего дня.
Значит в данной организации такие требования к синьору. Это не система СИ, единой шкалы тут нет. Этому "эксперту" следует испытывать стыд и посыпать голову пеплом?
Поведайте, пожалуйста, как вы чуть ли не каждый день используете методы clone, notify, notifyAll, wait, finalize класса java.lang.Object.
Вообще-то именно это и делает. Да, в мире розовых единорогов звание синьора выдается межгалактическим магистратом в присутствии представителей всех разумных цивилизаций. А в нашем реальном мире если контора вписалась платить тебе как синьору - значит для нее ты синьор. Если другая контора не готова на такое, то для нее ты не синьор.
Почему-то меня терзают сомнения, что вы сами всегда пишете с первого раза и без багов. Вам в таком случае на предприятии и тестовые среды не нужны - за ненадобностью.
Восьмое число после запятой в числе пи назовете по памяти? Так это же простой вопрос. При этом есть немало практических задач, где знание этих вещей необходимо.
Или все же оставим кесарю кесарево, а справочную информацию - справочникам?
Можно весь список сократить до тех, кому пофигу, и тех, кому нет.
Как по мне, первые 4 пункта - это ребята, которым пофигу. Компании нужен человек под конкретные задачи с конкретным набором скиллов. Если об этих задачах и об этом наборе скиллов на собесе речь не идет, то значит интервьюеру пофигу, что там компании нужно. Он или самоутверждается за счет накидывания всяких олимпиадных задач и вопросов на знание справочной информации, или просто тянет лямку обязанности провести собес.