MaratFakhrutdinov

оставь ребенка в покое, нефиг собственные комплексы реализовывать.

Посоветую использовать поиск, этот вопрос задавался уже много раз.

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

Начнём с того, что это невозможно.
Вина на тех, кто присылает год без века.
Бить их ногами и исправлять ситуацию на бэке.
Это не проблема фронта.
Если вариантов исправить бэк нет, то отказаться от этого кривого API.
P.S. А если вам прилетит "1/1/21" или "11/11/20"?.
Это какой год будет? 1921 или 2021, 1920 или 2020?
Как ваш код будет работать через три месяца? А через 9 лет? А через 70?

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

Слово "алгоритм" ни в вопросе, ни в многочисленных ответах не встретилось ни разу.

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

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

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

значит "запомнить много функций" или значит "запомнить и знать что и где искать в гугле и все понимать"?

Детский сад, штаны на лямках. Уметь программировать - это решать поставленную задачу качественно и в срок. Методология решения - ну, она может быть непосредственного начальника заинтересует, и то, если на code review ему не понравится, как написано. А руководству - ему аще плевать, оно оценивает с точки зрения бизнеса.

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

Ваша проблема довольно типична на самом деле :) Это не какие то индивидуальные особенности, просто многие боятся самому себе в этом признаться.

Например в рамках классического скрам планирования команда оценивает отдельные фичи или задачи всей командой да еще не в человекочасах, а в абстрактных еденицах, которые переводят в человекочасы опираясь на скорость работы людей до этого. Целая система.

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

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

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

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

• Ведите статистику по тому, сколько времени занимают сделанные вами задачи, или используйте существующую.
  
• Разбивайте задачи на подзадачи и оценивайте их отдельно, а потом складывайте результат.
  
• Сравнивайте задачи с теми, что вы уже делали.
  

Системный подход решает многое.
Ну и конечно классический финт ушами: закладывание рисков. Просто учтите риски, добавив время, проявив храбрость, чтобы сказать большую цифру. И если на самом деле сделаете быстрее, считайте, что учтенные вами риски попросту не случились. Это вашему руководителю будет очень понятно.

1. НЕ ВЕЗДЕ сроки имеют место быть. Ищите работу где сроки не требуются. Таких мест полно. Это как правило долгоиграющие проекты принадлежащие бизнесу, а не говеные веб-студии, штампующие на заказ.

2. Сроки можно озвучивать, если вы пишите что-то, что вам понятно, задача прозрачна или типична. Есть задачи, когда о сроках не может быть и речи - например, поддержка/разбор чужого кода кода. На таких задачах сроках быть в принципе не может.

3. Приехал я как-то с поломкой машины к мастеру-частнику. Говорю - вот то то не работает. Сроки? А он мне отвечает - а я не могу сказать. Откуда я знаю что там сломалось?
Это я к тому, что даже такая в такой теме, как ремонт авто, где казалось бы все четко и все делается по наработанной схеме, сроки крайне не определены.

4. Если с вас требуют сроки, значит вы что-то делаете не так или работаете где-то не там. Про сроки можно говорит в строительстве, где укладка одной плитки СТАНДАРТНО занимает Н минут и вы должны полы покрыть 30х40 метров. Тогда сроки справедливы. В IT сроков не может быть. Т.е. не должен исполнитель думать о сроках. Это не его дело. Менеджмент должен дать время с запасом и не терзать исполнителя.

Не зацикливайтесь на этом. Продолжайте работать дальше.