Posts Tagged csharp

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. 

, , ,


Be Careful with ToList()

I recently came across some code during a review that seemed perfectly fine at first glance, but upon further inspection, had potential to perform terribly. Take a look. What’s wrong with this code?

using (var context = new DbContext())
context.SomeTable.Where(t => t.Id == someId)
.GroupBy(t => t.Category)
.Select(tg => new { tg.Category, Profit = tg.Sum(p => p.Profit) })

Do you see it? It’s easy to miss.

Calling ToList() on the Enumerable materializes the query, iterating over the Enumerable in order to generate the List. Then, just a moment later, we iterate over the List. We’ve potentially doubled the run time of this method. In most cases, likely not a big deal, but what if the List contains thousands of items? We’re doing more work than necessary here.

Fixing this is a simple matter of storing the IEnumerable in a variable and using the traditional foreach syntax instead of the ForEach extension method.

using (var context = new DbContext())
var query = context.SomeTable.Where(t => t.Id == someId)
.GroupBy(t => t.Category)
.Select(tg => new { tg.Category, Profit = tg.Sum(p => p.Profit) });

foreach(var item in query)

It just goes to show that you really have to be paying attention when reviewing (or writing!) code. Some issues can be terribly difficult to spot at a glance.

, , , , , ,

Leave a comment

Replacing simple factories with Func<TResult> delegate

I’ve recently noticed the emergence of a recurring pattern in my code. Each project has the same class in it, and this duplication has really been bothering me. The solution to this repetition just hit me this morning while I was reading Jon Skeet’s “C# In Depth.”

First, let me illustrate the pattern I was using and why it’s a problem.

I’ve been refactoring 1-tiered legacy code into something testable. This has involved creating a data layer class, typically called DataProvider which implements an IDataProvider interface so that I can easily mock out the data access. ┬áNow, because any kind of data access is extremely likely to have unmanaged resources, IDataProvider extends IDisposable.

Read the rest of this entry »

, , , , , , ,

Leave a comment

Mocking the VBA Editor: Moq an IEnumerable that Works with Linq

It’s been a rough morning here. I’ve just spent six hours trying to properly create a mock for the VBProject interface. There’s very little information out there about this, so I thought I’d take a moment to jot this down and save someone else the headache. For all the grief this gave me, the solution is amazing simple.

Read the rest of this entry »

, , , , , , , , , ,


Using Hampers Testing: Enter the Factory

I’ve been writing a lot of C# lately, and paying a lot of attention to my test coverage while I’m at it. Everything was going great until I wanted to use the FolderDialogBrowser to let my users select a directory.

FolderDialogBrowser implements IDisposable, so I naturally reached for a Using block.

using (var folderPicker = new FolderBrowserDialog)
    if (folderPicker.ShowDialog() != DialogResult.OK)


Then I stopped dead. I can’t do that. This will display a GUI and any hope of running automated tests against this method is lost. Read the rest of this entry »

, , , , , , , , , , ,

Leave a comment