Being a true Polyglot is about your approach to the languages you don’t yet know

Almost every software engineer claims to be a Polyglot nowadays: Someone who develops in multiple languages.

Companies are very sensibly keen to hire polyglots, but I feel they’re missing out on the thing that makes real polyglots effective. They ask for a certain length of experience in multiple languages — usually a very specific list that they are already working with — whereas I think the strength of a true polyglot is their ability to pick up new languages quickly, on-demand. It’s about how those people will recommend and handle the next language the company decides to adopt, without requiring them to hire yet more developers who already know the latest language du jour. But of-course, it’s hard to pick out true polyglots at interview, so companies hire for current skill set instead.

A polyglot should be able to talk about the languages they have already worked with, and optimise their approach to picking up new ones. I think that once you’ve worked in 3-4 languages, and understand the broad features / differences from a Computer Science / language theory standpoint, you can pick up a new language in around a week. A week of your own time, that is. I’m not suggesting companies should fund that training period. I beefed up my JavaScript in a few weekends, having bought 2 decent books that were recommended and spent hours getting comfortable with it. Some languages may take a little longer, such as Scala or Clojure, but I suspect not that much longer.

A real polyglot knows what they don’t know, can maturely assess their level of experience in a new language and plans their approach to filling in those gaps in their knowledge, as fast as possible. For instance, knowing that you need to be aware of how concurrency, threading (and more specifically thread safety) work in a new language means you’ll seek out that knowledge before hitting your first race condition or sync / visibility issue. A naive developer would blunder on until issues arise and, let’s face it, this particular class of problem often arises first in production. I know from over 15 years writing in Java that getting concurrency wrong can kill projects, and so I’m acutely aware that claiming to be a polyglot means being aware of where such pitfalls may lie in other languages and, more specifically, knowing whether or not you’ve got a grip on that.

The same goes for static / dynamic typing, compilation versus interpretation (and hybrids in between), how to implement common design patterns, how to hide data, how to implement immutability, etc. The list of these broad topics isn’t that long, but knowing what you do / don’t know about each is the mark of a polyglot.

A real polyglot knows that their strength is their ability to pick up a new language, one that they haven’t been asked to learn yet, not in the current set that they already know. Hopefully employers will catch up with this concept, and we won’t see so many “2 years of Scala” requirements in job specs. Let’s hire today’s polyglots, not yesterday’s 🙂

Holding My Own Carrot & Stick

carrotWhen you work on your own project (or for yourself), you provide the direction, the determination, and the feedback (to yourself). It struck me recently how much uncommon maturity and discipline this requires. To do it every day, unswervingly, is something of an art.

Each morning, as I work through a quick rewrite of my “Changes That Stick” app, I review how I’m doing, tweak my direction, and provide the determination to meet my own deadlines. Most people who have only ever worked for a boss have never had to do this.

The first time I did it, I had the commonly-held belief that it’s easy. Of-course I should be able to stay focussed on my own idea, I thought. After all, I’d managed to be focussed for 18 years working on other peoples’ ideas!

And then, on Day 1 working for myself, I swear I thought I had some form of attention deficit disorder. I couldn’t focus for more than a few minutes. Everything was a potential distraction. And the only difference was that, for the first time, I was working on my idea. I began to realise how much the mandatory nature of regular work keeps us focussed on it, the fact that someone else has requested it means the decision about whether to complete it is outside of ourselves. The eventual pay cheque is the carrot, and the boss holds the stick.

But the second it becomes our work, it’s suddenly optional and we need to provide the direction, the discipline and the persistence ourselves. We need to set deadlines, stop ourselves wandering off down attractive-looking side paths and, most of all, be the one who believes in it most. That last one, more than any, is tough. A regular job requires your presence, your hard work and your time. Your own project requires much, much more… and you need to provide it, to yourself, on a daily basis.

It took me a few months to get to this point, but now I feel able to provide myself with the carrot & stick required to do my own work. I guess this also means that, in future regular paid jobs, no-one else will need to do that for me 🙂

Paralysed by Choice

road-arrowsThe path from having an idea to finishing a workable piece of software is filled with hundreds of choices. No, on second thought, probably thousands. Choice is what makes software development so compelling as a career, but I think it also often derails peoples’ efforts towards building something real with software.

Everything is a choice, even those we feel we no-longer agonise over such as our favourite programming language, Operating System, IDE, or certain aspects of programming style that we’ve adopted and now take for granted. But even these, in a team of two or more people, can come up for regular and often lengthy debate, sometimes of religious proportions.

Other choices we face might be design decisions, with all their subtlety and implications: Should we bother trying to make certain entities immutable? Where best to store them and in what format? Should we use a schema? How to achieve the best throughput, the lowest latency, the required reliability?

Some are priority based: Do we implement certain easy optimisations now as they come to mind, or strictly put them on a list for later? Which features are really MVP? No, really. If we can only deliver one out of two crucial features, which do we choose and who does it affect?

Often, the existence of a choice springs to mind after the point at which we would optimally have made it. Looking back at a portion of the product we already completed, we see there were opportunities to do it differently. “Better”. Then it’s a balancing act between moving forward, knowing the completed work is somehow imperfect (oh the torture!), or refactor it now before moving ahead. We all know what we want to do, but what will we actually agree to do? (And that doesn’t mean secretly re-coding it whilst no-one’s looking)

Some choices get revisited with nauseating frequency. This, particularly in teams, is a sign that we never really reached a decision. We foreclosed on the decision, took an easy option or the option that was most workable at the time, knowing full well that it would need changing but burying our heads in the sand. When disagreeing parties need to choose, it’s crucial that all parties agree the choice is made — past tense — rather than just postponed until the day that everyone can get their own way (because that day is, obviously, never coming).

Where choices exist, and they always do, there is a myth that an outcome is possible that leaves everyone feeling comfortable, happy with the decision, with all their needs and considerations met. Even in a team of one, this is not possible: it will be necessary to move on when refactoring could take place. Or it will be crucial to hit a deadline with a suboptimal implementation. But in larger teams, it is even more important to let go of the idea that an ideal decision is possible. Sometimes I think that declaring this truth openly would help alot. “Not everyone will get their own way. Deal with it”. What’s required is the best possible decision for this situation, this team, this product, this deadline, etc. And a desire not to continually revisit that until an agreed point in the future. That’s powerful, but so rarely achieved even in large organisations.

As software engineers, we spend years learning to code well and analysing what makes us better. I suspect we could spend a while learning how to make better decisions, alone and in teams. We make so many of them.