Writing your code is far and away the best way to learn. Not pseudocode, proper code; do the pseudocode first, but then implement it into VBA. That's where you will really learn, because you'll make all the mistakes and you will learn from them.
How I got into VBA; I used to be a programmer, but in languages like Cobol, Fortran, Mumps. I got bored of programming, I worked on some fascinating projects (nuclear power plant, RAF graphics modelling for Tornado aircraft). But then I went to work in a bank, where it was just dull. So I became an accountant (which is a bit perverse) but from a business aspect it's more interesting. Anyway didn't program anything fora few years. Started using Excel, and realised one day I could record macros. I'm essentially lazy when it comes to repetative tasks. As I had some big finance reports on plain paper where it was hard to see the detail, I wanted the report to print out in 'pyjama paper' style; in the old 'pre laserjet' days, computer reports came out on wide paper with alternate lines colured light green (hence the name as it was stripy). Made it easy to read though, and I wanted to do that with the Excel reports. So I recorded a macro to shade a few alternate lines, saw how it worked, and with the Excel help function and a bit of guessing I wrote the macro to do it. The internet didn't exist outside universities in those days, and Excel 4.0 was fairly new so there weren't any Macro books, so you just had to rely on XL Help, guessing and asking colleagues. From there I started to write other macros to make my life easier, and add buttons to the toolbar to use them. Simple things, like 'paste special/formula'. But the simple things became more complex, and here I am.
After a couple of years I got the John Walkenbach book which introduced me to userforms, then I discovered MrExcel.com, and now I'm essentially a contractor specialising in writing VBA (Excel, Access) solutions for Finance departments. My current project is about just shy of 2,000 lines of code.
I've never been on an Excel course (though I've delivered a few), but my core programming skills have stood me in much better stead.
As I said at the top, I've worked with a number of computer languages. You realise after the first few that, really they're mostly the same thing, it's only the way they do the same things that differs.
One thing if you're going to write pseudocode, I would recommend looking up 'Nassi Schneiderman' charts;
"http://www.sombers.com/Structured Design Nassi Schneiderman.doc"
is a good overview.
Its a tool for designing pseudocode, and once you're familiar with it, it makes it very hard to design bad code.
If you're going to get into modular or structured design (where procedures call other procedures) then it's far and away the best design tool I've come across, and it makes life very easy.
