Need Advice: Learning Two Subjects At Once

I know this probably isn't the best place to ask this question, but I always get such great answers from OC members I thought I'd give it a shot. I'm working for a software development company, and most of their work is designing Access DB's. So my day is spent learning Access/VBA. Issue is that's not really what I want to learn, there's not that many jobs out there for Access/VBA, I'd rather be learning SQL/C#. Regardless, I don't have any exp as a programmer, and the company was good enough to take me on and teach me, so I can't be too unhappy.

However, the reason for my post is this. I've been learning C# at night, and coming along quite nicely, but my Access training at work had slowed. I'm just doing repetitive debugging and combing through code for small edits. I want to learn more about Access, if only for understanding database fundamentals. I'm wondering if at night I can do an hour of Access training, then an hour of C#. I mean I know a lot of this is personal, without knowing me it's hard to make that call. I'm just talking generally, is that a good idea? Can I shift gears that rapidly and retain what I'm learning? Or should I go, 2 hours Access one night, then 2 hours C# the next? Or really not try and squeeze more Access in at all? I dunno, simply looking for some advice.

Too bad I can't just have Tank upload it to my BRAIN!

I'm a bit confused by your post, this seems like a personal question. We have no way of knowing if you have the time or mental capacity to learn what you want to learn.

I'd honestly ignore Access and go with SQL/MySQL. Once you learn about one database, the others make sense.

This is just a suggestion, but maybe you might want to consider separating the coding from the database work? You could try learning database structures and queries, then, try writing forms in Access and in C# to perform CRUD operations on your database. A book that really helped me learn SQL was, "SQL Queries for Mere Mortals".

Since Access can be used as a front-end for SQL Server, I suggest you do your database work in SQL Server.

Learning standard SQL will help you both in the future when you are doing SQL and doing Access now since you can query Access with SQL like syntax.

I don't think you should be so much worried about which language (VBA or C#) as much as you should be about learning how to program in general. By learning program flow and data structuring you should be able to program in any language. Then to learn a new language you just need to learn it's syntax and any little differences the language might have (ex. 0 or 1 based indexing for arrays).

Read and then re-read several times what Khamikal wrote. The other responses were not bad in any way, but Khamikal hit it exactly. Once you've done it long enough and in enough languages, you realize it's all the same stuff.

It may help to give you a more real world scenarioso you understand why Kemikal's post is so important.

Go online and read through anyone else's code. It's hard to go into someone else's code cold and figure out what is going on. (That's what comments are for, right? Wrong.) Even with comments, you still need to take it in. It's difficult.

Here is the key point you learn the hard way after months on the job as a programmer: Your own code, 6 months later, is no longer your own code. It is exactly like someone else wrote it entirely.

Point?

Point is that you need to write your code in a way that others can read it and figure it out with as little trouble as possible. Why? Because as I just pointed out, the number one beneficiary of this is yourself, in the future. I've gone back into old code and slapped myself. (No worries, I like that kind of thing)

How do you make it more readable? Comments? Nope. I have found that when you write code you are in a specific thought process and frame of mind, with specific information and variables in your own head you are thinking of. Any comments you write are just a verbalization of those. Months later, you will be in an entirely different mindset with entirely different thoughts going on.

The code itself should be the focus, not writing poor code then writing a comment to explain it because you couldn't take the time to write it better.

One technique:
Number 1 problem of amateur code: Long a$$ blocks of code. Either methods, procedures, functions, or whatever. If you are writing a function and you need to scroll, it's way, way, way too long. Break it apart. A lot. If you need to do a task that includes finding a file, validating if it exists, ensuring you have permissions to edit, opening the file, saving stuff, and then closing the file, it should not all be together in one function. It should be a bunch of small ones. (Hint, see a comma above, its a separate function). Later on, when your checkFilePermissions() function throws an error, guess what kind of problem you have... oh yeah, suggestion number 2 follows...

Self-commenting code - I can't tell you how many times I go into someone else's code and see a variable called x. And it's not being used as a Cartesian X coordinate. Now I have to figure out what x is to figure out what the code is doing. If instead I called x itemCount, it at least tells me a lot more and I have to do that much less searching.

And on databases, learn SQL, skip Access. Access will teach you a lot of bad habits and dependency on dummy tools. SQL was from an era where they could not make things complicated, so you can just the simplest parts of it for an entire career and do just fine. PM me with questions any time regarding it and I'll help you.