test13r

явление, когда берет деньги, и "разбирается", нормальное в случае постоянки: есть некая ставка, зависит от скиллов - накопленого опыта и общей сообразительности - и есть любые чаяния заказчика, которые прогер исполняет. Обычно больше ставка - исполняет быстрее - потому что скиллы. Там нормально, что он разбирается в рабочее время.

В случае же, когда дается ТЗ на фрилансе и прогер берется сделать за N часов, соглашаться, что 0.5 N ушло на изучение задачи нельзя. Однако для себя ставьте 1,5-2 N к срокам, озвучиваемым программистами и постоянно контролируйте.

Поддержка - обычно смесь 1 и 2 пунктов, некая плата за уверенность, что когда что-то нужно будет исправить, прогер не исчезнет. Она должна быть в пределах 0,25-0,5 стоимости вникания в задачу нового прогера

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

Но вот что я не могу понять, если человек берет по часовую оплату, но из половины и даже больше этих часов он разбирается сам, как это можно сделать, получается, что он не совсем хороший программист? Или это в принципе нормальное явление? И как тогда поступать считать меньшее количество часов ?

А если оперуполномоченный МУРа сидит и читает материалы дела - то засчитывать ему это как рабочее время или как прогул?
Или давайте ему засчитывать рабочим только "чистое" время: или когда он несётся в погоне вывалив язык, или когда в стрельбанине участвует...

За работу. Если грузчику платят за то, что он загружает фуры, почасовая оплата, то зачем ему платить когда он таскает мешки и возвращается за мешком на легке, ведь он не работает?
Код нельзя написать хорошо никогда. Можно стремится только к этому. Пока он разбирается это процесс разработки продукта. Почитайте книгу о циклах разработки ПО и все поймете

Методика разработки.

Waterfall: все тщательно планируем, назначаем сроки, разрабатываем, сдаем.

Agile: Примерно планируем, анализируем, назначаем конечный срок, планируем на текущую итерацию, разрабатываем, планируем на текущую итерацию, разрабатываем... , сдаем

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

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

Плюсы Agile:
Практически нет простоя ни у кого - все всегда могут занять себя задачами.
В случае появления новых требований, их можно без особого вреда ввести в проект почти на любой стадии. Главное чтобы технически это было возможно (в случае waterfall проблема именно на уровне утверждений и плана, то есть бюрократии)
Адекватное использование рабочей силы - если у кого-то нет текущих задач, его официально можно занять под другие проекты.

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

Можно начать с просмотра тех же видео от Яндекс КИТ (Курсы Информационных Технологий):
Безопасность Unix-подобных ОС
Криптография, шифрование
Обзорная лекция по безопасности
Сетевая безопасность
Информационная безопасность
Безопасность информационных систем
Информационная безопасность
Безопасность информационных систем
Из книжек можно прочитать Андрей Бирюков: Информационная безопасность: защит...
На том же Хабре можно пролистать раздел ИБ, чтобы понять, что можно выбрать
InfoSecurity
Из общего, думаю, уже можно будет понять, какими прикладными вещами заниматься.