Agelka

Структуры данных нужно учить в каком-то языке программирования.

Собственно вся суть в том, что кроме чисел и строк есть массивы, ассоциативные массивы, кортежи, собственные структуры, готовые объекты и так далее.

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

Основное чему нужно научиться - самоорганизации.
Уметь не лениться и ждать пока кто-то принесет самую лучшую книгу или подскажет самый лучший курс. Гуглить незнакомые термины.

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

Начните с html/css/javascript и питон, потом добавите sql.
И не что-то из этого, а все вместе.

Самый хороший ответ, который я получил на этот вопрос, что знания PM должен быть "a mile wide and an inch deep" :-)
А если серьёзно, то:
1. Традиционные методологии и стандарты проектного управления: PMI, Prince2, IPMI.
2. Гибкие методологии управления разработкой ПО: Agile, SCRUM, Lean, XP.
3. Выбрать один стандарт управления, на котором вы будете специализироваться и знать его глубоко.
4. Знать ГОСТ 34.602-89 «Техническое задание на создание автоматизируемой системы».
5. Ознакомиться с распространёнными нотациями, предназначенную для формализации и описания бизнес-процессов(IDEF, UML, BPMN).
6. Изучить ПО для ведения и управления проектами (MS Project, JIRA - обязательно). Вот хорошая подборка - https://habrahabr.ru/post/276873/

И, основное, уметь общаться с людьми! Это, наверное, самое главное. Большая часть проблем возникает от недостатка коммуникации между участниками проекта (IMHO)

Суть - убрать все преграды на пути работы команды.

Уметь слышать и понимать

Преграда 1 - коммуникации, разработчики не хотят этим заниматься, по этому мы должны сделать это за них, понять, что необходимо заказчику.

Уметь говорить

Мало понимать заказчика, мы должны еще объяснить программистам \ дизайнерам на на их языке то что необходимо заказчику. Из этого пункта мы получаем следующее:

1) Коммуникации - наше всё.
2) Говорить с командой на одном языке жизненно необходимо

Формулируй, властвуй, распределяй.

Хорошо написанное ТЗ - минус дохрелион человекочасов работы и тонны нервных клеток, помните, что даже если ТЗ написано идеально - программист все равно скажет, что оно херовое (чтоб ПМ не расслаблялся, а то иш тут менеджер...)

Планируй

Календарный план, Jira и ко - наши бро, планируй вехи и спринты и следи за планом, но без наркомании, не нужно анально карать всех вокруг за то что просрочили такс на 1 час.

Риск менеджмент

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

Менеджмент

Ну и разумется ПМ это менеджер, который может управлять командой, настроем команды, управлять конфликтами (искусственными) либо нейтрализовать их если они негативные.

Минутка полезного чтения - советы начинающим руководителям проектов