The developer tool suite offered by Microsoft for Excel is currently a set of three complimentary technologies:
- Visual Studio Tools for Office (Dot Net)
- Visual Basic For Applications
The VBA language is an interesting one. Often referred to as the “jewel in the crown” of the Office suite, there is no doubt that VBA is largely behind the huge success of desktop Office. Yet Microsoft seems to consider it to be an unwanted child and has left it to stagnate for 15+ years – except for the 64-bit support in
VBA7 which was grudgingly conceded for Office 2010.
Whilst Microsoft has made it clear that it will continue to support VBA for now, it has been incredibly indecisive on how to replace it, leaving VBA developers such as myself in a perpetual state of uncertainty as we live out the long tail. I honestly have no idea when a decision will finally be made but, for now, Microsoft seems to be concentrating its efforts on building out the BI capabilities of Excel and support for various platform endpoints. Excel is here to stay and has even been recently praised by Microsoft’s CEO, but if you ask any developer they’ll tell you there isn’t a future in VBA development.
The recent volatility (read: Brexit) has caused me to think very carefully about how to secure my professional future. Reskilling is something I’ve delayed for far too long: it took me ages to get good with VBA and I know that it will take me equally long – or likely longer – to get to the same standard in another technology. I’ve dabbled here and there, but I haven’t really committed. The time for dallying is over.
The question then becomes: which technology should I turn to? As far as I’m concerned VSTO has long been a dead turkey and, whilst Apps for Office is potentially worth learning, I don’t see any demand for it out in the market. Perhaps that’s because it is too new – or perhaps it is another turkey. The information available to me suggests that I need to look beyond Microsoft’s Excel development tool suite and possibly even beyond the wonderful world of Excel development itself.
I have to be realistic. I can’t just declare myself to be a Haskell developer and expect the job offers to come flooding in. A more pragmatic approach is to find a hybrid role – one where the key skill is Excel/VBA so I can deliver solid results – but where there is also an opportunity to use other technologies. There’s nothing like learning a new skill on-the-job.
In London’s finance sector where I work, Excel developer job requirements have a common theme:
- Outstanding Excel and Excel VBA knowledge
- Good business knowledge and experience. [RAD developer roles are business facing, often on trading floors.]
- C#.Net or Python or Java (or C++ for the more quantitative positions).
- Good database skills: typically SQL Server or Oracle. MS Access is often useful
The number of Excel-focused developer jobs here is decreasing, but I believe there is still enough time left in the tail to pick up one of the “alternative” skills highlighted above in bold and progress it on-the-job. After a couple of years that skill should be decent enough to apply for developer roles which have nothing to do with Excel – if one needs to.
Database skills are essential but, since I already have decent SQL Server, my focus is drawn towards learning either C#.Net, Python or Java. Python and Java are both excellent options, but I seem to notice more Excel developer roles advertised with C# attached to them. What is interesting about the Excel/C# roles is there’s usually very little mention of VSTO: the experience the recruiters are looking for tends to be on third party products such as Excel-DNA, Add-In Express and Spreadsheet Gear.
Other than immediate job opportunities, C# appeals to me for a number of different reasons:
Firstly, I already have some experience with C#. Don’t get me wrong – I’m a beginner to intermediate level at best – but at least I’m already a little way along the learning curve. C#.Net is a Microsoft technology so perhaps it will feel more familiar to me than Python or Java, thereby making it easier to pick up.
Secondly, and very significantly, the contract I currently have does have some scope for C# projects which I can leverage. I’m happy where I am and it can help get me where I need to get to.
Thirdly, it’s a great, central language to have under one’s belt. Once you’re good at C#, the Java language syntax is very similar and shouldn’t be too hard to pick up (or so I’m told). Knowledge of the .Net framework is transferable to other .Net languages such as VB.Net. The OOP principles and concepts are shared by many other languages. It can target many different endpoints. It certainly seems to open up a lot of doors.
Fourthly, I live with the ever-diminishing hope that Microsoft will decide to replace VBA with .Net. I’d love to be able to jump on that bandwagon. And, if by some miracle, VSTO is revitalised, then I would be in a strong position to leverage that too.
Fifthly, the C# language is still evolving. It’s an exciting and dynamic space to be involved in. No tails in sight here.
And finally, getting started with C# is free.
- Microsoft’s Visual Studio Community is a very rich IDE and is free to download from MSDN for individual developers. There are other free IDEs available out there – such as SharpDevelop – but I’ve never used them.
- Channel9 on MSDN offers hundreds of hours of free C# training videos.
- There are plenty of free e-books and online forums.
- Oh, did I mention, it’s free?
So that’s my current line of thinking. How about you? Are you an Excel developer? Where do you see yourself in 2-5 years’ time?