Eu estive em uma situação muito semelhante à sua há cerca de um ano atrás. Comecei a trabalhar com pouca experiência em programação (embora soubesse um pouco de OO e algumas outras linguagens para começar) e a única pessoa que estava me ensinando tinha muito pouco tempo. Ele sempre foi útil, mas eu senti que não gostaria de fazer todas as perguntas que fiz.
Outros já sugeriram coisas extremamente úteis aqui (escrever testes de unidade, por exemplo, mas da minha própria experiência, isso é algo que teria ido um pouco "longe demais" para mim do zero; ou comentar você mesmo partes do código, mas isso pode ser difícil dependendo do primeiro ponto / pergunta que vou fazer em um minuto). Os pontos a seguir resumem o que fiz e o que me ajudou, mas depende muito de onde exatamente estão seus problemas.
Além disso, eu tenho que concordar com @AK_, que disse que você realmente não precisa de comentários em C #. Isso pode não estar 100% correto (acho que há áreas em que os comentários definitivamente ajudam, por exemplo, código pesado para reflexão), mas, em essência, é. Se você escrever realmente 'código limpo' com métodos e variáveis bem nomeados e tiver muitas 'pequenas partes' de código, elas serão quase totalmente desnecessárias. Toda vez que senti a necessidade de comentários ao ler código até agora, depois de entender o que fazia, fiquei muito infeliz com a maneira como foi feito e pensei que poderia ter sido muito mais claro em primeiro lugar por uma boa refatoração.
Edit: Eu estou falando especificamente sobre comentários C # aqui, não documentação (seja documentação separada ou comentários XML), pois acho que a documentação é sempre importante.
Identifique quais são exatamente os seus problemas e se você pode categorizá-los. Ou seja, você ainda tem problemas com o próprio idioma ou não entende uma sintaxe específica (por exemplo, expressões lambda e LINQ em geral, ou Reflexão)? Se você não entender as linhas de código, não entenderá o que todo o método / bloco faz; portanto, comentar você mesmo será difícil. Em vez disso, pegue um bom livro ('C # em poucas palavras' era para mim, mas ouvi dizer que 'C # em profundidade' também é espetacular) e leia as coisas que encontrar. A categorização antecipada desses problemas facilita isso, pois você pode preencher 'lacunas maiores' de uma só vez ou até perguntar ao seu chefe sobre isso, pois não são mais muitas perguntas, mas sim explicar um único assunto ou as construções mais usadas para que você pode obter um enorme 'impulso'
Paralelamente ao exposto, tentei me familiarizar com a 'codificação limpa' e as melhores práticas gerais (não específicas do idioma). O efeito disso pode não ser imediato, mas será recompensado mais cedo ou mais tarde, quando você precisar estender o material existente ou se perguntar por que alguém criou tantos métodos pequenos em vez de um onde tudo está contido ;-)
Conheça os padrões de design comuns. Eles podem estar aparecendo aqui e ali no código que você está lendo, e se você os reconhecer, isso imediatamente lhe dará um momento do a-ha. Mesmo que você entenda o que o código que você vê lá faz, você pode se perguntar por que isso é feito dessa maneira, e descobrir isso sozinho geralmente não é tão fácil.
Por favor, não tome o texto acima, enquanto eu faço suposições sobre sua 'habilidade', muitas vezes alterno acidentalmente entre falar sobre minhas experiências e falar 'com você'. É principalmente o que encontrei e o que fiz . Como já foi dito, essa pode ser uma experiência muito boa e é praticamente o padrão no trabalho ler código que não é seu e que você não conhece muito antes. Mas pode ser realmente gratificante finalmente entender o que está acontecendo lá e reconhecer-se melhorando com essa 'habilidade' específica. Aproveite isso como uma oportunidade para aprender muito em muito pouco tempo, boa sorte! :)