Иван В

Если вы хотите научиться именно хорошо верстать, то углубляйте знания в чистом CSS.
Изучите все самые современные техники и нововведения CSS, изучайте новые фичи CSS, которые только появились, и у них нет ещё полной поддержки в браузерах. Находите какие-то сложные примеры с CSS-tricks, пытайтесь сначала сами их повторить, а потом сравнивайте с оригинальным решением.

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

1. Agile - это про то что люди должны договариваться. По тому надо не намёки делать, а говорить прямо и предметно.

2. Вот вы говорите, что вам нужно ТЗ. А зачем вам оно нужно?
Вам не понятна та постановка, которая описывается в карточках?
Есть неоднозначность?
Уже есть примеры, когда от этой неоднозначности пострадал продукт (например из-за необходимости переделывать)?

Или вам нужно не ТЗ, а виденье того, чем в итоге должен стать продукт?
Не понятно, для чего вообще все эти карточки перекладываются?
Если так, то, вероятно, вам нужно не ТЗ, а какие-то OKR-ы, чтобы можно было от них отталкиваться при составлении задач.

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

им всё равно нужно самостоятельно планировать работу и отвечать за неё?

Этот момент мне не до конца понятен. Т.е., грубо говоря, начальство должно полностью разбираться в программировании, устройстве продукта, самостоятельно оценивать задачи и ганта строить?

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

Программирование - это как плаванье. Ты сколько книжек не читай - все равно программистом не станешь.
Ты просто должен сесть и начать программировать. Прыгнуть в воду и плыть.

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

Чаще заказывай code-review своего кода и слушай советы старших коллег. Даже если обидно и стыдно.
Слушай. Записывай и потом применяй.

По поводу Алгоритмов и Структур данных. Почитай Никлауса Вирта. Он как раз такую книгу и написал.

Фото ФИО.
Выжимка о себе чем там увлекаетесь и прочее, без фанатизма.
Строчка технологий, возможно стоит сгруппировать по логическим группам.
Ссылки на гит или проекты, но тоже без фанатизма
Блок с вашим образованием.
Список проектов от новых к старым:
Название проекта, дата, ваша роль, выжимка.

Я считаю себя скорее бэкэндщиком, и да - много раз пришлось фронт заново повторять, вспоминать очевидное, потому что тяжело решать какую-то простую "фронтовую" задачу раз в 2-3 года. За это время все забываешь, да.
Точно так же забывается golang, если долго программируешь на python, и вообще любые неиспользуемые знания пропадают - так уж мозг устроен.

Но две важных вещи:
1. Вспоминать забытое - просто и быстро, это не учиться с нуля. Скорее всего какой-нибудь cheatsheet поможет из сети или самодельный. Они не пропадают совсем.
2. Это все равно надо. Хороший специалист в любой сфере должен иметь некоторое представление и о смежных вещах. Бекэндщику никуда без хотя бы базовых знаний по фронтенду. Фронтендщику бэк, наверное, нужен немного меньше, но если хочется быть ценным специалистом - то все равно нужно.

Есть подозрение, что из-за него некорректно работает форма авторизации / регистрации на сайте.

Надо бороться с причиной, а не с явлением как таковым. Если форма криво работает из-под VPN, то виновата форма, а не VPN. Половина мира уже сидит в интеренет под VPN, поэтому стоит задуматься о том, что у тебя не так реализовано. Тем более, что каких то объективных причин нарушения работы web-сервера если на него поступают запросы от VPN нет.
Я бы скорее предположил, что в форме реализованы какие то скрипты (возможно даже сторонние JS библиотеки), который блокировщики рекламы считают спамом, и режут их, отсюда и проблема. Надо конкретно смотреть, что не так.

ак определить, что у пользователя включен vpn

Ну определишь ты, и что дальше? Как это тебе поможет реализовать исправление ошибки формы? Лучше задуматься о том, как исправить форму, чтобы все могkи ей пользоваться независимо от VPN.

Т.е. в резюме у вас будет NDА, а в трудовой название компании? Што?
Мне прям интересно, что это за компания которая не хочет чтобы ее в резюме упоминали. Гидра какая нибудь :)

С точки зрения росийского права такой пункт трудового договора - ничтожен. Смело соглашайтесь.

До подписания NDA - компанию можно и назвать

Ну хотя бы для того чтобы другие её отсекали.. А то там ещё и потом гимны петь заставят и т.п.

Со смехом, тк если работали официально, то место работы будет написано в трудовой.

Надеюсь никогда не попаду в компанию, где вы являетесь ПМом :) Без обид, ничего личного, но даже возникновение мысли об этом поспорить уже абсурд. Сначала заказчик/начальник хочет чтобы функционал был сделан еще вчера, а на архитектуру, практики кодирования мы положим ботл, а потом у них возникают вопросы откуда баги. Ну вот оттуда и баги. Производство ПО это такое же производство как и любое другое производство. Если бы мы говорили про автомобильную индустрию, то на сколько бы вам хотелось ездить на машине которую сделали за вечер потому что сроки горят, конкуренты нас обходят? Мне вот тоже не хотелось бы. По этому в любом другом производстве уже давно выстроены процессы, есть отделы тестирования качества и прочие вещи, которые позволяют уменьшить/исключить брак. И только в ИТ почему то до сих пор является нормальным забить болт на все практики производства и потом спрашивать за баги с разработчика. Когда у вас появится формальное описание ТЗ (именно формальное, т.е. формализованное) в котором просто не может иносказаний одного и того же пункта, когда у вас появится опытный архитектор который будет довольно долго планировать архитектуру проекта, когда у вас появится нормальная процедура тестирования специально обучеными людьми и у вас все равно будут баги, тогда можно и задуматься, а стоит ли платить разработчику за баги, ведь теперь у меня есть все условия для того, чтобы багов не было. А до тех пор советую на эту кривую дорожку не вставать. Вот простой пример, рассудите сами:
Есть некоторый код который использует некоторую библиотеку. В библиотеке есть баг который всплыл у вас на проде. Разработчик в этом виноват? Может он виноват в том, что выбрал не качественную библиотеку? А у вас выстроен формальный процесс верификации запчастей из который состоит ваш проект? А у разработчиков библиотеки хорошие процессы разработки были? Это ведь тоже программный код который так же кто-то разрабатывал.

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

Приведите пример багов ;)
Выясните по какой причине возник баг.
Может выясниться, что баг возник по вашей вине как руководителя, который не смог выставить четкое ТЗ, в котором нет двумысленностей.
Может выясниться, что баг возник по вине архитектора, который не предусмотрел совместимость каких-либо компонентов.
Может выясниться,что баг возник по вине аналитика, который писал описание фичи

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

Ну и не платить за работу - останетесь без разработчиков.

У меня примерно так:
1. Если задание выполнено строго по ТЗ и принято - любой вновь найденый баг - это уже новая работа которая должна быть оплачена.
2. Если задание не выполнено по ТЗ и баги при приемке не принимать - то это ошибка разработчика, пусть исправит.
---
3. ТЗ должно быть составлено так чтобы не могло быть двойного трактования - если ТЗ позволяет трактовать задачу размыто и компания может предполагать одно, а исполнитель другое - ошибка того кто дал это задание разработчику - соответственно это не проблема разработчика, он не знает что у вас в голове и работа по переделке будет оплачена.
---

А вообще никаких общих правил не существует - как договоритесь так и будет.

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

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

Здравствуйте!

Если Вы положите правильные зависимости, то данные будут подтягиваться при их изменении

const getWeather = React.useCallback(async () => {
    try {
      setLoading(true);
      const response = await axios(urlCoords);
      const data = await response.data;
      setData(data);
      setLoading(false);
    } catch (error) {
      alert('Failed to load resource');
      console.error(error);
      setError(error);
      setLoading(false);
    }
    setLocation('');
  }, []);

  React.useEffect(() => {
    if (lat && long) {
      getWeather();
    }
  }, [lat, long, getWeather]);

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

Так что настройте и на будущее при переговорах это обсуждайте, и вопросы примерно следующие:

* Формат поставки
* Операционная система
* Доступы
* Права на исходный код
* Порядок приемки кода
* Прочее

То есть чем более точно вы все опишите в ТЗ и договоре, тем меньше у вас будет проблем