10 things you should never do on your resume

The resume offers an at-a-glance view of your past and present. If you want to get your foot in the door, be sure you avoid these missteps.

By Jack Wallen

What is your resume? A hassle you must undergo to walk into an interview with any hope of getting hired? Or is it a history of your professional life—ready to be shared with others to make lasting, career-forging connections?

If you view your resume as nothing more than a hurdle, you probably don't take it as seriously as you should. But if you value it as a game-changer, you understand its importance. Unfortunately, those who are new to the world of resumes (and even seasoned jobseekers) often make mistakes that can take them out of contention. Here are 10 resume mistakes to watch out for.

1: Lying

It shouldn't have to be said... but surprisingly, it needs to be said. People falsify or "pad" their resumes all the time. Thing is, it will come back to haunt you. It's a small world that only gets smaller with every passing day. Even the slightest exaggeration on your resume can catch up with you. Keep to the facts. Don't stretch or bend the truth. Don't alter employment dates to keep from having gaps in your timeline. Don't claim duties or experiences you never had. Don't. Don't. Don't.

2: Stating an unattainable goal

I'm just going to say this right now. Everyone knows you want to someday be the CEO of your own company. Everyone knows you want to stare down from above and run the corporate machine. Even beyond the unattainable goal, get rid of that objective that has littered resumes for decades. It's worthless. Saying that your goal is to climb the corporate ladder and be as wealthy as Bill Gates just piles on the bad. Scratch that section altogether and you'll have more room for what matters—experience and skills.

3: Adding achievements that aren't

We get it. You were prom queen or you were voted most likely to succeed in business (without even trying) by your peers in high school. But consider this: Are those achievements really achievements? The last thing you need is to puff up your resume with awards that have no relevance for the career you're chasing after. If you were elected president of your school's computer club four years running or you were awarded a citizenship award for your volunteer work at a local community center... then maybe we're talking. Academic achievements? Certainly. Just be judicious in choosing those highlights.

4: Citing previous salaries

Please, don't include your previous salaries on your resume. There are so many reasons not to do this. Here's one simple, self-serving reason not to do this: It will give your prospective employer a springboard for determining your new salary. Your goal should be to make more—so don't give the interviewer the means to undercut your true worth. Leave that information off so you can approach salary needs from a neutral point.

5: Including personal information

There is no reason to include the fact that you're married, have 2.5 kids, drive a minivan, attend X church, have a man cave, coach your middle child's soccer team, or think "khaki is a way of life." All of that will eventually come out in the wash as you begin your career in the IT or business world. On a resume, it has no place. If you don't agree, consider this. What happens if you go into an interview and the hiring manager happens to hate soccer or khaki? You've immediately put yourself on the defensive side of things and have to work your way around a preconceived notion.

6: Listing your age

It's not illegal for interviewers to ask you your age. They can. They shouldn't... but they can. Most often, it won't happen. But if it does, I'd recommend that you terminate the interview. Regardless of whether an interviewer plans on asking that question, you shouldn't prompt them or give them reason to question your value simply because you added your birthdate or age on that document. Leave it out.

7: Providing references

Don't include references. Don't even add "Available upon request." You're just wasting valuable real estate. If interviewers need references, they'll ask. Saying that your references are available upon request is like saying that you promise to come to work if hired. It's implied. Besides, the space on that single-page document is far too important to be used up by worthless statements.

8: Writing in third person

Jack believes that your being snarky or trying to impress by writing in third person makes you look cocky. Jack is certain the vast majority of people hate it when others talk of themselves in this manner. In fact, Jack insists that you never refer to yourself in third person unless you're trying to make your co-workers laugh. Jack would go so far as to not even write in first person. Why? I'm fairly certain it is understood every detail on your resume is about you. Agree with Jack...everyone is doing it.

9: Using a less-than-professional email address

It doesn't matter that you've used bromancewithbooze@gmail.com as your primary email address for years. Leave it off your resume. If that's the only email account you have, create a new one with a professional name (as in, your name). Even if you use it only for resumes, do it. (Along the same lines, don't use an AOL account address—especially if you're applying for a tech job!)

10: Including your current business contact information

Do this and you might wind up receiving a call at your current place of employment by your prospective employer. Never list the contact information of your current business. If the potential new employers want to contact your current business, all they have to do is look up the name to get the details. The only phone number you should include on your resume is your mobile number. Nothing more. And don't forget, your current employer might well be monitoring your phone calls and emails. Let that be your guide when you add information to your resume.

10 ways to advance your IT career

Worried that your IT career might stall out? These 10 practical strategies can help you achieve your goals as an IT pro.

By Mary Shacklett

When I talk with up-and-coming IT'ers, I sometimes encounter a sense of fatalism. It's as if they feel their jobs are preordained and they'll be assigned to a "dungeon job" forever. It is a mistake to think that way, because there are many steps you can take to advance your career and your understanding of IT, regardless of the situation that you find yourself in.

Here are 10 things you can do to develop your IT career.

1: Seek out the hidden silver lining in the situation you are in

I always had strong communication skills, so early in my career — when I was trying to focus on the technical side of IT — I invariably got reassigned to training or documentation and not to the technical jobs I wanted. I eventually did spend time on the technical side, and what I ultimately found was that my ability to explain technologies and applications in plain English to end users and business decision makers was a valued commodity. It eventually led to my promotions to project manager and then to IT director and CIO, because employers were looking for someone who could explain (and sell) IT to outside stakeholders.

2: Get into the business

Even if your goal is to become the chief systems architect or a database administrator, those who take the time to read corporate annual and quarterly reports and to understand the business are in the best position to deliver value that is appreciated and rewarded. The best news of all is that once you learn how to get on top of the business for your job, you can take this ability with you anywhere you seek employment.

3: Take a sales/marketing course

Many IT'ers have an inherent dislike for sales/marketing, which relies on intuitive skills, perceptions, and communications — and not so much on logic and task-oriented skills. Yet the key to business is dialogue and being able to sell both yourself and your ideas. If you are a heavily task-oriented person, and most IT people are, it might be a good idea to take or audit a marketing/sales course to learn a little bit about the art of selling. I guarantee that you will find it useful in your IT work.

4: Develop your communications skills

Even if you are uncomfortable, take the risk of volunteering to make a presentation or lead a meeting. This gives you visibility as a leader and assists in preparing you for a supervisory or management IT role, if that is your goal.

5: Take on the projects no one wants

I started my own IT management career by volunteering to head failing projects with the belief that I could turn them around. Once I succeeded, it was noticed and I was in line for promotions to higher positions of responsibility. Many people are afraid of volunteering for these projects, and I must admit that before I volunteered, I considered that I could get fired. However, I also considered that the project had already failed. The only way it could go was up. If you can lead the effort and turn a failure into a success, you will get noticed.

6: Look for mentors

There are profoundly talented and creative people in IT with great skills. Many are willing to share their experience and knowledge. If you have the opportunity to be an understudy to one, take it. You will learn your craft much faster.

7: Stay current

Once you're assigned to a particular area of IT, it can become difficult to stay current on overall IT trends or other IT areas of interest. Fortunately, courses, periodicals, and trade groups abound that can help you stay on top of things. Take advantage of them. It's one way to ensure that you stay fresh in your IT thinking and practice, even if your immediate area of responsibility is somewhat constricted.

8: Network

The more people you get acquainted with in IT and the business, the more people will know what you have to offer. Individual performance excellence is always paramount, but so is exposure to those who can help you advance your career.

9: Make everyone a winner

People like winners. They also like to feel that they are succeeding. This is why the best project managers and IT executive are those who have found a way not only to make projects work, but people work. A key element in this is teamwork. When everyone feels a part of the project and the project works, the payoff for the project team and for each individual's sense of self worth is incalculable.

10: Do a little extra in every piece of work

One of my early IT memories was of a senior application programmer who wrote each app based on the end user's specifications and then added a little "extra" that he knew would please the user. Sometimes this came in the form of a navigation shortcut for a screen, or perhaps it was an extra function or feature the user hadn't thought about. That lesson has always stayed with me. If you're assigned a piece of work, do it — and then deliver just a little bit more. You'll delight your customers, and the word will get around.

Take responsibility for your own career

Today's companies are far less nurturing than they used to be. Even great performers can suddenly find themselves jobless if a company misses a quarterly earnings target, and then they must cut back. The moral of the story is to always take responsibility for your own career. You can never be sure where your career will take you or even which companies you will work for — but your skills and know-how will stay with you wherever you go.

10 of the best pieces of IT advice I ever heard

Even if IT is the best path for you, you may encounter some stumbling blocks. These career-tested tips will spare you a few headaches along the way.

By Jack Wallen

The IT career can be a long, tough, but rewarding haul. You work crazy hours, you deal with angry, frustrated end users, and you spend most of your time embroiled in one tech emergency after another. At the end of the day you're exhausted, and it's all you can do to carry yourself home, eat something, and go to bed.

Or so it seems.

You also get to work with technology, help people get their jobs done, and even (in some cases) help save lives. But ultimately, it's just you—and you're going to need some advice to get you through. Over the years, I've been handed a few golden nuggets of wisdom I thought I'd pass down to you. Here they are.

1: Learn to say "no"

If you're new to the career, chances are you'll be saying "yes" to everything. However, as you gain experience and put in your time, the word "no" needs to creep into your vocabulary. Otherwise, you'll be exploited.

Of course, you have to use this word with caution. Should the CTO approach and set a task before you, the "no" response might not be your best choice. But if you find end users—and friends—taking advantage of the word "yes," you'll wind up frustrated and exhausted at the end of the day.

2: Be done at the end of the day

I used to have a ritual at the end of every day. I would take off my watch and, at that point, I was done... no more work. That simple routine saved my sanity more often than not. I highly suggest you develop the means to inform yourself that, at some point, you are done for the day. Do not be that person who is willing to work through the evening and into the night... or you'll always be that person.

3: Don't beat yourself up over mistakes made

You are going to make mistakes. Sometimes will be simple and can be quickly repaired. Others may lean toward the catastrophic. But when you finally call your IT career done, you will have made plenty of mistakes. Beating yourself up over them will prevent you from moving forward. Instead of berating yourself, learn from the mistakes so you don't repeat them.

4: Always have something nice to say

You work with others on a daily basis. Too many times I've watched IT pros become bitter, jaded people who rarely have anything nice or positive to say. Don't be that person. If you focus on the positive, people will be more inclined to enjoy working with you, companies will want to hire you, and the daily grind will be less "grindy."

5: Measure twice, cut once

How many times have you issued a command or clicked OK before you were absolutely sure you should? The old woodworking adage fits perfectly here. Considering this simple sentence—before you click OK—can save you from quite a lot of headache. Rushing into a task is never the answer, even during an emergency. Always ask yourself: Is this the right solution?

6: At every turn, be honest

I've witnessed engineers lie to avoid the swift arm of justice. In the end, however, you must remember that log files don't lie. Too many times there is a trail that can lead to the truth. When the CTO or your department boss discovers this truth, one that points to you lying, the arm of justice will be that much more forceful. Even though you may feel like your job is in jeopardy, or the truth will cause you added hours of work, always opt for the truth. Always.

7: Make sure you're passionate about what you're doing

Ask yourself this question: Am I passionate about technology? If not, get out now; otherwise, that job will beat you down. A passion for technology, on the other hand, will continue to drive you forward. Just know this: The longer you are in the field, the more likely that passion is to falter. To prevent that from happening, learn something new.

8: Don't stop learning

Quick—how many operating systems have you gone through over the last decade? No career evolves faster than technology. The second you believe you have something perfected, it changes. If you decide you've learned enough, it's time to give up the keys to your kingdom. Not only will you find yourself behind the curve, all those servers and desktops you manage could quickly wind up vulnerable to every new attack in the wild. Don't fall behind.

9: When you feel your back against a wall, take a breath and regroup

This will happen to you. You'll be tasked to upgrade a server farm and one of the upgrades will go south. The sweat will collect, your breathing will reach panic level, and you'll lock up like Windows Me. When this happens... stop, take a breath, and reformulate your plan. Strangely enough, it's that breath taken in the moment of panic that will help you survive the nightmare. If a single, deep breath doesn't help, step outside and take in some fresh air so that you are in a better place to change course.

10: Don't let clients see you Google a solution

This should be a no-brainer... but I've watched it happen far too many times. If you're in the middle of something and aren't sure how to fix an issue, don't sit in front of a client and Google the solution. If you have to, step away, tell the client you need to use the restroom and, once in the safety of a stall, use your phone to Google the answer. Clients don't want to know you're learning on their dime.

Five ways to reduce IT's software maintenance work

By Mary Shacklett

CIOs might not be able to control all of the factors that lead to continuous software maintenance, but they can follow these best practices to cut down on how much time IT spends on these tasks.

Software maintenance is a major issue for most CIOs because over 50% of IT time is spent on it -- a daunting figure that hasn't changed much though the years. It's also one of the least favorite topics that CEOs and other C-level executives want to hear about.

It's easy to avoid the topic of software maintenance, given the focus on today's problems and pressures that are brought on by a constantly changing business environment. In this high-pressure situation, which relentlessly continues its advance, the idea of going back to "fix things" or to even see why they haven't been implemented, seems pointless.

Nevertheless, CIOs have to care about this, especially when IT budgets continue to remain flat and when half of IT staff is deployed on maintenance every day. These CIOs see their project loads burgeoning, knowing that only half of their staff is free to work on them.

The vicious circle of continuous software maintenance is fueled by various factors, which include the following:

• In many cases, age-old legacy systems that are characterized by difficult to maintain (and to diagnose) "spaghetti code" that was written in the days when code was free-flowing and unstructured and yet continue to run mission-critical systems. It takes time to untangle this code and to fix or embellish it. The task is rendered more difficult because the code is usually undocumented, and the original writers have long since retired.
• New code is not as technically solid as it should be -- the reason is enterprise pressure to deploy the code, even if it is imperfect. Consequently, the organization lives with the imperfections until they become so overwhelming that the software maintenance team has to go in and fix it so it can get back into production.

CIOs cannot buck these circumstances, but some are beginning to take steps to reduce the amount of IT time spends on maintaining imperfect and broken systems. Here are five best practices to consider.

1: Use the cloud version of software to sidestep a legacy system

Some enterprise have actively deployed cloud versions of internal systems (like their enterprise resource planning systems) when they bring on new companies through acquisition. The reason is simple: By moving a new organization to the cloud, personnel in this business at least get used to using the same software that the acquiring enterprise uses. Over time, a decision can be made to transfer the acquired organization into the in-house enterprise system.

However, as more enterprises use this strategy, more are rethinking their approach. The result has been a change in thinking to where the ultimate goal becomes moving everyone (including the enterprise) to the cloud-based system. The idea is to push software maintenance to the cloud provider, thereby eliminating most of the time that internal IT has to spend on it.

2: Replace a custom system with a generic package

It sometimes makes sense to replace a custom system in favor of a third-party generic package that has more contemporary capabilities. In a situation like this, IT can also eliminate most of the software maintenance it incurs with the old software. The key is getting users -- and the business -- on board. Many times the customization that has been built into a system over decades can't be replaced with a more generic solution because of the competitive advantage the custom solution provides.

3: Invest in more quality assurance (QA) test bench automation

QA is one of the functions that many organization shortcut in the interests of getting software into production quickly. This isn't likely to change, but new automated testing tools in QA that run automated scripts and check for software deficiencies can change how well software runs and reduce software fix time.

4: Retrain and redeploy software maintenance personnel

As much as CIOs don't like to admit it, there is a pecking order in IT. The employees who often get placed on software maintenance teams are older IT programmers, new employees, or programmers who do not demonstrate proficiency in new app development. If software maintenance is to be reduced, these workers will need to be retrained and redeployed. Despite budget limitations and work commitments, CIOs must demonstrate a commitment to adopt these measures.

5: Set a metric for percent of personnel engaged in new projects

CEOs and other C-level executives might not want to hear about software maintenance, but if the CIO presents (and starts measuring against) a metric that shows the percent of IT staff dedicated to new projects and explains how software maintenance can negatively impact this, others are bound to take notice and view the effort more strategically.

10 low-cost ways to develop and improve applications

Enterprise developers are being asked to do more and to do it more quickly. Luckily, a number of cost-effective tools and time-saving approaches can help. 

Enterprises are being asked to develop more applications than ever... and in less time. Here are 10 tools and techniques to help jump-start your application development.

1: Cloud-based application development and testing

To economize soaring data center costs, companies are moving their application development and testing to pay-for-use platforms furnished by public cloud providers. The practice helps sites avert costly data center hardware and software upgrades.

2: Virtualized databases

Ten years ago, sites began cutting application development and data center costs by virtualizing servers and then storage--but few thought about economizing their softwarecosts through virtualization, with the exception of operating systems. Today, new solutions in the marketplace assist sites in virtualizing expensive software like databases by generating multiple virtual databases that can quickly be deployed for application development and testing.

3: Point and click app configuration

Rapid application development tools are now available in the cloud that allow you to target the hardware and software you want to run your app on and to define the type of app (e.g., "mobile app") you are writing with the click of a mouse. The technique frees programmers from worrying about the underlying hardware and software the app must run on, and it enables them to focus on the business.

4: Virtual operating system automated deployment

A substantial number of sites use manual scripts to deploy new virtual systems, running the risk of introducing human error and modifying scripts so the resulting operating systems being deployed are no longer compatible with the vendor's version of the OS. Now there's software that automates this process and verifies that changes to the operating system stay within the supported range of the vendor. The automation streamlines application deployment, reduces risk, and eliminates the manual effort involved when "homegrown" app deployment scripts are modified.

5: Scrum

Scrum is part of the agile application development methodology that enables a joint development and end-user team to collaborate on app building and refinement. The team works as a unit to build the application, together ensuring that the app meets IT and business requirements. The upfront, joint development process might take longer, but it pays off in time saved time later because co-development significantly reduces the potential for app modifications and failures. These savings are important. Most sites spend more than 50% of their application time modifying and fixing existing code.

6: Prototyping

Closely related to scrum is application prototyping. With prototyping, the majority of the application program is not built, but a rough layout of a display or report is created that the end user experiments with. The objective is ensuring that the app fulfills the business need. Because only a limited amount of time is committed to prototype development, it's easy to create new prototypes based upon end-user feedback and to get user buyoff before developing the rest of the app. This saves time because the app is on target in the first place. The developer doesn't have to go in to make complicated fixes for functionality that was missed because the user wasn't involved.

7: Workflow walkthroughs

Applications are only as powerful as the business processes they support. Yet surprisingly, a majority of application developers have little knowledge of the end business environments their applications operate in. To gain this understanding, developers can meet with end users to walk through the actual operation the app fits in. This gives developers first-hand knowledge of the operational workflow and improves the quality of the application.

8: Standards

IT departments that use standardized routines and application libraries create consistency in their application development that enables new programmers who must take over someone else's work to do so easily.

9: Help desk intelligence

Application developers can improve their understanding about what works and doesn't work in applications if they gather intelligence from help desk calls. The help desk can tell application developers which apps are most troublesome and receive the most user calls. When developers analyze these problematic apps, they can pick out trouble areas and take this knowledge into new application development so that old mistakes aren't repeated.

10: DevOps

Many IT departments are breaking down the walls between application developers, system programmers, and network specialists. This approach is called DevOpsbecause it combines the efforts of developers and operations specialists into one project team. By grouping professionals from diverse IT disciplines into specific application teams (e.g., finance, manufacturing, sales), application deployments are accelerated and trouble areas are resolved faster.

6 Daily Battles In The Life Of A Programmers

Being a developer is hard. I'm not saying other jobs are easy, but being in the software business demands a pretty solid effort. In this blog post I'll describe some of the situations that I find myself in and that are probably way too familiar for many of the developers out there.

1. When you get excited

Just like a cowboy in a western your fingers start itching and you just get that buzz going. You know that whatever else you have planned will be ditched. Sooner or later you will drop everything and start coding the thing you are excited about. Most of the time it's a good thing. It's like a drop of nitro inside the fuel tank. You are really focused and stuff gets done fast. Sometimes though, you get excited about things that aren't a priority and that's when it's much more difficult to satisfy your curiosity about the problem.

2. When you get in the zone

As the Zuckerberg character in the movie "Social Network" said when Justin Timberlake tried to greet the hackers: "Don't bother greeting, they are in the zone." Sometimes you just get the ball rolling so fast that everything else becomes a blip on the horizon. You have postponed your lunch for hours and your eyeballs are turning yellow because you just haven't been able to take a minute to visit the restroom. You just code, and with every code execution and every error you feel like the solution is just around the corner. "If I just fix this error, then I can commit and take a break". For me this can go on for a full workday. In the evening I find myself hungry and tired, but mostly happy because I have slayed yet another bug monster or climbed another feature mountain.

3. When you refactor

From time to time you have an epiphany. You find some new technology or a better way of doing something. Eagerly you feel like this is exactly what needs to be done to make the code faster, cleaner and more optimized. Pumped up, you dig into it hard. Many times this does not end well, though. That doesn't mean that the idea was bad. But the thought that this is just a minor adjustment goes out of the window, when a week in to the refactoring you find out one of two things:

a.) this is too big a piece of cake to eat with one go, or

b.) this just isn't working out with the current codebase.

Sometimes however it works out, and it really does all the things you imagined it would – and for all those times it's totally worth it.

4. When you make custom things

Creating a custom bit of software is generally not considered a good idea, because updates to the main libraries are almost certain to break it. But even if you decide there aren't going to be custom elements in the software, sooner or later there will be. It's just because of the fact that cool things aren't built in the main library. Is it my fault that Cocoa doesn't have popups that shoot fireballs (and that we need it because the designers sold the idea to the product lead)?

5. When you finish where you started

These are not my favourite days. Actually they can drag on for some time. These are the days when you're working on something new or on some nasty bug. Whatever it is, it's just something you can't put your finger on. You dig around the internet, read the docs and try to find anything that could give you an idea on how to proceed. When the day ends, you might leave with nothing to show for your work. You've cracked the code for a whole day and tried several different versions. In the end, however, your commit count is around zero and the lines of useful code written is about the same. When you finally get that Eureka moment, you feel incredibly relieved. Most of the time, the solution is really elegant and simple, and it makes you wonder why didn't you think of it straight away instead of wasting days on cracking with it. Two days of work and one line of code to solve it all.

6. There are no easy things

The famous saying we use here at Toggl is "How hard can it be?!". When something seems simple, it's probably quite hard to execute. Last such thing I remember was my acquaintance with Constraints in Cocoa. We needed to change the constraints of certain elements at runtime. It seemed quite easy, if we click here we change the constraints. But what I didn't know was that the documentation for constraints was quite vague and there were few examples floating around the Internet. Anyway, with good old trial and error method I got it working, but this simple thing wasn't definitely as simple as it seemed at first glance.

Source: Toggl