Hello, I have an Access DB that has quite a bit of VBA code behind it and I wanted to know if there is an easy way to determine how many lines of code there actually is. It would be nice if blank lines were ignored. There are quite a few forms and modules so going through each one would take awhile.
The reason I ask is because Access utilizes wizards quite a bit and someone could easily make a nice DB without coding much. I am a programmer but my job right now isn't really a programming job, but because I can I've created this DB and actually was coding everyday for about a year.
Now I don't get to code as much, so I'd like to find an actual programming job. I'm trying update my resume and I want to let employers know I've been actually coding this last year instead of using wizards and macros. I thought I would list the amount of code I actually produced. Does this make sense? I don't see much demand for Access programmers and am worried that my experience won't help me in finding a different programming job. To me programming is programming, you just have to learn the syntax of the language, but I don't know if employers feel the same.
Any input on the lines of code is appreciated and if you have any opinions on the rest I'd like to hear them. I apologize if this should be posted somewhere else.
Short answer: No, there is not an easy way to find total lines of code.
Long answer: Include "extensive custom VBA programming" on your experience for MS Access projects. When is the last time you saw ANY programmer's resume that gave the precise number of lines of code they wrote for their last job? There is not much of a demand for access "programmers", this is true. Most of the contracts I land are fixing databases that were made in house by a non-technical employee who thought they could go it alone. Those are what you should be sniping. if you want to get a different programming job, you'll have to learn the language first hand. Nobody will ever hire a vba "programmer" who thinks they can code in assembly because it's just a matter of syntax.
Teddy, thanks for the input. I should've mentioned I graduated with a CS degree and did most of my programming in C++. I also have done projects in Java, VB, & VAX Assembly, which would be on my resume so it's not like I'm trying to pretend I'm a programmer. That is why I said programming is programming.
The job I have now is my first job out of college and like I said isn't considered a programming job, although in the last year it has been.
Everyone wants potential employees to have real world experience and I've got real world experience, but because it's in Access/VBA I don't think it will be taken seriously. Am I right? Am I no better off than an entry level person when it comes to non-Access programming jobs?
Ah, in that case just list the languages. How far that piece of paper will get you is going to depend entirely on the person managing the intake process. The CS degree will get you in the door well in front of any "entry level" person off the street. It may even put you in front of more experienced programmers depending on the personality of the interviewer. I would list proficiencies in all the languages you're comfortable with.
Don't rely so much on leveraging VBA. It's often viewed as "VB -Lite®", and VB is looked at as a childs toy to begin with. This is basically wrong, but understand that when on the interview circuit, that's not a terribly uncommon perception.
Play up the fact that you have a working knowledge of the syntax and structures of x, y and z languages and you have life-cycle experience writing code in VBA. That might work out for you. The "I'm a programmer because I did VBA" thing doesn't get too far, I've tried that myself. I market myself as a database developer who can deliver automation solutions leveraging VBA. There's a bit of a difference between presenting that and "VBA/VB programmer". If you want to go more the programming route, highlight your bag of languages...
On the counting VBA lines issue, you can do something like this (use in a module named ModCountLines):
Function FnCountTotalVBALines() As Long
Dim i As Long
Dim Module As Object
Dim lngCountLines As Long
While i < Access.Modules.Count
Set Module = Access.Modules(i)
If Module.Name <> "ModCountLines" Then
lngCountLines = lngCountLines + Module.CountOfLines
i = i + 1
FnCountTotalVBALines = lngCountLines
Although, personally I'm not sure if quoting the number of VBA lines you've wrote will help you much in an interview!
I suggest an "Experience based resume" - this is where you take a look at actual work you have done and create a series of "job titles" that fit. Then you can put details (particularly accomplishments) under each. If you have relevant college/internship experience, include it.
For example, my first job was as a "Process Validation Engineer". I don't use a "Job based resume" because that title doesn't even come close to describing what I actually did: Quality Systems, Validation Coordination, Project Management, Project Engineering, Cradle to Grave Product Engineering Services, Software Development and Support, Database Creation, Hardware/Software Integration, etc. (got to love small companies). I happened to break my skill set into 3 main areas: Engineering, Quality and Software and went on from there.
Especially look to Teddy's "deliver automation solutions" - that's the real value of VBA. I market myself as being able to simplify and automate processes, reduce rework and errors and increase overall efficiency through the integration of existing software system. Talk up about what your company gained from the programming that you did.
I'd hate to say it, but anybody who can record a macro can claim to be a VBA programmer - especially when they discover how to get into the code editor and start tweaking it. Of course, as Teddy says, those type of people create work for folks like us. The experience is good - but highlight VB (without the "A") and C++ along with the other stuff.