Я Вам как Data Scientist — Data Scientist-у скажу: «С такой „разговорной“ аргументацией ваше „впечатление“ о проектах в больших компаниях не может быть верным по своей природе». Наличие у клиентов специалистов по анализу данных и построению прогнозных моделей является достоинством так как позволяет работать с качественными техническими спецификациями и получать качественную оценку представляемых результатов. При этом то, что Вы называете «танцем с бубном в поиске, решения, удовлетворяющего клиента» является обычным рабочим процессом, целью которого является решение поставленных клиентом задач.

RE: «DataArt или SoftServe, EPAM, Luxoft — у них что-то есть такого плана, но они более ориентированы на выполнение требований клиента, а не на решение под ключ»

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

Если интересно — имею опыт разработки более 20 тестов по R для hackerrank.com, проверки тестов других разработчиков и прохождения тестов от крупных компаний, в которых половина тестов были «моими». Из полученного опыта могу сказать, что:

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

2. Тесты сами по себе могут и содержат ошибки. Поэтому даже правильный код может показывать «неправильный» результат.

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

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

Недавно проходил онлайн собеседование. Рекрутер старательно создавал конфликтные ситуации, которые я также старательно пытался «сгладить». О самой работе до сих пор ничего не знаю. Зато знаю, что в случае приема меня на работу я буду одним из «рисков», за которым надо присматривать. То есть еще ничего не сделав, меня заранее на всякий случай сделали немножко виноватым. И зачем оно мне такое надо?

менеджер — подчиненные = 0

В таком случае лучше рассматривать 3 типа метрик: 1 — объективные (код), 2 — субъективные (люди), 3 — агрегация (код + люди)

Рекомендую познакомиться с книгой «Начала науки о программах» Холстеда М.Х. (1981). Несмотря на то, что книге уже 39 лет от роду, вы найдете в ней достаточно простую и красивую метрическую теорию оценивания программ, основанную всего на 2 метриках (количество операторов и операндов). В идеале оценка качества ПО должна быть независима от личности код написавшей.

Взаимно. В работе с данными обычно «детали делают» дизайн и определяют качество приложения.

Спасибо за хорошую статью.

Хочу добавить 2 цитаты как подтверждение приведенных правил

1. «All models are wrong, but some are useful» (управление ожиданиями)
2. «The details are not the details. These make the design» (будьте изобретательны)

Ссылки
[1] en.wikipedia.org/...​wiki/All_models_are_wrong
[2] en.wikiquote.org/wiki/Charles_Eames

Парень молодец! А вот интересно — сколько программистов смогли бы стать механиками?

Курс доллара в 2020 году будет на уровне 27 гривен за доллар. Такой курс валют утвердила Верховная Рада в законе о государственном бюджете Украины на 2020 год — 24tv.ua/...​_prognoz_kabmina_n1220135

R for Data Science — r4ds.had.co.nz
Лучшая книга для знакомства с R

Рекомендую канал #lang_r в группе «opendatascience» (ods) на Slack

R — это идеальное средство для быстрой и качественной разработки прототипов приложений, основанных на данных. В связке с R Shiny (shiny.rstudio.com) он позволяет представить результаты исследований в виде работающего приложения. Для продакшн есть отличный пакет «data.table».

RE: «Теперь у них создается впечатление, что они контролируют процесс».
Путь к сердцу менеджера лежит через диаграмму :)

Спасибо за статью.
Отлично!

Рекомендую к изучению „The Impressive Growth of R”
stackoverflow.blog/...​0/10/impressive-growth-r

PYPL — R in Top10 (7)
TIOBE — R in Top15 (15)
Отличный результат для в общем-то специализированного языка.

RE:

У него нет будущего кроме как в группах какихто староверов или хз кого

Абсолютно странное заявление, у которого точно нет будущего, в отличие от R.

В R есть рекомендации по стилю кода.
Например:
1. Style guide — adv-r.had.co.nz/Style.html
2. Google’s R Style Guide — google.github.io/styleguide/Rguide.xml
3. The tidyverse style guide — style.tidyverse.org

1. Рекомендовать R или нет вопрос личной оценки.
2. R != Python. Но у них есть общее «под капотом» — C++.
3. Будущее R более чем прекрасно и серьезно (www.rstudio.com/pricing)
4. Синтаксис R имеет «особенности», связанные со статистической мощью языка.
5. Хорошо документированный R код читается легче C++ кода.