Algorithms are clear
Here's the beautiful thing about algorithms: The problem space they deal with is well-defined, i.e. your requirements are not only actually known, but usually even formalized much like the metrics for the solution's quality.
So if I tell you to come up with an algorithm, there isn't much potential for communication problems, and measuring your performance is a trivial task. At the same time your performance is a fairly good indicator for your ability to think logically.
Algorithms are an efficient filter
The current problem of the industry (and the education) is the poor average quality of graduates. This has been illustrated with the FizzBuzz test, which is:
Write a program, that will go through the numbers from 1 to 100 and
will print "fizz" if the number is divisible by 3, "buzz" if it is
divisible by 5 and the number itself if it is divisible by neither.
Apparently, the majority of all Comp Sci graduates fail to solve this problem. Please note that this is an algorithmic question, although of course an embarrassingly simple one. Given this, getting someone who can solve the kind of problems given in Google Code Jam or Project Euler, you're already enjoying the crème-de-la-crème.
Algorithms are a tiny part of software development
The truth is, as soon as you work in the industry, you will not be using your algorithm skills more than 1% of the time.
Before you even start writing code, you must first gather and analyze requirements. Then you must synthesize your design based on them. Then you must implement the design. Then you must evaluate the implementation against the original requirements, then iterate the requirements, then iterate the design, then iterate the implementation and so on.
One of the requirements is sensible performance. If that requirement is not met, you must profile your implementation to track down the bottlenecks and then you can optimize it, which sometimes is a matter of straight forward micro-optimization (which is rather easy to do), but sometimes is a matter of using better algorithms (which is not always easily done afterwards). Therefore:
Algorithms are critical
The better your grasp of algorithms, the bigger is the chance that you get it right the first time. Otherwise, you're not only likely to run into a problem that can only be solved by implementing a better algorithm, but also you will be unable to actually solve it.
So while you almost never need this skill, it presents a single point of failure in your development methodology and if you don't have the skill, you can only hope that the necessity never arises, or that someone else jumps in to fix it for you.
What is really important is to get a feeling for computational complexity and how to keep it low, as I also explained in response to a similar question. Or to specialize in things where this simply isn't important, such as GUI development, but then again almost everybody hates it ... for a reason!
It is not bad practice to use GUI designer to design your forms, GUI. Esp in Visual Studio. They are there for this purpose and are extensively used.
In web development, it is a different story. It is a bad practice to use GUI designer (for example Microsoft Front Page now superseded by WebMatrix). The reason
- They provide a lot of extra code that you do not really need. They basically create junk.
- They increase the size of the html document. Which is HIGHLY undesirable for high end site which a large number of hits.
- They are hard to maintain because of a lot of extra junk code
So as far as your question, it is not bad practice to use GUI in design forms esp in Visual Studio. Not at all.
Best Answer
In theory, there are at least five possible approaches.
Top-Down:
Start with UI mock-shots or a paper prototype. Turn them into real dialogs, and work your way from the button handlers and other controls down through the logic and to the database.
Bottom-Up:
Start with the data structures (probably the database schema). Then add logic (modelling real-world processes); finally, your UI is just an interface to trigger the logic and display the results.
Logic first:
Start with the program logic, implementing data access and a rudimentary UI as needed. Then formalize and harden the data structures, and finally flesh out the UI properly.
Meet in the middle:
Start with database schema and UI, and simultaneously work towards the point where they meet. With this approach, the logic comes last.
Horizontal expansion:
Start by identifying the absolute minimum amount of functionality that would do something interesting, and implement the whole stack (data structures, logic, and UI) for this part. It could be just a basic CRUD cycle with a simple edit dialog for just one entity. Then start adding more features, implementing the whole stack for each feature (hence 'horizontal').
Each of these has pros and cons.
Top-down gives you something visible early in the process, and allows you to check your functional design with stakeholders - mock-shots often tell users more about a design than flowcharts or walls of text.
Bottom-up gives you a chance to design a rock-solid database schema before you commit to anything; since a database schema is notoriously hard to modify once released, you want to get this part right - the impact of modifying a UI is much smaller and produces fewer and less severe bugs.
Logic-first means you can test the logic before spending serious time on the database and the presentation, which is especially interesting if your logic is going to be really complex.
Meet-in-the-middle combines the advantages of bottom-up and top-down, but you'll have to jump back and forth between two tasks, and you risk ending up with logic that is more complex than necessary because your two ends don't meet naturally.
Horizontal expansion goes well with an iterative workflow, and it has the added advantage that, if you prioritize well, you will have a working application at any given time, so if you don't make a deadline, you will have a version that has fewer features, but is still fully functional, as opposed to a version that has a complete database, but no UI at all.
So which one you choose depends on your personal style, and on the circumstances.