Была та первая обезьяна, которая взяла в руки палку. Была та первая обезьяна, которая задала вопрос: "зачем?". Несмотря на то, что обезьяна с палкой лучше распиарена, та вторая первая обезьяна - это на самом деле откуда происходит человек.
У меня аккаунт на реддите с мая 2013 года. Не одну попытку я делал его понять и полюбить. Не видел я там ни разу чего-то похожего на хабр - когда из пары обсуждений выносишь за 20 минут больше чем из книжки, которую неделю читать будешь. На вот этом вот своём фундаменте спросил если можете примеры показать. Реддит не большой, там просто дохрена народу. Наиболее ценное, что мне там удавалось найти - ссылку на статью в каком-то блоге.
Чёт не понял ваш ответ. Гуглом активно пользуюсь с момента его появления, обучаю других, владею акциями Alphabet.
Я говорю о том, что с моей точки зрения реддит (как и большинство англоязычных ресурсов, предполагающих обсуждения) очень слаб в плане "поиска истины". В большинстве случаев обсуждения очень плоские и бездуховные, и читать там особо нечего.
Ищу статьи в гугле по своим текущим вопросам/задачам, если статья нравится, подписываюсь на автора через feedly, раз в неделю посмотриваю ленту всех подписок и кладу интересное в pocket. Всю неделю читаю pocket.
Только это конечно не один ресурс, а активное гугление.
Могли бы показать в качестве примеров пару тем на реддите с хорошим таким жирным обсуждением, чтоб прям кто-то пришёл там, хорошо написал, а ему вульгарную прагматичную аргументированную критику? Ну, типа как на хабре принято.
Я хожу на хабр из-за токсичной сектантской аудитории - тут "средний" комментарий на порядок содержательнее комментов на англоязычных ресурсах. В рунете намного сильнее развита традиция обсуждений.
Но хорошие статьи на англоязычных ресурсах конечно легче находятся. Практически на хакер ньюз подписался - и всё, проблема чтения за завтраком решена.
Перформанс ревью имеет такое же отношение к софт скиллз, как и к хард скиллз. У "хороших" программистов принято хард скиллз прокачивать независимо от того, что там менеджер на ревью сказал. Почему для прокачки софт скиллз механизм должен быть принципиально другим?
А теперь вы пишете про перформанс ревью в большой компании и снова не про софт скиллз. Я понимаю о чём вы, только это не про софт скиллз всё, а про неадекватные попытки их измерять.
ИМХО, софт скиллз - это как качество кода: у всех есть какие-то соображения насчёт хорошего и плохого кода, но вот взять кодовую базу и сказать, что качество у неё 4.92 из 10 - это всегда глупость.
Я правильно понимаю, что это работает только для валидации, которая не требует какого-то внешнего контекста? Вот например если я хочу Email проверять не только синтаксически, но ещё и на тему отсутствия в блеклисте в БД.
Второй вопрос - в сценарии с десериализацией DTO, состоящего из name/email/age - правильно понимаю, что ошибка десериализации будет содержать только первую ошибку? Т.е. если email и age оба некорректные, то на email оно упадёт, а на age даже не посмотрит?
Это вы написали не про софт скилз, а "как тяжело быть джуниором". Это джуниоров кидают с проекта на проект, с задачи на задачу - без возможности проникнуться проблемой, порефлексировать, спланировать работу на пару недель вперёд.
Чем сеньёрнее, тем больше ожиданий от окружающих насчёт "понять проблему и объяснить коллегам и начальству", "придумать решение и объяснить коллегам и начальству", "написать дизайн-документ, чтобы зафиксировать решение где-то кроме своей головы", "напомнить коллегам и начальству, что вот есть дизайн-документ, там все ответы", "иметь яйца побыть совестью команды, когда кто-то начинает рассказывать, что дедлайн уже через 2 дня, поэтому код ревью и юнит-тесты временно нужно отменить", и т.д.
Софт скиллз - это про то, как надо себя вести, чтобы не оказываться в ситуациях вроде всех тех, которые вы предложили в своих "токсичных" примерах.
На первом этапе происходит анализ всех материалов, рынка, потребителей и поведения пользователей. Необходимо провести исследование, в ходе которого нужно изучить рынок, изучить конкурентную среду, изучить пользователя и его проблемы, углубиться в суть тех гипотез инсайдов, которые стояли на входе в этот проект. Понять какие конкретно задачи у пользователя не решены, а если решены то, кем и как, возможно на рынке найдутся продукты, которые решают те же самые пользовательские задачи уже довольно хорошо.
Как и кем должна проводиться граница: наши пользователи vs. не наши пользователи, наши проблемы/задачи vs. не наши?
Для этого я использую четыре основных инструмента: 1. Miro 2. Notion 3. Электронные таблицы 4. Планировщики
Очень неспециализированный набор инструментов - больше, чем "просто бумага", но меньше чем "компьютер". Это из-за того, что более специализированного софта нет или из-за того, всех устраивает на честном слове? Вот например вы пишете:
Вот несколько признаков зрелой компании в сфере IT: ... 2. Клиенты компании сегментированы; портреты клиентов в каждом сегменте, а также их потребности и мотивы, задокументированы. 3. Есть сформулированные продуктовые метрики и инструменты контроля.
Сегменты каким образом описаны/зафиксированы? Просто текст? Продуктовые метрики чем именно трекаются и какими инструментами вы их анализируете?
Мне видится, что в "зрелом" процессе всевозможные решения должны быть гвоздями прибиты к цифрам, чтобы когда задаётся вопрос: почему радиус скруглённости кнопок у нас 3 пиксела, можно было проследить цепочку от коммита в гите - к задаче в джире, от задачи в джире - к какому-то источнику требований, от источника требований - к исследованию, от исследования - к сырым данным, и в итоге дать ответ, что кнопки у нас такие потому что 14 месяцев назад мы сделали A/B тестирование, которое показало, ...
UX-дизайнер - это очень расплывчатое понятие: начиная от синонима "web-дизайнер" и до самого "продакт менеджер".
В теории UX-дизайнер - это такой разносторонне развитый специалист, который может практически всё кроме написания кода: и предметную область понимает, и маркетинговые исследования проводить может, и фичи придумывает, и прототипирует, и проверяет на живых людях, и мысли пользователей читает, и каждое своё решение может объяснить и подкрепить какими-то данными, собранными во время исследований.
А из моего опыта на практике UX-дизайнер - это просто человек, который с умным выражением лица принимает решение по поводу цвета и border-radius для кнопок.
Была та первая обезьяна, которая взяла в руки палку. Была та первая обезьяна, которая задала вопрос: "зачем?". Несмотря на то, что обезьяна с палкой лучше распиарена, та вторая первая обезьяна - это на самом деле откуда происходит человек.
И не Томас, а вообще Джон Галт.
Поправлю немного: либо считают хамством, либо безгранично ценят за прямоту и расставление точек над i.
Я хожу на Хабр из-за комментариев. Часто статья может быть никакой, при этом в комментариях ценного больше, чем в статье.
У меня аккаунт на реддите с мая 2013 года. Не одну попытку я делал его понять и полюбить. Не видел я там ни разу чего-то похожего на хабр - когда из пары обсуждений выносишь за 20 минут больше чем из книжки, которую неделю читать будешь. На вот этом вот своём фундаменте спросил если можете примеры показать. Реддит не большой, там просто дохрена народу. Наиболее ценное, что мне там удавалось найти - ссылку на статью в каком-то блоге.
Чёт не понял ваш ответ. Гуглом активно пользуюсь с момента его появления, обучаю других, владею акциями Alphabet.
Я говорю о том, что с моей точки зрения реддит (как и большинство англоязычных ресурсов, предполагающих обсуждения) очень слаб в плане "поиска истины". В большинстве случаев обсуждения очень плоские и бездуховные, и читать там особо нечего.
Ищу статьи в гугле по своим текущим вопросам/задачам, если статья нравится, подписываюсь на автора через feedly, раз в неделю посмотриваю ленту всех подписок и кладу интересное в pocket. Всю неделю читаю pocket.
Только это конечно не один ресурс, а активное гугление.
Могли бы показать в качестве примеров пару тем на реддите с хорошим таким жирным обсуждением, чтоб прям кто-то пришёл там, хорошо написал, а ему вульгарную прагматичную аргументированную критику? Ну, типа как на хабре принято.
Одно время был подписан на dev.to - там 90% джуниорский мусор с хелоу ворлдами и спасибками в комментах.
Вот прямо сейчас в самом верху: https://dev.to/bespoyasov/clean-architecture-on-frontend-4311 Смотрите комменты какие:
Ну нафиг, уж лучше токсичный хабр :-)
Я хожу на хабр из-за токсичной сектантской аудитории - тут "средний" комментарий на порядок содержательнее комментов на англоязычных ресурсах. В рунете намного сильнее развита традиция обсуждений.
Но хорошие статьи на англоязычных ресурсах конечно легче находятся. Практически на хакер ньюз подписался - и всё, проблема чтения за завтраком решена.
Перформанс ревью имеет такое же отношение к софт скиллз, как и к хард скиллз. У "хороших" программистов принято хард скиллз прокачивать независимо от того, что там менеджер на ревью сказал. Почему для прокачки софт скиллз механизм должен быть принципиально другим?
А теперь вы пишете про перформанс ревью в большой компании и снова не про софт скиллз. Я понимаю о чём вы, только это не про софт скиллз всё, а про неадекватные попытки их измерять.
ИМХО, софт скиллз - это как качество кода: у всех есть какие-то соображения насчёт хорошего и плохого кода, но вот взять кодовую базу и сказать, что качество у неё 4.92 из 10 - это всегда глупость.
Я правильно понимаю, что это работает только для валидации, которая не требует какого-то внешнего контекста? Вот например если я хочу Email проверять не только синтаксически, но ещё и на тему отсутствия в блеклисте в БД.
Второй вопрос - в сценарии с десериализацией DTO, состоящего из name/email/age - правильно понимаю, что ошибка десериализации будет содержать только первую ошибку? Т.е. если email и age оба некорректные, то на email оно упадёт, а на age даже не посмотрит?
Это вы написали не про софт скилз, а "как тяжело быть джуниором". Это джуниоров кидают с проекта на проект, с задачи на задачу - без возможности проникнуться проблемой, порефлексировать, спланировать работу на пару недель вперёд.
Чем сеньёрнее, тем больше ожиданий от окружающих насчёт "понять проблему и объяснить коллегам и начальству", "придумать решение и объяснить коллегам и начальству", "написать дизайн-документ, чтобы зафиксировать решение где-то кроме своей головы", "напомнить коллегам и начальству, что вот есть дизайн-документ, там все ответы", "иметь яйца побыть совестью команды, когда кто-то начинает рассказывать, что дедлайн уже через 2 дня, поэтому код ревью и юнит-тесты временно нужно отменить", и т.д.
Софт скиллз - это про то, как надо себя вести, чтобы не оказываться в ситуациях вроде всех тех, которые вы предложили в своих "токсичных" примерах.
Как и кем должна проводиться граница: наши пользователи vs. не наши пользователи, наши проблемы/задачи vs. не наши?
Не выдержав нагрузки, сломался завод по сжиганию говорильщиков об IT.
Очень неспециализированный набор инструментов - больше, чем "просто бумага", но меньше чем "компьютер". Это из-за того, что более специализированного софта нет или из-за того, всех устраивает на честном слове? Вот например вы пишете:
Сегменты каким образом описаны/зафиксированы? Просто текст? Продуктовые метрики чем именно трекаются и какими инструментами вы их анализируете?
Мне видится, что в "зрелом" процессе всевозможные решения должны быть гвоздями прибиты к цифрам, чтобы когда задаётся вопрос: почему радиус скруглённости кнопок у нас 3 пиксела, можно было проследить цепочку от коммита в гите - к задаче в джире, от задачи в джире - к какому-то источнику требований, от источника требований - к исследованию, от исследования - к сырым данным, и в итоге дать ответ, что кнопки у нас такие потому что 14 месяцев назад мы сделали A/B тестирование, которое показало, ...
Эпл - дерьмо
(держатель акций эпл, владелец макбука, айпада и айфона)
UX-дизайнер - это очень расплывчатое понятие: начиная от синонима "web-дизайнер" и до самого "продакт менеджер".
В теории UX-дизайнер - это такой разносторонне развитый специалист, который может практически всё кроме написания кода: и предметную область понимает, и маркетинговые исследования проводить может, и фичи придумывает, и прототипирует, и проверяет на живых людях, и мысли пользователей читает, и каждое своё решение может объяснить и подкрепить какими-то данными, собранными во время исследований.
А из моего опыта на практике UX-дизайнер - это просто человек, который с умным выражением лица принимает решение по поводу цвета и border-radius для кнопок.