Back in the Consulting Game

I put in my 2 weeks notice 3 weeks ago at Multicast Media Technologies, a Live and On Demand Online Video company here in Atlanta. I was originally hired as a Flex Consultant back in March of 2007. I had taken a 3 month sabbatical to find a product company that jived with my goals, but mostly to play XBox for 2 1/2 months. After that, my wife and I jetted to Sydney, Australia so we could both speak at WebDU 2007 (she got the bigger room). I was pretty re-charged to do some Flex work that March. I even got the opportunity to don the khakis and do some on-site client consulting in California. About 5 months into it, they offered me a W2 position, and I accepted. I still kept the flip-flops.

My main goal going in was to obtain experience doing product work. I really got extremely irritated at some purist programmers making comments on my blog against my pragmatic views saying that I didn’t have enough experience maintaining code for long periods of time. While untrue, I wanted even more experience doing so in the product sphere where coding for the long term actually matters. Thankfully, all it did was re-affirm my beliefs (I’m still right, suckaz!).

Naturally, I learned a lot more too. A list in no particular order:

• No matter how good of a coder you are, you’ll fail if your goals do not align with the business goals.
• XML is more bloated than I thought it was. JSON & AMF 4 t3h w1n!
• PHP is still bad ass. He might not be hip like Python or Ruby, but he still can own.
  
• Our job as a GUI client developers is SO easy compared to server-side developers.
• Making money is more important than saving money if you can make more than you can save.
• One of the best things for a growing company is a bad ass Product Manager.
• Documentation targeted for marketing and sales is different than developer documentation.
• I still suck.

When coding initiatives on your own time for a company, be sure to get feedback from stakeholders other than developers. It’ll ensure what you are doing is valid… or invalid. That last part ensures a lot of developers will never ask, hehe. For people like me who need approval, it’s important.

There are plenty of ways to do client server communications nowadays, and plenty of format choices to do so. These include XML, JSON, REST, and AMF to name the main 4. XML was touted in the late 90’s to be the hotness because it was text, human readable, and easily parsed. While those statements are true, and yes, E4X is nice, there are better things out there now, like JSON and AMF. While easier for the client developer, they might not be easier for the middle-tier developer to implement. At the end of the day, though, it doesn’t matter; whatever is best for the user is best. XML is NOT it. It’s too bloated… at least for video players.

Most of my time was spent working with Vidego, a web based live and on demand video content management system. It also has a server & client API to allow agencies to create Flash video players, and developers to create applications that utilize it in Flex. What blew me away about this company was it was the FIRST time in 5 years where I would hit a back-end API in Flash… and it actually worked Day 1 whilst still in development. Furthermore, the speed at which bugs (if any) were fixed was insanely impressive. This pattern continued for over a year. That was the nail in the coffin for me. While the developers deserve the credit, it’s just more ammo that PHP is still the hotness. I’m sure if they used Python instead, it’d sing just as much, but it’s always nice to have validation that it doesn’t matter what platform you write code on, it just matters how good the developers are.

Since I spent over a year at Multicast, I saw the company and Vidego grow a lot. One thing that was really neat to watch was the IT portion. I didn’t get to see a lot of it, nor did I understand even 2% of it, but clearly, a lot of complicated processes were streamlined, and improved both in software and in hardware. While a lot of great individuals were involved, one thing that struck me is my perception is that there are a lot more variables involved in server-side work than client side. Like, if a client’s machine goes down… oh well, I don’t care. If a server goes down, however, the server-side guy and many others freak out. I have to work on millions on computers, but that’s not my problem, it’s Adobe’s. The server-side gals and guys have to have their stuff work on hundreds of computers, both local, dev, qa, NATs (not sure what those are), various connections to CDN’s… it’s crazy. So many moving parts. Most of my problems deal with people, communication, and getting on the same page. To me, that’s easier and tons less stressful.

Working at a product company, I constantly felt the need to “improve” things. I do this in consulting too, but here I had a vested interest and a lot more time. One thing I noticed is that things that made money were made priority, and things that lowered overhead costs were not. While saving $100,000k by spending 3 months might be neato, spending 8 days to make $300,000k is better. I might rather spend the 3 months because it’s cool and fun, but …tough. If your product doesn’t make money, you don’t get a paycheck. Lowering overhead costs when you can make more money by focusing on other endeavors that take less time is REALLY hard to resolve when you’re a programmer, especially with the counter argument of “If I spend more time now, I can spend less later”. It’s easier if you become part businessman. While easier to get the vision, you then get even more challenged on how to resolve the two perspectives since they aren’t mutually exclusive. Programmers want to spend years, even using Agile methodologies, to create the hotness. Businessman want to spend the least amount of time possible, yet still remain agile. How in the heck do you resolve that? If you know how, and execute, you create a successful software business.

When Carol Comstock was hired as the Product Manager, things changed for the better… a lot. The first thing I noticed was I stopped doing client management, and started coding more. The second thing I noticed was that things started to get organized and processes started to get implemented. There were a plethora of other good things that happened, but suffice it to say that it was one of the best hires Multicast Media ever made. I’ve always been more akin to hiring a good IA instead of a good manager / product manager, but my experience at Multicast changed that. I thrive in chaos, stress, and general insanity whether at a big company or small. Regardless, there are still parts about it that suck, and it was nice to have the opportunity to see the transition from before and after.

I’ll keep this one short: Just because you and all your developer friends know your code is awesome doesn’t mean anyone else does, nor does it mean those who are capable of selling it know why they should. Empowering them through good documentation & marketing material is the key. If you can’t write it, find or hire someone who can.

I only like working at places where people are better than me in some way. I wish to learn from those I work with. One of the reasons I accepted W2 is I knew I’d get the opportunity to work with and around people of that caliber. While discussions with my co-workers over the course of the year identified yet more things I either only partially know, or didn’t know at all… one dude in particular, Lou Parker, blew me away. Similar to that one awesome dude on 30onair.com, he had a track record of hotness. He’s one of those dudes that you go, “When I’m 90 years old, if I’ve only done just 10% of the stuff he’s done in his programming career, I can then die happy.” Must… work… harder…

So where too now? Back to Flex & Flash Consulting, what else. I’m trying to work on a product in my free time. …but first, the beach!