What to Unlearn?

Some things I’ve learned in my early career that originally helped me succeed I believe now are hurting me in job interviews. One of the pro’s to typing via dynamic languages and forgiving compilers such as ActionScript 1, Ruby, JavaScript and others is that you can code things that work very quickly. 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 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 I to this day still question a lot of what is considered “good programming” practices, I believe my pragmatism allowed me to judge what OOP, design patterns, and frameworks were appropriate, and how much of each were used based on a projects need. As my projects increased in scope, I learned to love strict-typing. Design patterns helped 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 & 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 an client side, to now contribute and benefit from the SWF format. Now they can create RIA’s, and really enjoy doing so. New blogs from talented developers you may not of known in the if you were strictly in the Flash Dev community are popping up daily, all with great code & development techniques to contribute to the greater community. Some were sleepers, others are just now getting around to getting 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 style of development. More often than not, these are real developers that don’t have the learned expectations of a lot of the early pioneers and frontiersmen that were those early brave programmers like Branden Hall, Colin Moock, etc.. 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 & FDS API’s where others are swimming around the boilerplate, low-level Flash Player AS3 API’s such as ByteArray & Socket as if they were nothing foreign and new.

One things 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 are 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, about what an 8 bit alpha channel is, and how it revolutionized what we can do with design on the web. …but 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 & 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 event Flex. Either way, I feel we’ve all had this 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 had we had an entire industry merge in like this, and on such scale. So, 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 really hard to match those 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 2”. If you want me to develop a widget for a client in 1 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 2 months… would those tools, and those who corroborate their joy of being converted be now justified? I’m sure the traditional software devs are nodding their heads saying, “Obviously”. Of course, if you asked them if they blindly accepted new frameworks and processes, I bet you most wouldn’t say “No”; they’d look at them logically, and want to see proof on 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 dev would understand? Obviously the Ruby guys “get” what the advantages of loosely typed languages, and the agency non-coders love when we have good attitudes to make their designs do awesome dyanmic things, but how do you translate that to AS3, when you are rewarded twice for strong-typing: speed & maintainability? I could not strongly type and 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 & time forcing designers & programmers to slave away at 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 & weeks.

I guess what I’m saying is, the software developers coming to Flex already have preset ways they develop; Flex is just a technology in their repertoire where I think for a lot of us from the Flash background, it’s a way of life. And that way of life has drastically changed. And I think it’ll continue to change as swaths of more and more traditional software devs, both enterprise and small, get on board in such numbers we’ve never seen before. For them, it’s a nice, new opportunity to create more rich GUI’s that are easier to deploy, easier to develop for, and more enjoyable for all involved. 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 CompSci’s 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 any back-end there is. I know how to get complementary technologies and tools to help make my development & 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 development 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 us Flash and early Flex devs weren’t around for the EJB wars, or all of the other battles fought over blogs, email lists, and conferences about how Spring & 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. Those are growing pains, yes, but they do not 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 developers’ life is fraught with learning new things all the time. That’s what makes it fun. It’s just there are wayyyyyy more opinions & options now than 5 years ago.

I know that insane deadlines, hastily written ActionScript 1, and non-source controlled projects will still exist for some time. This could even be for me via 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 & 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 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 said.

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.

8 Replies to “What to Unlearn?”

  1. Hi Jesse,
    I hear what you’re saying there, been in much the same predicament myself. It’s a question of growing/evolving in new directions. How much of what you know can you bring with you? One of the things I’ve been doing to try to reconcile concepts of oop, frameworks, strict typing etc with the demands of quick production times involves looking at my workflow, and investing time in creating code generators and automations. I’m trying to hit a point where I never write the same code twice – this may be ambitious, but I’m alreadying seeing big improvement just from attempting it.

  2. I identify with what your speaking of here a lot.

    For the past dozen years my curiosity has sent me into a lot of different programming niches. It’s more interesting than staying in one role, but every time it’s like entering a totally alien world.

    It is pretty amazing that, here we have a field that in daily process has to ballance tradeoffs that relate nanoseconds to gigabytes. And yet it’s still very easy for cultural biases to creep in based on job niche.

    Sometimes it’s based on technology (mainframe, standalone-cd, client-server, html, flash) and other times it’s based on the kind of applications that are being developed (data entry, training, productiivty, games, advertisements), but it’s amazing how many distinctly different mindsets, sets of priorities and types of businesses there are.

    I prize these kinds of culture shocks though. If our lives were novels, dealing with change would be a big theme and the occasional culture clashes are a real opportunity to find meaning. There seem to be fewer of them these days than there were in the 90’s. I think folk have gotten more used to change and biases are a little harder to come by. But the comunication between Flash and Java should be a particularly interesting one in the next few years, in particular along this rapid vs maintainable line.

  3. ‘New blogs from talented developers you may not of known in the if you were strictly in the Flash Dev community are popping up daily’

    Any you’d particular recommend?

  4. Def agree – different approaches are benefitial in different scenarios, but don’t unlearn anything, IMO.

    Flash is definitely changing, but the sky isn’t falling *yet*. I don’t think ALL Flash work will become Flex work in the near term; Enterprise apps definitely can benefit, but there are so many projects that are quickly attainable in Flash without having to rely on the Flex Framework.

    AS3 rocks and I will be using it, guaranteed, but with the evolution of Actionscript occuring, I think the hardest hit will be the long term designers who are used to being able to quickly mock up prototypes who now have to either write classes or utilize pre-built systems to do what they have always been able to do – especially those who have never had to write a class before. That capability has been key to the adoption of Flash by so many creative folks, and it is somewhat scary to see that key capability start to erode. That said, the best and brightest will continue to evolve and adapt (insert Darwin reference here). The danger I see is the requirement of such a degree of specialization from both design and development, that it becomes difficult for one person to do both. It may not be a huge part of the ecosystem, but it is an important one, IMO.

    On a lighter note, I still relish the fact that my Java friends are jealous of closures. Apparently now they are at least supported in theory under the new Java 7 proposal.

  5. Well, technically they can still work as normal. Flash 9 alpha will allow you to export to Flash Player 9 using AS1 or AS2. No one is forcing them to use AS3.

  6. Lots of talk about Flex2.0 but what we’re really talking about is AS3.0–we only use Flex to compile. When Flash9 Pro is released, Flex will fade quickly away.

  7. Hi Jesse,
    After rereading your post I’d like to encourage you to check out Spring in some detail – if you haven’t already. Or at least look at some of Rod Johnson’s books.
    One of the great things about inversion of control is that you can get rid of singletons and remove calls to service locators from your code. Your objects get simpler, easier to write, and more maintainable.
    Cheers and warm regards,

  8. I used Spring 3 years ago on a Flash app. From the server-side perspective, I thought it was pretty hot they could just embed XML tags and at compile time, it just replaced everything with what you had in the config. Rather than coding for encapsulation, your code generator injected the right data when your code was compiled. To me, that was pretty hot.

    Could we adapt this for Flex to remove ServiceLocator, and even a few Delegate calls? Sure, and I bet it’d be nice to have a large portion of that code code generated.

Comments are closed.