Saathos Virgil

В огромно кол-ве компаний у HR есть четкий фильтр по опыту, вы его не проходите.
Большая часть компаний осуществлявших массовые стажировки начинающих специалистов из РФ ушли. Рынок младших специалистов и до этого, последние несколько лет, был не сахар, а сейчас можно сказать он совсем сдулся.
Джуны реально должны пробивать лбом стены, чтобы попасть к более менее приличное место.
Так, что держитесь за текущую позицию, набирайте 2-3 года опыта, все это время учитесь.

1. Оценивать эффективность работы, не понимая принципов разработки не получится — как минимум, высок риск демотивировать программистов.
   
2. Если есть проект и в нём руководитель проекта, который занимается именно проектом, но не понимает в разработке, то по классическим структурам команд (из того же PMBOK) нужен отдельный функциональный менеджер, который будет понимать в программировании и будет отвечать за производительность (требования, собеседования, инструменты, оценки и т.п.)
   
3. Эффективность очень сильно привязана к особенностям процесса разработки (agile/waterfall), особенностям проекта (например, какие цели — быстрее выдать результат, или обеспечить качество).
   
4. Заставлять сотрудников отмечать время недостаточно. Если им не разъяснено зачем это нужно делать (какие могут быть последствия), они, как умные люди, начнут что-то сами себе соображать и искажать статистику. А если проверяющий не понимает их работы, то не сможет ничего обоснованно предъявить.
   
5. Ну и есть у меня предположение, что за формально озвученным вопросом ("как следить за эффективной работой") скрывается настоящий вопрос ("не укладываемся в сроки/бюджеты", например). Хорошо бы начать с него, не всегда проблема решается с помощью таймшитов, возможно, у вас проблема с изменениями требований или вообще ошибочно выбрана архитектура ;) Учитывая, что в вопросе озвучен только один ПМ (без знания программирования) и ни одного технического "офицера", тут попахивает потерей управления вообще.
   

Легко проверить же:
Скрипт выдает такое:

a = 1234
b = 1234

print(id(a))
print(id(b))
print(a is b)

# 2221342169168
# 2221342169168
# True

Как видим - a и b ссылаются на тот же адрес памяти - python соптимизировал использование переменными памяти, поскольку в скрипте во время выполнения переменные не меняются.

В то же время в консоли создаются переменные в разных областях памяти:

>>> a = 1234
>>> id(a)
2715578112304
>>> b = 1234
>>> id(b)
2715578112432
>>>
>>> a is b
False

поскольку значение переменных больше 256 и заранее неизвестно как вы с переменными поступите дальше

Лутц - очень хорошо. И еще сделайте последовательно калькулятор, 2048, тетрис, блокнот, магазин на Django.

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

Письмо, полное сомнений и множества вопросов. Я не совсем понял что требуется от нас. Если отвечать на главный вопрос - то да. Перспективно. Go драйвит Google как основной язык для микросервисов. Но учитывая возраст кандидата я-бы спросил следующее.
- как с английским?
- как быстро обучаешся чему-то новому?
- согласен ли на релокацию?

Какие перспективы в РФ - понятия не имею но перспективы в зарубежных конторах - есть.

Хочу предупредить автора об ошибках которые я сам совершал. Я думал что дело в языках и технологиях. Но это не так. Дело в коммуникациях. Я работал минимум с 5 зарубежными компаниями и я своими глазами видел что мои знания просто нивелировались на фоне например моего не очень сильного английского. А другие teammates в силу широких коммуникатиционных скилов могли очень быстро найти контакт с нужными людьми и обходили
меня в карьере достаточно быстро.

По сути когда тебе за 40 - вообще не имеет значения какой язык ты знаешь. У тебя за плечами должен быть уже
такой багаж что тебя можно просто брать как опытного советника в технических вопросах. Язык можно подучить но если речь идет просто о распределенных системах и микро-сервисах то больше знаний требуется в части например анализа узких мест системы. Кеширования. Грамотного дизайна безопасности и репликаций и бекапов и восстановления от сбоев. Этот пласт знаний вообще лежит вне языка. И поэтому джун даже очень хорошо выучивший Go или Python не может решать такие вопросы. А автор - скорее всего может. Барьером может быть
какая-то банальность. Например язык. Поэтому я и спрашиваю.

wsl2 по сути виртуалка,
из коробки автоматически пробрасываются порты приложений открытых в wsl2 на хост ( но не наружу).

Eсли вы запускаете приложение в windows которое открывает порты,
это не значит что они будут проброшенны в эту виртуальную машину,
для доступа вам понадобится обращаться по ип адресу.

Вы также можете настроить весь стек внутри wsl2 или к примеру в докере

Так каждая игра по сути требует индивидуальный подход. Особенно это касается старых игр. Какое то обобщение можно сделать для игр на одном движке.

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