Был похожий опыт, слишком хорошо справился с одной задачей от начальника, начальник почувствовал себя глупо, т.к. задача решалась гораздо проще чем он думал. После этого отношение ко мне только ухудшилось, меня просто игнорировали.
Далее использовал свободное время чтобы подучиться и найти другую работу прогером.
Полностью согласен, не хватает кармы чтобы плюсануть.
Есть близкая к теме книжка — «Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency»
Сам выгорел недавно, уволился, пара недель свободных вообще ничего не изменила.
Не было никаких переработок, зато был полный хаос, неразбериха кто что делает и кто за что отвечает; ужасное отношение менеджмента, типа перебросить всех JS фронтендеров на руби бэкенд, за месяц не разобрались, значит тупые, все ушли или были уволены; ну или на митинге при всех сказать что презентация дрянь и отпустить несколько едких комментариев о презентующем и всех остальных; а через несколько месяцев собрать из остатков новую команду фронтеэндеров.
Последним что видел был план — 4 новых приложения за год, никаких согласований сроков или что там будет.
В общем ни спокойствия ни определённости на протяжении нескольких месяцев.
Скомпрометируют lastpass — утекут все ваши пароли одновременно.
А разве содержимое не шифруется мастер-паролем?
Бумажки да, где-то сменил пароль, где-то восстановил и при изменении нельзя использовать старый, где-то требуют пароль чуть сложнее, где-то всё ещё http и я не хочу светить мой пароль.
В результате ворох сервисов с вариациями одного пароля. Плюнул и использую менеджер паролей.
Сам подход не нравится. Что будет если например потребуется отобразить предпросмотр перед публикацией и кнопку отменить? Или открыть модальное окно ещё раз?
И компонент Modal может превратиться в монстра с 20 возможными пропсами.
Согласен, проще было тогда уж написать e2e тест на Cypress, по крайней мере было бы больше уверенности что с изменением компонента ничего не сломалось, критерием что компонент работает будет что-то в реальном браузере.
Делловские ноутбуки, говорят, хороши. Лично у меня с тхинкпадами никогда проблем не было, а у них бывают весьма мощные модели (P-серия, например).
У меня Asus Zenbook, под линукс пришлось поменять wifi модуль и нужны были тонкие настройки чтобы некоторые фичи типа режима сна или авто регулировки подсветки клавиш работали корректно.
Беглый поиск в гугле показал что и на тинкпадах есть похожие мелкие проблемки.
Да это с любой осью так.
С линуксом этого больше всего. Вероятно после начальных сложностей это будет проще и приятней чем с маком, но эти первые сложности отпугивают.
Это вопрос субъективный. Я не нахожу UX на маках более удобным, а всякие мелочи (типа модального диалога выбора файла в сафари или непонятно как работающих виртуальных столов) есть.
Это да, файндер неудобный, рабочие столы тоже, но и то и другое используется не так часто. Но UX в целом лучше проработан.
Если работодатель уже пользуется линуксом, например, на серверах, то это должно быть не так уж и сложно.
Только убедить что я не глупее тех кто занимается безопасностью на серверах.
UX на маках отполирован, да и система в целом заточена чтобы хорошо работать на эппловском железе.
Линукс это сборная солянка и оно должно работать на всём подряд, не так много производителей заботятся чтобы на их железе линукс тоже работал без проблем.
Плюс купив мак гораздо больше вещей просто работает, большинству не нужны тонкие настройки.
Неважно как хорош линукс, популярность складывается из UX, маркетинга и брэнда.
Найти мощный ноут для разработки с линуксом или такой на котором линукс будет работать без танцев с бубном. Выбор этих ноутов не так велик.
Множество мелких проблем, которые придётся решать гуглом. В последнее время с этим лучше, но линукс всё ещё ассоциируется у большинства с тем что много чего придётся дорабатывать напильником
Интерфейс и UX в целом на маках более проработанный, может мелочь, но это влияет на выбор
Убедить работодателя что линукс будет безопасней чем OSX
Статья интересная, схожие с моими наблюдения. Организовать порядок выполнения тестов хорошая идея.
Юнит тесты тоже полезны, для маленьких чистых функций. Но большую часть времени е2е тесты(или интеграционные) дают уверенность что фича работает и не мешают рефакторить.
А подход писать юнит тесты на каждый чих в погоне за покрытием это маразм. Приводит к тому тесты становятся ритуалом, их пишут и исправляют абсолютно бездумно. Покрытие дает ложное ощущение что код хороший, хотя может быть неподдерживаемая лапша.
Потом это бездумное отношение перекидывается на код и начинается ад.
В прошлом проекте пеклись о юнит тестах и покрытии кода. В результате была уверенность что отступ будет 10рх и никакой уверенности что компонент в целом работает.
Без конкретных сложных примеров это статья ни о чем. Например селект с фильтрацией и мультиселектом или дейтпикер.
UI компоненты очень плохо тестируются юнит тестами, чем сложнее компонент тем меньше толка в юнит тестах. Неизбежно есть сайд эффекты и тестовая среда работает не так как браузер, плюс асинхронные фичи. Моки только делают ситуацию хуже.
Разумней иметь переиспользуемые маленькие чистые функции для любых целей, тестировать их на 100% юнит тестами. А более сложные компоненты тестировать e2e тестами.
Стремление к слепому 100% покрытию тестами не заменит продуманой архитектуры и рефакторинга. Но большое количество юнит тестов осложняет этот процесс.
Безусловно, иногда ситуации на работе или в семьи не оставляют на это времени.
Но бывают периоды когда назгрузка небольшая и можно сделать что-то для души.
Про 24/7 никто и не говорит, но хоть что-то за несколько лет в профессии должно накопиться. Хотя бы несколько репозиториев с экспериментами или по курсам.
Дело в том что в любом деле необходима увлечённость или даже страсть, иначе мастером в этом деле никогда не станешь.
Хобби проект как раз показывает что человеку интересна его профессия, что он как-то совершенствуется, а не тупо фигачит говнокод ради денег.
Есть небольшой проект на пару сотен звёзд на гитхабе.
Жаль что сейчас нет времени(или сил) его доделывать.
Проект принёс понимание как и почему софт обрастает багами и становится неподдерживаемым, а также важность SOLID, DRY и общих принципов проектирования.
import {gameConnect, gameStatus} from "../ducks/actions";
, и подобное
2. Css действительно хромает, формально он работает, но внося изменения легко что-то сломать,
position: absolute;
и
right: ...
не есть хорошо, выдаёт что опыта со стилями/вёрсткой нет.
3. Местами выглядит сложно, есть впечатление что код надёрган откуда-то, но и лапшой вроде не назвать.
Если UI работает шустро и хорошо (лень запускать), то можно простить некоторую переусложнённость из-за вебсокетов и асинхроньшины.
UI before API
Думаю что если человек подходит под все хотелки то может оказаться что расти на этом месте будет уже некуда, это тоже не есть хорошо.
Вероятно требования/пожелания к соискателю невнятно сформулированы или они просто придираются.
Далее использовал свободное время чтобы подучиться и найти другую работу прогером.
Не так часто но такое встречается.
Есть близкая к теме книжка — «Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency»
Сам выгорел недавно, уволился, пара недель свободных вообще ничего не изменила.
Не было никаких переработок, зато был полный хаос, неразбериха кто что делает и кто за что отвечает; ужасное отношение менеджмента, типа перебросить всех JS фронтендеров на руби бэкенд, за месяц не разобрались, значит тупые, все ушли или были уволены; ну или на митинге при всех сказать что презентация дрянь и отпустить несколько едких комментариев о презентующем и всех остальных; а через несколько месяцев собрать из остатков новую команду фронтеэндеров.
Последним что видел был план — 4 новых приложения за год, никаких согласований сроков или что там будет.
В общем ни спокойствия ни определённости на протяжении нескольких месяцев.
А разве содержимое не шифруется мастер-паролем?
Бумажки да, где-то сменил пароль, где-то восстановил и при изменении нельзя использовать старый, где-то требуют пароль чуть сложнее, где-то всё ещё http и я не хочу светить мой пароль.
В результате ворох сервисов с вариациями одного пароля. Плюнул и использую менеджер паролей.
И компонент Modal может превратиться в монстра с 20 возможными пропсами.
У меня Asus Zenbook, под линукс пришлось поменять wifi модуль и нужны были тонкие настройки чтобы некоторые фичи типа режима сна или авто регулировки подсветки клавиш работали корректно.
Беглый поиск в гугле показал что и на тинкпадах есть похожие мелкие проблемки.
С линуксом этого больше всего. Вероятно после начальных сложностей это будет проще и приятней чем с маком, но эти первые сложности отпугивают.
Это да, файндер неудобный, рабочие столы тоже, но и то и другое используется не так часто. Но UX в целом лучше проработан.
Только убедить что я не глупее тех кто занимается безопасностью на серверах.
UX на маках отполирован, да и система в целом заточена чтобы хорошо работать на эппловском железе.
Линукс это сборная солянка и оно должно работать на всём подряд, не так много производителей заботятся чтобы на их железе линукс тоже работал без проблем.
Плюс купив мак гораздо больше вещей просто работает, большинству не нужны тонкие настройки.
Неважно как хорош линукс, популярность складывается из UX, маркетинга и брэнда.
Но есть траблы:
Юнит тесты тоже полезны, для маленьких чистых функций. Но большую часть времени е2е тесты(или интеграционные) дают уверенность что фича работает и не мешают рефакторить.
А подход писать юнит тесты на каждый чих в погоне за покрытием это маразм. Приводит к тому тесты становятся ритуалом, их пишут и исправляют абсолютно бездумно. Покрытие дает ложное ощущение что код хороший, хотя может быть неподдерживаемая лапша.
Потом это бездумное отношение перекидывается на код и начинается ад.
Без конкретных сложных примеров это статья ни о чем. Например селект с фильтрацией и мультиселектом или дейтпикер.
UI компоненты очень плохо тестируются юнит тестами, чем сложнее компонент тем меньше толка в юнит тестах. Неизбежно есть сайд эффекты и тестовая среда работает не так как браузер, плюс асинхронные фичи. Моки только делают ситуацию хуже.
Разумней иметь переиспользуемые маленькие чистые функции для любых целей, тестировать их на 100% юнит тестами. А более сложные компоненты тестировать e2e тестами.
Стремление к слепому 100% покрытию тестами не заменит продуманой архитектуры и рефакторинга. Но большое количество юнит тестов осложняет этот процесс.
Но бывают периоды когда назгрузка небольшая и можно сделать что-то для души.
Про 24/7 никто и не говорит, но хоть что-то за несколько лет в профессии должно накопиться. Хотя бы несколько репозиториев с экспериментами или по курсам.
Хобби проект как раз показывает что человеку интересна его профессия, что он как-то совершенствуется, а не тупо фигачит говнокод ради денег.
Есть небольшой проект на пару сотен звёзд на гитхабе.
Жаль что сейчас нет времени(или сил) его доделывать.
Проект принёс понимание как и почему софт обрастает багами и становится неподдерживаемым, а также важность SOLID, DRY и общих принципов проектирования.
Мало что понял, но очень интересно. Не хватает кармы поставить плюс.
2. Css действительно хромает, формально он работает, но внося изменения легко что-то сломать, и не есть хорошо, выдаёт что опыта со стилями/вёрсткой нет.
3. Местами выглядит сложно, есть впечатление что код надёрган откуда-то, но и лапшой вроде не назвать.
Если UI работает шустро и хорошо (лень запускать), то можно простить некоторую переусложнённость из-за вебсокетов и асинхроньшины.
Думаю что если человек подходит под все хотелки то может оказаться что расти на этом месте будет уже некуда, это тоже не есть хорошо.
Вероятно требования/пожелания к соискателю невнятно сформулированы или они просто придираются.