Questions About Learning VB.NET

brianwolters

New member
Joined
Aug 30, 2005
Messages
3
Location
Arkansas
Programming Experience
1-3
I really have a simple yet complex question. When learning VB.NET, are you expected to memorize how to do everything? For example, I am using an excellent book on VB.NET and it just covered the print dialog box and printing and I was really shocked at the amount of code needed to just print. Are programmers expected to know all of that my memory? I am grasping the basics but I feel I'll need to refer back to books and reference guides often. Is that normal?

Thanks,
Brian
 
O yeah it is absolutly normal and after some time it comes by itsself don't worry!
But note that learning VB.NET is very fun and easy if i may and it much differs than say C/C++. What if i tell you that learning C++ is unlike learning anything else (compared with C++ VB.NET is a kid's game). There is no such thing as one right answer and C++ books are also sometimes more confusing than of help. Oh my god i wish i could learn C++ like i'm learning VB.NET

Happy coding ;)
 
Thanks for the quick and positive response. I've had hostile and rude responses in other forums.

Well, first of all, I am totally not ready for the 70-306 test. Tried a practice exam and made a 0/10. :mad:

I've actually created (still no where near complete) a text adventure game created in VB.NET and it works well. However, in the "real world", it hasn't taught me much. In fact, someone more knowledgeable in VB.NET would say I have bad or messy code.

I am very weak in the area of class design and comprehending how to create and access them. And I have no experience in data use and retrieval. I am using Books 24/7 online and have a wealth of books to study VB.net, so hopefully I will start to build my knowledge and get ready for the 70-306.

Any tips and suggestions would be appreciated.

Brian
 
There's a quote I heard a while back: A good programmer knows everything. The best programmers know when and where to look things up.

Some of it will come naturaly and over time, but other things simply won't stick and you'll be constantly looking it up. There's nothing wrong with that, and in .NET it's harder to memorize things, since there's no telling where something is exactly in the .NET frame work namespaces.

Practice, practice, practice.

-tg
 
Yes i agree with TG ... there is noone that knows everything.
And about good programmers. What is good programmer really? Someone who has spent years in learning and building. Nah ... i don't think so. I've met many of them that claim themselfs for good programmer and when i saw their code "omg" it was so unreadable that i nearly cried.
Just follow the basic rules about programming and that's it ... you are in.

Btw, there is something like good programmer indeed and if you want to find more about this just take a look at this good article that explains about the differences between good and bad programmers:
good programmer will simply create code of a quality that average programmers never can create.
article sector said:
The real trouble with using a lot of mediocre programmers instead of a couple of good ones is that no matter how long they work, they never produce something as good as what the great programmers can produce.
Five Antonio Salieris won't produce Mozart's Requiem. Ever. Not if they work for 100 years.

Regards ;)
 
TechGnome said:
There's a quote I heard a while back: A good programmer knows everything. The best programmers know when and where to look things up.

Some of it will come naturaly and over time, but other things simply won't stick and you'll be constantly looking it up. There's nothing wrong with that, and in .NET it's harder to memorize things, since there's no telling where something is exactly in the .NET frame work namespaces.

Practice, practice, practice.

-tg

Next question...doesn't the 70-306 exam basically want that stuff memorized?
 
Beats the hell out of me.... I haven't taken it. I don't think it's going to care if you know that it's System.Data.SqlClient or not.... but rather knwoing when to use a Reader vs getting a DataSet vs ExecuteNoQuery. That kind of stuff. How to use a Try...Catch...Finaly construct. More about the syntax and the tools rather than the framework.

-tg
 
here's my advice in case anyone wants it lol:

when it comes to vb (.net and all previous versions) it can take a while to get the hang of what all is going on and can be very difficult at first to think a program through to get the result you want

but after writing a bunch of small apps (like the text adventure game for example) you'll start to get the hang of what objects do what and how to put a few of them together to get new results

once you grab the basic understanding of how things work and be comfortable with how the vb syntax is you'll be able to take on much larger apps and not even realise how easy it can be

does any of that make any sense?
i think it does

and welcome to vbdotnetforums brian!
 
Back
Top