[lallysingh]

I disagree.

You shouldn't learn to write maintainable software by rote. You just mechanically learn what to type, and how to type it, without ever learning why. Which is important. Knowing why certain constructs are hard to understand prevent you from doing the same spaghetti in perfectly-sanctioned style. Knowing how people read unfamiliar code is important, and teaches you which parts of the style-guide-mandated documentation are best kept short (for someone scanning your file to see what-does-what) and which parts long (to describe the edge cases).

Honestly, the best way I've found to write software is to start with a complete proof-of-concept mess. That way there's minimal friction during the get-it-right phase. Then I factor out the actual 'hard work' code from there into a reusable component, and turn the rest into the start of my test harness.