Тема, наверное, не совсем относящаяся к начинающим разработчикам, скорее к начинающим управленцам. Однако, есть мнение, что управление проектами разработки программного обеспечения получается лучше все-таки у тех, кто прочувствовал нюансы разработки что называется на собственной шкуре. Не все согласны с таким мнением. Многие не без оснований считают, что управление командами разработки это всё-таки несколько другая наука, больше связанная с социальной и экономической, чем с инженерной. С другой стороны, кибернетика - наука об управлении - сама по себе является достаточно точной математической дисциплиной, нежели чем гуманитарной. Так или иначе, от того, что организацией программистов занимается человек с программистским прошлым...
О правильной мотивации программистов, расчете их материального и эмоционального вознаграждения высказано неимоверное количество мнений. По большей части они сводятся к размышлениям о том, как правильно и наиболее объективно можно измерить производительность труда программиста. Так или иначе они связаны со оценкой производительности отдельного программиста, и с тем как это сложно бывает сделать. К этому я уже ранее, неким образом подбирался. Есть лидирующие точки зрения, есть разные варианты под разные ситуации. Прогрессивные и консервативные, регуляторные и рыночные. Я не собираюсь оспаривать какие-либо из них или топить, скажем, за эджайл с канбаном. Я позволю себе высказать личное мнение, по поводу того, как не следовало поступать...
Программистская терминология характеризуется одновременно своей специфичностью, когда термин обозначает весьма конкретный феномен, когда для каждого конкретного термина существует свое определение, и, вместе с этим, отсутствием отдельных собственных слов для этого. Программисты берут слово из какой-то совершенно общей области знаний и сопоставляют его с каким-то своим понятием. Файл, сокет, семафор, баг, фича, шаблон, проект, дизайн... Так и в случае с программной "архитектурой" - это не совсем, а скорее совсем не то, что под этим понимает строитель или любой другой непосвященный обыватель. Собственно общего между обыкновенной архитектурой и архитектурой программной одно - это некий уровень или стадия процесса создания. Архитектура это...
Persistence - один из айтишных терминов, который не переводится прямо на русский. Во всяком случае не одним словом. Сохраняемость? Персистентность - способность системы сохранять собственное состояние после остановки процесса. Вообще феномен присущ не только для информационных систем. Способность тритонов и прочих примитивных гадов "оживать" после полной заморозки, например - сходное явление. Другое дело, что нам пока не до конца известно, какая часть, если так можно выразиться, сознания, восстанавливается весной, после того как лягушка оттает и её сердце возобновит прокачку глюкозы к мозгу. Ей может быть не так много и надо.
Постулат о том, что нельзя научиться программировать без практики нынче можно слышать из каждого утюга. Звучит этот догмат каждый раз немного по разному, но суть всегда одна - теория без практики - время на ветер. Что ж, cложно с этим не согласиться, тем более имея на руках очевидные результаты. Те кто совмещал теорию с практикой действительно легче и лучше усваивают материал и этому есть совершенно не программистское объяснение. Человек вообще так устроен. Да и вообще все животные обладающие высшей деятельностью центральной нервной системы приобретают опыт так или иначе через практику. Так устроен мозг.
"Чукча не читатель, Чукча — писатель." - однозначно можно высказать и в мой адрес. Я отношусь к людям скорее не любящим читать. Ну или, по крайней мере, не считающим чтение каким-то отдельным важным занятием. С другой стороны, часто вынужденно, все-таки прочитал я всего, наверное, не намного меньше среднего обывателя, особенно технической литературы.