Shadom

2. Писать на С++/CLI. Только тут я не понимаю, как их совместить.
Ну написал я код на С++/CLI, а как мне его в проект , написанный на С# вставить ?

Этот вариант неплохо разжеван в этих двух вопросах.
Можно ли совместить в одном проекте программы написанные на разных языках (C++, C#) в VS2012?
Как динамически подключать библиотеки?

Этот вариант на деле оказался самым удачным, потому что деление проекта на три части (C++; CLI; C#) так же строго делит и области ответственности. На стороне C# остается только интерфейс, на стороне CLI - только связь с низким уровнем, на стороне C++ - только низкий уровень.
Целостность кода сохраняется, библиотеку низкого уровня можно с равной легкостью подключить как к библиотеке CLI, так и к другому низкоуровневому проекту.

Собирать из исходников нужно в очень редких случаях, на столько редких, что знать как это делается вообще не нужно. Так что можно смело отмести этот навык.

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

Для бекендера надо уметь устанавливать и настраивать тот софт с которым работаешь: nginx, apache, mysql, postgres, redis, mongodb и так далее.

Vim можно вообще не знать, в *nix обычно есть редактор проще, типа nano, joe или вообще mcedit.
Самое главное - научиться выходить из vim прежде чем испортишь файл ;-)

Если работаешь с языком, у которого есть свой пакетный менеджер (npm, yarn, pip) нужно уметь установить его и разруливать ошибки при установке через эти пакетные менеджеры.
Например для python-pip требуются установленные компилятор и заголовочные файлы питона. Имею ввиду, что такие тонкости надо знать.

ssh само собой надо уметь настраивать, генерация ключей, настройка авторизации по ключу, копирование файлов scp.

git настраивать bare-репозитории чтобы заливать на сервер и там же разворачивать, при работе без сторонних сервисов типа github, bitbucket.

Центральный показатель для бизнеса, а следовательно и руководителей, как людей представляющих интересы этого самого бизнеса - это коэффициент возврата инвестиций (ROI). Соответственно, сотрудник должен приносить компании больше денег, чем потребляет. Естественно, что чем выше разрыв между затратами и прибылью, тем лучше, поэтому фонд оплаты труда руководитель должен держать на том минимальном уровне, который гарантирует бесперебойную работу сотрудников. Один из факторов этой бесперебойности - низкая текучка. Сотрудников терять нежелательно. И чем ценнее для компании сотрудник, чем более он профессионален и/или чем больше на него завязано, тем дороже обходится его потеря. Натурально в деньгах. Придётся затратить больше, чем обычно, денег на поддержание работы без него. Придётся затратить деньги и время (те же деньги) на поиск, найм, введение в работу, возможно, обучение нового сотрудника. При этом он может оказаться совсем неподходящих и цикл придётся повторить. Или может оказаться просто хуже прошлого и эффективность отдела снизится. Поэтому, когда сотрудник приходит просить прибавку, руководитель оценивает может ли этот сотрудник уйти или только блефует, насколько легко его будет заменить, какой урон компании будет нанесён его уходом. Потом руководитель оценивает стоимость расширения ФОТ - есть ли резервы, какой сейчас ROI, будет ли больший ROI от реинвестиции этих средств во что-то другое? Если уход сотрудника будет стоить меньше, чем увеличение ФОТа, сотруднику откажут.

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

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

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

До окончания проекта вы можете лишь создавать видимость профессионализма, а реальная его оценка будет после завершения проекта.

Чтобы создать видимость профессионализма нужно:
1. говорить уверенно
2. слушать, а не навязывать
3. демонстрировать уверенное владение технологией производства
4. говорить о проблемах и методах их решения/устранения
5. отстаивать свои интересы

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

Когда заказчик поймет предлагаемую технологию, поймет что вы ее прекрасно знаете, что вы знаете все тонкие места и подводные камни (то есть делали это многократно) - тогда вы создадите видимость своего профессионализма.

Чем лобби Microsoft хуже, чем лобби Oracle? А по факту сейчас C# более развитый язык с гораздо большим количеством синтаксического сахара и проще "во вхождении".

Вообще сначала поделюсь своим мнением по тематике вопроса. Не понимаю почему люди так рьяно не любят вопросы не об IT, на тостере? Я лично убедился, что например в моей области проф. форумов нет, я специалист по компьютерной графике, и немножко программист. Я чуть чаще чем всегда обращаюсь с вопросом не связанным с IT напрямую, на тостер или SO, ну или другие форумы программистов. А где по вашему еще такое развитое сообщетсво состоящее преимущественно из людей умных? Да человек обратился со вопросом психологии на форум технарей. А куда еще? На формум недопсихологов? Получить очевидный ответ, что ему нужно социализироваться? Как раз таки на форумах и QA сервисах по моему и можно получить, четкий, структурированный и логичный ответ, так как тут сидят люди, которые думают четко и структурировано, много и о разном, возможно и о его проблеме они думали, так как профессия у них такая- думать!
Теперь к твоей проблеме. Я нашей самый действенный для меня способ. Просто не ссы. Делай. Одна проблема если у тебя словарный запас как у банки с огурцами, другое дело если ты не можешь выразить свои мысли, хотя в голове все красочно и логично. Говорить это навык. Развивай его. Попробуй английский поучить. Дойдешь до стадии когда будешь развивать разговорный английский, придется говорить с кем нибудь. Вот так и научишься. Заводи знакомства, вобщем делай все, что делают обычные люди. Только не в этих ваших разумеется. Серебрянной пули тут как и везде - нет. Серебрянная пуля это пытаться имитировать, то что делают другие люди. Посмотри на людей вокруг. Допустим ты хочешь стать чотким пацаном, качком таким, который лицо на ноль поделит кому угодно. Но ты не знаешь как. Что делать? Все просто, смотришь и анализируешь, что делают эти парни, и делаешь как они. Идешь в качалку, на бокс, заводишь девушку. И так в любой человееской деятельности.
Ну и удачи тебе, а вопрос твой скорее всего скоро удалят, а жаль.

Замена HDD на SSD, добавление DDR до 8.

Позволю себе дать вам более абстрактный совет: не ведите общего бизнеса с друзьями, не берите у них в долг и не одалживайте сами. Это самый верный способ потерять друга.

Рано или поздно вам придётся делать выбор между дружбой и профессионализмом. Если хотите работать в команде, ищите единомышленников-профессионалов.

Таблица принятия решений (таблица решений) - очень эффективное решение для такого рода задач.
Из русской Википедии:

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

На английском - Decision table - можно найти гораздо больше полезного материала, чем на русском. Допустим, это видео с объяснением.
Таблицы можно хранить в СУБД и обмениваться при помощи CSV.
IBM и многие другие компании применяют их в разных своих продуктах. Особенно полезны для описания деятельности бухгалтерии, складского учета и пр.