Monday, July 17, 2000

Developer Career Tip #0007---Interview the Interviewer

Developer Career Tips #0007

Interview the Interviewer

In my last article, I talked about the importance of asking a question (or more) during a job interview to let the interviewer know that you are capable of more than just answering questions and that you have a genuine interest in the company.

Don't allow the interview to become a one-way piece of communication where the interviewer learns everything necessary to make a decision as to whether or not you are what the company needs and wants, but you learn nothing about the company to make the same decision. Too many job candidates find themselves interviewing for a programming position, receiving an offer and then finding themselves in a position they don't like.

How can you avoid this?

Be prepared to get the answers to the questions you'll have the first day or first week of your new job---you don't want to wait until then to find out.

I'm not talking about fundamental questions such as salary, work hours, vacation time and other benefits---these are likely to be part of a standard package provided to you prior to the interview.

I'm talking about questions such as:

What type of work will I be doing?
Will I be programming?
If so, will it be new development, or maintenance of existing code?
If code maintenance, is the original author still with the company?
What language or languages will I be writing?
Will I be working as part of a team?
If so, what are the skill levels of my team members?
How many years with the company do my team members have?
Who will be my supervisor?
How many years with the company does he or she have?

While these are questions to which you can easily obtain answers on your first day on the job, by then it may be too late--particularly if you've left a previous position to obtain that long awaited developer's job, only to find out you'll be manning a Help Desk for the next 6 months until the company signs a big contract.

Of course, you may not be in a position to be picky---if you are a candidate just trying to get your foot in the door, any job offer may be a good one.

Next time: An innovative approach to getting your foot in the door

Monday, July 10, 2000

Programming Tips & Tricks #0006---Named Visual Basic Arguments

Tips & Tricks #0006

Named Visual Basic Arguments

One of the themes I emphasize in my computer classes over and over again is the importance of writing code that is readable---that is, code that other programmers and developers will be able to understand, and if necessary, easily modify in the future. Some obvious ways to write readable code include the use of program comments in your code---no matter what the language you are using to develop your program, all major languages provide for comments. Something else that can make your Visual Basic more readable is the user of Named Arguments.

Let me illustrate by executing the Visual Basic MsgBox Function to display a Windows Message Box. The Visual Basic MsgBox function has one required argument (Prompt), and four optional arguments (Buttons, Title, HelpFile and Context).

MsgBox “I love Visual Basic”

By default, this code will display a Message Box with a single command button captioned OK, with the text “I love Visual Basic”, and the Visual Basic Project name displayed in the Title Bar of the Message Box.

Suppose I’m not happy with the default Title in the Message Box, and I decide I want to customize it. Doing this is easy—all I need to do is supply the Title argument to the MsgBox function. However, since Title is the third argument, I either need to supply the second argument---Buttons, which is by default presumed to be the value vbOKOnly---or provide a ‘comma placeholder’, like this.

MsgBox “I love Visual Basic”,, “SearchVB.Com”

Notice the two commas back-to-back, with no value in-between. This is the ‘comma placeholder’ and is how we tell VB that although we have a value for the third argument, we have no explicit value for the second argument.

When we execute this code, we’ll see a Message Box that reads “I love Visual Basic”, and that has “SearchVB.Com” for its Title Bar.

Named Arguments can make passing optional arguments easier—and make your code infinitely easier to read and modify. For instance, the code we wrote above can be re-written to this using Named Arguments.

MsgBox Prompt:="I love Visual Basic", Title:="SearchVB.Com"

With Named Arguments, we specify the name of the argument, followed by a colon and equals sign (:=), then the value for the argument. By using Named Arguments, we don’t need to provide a ‘comma placeholder’ for the second argument Buttons. Since we are naming the argument, VB knows that ‘SearchVB.Com’ is the value for the Optional Argument ‘Title’. And since we name the arguments, being able to read and understand the code in the future is much easier.

Monday, July 3, 2000

Developer Career Tip #0006---Interview Tip #1---Be sure to ask a question!

Developer Career Tips #0006

Interview Tip #1---Be sure to ask a question!

I'm frequently asked, by my readers and students strategies for answering questions during a job interview. There's no doubt that your ability to 'show your stuff' during a job interview is crucial to landing a programming job.

I'll be covering strategies for answering questions in future articles, but today I want to discuss what I think plagues more job candidates than any other single issue--failing to ask a question during the interview.

Not only do I teach and write books, I also own my own consulting firm, and although I do most of my own work, on occasion I do hire someone to help out during busy periods---usually from a pool of candidate students provided to me by my University's Co-Operative Education program.

These students are highly recommended by the Chairman of the Computer Science Department, extremely motivated, and choosing among two or three candidates can be very difficult.

So how do I make my choice?

That's easy---I pick the candidate who asks me the best questions!

Asks questions? Isn't it the interviewer who should be asking the questions, not the job candidate?

Many job seekers are of the mistaken impression that the role of the candidate is to answer questions during the interview. From the interviewer's perspective, however, you can't imagine the poor image that is conveyed of a job candidate who sits through the interview, and politely (and quite skillfully) answers each and every question, and then when asked if they have any questions, simply say 'no' as if they are anxious to leave!

Taking the time to ask a question or two during the interview shows the interviewer that you are enthusiastic and genuinely interested in the position and the company, and that you can not only answer questions posed of you but that you can initiate and carry on a conversation (a skill that is crucial when talking with end users). In short, taking the time to ask a question or two can land you the job!

Another benefit is that it gives you the chance to seek clarification on the job itself, the types of duties that will be required of you, and to learn more about the company and the people with whom you will work. These are questions to which you want answers before you show up for work the first day.

Next time: Questions to ask before saying "Yes, I'll take the job"

Monday, June 26, 2000

Programming Tips & Tricks #0005---With...EndWith in VB

Tips & Tricks #0005

In my consulting practice, I frequently see examples of Visual Basic code that could be improved upon, either from a readability point of view or from an efficiency point of view. Today I'd like to discuss a relatively new Visual Basic construct that can improve both the readability and efficiency of your code---and save you quite a few keystrokes in the process. That construct is the With…End With statement.

The With…End With statement allows you to 'bundle' Property and Method calls to a single object within the With…End With block. For instance, here's some code that sets the properties of a Command Button, and then executes its Move Method.

Private Sub Form_Load()
Command1.Caption = "OK"
Command1.Visible = True
Command1.Top = 200
Command1.Left = 5000
Command1.Enabled = True
Command1.Move 1000,1000
End Sub

By using the With…End With statement, we can eliminate quite a few programmer keystrokes, and make the code a bit more readable in the process---like this…

Private Sub Form_Load()
With Command1
.Caption = "OK"
.Visible = True
.Top = 200
.Left = 5000
.Enabled = True
.Move 1000,1000
End With
End Sub

Not only have we reduced the number of keystrokes in the procedure, but using the With…End With construct produces more efficient code.

Each reference to an object's property or method requires a Registry 'look up' to execute the code statement---by using the With…End With statement, VB is able to 'pool' this lookup into a single Input Output operation---thereby making your program run faster.

The bottom line---whenever you find yourself coding multiple operations against an Object, use the With…End With statement.

Monday, June 19, 2000

Developer Career Tip #0005---Learning Visual Basic---Part 3

Developer Career Tip #0005

Learning Visual Basic---Part 3

In my last two articles, I dealt with ways to learn a new programming language, including taking official Microsoft Curriculum courses at a Microsoft Certified Technical Education Center (CTEC), long term training at a computer programming school or institute, or enrolling in a course at a local colleges or university. All of these options have one thing in common: you need to be present at a predetermined time and place for a specific duration in a classroom led by an instructor. In today's article, I want to discuss an interesting alternative to classroom based training---web based learning.

I've taught programming for 20 years, and up until three years ago, all of it had been via the traditional route of instructor led classroom training. When I was initially approached to teach a web based programming course in Visual Basic (I teach for SmartPlanet and ElementK), I must confess I had my doubts, but within two weeks of beginning the course, I was amazed that not only could web based learning be just as good as traditional classroom based training, but in many ways it was far superior.

From a student's perspective, web based training can solve a myriad of logistical problems. Most web based training is message board based---which means that there's no formal meeting time. Students log in, obtain the week's assignment (usually a reading assignment), and then use the message board to ask questions, and check back later for answers.

For students whose work or personal commitments prevent them from traveling to formal classroom training, web based training permits them to sign into the 'classroom' whenever their schedules permit. Also, many web based programs are self paced, which means you can speed up or slow down the pace of your learning as your schedule demands. And for some students, perhaps the greatest benefit of web based training is that it's typically a fraction of the cost of formal classroom training.

From an instructor's point of view, I was amazed how web based training solved some of the problems I see in my traditional classes. For instance, since there is no formal lecture mode via the Internet, a higher percentage of students actually read the assigned material, since they can't rely on picking up the material in a lecture period. Secondly, since questions and answers are posted publicly on the message board, just about everybody in the class obtains the benefit of the questions that are posed and the answers that I give. Unfortunately, in a traditional classroom setting, students do not always pay attention to the questions others pose, nor listen to the answers.

Monday, June 12, 2000

Programming Tips & Tricks #0004---Printing the contents of your VB project

Tips & Tricks #0004

I recently received an email from a reader who wanted to print the contents of his Visual Basic project to a file.

For those of you not familiar with this Print feature of Visual Basic, you can print an image of any or all of the forms in your Visual Basic project, plus the code in those forms, to a printer for documentation purposes.

In addition to printing directly to a printer, you can also route the print to a text file---either for archive purposes or for subsequent printing.

The problem is that when my reader tried to view the output file using his Notepad Editor, he reported seeing strange characters at the top of the document, and when he printed the file from within Notepad, the results were far from satisfactory.

What causes this is that when he directed the print output to a file, his Windows default printer was set to a high tech model (either a laser or an ink jet printer). The strange characters included in the document were printer control characters that Windows inserted into the file---the same characters that Windows would have sent to the default printer to ensure that the document printed properly..

Fortunately, the fix is easy.

To produce a file that can then be opened cleanly in an editor such as Notepad, you must first install a Generic-Text Only Printer driver on your system (You can do this by Adding a Generic-Text Only Printer via the Windows Print Manager), and then selecting this Printer as the target printer in the VB Printer Dialog Box.

The result is that your output file will contain only text---no special Printer Control Characters.

Monday, June 5, 2000

Developer Career Tip #0004---Learning Visual Basic---Part 2

Developer Career Tips #0004

Learning Visual Basic---Part 2

This is a continuation of my previous article, in which I answered the question, how to learn a new programming language. In that article, I stated that the answer to that question depends on many factors: Do you already know a programming language? How much time do you have to learn one? How do you learn best?

Last time, I described CTEC's (Certified Technical Education Centers), and pointed out these may not be everyone--in fact, they may be a good choice if you already know the programming language you are there to learn!

Are there other alternatives?

Yes, there are plenty.

For instance, there are computer schools that, with programs of varying lengths, turn out graduates that are employable to some degree or other. In my area, schools such as the Computer Learning Center and the Chubb Institute have programs that range from 3 months to a year and teach a variety of programming languages and PC skills. The advantage of a program like this is that you are spending a lot of quality time learning the language. When you are finished, you know it well. The disadvantages are time and cost. You might spend 3 full months, 8 hours or so per day, 5 days per week, learning the language. If you are already employed, this is not a viable alternative, although most of these schools do offer evening hours. Another disadvantage is cost---these schools are not cheap.

A quicker, cheaper alternative are the Professional Development or Certificate programs that many College and Universities are now offering. I teach in such a program myself, and I think they're ideal. For instance, my Visual Basic course meets one time per week, 3 hours per session, for 10 weeks. The amount of classroom time is just about the same as a CTEC, but spaced out more. This permits the students to learn more on their own, spending time in between meetings reading the textbook (and it's an excellent one), doing exercises, and working on a class project.

This one time per week session is less encompassing than a Computer School--but it's also cheaper, and is a good choice for those already employed.

Next time---Online learning alternatives