Uncharted Waters

Oct 8 2013   1:46PM GMT

A Different Look at Your Tech Career



Posted by: Matt Heusser
Tags:
career
careers
technology

Which way should you go next?If you live in a developed nation, you are probably familiar with the technical career ‘wisdom’, which usually goes something like this:

- New graduates are cheaper, hungry, work hard, and are open to learning new things

- As people get older, it gets harder to learn new things

- Therefore the typical tech career is about fifteen years long.

After fifteen years, if you haven’t moved up into management, you’d better be working for a company where you have deep an intimate technical knowledge, inventing something new (eg be the author of Linux, create git, that kind of thing) or move on to some other field.

I can’t disagree the conclusions above, but if you don’t mind,  I’d like to propose an alternate explanation for why – and perhaps what you might do about it.

What Actually Happens

Allow me to present a crazy alternative: Most people learn the technology they need to get through school, and the technology they need on the first job.

So thirty years ago, when you graduated from college and got that first job, you learned COBOL or RPG. You then spent the next ten to twenty years getting really good at COBOL. You’d learn the new versions of COBOL, some new tricks in the operating system, etc, but, for the most part, you’d  be a COBOL programmer.

Over time, new shops appeared, running C or C++. You didn’t work there. Some companies converted away from COBOL; a lot of them converted in the late 1990′s and early 2000′s to Java – you didn’t work there either.

In the end, the number of companies you could work for shrunk, but that might be okay – some people left the field, others went into management, and others did learn Java.

You can repeat this for C++ in the 1990′s, Perl, Python or Ruby in the 2000′s.

You can repeat it for Node.Js, HTML5 and CSS today. My examples here are from programming, but I could have used MVS to MS-DOS to Client/Server to Web, or Exchange to GoogleMail. Every kind of tech job has been changing, all the time, for the history of computing.

An Example

I have a friend, Ken, who is a professional COBOL contractor.

Yes, Ken is making a living, mostly because while the demand for COBOL contractors is low, the supply is also vanishingly low. The two balance out.

Ken comes in and writes the new code for the ERP upgrade, or the new acquisition, or whatever. That means he works for a small handful of companies that were early adopters of big technology, mostly mainframes in the 1970′s, doing a lot of data processing — banks, insurance companies, that sort of thing.

Another friend of mine, Bill, was a long-time Microsoft Visual C++ programmer. When those jobs went South, Bill went to graduate school for a couple of years, and is now back, writing code in Visual C++ for a legacy system. When I met Bill for lunch last year, he told me that staying in technology is simple: “The trick is to find a company that stopped growing about the same time you did.”

Somehow I find that … unsatisfying.

“There’s The Rub”

About ten or fifteen years ago I did a lot of programming in Perl on an Apache system. All of a sudden the new college graduates were super-excited about Ruby. At the time, I said “What can you do in Ruby that you can’t do in Perl?” I was not alone in this question.

The response, mostly about how terrible Perl was, told me the people I was talking to didn’t really know Perl at all; they had learned one language after college, and it was Ruby.

My friends and I were scoffers.

Ten years later, those programmers have gone and written a pile of now-legacy Ruby. The Perl shops I used to work with have gone away, converted to a different technology, or at least, consider their existing Perl investments legacy code to be minimized.

All of a sudden, my old friends, the scoffers, are having finding jobs in the new economy.

Meanwhile, every CEO is saying there is some sort of talent shortage.

Alternatives

An image of Robert C. Martin's "Clean Code" In Robert C. Martin’s Clean Code, the author suggests the classic answer: If you invest 20 hours per week on your own time in professional development, then knowing the new hotness isn’t going to be a problem.

Of course, that’s four hours a night. 7PM to 11PM, from dinner to bed. Every weeknight night. Not everyone is willing to make that kind of an investment.

Staying current may be the best-known option, and it might work for professors who have summers off, but it is not the only one.

The Ken/Bill route is the second option; tie yourself to a technology and develop a reputation in that technology.

For a third choice, you can find a single company and get to know not just the technology, but the business process. Become the expert in the business logic and rules the company runs under, and you’ll still be valuable two or three new “technical innovations” down the road.

Fourth, there’s changing your focus from something changes all the time to something that has more broad appeal. Right now, the current hotness is ‘agile coaching’, and that certainly has a place. Over the past few years, I’ve been focusing on process and quality on software projects. (I’ll defer the conversation about management to the thousands of posts available on this subject.)

If you’ve read up to this point, you are likely thinking my conclusion is going to be about making a ‘plan’; steering to one of four options above. Instead I’d like to present a fifth option.

Hogwash

All this talk of reducing a person to a resume removes any element of mastery. Without recognizing mastery, the industry will keep hiring for price/buzzword match, and keep making the same mistakes.

And we do. After fifteen years of field experience, I’ve seen the same appeals to overtime, loss in pride in work, poor definition of work leading to rework, again and again. It’s downright predictable.

So here’s a fifth way: Find a way to demonstrate and sell your expertise as a grownup. Doing that means figure out what you do differently, based on your experience, and looking for ways to capitalize on that.

For me, it’s been writing, organizing people, and seeing danger signs before anyone else does. Yes, I do testing, and analysis, project management, even write code — but figuring out how systems are flowing, where the bottlenecks are, and how to go faster — that’s not something everyone can do.

If you want to stay in the game, find a way to be different.

Next time: Ways to break out of the game.

 Comment on this Post

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when other members comment.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to: