Чтобы обратиться к какому-либо узлу, его сначала надо найти

Для этого есть разные методы, но в современном прототипировании чаще всего применяются два метода:

let el = document.querySelector(selector)
и
let elems = document.querySelectorAll(selector)

Оба метода получают на вход CSS-селектор элемента. Например:

let el = document.querySelector(".someClass b");

Отличие их в том, что querySelector вернёт один узел, который попался первым, а querySelectorAll вернёт список всех узлов на странице, соответствующих селектору.

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

Если же вам всё-таки нужен метод map, то вы можете преобразовать список узлов в массив при помощи конструкции [...nodeList]:

let arr = document.querySelecroAll("a");
[...arr].map(el => el.innerText);

Подробнее в видео: https://youtu.be/KIBv7QMToP4
И в примере с кодом: https://codepen.io/detepr/pres/mQqKZO

Шпаргалка продакта: жизненный цикл задачи

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

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

Как это работает

Сверху в шпаргалке стадии, под ними вопросы. Еще ниже инструменты, которые помогают на эти вопросы ответить.

Берёте задачу и прогоняете по вопросам. Находите то, о чем не подумали. Думаете, дополняете. На выходе получаете проработанное решение и план действий.
Пользуйтесь

Личная продуктивность

Что думал в начале 2019:
- Энергичный сфокусированный человек всегда выиграет у уставшего и раздёрганного.
- Чтобы быть энергичным и сфокусированным, нужно качественно спать (http://t.me/desprod/80), правильно питаться (http://t.me/desprod/123), много двигаться (http://t.me/desprod/145), ограничивать приток входящей информации (http://t.me/desprod/270), медитировать (http://t.me/desprod/343).
- Вообще страшно интересно узнавать о том, как работает твой организм, откуда у тебя берётся энергия, и максимально использовать это знание.
- Некоторые ребята пытаются ещё усилить эффект с помощью фармакологии (http://t.me/desprod/153), но, на мой взгляд, это супер-опасно — всё равно, что ковыряться обычной отвёрткой в тончайшем часовом механизме. Мы слишком мало знаем о долгосрочных последствиях приёма всех этих препаратов.

Что думаю в начале 2020:
- Вся эта «физиологическая» продуктивность не является достаточным условием того, чтобы у тебя что-то путное получалось. И даже необходимым условием не является.
- Всё это — гигиена. Не медитировать — то же самое, что не чистить зубы.
- Гораздо важнее, на чём именно мы собираемся фокусировать свою энергию и зачем нам это.
- Можно сколько угодно высыпаться, правильно питаться и заниматься физкультурой, но если у тебя нет чёткого честного ответа на вопрос о том, зачем ты работаешь, то толку от всей твоей энергии никакого.
- Уставший раздёрганный человек с сильной внутренней мотивацией вполне может выиграть у энергичного и сфокусированного. Особенно если последний не понимает, зачем в это всё ввязался, и на самом-то деле ничего не хочет. Зато когда у человека есть настоящая причина, которая его вдохновляет, он даже невыспавшийся готов свернуть горы.
- Так что, кажется, настоящая продуктивность начинается с ответа самому себе на вопросы «что надо сделать» и «зачем». Но это уже тема для отдельного разговора.

Вопрос: как менеджеру-гуманитарию начать разбираться в технических вопросах?

Для начала стоит принять, что как бы сильно вы ни старались — вряд ли вы станете говорить с командой на одном языке: они варятся в проекте по 6-8 часов в день, у вас столько времени попросту нет.

Затем попробуйте понять, а для чего вам собственно нужно разбираться? Если хотите иметь больше веса в обсуждениях (условное «чтобы вас не наебали») — тоже не выйдет: во-первых — вы не прораб на стройке и наёбывать вас никто не собирается, а во-вторых всё равно обманут, если захотят.

Если вы решили приносить больше пользы, к примеру предлагать более простые и остроумные решения, или интуитивно чувствовать сложность задач — то просто почаще общайтесь с командой. Подучите ваш язык программирования, попробуйте пройти обучающие туториалы вашего фреймворка (они рассчитаны именно на таких начинающих, как вы), а затем просто начинайте спрашивать у ребят, как работает та или иная часть системы. Любой человек с радостью открывается, когда видит искренний интерес к своей работе.

Пара часов таких разговоров в неделю — и через несколько месяцев месяцев вы начнёте приносить гораздо больше пользы на обсуждениях.

Вопрос: есть команда из трёх человек

Вопрос: есть команда из трёх человек: сильный разработчик, который делает быстро, но поверхностно; есть слабый разработчик, который делает медленно, но работающий код (и часто переделывает за сильным) и есть тимлид/пм (я), который не сильно разбирается в коде. Сильный буллит слабого, что тот не разбирается и вообще плохой программист. Что делать?

Давайте для начала разберёмся, почему вы считаете сильным того программиста, который буллит? Судя по вашему описанию, второй программист гораздо сильнее, чем первый — за ним не приходится переделывать.

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

Подумайте внимательно, насколько поведение первого программиста совместимо с профессионализмом на работе в вашем представлении? Как далеко он заходит в своём буллинге? Если недалеко (хотя мне сложно такое представить) — отправьте его на месяц или два в отпуск, посмотрите как команда поживёт через него. Если сильно — немедленно увольняйте, иначе второй просто сбежит или, ещё хуже, превратится в фикус, и вы в любом случае останетесь без двух программистов.

Время собирать фрукты

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

В выступлении Евгения Гурьянова из DocDoc на Product Sense (да, я всё ещё досматриваю то, что не успел послушать вживую в Минске) было про опыт использования этого подхода в масштабах компании и с активным использованием экспериментов. Команда Евгения проводит быстрые A/B проверки гипотез и примерно 2-3 из 10 экспериментов приносят рост конверсии. Причем не на пару процентов, как это обычно бывает, а сразу на 20-30! Вы удивитесь какие простые изменения могут дать заметный прирост в заявках от клиентов и, следовательно, в деньгах для компании!

Формат доклада тоже хорош. Фрукты Евгений классифицировал — будут и ананас, и груша, и даже картошка. Дело было в Минске... ;)