While this post is about programming, it also draws an extended analogy to dungeons and dragons, specifically two of its classes, that correspond to two attitudes toward programming.
In D&D, wizards study magic. They prepare their magic spells ahead of time. While they may learn a large number of magic spells, they need to prepare them ahead of time and can’t just cast them at will.
Wizard programmers prefer up-front design. They apply reason and logic to divide and conquer a large problem, they rely on building blocks like design patterns and algorithms. Wizards rely on explicit knowledge.
D&D sorcerers have an innate connection to the magic. They wield tremendous forces that they sometimes don’t quite understand, it’s wild and unpredictable. It’s not something they’ve learned to do, but something they’ve discovered in themselves, a talent.
Sorcerer programmers prefer bottom-up design. The process is creative and chaotic, it’s the molding of clay rather than arrangement of bricks. Development relies on building pieces of the software, not yet clear how they will fit together, meanwhile forming an ever deeper intuitive understanding of the problem. Their software is grown, not designed. Sorcerers rely on tacit knowledge.
In practice this is a spectrum. While most developers will probably lean more toward one side of the practice, many will utilize both methods to some extent.
There is notably some degree of misunderstanding between developers on the far ends of the spectrum.
Strong wizards consider sorcerers to be recklessly sloppy and undisciplined. They will often fail to appreciate the depth of the intuitive understanding of the sorcerer. They think sorcery looks like the undisciplined programming of a complete beginner, it is only through uncanny luck they ever get anything done at all, let alone on time.
Strong sorcerers in turn find wizards overbearing and bureaucratic. They don’t understand the wizard’s need for rules and documents. They feel it is as though the wizards never dare remove their training wheels. They find the wizards’ solutions bloated and clunky, and the entire development process unbearably slow and tedious.
In practice, both of these methods work, although they have their weak and strong points.
For well understood problem domains, wizards are far more reliable in crafting something that works, since the entire wizard’s process relies on translating explicit knowledge into a software design.
For poorly understood problem domains, sorcerers will often outperform wizards by a fairly significant margin through their ability to quickly build an intuitive understanding of any problem; the act of producing the code is the same as the act of understanding the problem.
Arguably, there’s an aspect of personality and talent as well. A strong sorcerer may never be more than a mediocre wizard, no matter how hard they try to apply the same tools; and the opposite may be even more true.
That said, there is probably something to be gained for those on the extreme ends on the spectrum from attempting to at least understand how the other side works, to dabble a bit in the other method. Even though you may probably not be able to master both classes, a strong sorcerer with a modicum of the wizard’s discipline; or a strong wizard with just some of the sorcerer’s intuition is a force to be reckoned with indeed.