It’s quite the trend to call yourself a “polyglot programmer” of late, and it’s a label that’s at risk of being misappropriated for evil (read: recruitment consultant needs), but there’s a real solid truth to it, and a reason people started self-identifying as polyglot a couple of years ago.
Diversity, in all walks of life, is a good thing. Diversity helps you think around problems, diversity changes the way you approach things, and diversity forces you to keep an open mind. Technology is no different. Being aware of multiple approaches to solving a problem, makes you a better programmer in whatever tool or language you’re using right now.
I’m surprised then, that people often ask me “if you were starting again, what would you use?”, “do you still like X?”, “what do you think the future of Y is?” and commonly, considering I do a lot of work in C’# “would you do this in .NET if you were doing it again?”. The subtext of many of these questions is a simple and perhaps fearful one of “what do I need to learn to keep being able to pay the rent?”, and that’s a very human and important question.
My bets (TL;DR version)
Firstly, if you’re using a currently mainstream language, and you’re totally happy with that, there’s a good chance that your job will probably never disappear in some capacity or another. COBOL programmers still make a fine living. If financial security is all you’re concerned with, any language that’s mainstreamed for a sufficient length of time ( > 5 years, mass adoption) will have a suitable amount of business as usual maintenance work to keep you employed. What will change as time progresses, is the amount of interesting and forward looking work available to you, if you choose to silo yourself into one specific language or ecosystem.
But you want to do some interesting work right? The bad news is you can’t learn every tool and framework. Some doors will remain shut to you, because you are time constrained. What you want to do, is ensure you have enough influences and enough variety, that you apply yourself and be useful in a number of environments. So, half way through 2013, I think you should probably have a cross section of the following (as a developer):
A strong skill in a decent, popular, object-oriented programming language, likely a C-shaped one.
Your Java, your Ruby, your C#. This gives you a good grasp on traditional server side programming if you’re doing web work, and applications on the server / desktop.
Be aware of function programming
It’s worth taking the time to look at languages like Clojure, F#, or even languages with certain aspects of monadic behaviour (arguably Linq in C#). Functional programming will make you think about structuring applications in different ways, and different is always educational. Functional programming and finance appear to be on an upward trend, so if you’re interested in that sector get learning.
Something that runs on a smart-phone
Smart-phones are clearly big, they’re not going away, and smart devices are only going to become more pervasive. They’re the new desktop, so learn to get your code onto them. You can go the pure native route (Java / Objective-C) or learn a cross platform framework (Cordova / PhoneGap / Xamarin), but make sure you can get your code running on them.
T-SQL is not going to die, but it’s already well on its way to not being the default answer to “I need to store some data”. It doesn’t “web-scale” trivially (though you can get a fair way down the road with it) and compared to the big players in modern document databases, it’s arcane legacy black magic.
Kids learning programming today are more likely to use a cloud hosted document database to spin up their learning apps than deal with the impedance mismatch of object to relational database mapping, and in the long term, it’ll win.
You’re going to see people doing things in document databases that T-SQL would be way better at, but the historical friction associated with DBA and stored procedures and database change control has been inconvenient and productivity killing for long enough to be just about ready to perform seppuku. Your MySQLs and SqlServers aren’t going to vanish, but they’re going to get much less exciting, and much more marginalised, but betting on them as the future of web storage at this point is betting against the internet.
If I had one piece of advice for a DBA? Learn how to do map/reduce. You’re going to need it.
Understand the web and REST
Connectivity matters, APIs matter. If you’re starting a company, you’ll want to integrate with other services to get you to market quicker, and if you’re large and dominant, you’re likely going to want to offer your software for partners to integrate with. Understanding RESTful design, HATEOS, and how to put together a reasonably intuitive, scalable web API is important.
It’s a channel of growth for your product, and it lets you take your content to where the users are willing to consume it. Neglect this fact and you’re probably going to have your lunch eaten by a competitor. Understand this as a developer and you’ll have a job for a long time.
DevOps, Continuous delivery, cloud infrastructure
Script everything. Make everything repeatable.
Traditionally when “developers did ops” it was because you didn’t have the resource to hire “ops guys”. As the way we deploy and monitor our software matures, the lines between developers and ops cease to exist.
If you’re an ops guy, you’ll find yourself scripting environmental changes and committing to git repos. As a developer, you might be building monitoring and alerting as first class concepts into your applications. As you have to build systems that scale across hundreds of severs, not just ten, the kinds of tools you’ll need to build will change. Learn about these things. You’ll probably all need to learn one or more scripting languages.
Don’t buy into tools or organisations that pretend they can magically give you a devops “capacity”. Tools are a crutch, the culture of cooperation and open-ness, real time monitoring and automation is what you need to pay attention to. Always ship your software. Ship it so you know it works, ship it so you can get paid, ship it so your users know it works.
A search tool
Search is a big deal and it’s now mature and available. There’s no excuse to have some crummy SQL-server full text search implementation that never really finds anything when you can use Lucene, or a good Lucene wrapper like ElasticSearch or Solr. Search can make or break a product, invest some time in it.
You can’t learn everything, but you can get a good cross-section
Being polyglot doesn’t mean you have to know everything, but you should make sure you know a good balanced cross section of the right things, and in an industry so prone to change, always focus on learning different practices and styles, than different frameworks.
From my casual observation, I’d suggest betting on tools with active developer communities or some kind of formal support as a good sign of maturity. My casual observations around current language trends, in order of importance:
- Ruby (holding, immensely popular and mature)
- C# + ASP.net & Java (holding, king of “hard server side” for powerful fast software)
- Front end browser frameworks (increasing, but notably jQuery, Underscore, Knockout and Angular)
- Other languages on the JVM (Groovy, JRuby) taking advantages of the JVM without the Java.
- Objective-C seems tied to the success of iDevices as nobody wants it anywhere else
- Clojure/F# (niche, finance, functional)
- PHP (downward trend, I’d not recommend new work here, but bigger than Jesus)
- Python / Erlang (also ran, small)
- Learn C#, Ruby or Java.
- Understand document databases and SQL
- Understand REST
- Do continuous delivery
- Learn Lucene or a Lucene wrapper
And yes, I’d do it again in C#.