Not a proper paradigm, but I will say test-driven-development. They didn't teach that to us at University, or I was not paying attention when they did. I had to

Not a proper paradigm, but I will say test-driven-development. They didn't teach that to us at University, or I was not paying attention when they did. I had to learn it afterwards. I struggled with it for months. Only started seeing the benefits way after. An exercise on delayed gratification. I think its main difficulty is that it requires "learned intuition" - knowing which tests to write first, and which ones to build afterwards. It's a bit like solving integral equations - apply the "right" transformation and you get to the result in a few steps, fail to see the pattern and you'll have a hard time. Perhaps I didn't find the right resource. I won't say that I use it every day, but it is certainly at the top of my toolbox.