afiskon

Он по-своему прав. Если нормально писать, то в большинтсве случаев все действительно понятно из кода. А комментарии только место занимают, да еще и со временем начинают вводить читающих их людей в заблуждение, если с кодом разъехались. Но если это часть корпоративной культуры, то просто не принимать pool request без комментариев, вот и все. Либо начнет писать комментарии, либо не будет делать фичей и вылетет "за неуспеваемость", тут уже ему решать.

На HeadHunter / BrainStorage просто поищите. Допускаю, что взять захотят не везде. Но программист со знанием Java и C++ и 20-и летним опытом залежаться не должен.

В добавок к ответу anyd3v я бы назвал еще систему контроля версий (желательно git), багтрекер (jira и тд), систему непрерывной интеграции (jenkins). Плюс отладочные средства в зависимости от того, что пишите. Скажем, если пишите REST-сервис, то это curl и tcpdump.

textbroker.ru

заливаете файл перевода, объясняете, что нужно делать, получаете обратно перевод.

Вот еще по теме eax.me/database-design

Попробуйте Perl или Python

Попробуйте Cygwin + поработать исключительно с софтом, который есть как под Linux, так и под Windows (см например, тынц и тынц). Когда заметите, что все используемые вами программы есть и под Linux, просто сносите винду и ставьте Ubuntu. Если ссыкатно, то сначала попробуйте под виртуалкой.

Читайте больше книг, пишите код, пробуйте новые технологии (СУБД, языки и так далее), С опытом придет.

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