Over-engineering syndrome and becoming results-oriented
In January, I reflected on year 2009 as it pertained to my programming career. What had I accomplished?
I thought long and hard about this. I didn’t publish any kick-ass new websites. I didn’t make any major contributions to an open source project. The crowning achievement of my year was a Facebook app that accidentally exploded in popularity when it was really just meant to be a “Hello World!” app to learn the Facebook API.
But this made no sense — I spent more time than I ever had in code over the past 365 days.
Somewhere along the way I lost sight of the goals. I did not become a programmer because I was amused with math, engineering, or manipulating computers. I became a programmer to create things that have a real impact on the world in some way, even if only slightly. When I first started programming, my code was hideous, insecure, and unmaintainable. But they worked. They had an input, and more importantly, they had an output. And that output did something useful. Why did the culmination of my last year of work have so little output?
The past year has been a great learning experience in other ways, of course. I learned Zend Framework inside and out. I built my own true MVC stack from scratch for learning purposes. I spent tons of time understanding different domain model implementations and formal ORM libraries. And now it’s time to put that knowledge to use. I’m switching gears back to being a results-oriented developer.
This made me realize why developer managers push deadlines so hard. Ship your code. Perfect code is not perfect unless it’s shipped.
Understanding design trade-offs and cutting features is a skill, not an option.
