Showing posts with label experience. Show all posts
Showing posts with label experience. Show all posts

Sunday, July 15, 2018

What motivated you to learn to code?

I received an interesting question, today: "What motivated you to learn to code?"

Maybe it's old age, but my memory for ancient events seems to have improved. I remember quite clearly those days, back in the 1950s, when I worked as a "computer." That was my job title, computer. I did physics calculations with pencil and paper—and an eraser.

At that time,I had never seen a computing machine, nor another person who had ever seen one. 

When I left graduate school, I went to work for IBM in San Francisco. Nobody else in the IBM office had ever seen a computing machine, at least not a stored program one. We had a machine with 10 wireable instructions (IBM 604) and one 10-digit word of data storage. I was motivated to learn to code that machine by a one-dollar bet that I could turn on all the lights on the console. I won the bet.            

The first stored program machine (IBM 650, with 1,000 words of drum memory) was due in the IBM office two weeks after I started there. I was given the assignment of learning how to program it, as nobody else in the office had a clue. I learned to code by reading the machine manuals for two weeks.

Also, two weeks after the machine arrived, I had to teach a programming class to three other new hires. So, that assignment also motivated me. When the machine arrived, I was the only one who dared to touch it for two weeks, so I wrote programs for the sort of calculations I had been doing in my job as a computer.


It was the thrill of a lifetime.


Tuesday, November 07, 2017

When do I know I'm not a beginning programmer any more?

I was asked, "When do I know I'm not a beginning programmer any more?"

I wouldn’t answer this question, because it’s the wrong question.

You should not ever want to know you’re not a beginner, because a true professional is always a beginner. The world in general, and the world of programming in particular, is so complex, so huge, that one lifetime is not long enough to stop being a beginner.

Your beginner’s mind is one of your most valuable tools. It requires you to look at each situation afresh, and to innovate. (Fundamentally, that's what the Agile movement is all about.) If you know children, watch how they use their beginner’s minds to conquer their world.

I’m very suspicious of people in the programming field who think they are no longer beginners. Myself, I’ve been programming for about 70 years, and I still consider myself a beginner.




Monday, October 23, 2017

Where do old programmers go?

As far as I can tell, I’m the oldest old programmer to answer this question so far. I’m so old that the title “programmer” didn’t even exist when I started.

I celebrate my 84th birthday this week, and as far as I know, most of the programmers who were around under various titles when I started (in 1956, maybe 20 of us in the USA) are now dead. I hope they’ve gone to heaven (the cloud?).

Myself, I gradually ceased writing code for money and transitioned to training younger people to be outstanding professional programmers. I still write lots of code for my own use and amusement and learning, but it’s been at least 40 years since I could tolerate writing code for a boss who didn’t understand what programming was all about.

I’ve earned multiple livings as consultant, teacher, and writer. Always about programming, but more about design rather than coding details as the years went by. If you’re good, you can do any of these things even at advanced age, but you can’t just sit around waiting for someone to find you.

If you’re not good, than either get good (it’s never too late) or retire. We don’t need mediocre programmers, and we never did.


Sunday, September 03, 2017

Why is reading or writing something different from doing something?

First consider reading. Reading is (usually) a solitary activity, with no feedback. Without feedback, there's no check on what you believe you're learning.

Now, writing. Unless you put your writing in the hands of someone (or perhaps some computer analysis app), there's also no feedback, so there's no check on whether you wrote sense or nonsense.

When you do something, you interact with the real world, and the world responds in some way. With the world's feedback, you have the possibility of learning, confirming, or disconfirming something. That's why we strongly favor experiential learning over, say, lecturing or passive reading or writing.

If you want to teach somebody something, don't just send them to a book, or, even worse, tell them what you want them to know. Instead, figure out a way to have them experience the situation in which the learning applies.

After they've had the experience, you then might want to send them to a book where they can read about what they experienced.  Alternatively, you might ask them to write about their learning and have you read what they wrote.

You can try this out:

Step 1. Write a sentence or two about what would happen if you tried to move your desk six inches (15 cm) to the left or right.

Step 2. When you finish writing, get up and move your desk six inches (15 cm) to the left or right.

Step 3. What did you learn in steps one and two?



For a far more thorough answer to this question, see my four-volume series on Experiential Learning 



Then do some of the experiential exercises you find there.



Tuesday, August 15, 2017

Must a Developer Know the Language?

We were asked, "Have you ever applied for a software developer job where you didn't know the language?"

My story is not exactly the same as others might have, for several reasons, but I think it does answer the question.

There are two phases to my story. My first job developing software was at IBM, in 1956. At that time, I didn’t know any programming language, largely because there really weren’t any languages other than machine code. So, I spent two weeks in a closet learning my first computer language.

Actually, it was three languages at once: machine codes for the IBM 704 and 650, plus the wired “language” for the IBM 607.

The second phase of my story takes place some years later, when I became a consultant. In that role, I have helped many, many clients who were using languages I didn’t know—even though I knew quite a few by that time, including LISP, Smalltalk, APL, PL/I, COBOL, FORTRAN, C, Pascal, Simula, several home-grown special application languages, and the machine code for the IBM 7090, 1410, 705, STRETCH, Dec’s PDP-1 and a few other machines. I had also studied in a bookish way quite a few other machines while doing competitive analyses for IBM.

I was able to help those clients largely because their problems seldom had much to do with the details of their chosen language(s). Instead, they were people problems of all sorts. The problems that did wind up with a language embodiment were usually easy to spot using my general knowledge of computer languages and typical errors people made in using them. That’s why I’ve always insisted that professional developers should know at least a handful of different language.

I think there's an analogy here with the term "mathematical maturity," something we might call "programming maturity." Here's how Wikipedia defines mathematical maturity:

Mathematical maturity is an informal term used by mathematicians to refer to a mixture of mathematical experience and insight that cannot be directly taught. Instead, it comes from repeated exposure to mathematical concepts. It is a gauge of mathematics student's erudition in mathematical structures and methods.

For instance, a mature mathematician is able to transcend notational differences, unlike my tutorial student who flunked algebra because he had learned to "solve for x," but said, "You didn't teach me to solve for y."


We could easily use most of those words to define "programming maturity," the ability that allows you to succeed in a developer job using a language in which you have no previous experience.


Tuesday, July 04, 2017

Significant Change in Five Minutes

Some people seem so eager to improve their situation that they're in a big hurry to be told:

What can I learn in 5 minutes that can change my life?

If I thought they were able to learn from people telling them things, I would tell them this:

Stop trying for instant, effortless changes in your life.

But, most people probably won't learn this from me telling them. Instead, they will probably have to have some experience that could change their life.

From my telling, they might learn about something, but not really learn, in the sense of putting something new into action. Learning about something is not the same as learning to do something.

Generally, only experiences can really teach people things that would change their lives.

For instance, they might be in an auto accident that would leave them blind, or quadriplegic.

Or, perhaps they would come home one day to discover that their spouse has left them for someone else.

Or, maybe they would be fired from a job they thought was totally secure.

Or, they could win $100,000,000 in the lottery.

Such learnings would change someone's life in five minutes, though they would be followed by many more changes—call them aftershocks.

If that is what they're looking for, they don't need accidents or surprises. They could arrange a life-changing experience for themselves. Parachute out of an airplane. Compete in a triathlon. Volunteer for a month in a soup kitchen or a veterinary hospital.

I suspect, though, that people who ask for five-minute changes are looking for some other kind of change—no pain, no effort, but just something positive and perhaps wonderful, like eating strawberry ice cream instead of vanilla. Well, if that's their desire, they can forget it. It's not going to happen.


I hope you've learned that lesson in the five minutes it took to read this note—but you probably didn't.



Friday, May 26, 2017

Advice to New Graduates

It's now graduation season, time to give advice to new graduates entering the world of work. Every few years, I notice the season and republish some old, but still valid, advice I offered my youngest son, many seasons ago.

Letter to My Son, John
(On the occasion of his graduation with a degree in computer science)

Dear John,
I know some of the other fathers are giving their sons BMWs for graduation, but as a fresh computer science graduate, you're probably going to be earning more than I do as a writer.

It's not totally dishonorable being a writer. Last month, when Dani and I were in Hannibal, Missouri, we visited Mark Twain's birthplace. They've made it into a museum, and it seems to attract a lot of tourists.

Before computer scientists came along, writers used to be pretty famous, and some of them even got rich. So save this letter. You may not appreciate the advice, but someday you might be able to donate it to a museum.

On the wall of the museum, under an old photograph of his schoolhouse, was this quotation from one of Twain's letters:

"I was always careful never to let my schooling interfere with my education."

Being an old-timer in computer science myself, I didn't have to be as careful as Mark Twain. When I went to school, there was no such thing as computer science. There wasn't even a computer—unless you count me (that was my job title).

I made 90 cents an hour inverting matrices for the physics department, using a clunky old Friden, paper, pencil, and lots of erasers. No, I'm not going to advise you to complete your education by inverting some 10 by 10 matrices with a Friden. If I wanted to build your character, I'd buy you a hair shirt for graduation.

Subject Matter
I did want to tell you how lucky you were to have such fine schooling as part of your education. I hope that the next stage of your education will be half as good, which it ought to be, if only you can stay out of the trouble I got into when I was a fresh graduate.

The problems I caused myself weren't due to things I didn't learn in my schooling. As another great American humorist, Will Rogers, said, "It's not what you don't know that gets you in trouble, it's what you know that ain't so."

If my experience is any guide, there are a few parts of your schooling you may want to forget before you report for your first job.

The first and easiest thing you'll have to forget is all the specific facts you learned in your technical courses. If you had majored in Greek grammar, or in the history of rural Belgium in the Middle Ages, you wouldn't have to forget all the facts you so patiently memorized. In some subjects, the facts haven't changed in the past few generations, but you certainly can't say that for Computer Science.

Did you ever stop to think why Computer Science graduates are paid so much more than Greek or History majors? Did you think it was because of the scraggly black beard or your long fingernails? Well, it's not.

It's because Computer Science is high technology—and that means the entire subject matter is changing even as you read these words. The history student is being paid a pittance to remember a body of relatively fixed material, but you're being paid that fabulous salary largely because of your ability to keep pace with innumerable rapid changes.

Being a specialist in information processing, you should be able to understand the process that led to the information you found in your textbooks.  A fact that you found in your freshman textbook would be four years old by now even if it was brand new when you were wearing a beanie. But the book was probably two years old or more by that time, which makes it at least six years out of date.

And you also have to consider that a book takes about a year to publish after it is written, and perhaps two years to write in the first place. You can conservatively add another year for the author's inability to keep up with the latest in new technology.

That makes a nice round ten years for the age of the facts you learned as a freshman. It's not much better for what you learned as a senior—and could be worse, because advanced texts take longer to write, longer to publish, and are too expensive to keep updating every couple of years. Just how long is 10 years of computer technology? Well, I read the other day about the resale value of some System 370 models IBM introduced (ten years ago). Back then, they sold for about $3 million. Today, their book value is exactly zero. The big argument is whether to pay people for hauling them away or to call it even for the scrap value.

IBM used quite a bit of gold and silver in the connectors in these models, which accounts for any value they still have. So, unless you're in collecting precious metals, don't start your career in an organization whose computer is ten years old, either. Keep your gold fillings, but forget whatever facts you learned in school.

But don't worry. It's not so hard to forget facts. Psychological studies show that 24 hours after a lecture, you've forgotten half the facts presented. In the succeeding days, this halving process continues unabated.The same thing happens after an exam—as you certainly must have learned by now.

Once in a while, though, in spite of your best efforts to forget everything, something you learned in school will pop into your head. In that case, just keep it to yourself. The last thing you want to do on your new job is to go broadcasting your ignorance to your coworkers. Instead, close your mouth and open your ears. You might learn something that's new to replace the obsolete fact—which is even better than forgetting.

Grades
Telling your coworkers about all the facts you learned in school is almost as bad as telling them about your grade point average. I know it's hard to accept—especially after all the emphasis on grades the past 16 years of your life—but now that you've landed a job, nobody is interested in your college grades.

But forgetting your grade point average isn't nearly enough. You must also forget everything you know about grades and grading. Business is not school. You may be "graded" on your job, but it won't be on the same basis you were graded on at school.

For instance, when you wrote that little assembler for ComSci 321, you didn't have time to finish the macro facility. So you turned in a partially finished job for a B-plus.

Or that time the micro you designed for ComSci 442 gave the wrong remainder on floating point division. You took an A-minus and were glad to be rid of the thing.

Those strategies don't work on the job. There are no B-plusses for partially completed projects. And no A-minusses for hardware or software with bugs. On the job, you finish your tasks and you finish them right, or you flunk.

Or maybe you think you can take an Incomplete like you did when you didn't want to stop working on that really interesting flow tracer. Or the time you spaced off the last program in advanced programming. Well, forget Incompletes, too.

Specific Plans
If you have a good boss and you're sufficiently interested in something to want to continue working on it, you'll probably be allowed to do it—on your own time—and only after you've turned in the project as assigned. As far as other reasons for Incompletes, forget them.

If you flunk, you won't have to worry about going in to argue with the boss about getting a higher grade. Your boss will call you in before you get a chance.

But don't waste your time preparing arguments for raising your grade. Instead, prepare specific plans for finishing the project or getting rid of the bugs. And also prepare plans for improving your performance on the next assignment. If you don't there may be no next assignment.

Oh, you're not likely to get fired—not in today's business world. More likely, you'll get trivial assignments—and keep getting them until you can prove you're capable of finishing something correctly and on time.

There are no A and B grades. Only A and B assignments. Your college grade average might earn you an A assignment for your first project, but it will never earn you a second.

I know it's a bit frightening to learn that you must get an A on every assignment, but once you've mastered the art of "cheating," it's not nearly as bad as it sounds. Actually, the sound of the word "cheat" is the biggest barrier you'll have to overcome. I don't mean it in the sense of "cheating on your wife" or "cheating at cards," but more in the sense of "cheating death."

By "cheating," I mean going outside the rules that previously bound your thinking. Some instructors say it's cheating to solve an exam problem using a method that wasn't taught in class, or even by looking up the answer. In fact, some instructors still consider it cheating if you use a computer to help you solve your homework! But on the job, you're being paid to use any method that works.

You've spent the past 16 years of your life learning to play by the teacher's rules. Now you're expected to invent your own rules, and you're going to find it difficult to use "any method that works." But once you manage to forget about teachers and their rules, you'll find that this kind of cheating is as natural as drinking beer on a warm summer day.

More natural, actually. Drinking beer is an acquired taste, but breaking the rules is the natural heritage of every human being. Indeed, our superior cheating ability is what differentiates us human beings from all the other animals.

A fox is supposed to be a cunning hunter, but human beings can outhunt any fox that ever lived. How? By cheating, that's how. They "cheat" by getting other people to help them and by using tools invented by other people. You may not call those things cheating, but they sure look like cheating to the fox.

The reason you don't consider cooperation and use of tools as cheating is that you're a human being, not a fox. Your teachers had to forbid "cheating" in school in order to create an environment for teaching facts (which you'll have to forget) and giving grades (which are now worthless). They had to make you forget, temporarily, the basic ability that makes you human—the ability to cooperate.

On the job, you'd better remember your humanity. You don't sign an "honor code" saying you have neither given nor received help. On the contrary, if your boss sees you never help anyone else, or haven't the brains to ask for help when you don't know something, you'll be severely downgraded. If you do everything from scratch and fail to use the simplest shortcuts you can find, you'll be consider an ox, not a fox.

It's actually not that hard to work effectively with other people, even after all those years of isolation. Outside the classroom, where most learning takes place, you have plenty of practice getting and giving help—study groups, team projects, or just those endless conversations over cold coffee in the Union. You may have thought you were just wasting time, but you were actually practicing for the world of work.

Well, I know that's a lot of stuff to forget in so short a time, but I know you can do it if you set your mind to it. Underneath that schoolboy exterior, there beats the heart and throbs the brain of a real human being.

Before you know it, you'll have forgotten all that schooling and gotten on with the business of your education. Good luck!


Love, Dad.

Saturday, December 17, 2016

What's the most touching thing to say to a teacher?

What's the most touching thing to say to a teacher?

The question was, "What's the most touching thing to say to a teacher?" There were many fine answers, and all of them said more or less the same thing: thank your teacher for changing your life.

I agree that telling your teacher “thank you” can be touching, but in my 60+ years of teaching, it’s only the second most touching thing. So, what’s the most touching?

What touches me most is when a student teaches me something I did not know. That shows me that the student has become a contemporary, a grown-up person who will go on to teach others, part of the great chain of “paying forward.” When that happens, I know that I have succeeded in some small way of helping that student and the world in which we all live. That’s what touches me the deepest.

Moreover, in my career such learning has happened thousands of times. If I am a better teacher today, a better human being, I owe it all to my students. Thank you, students. Thank you.


See, Experiential Learning for more on how and why I learn from my students, so you, too, can be touched by what they teach you.