Every developer has a set of bias that drives their development. A developer’s bias determines how they write code and what they consider is good vs. bad code. I believe there are few if any "well rounded" developers that provide equal weighting on all areas; that’s why having a team of developers with different bias can be a good thing (or they can tear each other’s eye-balls out, depending on the mix!)
For many, absolute performance of every line of code seems to be an overriding factor. Lately, a lot of developers have (fortunately) become focused on testing. Others focus on user interfaces; some on making them beautiful and others on making them usable. Still others consider security of utmost importance. And there are many areas I don’t mention here or below (if your area of bias wasn’t mentioned, please tell me about it in the comments.)
My personal bias is strongly towards architecture. For me, an architecture that provides maintainability (small functionality updates mean small code changes) followed closely by elegance (consistent naming and orthogonal design) and enablement of "RAD-ability" (standard patterns contained in a framework.) I have further bias towards resiliency (adaptability to change), robustness (graceful handling of unexpected conditions), correctness (ensuring correct logic and interaction), and minimized yet explicit coupling (subsystems communicate in few, well-defined ways.)
When I say I have biases towards the above aspects of architecture, I mean when a tradeoff must occur, I will choose architecture over, say, performance. That doesn’t mean I don’t want performance, but I won’t sacrifice architecture unless absolutely necessary. And I am pretty sure I’ve had these biases since I first started coding. Over the years I’ve learned that several of the aspects I mention are opposing forces, such as RAD-ability and resiliency. So I’m always trying to balance goals.
Why do I blog about this? First, as a background piece for future blogs I plan to write. Second to state that development goals are often at odds with one another, though that should be obvious to any developer.
And third, to point out that most disagreements about which language to choose or how to implement something are driven by developer bias. Without knowing a developer’s bias is it is hard to appreciate their arguments and come to a resolution. But more importantly, I believe every developer should contemplate their own biases because doing so will help them become a better developer overall.