How to Survive Becoming a Flex Developer

In the movie Rustlers’ Rhapsody, Tom Berenger’s character tells the locals in the town he’s come to, that all saloon towns are the same: each town, he tells them, has a town-drunk, each town has a town-prostitute, and each saloon town has a black-hat cowboy (and the black-hat cowboy can’t win in a gunfight because he’s a bad guy). How does the nomadic white-hat cowboy know all this? Because he goes from town-to-town and he’s seen the same scenario play out over and over again.

The State of Flex Developers

As a Nomadic Software developer who has worked on the Flash Platform for the past ten years, let me tell you something: most software companies are pretty-much the same, from town to town. At each company, you’ll see some of the following types of Flex Developers:

• There’s one Flex developer who does 80% of the work, and then spends the rest of his time getting caught up on the latest technology (which requires the rest of his conscious time).
• There are a few developers who were hot when AS1 was the rage and they’re almost ready to move to AS2. But in the meantime..
• There are the Flex developers who somehow got moved from Java Development to working on the client-side (and they didn’t consider this change to be promotion).
• There are the Flex developers eager to learn something new, but they have no idea how to go about it.

In short, I see people who are burnt-out, not-interested, not-interested and unhappy, or interested and frustrated.

Things Have Gone Wrong

There are always a lot of jobs opening up in Development, and I rarely see developers much older than I am (I’m only 33). Neither one is a good sign for career prospects, but what does that say about the Software that IS out there? How experienced are the people who are building the software that impacts our lives when they all seem to be so young, and worse, young and (see categories above)? Well, I’m glad you’ve asked!

To all of the developers out there who wake up and think, “I will never learn how to do this. I will never learn all the stuff I need to learn to become really good at Flex Development and have a life”, put down your whiskey-glass and pay attention.

The Software Industry is a cut-throat business

Most saloon towns (and yes, I am going to stick with the Wild-West metaphors for the rest of this post) only have enough room for a few cowboys, and there’s another one riding-in with a fancier gun and a faster horse.

If you lose your job working in one of the smaller towns, you’re either going to have to relocate, market yourself so aggressively you can work remotely from home, or look for a new line of work. In a big city with a focus on technology (like Raleigh-Durham or New York City), the competition for software jobs can be fierce. Software is one of the highest paying fields that doesn’t require an advanced college degree, and that is a major draw for a lot of people who have the basics down, and are willing to go to any length to have the salary of a medical doctor in less time than it takes to finish medical school.

Software is a new business and it changes fast.
The processes for building a physical structure, like a town-hall, have been around for 1000s of years. The processes for building software have been around for 40 years, and web-programming only took-off around 1996. For the past few years, people have been coming out with proposals for processes that are then tried, proven and refined, or tried, proven false, and tossed out. We’re STILL figuring out what works and what doesn’t work, and software development is still in its infancy. You should expect things to change rapidly over the next few decades. Roll with the changes. You need to know how technology changes. You need to learn what to follow and what not to follow. You need to know how to stay ahead of the curve. You need to do it in a way that is efficient so you can have a job and have a life. If you don’t keep up, you’re going to walk into the street one day at high-noon for a show-down and find out that the other cowboy standing at the end of the road has a bullet-proof vest beneath that duster.

You Won’t Learn Much At Work

Companies aren’t going to pay to train you. It’s not in their best-interest to ‘hope’ their financial investment in your education is going to pay dividends in profit for their next fiscal quarter. Unless you possess some special product knowledge, it’s cheaper to replace you with someone who already knows how to solve a complex coding problem, because that person is going to come up with elegant solutions that won’t just save time coding, but will make it easier for Mary and John in Quality Assurance to test other areas of the product, and it means Susan and Phil in Marketing can start selling the product sooner and it means Jenny in User Experience is going to have plenty of time to fine-tune the interface. And besides, even if your company DID train you, what’s going to prevent you from leaving once your skills have grown? Now that you’re more marketable with a higher earning potential, it’s time to open on Monster.com and begin anew!

Software Developers Have a LifeCycle, too
Software Developers are only valuable if the skill they’re bringing to the table is in demand. The Flex SDKs evolve every few months. A new Flex IDE comes out  every 2-3 years. And the tools and approaches begin a Sea Change about once each year. With such an enormous learning curve, it doesn’t take much to fall behind.

How soon can you become irrelevant?

• You can become irrelevant in 2 years at a small company.
• You can become irrelevant in 4 years at a Fortune 500 company.

How Can You Mitigate the Dreaded Fall-Behind?

Propose a Radical Change (or just do it)
I’ve been to a lot of meetings with people that have lots of industry experience. I’ve sat around tables with managers who have MBAs, developers who have advanced degrees in Computer Science, and the kind of documentation that makes you believe the enterprise-application we’re about to launch has been carefully thought-out. Then, after a few weeks (or a couple months if I’m new to a company, their people, culture and processes), it becomes clear that the people are well-intentioned, but they are missing major pieces in their development process (and they all know it, too).

I may walk into a company and say, “You have no automated build process. You spend 2 days each week doing the same thing. You have developers with different environments, so they spend a solid day each week trying to figure out why an issue in QA can’t be replicated on Bart’s workstation, but it can be replicated on Wyatt’s workstation with ease.”

Then, I ask, “Why not add an Automated Build Process?”

The answer is always the same: “We don’t have enough time.”

The answer is going to be the same whether we’re talking about refactoring a code-base to design patterns, adding a version-control system, implementing a framework, or adding an automated build process.

By default, your boss is going to tell you “No.”

The Unspoken Truth about Your New Enterprise Approach

Enterprise practices will probably absolutely save you time on your next big project (and all projects grow in complexity and become ‘big’, anyways). Enterprise practices help to ensure projects get completed. Enterprise practices keep morale high and prevent resources people from quitting in the middle of the morning Scrum resigning at the end of the project. Enterprise practices reduce tension and friction between team-members. Enterprise practices will help to ensure you go home by 8pm, 7pm,6pm, 5pm (going home at a reasonable hour ensures mothers and fathers see their kids and the enterprise practices ensure loved ones see their significant others. Going home at a reasonable hour means you’ll probably workout and eat a healthy dinner and watch a movie).

It’s NOT cool to talk about these ‘desires’ at the next Business Requirements meeting. IT IS COOL to talk about how amazing the project is going to be when it’s done and how valuable you’ll all be!

Steps If you’re In the beginning of a project:

1. Find a process that is popular and would apply to your project.
2. Implement 1 new enterprise practice into your project (and act like it was totally expected if anyone asks). From this,
   • You will benefit
   • Your company will benefit
   • Your team will benefit
3. Immerse yourself in the new practice over the next two weeks, and then tinker with it for an hour or two a day.

Steps If You’re In the Middle of a Project:

1. Find a process that is popular and would apply to your project.
2. Memorize the buzzwords.
3. Understand intimately how the process applies to your project.
4. Understand intimately why the process was never implemented or suggested. You may end up attacking someone’s competency or your own, so be prepared to vigorously defend your newly-held beliefs.
5. Propose a new approach. Tell your boss that your company MUST implement a _______.
6. Prepare for the rebuttal of, “We don’t have enough time to implement _______”. Explain why implementing the process will save you time, money, and a loss in morale.”
7. Repeat the proposal as a Mantra.
   1. If the company elects not to use your approach, show them as the project moves forward that you could have saved time (and money) by using your idea with specific examples in the moment. I often use, “I guess we could have been out having beers instead of doing this again [bonus points for a dead-pan delivery].” Don’t let your proposal be forgotten.

Choose the right company and learn on the job
The processes a small company adopts are centered around a development approach that produces a more robust product in less time, with fewer developers, even if that means rapidly learning something new. You could be working on Flex one day, and Silverlight the next. You could be working on JavaFX and then back on Flex. The small companies are not bound to the same constraints as a huge company. Small companies have flexibility and choice. You can walk into a small company and propose a development approach you’re interested in learning, and your boss may let you run with it. And by “propose”, I’m talking about going out to Starbucks with your boss and proposing the adoption of LiveCycle or agreeing to migrate to a new SDK while he’s adding extra ice to his Venti Iced-Coffee.

At a small company, you’re going to need to learn new platforms on the job, which often means you have to request to be moved to projects that offer you the opportunity to learn new things. Show initiative and be very honest if you feel like you’re not being put on a project that will make you more marketable (if you think there are other options).

A Fortune 500 company is slow-moving, and it’s usually one major platform (or 2) behind in each release cycle. The Fortune 500 company has a major perk if you’re a Self-Starter: if the code you’re working on has reached a milestone earlier than expected, you’ll have time to download and experiment with the latest languages, methodologies, and application servers on the company dime while you wait for the others to catch-up (and remember, your goal is to look busy so you don’t make your boss look like he’s not managing. He knows what you’re doing. Just don’t bring your start-up to the office).

In Old-West Speak: There’s a big difference between Tombstone, Arizona and Tucson, Arizona. Choose the town that gives you the best opportunity to learn new things.

Learn how to be resourceful
In 2003, the project I was working on was winding down. I had finished the programming and I was bored out of my mind. I was still an entry-level programmer and I wasn’t learning anything new. So I joined UltraShock, a Flash forum. I would go through the posts with questions I didn’t know the answer to, and I would search out the answer, write the code, test the code, and the post the solution.

I received lots of emails and posts thanking me for helping someone solve a problem, but I was really helping to advance my own skill-set. I also taught myself something very valuable: I am fully capable of finding a solution to ANY programming problem. I learned the true skill-sets of my peers (what they were good at solving even if they didn’t enjoy solving the problem), how to search through live-docs, and I learned the power of networks (someone always seemed to know someone who had special knowledge of a topic).

In Old-West Speak: Prove to yourself that you can setup camp between any two saloon-towns and survive based on your resourcefulness. Can’t find the instructions for setting up your tent? Can’t read the instructions for setting up your tent? You need to prove to yourself that you can find someone in the next town who can teach you.

Work with someone smarter than you
In 2004, I took a job in Jacksonville, Florida. After having worked a contract in San Diego and having enjoyed the weird, transient lifestyle that is Reno, Nevada, I wasn’t exactly keen on moving to Jacksonville. My girlfriend at the time was interested in moving back to her hometown, and my boss was pretty honest that the product we launched wasn’t selling and I was a drain on payroll.

I was assigned to work in R&D as  a Flex Developer. My team-lead was exceptionally bright, and he taught me Object-Oriented Programming, Object Relational Mapping, and Frameworks. He moved me away from the world of procedural programming that I had found to be comfortably familiar, and helped me to transition into real software development. He helped me over a hurdle that was difficult to learn on my own by mentoring me.

Just remember, if you’re an entry-level developer, that’s okay. I’ve always been amazed how perceptive managers are when it comes to understanding the competency of their employees (even when they pretend to be incompetent). If you don’t know how something works, open up and be honest about your confusion. Whatever you do, don’t pretend to know something. In Software, you get a gauge on someone’s competency pretty quickly.

In Old-West Speak: Find the first School-house you can, and listen carefully to the school-teacher. Sit closer if it helps, and don’t worry about what the other kids say about you being the teacher’s pet (you probably won’t be working with them in a few years anyhow).

Learn from Blogs, but Filter out the Noise
Most blog aggregators feed off the blogs of thousands of developers. Most of the bloggers don’t contribute much to your learning. Follow the handful of developers who are going to give you a glimpse of their experiences with the latest in Flex Development. Don’t waste time reading the blogs of people who aren’t going to offer valuable insight. You can learn a lot from a small group of people, like Jesse Warden, Brian Riley, and Steven Sacks.

If you’re not eagerly looking forward to the next post a blogger writes, you shouldn’t be reading the blog. If you’re thinking about buying the blogger a Christmas present because he or she has taught you something that has enriched your professional career, you’re on the right blog.

In Old-West Speak: A lot is said down at the Saloon. Strangers like to talk and share stories. Ignore almost everything you hear in that saloon, unless it comes from the mayor or the sheriff.

Build a Small-Scale, Enterprise-Application
One of the beautiful and terrifying parts about technology is how massive milestones have reduced job-security. When I was starting out as a programmer in 2000, the DBAs were the highest paid positions with the most job security. By the time Hibernate evolved and became common-place, DBAs were no longer the foundation of all projects. With Adobe LiveCycle Dataservices and the Fiber Modeling Plug-in, most of the work that was done on the client by a Flex Developer has become the ‘domain’ of the Java Developer. Much of the work that the DBA used to do will now be done starting in the Model that drives the DB creation. Much of the work the Java developer used to do is now done based on services the Model generates. It’s awe-inspiring to see how much quality code Fiber can generate, but Flex Developers will soon need to know more about Model-Driven Development (Including Hibernate and Java) if they’re going to stay relevant.

It’s important to build a product you’re passionate about. It doesn’t need to be enormous, and it can be a product that does very little, but it needs to utilize an entire enterprise-stack. By building and evolving this project, you’re going to learn languages, platforms and application servers you never knew about, and you’re also going to learn how those things work together.

• Learn a tool that makes life easier. Try Cairngorm 3 Validation
• Learn a mainstream framework. Try Parsley
• Improve the quality of your code using a Code Quality tool. Try FlexPMD
• Learn a unit-testing framework. Try FlexUnit 4
• Make all of the above work with an automated build-process. Try Ant
• Learn some Java. The support for Java and Flex integration is excellent, the language and the OOP concepts are similar to Actionscript, and the tools for Enterprise development are robust. Try a Java Tutorial.

In Old-West Speak: Build your own Saloon Town that can stand the test of time, even if each building is the size of an outhouse.

Look Into the Future of Trends (and position yourself accordingly)

Frameworks

In 2004, Caringorm was the standard framework for Flex development. It was also the only choice. Last year, most of the contracts I was working on used PureMVC, and two of the client courtships required PureMVC experience. By the end of 2009, most of the contracts I was courting were using or moving towards Mate or Parsley. Now, RobotLegs is gaining some momentum and Cairngorm libs are being coupled with Parsley as the framework of choice.

You can’t learn every framework. Worse, when you’re out there interviewing for that next great Flex job, you may find that the team interviewing you is dead-set on finding someone who knows the framework they’re using. Don’t feel like you’re incompetent because you’re not familiar with every Flex framework.

A framework is an Architectural Design Pattern, and all Architectural Design Patterns look to solve the same problem: An architectural pattern expresses a fundamental structural organization schema for a software system, which consists of subsystems, their responsibilities and interrelations.

Rather than jump on the framework-of-the-week bandwagon, look at where the time, energy and money is being spent by examining the Trunk of Adobe’s Open-Source Project. Don’t worry about learning every framework, but always be familiar with the direction of large teams who shape and mold the future of technologies.

Don’t worry about the next Flash-Killer
You’re going to see a danger to your livelihood quite often. You’ll see competing skills required in “Wanted:Flex-Developer” job postings. You’ll think you’re falling behind or you’ll think the world hates Flash. Focus on what you enjoy and if you ever need to make a switch, you should see the writing on the wall about 2-4 years ahead of time, and when you do know, rest-assured there will always be jobs to tide you over until you learn something new.

Automate quality on Friday. AKA: Friday is for Refactoring
Projects grow in their complexity very quickly and the best way to know you’re moving a project forward is to know you’re contributing to the growth of the code-base, not duplicating it or obfuscating the code.

You’re going to meet developers who are going to tell you that you’d be just as good as them, if only you worked harder to “just get it done.” You’re going to see developers who show you how to do something in ColdFusion, JavaScript, and PHP that can be done in just 10 lines of code[!]. Developers are going to tell you that with Actionscript and Java, you’re going to be writing 100 lines of code for every 10 they would write in another language. Remember that a Robust product is never measured in the sheer number of lines of code. The ability to output a variable in fewer lines of code doesn’t reflect the integrity of the code when there are new conditions applied.

I’ve had clients who wanted to measure my productivity by the number of lines of code I’d written. Yet, I’ve helped Fortune 30 companies to move a stalled product from stagnation into production by refactoring a project to a fraction of the size it once was.

You should obsess over the idea of writing code that is reusable. Tools like FlexPMD and FlexCPD can help to ensure you’re writing quality code. Books like Martin Fowler’s Ractoring will help you to write better code.

Set-aside every Friday to refactor the code you’ve written all week using the latest tools and proven methodologies. Write less code.

RPCs

In 2004, ColdFusion with Flash Remoting was still the standard in two companies where I was working. Both companies have since moved to Java with a Flex Client. By 2007, WebServices was the norm with Java. By 2009, most of the companies were using Java with BlazeDS. Next year, I suspect most of the projects are going to be incorporating Adobe’s beautiful LiveCycle Data Services with the Fiber plug-in for Model Driven Development.

Learn RemoteObjects

Don’t worry about learning every single RPC as a Flash or Flex Developer. I’m going to take it one step-further and encourage you to skip-over WebServices altogether. Don’t bother with JSON, XML, or HTTP.

Most of the companies I’ve worked for have used one or all of the above to get their software up and running. Those same companies are working on Legacy platforms. When you work with real entities through BlazeDS/LCDS/AMF/GraniteDS, you have the opportunity to work with real-objects that have a direct correlation to identical (or slightly transformed) objects on the client.

Model-Driven Development with Flash Builder 4 and LCDS represents something more than a simple-code-generator. MDD with Fiber and LCDS gives small companies and enterprise organizations a starting point to eliminate hundreds of tasks developers used to implement manually.

Programming is a Living. Programming is not Living.
Six years ago, I was driving in my truck with a good friend. It was late in the evening and we had just finished unloading some boxes of furniture I had given him as I prepared to move to Atlanta. I brought up work, and my friend asked, “Why is it that whenever software developers get together, we always talk about work? I miss talking about R/C airplanes.”

My friend had a valid point: Software Development requires so much time and energy, that it’s hard to leave work at the office. Some of the problems are so complicated and so multidimensional, it’s hard not to leave the cubicle and ponder the possible solutions. Now, looking back at the past 10 years, I can honestly tell you that I haven’t solved many problems thinking about them after-hours.

Worse, I haven’t really had any conversations evolve after I answered the notorious question of, “So what do you do for a living?”

People have a frame of reference for “Software Developers”. And the second someone hears you’re a “Programmer”, they have visions of you sitting in your mother’s attic for three years without any friends, trying to reassemble the Atari you disassembled, just to prove to yourself you could put it back together again.

If you hang-out with coworkers after work, you’ll tire of your job much more quickly. Social-skills come from regular interaction, and experimentation. These same social skills are important at work, and they’re important to having a real-life. You are not your job, even if you’re at the office more than you are at the house. Each time I have an ad-agency as a client, I’m reminded how charismatic the designers and marketing people tend to be. Each time I have a software consultancy as a client, I’m amazed how introverted developers tend to be, with no inflection, a rapid speech rate, slumped shoulders, and poor eye-contact. Their body-language and speech patterns often reflect their self-confidence.

Don’t let software become your life. If you become a Flex Developer and Stay a Flex Developer, come up with a plan to keep learning, while you explore other interests and find new friends. Get on meetup.com and find something else to do, but do things to remind yourself that writing solutions to solve complex problems can be a great way to make a living. But it’s not living.