10 tricks for working more effectively in PowerPoint

PowerPoint is a powerful presentation package, but most of us don’t use it often enough to learn its many timesaving tricks. The good news is that you don’t have to be an expert to get more mileage out of PowerPoint features. Here’s a look as some of the shortcuts and tricks you can use to put PowerPoint to work for you.

Note: This information is also available as a PDF download.

#1: If you don’t like the design, pick another

You can build a presentation from scratch, but most of the time a design template is more than adequate. These templates apply consistent design and formatting attributes from the first slide to the last. Click the Slide Design button on the Formatting toolbar to open the Slide Design task pane to get started. (In PowerPoint 2007, choose a design template from the Design group.)

You’re not stuck with a design once you choose it. At any time, even after the presentation is complete, you can choose another design. Simply select the one you want; you won’t lose any content.

You can also change the design for only selected slides, without actually removing the template from your presentation. In the Slide pane or Slide Sorter View, select the thumbnails that represent the slides you want to change. Next, click on the drop-down arrow beside the desired design in the Apply A Design Template list and choose Apply To Selected Slides (Figure A). (There’s no drop-down arrow in PowerPoint 2007; just right-click on the design.) PowerPoint will immediately update the selected slides.

Figure A

#2: Hone for focus

Resist the urge to crowd as much text as you can onto a single slide. If a busy slide doesn’t overwhelm your audience, it will most certainly distract them. Instead of listening to you, they’ll read ahead.

Once you have a rough draft of your presentation, review it with the following goals in mind:

• Replace complete sentences with key words and phrases
• Get rid of unnecessary clip art
• Remove punctuation

By following these steps, you may reduce content by as much as half, and your presentation will be more focused.

#3: Don’t forget The end!

When you come to the end of your presentation, what comes next? If you click out of Slide Show View, your audience will get a behind-the-scenes peek at your work, and you probably want to avoid that. Instead, end your presentation with a slide that maintains the presentation’s master slide details but displays a simple message such as Thank you for your support or Thank you for coming.

Of course, the end slide doesn’t have to display a message. A blank slide might be adequate. You might even consider combining two end slides: Display a short thank you, or otherwise appropriate message, and follow it with a blank slide. That way, if you click out of the message slide, you’re still covered.

Professional presentations include a slide dedicated to ending the presentation. It protects you and cues your audience.

#4: Create your own AutoContent template

The AutoContent Wizard is a great place to start when you’re not sure what a presentation should cover. This wizard creates a new presentation using built-in templates, and you can customize the results.

What you might not know is that you can add an existing presentation to the AutoContent Wizard’s library. To do so, complete the following steps:

1. Launch the wizard by choosing New from the File menu.
2. Click the From AutoContent Wizard link in the New Presentation task pane.
3. Click Next in the wizard’s first pane.
4. Choose the most appropriate content template category and click Add (Figure B).
5. Locate your presentation file and click OK.
6. Quit the wizard.

At this point, the presentation you added is available to use as a content template. Don’t let a good, generic presentation go to waste. Most likely, you’ll have to customize it, but that’s true of any content template you choose.

The AutoContent Wizard isn’t available in PowerPoint 2007. Instead, use a themed template. Choose File from the Office menu and select New to get started.

Microsoft offers more free templates.

#5: Send a presentation to Word

PowerPoint can print views, but you can’t modify the results much. For instance, you can print handouts or even individual slides, but PowerPoint just prints a hard copy of your exact slides. If you want to enhance or format handouts, send the presentation to Word, which offers more flexibility. To do so, complete the following steps:

1. Choose Send To from the File menu.
2. Select Microsoft Office Word from the resulting submenu.
3. In the Send To Microsoft Office Word dialog (Figure C), choose one of the many send options. The Outline Only option sends only the content.
4. Click OK.

Figure C

Once your content is in Word, you can apply formatting and printing options that aren’t available to you in PowerPoint.

In PowerPoint 2007, you use the Publish command to send content to Word. Choose Publish from the Office menu and then choose Create Handouts In Microsoft Office Word.

When you do supply handouts, consider handing them out at the end of the presentation instead of at the beginning. Some people will pay more attention to your handouts than your presentation.

#6: Reverse those points

You probably know that you can display bullet points one at a time by choosing an animation scheme in the Slide Design task pane. Specifically, choose Fade In One By One from the Subtle section. What you might not know is that you can display bullet points in reverse order. The easiest way to reverse point order is to choose Show In Reverse in the Moderate section of the Animation Scheme task pane.

It’s a good idea to spend some time viewing all of the Animation Scheme options. It won’t take long, just a few minutes. Being familiar with all the effects is the key to using each appropriately. In addition, where animation is concerned, less is better than more — go easy and use animation only when you have a specific reason to and not just because you like a particular scheme.

You’ll find animation options on PowerPoint 2007’s Animations tab in the Animations group. Use the Animate drop-down list to choose the desired effect. The interesting advantage in 2007 is that as you choose an effect, PowerPoint displays it, so you can see it at work before you select it.

#7: Beware of busted GIFs

PowerPoint 2000 was the first version to support animated .gif files, but the viewer didn’t. (PowerPoint Viewer is a support application that lets others view your PowerPoint presentation, even if they don’t have PowerPoint installed locally.) Unfortunately, the older viewers don’t support .gif files. This limitation has the potential to spoil your otherwise flawless presentation.

The good news is that more recent viewers do support .gif files. In fact, they offer full-feature support all the way back to PowerPoint 97. If you’re still using an older version of PowerPoint — 97, 2000, or XP — the latest viewers will run your presentations, .gif’s and all. Microsoft offers a list of the different PowerPoint Viewer versions.

#8: Reverse slide print

Most printers allow you to print in reverse, but you can’t always get to individual printer options — especially with networked printers that are configured for all users by an administrator. If printing options are limited, you can still have PowerPoint print your slides in reverse order, with or without help from your printer:

1. Choose Print from the File menu. (In PowerPoint 2007, choose Print from the Office menu.)
2. Click the Slides option in the Print Range section.
3. Enter the range of slides in reverse order. For instance, if you want to print slides 1 through 10 in reverse order, enter 10-1 instead of 1-10. It’s an easy solution to implement.

PowerPoint will remember this setting until you change it or exit the presentation. Even if your printer has a reverse option available, you might find the PowerPoint route easier to take if you consistently print the same range of slides during the same work session, as your printer might not remember the setting.

#9: Reduce file size

PowerPoint files can be huge. If you send them via e-mail, you might find it takes a while to upload and download a presentation, especially if you or a recipient is still using a dial-up connection.

You probably use special software to compress the file before sending. You can also reduce the size of the original file by deleting the slide thumbnails. To do so:

1. Choose Properties from the File menu.
2. Click the Summary tab.
3. Locate the Save Preview Picture check box at the bottom of the dialog box (Figure D) , deselect it, and click OK.

Figure D

Doing this will save a huge hunk of KBs, even before you compress the file. If you disable the thumbnails, you can’t preview the file in the Open dialog box, but that seems like a small tradeoff for the KB savings.

This option is harder to find in PowerPoint 2007. From the Office menu, choose Prepare and then Properties. From the Document Properties drop-down list, choose Advanced Properties to find the Summary tab. You’ll still save some space, but not as much.

# 10: Control the pointer from the keyboard

During a slide show, PowerPoint hides the pointer five seconds after you display each slide, and then it disappears. When you click to view the next slide, the pointer becomes visible for another five seconds. You can control pointer display by clicking the icon in the bottom-left corner of the screen, but that’s a bit distracting in the middle of a presentation. Instead, consider controlling pointer visibility from the keyboard:

• Ctrl + H hides the pointer immediately.
• Ctrl + A displays the pointer immediately.

Once you use Ctrl + A to display the pointer, it’s fixed. There’s no five-second delay. You must use Ctrl + H if you want it to go away.

10+ Windows XP keyboard shortcuts to speed everyday tasks

How expansive is your repertoire of Windows XP keyboard shortcuts? A lot of users learn a handful of shortcuts but turn their backs on a host of other ones that could come in handy. Check out the selection of shortcuts below and see if there aren’t a couple you didn’t know about that could be saving you some real time.

You can also download a PDF that lists 50+ Windows XP shortcuts.

The shortcuts

Keystroke	Function
Alt + Tab	Switches between open programs
Alt + F4 (in a program)	Closes the program
Alt + F4 (from the desktop)	Opens the Windows Shutdown/Restart dialog box
Alt + Enter	Opens the Properties page of a selected item
Alt + Esc	Cycles between open programs in the order they were opened
Alt + Spacebar	In the active window, this brings up the corner dialog box for Move, Size, Minimize, Maximize, or Close
Shift + Insert a CD/DVD	Inserts a CD/DVD without triggering Autoplay or Autorun
Shift + Delete	Permanently deletes an item (rather than sending it to the Recycle Bin)
Ctrl + Shift + Esc	Opens the Windows Task Manager
Ctrl + drag an icon	Copies that item
Ctrl + Shift + drag an icon	Creates a shortcut for the item
Right-click + drag an icon	Brings up a menu to copy, move, or create a shortcut for the item
F1	Opens Windows XP Help
F2	Highlights the label of a selected item for renaming
F3	Opens Windows search for files and folders
F5 (or Ctrl + R)	Refreshes an Internet Explorer page or other window
F6	Cycles through the elements that can be selected in a screen or window
F10	Selects the menu bar in the active program (usually the File menu) so that you can use the arrow keys to navigate through the menus and the Enter key to display one
Shift + F10	Displays a shortcut menu for an item (like right-clicking with the mouse)
Ctrl + Esc	Opens the Start menu

Roll your own shortcut

You can also create custom Windows XP shortcuts. Just right-click on the icon of a program or program shortcut, choose Properties, click the Shortcut tab, and enter a keystroke combination in the Shortcut Key field. Windows will let you assign only key combos that aren’t already taken.

How your tech resume should differ from a general resume

Resume writing has almost become a science. There are a gazillion companies out there that exist only to help people create resumes that will garner interviews. While many of the standard resume suggestions work for any type of resume, there a few tweaks you’ll need to make in order to create a resume specifically for a position in IT. Here are some things to keep in mind when creating a tech resume:

1. You don’t have to stick with one page. Many sources will tell you a one-page resume is better, but that’s not necessarily true for a tech resume. For an IT position, you’ll need to showcase your technical skills as well as your customer-centric skills, so don’t be afraid to go to two pages. But try to keep it to two.
2. On the first page of your resume, include a summary of your qualifications. This is information not bound by dates of employment. You’re simply outlining your background and your general strengths.
3. Also on the first page, outline only your top qualifications. Focus on your familiarity with modern and emerging technology and don’t waste space on outmoded stuff. No hiring manager is going to care much about your expert knowledge of Windows NT.
4. Fill your online resume with lots of keywords. Hiring managers, in an effort to cut to the chase, may electronically search your resumes for the terms they’re looking for.
5. Run spell check but don’t trust it. Spell checking won’t flag correctly spelled words used incorrectly and may not catch tech terms and proper product names that are not part of the dictionary. For products, be sure to use the manufacturer’s spelling. Nothing kills your credibility faster than to say you’ve worked with a technology for years when that technology or acronym is incorrect on your resume.

The five worst things you can do in a meeting

Here are five meeting offenses that will not only drive your co-workers crazy, but will also damage your reputation within the workplace.

1. Show up late - Occasionally there is an emergency that crops up that forces you to go into a meeting a few minutes late. But usually the culprit is poor time management. Consistently arriving late implies to your manager and your co-worker that you are either extremely disorganized or don’t really respect the rules that everyone else follows.
2. Bring your cell phone - Again, there could be special circumstances that would require having a cell phone in a meeting, such as a call from a doctor or your child’s school. But if your cell goes off at every meeting and it’s just your spouse needing to know if you’ll pick up some Pudding Pops after work, shame on you. This behavior shows a lack of respect as well as a lack of commitment to your job.
3. Have a side conversation - Nothing rankles a meeting leader more than two people having a whispered conversation separate from the topic at hand.
4. Don’t focus - Believe it or not, I’ve been in meetings when attendees have leafed through clothing catalogs or balanced their checkbook while the leader is talking. Trying to multi-task in a somewhat dull meeting might be tempting, but it’s very rude. And don’t think people don’t notice.
5. Talk just to hear yourself speak - It may be your way of raising your office profile, but hogging much of the meeting spotlight with philosophical ramblings will not do it. Be brief and succinct. Meetings are for communication; they are not your personal stage.

10 things you should do if you make a big mistake

Note: This information is also available as a PDF download.

#1: If possible, come up with a plan to fix the problem

Don’t just walk away and wash your hands of the situation. True, other people might have to be involved in solving the problem. However, if you caused the problem, you are responsible for coming up with the plan to resolve it. The plan needs to address the actions that need to occur, the people who need to take them, and the amount of time you think the actions will take. The people involved most likely will be the boss, your co-workers, and any internal or external customers affected by the mistake.

#2: Come clean with your boss

Trying to cover things up rarely works. If and when your boss finds out, say, from someone else (worst of all from your boss’ boss), things will be even worse for you. In this kind of situation, it’s important that you be in control of the message. So as hard as it will be, you should summon up your strength, take a deep breath, and go talk to your boss.

#3: Let the boss know about that plan

In this situation, and in fact at any other time, never to go to the boss with just a problem. Go with a solution as well. In this case, go with the plan you developed and show the boss that, to at least some degree, you’re in control.

#4: Tell the affected parties

Let those affected by your mistake know what happened, but spare the technical details for now. Instead, focus on how the situation affects them: what limitations are in place, what functions are unavailable, and how long these limitations and lack of function are expected to last. Most important, offer any workarounds you can. Ask for their suggestions as well. If the mistake involves a system outage, perhaps some veteran techs can remember what they did in the old days, before that system was in place. If you have to and can do so, think about calling retirees for their ideas.

#5: Don’t blame others

You’re no longer in grade school. Trying to blame other people makes you look unprofessional, diminishing the opinion that others have of you. Conversely (and paradoxically), taking responsibility and admitting your mistake can win you respect. Your co-workers might end up thinking, “You know, even though [your name] messed up, it took a lot of character to admit it. [Your name] is a real stand-up person, and someone who can be counted on.”

#6: Stop looking back

Learning from the past can help prevent repeat mistakes. However, don’t confuse learning from the past with dwelling on the past. The latter involves endless self-recrimination and often self-pity, neither of which helps resolve the situation. If you find yourself dwelling on the mistake in this manner, stop it right now and read the next tip.

#7: Prepare and issue a “lessons learned” document

“Those who do not remember the past are doomed to repeat it.” “As a dog returns to its vomit, so a fool repeats his folly.” Maybe you’ve heard these or similar sayings. Their point is clear: We need to understand the mistake we made so that we can avoid it in the future. Documenting the mistake, and the steps taken to resolve it, are key in this regard. In doing so, be sure to cover the conditions that led to the mistake, the steps taken to correct it, and the measures taken to prevent its recurrence.

In my example of the bad SQL table, I ended up not only keeping my job, but I also kept my security officer user profile. However, we created a second user profile for me, one that lacked access to production data, which I was to use for testing and development work.

#8: Apologize to those affected

Mistakes often cost others in lost time and productivity and hence frustrate them. Consequently, even if you solve the problem, the people who were affected by it might still be upset if you never acknowledge that frustration. I’m not saying you have to be an Oprah or a Dr. Phil, but taking a second to apologize will go a long way toward restoring you to good graces. By doing so, you show you appreciate what they had to go through.

#9: Determine whether the mistake can occur elsewhere

This point relates to the “lessons learned” document. Here, however, you should consider other areas of the business, or other applications. To what extent do they have the same conditions, procedures, or people that could cause them to experience the same type of problem? You might want to alert those areas. They may answer that they have more competent staff, but that’s a risk you’ll have to take.

#10: Put the best face possible on what happened

Everyone focuses on the negative effects of a problem. There had to be some; otherwise, it wouldn’t have been a problem and wouldn’t have received such scrutiny. However, can you find any good things, no matter how small, that resulted from this problem? One of the most useful concepts I’ve learned is that of “reframing” the situation, that is, to change the way a person looks at it. In this case, reframing the problem might take the following form:

• Yes, a problem occurred.
• Yes, the system was unavailable.

BUT the good news is

• It happened during a slow time.
• It identified issues we need to address elsewhere in other systems.

Of course, in offering these arguments, it’s helpful if you can do so with a straight face.

The Do’s and Don’ts of successful interviewing

My comments are in brackets.

Do:

• Arrive on time.
• Greet the interviewer by name. [Not his or her first name though until you are issued the invitation.]
• Smile and shake hands firmly. [However, making a good impression is not dependent on how many knuckles you crush.]
• Look alert and interested at all times. [Turn off the cell phone and PDA. Somebody’s going to post in the discussion and ask who’d be stupid enough to leave those on in an interview. I’ve been a witness to it; they’re out there.]
• Speak firmly, clearly and loudly enough to be easily understood. [[A good suggestion but you just know someone reading it will go overboard, yelling and annunciating like a tourist in a foreign land.]
• Look the interviewer in the eye while speaking. [If you’re shy this can be hard to do, but it does help.]
• Structure your comments in a positive manner. [If you’re negative in a meeting in which you’re supposed to impress someone, what does that tell the interviewer about how you’ll be on the job?]

Don’t:

• Exhibit overbearing, overaggressive, or egotistical behavior. [You don’t have to be brash or smug to come across as self-confident.]
• Show a lack of interest or enthusiasm about the position or company. [Why even show up if you’re not interested?]
• Appear excessively nervous. [This is easier said than done if you are actually, well, nervous, as most of us are in interviews. Just try to take some deep breaths beforehand and prepare yourself for possible questions.]
• Overemphasize your compensation. [It was always a red flag to me as a manager when a job candidate asked what the salary was in the first 15 minutes.]
• Make excuses for unfavorable factors in your work history. [It’s tempting, I know. But taking responsibility for yourself is the mature thing to do.]
• Disparage past employers, managers, projects or technologies. [This would tell me that you’re going to do the same thing as an employee working for me.]
• Answer only “yes” or “no” to questions. [It’s pretty awkward when you ask what you think is a probing question and get only a one-word answer in return. Don’t rattle on and on but try to expound a little just to show the interviewer that the wheels up there are turning.]

What hiring managers hate about your resume

• Grammatical/spelling errors
  Too much information (or as GSG says, “I’m hiring you for a job. I don’t want to know about your 4 kids, that they are (in your opinion) little Einsteins, your dogs, your husband/wife, or your hobby of knitting little stocking caps for the poor little cold kittens.”)
• Information provided that the interviewer can’t legally ask for (marital status, age, religion)
• Unexplained date gaps in work experience
• An overstatement of technical skills
• Bad formatting (TiggerTwo hates “the failure to place the most important information in the top third of the page, lack of white space, a bunch of keywords that appear to exist only to be keywords, failure to provide a skills listing, use of less than 10 point font, and use of a difficult-to-read font.”)
• “If you can’t tell from the resume alone if the owner is enthusiastic about (some aspects of) his previous job experiences, the resume is out.”
• Not highlighting actual results delivered
• Overly long resumes. According to frostbite, “anything more than 2 pages is a hard read, more than 4 is a tome.”

10 tips for writing a job-winning developer resume

As seasoned job hunters know, the first step on the road to finding work is to write a resume that gets you the interview. Unfortunately, some of the traditional resume writing rules just do not work well in the software development industry. Here are 10 tips for writing a programmer resume that will increase your chances of getting the interview.

Note: This information is also available as a PDF download. For a more detailed look at this topic, see the blog post “Write a resume that will land you a programming job.”

#1: Provide a skills list up front

The hiring manager wants to know if you have the skills the company is looking for. An “experience” section gives managers a good idea of how much experience you have, but if you have a “skills” section at the top of the resume, their eyes go there first. Sure, you may be making it a bit easier for them to weed out your resume. But on the flip side, you might bring to their attention some skills they would otherwise overlook. At the very least, the hiring manager will appreciate the skills list.

#2: Make the experience interesting

Most developers on the market have written a data-driven Web site or desktop application. To give a bunch of examples of these on your resume is not impressive. What does impress a potential employer is experience that has something unique about it, showing you’ve done more than just “Hello World” level work. If you’ve been working under unique constraints or in environments with high levels of transactions or zero tolerance for failure, that looks very good to the person reading the resume. So show me how your experience is different, and I will see you as different.

#3: Root out grammar, spelling, and other common mistakes

Over the course of my time hiring, I have seen all sorts of grammar and spelling mistakes on resumes. One of the most embarrassing was when someone misspelled the name of the college he graduated from. Resumes do contain some unique grammatical conventions, and software development work in particular often revolves around acronyms or oddly spelled words. But that is really no excuse. Check your spelling and your grammar. This tip appears on just about every resume advice article I have ever read, but it clearly needs repeating.

#4: Education counts, but not for much

Unless you are just entering the job market for programming or are applying for a very specialized position, your education is not terribly important. Sure, you need to put it on your resume, but list it last, please. The hiring managers who need or want to know about it can find it, and the others won’t have to spend time on it. The world of programming changes often enough so that somewhere around seven years later, most schooling (except for “principles and theory” subjects, like mathematics or “pure” computer science) and certifications have little in common with the current working world reality.

#5: Get to the meat, quick

The traditional resume format includes a lot of information that’s just not needed, in the mind of the development manager. Your summary and possibly even the objective are two such sections. There really is no way to provide a summary that describes most programming pros in a way that is accurate, yet shorter than a resume itself. This is why most summary sections read like so much useless drivel: “Seasoned programmer with 10 years development,” followed by highlights of the skills section. Thanks, but no thanks.

The objective is often (but not always) just as useless. If you are looking for a change of pace, it offers a great way to keep the reader from pigeonholing you based on your skills and experience. The intermediate programmer looking to slide into a senior developer position can safely skip the objective. The senior programmer who wants to become a software architect or a DBA needs to state an objective. So avoid the summary at all costs, provide only useful objectives, and let the reader get to your skill set as quickly as possible.

#6: Formatting matters

The formatting of your resume is important. While the days of mailing resumes printed on premium stationery are long past, it is still a document that someone needs to read on a computer screen and on paper. That can be quite a balancing act, believe it or not. This is not the time to show off your inner Picasso, unless the position you are applying for is of a visually artistic nature. This is the time to enhance readability. That means using a larger font (10 to 12 points), a common font that all computers have (if your document format does not bundle fonts within it), and one that looks good both on the screen and off. My recommendations are Verdana, Arial, Tahoma, Calibri, and Helvetica.

Use enough whitespace so that the document does not seem too dense, which will turn readers off. At the same time, don’t waste so much space that it takes eight pages to print 200 words. Of course, the format of the file itself is important. My experience has been that 99.9% of the recruiters out there will ask for your resume in Microsoft Word format if you send it in any other format, so make sure that you can provide a document in the standard .doc format.

Always keep in mind that the resume is your primary tool for selling yourself. If readers can’t consume the information in it, whether due to technical issues or readability problems, they will quickly move on to the next resume.

#7: Be cautious with the length

Regardless of how your document is formatted, try to keep the length between two and four pages, unless there are extremely special circumstances. People who spend a lot of time doing short-term contract work can have longer resumes, and people just entering the job market can have shorter resumes.

Overall, it is tough to properly highlight your technical skills and more than one position in the traditional one-page resume format. Two pages should be the baseline for any intermediate or senior developer. But after about four pages, the reader’s eyes start to glaze over. Much like your education, the experience you had more than seven or eight years ago is not terribly relevant, but the hiring manager does like to see an arc of increasing responsibility or project difficulty.

#8: Properly document your history

Programming is not like most fields when it comes to employment history. For one thing, many programmers are contractors, which leads to an employment history that can look like a train. In addition, the dot-com bust is not too far behind us, and IT has always been an industry with a lot of bankruptcies, mergers, and acquisitions.

The problem is, no hiring manager likes to see a long list of short-term jobs. If your resume has a string of such jobs, with job titles that get bigger and bigger, you look like someone who has no loyalty. On the other hand, if the jobs seem basically the same (or worse, get lower on the totem pole), it makes the reader think that you may simply be unemployable. If you have a legitimate reason for the short-term jobs, make sure that the reason is obvious. For example, mark the contracting/consulting positions clearly.

#9: Don’t put the reader at legal risk

No hiring manager likes to be accused of prejudiced or discriminatory hiring. Not only is it unethical, but it is illegal. So hiring managers who are trying to do the job right will be familiar with the list of questions they can’t ask an applicant. Your part of the equation is to exclude this information from your resume. The hiring manager does not need to know your marital status, ethnicity, nation of origin, age, religion, or sexual orientation. There are a lot of other things the hiring manager does not need to know, either. If you include these irrelevant details on your resume, the hiring manager will feel scared and skittish. Leave these details out, please.

#10: “What a geek!”

In high school, you may have hated being called a geek. But today, you are trying to find work as a programmer. “Geek” is “gold” to hiring managers. Find a way to show them that you are smart, love programming, and are constantly growing, learning, and exploring new ideas. Talk about your relevant hobbies if you have any, like contributing to open source projects or volunteering to teach local kids programming. Let them know if you like programming or computers enough to deal with them outside of work.

It is a really simple equation for the hiring manager. While two candidates may be equal today, the candidate with passion will be far more advanced tomorrow than the candidate who treats it as “just a job.”

Real-life resume blunders

How bad of a mistake can you make on your resume? Here are some real
life examples from Dribbleglass.com:

• I am very detail-oreinted.
• My intensity and focus are at inordinately high levels, and my ability to complete projects on time is unspeakable.
• Thank you for your consideration. Hope to hear from you shorty!
• Enclosed is a ruff draft of my resume.
• It’s best for employers that I not work with people.
• Here are my qualifications for you to overlook.
• I am a quick leaner, dependable, and motivated.
• If this resume doesn’t blow your hat off, then please return it in the enclosed envelope.
• My fortune cookie said, “Your next interview will result in a job.” And I like your company in particular.
• I saw your ad on the information highway, and I came to a screeching halt.
• Insufficient writing skills, thought processes have slowed down some. If I am not one of the best, I will look for another opportunity.
• Please disregard the attached resume-it is terribly out of date.
• Seek challenges that test my mind and body, since the two are usually inseparable.
  Graduated in the top 66% of my class.
• Reason for leaving last job: The owner gave new meaning to the word paranoia. I prefer to elaborate privately.
• Previous experience: Self-employed-a fiasco.
• Exposure to German for two years, but many words are inappropriate for business.
• Experience: Watered, groomed, and fed the family dog for years.
• I am a rabid typist.
• I have a bachelorette degree in computers.
• Excellent memory; strong math aptitude; excellent memory; effective management skills; and very good at math.
• Strengths: Ability to meet deadlines while maintaining composer.
• I worked as a Corporate Lesion.
• Reason for leaving last job: Pushed aside so the vice president’s girlfriend could steal my job.
• Married, eight children. Prefer frequent travel.
• Objective: To have my skills and ethics challenged on a daily basis.
  Special skills: Thyping.
• My ruthlessness terrorized the competition and can sometimes offend.
• I can play well with others.
• Personal Goal: To hand-build a classic cottage from the ground up using my father-in-law.
• Objective: I want a base salary of $50-$60,000 dollars, not including bonus. And some decent benefits. Like a retirement plan, health insurance, personal or sick days.
• Experience: Provided correct answers to customers’ questions.
• Education: Graduated from predatory school with honors.
• Never been fired, although it could happen anytime now.
• I have happily been a “kept man” for the past 10 years.
• Have extensive experience in turkey manufactures as well as new product development and implementation.
• I am accustomed to speaking in front of all kinds of audiences. I make points as well as I can.
• Personal: Five children. Dog: Jasper. Cat: Morris. Gerbil: Binky.
• While in military, was instrumental in creation of a treat detection system.
• My compensation package at my last job included a base salary of $64,500 with excellent benefits including flextime. I am looking for a position in which I can work a more flexible schedule.
• Hire me and you won’t regret it-I am funny, cute, smart and creative… really.
• Referees available upon request.
• Previous rank: Senior instigator.
• I have recently sold my home and I now live in a large RV so I will be able to relocate quickly.
• Reason for leaving: They stopped paying me.
• Cover letter: Desire the chance to showcase my delightful personality, intelligence and superior judgment, which are so hard to find these days.
• Personal achievements: Successfully played “Chop Sticks” on a toy piano with my big toes.
• Objective: To obtain a position where I can make a difference, infecting others with my professionalism, enthusiasm and dedication.
• Strengths: Impersonal skills.
• Special interests: I like any projects that are fun.
• Please explain any breaks in your employment career: 15 minute coffee break while working at a home improvement store.
• Vocational plans: Sea World.

Write a resume that will land you a programming job

Put your skills front and center

Reading the in-depth details of how you used mainstream skill XYZ to accomplish typical task ABC is not at the top of my agenda. I want to see your skills up front, so I don’t need to go trolling through your resume to see if you meet my minimum needs.

Skip the summary and maybe even the objective

Those summaries are a waste of my time. It is going to say something like “seasoned IT pro with great communication skills” or “proven veteran with 10 years of programming experience.” How do I know this? Because they all say this. Skip it, please.

The objective is a slightly different story; it is useful only if it informs the interviewer about something that the skills and experience does not. The objective’s relevance to me is largely a function of whether you wish to keep doing what you have been doing. If I see you have been programming — particularly at the data access layer and the business object layer — and there is no objective, I am going to assume that you are looking for more of the same with a different employer or location. If you want to do more of that work and put an objective, you are wasting space. If you are looking for a change of pace — like getting more into the presentation layer or heading towards a management track — it’s important to state that in your resume. Otherwise, we may discover during the interview that you are not interested in what we have to offer.

List your education last

Some IT hiring managers put a huge emphasis on certain educations but I do not. I always want you to list your school and your major, but I will only ask you about your education if there is something unusual or intriguing.

For instance, a candidate with a Computer Science degree from MIT or with a PhD in Organic Chemistry will draw my eye because these degrees show a level of high intelligence. On the flipside, an AA in basket weaving or a lack of a degree will not count against you.

In most cases, I am not even curious about your education until I have already made up my mind. This includes certifications — MCSEs and CCNAs do not impress me that much at this point. They matter to some folks, and they do not hurt you in my opinion, but I will only take that certification into account if all else is equal.

Show me that you are different

Even if my project is a run-of-the-mill Web-based, data driven application (which it is not), I still want to see that you are more than someone with 10 years of experience writing run-of-the-mill Web-based, data driven applications. For example, compare these two items:

BORING!
East Coast Power - Programmer 1999 - 2005

• Wrote VB applications to control machinery. The hardware interface was handled in a COM library that was written by another team. Application was robust and reliable.
• Wrote Web-based tool to track system faults.
• Created Web service to allow partners to consume portions of the database.

WOW!
East Coast Power - Programmer 1999 - 2005

• Wrote VB applications to control nuclear reactor. Real-time control and monitoring of systems handling 10,000 unique data inputs per second.
• Wrote advanced algorithms in C# to detect imminent system failure, which were used within a Web-based application.
• Created Web service in C# to allow partners to access data in a secure, reliable, and responsive manner; typical data set was 1,000,000 rows and concurrency challenges needed to be overcome at the database and application layers.

See the difference? Control machinery does not help me much – you could have been working on the elevator system for all I know. Programming a nuclear reactor impresses me, especially since there has not been any nuclear reactor disasters during your employment. Writing advanced algorithms in C# touches my engineer’s heart; whereas writing a mere Web-based tool is ho hum. And, while writing a Web service is fairly simple, particularly in ASP.Net, it’s not so easy to write one that is “secure, reliable, and responsive” with that size of a data set. It’s also not easy to deal with concurrency issues at two different levels.

I am not saying that it needs to be wordy or full of minute details, but if you are doing work beyond what a summer intern could do, I need to know about it. Every developer has written a Web-based, data driven application. Show me more.

Make sure that your experience highlights your skills

I don’t expect your employment history to include a list of all your skills. But if you are looking for work as a .Net developer, show me that you have done some .Net work. If you do not list that experience, I am going to assume that you have little or no experience with it — even if it is on your skill list. If you have large amounts of experience outside of the workforce, find a way to show that on your resume.

Keep your resume between two to four pages long

I have struggled through seven-page resumes filled with jargon and boring details that made me want to cry. An overly long resume doesn’t necessarily make me rule out a candidate, but why make it hard on me?

On the other hand, a resume that tries to stick to the one page rule is not going to cut it for a technical person unless they are new to the field. In my experience, two to four pages is just right. Also, please use some whitespace, so I do not feel like I am drowning.

Watch your formatting

While technical pros’ resumes do not need to be pretty, formatting can make a huge difference in a resume’s readability. If you cannot put three pages of text in front of me in a readable form, do I really want you touching the UI or writing code that someone else might have to maintain?

I recommend that you stick to a larger font size (e.g., 10 - 12 pt.) in a font that reads well onscreen and in print (e.g., Verdana, Arial, Tahoma, Calibri, Helvetica). If you want a slightly fancier font, use it only for section headers. Also, do not mix Serif and Sans Serif fonts — that is just ugly. Do not use “Comic Sans” anywhere, especially in hot pink or baby blue (and yes, unfortunately, this needs to be stated). Keep your margins and space between paragraphs large enough to provide the reader some “breathing room.”

Employment history

I give applicants some slack on employment history. For instance, five year stints are fairly rare in IT, and I give anyone a lot of leeway if their history includes anything that occurred during the dot com boom/bust.

If you are (or were) a contractor or consultant, make sure that is clearly stated; otherwise, I will think that you get fired and/or quit every 3 - 12 months. If you were not a contractor or a consultant, and it looks like you have a hard time staying at a job, I am going to be very cautious. If I see an increasing progression of job titles, “mercenary” pops into my head. Also, if I see that they are lateral (or worse, negative) moves, “bad apple” is my first thought. Of course, sometimes you get hit with a string of employers that go under or get acquired — it happens to the best of us. If that is the case, find a way to convey that information so I don’t think you are unemployable.

Spelling and grammar

It is critical that the spelling and grammar in your resume is flawless. I have seen applicants misspell the name of their state and the name of their school. If grammar and spelling are not your forte, ask someone to look over your resume for you. While I understand that many IT pros are not native English language speakers (or are English language speakers who paid little attention to those subjects in school), you should still ask someone for help. In fact, knowing when to ask for help is a hallmark of the best developers. If I interview you and realize from your speech that you had the sense and humility to ask someone for help on your resume, I am going to be truly impressed. (For examples of what not to do, check out this list of real-life resume blunders.)

Stay out of EEO (Equal Employment Opportunity) territory

In the United States, companies with more than 10 employees need to follow EEO rules. These rules state that an employer cannot discriminate against or show preference for an employee based on certain group membership items or personal lifestyle issues, such as gender, age, ethnicity, nation of origin, religion, sexual orientation, and so on. So, do me a favor and try to not expose any EEO-related information to me on the resume. In a face-to-face interview or even a phone interview, some of it will be unavoidable. But I will never solicit that information. Not only do I want to keep my employer and myself out of trouble, but I personally feel that EEO is important. I can understand that many names (or even college attended) are strongly correlated with ethnicity, religion, or nation (or at least general geographic region) of origin, and college graduation or attendance dates give some age clues. Minimize this as much as possible. Please do not tell me about your church, your family situation, your home life, your parents, and so on. It is not that I am not interested — I would probably love to learn these things about you if we hire you — but I do not need or want to know them before that you come on board.

Outside interests, hobbies, achievements, and activities

I like to see these, but only if they are relevant. I really do not need to know about how big of a fan you are of the New York Knicks; but if you wrote a piece of software that can do something nifty with the team’s statistics for fun, I would love to know about it. People who contribute to open source projects get a huge gold star in my book, but only if I feel like they would be comfortable working on proprietary software with proprietary tools, and not bringing anything GPL’ed into my codebase. That is a small caveat there. “Contributed to project XYZ in the areas of ABC and DEF” is enough to whet my appetite. Show me some outside learning too — don’t let me think that you get home at 6;00 and shut off your brain. If this work is not interesting enough for you to read about or experiment with on your own time, why would I think that you will be engaged or even interested in the job we would hire you for?

Gracefully show your inner geek

Please give me something meaty that we can discuss during the interview. So, where it is relevant, try to show me how much of a nerd you are.

For instance, try to mention the hovercraft you made from an inner tube and a lawn mower engine. Make note of the iterative, evolutionary game theory system you coded in Lisp that proves that Nash’s equilibrium is dead wrong. Tell me something about your three chess championship victories. I do not want to know that you memorized UHF or that you have a pocket protectors collection that have logos of now defunct minicomputer vendors.

I know most of this falls under the previous section, but it is relevant. I love to work with programmers who love technology and logic and using their brains. People like that are simply better programmers. Why would I want to hire someone who is intellectually lazy for an intellectually challenging job?

Obscure or nonmainstream technologies

I am not hiring Lisp, Prolog, Erlang, APL, Scheme, Clipper, PowerBuilder, Delphi, Pascal, Perl, Ruby, Python (forgive me for including those four in this list), Fortran, Ada, Algol, PL/1, OCaml, F#, Spec#, Smalltalk, Logo, StarLogo, Haskell, ML, D, Cobra, B, or even COBOL (which is fairly mainstream) developers. If you show these on your resume, I will want to interview you just for the sake of slipping in a few questions about these items. I am serious. As part of my secret geekiness, I am really into obscure and almost obscure languages and technologies. I know that a lot of those items take better-than-industry-average intellect and experience to do; they also provide a set of experiences that gives their practitioners a great angle on problems. While you will never directly use those skills in my shop, you will be using those ways of thinking, and it will give us something to talk about on your first day.

(Aside: A coworker was shocked to learn that I played Half Life. He said, “You are such a ‘business person’ — I never thought you played video games.” I guess I’m camouflaging my secret geekiness too well!)

Good luck

I’ve given away crown jewels here. In my perspective, these tips will help any programmer write a perfect resume and get them an interview.

What do you think gets applicants an interview? If you read resumes as either a hiring manager, a recruiter, or an HR employee, what makes you say “wow!” or “ugh!” when you see it on paper?

Routing Algorithm

Routing Metrics

Routing tables contain information used by switching software to select the best route.

Routing algorithms have used many different metrics to determine the best route. Sophisticated routing algorithms can base route selection on multiple metrics, combining them in a single (hybrid) metric. All the following metrics have been used:

•Path length

•Reliability

•Delay

•Bandwidth

•Load

•Communication cost

Path length is the most common routing metric. Some routing protocols allow network administrators to assign arbitrary costs to each network link. In this case, path length is the sum of the costs associated with each link traversed. Other routing protocols define hop count, a metric that specifies the number of passes through internet working products, such as routers, that a packet must take en route from a source to a destination.

Reliability, in the context of routing algorithms, refers to the dependability (usually described in terms of the bit-error rate) of each network link. Some network links might go down more often than others. After a network fails, certain network links might be repaired more easily or more quickly than other links. Any reliability factors can be taken into account in the assignment of the reliability ratings, which are arbitrary numeric values usually assigned to network links by network administrators.

Routing delay refers to the length of time required to move a packet from source to destination through the internetwork. Delay depends on many factors, including the bandwidth of intermediate network links, the port queues at each router along the way, network congestion on all intermediate network links, and the physical distance to be traveled. Because delay is a conglomeration of several important variables, it is a common and useful metric.

Bandwidth refers to the available traffic capacity of a link. All other things being equal, a 10-Mbps Ethernet link would be preferable to a 64-kbps leased line. Although bandwidth is a rating of the maximum attainable throughput on a link, routes through links with greater bandwidth do not necessarily provide better routes than routes through slower links. For example, if a faster link is busier, the actual time required to send a packet to the destination could be greater.

Load refers to the degree to which a network resource, such as a router, is busy. Load can be calculated in a variety of ways, including CPU utilization and packets processed per second. Monitoring these parameters on a continual basis can be resource-intensive itself.

Communication cost is another important metric, especially because some companies may not care about performance as much as they care about operating expenditures. Although line delay may be longer, they will send packets over their own lines rather than through the public lines that cost money for usage time.

Polymorphism

Polymorphism means that the same thing can exist in two forms. This is an important characteristic of true object oriented design - which means that one could develop good OO design with data abstraction and inheritance, but the real power of object oriented design seems to surface when polymorphism is used.

In programming languages, polymorphism means that some code or operations or objects behave differently in different contexts.
For example, the + (plus) operator in C++:
4 + 5 <-- integer addition 3.14 + 2.0 <-- floating point addition s1 + "bar" <-- string concatenation! In C++, that type of polymorphism is called overloading.


Polymorphism

• Literal meaning - many forms
• OOP meaning
  - Same method (message) but different behavior
  - Object determines which method gets executed
• Function or Method Overloading
  - Similar message but different behavior
• Abstract interfaces to class hierarchies
  - Define core data and behavior capabilities of a class family
  - All classes in the family support core capabilities
  - All objects in family respond to core methods (messages)

A classic example is how area is calculated on different shapes. We define an abstact base class shape and derive two classes - rectangle and circle from it. An area() method defined in the base class will have to be implemented differently in rectangle and circle, since it has to be calculated differently.

This is an example of polymorphic behavior, and in C++, this is implemented using virtual member functions. The area() member function is defined virtual in the base class, which signals to the compiler that this member function has to be invoked from the correct derived class at run time. This is indeed a run time decision, and which derived class member function is to be invoked depends on which derived class pointer has been assigned to the base class pointer. This also brings in the concept of late binding (run time binding), since the above association to the area member function can only be done at run time. The compiler will have to insert extra code to do the late binding, which adds in a little runtime overhead.

Types of Polymorphism:
C++ provides three different types of polymorphism.
Virtual functions
Function name overloading
Operator overloading

In addition to the above three types of polymorphism, there exist other kinds of polymorphism:
run-time
compile-time
ad-hoc polymorphism
parametric polymorphism

Other types of polymorphism defined:
run-time:
The run-time polymorphism is implemented with inheritance and virtual functions.
compile-time:
The compile-time polymorphism is implemented with templates.
ad-hoc polymorphism:
If the range of actual types that can be used is finite and the combinations must be individually specified prior to use, this is called ad-hoc polymorphism.
parametric polymorphism:
If all code is written without mention of any specific type and thus can be used transparently with any number of new types it is called parametric polymorphism.

In general, there are two main categories of Polymorphism namely
Ad Hoc Polymorphism
Pure Polymorphism

Overloading concepts fall under the category of Ad Hoc Polymorphism and Virtual methods. Templates or parametric classes fall under the category of Pure Polymorphism.

Persistence

One of the most critical tasks that applications have to perform is to save and restore data. Whether it be a word processing application that saves documents to disk, a utility that remembers its configuration for next time, or a game that sets aside world domination for the night, the ability to store data and later retrieve it is a vital one. Without it, software would be little more effective that the typewriter - users would have to re-type the data to make further modifications once the application exits.

Therefore, an object that has the ability to store and remember values is often said to have persistence. For Example, the ability of your car radio to remember your list of favorite stations is often referred to as persistence.

It also can be defined as the property of an object by which its existence transcends time(i.e., the object continues to exist after its creator ceases to exists) and/or space (i.e., the object's locations moves from the address space in which it was created).

Hierarchy

In computer science's object-oriented programming, the mapped relationships of sub- and superclasses is known as a hierarchy. This can be visualized as an upside-down tree (or perhaps a pyramid), the top of which is known as the root.

The issue is more complicated with languages that support multiple inheritance, where hierarchy can be any directed acyclic graph.

Aggregation or Composition relationships in object-oriented design also form a hierarchy, composition hierarchy.

In object-oriented programming, a class is a template that defines the state and behavior common to objects of a certain kind. A class can be defined in terms of other classes. For example, a truck and a racing car are both examples of a car. Another example is a letter and a digit being both a single character that can be drawn on the screen.

In the latter example, the following terminology is used:

• The letter class is a subclass of the character class; (alternative names: child class and derived class)


• The character class is immediate superclass (or parent class) of the letter class;


• The letter class extends the character class.

The third formulation expresses that a subclass inherits state (instance variables) and behavior (methods) from its superclass(es). Letters and digits share the state (name, font, size, position) and behavior (draw, resize, ...) defined for single characters.

The purpose of a subclass is to extend existing state and behavior: a letter has a case (upper and lower case, say stored in the instance variable letterCase) and methods for changing the case (toUpperCase, toLowerCase) in addition to the state that it already has as a character.

However, a digit does not have a case, so the methods toUpperCase, toLowerCase do not belong on the common level of the Character class. There are methods that are special to the digit class. For instance, a digit may be constructed from an integer value between 0 and 9, and conversely, the integer value of a digit may be the result of say the intValue method.

In graphical terms, the above character example may look as follows:



The classes form a class hierarchy, or inheritance tree, which can be as deep as needed. For example, the letter class can have on its turn the subclasses vowel and consonant.




When a message is sent to an object, it is passed up the inheritance tree starting from the class of the receiving object until a definition is found for the method. This process is called upcasting. For instance, the method toString() is defined in the Object class. So every class automatically has this method.

In graphical terms, the inheritance tree and the message handling may look as follows:

A hierarchy is useful if there are several classes which are fundamentally similar to each other. In C++, a "base class" is a synonym for superclass and"derived class" is a synonym for subclass.

Messaging

"The process by which an object sends data to another object or asks the other object to invoke a method." Also known to some programming languages as interfacing.

The object's interface consists of a set of commands, each command performing a specific action. An object asks another object to perform an action by sending it a message. The requesting (sending) object is referred to as sender and the receiving object is referred to as receiver.




Control is given to the receiving object until it completes the command; control then returns to the sending object.

For example, a School object asks the Student object for its name by sending it a message asking for its name. The receiving Student object returns the name back to the sending object.



A message can also contain information the sending objects needs to pass to the reveiving object, called the argument in the message. A receiving object always returns a value back to the sending object. This returned value may or may not be useful to the sending object.

For example, the School object now wants to change the student's name. It does this by sending the Student object a message to set its name to a new name. The new address is passed as an argument in the message. In this case, the School object does not care about the return value from the message.



It is very common that a message will cause other messages to be sent, either to itself or to other objects, in order to complete its task. This is called sequential operation. Control will not return to the original sending object untill all other messages have been completed.

For example, in the following diagram, Object A sends a message to Object B. For Object B to process that message it sends a message to Object C.Likewise, Object C sends a mesage to Object D. Object D returns to Object C who then returns to Object B who returns to Object A. Control does not return to Object A until all the other messages have completed.

How do receiving objects interpret messages from the senders? How are the messages processed?
Each message has code that associated with it. When an object receives a message, code is excercuted. In other words, these messages determine an object's behavior and the code determines how the object carries out each message. The code that is associated with each message is called a method. The message name is also called the method name due to its close association with the method.
When an object receives a message, it determines what method is being requested and passes control to the method. An object has as many methods as it it takes to perform its designed actions.
Refer to the following diagram, name, name:, address and name:address are method names for the Student object. When the Student object receive the name message, the name message passes control to the name method defined in Student.

Fundamental Concepts - OOP

Object-oriented programming (OOP) is a programming paradigm that uses "objects" and their interactions to design applications and computer programs. It is based on several techniques, including inheritance, modularity, polymorphism, and encapsulation.


Class
A class defines the abstract characteristics of a thing (object), including the thing's characteristics (its attributes, fields or properties) and the thing's behaviors (the things it can do or methods or features). For example, the class Dog would consist of traits shared by all dogs, such as breed and fur color (characteristics), and the ability to bark (behavior). Classes provide modularity and structure in an object-oriented computer program. A class should typically be recognizable to a non-programmer familiar with the problem domain, meaning that the characteristics of the class should make sense in context. Also, the code for a class should be relatively self-contained. Collectively, the properties and methods defined by a class are called members.


Object
A particular instance of a class. The class of Dog defines all possible dogs by listing the characteristics and behaviors they can have; the object Lassie is one particular dog, with particular versions of the characteristics. A Dog has fur; Lassie has brown-and-white fur. In programmer jargon, the object Lassie is an instance of the Dog class. The set of values of the attributes of a particular object is called its state.The object consists of state and the behaviour that's defined in the object's class.


Method
An object's abilities. Lassie, being a Dog, has the ability to bark. So bark() is one of Lassie's methods. She may have other methods as well, for example sit() or eat(). Within the program, using a method should only affect one particular object; all Dogs can bark, but you need one particular dog to do the barking.


Message passing
"The process by which an object sends data to another object or asks the other object to invoke a method." Also known to some programming languages as interfacing


Inheritance
"Subclasses" are more specialized versions of a class, which inherit attributes and behaviors from their parent classes, and can introduce their own.
For example, the class Dog might have sub-classes called Collie, Chihuahua, and GoldenRetriever. In this case, Lassie would be an instance of the Collie subclass. Suppose the Dog class defines a method called bark() and a property called furColor. Each of its sub-classes (Collie, Chihuahua, and GoldenRetriever) will inherit these members, meaning that the programmer only needs to write the code for them once.
Each subclass can alter its inherited traits. For example, the Collie class might specify that the default furColor for a collie is brown-and-white. The Chihuahua subclass might specify that the bark() method produces a high-pitched by default. Subclasses can also add new members. The Chihuahua subclass could add a method called tremble(). So an individual chihuahua instance would use a high-pitched bark() from the Chihuahua subclass, which in turn inherited the usual bark() from Dog. The chihuahua object would also have the tremble() method, but Lassie would not, because she is a Collie, not a Chihuahua. In fact, inheritance is an "is-a" relationship: Lassie is a Collie. A Collie is a Dog. Thus, Lassie inherits the members of both Collies and Dogs.
Multiple inheritance is inheritance from more than one ancestor class, neither of these ancestors being an ancestor of the other. For example, independent classes could define Dogs and Cats, and a Chimera object could be created from these two which inherits all the (multiple) behavior of cats and dogs. This is not always supported, as it can be hard both to implement and to use well.



Encapsulation
Encapsulation conceals the functional details of a class from objects that send messages to it.
For example, the Dog class has a bark() method. The code for the bark() method defines exactly how a bark happens (e.g., by inhale() and then exhale(), at a particular pitch and volume). Timmy, Lassie's friend, however, does not need to know exactly how she barks. Encapsulation is achieved by specifying which classes may use the members of an object. The result is that each object exposes to any class a certain interface — those members accessible to that class. The reason for encapsulation is to prevent clients of an interface from depending on those parts of the implementation that are likely to change in future, thereby allowing those changes to be made more easily, that is, without changes to clients. For example, an interface can ensure that puppies can only be added to an object of the class Dog by code in that class. Members are often specified as public, protected or private, determining whether they are available to all classes, sub-classes or only the defining class. Some languages go further: Java uses the default access modifier to restrict access also to classes in the same package, C# and VB.NET reserve some members to classes in the same assembly using keywords internal (C#) or Friend (VB.NET), and Eiffel and C++ allows one to specify which classes may access any member.



Abstraction
Abstraction is simplifying complex reality by modeling classes appropriate to the problem, and working at the most appropriate level of inheritance for a given aspect of the problem.
For example, Lassie the Dog may be treated as a Dog much of the time, a Collie when necessary to access Collie-specific attributes or behaviors, and as an Animal (perhaps the parent class of Dog) when counting Timmy's pets.Abstraction is also achieved through Composition. For example, a class Car would be made up of an Engine, Gearbox, Steering objects, and many more components. To build the Car class, one does not need to know how the different components work internally, but only how to interface with them, i.e., send messages to them, receive messages from them, and perhaps make the different objects composing the class interact with each other.



Polymorphism
Polymorphism allows you to treat derived class members just like their parent class's members. More precisely, Polymorphism in object-oriented programming is the ability of objects belonging to different data types to respond to method calls of methods of the same name, each one according to an appropriate type-specific behavior. One method, or an operator such as +, -, or *, can be abstractly applied in many different situations. If a Dog is commanded to speak(), this may elicit a Bark. However, if a Pig is commanded to speak(), this may elicit an Oink. They both inherit speak() from Animal, but their derived class methods override the methods of the parent class; this is Overriding Polymorphism. Overloading Polymorphism is the use of one method signature, or one operator such as "+", to perform several different functions depending on the implementation. The "+" operator, for example, may be used to perform integer addition, float addition, list concatenation, or string concatenation. Any two subclasses of Number, such as Integer and Double, are expected to add together properly in an OOP language. The language must therefore overload the concatenation operator, "+", to work this way. This helps improve code readability. How this is implemented varies from language to language, but most OOP languages support at least some level of overloading polymorphism. Many OOP languages also support Parametric Polymorphism, where code is written without mention of any specific type and thus can be used transparently with any number of new types. Pointers are an example of a simple polymorphic routine that can be used with many different types of objects.



Not all of the above concepts are to be found in all object-oriented programming languages, and so object-oriented programming that uses classes is called sometimes class-based programming. In particular, prototype-based programming does not typically use classes. As a result, a significantly different yet analogous terminology is used to define the concepts of object and instance, although there are no objects in these languages.

Differences Between C and Java

If you are a C or C++ programmer, you should have found much of the syntax of Java--particularly at the level of operators and statements--to be familiar. Because Java and C are so similar in some ways, it is important for C and C++ programmers to understand where the similarities end. There are a number of important differences between C and Java, which are summarized in the following list:

No preprocessor

Java does not include a preprocessor and does not define any analogs of the #define, #include, and #ifdef directives. Constant definitions are replaced with staticfinal fields in Java. (See the java.lang.Math.PI field for an example.) Macro definitions are not available in Java, but advanced compiler technology and inlining has made them less useful. Java does not require an #include directive because Java has no header files. Java class files contain both the class API and the class implementation, and the compiler reads API information from class files as necessary. Java lacks any form of conditional compilation, but its cross-platform portability means that this feature is very rarely needed.

No global variables

Java defines a very clean namespace. Packages contain classes, classes contain fields and methods, and methods contain local variables. But there are no global variables in Java, and, thus, there is no possibility of namespace collisions among those variables.

Well-defined primitive type sizes

All the primitive types in Java have well-defined sizes. In C, the size of short, int, and long types is platform-dependent, which hampers portability.

No pointers

Java classes and arrays are reference types, and references to objects and arrays are akin to pointers in C. Unlike C pointers, however, references in Java are entirely opaque. There is no way to convert a reference to a primitive type, and a reference cannot be incremented or decremented. There is no address-of operator like &, dereference operator like * or −>, or sizeof operator. Pointers are a notorious source of bugs. Eliminating them simplifies the language and makes Java programs more robust and secure.

Garbage collection

The Java Virtual Machine performs garbage collection so that Java programmers do not have to explicitly manage the memory used by all objects and arrays. This feature eliminates another entire category of common bugs and all but eliminates memory leaks from Java programs.

No goto statement

Java doesn't support a goto statement. Use of goto except in certain well-defined circumstances is regarded as poor programming practice. Java adds exception handling and labeled break and continue statements to the flow-control statements offered by C. These are a good substitute for goto.

Variable declarations anywhere

C requires local variable declarations to be made at the beginning of a method or block, while Java allows them anywhere in a method or block. Many programmers prefer to keep all their variable declarations grouped together at the top of a method, however.

Forward references

The Java compiler is smarter than the C compiler, in that it allows methods to be invoked before they are defined. This eliminates the need to declare functions in a header file before defining them in a program file, as is done in C.

Method overloading

Java programs can define multiple methods with the same name, as long as the methods have different parameter lists.

No struct and union types

Java doesn't support C struct and union types. A Java class can be thought of as an enhanced struct, however.

No enumerated types

Java doesn't support the enum keyword used in C to define types that consist of fixed sets of named values. This is surprising for a strongly typed language like Java, but there are ways to simulate this feature with object constants.

No bitfields

Java doesn't support the (infrequently used) ability of C to specify the number of individual bits occupied by fields of a struct.

No typedef

Java doesn't support the typedef keyword used in C to define aliases for type names. Java's lack of pointers makes its type-naming scheme simpler and more consistent than C's, however, so many of the common uses of typedef are not really necessary in Java.

No method pointers

C allows you to store the address of a function in a variable and pass this function pointer to other functions. You cannot do this with Java methods, but you can often achieve similar results by passing an object that implements a particular interface. Also, a Java method can be represented and invoked through a java.lang.reflect.Method object.

No variable-length argument lists

Java doesn't allow you to define methods such as C's printf() that take a variable number of arguments. Method overloading allows you to simulate C varargs functions for simple cases, but there's no general replacement for this feature.

Differences Between Java and C/C++

• The Preprocessor
• Pointers
• Structures and Unions
• Functions
• Multiple Inheritance
• Strings
• The goto Statement
• Operator Overloading
• Automatic Coercions
• Variable Arguments
• Command-Line Arguments

It is no secret that the Java language is highly derived from the C and C++ languages. Because C++ is currently considered the language of choice for professional software developers, it's important to understand what aspects of C++ Java inherits. Of possibly even more importance are what aspects of C++ Java doesn't support. Because Java is an entirely new language, it was possible for the language architects to pick and choose which features from C++ to implement in Java and how.

The focus of this appendix is to point out the differences between Java and C++. If you are a C++ programmer, you will be able to appreciate the differences between Java and C++. Even if you don't have any C++ experience, you can gain some insight into the Java language by understanding what C++ discrepancies it clears up in its implementation. Because C++ backwardly supports C, many of the differences pointed out in this appendix refer to C++, but inherently apply to C as well.

The Preprocessor

All C/C++ compilers implement a stage of compilation known as the preprocessor. The C++ preprocessor basically performs an intelligent search and replace on identifiers that have been declared using the #define or #typedef directives. Although most advocates of C++ discourage the use of the preprocessor, which was inherited from C, it is still widely used by most C++ programmers. Most of the processor definitions in C++ are stored in header files, which complement the actual source code files.

The problem with the preprocessor approach is that it provides an easy way for programmers to inadvertently add unnecessary complexity to a program. What happens is that many programmers using the #define and #typedef directives end up inventing their own sublanguage within the confines of a particular project. This results in other programmers having to go through the header files and sort out all the #define and #typedef information to understand a program, which makes code maintenance and reuse almost impossible. An additional problem with the preprocessor approach is that it is weak when it comes to type checking and validation.

Java does not have a preprocessor. It provides similar functionality (#define, #typedef, and so on) to that provided by the C++ preprocessor, but with far more control. Constant data members are used in place of the #define directive, and class definitions are used in lieu of the #typedef directive. The result is that Java source code is much more consistent and easier to read than C++ source code. Additionally, Java programs don't use header files; the Java compiler builds class definitions directly from the source code files, which contain both class definitions and method implementations.

Pointers

Most developers agree that the misuse of pointers causes the majority of bugs in C/C++ programming. Put simply, when you have pointers, you have the ability to trash memory. C++ programmers regularly use complex pointer arithmetic to create and maintain dynamic data structures. In return, C++ programmers spend a lot of time hunting down complex bugs caused by their complex pointer arithmetic.

The Java language does not support pointers. Java provides similar functionality by making heavy use of references. Java passes all arrays and objects by reference. This approach prevents common errors due to pointer mismanagement. It also makes programming easier in a lot of ways simply because the correct usage of pointers is easily misunderstood by all but the most seasoned programmers.

You may be thinking that the lack of pointers in Java will keep you from being able to implement many data structures, such as dynamic arrays. The reality is that any pointer task can be carried out just as easily and more reliably with objects and arrays of objects. You then benefit from the security provided by the Java runtime system; it performs boundary checking on all array indexing operations.

Structures and Unions

There are three types of complex data types in C++: classes, structures, and unions. Java only implements one of these data types: classes. Java forces programmers to use classes when the functionality of structures and unions is desired. Although this sounds like more work for the programmer, it actually ends up being more consistent, because classes can imitate structures and unions with ease. The Java designers really wanted to keep the language simple, so it only made sense to eliminate aspects of the language that overlapped.

Functions

In C, code is organized into functions, which are global subroutines accessible to a program. C++ added classes and in doing so provided class methods, which are functions that are connected to classes. C++ class methods are very similar to Java class methods. However, because C++ still supports C, there is nothing discouraging C++ programmers from using functions. This results in a mixture of function and method use that makes for confusing programs.

Java has no functions. Being a purer object-oriented language than C++, Java forces programmers to bundle all routines into class methods. There is no limitation imposed by forcing programmers to use methods instead of functions. As a matter of fact, implementing routines as methods encourages programmers to organize code better. Keep in mind that strictly speaking there is nothing wrong with the procedural approach of using functions; it just doesn't mix well with the object-oriented paradigm that defines the core of Java.

Multiple Inheritance

Multiple inheritance is a feature of C++ that allows you to derive a class from multiple parent classes. Although multiple inheritance is indeed powerful, it is complicated to use correctly and causes many problems otherwise. It is also very complicated to implement from the compiler perspective.

Java takes the high road and provides no direct support for multiple inheritance. You can implement functionality similar to multiple inheritance by using interfaces in Java. Java interfaces provide object method descriptions but contain no implementations.

Strings

C and C++ have no built-in support for text strings. The standard technique adopted among C and C++ programmers is that of using null-terminated arrays of characters to represent strings.

In Java, strings are implemented as first class objects (String and StringBuffer), meaning that they are at the core of the Java language. Java's implementation of strings as objects provides several advantages:

• The manner in which you create strings and access the elements of strings is consistent across all strings on all systems
• Because the Java string classes are defined as part of the Java language and not part of some extraneous extension, Java strings function predictably every time
• The Java string classes perform extensive runtime checking, which helps eliminate troublesome runtime errors

The goto Statement

The dreaded goto statement is pretty much a relic these days even in C and C++, but it is technically a legal part of the languages. The goto statement has historically been cited as the cause for messy, impossible to understand, and sometimes even impossible to predict code known as "spaghetti code." The primary usage of the goto statement has merely been as a convenience to substitute not thinking through an alternative, more structured branching technique.

For all these reasons and more, Java does not provide a goto statement. The Java language specifies goto as a keyword, but its usage is not supported. I suppose the Java designers wanted to eliminate the possibility of even using goto as an identifier! Not including goto in the Java language simplifies the language and helps eliminate the option of writing messy code.

Operator Overloading

Operator overloading, which is considered a prominent feature in C++, is not supported in Java. Although roughly the same functionality can be implemented by classes in Java, the convenience of operator overloading is still missing. However, in defense of Java, operator overloading can sometimes get very tricky. No doubt the Java developers decided not to support operator overloading to keep the Java language as simple as possible.

Automatic Coercions

Automatic coercion refers to the implicit casting of data types that sometimes occurs in C and C++. For example, in C++ you can assign a float value to an int variable, which can result in a loss of information. Java does not support C++ style automatic coercions. In Java, if a coercion will result in a loss of data, you must always explicitly cast the data element to the new type.

Variable Arguments

C and C++ let you declare functions, such as printf, that take a variable number of arguments. Although this is a convenient feature, it is impossible for the compiler to thoroughly type check the arguments, which means problems can arise at runtime without you knowing. Again Java takes the high road and doesn't support variable arguments at all.

Command-Line Arguments

The command-line arguments passed from the system into a Java program differ in a couple of ways from the command-line arguments passed into a C++ program. First, the number of parameters passed differs between the two languages. In C and C++, the system passes two arguments to a program: argc and argv. argc specifies the number of arguments stored in argv. argv is a pointer to an array of characters containing the actual arguments. In Java, the system passes a single value to a program: args. args is an array of Strings that contains the command-line arguments. In C and C++, the command-line arguments passed into a program include the name used to invoke the program. This name always appears as the first argument and is rarely ever used. In Java, you already know the name of the program because it is the same name as the class, so there is no need to pass this information as a command-line argument. Therefore, the Java runtime system only passes the arguments following the name that invoked the program.