Archive for June, 2013

The Pragmatic Polyglot

Monday, June 24th, 2013

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.

The rapid rate of change in technology, and especially web programming frameworks, is a bit of a blessing and a curse. Open source gives us all a stage to contribute on, and people take that and run with it, it’s amazing, but literally everybody jokes about the half life of JavaScript frameworks that don’t “make it”, or the number of promising but ultimately stillborn frameworks that get hyped. As technologists, the attraction of new and shiny gives us a moving target that we’ll probably never hit. It’s ok though, things get fixed on the way.

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.

JavaScript

Some people adore it, but there’s a huge portion of the programming community that despise JavaScript for it’s bugs, for it’s lack of design, for it’s inconsistency and most ironically for it’s popularity. Tough. JavaScript is the assembly language of the web (while being accessible) and is not going away.

The low barrier to entry makes JavaScript powerful, it more or less runs everywhere, and the big-3 of tech all invest heavily in it. Be good at JavaScript, learn how to structure large client side applications and make sure you can unit test them. If it makes you feel better, just pretend that it’s a dialect of LISP. Take time to learn how to write JavaScript as JavaScript, and don’t just try and write Ruby or C# style code that runs in the browser.

Make sure you’re comfortable with using libraries like jQuery and Underscore to fix up some of JavaScripts inconsistencies. Invest time in learning Knockout.js or Angular.js for data-binding and single page applications. Learn node.js for the server side. Don’t jump on every single new JavaScript framework that hits the web though – it’s worth investing in the thing that’s used by people, and as a result, likely to succeed rather than atrophy.

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.

Polyglot persistence

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:

  • JavaScript (increasing in importance, and already dominating)
  • 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)

TL;DR

  • Learn C#, Ruby or Java.
  • Learn JavaScript and how to code in it idiomatically
  • 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#.

Think people aren’t communicating? Remember you have the privilege of looking at the code

Tuesday, June 18th, 2013

I’ve had a couple of interesting conversations recently where people have expressed frustration that non-technical people involved in product development were either “not communicating” or “not thinking around the problem enough”. In a couple of these conversations, I’ve had to articulate quite clearly that I think this is a fairly wrong-headed approach to this problem, because what it’s really doing is highlighting the different ways that technical and non-technical members of a technology department access information regarding how software works.

As a developer, always remember this:

If you are *ever* confused about what some of the software you work on does, you have a simple, irrevocable crutch. You can read the code. You can read the commit log. Nobody else gets to.

It’s worth remembering that before you jump to the conclusion that somebody just hasn’t been paying attention, remember that it’s likely that the information you have available to you, just isn’t available to them.

Think about the myriad of ways that you screw up communicating information to your peers on a day to day basis. Now imagine, that instead of being able to “just check” something, you have to take it on faith that something you have been told is accurate. It’s frequently not the fault of the people that don’t have access to the information you have available to you.

And you know what the one sure fire way to correct this behaviour is? Don’t get mad, don’t get frustrated, tell them. Help them understand, and if they’re amiable to the idea, show them the code too.