Atelier Clockwork

Choosing when to Put Down Old Tools

Which Lets You Pick up New Tools

I’m finding the reactions of people who are not developers to my excitedly telling them about the announcement of Swift to be interesting. Some of them pick up on the fact I’m excited, a lot of them don’t care and smile and nod, and some of them offer condolences because now a whole stack of my skills are going to be obsolete.

The thing is, I’m not bothered by that. I have far more obsolete or unused skills than I do active ones. Keeping the domain to just programming languages I have formal training with or have used these languages professionally in the past, the list is as follows:

  1. QBasic
  2. Visual Basic
  3. C
  4. PHP
  5. Lingo
  6. ActionScript 1.0
  7. ActionScript 2.0
  8. ActionScript 3.0
  9. FLEX
  10. Javascript / JQuery
  11. ASP.NET

And yes, all 3 versions of ActionScript were different programming languages, not just revisions of the same language. Right now I’m working on a project that has modules written in:

  1. Objective-C
  2. Ruby
  3. Java

I already have a roadmap planned to first switch all new classes for the project over to Swift sometime after xCode 6 leaves beta as I know better than to mix beta software and a production environment that includes a schedule. When it feels like I have a feel for best practices in Swift, and likely when a major revision of the project is starting to take advantage of the ability to use dynamic libraries and extensions, I’ll be rewriting the Objective-C sections of the project in Swift. And this isn’t just about Swift being newer, it looks to sand down a lot of the rougher edges in Objective-C, and to be a faster and safer language while doing it.

The other, promising, part of the Objective-C to Swift transition is that it should be easier for me to go from not knowing the language at all to getting real work done. Even though the grammar and structure is different, it still talks to the entire UIKit API in a form that’s at least sort of recognizable, so I’m not learning a whole new system level API.

My guess is that within 2 to 3 years, I could add Objective-C on the list of programming languages that I used to work in, though I probably will be staying trained up on and working in it more often than anything else on that list aside from potentially Javascript. Assuming I don’t pick up more languages (or get to drop Java as a dependency in my project) this puts my “obsolete” to “modern” skills count at 4:1 in 3 years, and if I can bump Java too it’s over 6:1.

Every one of those skills has been a stepping stone that contributes to the much more general skill that is being a good developer. Part of it is that many of the languages were the expedient choice. I learned ActionScript, because Flash was the best way to make sure that you could use modern video encoding on a Windows XP machine, which for a long time the user could not install software. Even now, I’m not thrilled with the fact I’m writing a REST API in Java, but it was the best choice to meet all of my project requirements.

Programming makes up a tiny subset of my “obsolete” skills. My 3D modeling, rendering, and animation knowledge is now woefully obsolete and rusty. I used to know how to install and maintain every version of Windows from 3.1 to XP, and those operating systems are now all obsolete.

On the other hand, I now maintain a Linux server in the cloud, which I could not say that I could manage 2 years ago. A few months ago I painlessly transitioned a server from Ubuntu on AWS to CentOS on DigitalOcean, because I decided if I was changing hosting providers I may as well see what it’s like installing a LAMP stack on a different distribution of Linux, as several developers I respect had name dropped CentOS as the best choice for a pure server environment.

I try to force myself to use the best tools for whatever it is I’m working on. A lot of the time, the tools I’m familiar with have an advantage. Eventually the tools I know won’t be the best option. That can be because of significant improvements in other tools, because the tool I know is no longer supported, or because the project has requirements that are at the edge of or beyond the capability of the tools that I already know.