Как мне кажется, эмоциональное выгорание - это очень частый спутник творческих профессий. Дело в том, что есть огромная разница, когда ты делаешь что-то в удовольствие и для себя и когда ты этим зарабатываешь.
Поэтому например сейчас стало появляться много материалов про выгорание, то как с этим жить, у некоторых ИТ-компаний есть wellbeing-программы, которые помогают с такими вещами справляться.
Все что вы изучали так или иначе всегда пригодится. Скажем, тот же TypeScript вовсе не отменяет знаний JS, он добавляет новую абстракцию и большую строгость, но он основан на JS и компилится-таки в него.
Дополнительную мотивацию можно взять из вашей же предметной области (вы писали, что вы морской инженер с большим опытом), возможно, вам будет интересно развиваться в ПО для вашей предметной области. Несомненный плюс умения программировать - оно может быть приложено куда угодно. И это круто!
P.S. Очень смело и классно что вы написали о своем опыте и отрефлексировали его. Люди могут резко менять профессиональную деятельность или искать себя снова и снова и это нормально. Я вас поддерживаю, вы молодец!
Профессура обычно забывает о том, какие комментарии уместны, а какие нет. Документирующие комментарии, объясняющие для чего функция, объект и т.п. нужны - очень даже нужны, а вот "профессорские" // присваиваем x 5 " не нужны и засоряют код
Здесь интересный момент. Мне много так говорили, но дело в том, что "рамки поставленной задачи" понятие условное. Например, корифеи программирования (вроде Дядюшки Боба, Макконнелла и так далее) говорят нам про правило бойскаута - если ваша задача требует рефакторинга, проведите рефакторинг и приберитесь, потому что архитектура системы должна развиваться. Однако, когда ты приходишь и говоришь "Думаю, нам нужно улучшить здесь и здесь, чтобы решение легко хорошо" чаще всего тебе как раз этой фразой и отвечают - "Не выходи за рамки поставленной задачи".
Я, конечно, могу написать "чтобы работало" и успокоиться. Но что делать с пониманием того, что это очередное размещение костыля, а не решение проблемы?
У Ворда есть такая штука как поля. Поиск текста по плейсхолдерам это очень и очень топорное решение. Гораздо гибче еслр вы создадите 2 кастомных поля в документе (причина, отработка, ещё можно добавить название компании, ФИО и должность руководителя) в коде вы просто заполняете поля и вызываете UpdateFields(). Все. Код сильно сократится в таком случае
Легко видеть, что у полиномиального уравнения, в котором степень переменных не превышает 1, типа y = 3x + 4, есть бесконечное число рациональных решений. Любое рациональное значение x даёт рациональное значение y, и наоборот.
Простите, что? Корнем этого уравнения (как и любого линейного уравнения) будет являться одна и только одна точка. Никак не их бесконечное множество. Ну и да, статья написана несколько грубовато
А где первая часть?)))
Добавьте speech-to-text и text-to-speech и будет вам щастье))
Ну вот, круто! Я правда бэк и C#, поэтому всю прелесть фронта заценить не могу, но мало ли, вдруг общие вопросы будут, обращайтесь, если что
Правило 10к часов все же не работает. И это уже давно не новость, а так, да, можно много чем заняться в IT, не обязательно писать код
Как мне кажется, эмоциональное выгорание - это очень частый спутник творческих профессий. Дело в том, что есть огромная разница, когда ты делаешь что-то в удовольствие и для себя и когда ты этим зарабатываешь.
Поэтому например сейчас стало появляться много материалов про выгорание, то как с этим жить, у некоторых ИТ-компаний есть wellbeing-программы, которые помогают с такими вещами справляться.
Все что вы изучали так или иначе всегда пригодится. Скажем, тот же TypeScript вовсе не отменяет знаний JS, он добавляет новую абстракцию и большую строгость, но он основан на JS и компилится-таки в него.
Дополнительную мотивацию можно взять из вашей же предметной области (вы писали, что вы морской инженер с большим опытом), возможно, вам будет интересно развиваться в ПО для вашей предметной области. Несомненный плюс умения программировать - оно может быть приложено куда угодно. И это круто!
P.S. Очень смело и классно что вы написали о своем опыте и отрефлексировали его. Люди могут резко менять профессиональную деятельность или искать себя снова и снова и это нормально. Я вас поддерживаю, вы молодец!
Профессура обычно забывает о том, какие комментарии уместны, а какие нет. Документирующие комментарии, объясняющие для чего функция, объект и т.п. нужны - очень даже нужны, а вот "профессорские" // присваиваем x 5 " не нужны и засоряют код
Здесь интересный момент. Мне много так говорили, но дело в том, что "рамки поставленной задачи" понятие условное. Например, корифеи программирования (вроде Дядюшки Боба, Макконнелла и так далее) говорят нам про правило бойскаута - если ваша задача требует рефакторинга, проведите рефакторинг и приберитесь, потому что архитектура системы должна развиваться. Однако, когда ты приходишь и говоришь "Думаю, нам нужно улучшить здесь и здесь, чтобы решение легко хорошо" чаще всего тебе как раз этой фразой и отвечают - "Не выходи за рамки поставленной задачи".
Я, конечно, могу написать "чтобы работало" и успокоиться. Но что делать с пониманием того, что это очередное размещение костыля, а не решение проблемы?
Инвестигатор (investigator) - это полностью заимствованное понятие, соответственно и парное с ним тоже прямо заимствуется
У Ворда есть такая штука как поля. Поиск текста по плейсхолдерам это очень и очень топорное решение. Гораздо гибче еслр вы создадите 2 кастомных поля в документе (причина, отработка, ещё можно добавить название компании, ФИО и должность руководителя) в коде вы просто заполняете поля и вызываете UpdateFields(). Все. Код сильно сократится в таком случае
А .NET тут причем?
ru.wikipedia.org/wiki/Меандр_(радиотехника)
Простите, что? Корнем этого уравнения (как и любого линейного уравнения) будет являться одна и только одна точка. Никак не их бесконечное множество. Ну и да, статья написана несколько грубовато