Some things that I learned early in my career that originally helped me succeed, I believe are now hurting me in job interviews. One of the pros to typing via dynamic languages and forgiving compilers such as ActionScript 1.0, Ruby, JavaScript, and others is that you can quickly code things that work. In a lot of the early agency, multimedia, and small software company work that I did, these technologies were great. They didn't get in your way, and they empowered you to quickly create programmatic solutions that were enhanced or even driven by good designers. You could hit insane deadlines, recompile changes quickly for a client, and react flexibly to ever-changing, almost fluid requirements...if any.

I believe those early successes helped me become very pragmatic, agile, and optimized. While to this day I still question a lot of what is considered "good programming" practices, I believe my pragmatism allowed me to judge which OOP, design patterns, and frameworks were appropriate, and how much of each were used based on a project's need. As my projects increased in scope, I learned to love strict-typing. Design patterns helped me organize my code enough to be able to quickly change the design for whatever reason and still have my code work. I learned to love frameworks such as ARP and Cairngorm as I started getting more development help on projects (I used to be the only developer).

Things have changed. With the release of Flex 2, 2006 opened the door for traditional programmers, both server-side and client-side, to now contribute and benefit from the SWF format. Now they can create RIAs, and really enjoy doing so. New blogs from talented developers you may not have known of, if you were strictly in the Flash development community, are popping up daily, all with great code and development techniques to contribute to the greater community. Some were sleepers, others are just now getting around to acquiring a blog because other traditional developers are doing it too, and some are just coming into the echo chamber that is the Flash/Flex development blogosphere. All bring with them their own style of development. More often than not, these are real developers who don't have the learned expectations of a lot of the early pioneers and frontiersmen, those first brave programmers like Branden Hall and Colin Moock. They are the ones who use test-driven development, Inversion of Control, and some even care about your CMM level. Some are all about the Flex component and FDS APIs, while others are swimming around the boilerplate, low-level Flash Player AS3 APIs, such as ByteArray and Socket, as if they were nothing foreign and new.

One thing is abundantly clear, though: these are programmers and they mean business - business in the sense that they have lingo, processes, and development setups that only used to trickle into the Flash development community. Granted, there is plenty of prior art to showcase all of these things in some shape, form, or fashion in our community, but never has it been on such a paradigm-changing scale as this.

Why Does This Matter?
For one thing, these guys 'n gals don't know the Flash Player; they just know they like what it can do. Most don't know, nor care to know, what an 8-bit alpha channel is and how it revolutionized what we can do with design on the Web. However, they know we do, and they want us on their teams because they need to focus on getting their J2EE back ends to work wonders with our Flex front ends. If you know Flash and/or have a minuscule amount of Flex experience with a design background, you are in high demand.

The common theme I keep seeing is that Flex is being used more and more in a lot of traditional enterprise development setups. This means having an actual quality assurance team, maybe even user testing, all with the assumption you'll use the tools and processes that traditional Java developers on large teams use. I feel a lot of Flash developers have spent their entire careers learning more and more about traditional software development to augment their ability to be more successful in their traditional multimedia and agency work. That is, of course, unless they truly have crossed over to full application development and are just waiting for Flash Player 9 to hit the magic 80% penetration mark before they make the dive to AS3 or even Flex.

Either way, I feel we've all had an open mind about learning new things, since our industry in particular has changed so fast. While I may be extremely suspicious of using test cases, or appear quite unconvinced about having Spring lend some of its concepts to the client, I'm actually very open. Again, while we've had a lot of great traditional developers contribute their learning to our industry to help move us forward, never have we had an entire industry merge like this and on such a scale. I'm still learning every day about how a myriad of development teams do their work based on their varied backgrounds (C, C++, Java) and what tools and processes they use to make better software.

It's just really hard to match the lessons they've learned with my own pragmatic ones. They don't complement each other at all. They come to a harsh clashing in the old consulting adage of "fast, cheap, and good... choose two." If you want me to develop a widget for a client in one week (which is definitely more than reasonable), I see little value in creating test cases and implementing ARP. I've been burned too many times not to use source control, but what if I had two months? Would those tools and those who corroborate their joy of being converted now be justified? I'm sure the traditional software developers are nodding their heads saying, "Obviously." Of course, if you asked them if they blindly accepted new frameworks and processes, I bet most wouldn't say "No"; they'd look at them logically, and want to see proof of ROI of their time invested before learning them.

But is there any return? Do I have anything to give? What about all the accelerated development talents, tricks, and skills I've learned over the years to hit impossible deadlines with design and code - how do I convey value to them that a traditional software developer would understand? Obviously the Ruby guys "get" the advantages of loosely typed languages, and the agency non-coders love when we have good attitudes to make their designs do awesome dynamic things. How do you translate that to AS3, when you are rewarded twice for strong-typing: speed and maintainability? I could choose not to strongly type, turn off compiler warnings, type far less code, and get things done a lot faster. But to what gain? We are no longer suffering the agency problem, under-bidding on both price and time, forcing designers and programmers to slave away for immense hours of time (well... some of us). Yes, clients in the enterprise sphere are as demanding as well, but we're talking months or years here, not days and weeks.

The software developers coming to Flex already have preset ways they develop; Flex is just a technology in their repertoire, while I think for a lot of us from a Flash background, it's a way of life. That way of life has drastically changed. I think it'll continue to change as swaths of more traditional software developers, both enterprise and small, get on board in such numbers as we've never seen before. For them, it's a nice, new opportunity to create more rich GUIs that are easier to deploy, easier to develop for, and more enjoyable for all involved. As for us old skoolerz? Our life is changing. What I'm having problems accepting is that it's "supposed" to fit into traditional development molds. It seems just obvious now that the computer scientists have their true IDE, command-line compiler, and strongly typed runtime. To me, it just seems one of the many ways to utilize the SWF platform, and, therefore, nothing is implied or inferred.

I feel like I have a lot to offer. I know how the Flash Player works. I know how to get a variety of designs to work. I know how to talk to any back end. I know how to get complementary technologies and tools to help make my development and design implementations efficient. I remove headaches from server-side developers, and they remove mine. I have client development experience that translates to both Web application and desktop development. I can get things done and, if need be, get them done quickly. The J2EE guys like this. What they don't understand is that us Flash and early Flex developers weren't around for the EJB wars, or all of the other battles fought over blogs, e-mail lists, and conferences about how Spring and Hibernate revolutionized server-side Java development and that industry as a whole. When we ask questions, it's because we didn't participate in that. We had our own battles dealing with the maturation of a fledgling language moving from a dynamic environment to a more traditional programming one. There were growing pains, yes, but they don't necessarily translate to process ones. This doesn't mean we have the proper context to appreciate what you all have to offer. Just something to keep in mind when you explain something that's wonderful in your work flow, and you're greeted with a blank stare. Something to think about. We're not dumb; we love new toys, and love this stuff as much as you do. An ActionScript developer's life is fraught with learning new things all the time. That's what makes it fun. It's just there are a lot more opinions and options now than five years ago.

I know that insane deadlines, hastily written ActionScript 1.0, and non-source controlled projects will still exist for some time. This could even be for me via the side contract jobs I take to supplement my full-time income. To me, those development decisions exist because you can thrive on them in such fast-paced environments. It's just been really hard to reconcile the lessons I learned from those areas into traditional software development, specifically in interview conversations. You can really sound like a buffoon to those people even if you've had a long history of proven successes and notes of merit. So far, I've had a few instances of tension with the bigger companies, and none with the startups. Basically, those who use more enterprise development technologies struggle to understand why I wouldn't want to use their uber-involved processes, whereas the startups and I really have a synergy in "getting things done." When I bring this up to the enterprise potential employers, they are definitely in agreement that they too like to get things done.

...but it's not the first thing, they say.

Anyway, just wanted to point out it's something that's been challenging for me to reconcile: past learned lessons on "how to survive as an engineer in a fast-paced environment" coupled with "how to develop maintainable, long-lived software." Different worlds, man, different worlds.