Custom Search

Saturday, April 23, 2011

Keeping yourself marketable

A recent question on LinkedIn asked about the skill set to be working on if you're hoping to make yourself more marketable. This is something every professional programmer should be thinking about as long as they want to keep doing technical work. I've been thinking about this for a bit, and it ties into what I wanted to write about next in any case.

Before considering what skills you want to be working on, you have to start with what skills are going to be in demand - which means thinking about users are going to want from their computers in the future.

Enter the mobile internet

Unless you've been hiding under a rock for the last few years, you've run into some form of mobile device with internet access - smartphones, netbooks and tablets of various kinds. In particular, Apple (and I'm only an Apple fanboy when compared to Windows fanboys) changed the world with the iPhone. Full screen touchpad devices - with or without keyboards - are everywhere.  It changed the pocket computer (with or without a network connection) from something a small percentage of geeks carried to something almost a quarter of the people in the country have. And they're just getting started, with tablet prices dropping drastically since Apple introduced the iPad, and wireless broadband prices falling.

I've believed since the 90s that the mobile internet was going to be the real growth area for mobile devices. You might never be able to carry enough storage in your pocket to keep a database of, for example, every movie currently playing in the US, but even in the late 90s you could access that information from a cell phone or internet-connected personal digital assistant.

Lately, I've seen examples of what I think people are going want from applications in this environment. Users will want their data to be available no matter what device they're using.  As they move from adding notes on a tablet or laptop in a meeting to major editing on their desktop to a quick fact check on a cell phone while out at lunch, there's no reason to actually have to worry about making sure that everything is in sync - it should just happen. Save will no longer mean put this in local storage, but also imply and copy it to the server, and Open will mean check the server for updates. Variants include classic client/server relationships, where the user edits directly on the server, or saves and opens only go to the server - the user won't really care. In this environment, not only are the devices mobile, but the data is as well.

Technologies for mobile data

The development model for such applications is still being worked on. Obviously, they'll need a network (invariable web) back end no matter what platforms are targeted. The front end can run in a browser - which has the advantage of being portable to many platforms out of the box. With HTML5 and proper CSS, it will even work reasonably well on everything from small mobile devices to the desktop. However, In the brief history of such devices, users have shown a strong preference for native applications over browser-based applications, if for no other reason than mobile devices can't always reach the network. Mobile platforms - unless they're running a lightweight version of a desktop OS - tend to have restrictions on the development environment that vary from platform to platform. Finally, the back end may well run on a cloud server such as Amazon's Elastic Cloud or Google's App Engine, which may have it's own set of restrictions.

The desktop client can be written in whatever technologies are most suitable for the desktop, which will be discussed in the next section.

Mobile applications depend on the platform. The only one I follow closely is Android; I'll expect corrections from readers for the rest. 
For iOS, it's pretty much restricted to Objective C. Symbian is C++. Blackberry is Java. All three of these allow some selection of web tools like JavaScript, Flash and AIR - though which varies from platform to platform. Android is primarily Java-based, though it's open nature means you can develop for the embedded Linux system using anything in the Gnu Compiler Collection. Google supports a variety of scripting languages via the Android Scripting Environment. Finally, that the Android market is open means a number of different programming are available for Android. Many are ports of Java languages.

While EC is unrestricted, AE is restricted to Python and Java. Given Java's popularity in the enterprise computing world, it's unlikely that any cloud server won't allow things running on the JVM.

Exit the clock race

Another relatively recent change is the ending of the chip manufacturers wars to turn out the chip with the highest clock rate. Basically, it got to the point where it was more cost effective to wring more processing out of chips by putting more processors on them than by cranking up the speed. So my old 3.8GHz dual-core Pentium 4 is the fastest (and hottest) popular cpu sold in the US, but slower than many modern 2.xGHz systems. And these days, multi-core chips are the norm for desktops, laptops and tablets, and expected in the generation of smart phones and similar sized devices just being released.

This changes the development world since using the extra speed in these processors means running your code in parallel - which means dealing with concurrency issues. As a result, a number of different tools for dealing with concurrency at a higher levels than locking code segments have emerged. Eventually, these tools will show up in mainstream languages, but there's no harm in getting a head start on them if you can do so.

Summing up

The most valuable people will be able to work on multiple front end platforms - and on the back end as well. Since an applications first implementation is liable to be a pure web application, this makes the web tools - JavaScript and libraries, advanced HTML, and CSS - the tools to study. There isn't much that can be done about that.

Mobile platforms are liable to be the second front end. Those web technologies and Java are the only things that show up on multiple platforms (unless you're writing to the embedded OS under the application layer).

The back end could be any number of things. Ruby on Rails and Python with a number of web frameworks (Django, Pylons, Zope) are popular. Both SQL and the new noSQL databases are frequently used in such applications, and hence worth keeping in mind.  Java is also popular, at least at the enterprise level, where Java's web server technologies are excellent.

So web technologies and Java would seem to be the thing to study. However - Java does not necessarily mean the programming language here, as there are a number of languages that run on the JVM but aren't Java. Most notably, Jython and JRuby are Python and Ruby running the JVM, so those might well be a good combination with a web framework for the language. The other thing to note is that some of these languages - like Clojure and Scala - have interesting concurrency features.

Those who've been following this blog will have read about my experiments with Clojure. Next I'll discuss my preferences, and how that factors into what I choose to do next.

1 comment:

  1. I posted an answer on Quora ( along these same lines. I think that most developers have two broad choices regarding keeping themselves marketable: (1) become the end-all, be-all, uber-guru for a very specific niche or (2) be ready to learn a brand new language and/or skill set every four to six years to stay current with the market.