auoa16

насколько вообще типична эта ситуация

Более чем типична

у меня есть идея грандиозного IT-проекта

Правильнее сказать, что у вас есть ощущение, что ваш проект грандиозный. Я не знаю ни одного программиста в мире, у которого нет идей "грандиозных" проектов. Помимо программистов, еще десятки миллионов других людей имеют идеи "грандиозных" проектов. В итоге же, из всего количества стартапов выживают спустя 3 года менее 5%. Из них половина работает в небольшой плюс, лишь оставшиеся 2% становятся успешными проектами. Иными словами, даже если ваш проект грандиозный, вероятность того что он станет успешным примерно 2%. Чтобы Вы понимали насколько это мало, просто поставить в рулетке на конкретное число и выиграть намного более вероятно, чем запустить успешный стартап. Только в случае рулетки вы теряете лишь деньги, а в случае с проектом деньги и драгоценные годы.

но почти нет скиллов в программировании

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

Что нужно понять?
1) Понять, что ваша идея это обычная идея, коих в мире миллиарды. Она в среднем не лучше и не хуже других идей.
2) Понять, что даже если ваша идея потрясающая и даже если вы освоили программирование на уровне лучших инженеров гугла, при этом собрали сильную команду из разработчиков, менеджера продукта, специалиста по маркетингу и т.д., все равно ваши шансы на успех равны 2%.
3) Понять, что если у вас нет команды из предыдущего пункта, то ваши шансы примерно чуть более 0%.

Что в таких случаях надо делать?
1) Получить словесное подтверждение того, что идея чего-то стоит. Например, рассказав о проекте 20и людям, посмотреть сколько из них сочтут вашу идею хотя бы "нормальной", не нужно грандиозной.
2) Поискать аналоги. С вероятностью 95% вашу идею уже реализовали ранее, проверить популярность продукта, посмотреть в чем различия с вашим виденьем, плюсы/минусы и т.д.
3) Как только получили предварительное подтверждение, что идея не го*но, пора делать прототип. Тут уже смотрите сами: либо ищите людей, готовых работать на вашу идею, либо сами прокачивайтесь до уровня, позволяющего сделать MVP, либо подзаработайте денег и наймите того, кто сделает MVP.
4) Как только MVP сделан, пора показывать его людям. Если хотя бы 10 человек будут в восторге от вашего продукта - это успех, можно искать инвестора. Если хотя бы 50 человек будут просто пользоваться без восторга вашим продуктом - можно искать инвестора. Если ваш продукт платный и его купят хотя бы 5 человек - можно начинать искать инвестора.

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

"Для программистов" вряд ли существуют, по крайней мере в том виде, в котором Вы себе представляете. Я говорю о

например что его гложит в javascript'е, с чем затык, почему не получается

Исходя из такой логики(если я правильно уловил ход Ваших мыслей), психотерапевт мало того что должен быть компетентен в психологии, так еще и быть высококлассным программистом во всех областях и во всех языках, чтобы понимать боли и "затыки" всех своих пациентов, но это, как понимаете, невозможно.

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

Вопрос профессионального выгорания особо остро стоит у программистов - тут я соглашусь, специфика такая. Но это не значит, что для лечения нужно быть с головы до ног погруженным в IT. Высококвалифицированному психотерапевту изучить особенности профессионального выгорания программистов от а до я не составит труда за неделю-другую, и для этого ему совсем не нужно знать javascript)

Если нужно получать в едином формате, просто передавайте формат culture(третий) в format, например для формата 01.11.2017 вот так: SELECT FORMAT( GETDATE(), 'd', 'ru-RU');

Джуны не только в ios разработке не нужны, они нигде не нужны кроме веба и околопрогерских позиций вроде аналитик, техподдержка и т.д. По остальным направлениям вакансии джунов появляются 1-2 в месяц в городах миллионниках, в Мск может будет 7-8, а теперь прикидываем сколько человек на нее откликнется, даже если все откликнувшиеся будут без опыта у вас все равно мизерные шансы быть приглашенным на собеседование(не говоря о том чтоб пройти его, оказавшись лучшим из кандидатов), но а если среди откликнувшихся будут люди хоть с каким-то опытом и парой опубликованных приложений(а они будут), то у вас и вовсе нет шансов.

-Что тогда делать? - спросите Вы
-Либо искать стажировки бесплатные/за еду, либо в домашних условиях прокачиваться до миддла - отвечу я

Чтобы произошло первое нужна большая удача, ведь шансы найти стажировку хоть и выше чем работу джуном но не сильно.

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

Вот частично вроде

Тут Вам по кусочкам дали ответ, осталось собрать воедино, чтобы было понятно что к чему. Далее по пунктам:

1) Первое и самое главное здесь то, для чего вообще это хеширование нужно. Правильный ответ Вам дали "олды", о которых Вы сами упомянули, + Сергей Горностаев привел пример отличной книги, где об этом можно почитать подробнее. Если в двух словах, то в распределенных базах данных(когда они хранятся в более чем одном экземпляре) прежде чем сохранить какую-то информацию в какой-то из экземпляров нужно для начала понять, а в какой именно экземпляр должны сохраняться определенные данные. Вот представьте, Вы регистрируетесь в инстаграм, там сотни экземпляров баз данных, как им определить в какой вас сохранить? И тут как раз вступает в дело та самая хеш-функция по каким-то уникальным данным(например по мэйлу или по номеру телефона), которая дает на выходе число. Именно это число определяет в какой экземпляр базы данных сохранить конкретного пользователя(чаще всего там используют деление по модулю на количество экземпляров, ну об этом подробнее можете прочитать в книге, о которой говорилось).

2) Теперь о том, почему это используют как id вместо обычных чисел. Причин может быть на самом деле много, я вам приведу сейчас самую наглядную, а подробнее уже сами потом изучите. Как говорилось выше, распределенная база данных это множество разных экземпляров баз данных, где в каждом экземпляре свои данные. Вот представьте, что у нас 10 разных экземпляров. И хеш-функция по вашему логину указала, что вас нужно сохранить в экземпляр №6. А по моему логину хеш-функция показала, что меня нужно сохранить в экземпляр №3. Тогда что получается: и я и вы теперь записаны в таблицу Users, только ваша таблица Users не имеет никакого отношения к моей, потому что эти таблицы находятся в разных базах данных. То есть логически это одна база данных, но по факту это разные экземпляры. И если бы мы с вами были первыми пользователями и в качестве id использовались бы обычные числа(например автоинкрементные поля), то в базу данных записалось бы два пользователя с одинаковым id(если мы первые пользователи то оба получили бы id=1 каждый в своей базе), что является катастрофой. Так вот чтобы избегать подобных ситуаций, используются специальные идентификаторы, которые называются uuid. Все популярные СУБД имеют встроенную поддержку таких идентификаторов и способы их генерации. Однако насколько я понял в вашем случае вместо использования встроенных функций для генерации uuid разработчики используют результат хеш-функции в качестве этого самого uuid, что довольно классное решение на мой взгляд. А что касается производительности - результат этой хеш-функции это такое число в шестнадцатиричном виде(только чуть больше, 20 байт против 16 у uuid), как классический uuid, поэтому производительность вряд ли пострадает.