Что делать с джуниор программистом, который самоучка и не с этой планеты?
Во первых:
Нужно разделять личные качества и профессиональные!!
(Какая разница, что он бедный или хулиганил....)
Второе:
Если профессиональные качества вас устраивают, то пусть человек работает и не мешайте ему.
Если не устраивают, то ищите другого специалиста
Третье:
Срыв сроков это не только его вина или еще чья то. Часто так бывает, что это общая вина: заказчик меняет ТЗ, менеджмент обещает сроки, лишь бы ухватить заказ, технический директор не вникает в процесс.... В итоге всё вешается на джуна.
И еще:
Программист это творческая профессия. Это не оператором работать по 8 часов по некому алгоритму. Тут и думать надо и вникать и прорабатывать отдельные моменты. Нужно создавать условия для комфортной работы, а не наседать и стоять над душой. Но чтобы релакс не затягивался, даже долги нужно планировать.
Далее необходимо понять, почему возникают задержки:
Если это плохая планировка времени, то пусть работает как ему удобно (в ночное время или вечернее), если задержки возникают из-за недостатка знаний, значит нужно их подтягивать, включая курсы или помощь наставников.
И:
Он склонен всю задачу целиком держать в своей голове и думать над ней один. И чтобы никто не отвлекал. Обсуждать с кем-либо задачу, даже просто общаться в корпоративном чатике среди рабочего дня - все это вроде не дает видимых проблем, но по нему видно, что это его сильно раздражает.
Меня тоже раздражает отвлекаться каждые 5 минут на сообщения, которые вообще не относятся ко мне. А бесконечные обсуждения могут бесконечно обсуждаться.
Взялись работать - работайте. Летучка 10 минут каждый день с утра. 60 минут в понедельник. И всё. Ибо нех.
С ним же никогда не было начальника
Начальник не команда. Начальник может и не быть наставником, советчиком, помощником.
Более ценно, когда есть кому подсказать.
ведь тогда порядка было бы в сто раз больше, а работы меньше
Работы было бы меньше, если бы вы, там наверху, между собой всё порешали, а потом уже приходили со своими хотелками, а не переобувались каждый день со своим ТЗ "не знаю что хочу".
Пусть всё делает по-шагам.
Распишет архитектуру и сдаёт каждый модуль (вначале - логику, затем - рабочий код). Часть модулей - можно поручить делать другим. (устранили 2 проблемы)

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