Дратути Антон

https://habr.com/ru/articles/1102140/

Уже в моём поколении многие шли в IT ради денег, да и среди людей постарше, думаю, тоже. Модно, престижно, пафосно, где-то ещё и сырки по средам дают 😃. Но сам я вырос в таком пузыре, где в IT видели скорее прикол и фан, а предел мечтаний зп был 100к гросс (это когда ты там синьор стафф инженер).

В школе я помогал учителям разбираться с компами. По фану участвовал в олимпиадках. Игрался с ArtMoney, писал вирусы (для себя), разбирался с сетью, заводил каскады Хаара через OpenCV, пилил сайтики (были как простые, так и вундрвафли через adobe muse). Всякие тетрисы, змейки, на плюсах и на C# — ух, чего только не было. В универе до первой работы подрывался на каждую шабашку, поскольку это было просто прикольно. Меня просто пёрло и прёт от того, что я делаю 😍.

Когда я нашел первую работу (прям официальную, не шабашку), я был удивлён, что будут платить зарплату, и очень приличную (60к гросс), поскольку я шел нарабатывать себе опыт и мне главное было работать с людьми из индустрии 😮‍💨. Но потом оказалось, что в офисе ещё и печеньки есть, и даже кофемашина. Сейчас с таким оффером хорошо, если тебя не пошлют.

Конечно, я не хочу лицемирить: сейчас деньги — один из самых важных факторов того, где и чем я буду заниматься. Но очень важна та самая "прикольность", ради которой я в эту ITшку и пришёл. Хз, что дальше будет с рынком и зарплатами, но в IT, как мне кажется, стало ещё прикольнее. В целом, я думаю, разберёмся, и не такие метели в ебало летели 😀.

Прочитал пост Лёши про евалы, ну решил тоже подушнить на эту тему, коли есть у меня такая возможность.

Если меня спросят, из чего состоит твой рабочий день, одним из первых ответов будет — думаю про систему замеров. В какой-то момент развития продукта на базе ML умение честно оценивать свой стек на всех его этапах — это базовый минимум. И чем раньше это осознание придёт к команде — тем меньше будет попаболи в будущем 😃.

Типичный сценарий до осознания выглядит так:
1. Приходит продакт Q и говорит: ребят, давайте запилим фичу A. Вот вам корзинка, lmaj или дсатом посмотрим кач-во, так и покатим;
2. Вы соглашаетесь (это же важно для бизнеса), внедряете, получаете лавры;
3. Приходит продакт W и говорит: ребят, давайте запилим фичу B.
4. Вы понимаете, что A и B могут пересекаться, а могут работать по отдельности. Теперь нужно понять, как замерить каждую из них, что происходит на пересечении и не сломали ли вы что-то из уже работающего. Но вы справляетесь и выкатываете.

Как вы понимаете, дальше приходят продакты R, T, P и т.д., и вы чувствуете, что вам уже больно 🏥. И тут вы задумываетесь, как же правильно? Как проверять всё после каждой новой фичи и не тратить на замеры вечность и весь бюджет ?

Лично мне здесь нравится мысль из TDD (test-driven development): сначала разобраться, как ты будешь проверять результат, а уж потом бежать делать. В моём случае — ещё и подумать, как эти замеры будут жить, когда рядом появятся следующие 100500 фичей. На удивление это помогает избежать очень кривых предложений и строить что-то работающее в долгосроке.

В следующем посте подушню про сами корзинки и то, как замерять на них качество, а пока расскажите, как вы тестируете свои харнесы? Ну или 😮‍💨?)

Лол, чтоооо

https://arxiv.org/abs/2610.31642