Do you want to be a VBA Developer, or do you want to be a Software Developer?

I’ve seen a number blog posts by very good VBA devs worrying about the future of the platform and their careers. They’re right to be concerned, but not because they’re VBA devs. A Java developer should be concerned. A C developer should be concerned. And yes, a C# developer should be concerned too. 

You see, these folks are worried that their platform/language of choice is going to become obsolete. If it’s the only one you know, that makes you obsolete too. If you’re an X developer, then any given day could be your last. As new technologies become prevelant, old ones become more and more niche. The jobs fade away with the old stacks. If you want to protect yourself and your family, then you need to have more than one hammer in your toolbox. I think you have to ask yourself, do you really want to be a VBA developer or do you want to have the security of being a Software Developer?

It’s often said that bad developers can write bad code in any language, but the opposite is true too. Good developers can write good code in any language.

I’ve had a few folks ask me how I made the jump from being a VBA dev to being a C# dev.  The truth is, I wasn’t ever a VBA dev. My first (and second) language was BASIC. Then I learned some Java. At this point, it was only a hobby. I had no dreams or aspirations of doing this professionally. I was a Planogram Analyst. My job was to create schematics to show people where to put the right amount of the right product on the shelf. It was a tedious job, so I started using VBA and JDA Space Automation (a proprietary scripting language) to automate my work. I bet many of you VBA developers out there started the same way. 

Being a nice guy, I shared these tools with my coworkers. Eventually, I was asked to do it full time. That’s when I had to learn some SQL. Soon after, I started using SSIS for all the ETL jobs we needed. So you see, I was never really a VBA dev. I was a software developer. I learned and used whatever tool I needed in order to get the job done. 

Still, if you looked at my resume At the time, you would have labeled me a VBA dev. Perhaps, a person could be justified in doing so. Hell, 6 months ago, you could have easily labeled me a C# dev, but I’m not. I’m more than that and I bet you are too.  It’s often said that bad developers can write bad code in any language, but the opposite is true too. Good developers can write good code in any language.

That doesn’t matter much to recruiters and hiring managers though, does it? So how did I make the jump away from VBA professionally?

First, I accepted that being labeled a VBA dev was putting my future at risk. Then I picked a language that was in demand and started learning it. I’d write solutions to Project Euler problems and post them on Code Review Stack Exchange. There, I could get feedback from professionals who really knew the language. That feedback is absolutely critical to really learn something. Without it, you don’t even know that you’re making mistakes. 

Next, I started getting serious about OOP, SOLID, clean code, and unit testing. I’d spend my time reading books like Clean Code and Code Complete. I started to ruthlessly apply good engineering practices to my VBA code at work. Only, VBA didn’t quite have the toolset I needed to really test drive my code. So, I started building them, in VBA at first, but soon after the Rubberduck project was born. Finally, I ended up breezing my way through an paid and verified EdX course for some “formal proof” that I knew the language I’d be using at the places I was applying to. 

Now I had all the ammo I needed to make the jump, but it still wasn’t easy. I had to treat finding a job like it was a job, because it was. During the time I was looking for work, I was spending at least 20 hours a week writing cover letters and performing phone screens, on top of my 50 hour a week job. I nearly burnt out before I finally found a great place to work, but I did find one and made the jump. Since then, I’ve started to learn C, C++, and embedded development. 

So, for those of you who’ve asked me how I made the jump from VBA to C#, I’m still not sure that I’m the right person to ask, but here’s my TL;DR:

1. Learn how to write Object Oriented VBA. 
2. Stop thinking of yourself as a VBA dev. 
3. Learn an in demand language. 
4. Learn how write good unit tests. 
5. Start contributing to an Open Source project written in your new language.
6. Get a certification, even if it feels silly. 
7. Make it your job to find a new one. 
8. Never stop learning. 

Comments on Doc Comments

I was reviewing some VBA code over at Code Review Stack Exchange the other day and it got me to thinking about comments. The code wasn’t too bad, but there were so many comments in the code that, well…

I just read over this again and I think the fact that I mention the comments so often really highlights the issue. I barely even looked at the code because I was too distracted by all the comments.

VBA and Git the Sequel: This Time it’s Integrated

I’ve talked before about using Git with VBA and also about the importance of using source control and other tools for our work. Truthfully though, using source control with VBA is still hard. This is mostly because getting the code modules into and out of the VB Project is hard, and harder to do right. Well, you may have heard that there’s a new duck in town. It’s taken me about 6 months of spare time, but Rubberduck v1.4 not only has a source control COM library that you can use right in VBA to work with Git VBA repositories, but you can also now branch, commit, pull, push, and merge right from inside of the editor.

Iterate over a date range in VBA

After years of VBA development, I’m still learning about the language every day. I was absolutely surprised when I tried this today. You can iterate over a date range just like you can iterate over a range of integers.

Public Sub LoopOverDateRange()
    
    Const startDate As Date = #5/13/2015#
    Const endDate As Date = #5/20/2015#
    
    Dim d As Date
    Dim i As Integer
    i = 1
    For d = startDate To endDate
        Debug.Print "Iteration " & i & ":" & vbTab & d
        i = i + 1
    Next
    
End Sub

This code will result in the following output.

Iteration 1:    5/13/2015
Iteration 2:    5/14/2015
Iteration 3:    5/15/2015
Iteration 4:    5/16/2015
Iteration 5:    5/17/2015
Iteration 6:    5/18/2015
Iteration 7:    5/19/2015
Iteration 8:    5/20/2015

Enjoy!

VB Attributes: What are they and why should we use them?

Did you know that there’s code in your VBA projects that you can’t see in your editor? Want to see it? (Of course you do.)

Some Days…

It’s been a crazy day. I found out that we have users on the other side of the globe, Rubberduck doesn’t work in 64 bit versions of Office, and JetBrains gave us a free Open Source license of ReSharper. Oh… And I worked a full day putting out fires at the office. Some times things get surreal. 

I just wanted to share this with everyone and let you know what’s coming down the pipe for the blog. I still owe you a look at what we’re planning for the next minor release of Rubberduck (Hint: it includes support for Office 64x…). I also want to do a small series about VBA attributes over the next few weeks. They’re very cool and under utilized in my opinion. That’s probably because there is next to no documentation available. So, I’m going to pick one or two to talk about at a time and document what I happen to know about them. 

Until then,

Happy Coding.

The Professional VBA Developer

I came across a post on Programmer’s Stack Exchange yesterday that really irked me. It took me a little while to really digest what upset me about it, but I think I understand now. This developer was asking for more reasons to back up his claim that he should move his solution from VBA to C#. That in itself is fine. As I stated in my response, I understand his desire to move his solution to C#. I wish I could move all of my projects to the .Net platform myself.

No. Wanting to move to a more modern technology was not my issue with his question. My problem was with how he acted like working in an old technology gave him a pass on being a professional.

Version 1.2 is here!

Version 1.2 of Rubberduck has arrived. I’ll follow up soon with some thoughts about it and where we’re heading next.

Rubberduck News

I’m really excited to announce this, so I’ll get to the point…

Version 1.2 just released!

The most visible change is all of the new Code Inspections. There were only a handful of them in Version 1.1, but now Rubberduck is finding all kinds of issues with VBA code. Everything from obsolete syntax to unused variables. It’s really very cool.

The other very visible change is the addition of an Extract Method refactoring tool. Highlight some code, and extract it into its own method. Awesome. This one is very much like the static code analysis was in the last version, just a glimpse at the great things to come.

There were also a lot of improvements under the hood. We entirely swapped out the parser that allows us to do much of what we’ve done. Along with that, we’ve fixed a verifiable crap ton of bugs and UX problems. I’m…

View original post 28 more words

See a Need, Fill a Need

I’ve been fairly absent from this blog lately. I’ve been busy working on a new release of Rubberduck and, honestly, there are only so many hours in a day. More importantly, there are only so many concentrated thoughts to go around in 24 hours. So, I apologize for being gone for so long. I hope you can forgive me when you see the results. I’m really excited about our next release. There’s some really awesome things in there. You can download the pre-release now if you’re interested. There are a few kinks to work out, but things should be stable very soon.

To be truthful though, that project is the last thing I want to talk about right now. Rubberduck has become an obsession. There have been so many early mornings and late nights that I can’t possibly count them. There will be more. Many more. We’re only getting warmed up… and I’m going to talk about it anyway. It is an obsession after all. Like any addict, I just can’t let it go.

Test Driven Development in VBA: Eating Our Dogfood

You heard me right. TDD in VBA. It’s completely possible. I know because I’ve spent the last two weeks using Rubberduck’s Unit Testing framework doing it.