The Lounge is rated PG. If you're about to post something you wouldn't want your
kid sister to read then don't post it. No flame wars, no abusive conduct, no programming
questions and please don't post ads.
Welcome aboard! You'll soon get used to us, just try not to step in anything...nasty. Oh. Sorry about that, it'll probably brush off when it dries.
If you have done the training classes then you should have had to do exercises, yes? And they involve writing the code behind the designer - so you should already be somewhat proficient in doing it. But it may be a scale thing - working on a whole project can be daunting, particularly at first. The trick is to break it into smaller bits and look at them all separately. If the bit you are looking at is too big to work out, you treat that as a whole project, and break it down as well. Eventually you come to bits which are the right size, and you can do them. Which means the bigger bits start to work as well.
After a while, you tend to find that the "little bits" you can do are actually "quite large bits" and you can start to see where everything goes and how they interrelate. It's practice, and experience really.
Have a little faith, give it a try, and don't try too big a project to start with - getting frustrated because what you have selected is too complex for your experience level doesn't help you to improve. You'll get there if your course was any good!
If you get an email telling you that you can catch Swine Flu from tinned pork then just delete it. It's Spam.
Start with simple examples (hello world, pyramid of stars, Magic square, open/write/close text files, ... ), do not try to do User Interface now, learn how to do simple console application; learn the basic input/output, logic and conditions, functions and all that.
The IDE confuses the basic concepts of programming making it very difficult to understand why something is happening. Don't use the IDE until after you can get simple logic problems solved at the command line.
Welcome to the dark side, where an odd sense of humor is a necessary tool of the trade.
Everyone else is correct, start simple, also creating an application for something that has meaning for you to hold your interest.
Visual Basic is a fine language to start with, there isn't that much difference between VB and C#. If you are getting paid to write in VB, you write VB.
It's a Ford vs. Chevy vs. Audi vs. BMW thing. Yes they all have different performance parameters and feature sets. Some people invest a lot into their choice, and defend their decision of choice, sometimes a little too aggressively.
I will re-iterate what Ennis said. Do not start with the IDE and trying to create a window's app. Start with a console window and a few simple things:
1. How to write "Hello World"
2. How to format a date
3. How to read an input
4. How to convert a string to a number and add two numbers
5. How to write and call a method (a static method!)
6. How to write and instantiate a class
7. How to call methods in a class
8. Learn about fields and properties of a class.
9. Learn about public/protected/private.
10. Learn about base classes and derived classes. Write a class that overrides a virtual method.
11. Learn about delegates.
12. Learn about events using delegates
13. Maybe, just maybe, you will be ready to then double click on a button in a form and write something useful in the button's event handler.
14. And then, throw out the "Microsoft IDE way" and learn about MVC and MVVM.
I'm not a very experienced developer and I didn't learn how to develop software at school either.
So my advice may not be too accurate, but then again... I know how you're feeling since I was feeling like that too exactly one year ago.
This was for me the epiphany that helped me tremendously: Try to think about a software project in layers.
I don't know anything about the project you're attempting to make, so the following is just an example of a common structure:
Database, Handler, Controller, Application layer.
Think of the Database as the bottom layer and the application layer as the top.
For each feature you create, start to work at the bottom and then work your way up.
You'll find it'll be a lot easier to figure out what to do next if you try to work in that order, especially at first. If you have to work on existing project, try to see if a similar structure is there (if not, then you're basically screwed).
Always respect the flow of data in your project, the role of your namespaces/classes; never make any exceptions to your own rules, unless the rules were wrong.
In this case: the Database stores and provides information, the handler controls database and puts data into objects to pass on to the controller, the controller handles all the logic and the application layer talks with the controller and only deals with how the interface looks like.
For the rest, you shouldn't worry too much about writing bad code when you're coding. You should worry a lot about it when you're not coding, but when you're coding you should make stuff happen and don't get paralysed.
Avoid copy pasting code and try to re-factor/reuse code instead. Finally, focus on the basic functionality first and worry about the details later.
Oh, and don't re-invent the wheel. Most of the stuff, if not all, you're trying to do has been done before and you have the Google machine at your disposal.
it's a personality thing.
either your personality maps to the job description or it doesn't.
quit while you are ahead, as my father would say, think that refers to gambling, but i am sure it pertains to your situation
it's not the "variety" of personalities -- it is likely they have two strong traits in common: analytical and problem solving oriented, i.e. like to fix things, find out how things work, seek to understand the "how" and the "why". Zen in on that for just a second.
In the “old days”, we started as “programmer trainees” and were expected to be “on-call” within 2 weeks; you had to go in for at least an hour when there was a problem and attempt to fix it before calling someone else for help. (And these were mission-critical systems).
You first did “maintenance” before being given development.
Ask a supervisor or co-worker for a small, non-critical, outstanding work request on an existing application and dive in (in your spare time, if necessary). You’ll be a lot more motivated than if you were writing trivial sample apps you have no real interest in.
(At this stage, you will need to present any changes you propose before implementing them and also submit to a code review later).
I would have to agree with this direction. While I have worked my way through the basics, at some point just creating example apps was extremely boring and not so fun. Getting your hands dirty in a big app with a small feature / fix required is a very good way to start figuring things out from within. (Analysis)
The example way is good to do at the same time as a way to get more exp, think on different problems and starting on design thinking I suppose. (Synthesis)
Keeping VB aside for a moment, you can take the free online 7-week long introductory Computer Science Course from Udacity (https://www.udacity.com/course/cs101[^]) to get your basic computer science concepts understood. This course is in Python language, though.
Back to VB, you can port snippets from that Python code to VB, and make them work. This way, you'll gradually become familiar with both programming concepts and their implementation.
I started my way to develop applications by taking an existing application and trying to rebuild it from scratch.
Don't try to recreate an application which is pure magic for you. Keep it simple and extend it with your own ideas (even if they don't have anything to do with the original application anymore)
- Take the basic functionality of the application and rebuild it by writing the code yourself.
- Add additional functionality
- Come up with ideas for ...
- ... writing/reading something to a file
- ... writing/reading something from database
- ... making your application configurable (file and/or database)
in my case it was the windows calculator
- I implemented the basic functionality like add, subtract, multiply, divide, etc.
- Added errorhandling via message boxes
- Added logging to file
- added a value store (calculator memory function) which saves values in a db
This helped my to getting a basic knowledge of the language and framework i was using.
For solving problems codeproject.com and stackoverflow.com are very nice sites to find explanations and solutions for specific problems. most of the time you can expect that the problme you've got already someone else has asked it and someone else has provided a solution for it. It is important that you try to break your problem down from the whole code to an isolated reproducable problem.
This helps yourself understanding what the problem really is and, if you can't come up with a solution yourself, others finding a solution for you (if your asking for help, of course)
Later when you understand the basic, step it up a notch and try what you can accomplish using interfaces, derivation and so on.
In my opinion, if you "have been been doing IT work for over 25 years (servers, networks, hardware, etc...)," then you are already a programmer on many levels. The skills of logical analysis, framing the problem to be solved, planning a solution in stages, step-by-step iteration and testing, and problem-solving, etc., you know in hardware will, I believe, transpose into programming.
While I think it is unfortunate that you are going to focus on VB.NET to learn programming, if that's the "currency" of the work environment you are in for the future, well, so be it. I say this not because I have any prejudice against VB.NET, but, because I think Microsoft truly created a mutant monster when they adapted VB6 to VB.NET, and the awkward and obscure syntax, and constructs, they added to the language to force it to fit into an object-oriented programming universe, is a spaghetti-verse of syntax that makes learning/using it much more difficult than, for example, C#.
For learning basic programming concepts, there is absolutely nothing wrong with using an IDE like Visual Studio ! Programming these days is about objects, and events, about classes, and sub-classes, about graphic user-interfaces, and database access. Programming, now, is about user-interfaces in which asynchronous events occur (the does user does anything at any time, depending on mode/context).
If you have a set of good introductory books, go through them step-by-step. Pose yourself small challenges, and implement them.
You like math problems: how about Project Euler as a source of a vast series of problems to solve (from simple to very complex) [^]. And, you have had other good resources recommended to you, here, by several people, like the course at MIT.
Consider asking the experts in your own company for their advice/thoughts on small projects to create on your own: if your goal is to become productive writing code in your company.
This thing we tell of can never be found by seeking, yet only seekers find it.
Abu Yazid Al-Bistami (Persian, Sufi, 804-872)
"I say this not because I have any prejudice against VB.NET, but, because I think Microsoft truly created a mutant monster when they adapted VB6 to VB.NET, and the awkward and obscure syntax, and constructs, they added to the language to force it to fit into an object-oriented programming universe, is a spaghetti-verse of syntax that makes learning/using it much more difficult than, for example, C#."
You are so far off the mark there your comment is laughable. VB.Net is a completely different beast to VB6 or VBA. Geez, its been ten years since VB.Net was released, when will people forget VB6 and move on from their noob like prejudices! VB.Net is OO from the ground up. It has more in common with C# than VB6!
I am a self taught VB developer. I learned basic programming concepts in high school in the 70's and learned Fortran in college in the early 80's.
I recommend this series of video tutorials if you are interested: