2007 in review: Five humble suggestions for better programming and writing

Brian Dillard, Monday, December 31, 2007 @ 1:33 pm

I began 2007 as a front-end tech lead on a multi-million-dollar software project for a global travel company with a massively distributed waterfall development model. I ended it working in small, agile teams on R&D projects at a small outsourced software shop. I got involved in open source, became (yet another) tech blogger, and set in motion lots of other writing and speaking projects for 2008. It's been quite a year.

I'm sure everybody is sick of year-end lists at this point, so let me present a slightly more personal and highly subjective list of the five most important things I learned this year about software development and technology writing:

Front-end engineers should learn the M and C, not just the V.

This one should be a gigantic heap of "duh," but it's not. Front-end engineers often focus so squarely on the view in model-view-controller that they marginalize themselves and their entire discipline. When I was at Orbitz working on a dedicated front-end team, databases and business logic were so far removed from my day-to-day purview that I forgot a lot of what I'd learned building front-to-back ASP Classic applications a decade earlier. It's only now that I'm working on Rails projects that I've rediscovered the self-assurance that comes from understanding (and sometimes coding) the entire stack. UI-layer engineering has finally become a legitimate and respected discipline in its own right. Let's keep pushing forward by learning to speak - if not program - the languages used by our colleagues at other application layers.

Standards can only get you so far.

The rise of RIAs flies in the face of the standards-guru mantra that JavaScript should be abstracted into a progressively enhanced behavior layer. The dichotomy between web-as-media-platform and web-as-software-platform has never been more pronounced. Without web standards, we never would have gotten where we are today. But without forcing the web to do more than it was designed for, we'll never push things forward.

I don't want a future that relies solely on proprietary runtimes. Yet JavaScript, CSS and HTML move forward in fits and starts, generating tons of controversy at every step. The best hope for an Open Web is a future in which Opera, Safari and Firefox implement promising modules from draft standards and eventually drag IE along with them. It's smarter to make these modules de facto standards than to wait for them to become actual standards. SVG/Canvas, xmlHttpRequest and Microformats all point toward a future in which developers and browser vendors drag the WC3 and its ilk kicking and screaming into the light.

Tools make you lazy, so force yourself to work without them once in a while.

IDEs are huge productivity enhancers, but - like Ajax toolkits - you shouldn't become so dependent that you're helpless without them. When you're troubleshooting a production issue over dial-up from your grandmother's basement over Christmas with nothing but a remote command line to help you, you'd better not flake out. In the past year I've written code on a Mac, a PC and a Linux box in everything from HomeSite to Textmate, IntelliJ IDEA to vi. It's not fun to undergo constant cognitive shifts between operating systems, application interfaces and bundles of muscle memory. But it does keep you from getting stuck knowing only one way of doing things. Weightlifters who constantly rely on the same exercises at the gym eventually stop building muscle. Only when they switch it up - flies instead of presses, squats instead of lunges - do they make additional progress.

There's no way to learn everything, so don't try.

My biggest freakout of the year came when I stumbled out of Orbitz blinking in the bright glare of the Ajax blogsphere. Suddenly I had to get up to speed on a huge array of technologies and methods of working that I'd never employed before. The trap is to think that you can do it all. Learning Agile methodologies helped me realize that I should approach my skill portfolio the same way. Set goals for your inner autodidact the same way you'd prioritize stories in a sprint. Small, achievable learning goals will help you understand the basics of a broad range of technologies and decide which ones are worth additional, incremental investment.

Hot air doesn't matter if you don't do the work.

My other biggest challenge in living up to the job title of RIA Evangelist was coming up with topics to post about. As I learned the ropes at Pathfinder, I found that my best technology writing came out of direct technology experience. Reading about a library, framework or application is well and good, but playing with it proves far more productive. Otherwise, your posts just end up regurgitating ideas you've read about but not experienced yourself. (And commentators are quick to cry foul on you for talking out of anything but direct experience.)

Tomorrow, I'll post my 2008 programming resolutions. In the meantime, happy new year!

Technorati Tags

• front end
• JavaScript
• Ajax

agile ajax

Comments: 1 so far

• Leave a comment
• Comment feed for this post
• TrackBack URL

1. 

   I really like your analogy of learning and agile processes. I too spent a lot of 2007 attempting to learn far more than I possibly could, quite a bit on irrelevant topics. So this is certainly on my 2008 list.

   Comment by Martin, Monday, December 31, 2007 @ 3:55 pm

Leave a comment