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.
Great web site. Love the info and suggestions I can get here.
So, I have been doing IT work for over 25 years (servers, networks, hardware, etc...) and never delved into the development field. I now have the opportunity to learn writing and modifying code, but I am having a hard time making this logic click.
I have several beginner books on Visual Studio (2005,2010,2012)and have done the training classes offered by a local business.
I am focusing on Visual Basic as my language of choice because the company I work for uses this only.
Any suggestions on how I can make all this info click?
I understand the concepts, but just could not write the code behind a app i lay out in VS Designer to save my life.
Thanks all for the great advice. I sort of suspected I was trying to bite off more than I could chew.
Going to go back simple and work my way up.
Learning Visual Basic will tar you as a n00b forever, and firmly establish a reputation that will be very difficult to get out of. If you are going to learn a CLR language, C# might be a better choice. And if you want to expand your horizons beyond Microsoft, java might be the one.
haha...maybe a Old n00b...
I have read that once you have a language down, it makes learning other languages easier. Vb and VB.Net are what our dev guy uses here, so I need to get this to assist. C# is on my list as well as Java for personal enrichment.
Any suggestions on a n00b learning C# and Java (as well as VB)? Don't seem to have a issue with the tools to design apps, just making it do what I want.
I have read that once you have a language down, it makes learning other languages easier...
This is indeed true to a certain extent. I know about 100 computer languages, and at least in the early days, it was all really just syntax. I was usually able to learn a new language by reading the language reference. There were several exceptions to this (assembly, APL, C). Nowadays that is not quite so true.
What is more important to grasp is the concepts and programming paradigms involved: [assembly], object oriented programming, functional programming, web, templates, lambdas, ...
Next to that is frameworks and environment: MFC, WTL, CLR, unix/linux, ...
Each of these is a separate skill, and shifting from one language to another is a much smaller step if you understand the paradigms involved.
If you are good with one assembly language, you will not have much trouble with another.
Group all kinds of programing languages by their closeness to the hardware and their generations (also roughly equivalent to the prevailing programing model) and you get an accurate impression of how small or big the step from one to another may be.
And in the end they all produce just a lot of bytes that the processor will try to execute as instructions.
at least in the early days, it was all really just syntax.
I am experiencing something like this right now. I know about 3 or more languages (depends on what you consider 'knowing' a language). I was given a test in a language I had never attempted to learn before. I had to fix 3 bugs. The first was just strings that are really dates being sorted alphabetically like "1-Feb-2012" coming before "1-Jan-2012". I had to make it sort chronologically. I got the syntax down, found out how the date types work, and I fixed it. The other 2 bugs had nothing to do with the main code language they were using. The template system they use needed to be modified for the second bug. The third bug involved changing an oracle database table to include two more columns, and having their build scripts and code generation tools pick up these two extra values. I fixed 2 out of 3. I felt awesome when I made that brand new language do what I wanted, and then stupid for not knowing nearly enough about the other components that drive their application. I am on a mission now to learn these things, and what you just said really hit home.
A large part of learning a .Net language is learning the framework, Visual Studio, OO concepts and design patterns eg MVC. Somebody who is a competant VB.Net developer won't have much trouble picking up C# - same framework, same IDE, same OO concepts baked in. The difference is mainly down to syntax. Hence why there are websites offering VB.Net to C# converters and visa-versa!
Of course you will be noob, only because you program on language without ";".
VB.Net and Csharp are 97% like same, only compiler AST are different, in most cases, IL generated are same.
Even in new framework, the compiler will be the same.
Dammit, I tripped into one of these traps fo non-native english speakers
No, I thought something where you can manage contacts (real people, not electronic contacts).
Every contact has a surname, last name, street name & number, postal code, phone number and email address.
Creating, editing, deleting and displaying them should be a good start. Afterwards he can add the possibility to save them when the application is closed and load them when the app is started and learns about file handling this way.
It is possible that Swiss ladies don't start running away and screaming for help when you approach them with scissors (or a large knife) and an evil glint in your eye, but British ones will either scream and run, or kick you where the pain starts...and IIRC aren't all Swiss tooled up?
An App would be a lot safer!
If you get an email telling you that you can catch Swine Flu from tinned pork then just delete it. It's Spam.
We are. But there is a set of different tools, see details here[^].
It is possible that Swiss ladies don't start running away and screaming for help when you approach them with scissors (or a large knife)
A colleague of mine stated it this way: Talk to her, hit her really hard and use the moment of surprise to put the chloroformed handkerchief on her mouth until she does not move anymore.
I want to state clearly that a colleague of mine said this. I prefer to get women by good-looking and a nice personality . They stay longer with me than they would do with him (The a dress app is a good idea anyways) .
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: