Захар Кущенко

Тут речь о мягких навыках, в частности про управление собой и концентрацию.

Как вариант, использовать эту привычку во благо. Посещать ютуб стало привычкой, теперь нужно культивировать просмотр нужного контента.

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

Вот например, чтобы изучить что-то основательно, нужно курить 3-4 часовые видео + практика, но в реалиях такого энтузиазма мало у кого есть, поэтому, как вариант начать с 5-15 минутных видео. Просто начать.

У меня была точно такая же история, только вместо ютуба я читал тостер)))) Понимая, что не могу с собой ничего поделать, я начал просматривать по 300-400 советов из разных тематик ежедневно в том числе рубрики в которых я полный ноль. А позже я культивировал полезный поиск + сбор полезных материалов, в том числе из комментариев.

Я купил ежедневник, где что-то зарисовываю или записываю о том, что я смотрю и читаю, подстегивая себя к новым знаниям. Это своеобразная медитация. Скептически всегда относился к ежедневникам, но оказалось забавно, как такая штука может якорить и напоминать: не останавливайся, чувак!

В один момент, я понял, что хочу углубляться по вопросам и перескочил с тостера на видео, книги и практику. Начинал так же, с банальных вещей, которые культивировал. Например, что такое цвет? И по 15-20 мин ежедневно что-то читал, смотрел изучал, пока не захотелось это делать по 30 мин в день. некоторые вещи я хочу делать теперь по 3-4 часа в день.

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

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

Мягкие навыки 1
мягкие навыки 2
40 правил философии ответственности обрати внимание на 2 правило
теория психики
рекомендую его заметки

Давай ещё разок: тебе не сжигать мосты нужно, а выжать полезное действие из привычки.

0. Никаких резких перемен не будет.
1. Почитать про софт скилы и что формирует их.
2. Продолжить смотреть ютуб, разбавив ежедневной рубрикой "полезные 15 минут"
3. Окружить себя инфополем текущего уровня, пока не захочется на следующий. А захочется, так как эти 15 минут превратятся рано или поздно в 20, а потом в 30. Культивация полезного действия.
4. Попав на новый уровень, проделать тоже самое.

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

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

1. Такой кучи тегов даже у меня нет)) Если Вы знаете названия технологий, не говорит о том, что Вы знаете сами технологии. С Вашим опытом никто не поверит, что Вы имели реальный опыт со всем этим, а не просто hello world написали. Выберите те, в которых по Вашему мнению Вы лучше всего разбираетесь.

2.

Отличное знание WinForms, ASP.NET, LINQ и WPF. Паттерны: MVVM, MVP, Repository, IoC.

Для третьекурсника звучит самонадеяно. При такой формулировке на техническом собеседовании будут проверять "отличное" знание и я почти уверен, что Вы его провалите. Лучше сказать что-то подобие: имел опыт работы с, для реализации использовал технологии, имею <начальные> навыки работы с и т.д.

3.

Занимался исправлением мелких багов, написанием небольших SQL-запросов и unit-тестов, решал небольшие задачи.

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

4.

Если вспомнить css и html

Вот такое никогда не пишите. Лучше соврать или преувеличить, или даже написать "Отличное знание", но не так как Вы здесь сформулировали.

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

6. Опыта одного проекта мало. Где опенсерс проекты, где участия в хакатонах, где амбиции стартапов, посещение конференций? Работодатель хочет понимать как Вы заинтересованы развиваться, какие у Вас планы для дальнейшего роста. Он берет вас нулевым не из альтруистических побуждений, а с надеждой, что Вы быстро вырастите и вернете ему прибылью затраченное на Вас время. Из Вашего резюме видно только одно: я студент - дайте работу. А почему Вам, за какие такие заслуги и что с этого будет иметь работодатель - не понятно.

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

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

Это стандарт такой для ElectronJS?

Да. Программы на нём самые прожорливые, пушо запускается сначала огромный прожорливый Хром, а уже в нём ворочается прожорливый JS.

Веб-дизайнер должен знать:

• Свой стак инструментов, обычно это: Adobe Photoshop, Adobe Illustrator, Sketch или Figma, или Adobe XD, invision или principle (для анимации интерфейсов)/
• Уметь проводить юзабилити тестирование.
• Уметь работать с графикой (хотя бы как-то)
• Уметь проводить интервью с пользователями, получать фидбэк.
• Уметь работать с дизайн системами, понимать что такое UI-kit, паттерны, уметь ими пользоваться.
• Иметь тонкие навыки типографики, понимать что такое акценты, как сделать текст читабельным и т.д. и т.п.
• Уметь собирать интерактивные прототипы (figma, invision, adobe XD)
• Иметь чувство прекрасного
• Уметь обрабатывать изображения

Это минимум, а дальше по мере надобности и возможностей. Еще сейчас часто требуется UX/UI дизайнер, который умеет рисовать и сайты, и мобильные приложения.

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

А вакансий на веб-дизайнера море, по желанию всегда можно устроиться стажёром и всему этому обучиться.

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

Такие стандарты существуют. Наиболее известные - MISRA C и MISRA C++. Как можно догадаться, для языков С и С++, соответственно. Изначально созданы для автомобильной промышленности, но распространились и на аэрокосмическую отрасль, медицинскую технику, военных и прочие критичные к надёжности области. В том числе и АЭС.

Из MISRA C выросли SEI CERT C/C++, AUTOSAR General Software Specification, JPL Institutional Coding Standard for the C (стандарт NASA) и ещё куча других.

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

Помимо этого, существует ворох стандартов, описывающих подходы к организации процесса разработки и контроля качества. У каждой отрасли свои стандарты. Например, AS9100.

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

Update 2019-12-30:
На хабре появилась интересная статья с кратким обзором MISRA.

https://qna.habr.com/ (бывший toster.ru)
https://ru.stackoverflow.com/
Ну и гугл.

Очерёдность написания сайта вам никто не скажет, потому что её нет, а до банальных вещей вы и сами догадаетесь. В остальном ответы получают те, кто задают правильные вопросы. А где именно задавать: в гугле или на сервисе - не столь важно. Главное, знать, чего хочешь, и правильно формулировать (и оформлять, если надо).