Your complete guide to a money-making career in the tech industry

A few weeks ago, I received an email from a reader asking me if I would work in the tech industry again if I had the chance to do it all over. Like I said before, this IT business can drain the life out of you. Long hours. It's boring, but also exciting, frustrating and lucrative all at the same time.

I would do it again, but only because of the techniques that I have developed to keep this business from killing me. One can make a great deal of money in information technology - money that can be used to fund an early retirement lifestyle.

But, information technology can also kick your ass if you are not careful, trapping you into a box full of dragons and pit vipers clawing their way into your very soul ... yet tempting you to stay put with promises of shiny possessions and awe-inspiring power and influence.

How do we navigate the maze of a career in information technology? To maximize income potential and minimize soul-crushing stress is the definition of success in this business?

Let this guide teach you how to build a career in information technology...and live to tell about it.

Your guide to a career in the tech industry

I have worked in information technology all my life. My first job straight out of college involved low-level programming using PERL (that's right, PERL!).

I slowly climbed up the food chain by managing production software migrations for a couple of years. Then, I dove back into web development over the next 8 or so years before finally getting my shot to lead an entire information technology department (a job that I promptly quit).

In my last job before retiring early, I was a database consultant.

Over the years, I've learned a thing or two about this business and what makes the difference between successful careers and unsuccessful ones - in Corporate America.

First, let's get this out of the way now: Information technology kinda sucks.

More accurately, working in IT sucks. I love writing web applications, but I hate working for a company that writes web applications. I love picking and choosing my own computing hardware, but I don't enjoy this same process for a business.

Working in IT can be incredibly stressful.

Businesses of all types depend on their information technology infrastructure and are willing to pay handsomely for its maintenance. But with those lucrative paychecks comes an expectation that things nearly always work, and when they don't, THEY MUST BE FIXED, and now.

And this brings us to my first point of building a career in information technology:

Prepare yourself for a sense of urgency

It's not a matter of "if". It's "when". In information technology, things will break. The insane complexities of how software products function with other software products is nearly limitless.

These complexities break shit, all the time. And rarely will you find a situation where software doesn't need to integrate with other software.

And when things break, the IT staff is on the hook to fix it - even if they have no idea what broke or didn't even designed the darn thing to begin with.

Learn to Google. No, scratch that. Master Google. Become an expert at finding answers, fast. The nice thing about IT problems is very simple: you probably aren't the first one to experience them, and chances are someone has posted about them before. Web sites like StackOverflow.com are your friends. Use them.

Some food for thought: I have found that the less a person knows about information technology, the more "urgent" problems become.

Most organizations don't care about making information technology easy

As important as information technology is to a business, most businesses largely ignore the technical implications of their decisions, relying instead on their "IT guy" or staff to figure it out, fix it, enhance it or debug it.

They don't give two shits about how their software choices affect their larger infrastructure.

And, this is why it's important for IT staff (and especially management) to educate their organizations the best they can about how their IT decisions effect the business. I know this won't always be possible. The larger the organization, the less likely they will be to actually care what their IT folks say.

But if we don't try, we'll never make headway.

Prepare yourself for insanely complicated networks and software installs. Almost nothing works to a company's specification out of the box. Config files will need to be changed. Settings tweaked. Network firewalls opened (or closed).

Nearly 100% of the time, the software will need to be configured so it runs precisely how an organization wants it to run...which usually isn't how it was designed by the manufacturer.

And naturally, all this needs to be maintained.

Understand this: A large percentage of a company's spending on information technology is due to needless complexity put in place by bottom-line decisions made by non-IT layers of management.

Earning potential increases in customer-facing vendor roles

Consulting services means big-time money. When spending thousands, hundreds of thousands (or millions) of dollars for an enterprise software product, companies often hire the vendor to help them integrate the product into their environment.

The U.S. Government does this a lot, and they pay vendors huge sums of money for on-site consultants to hold their hands while getting things set up.

These vendor consultants often make a good deal of money. They are not only experienced technically, but they interface with customers.

Consultants are hybrids between pure technical staff and sales. They are the face of the company, and vendors aim to only put their best in front of their sources of revenue.

As a result, consultant positions often pay a great deal of money. However, stress can quickly become overpowering. Customer problems often require 24/7 support. If a consultant can't figure out a problem, he or she is personally on the hook until it gets fixed.

And let's face it, the shame and humiliation of failing in front of a customer can be a big deal. Nobody is perfect, but when customers pay $250/hour for a consultant who can't fix a problem, it just sucks for everybody involved.

If you're a consultant, the stress is high. You're often on-call. You travel quite a bit. But, you also get paid handsomely for it.

In customer-facing positions, the pressure is high, but the reward is also high. How much pressure are you willing to take? Deciding this early will make your career easier to manage. Take positions that truly interest you. Pass on opportunities that demand too much stress.

Because in IT, there will always be another opportunity down the line.

Learning to debug is more important than learning to build

Colleges completely suck at preparing our nation's youngsters for careers in information technology, and especially software development. The reason is because the academic setting rarely resembles real life and how business is done in this country.

Most information technology related programs teach concepts from a start-to-finish perspective. That is, you have a clean slate to work with. You learn how to properly design an application, or put together an efficient network, or code up some pretty darn impressive algorithms that do some amazing number-crunching in a split second.

That's all great.

But what universities don't teach is how information technology in business actually works. In the real world, we very rarely have a blank slate to work with when designing new applications. We have business requirements to satisfy, management to please, complicated networks to contend with, weird or archaic technologies built in the 1980s to interface to.

But worse, many times we don't get to start from scratch, either.

Nine times out of 10 in my career, the work involved something that was already there. We aren't designing networks from scratch.

Instead, we are improving existing networks. We aren't designing software applications from the ground up. We are taking a pile of crap written by someone else and making it work. Or work better.

Most of the time, we don't get the luxury of clean slate work.

We are forced to learn what the organization already has in place, or debug existing systems, or learn how to connect to and interface with stuff that's already in use.

In other words, we are often confined to nonsensical policies, weird coding standards, pre-existing applications and lots of poorly-written code.

Universities fail to teach students how to debug someone else's code, to step through code line by line using tools like Visual Studio and inspecting every variable, every data structure, every interface, every API call, every ... everything.

Debugging code might be a small section of a larger class, but that's not nearly enough when 90% of a typical developer's job is debugging.

Successful IT careers depend on your ability to take something that is pre-existing and improve it, debug someone else's code and fix it, understand complex networks and work within them.

Learn how to interview and craft your resume

When I worked as the Director of Information Technology, I interviewed quite a number of people for software development and system administration opportunities. We only ended up hiring a fraction of candidates even though we had several positions available.

We didn't use any interviewing tricks. We asked straightforward questions and expected straightforward answers. We asked questions based on what was written on their resumes.

Most of the time, I wasn't impressed.

In short, too many candidates couldn't back up their resume's impressive accomplishments.

I need to stress this: Everything on your resume is fair game!

If you list experience with a programming language, it means that you've personally used that language enough to talk intelligently about it. Reading an article or writing a "Hello World" application isn't enough.

That is not experience.

That is trying to bullshit your way into a high-paying IT position.

Take a look at your resume and ask yourself, honestly, if you want your next interviewer to ask questions about a particular concept or capability on your resume. If you are prepared to talk about it, great. If not, don't risk it...take it off.

The second I discovered that a candidate included something on their resume that they weren't familiar with, the interview was over.

Secondly, you may be asked to demonstrate your knowledge during the interview process. Coding challenges are common for software development positions. Remember that the organization is not only interested in your ability to solve the challenge, but more importantly, they are observing your thought process to get to the answer.

Under pressure.

For example: How do you respond under pressure? How do you work through possible scenarios in your head and select the best one?

Move around every couple of years

I've learned more from moving around than I ever did working at any one company, and this is especially true in information technology.

Every business has their own way of doing things. They have their own software development process. Their own network, coding standards and software tools. Their own everything.

Hanging around any one company long enough makes you more knowledgeable and experienced with that company's information technology process, but it does your career no favors.

In 14-years working corporate America jobs, I’ve worked for five different organizations.

Each company did things differently. I got exposed to different development processes, meeting schedules, work attitudes and company cultures.

Of course, the work itself differed from place to place and my experience interacting with a variety of technologies and computer environments continued to expand nicely.

Moving around gave me a huge leg up in my career. And, every time I  moved to a different company, I got a raise. Often, a nice one.

There are exceptions, but the more that people move around, the more exposed they become to new ways of doing business. I like to think that each organization makes us smarter and more equipped to tackle problems that might seem unique to some. Move around enough and you will likely see it all.

In the end, no problem is all that unique anymore.

Know your resources

Working in information technology doesn't mean that you "know everything" in IT. It does, however, require that you know where to find quick answers.

The better you are at Googling, the easier your job will be, guaranteed.

StackOverflow.com is a software developer's go-to source for figuring out programs or blasting through technical roadblocks. It's a site where other software developers post questions and get answers from others in the industry. Like I said before, the problem that you're having probably isn't unique to you. Someone, somewhere, has had your exact problem - or at least one that is very similar.

Information technology is about knowing where to get your answers, and fast. Develop your collection of go-to sources. Know them, and know them well. Use them often. Understand their quirks. Because when time is critical, you can't afford to fumble around and get lost in the weeds.

You need answers.

There is nothing like fixing a high-visibility problem

I will wrap this guide up on a positive note. Although information technology can be stressful and life draining, there is that incredible feeling you get when you fix things. That problem nobody else could figure out, but you fixed it? That one.

Or the time you brought the company's website back online after a problem? That one too. Or walking (strutting?) out of a client's office building after totally kicking ass?

Successes in information technology feel incredible in large part because of how frustrating the business can be. Feeling good knowing that you were the source of getting something major accomplished isn't unique to this business, but it feels especially awesome after suffering through nights and weekends of torment, or spending hours researching a problem and trying out possible fixes.

The successes, when they happen, are unlike any other feeling I've ever experienced in corporate America.

This post was originally published August 2016 but has been updated and revised using the Revise and Republish strategy.