Vol
1, Issue 12, December 1997
Copyright (C) 1997 by Steve Litt
Vol
1, Issue 12, December 1997
Note from 2023!
This document was written in December 1997, 25 years ago. It's assertions are still true today. In fact, they're even more true. 18 month obsolescence sounds like a slow pace today. Today there are several new programming languages every year.
That being said, the examples from this document are archaic in today's world. Almost nobody today has heard of "Compuserve", "Powerbuilder", Cobol or "Clarion". The point is this: Technologies come and go, but the need for ever faster learning will always be with us.
This isn't your father's job market. Not only does today's Troubleshooter work with systems 100 times more complex than twenty years ago, but the rate of technological change has exceeded what was formerly believed to be the human ability to adapt. This rapid change creates a new set of expectations and realities for today's employee.
What good is a four year college when the curriculum trails technology by two years? Are the four years well spent if they're obsolete 18 months after graduation? What if the course took only 3 months? Can the Troubleshooter afford to spend 3 months of unpaid training every 18 months to keep up? Can his employer afford to pay for such training? Then there's the ten year veteran employee who takes 18 months off to care for a child or sick relative, or to try to start a new business. When that employee comes back to the job market he or she is back competing with brand new college grads.
The answer to all these questions is obvious: We need a radically new, radically faster way of learning. This issue of Troubleshooting Professional explores some tantalizing possibilities. Our examples come primarily from the world of Application Development because it's changing so fast and because I have an intimate familiarity with it. If lately you've felt like a winded mouse on a brutal treadmill, think about what you see in this issue. And remember, if you're a Troubleshooter, this is your magazine. Enjoy!.
The Cobol Programmer is the last of a dying breed. He learned his trade in an era of polyester shirts and platform shoes. For twenty years he's used the same tools to make the same products in the same environments. Twenty years to perfect use of those tools. He can take a three year vacation, come back, and begin again right where he left off. While his C++, Powerbuilder, VB, Java and Delphi brethren spend unpaid hours per day learning new languages and new commands, the Cobol programmer just does his work and collects a fat paycheck. Must be nice.
And with the Y2K crisis, it will stay nice for the next 5 years. Y2K will suck up every programmer remotely claiming to have Cobol experience, calling back those that were retrained in VB or vanquished to unemployment during the early 90's recession and client-server boom. Scores of new college graduates will rush in to fill the VB jobs. But what happens to the Cobol programmer in 2002, when Y2K winds down?
It will be a game of musical chairs, with ever more Cobol programmers standing chairless as Cobol maintenance jobs dry up. News articles and TV news soundbites will show, in excruciating detail, the effect of the Cobol collapse on people and families . Cobol programmers will be retrained, at taxpayer expense, in VB or whatever happens to be the language of the month. It won't work, for the problem isn't the tools. The problem is the average Cobol programmer hasn't learned how to learn. And even if they learn how to learn, many will lack of resolve and commitment to use that ability.
The Cobol programmer is a dying breed -- but not because of his language. By that definition VB, C++ and even Java programmers would be on their way to becoming a dying breed. No, the thing that makes the Cobol programmer a dying breed is he's the last of the language-for-life programmers. Polyester and platform shoes will some day return to fashion. The one-language programmer never will.
Desperation can be a wonderful motivator. It sure was for me after the 1987 stock market crash. You remember the crash. After Reaganomics produced a dizzying stock boom throughout the spring and summer, much of the nations wealth was stored in the stock market. Bank accounts were liquidated to buy into the "sure thing" market. October 19, 1987, the Dow Jones Industrials fell 508 points. That day, almost a quarter of the the money stored in the market ceased to exist. Money earmarked for capital equipment and additional employees -- gone.
Spending and hiring ceased. What a rotten time to be unemployed. I was unemployed. By mid-November I was approaching a situation of selling my computer, the tool of my trade, to pay the rent. I had to think of a solution, fast. I took a long walk to be alone and think.
It was a hot November day in Los Angeles, and mile after mile I went over it in my mind. My thoughts turned to that tactic so familiar to all Troubleshooters; exploiting the differences between a working and non-working system. I knew several programmers with less brains, ability and productivity than me, who were doing quite well. They always had better jobs than me. They were never unemployed. What did they have that I didn't?
As the hot day faded into a perfect evening, it became clear. Every one of them was accomplished in the use of the terminology of their trade. Buzzwords. Jargon. Their use of terminology gained them employment I couldn't touch, even with my record of robust apps delivered early and under budget. With my drive and abilities, imagine what I could accomplish if I fluently used industry terminology. After rehearsing terminology, I tested my hypothesis the next week.
A large company needing experienced RBASE programmers, so I made an appointment to interview for a contract. I had never written a line of RBASE. A quick skim of a couple RBASE books yielded RBASE specific terminology and their definitions, and a visit to a friend with an RBASE interpreter rounded out my understanding of the terminology I'd memorized. The interview with the MIS director went splendidly, with gushing enthusiasm. Then came the interview with the lead programmer. Would he believe I had many months RBASE experience?
The lead programmer was good. Really good. It was obvious from his discussion of design and coding methods, and from the program source he showed me. Not the kind of guy to be fooled easily. I took a deep breath and began spouting RBASE terminology. He spouted terminology right back. Code was displayed, suggestions made. The lead programmer took me back out to the MIS director saying "this guy's a real programmer. I want him!". It was decided I would begin four days hence.
Those four days were spent cramming RBASE. My first day on site, they threw everything but the kitchen sink at me. I did what they asked, and did it to their satisfaction. My transferable skills, Troubleshooting Process and program design, helped immensely. The work was done at night so nobody would see me programming with the manual on my lap. 2 weeks later the manual disappeared and day-shift became a reality. They never even suspected. I sure pulled the wool over their eyes!
Let he without wool cast the first stone. My little slight-of-hand was page 8 filler -- a humorous little human interest story. The wool over *my* eyes prevented my seeing the screaming page 1 headline, which may have looked something like this:
All the news The Daily Developer December 15, 1987 Programmer Masters Language in One WeekLOS ANGELES -- It was revealed yesterday that programmer Steve Litt mastered the RBASE 4gl programming language in one week. While the accomplishment is not unheard of, what makes this case unique is that Mr. Litt did it while obtaining a contract with a new client, and pulled it off without the new client's knowledge. Observers attribute his success to a new learning method which stresses mastery of technology specific terminology ... |
Yes, the big story was that the terminology study designed to "fake out" the client also jump-started the learning process. Unbelievable at first, this fact stands gains credence after a closer look:
Modern technical work is conceptual. Concepts like relational databases and object oriented programming are orders of magnitude tougher to understand than tangibles like bicycles. If you compare mastering a concept to riding a bucking bronco, then naming that concept is like getting a saddle, bridle and reigns on the bronc. A name makes a concept tangible. For instance, once you understand what the word relational database means, you'll never have to say this again:
| A method of organizing data where entities are placed in tables, with each entity locatable by a key field. To completely describe such an entity, other types of entities may be accessed through their key fields, a copy of which is stored in the first mentioned entity. |
Note that even this long-winded definition depends on (bolded) technical terminology. To get completely away from terminology, you'd need to say something like this:
| A method of organizing data where each thing is put into lists of similarly categorized things. Each thing in the list consists of one or more facts about the thing, plus a special fact whose purpose is to uniquely identify the thing. To completely describe a thing in a list, other types of things from other lists may be accessed through their own unique identifier facts, a copy of which is kept as a fact in the first mentioned thing. |
The originators of a concept give it, and its sub-concepts, names. These names form the technical terminology and give the concept tangibility. To attempt to master the concepts without first mastering the originators' technical terminology is to re-invent the wheel. Terminology-first learning speeds mastery several fold.
In the 10 years since the start of that 1987 contract, I've come back many times to help them with numerous systems, including document management, time and billing, employee review, and technical documentation. Accomplishing this has required me to rapid-learn Clarion, C++, 86xx assembler, WordPerfect macros, Winhelp authoring, Powerbuilder, HTML, Perl, UNIX shellscripts, Informix 4gl, and Sybase. Now days they don't even ask me if I know a technology -- they just ask me to do it. A couple weeks ago, the Technology Director pulled me aside and said, "Steve, you have no idea how valuable your services are to our firm. Thank you so much!".
Yes, I really pulled the wool over their eyes :-)
Jeff was the best athlete on his outdoor speedskating team. A former track star, his endurance went on forever, and his strength was beyond compare. But he didn't win races.
To understand this, you need to know a little about outdoor speedskating. These are endurance events: 10 kilometers, 20 kilometers, or 26 miles. Wind resistance is the limiting factor, so skaters skate right behind each other (called drafting), in a line or bunch (called the pack). Since the lead skater takes all the wind resistance, the pack frequently changes lead skaters. In this way a pack of skaters can skate faster, for a longer time, than any individual.
Jeff lacked the technique to stay with the pack as they changed velocity and pulled off various maneuvers. So he'd skate, for miles, 20 or 30 feet behind the pack. His superb conditioning allowed him to pull off the impossible -- keeping up with the pack while working alone. But it took its toll. In the final 500 meters, when the pack broke into a free-for-all sprint, Jeff was too tired, from miles of working alone, to sprint with the pack. He'd be 10 seconds off the winning time.
Reminds me of technical people who try to learn off the job, rather than on the job. Work all day with old technology, then study half the night to catch up on the new. In the final sprint for the promotion or the new job, they're just too tired to win.
There are two barriers to on-the-job learning. One is slow adoption of technology by the employer (or client, if you're a contractor). The solution to that is simple -- get a new job or contract where you'll be in the high-tech pack, rather than working alone like my buddy Jeff. The other barrier is something commonly mislabeled as "honesty".
Some job seekers bend over backwards to tell, in excruciating detail, every gap in their work history and their skillset, all in the name of "honesty". They make sure the perspective employer knows that although they've worked intermittently with technology-X, they really haven't done much with it. They pay big time for their "honesty", in lost opportunities for new-technology jobs. Instead, they're given jobs with the same old technologies, over and over again, until those technologies obsolete and their career dies on the vine.
Employees are not the only one who pays for their "honesty". Their prospective employer passes them up, usually for someone of lesser ability. The employer is deprived of the "honest" employee's contribution.
Employers aren't innocent victims in this "honesty" wastage. Too often the employer issues a job order requiring years of experience in every single technology the new employee will be using. A lateral move. No on the job training done here! Their human resources department matches buzzwords on the job requirement sheet with buzzwords on the resume. "When in doubt, screen em out". Obviously, no "go-getter" with all the requirements would consider such a dead-end job, so the successful candidate will be one of these three:
|
For the employer's sake, I sure hope it's number 2. Otherwise, the employer just pays and pays.
So here's my advice to you when seeking a new job or a promotion. There's a wide spectrum of "spins" you can put on your work experience. Always choose the most positive possible "spin". If you're worried about "honesty", simply pledge to yourself that when you get the job or promotion you'll do whatever it takes to match your performance to your "spin".
In the high-tech career race, people fall hopelessly behind every day. Some go back to school in hopes of catching up to the pack. Others retire, or open a bed-and-breakfast in Carmel. That's OK. But if you're high-tech and like it, live by this rule:
This issue of Troubleshooting Professional points out, over and over again, that the past methods of off-the-job learning fail us, as employees, employers, and consumers, in the 1990's technological whirlwind. So what do we replace it with? I'd suggest a process which I'll call Rapid Learning (there -- I just made a concept tangible).
|
You can't design a microprocessor without knowing Ohm's law. Technologies come and go, but certain physical laws, methodologies, processes and concepts are vital and unchanging. Learn them.
The mind is a terrible thing to waste. The guy who learns every single technology coming down the pike will burn out and go nowhere. Choose carefully. The choice boils down to money and love. Any technology you learn must have a real shot at paying the bills for the next year, otherwise it's just a hobby. And you must like it. If money is your only criteria, technology is the wrong place for you. Be a stockbroker.
Make a terminology glossary for the technology. If the technology is bleeding edge, the only place to learn the terminology is the 'net. If it's a little bit established, I start with a "For Dummies" or "Idiots Guide to" book. That gives definitions for the most common terms, and gives a good overall tutorial of their relationships to the technology. It's easy and non-threatening. Remember -- "For Dummies" means when you've finished the book, you're no longer a dummy in the technology.
Next comes magazines, trade publications, company brochures. Now go deeper with computer program help files, Internet Websites, and files and intermediate or advanced level books. Remember to concentrate on the terminology -- don't get bogged down with the details. Keep up your Technical Terminology Glossary.
By now you should have enough terminology to sound knowledgeable. Get further terminology terms and definitions from Internet newsgroups, Compuserve Forums, face to face networking encounters, etc. Once you're really in the know, you're ready to proceed...
Find several jobs, or assignments if you're already employed, using the new technology. Using your terminology to communicate, get plugged into one such job or assignment. Remember to put your best foot forward. See the Speed Skater article.
Before you show up on your new job or assignment, you darn well better look like you've been doing it all along. If the new technology is a computer program, make sure you log several hours doing the most common tasks in the program. If it's a new operating system, get practice with all it's commands (especially man, or help, or /?, or whatever it's integrated help). If it's a new machine, get comfortable operating it. This way when you come on board, you don't look like a "newbee". It's also a great confidence builder to take the bull by the horns and know you're in familiar territory.
If the new technology is a computer program, buy it or find a friend who will let you log a few hours on his copy. If it's a machine, have a friend help you log some hours on his company's machine. Or maybe you can rent the machine (especially if it's test equipment).
You might wonder why this step doesn't come before getting the job or assignment. Of course it's nice to can get hands-on before getting the job, or even better before beginning the interview process. But not if it delays your job search. The absolute necessity is that you have hands-on before actually showing up for your first day of work on the new job or assignment.
This is what separates the powerhouse from the snake-oil salesman. The snake-oil salesman gets the job under false pretenses and fails at company expense (and ultimately his own). The powerhouse makes the pretenses true, creating wealth for his employers, himself, and his society. So do what the powerhouse does: work 60, 80, or 100 hours a week the first several weeks of the job. But have your timesheets reflect a 45 or 50 week workweek so your new employer doesn't wonder why you're accomplishing so little in so much time.
Take the extra time to finish your assigned work. Read everything you can get your hands on. Practice the techniques you read about. Spend an hour or so every night reviewing what you did that day -- what you did right, what you did wrong, what you learned. Soon enough you'll perform at senior level, and be ready for the next step...
Have you seen anyone burn out? I've seen it, several times. It's not pretty.
You can't go full throttle, continuously, without it affecting your marriage or relationship, your family, your health, or your sanity. For the next few months, simply "do your job". Get really good at it. Discover those little secrets that separate the true master from the merely excellent. Work reasonable hours. Get recreation, exercise, and family time. Force yourself if necessary. Get good and rested. Because the next technology arrives quicker than you think.
Time was, you'd hire a guy out of college, all trained and ready to go. He'd work the next forty years, and just before you gave him the gold watch and going away party, you'd get a replacement out of college. Your training budget? What training budget? You hired college grads, and occasionally people trained by other companies.
Now you hire a guy, and he's totally, completely obsolete in two years. Unless you give him continuing training. And the minute you train him, he jumps ship for a company giving him 10% more. You spend $3000 for training, per employee, per year, but the performance you get in return is less than stellar. What's an employer to do?
You know many contemporaries who take a hard line. Demand years of experience in all relevant skills. Work em to death for two years, and when they've fallen behind the technology lay em off and get someone fresh. You've seen the quality of employee these businesses attract, and the level of employee commitment. So have their customers, who are deserting en masse. You've seen the incredible turnover costs these businesses incur, and the incredible salary premiums they substitute for employee career advancement and satisfaction. No, that's a road you don't want to go down.
Then there are your fellow executives spending a small fortune sending their employees to every conceivable training course. So much training they're always down a couple employees, affecting responsiveness to the customer. And you've heard about trainee conduct in these courses. How most of the trainees are there for the free coffee and donuts, and to get to away from phone calls and demanding bosses. A paid vacation, if you will. And worst of all, how once they've been trained in a hot, marketable technology, they quit to work for someone else. That's a sucker-bet you're just not taking.
So what's an employer to do? First and foremost, I think both employee and employer must understand that with technology obsolescence half-times approaching a year, the employee must learn, not be taught. I'm not saying employees should never attend courses -- just that they should go to learn, not to be taught (and certainly not to snarf donuts and daydream). So in this new era of instant obsolescence, hire proven learners. Don't ask the prospective employee to prove that he's already doing the technology you're doing today, ask him to prove a track record of learning similar technologies in the past. Then give your people a real incentive to learn, both on the job and off. When they acquire a new skill related to your business, give them a raise right away, before your business park neighbors do. Understand that a big part of compensation is a learning-friendly environment. Don't give them busy-work because it's cheaper than hiring a secretary, an assistant, or a courier. Don't work them 65 hours a week (80 during emergencies), and expect them to learn on their own time. They'll be gone!
On the other hand, those employees who don't learn and won't make the effort and take the responsibility to learn, must be shown the door. Now that everyone's working so hard to do and learn at the same time, it's vital for morale that *everyone* contributes. Those wanting an unchanging job will work as a lifeguard or cab driver.
Don't send them to training willy-nilly. Make them prove there's an immediate and pressing business need for them to quickly learn the material, before signing the check. When they recommend a new technology, make them prove the business sense it makes. Listen carefully and evaluate.
Make your employees a part of your technology decisions. There's nothing that turns a good workforce bad quicker than a bunch of "suits" adopting the wrong technologies, then trying to horse-whip the "techies" into making it work.
Be nice to your employees. A smile and a good word cost nothing. Give them honest feedback, and when the feedback is negative, work with them toward a resolution. Be respectful of their time. And above all, please, please, PLEASE respect their intelligence.
Respect their intelligence. Don't say "we expect our employees to be entrepreneurial", then pay them straight salary, while the Wall Street Journal reports your company's outstanding stockholder gains and executives' generous bonuses. Don't tell them "your advancement here is commensurate with your ability" when your policies forbid more than a 7% per year salary increase.
Respect their intelligence. Don't tell them "we don't count the hours here", then dock them or scold them for those occasional weeks when they come in less than 40 hours instead of more.
Respect their intelligence. No cutesy little posters showing little business cliches (things go smoother when we all pull the same direction) in a cartoon with children, animals, carrots and sticks.
Respect their intelligence. No lofty sounding names for programs of the month. The only true "employee enrichment program" is a raise.
Respect their intelligence. Give em the authority to do the job they've been given.
Respect their intelligence. No silly team building exercises. They stopped going on treasure hunts in grade school. Instead, give the team a real problem, real authority to solve the problem, and real compensation as a team when they solve it. They're smart enough to do the rest.
You hire your employees to be smart. Treat them accordingly!
It's simple really. Now that total obsolescence happens every couple years, hire based on an ability to simultaneously learn and do. Then create an atmosphere where they can happily do just that, and where they're rewarded for it on a timely basis.
Higher Education is about to come full-circle. Time was students learned only generalist core skills inside the ivy. By the 1970's, it was obvious generalist education wasn't preparing them for the jobs of the day, so colleges and universities responded by teaching technology. Now that the student's third year technology courses are obsolete diploma day, colleges and universities must respond again. Today's higher education focus must be on learning to learn, and on generalist core skills.
Give a man a fish, you feed him today. Teach him to fish, you feed him for life. Today's graduate must re-learn his technical skillset twenty times over the course of his career. Teaching specific technologies puts bread on his table for 18 months. Then what? Increasingly, success will belong to the rapid learner.
What process is used to learn? Where do you find the terminology? What attitude should you adopt while learning? What tools and props can help you? How can you refine and improve your ability to learn? How is learning ability individual, and how is it universal? What are the limitations, and how can they be circumvented?
Colleges and universities in the US are graduating students who can't effectively write or speak English. How will they conduct a job interview? How will they work with a team? How will they describe their discoveries? This must change.
All technology stands on the shoulders of what came before it. Today's technical student must know, at an intellectual and intuitive level, ohms law, physics, statics and dynamics, radiation theory, thermodynamics, geometry, calculus. He need not learn every last equation, as long as he learns where to look it up and how to use it when he finds it.
This core skill is often overlooked. Behind every "how to", there's a process. Understanding, appreciation, and use of processes must be learned in high school and college.
No design springs fully formed into the world. A fundamental part of the design process, and often the biggest, is troubleshooting. This must be recognized as a core skill. It must be learned in high school, and mastered in college. It's no longer practical for employees to spend their first couple years on the job without Troubleshooting Process knowledge.
Behind every successful technician, there's sales competency. There are thousands of programmers as skilled as Bill Gates. Which one made billions? Sales ability is the single most accurate predictor of monetary success. It's also a vital part of technological success. The greatest technology in the world is worthless without the ability to persuade others to use it. What every happened to superior products like the Atari ST, the Commodore Amiga, the GEM operating system?
It doesn't need to be called "sales". If it's more comfortable to call it "persuasion", "negotiation", "conflict resolution", "training for teams", by all means call it that. Just make sure the student learns to effectively persuade others, including persuading them to part with a hard-earned dollar. Without this, you're turning out graduates useless to Industry.
The cliche is true -- this is a global economy. Lack of a foreign language restricts the graduates opportunities, and those of his employer.
For several months I've asked you to vote on whether I should continue writing Troubleshooting Professional Magazine. The votes are in, the decision made.
There were very few votes, as expected. My stats indicate Troubleshooting Professional Magazine claims only a small portion of Troubleshooters.Com's readership. However, the votes that came in all said the same thing: "We love it, keep it". So I'm keeping it, but changing the format. Starting next month, Troubleshooting Professional will be a smaller magazine, often with just one article per month. This will allow the continuation of the magazine without the pressure of cannibalizing my other work. So Troubleshooting Professional lives on into 1998.
You asked for it, you got it.
We anticipate two to five articles per issue, with issues coming out monthly. We look for articles that pertain to the Troubleshooting Process. This can be done as an essay, with humor, with a case study, or some other literary device. A Troubleshooting poem would be nice. Submissions may mention a specific product, but must be useful without the purchase of that product. Content must greatly overpower advertising. Submissions should be between 250 and 2000 words long.
All submissions become the property of the publisher (Steve Litt), unless other arrangements are previously made in writing. We do not currently pay for articles. Troubleshooters.Com reserves the right to edit any submission for clarity or brevity. Any published article will include a two sentence description of the author, a hypertext link to his or her email, and a phone number if desired. Upon request, we will include a hypertext link, at the end of the magazine issue, to the author's website, providing that website meets the Troubleshooters.Com criteria for links and that the author's website first links to Troubleshooters.Com.
Submissions should be emailed to Steve Litt's email address, with subject line Article Submission. The first paragraph of your message should read as follows (unless other arrangements are previously made in writing):
After that paragraph, write the title, text of the article, and a two sentence description of the author.
www.troubleshooters.com: Steve Litt's website.
www.troubleshooters.com/stats.html: Statistics page for Troubleshooters.Com.