BorLaze

Пример как раз отлично иллюстрирует то, что исключений тут и даром не надо.

На вопрос isDirectoryNameCorrect мы хотим получить только "да" или "нет".
При этом нас совершенно не беспокоит, почему "нет" - то ли набор символов в имени недопустим, то ли диск посыпался, то ли прав не хватает - нам это не интересно.

Вот тут, как по заказу - отличный пример, зачем нужны объявления переменных, типизация и прочие "излишества, ограничивающие программиста" :-)))

Жадные, ленивые дети...

Есть сайт A с N фичами. Ему потребовался дополнительный сайт B (причем на чужом домене) , который содержит от предыдущего N - 2 фичи, и еще пару своих (на самом деле, больше обертки над уже сущетвующими из A).

Не надо ничего копипастить.

Делаем абстрактный сайт О, в котором будут общие для А и Б фичи (те самые N-2 из А).

Сайт А наследует сайт О + 2 фичи, характерные для А.
Сайт В наследует сайт О + 2 фичи, характерные для В.

Все.

В дальшейшем, при разработке чего-то нового, смотрим, куда это добавить - если только для сайта А, тогда в А; если только для сайта В, тогда в В; если и туда и туда, тогда в О.

API - это лишняя связность между компонентами, которая в данном случае избыточна и вредна (как тут выше заметили, если падает сайт А, это не должно касаться сайта В).

Возможно ли этим зарабатывать, и если да, то как называется эта позиция в команде, когда вся твоя работа заключается в написании именно алгоритма? Есть ли в целом такая должность в чистом виде или это является в совокупности частью компетенции стандартного разработчика?

Я бы предварительно задал себе несколько вопросов...

А что Вы можете "выдать на гора", чего не сможет сделать стандартный разработчик?
Алгоритм будет быстрее, менее прожорлив к ресурсам, устойчивей?

Опять же - что это будет за алгоритм? Если "взять входные данные" -> "сделать хорошо" -> "вернуть результат" - то зачем стандартному разработчику такое счастье? Детализировать алгоритм до степени, когда его можно легко реализовать - это, понимаете ли, не так уж от программирования далеко.