Шармааан!))

Нет. Лучше не отдавать такие задачи одинокому чуваку в окружении маркетологов, а брать эти задачи в основную команду разработки.

Я просто много видел как бывает в компаниях, которые сами живут долго и проекты в них живут долго - за это время успевают поменяться по несколько раз все команды, от менеджмента и маркетологов до разработки и эксплуатации. И видел какой ад там случается, если пустить всё на самотёк или понадеяться что потом поправят.
Есть хорошая книжка - Software Engineering at Google, они там очень сильный акцент на этом делают и на мой взгляд весьма заслуженно.
«Software Engineering is programming integrated over time” (c)

Вот это моя беда. Допустим, я вижу проблему, которая выстрелит в ногу через три года. Но бизнес может не думать больше чем на год вперёд (MVP). Надо мне что-то в связи с этим предпринимать?

Тут конечно нужно уметь держать баланс и в этом и есть искусство. Но вот конкретно я видел ситуации, когда в ад всё скатывалось гораздо быстрее чем через 3 года, а MVP в первых версиях обычно сильно далёк от того что должно получиться на самом деле => бизнес застревал в состоянии “мы тут наделали кучу ***(плохих решений), продукт получился не тот что нужен рынку, понятно как поменять продукт, но менять то что уже есть крайне сложно”. И вот это уже задница. Если те проблемы, которые ты сейчас видишь, к такому не должны привести — нормально потом переделать.

почему числу? это функциональный анализ. Мы просто загрубляем функцию времени работы алгоритма  f(n) простой функцией g(n), которая при подборе константы c ограничивает сверху: f(n) < c g(n). Это bigO. Если вдруг нам нужна оценка снизу и мы можем теоретчески подобрать функцию k(n) ограничивающую нашу функцию снизу с точностью до константы с1: f(n) > c1 k(n). Это bigOmega. Простейший пример: работа с деревом: или дерево хорошо ветвится или вырождено в список. Там нам понадобятся и оценка снизу и сверху.

bigTheta это случай когда нам повезло и мы может на базе одной простой функции g(n) подбором констант ограничить нашу функцию f(n) и сверху и снизу: c1 g(n) < f(n) < c2 g(n)

конечно, случай с bigTheta это удача, вопрос нужна ли она нам. Потому что в основном инженерам надо бы оценить максимальной время работы и максимальный объем памяти, который мы можем получить. А остальное  - это уже больше научные изыскания.

спасибо!

забыл весь матан уже за 20 лет

Я думаю многие видели )
Во мне развилась чуйка на тему - "эта хрень не проживет больше года, нет смысла в нее инвестировать. пусть сделают джуны, и не будут отвлекать нормальных людей от нормальных дел"

И знаешь сколько раз я ошибался? )
ноль.

В обратную сторону бывало )

Нет проблемы, если что-то сделают джуны - они тоже должны что-то делать и чему-то учиться. Половина Яндекса стажёрами написано 🙂
Но джуны тоже бывают разные и хорошо бы чтобы они всё же понимали немного про сложность алгоритмов. Для них это особенно важно - если они остального ещё не понимают, а базовые вещи уже не понимают, то что они вообще понимают и смогут сделать? 🙂

абажи, разговор был про пхпешника для маркетологов )

Много разговоров было 🙂 Про маркетологов я отвечал чуть выше:
> лучше не отдавать такие задачи одинокому чуваку в окружении маркетологов, а брать эти задачи в основную команду разработки

опять же, это моё ИМХО, никого не убеждаю — у всех свой путь 🙂

https://users.cs.duke.edu/~ola/ap/recurrence.html ну и если будет интересно, про оценки для рекурентых вещей. Но это лучше Сoncrete mathematics (https://www.amazon.com/Concrete-Mathematics-Foundation-Computer-Science/dp/0201558025) почитать с упражнениями - реально крутая книжка для аналитического мышления.

Тетта не сходится

Потому что qSort это O(n^2) и при этом Theta(n log n)