Про оценку сроков

Мы ужасно умеем оценивать сроки. Подкидывание монетки или бросание кубика даст верную оценку с той же вероятностью, что и команда опытных программистов. Но бизнесу необходимы сроки, и каждый спринт нам приходится оценивать задачи, надеясь на удачу и на то, что не возникнет непредвиденных проблем.

Однако непредвиденные проблемы возникают практически всегда. Внезапно выясняется, что часть системы, куда нужно интегрировать новую фичу, работает с багами, или наше решение не вписывается в существующую архитектуру. Разумеется, все эти моменты становятся известны уже в процессе решения задачи, но никак не на этапе планирования. Мы сталкиваемся со сложным выбором: провалить сроки или овертаймить.

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

В защиту программистов скажу, что проблема оценок существует не только в айти: любой сложный процесс практически невозможно спрогнозировать. Один мой менеджер как-то сказал: представь, что твой врач не может назвать, сколько времени уйдет на лечение, что ты будешь чувствовать? Это был очень плохой пример: как раз в это время я проходила стоматологическое лечение, которое заняло на год больше ожидаемого и оказалось в 2,5 раза дороже изначально планируемой суммы.

Разработка - это сборка конструктора из мелких деталей: никогда не знаешь, подойдёт ли новая деталь к уже собранной части. Это напоминает известную проблему остановки Тьюринга: для любых двух функций F и G мы никогда не можем определить, что их суперпозиция остановится (= заработает как надо). Алан Тьюринг доказал неразрешимость этой проблемы еще 90 лет назад, однако менеджеры по сей день продолжают пытать программистов на очередном дейли вопросом “так, сколько тебе еще делать эту задачу?”.

Однако можно сделать ровно противоположное: не угадывать срок, который уйдет на разработку, а зафиксировать время, которое вы готовы уделить на фичу. Например: “Мы готовы потратить на эту фичу 2–5 дней. Обязательно - чтобы работало вот это. Всё остальное сделаем по возможности”. Тогда вы не будете зависеть от точных оценок, и при любом раскладе сделаете главное.

Первый раз я применила этот способ еще в 2019 году. Я прикинула, что мне нужно около двух недель на задачу. Однако менеджер вернулась ко мне со словами - “бизнес не дал тебе две недели, бизнес дал тебе неделю”. “Хорошо, я могу сшить семь шапок из этой шкурки,” - подумала я. Я сделала каркас фичи за неделю, но не успела добавить несколько удобных штук в свое решение, плюс пропустила некоторые корнер кейсы. Менеджер осталась довольна. А затем попросила доработать решение и учесть корнер кейс. “Хорошо,” - сказала я, - “на это мне нужна еще неделя”. На том и порешили.

Если вы разработчик и от вас требуют конкретные сроки - попробуйте так и сказать: “Я точно успею сделать вот это, а остальное - постараюсь, если не вылезем за дедлайн”. Тогда вы точно сможете рассчитывать на то, что критическая функциональность будет готова в срок, а опциональной можно пренебречь.

В тему оценки.

Сейчас взяла в работу задачу по починке скриншотных тестов. Ситуация: локально и в ci тесты проходят с разным результатом. Докер образ один и тот же. Честно говоря, я даже не представляю, в чем может быть проблема - я специально настраивала прогон в докере, чтобы добиться консистентности результата.

И ведь мне это нужно как-то оценить 😊

Говорила то же самое, когда это еще не было мейнстримом 😊
Брутфорсить собесы - это очень плохая идея.

Небольшое объявление для тех, кто планировал прийти ко мне на менторство или консультации - из-за сильной загруженности как минимум до конца октября такой возможности не будет :(
Это не относится к тем, с кем уже работаю или с кем есть договоренности.

Upd. Если вам нужна моя помощь и дело не терпит до конца октября, на данный момент смогу уделить вашему кейсу 10-15 минут и ответить на ваш вопрос в личке. Пишите в личку. Это бесплатно😊

Прошлый пост вызвал жаркую дискуссию о том, нужны ли алгоритмы.

Для меня знание алгоритмов - как личный автомобиль: без него можно прожить, но с ним гораздо удобнее. Самое главное, что дает их изучение - это умение думать. Казалось бы, зачем в повседневной работе помнить DFS или бинарный поиск? Не лучше ли сразу учиться на реальных задачах?

Я считаю так: если вы учитесь на реальных задачах, то вам постоянно придется учиться каким-то новым реальным задачам. На старой работе вы привыкли хранить данные в редаксе, приходите на новую, опа, а тут используется контекст. Приходится постоянно переучиваться.

Так получается потому, что реальных задач невероятно много. А вот фундаментальных задач, частными случаями которых являются реальные, на порядки меньше. Понимая фундаментальные задачи, можно с их помощью решить частные случаи. А вот наоборот, увы, не работает (ну а если у вас работает, значит, вы уже шарите в алгоритмах😎).

Бинарный поиск

Сегодня поговорим о бинарном поиске.

Бинарный поиск нужен для того, чтобы быстро что-то найти. Для того, чтобы можно было легко что-то найти, нужен порядок (прямо как в шкафу). Проще говоря, данные, где вы ищите, должны быть отсортированы по какому-нибудь признаку.

Алгоритм бинарного поиска заключается в том, что мы делим кучу данных на две равные кучки данных поменьше и затем пытаемся понять, какая из двух кучек нам подходит. После того, как мы это поняли, мы продолжаем поиск в нужной кучке. Вот и весь Великий и Ужасный Алгоритм, которым пугают джунов, как бабайкой. С вас три тыщи.

В классическом варианте вы наверняка увидите массив чисел, в котором ищется число x, равное, ну скажем для примера, 17. Мы делим кучку на две части пополам, и смотрим, чему равна середина. Если середина больше 17, то нам нужно искать в левой кучке (там, где числа поменьше). Если середина меньше 17, то наша кучка - правая. Искать таким образом числа в массиве вам, скорее всего, не потребуется никогда, но вот сама идея - “разделяй и властвуй сравнивай” - очень полезная.

В повседневной работе идея делить кучу на две поменьше пригождается в самых разных ситуациях. Например, конструкция if else тоже позволяет поделить данные на две кучки по какому-нибудь признаку. А еще та идея полезна для дебага. Допустим, вы внесли много изменений в код и в какой-то момент все сломалось (прямо как у меня сегодня). Как быстро найти проблемный файл? Очень просто: убираем половину ченжей (например, в stash) и проверяем, как это отразилось на баге. Если баг все еще воспроизводится, то делим эту кучку еще на две. Эту же идею использует для дебага git bisect.

Можно пойти дальше в своих размышлениях и додумать до идеи делить кучу не на две, а на три. Такие задачи иногда дают младшеклассникам на олимпиадах по математике. Мне впервые попалась такая в подготовительных материалах, когда мне было 8 лет, и решение дошло до меня только на следующий день.

Удачных вам разделений и сравнений!
#алгосы

Друг скинул еще одну задачу с собеседования: https://leetcode.com/problems/isomorphic-strings/. На ее решение у меня ушло около 7 минут. Решение:

var isIsomorphic = function(s, t) {
    const dictS = {};
    const dictT = {};
    for (let i = 0; i < s.length; i++) {
        const sChar = s[i];
        const tChar = t[i];
        if (!check(sChar, tChar, dictS) || !check(tChar, sChar, dictT)) {
            return false;
        }
        
    }
    return true;
};

function check(origin, replacer, map) {
    if (map[origin]) {
        return map[origin] === replacer
    }
    map[origin] = replacer;
    return true;
}

Меня огорчило, что я не попала в 10% самых быстрых решений (beats 89.81%). Закинула чат гпт и он решил гораздо хуже (beats 32.05%).
Вот так этим вечером внезапно выяснилось, что чат гпт решает алгозадачи так себе - по крайней мере, те две, которые мы разбирали сегодня в канале, он решил хуже меня.

Для меня это еще один повод использовать алгозадачи на собесах 😎

Мне интересно, дизлайк на предыдущий пост поставил человек, который попал в 10% самых быстрых решений? 🤔