This is the text of the Commencement address by Steve Jobs, CEO of Apple Computer and of Pixar Animation Studios, delivered on June 12, 2005.
I am honored to be with you today at your commencement from one of the finest universities in the world. I never graduated from college. Truth be told, this is the closest I've ever gotten to a college graduation. Today I want to tell you three stories from my life. That's it. No big deal. Just three stories.
The first story is about connecting the dots.
I dropped out of Reed College after the first 6 months, but then stayed around as a drop-in for another 18 months or so before I really quit. So why did I drop out?
It started before I was born. My biological mother was a young, unwed college graduate student, and she decided to put me up for adoption. She felt very strongly that I should be adopted by college graduates, so everything was all set for me to be adopted at birth by a lawyer and his wife. Except that when I popped out they decided at the last minute that they really wanted a girl. So my parents, who were on a waiting list, got a call in the middle of the night asking: "We have an unexpected baby boy; do you want him?" They said: "Of course." My biological mother later found out that my mother had never graduated from college and that my father had never graduated from high school. She refused to sign the final adoption papers. She only relented a few months later when my parents promised that I would someday go to college.
And 17 years later I did go to college. But I naively chose a college that was almost as expensive as Stanford, and all of my working-class parents' savings were being spent on my college tuition. After six months, I couldn't see the value in it. I had no idea what I wanted to do with my life and no idea how college was going to help me figure it out. And here I was spending all of the money my parents had saved their entire life. So I decided to drop out and trust that it would all work out OK. It was pretty scary at the time, but looking back it was one of the best decisions I ever made. The minute I dropped out I could stop taking the required classes that didn't interest me, and begin dropping in on the ones that looked interesting.
It wasn't all romantic. I didn't have a dorm room, so I slept on the floor in friends' rooms, I returned coke bottles for the 5¢ deposits to buy food with, and I would walk the 7 miles across town every Sunday night to get one good meal a week at the Hare Krishna temple. I loved it. And much of what I stumbled into by following my curiosity and intuition turned out to be priceless later on. Let me give you one example:
Reed College at that time offered perhaps the best calligraphy instruction in the country. Throughout the campus every poster, every label on every drawer, was beautifully hand calligraphed. Because I had dropped out and didn't have to take the normal classes, I decided to take a calligraphy class to learn how to do this. I learned about serif and san serif typefaces, about varying the amount of space between different letter combinations, about what makes great typography great. It was beautiful, historical, artistically subtle in a way that science can't capture, and I found it fascinating.
None of this had even a hope of any practical application in my life. But ten years later, when we were designing the first Macintosh computer, it all came back to me. And we designed it all into the Mac. It was the first computer with beautiful typography. If I had never dropped in on that single course in college, the Mac would have never had multiple typefaces or proportionally spaced fonts. And since Windows just copied the Mac, its likely that no personal computer would have them. If I had never dropped out, I would have never dropped in on this calligraphy class, and personal computers might not have the wonderful typography that they do. Of course it was impossible to connect the dots looking forward when I was in college. But it was very, very clear looking backwards ten years later.
Again, you can't connect the dots looking forward; you can only connect them looking backwards. So you have to trust that the dots will somehow connect in your future. You have to trust in something — your gut, destiny, life, karma, whatever. This approach has never let me down, and it has made all the difference in my life.
My second story is about love and loss.
I was lucky — I found what I loved to do early in life. Woz and I started Apple in my parents garage when I was 20. We worked hard, and in 10 years Apple had grown from just the two of us in a garage into a $2 billion company with over 4000 employees. We had just released our finest creation — the Macintosh — a year earlier, and I had just turned 30. And then I got fired. How can you get fired from a company you started? Well, as Apple grew we hired someone who I thought was very talented to run the company with me, and for the first year or so things went well. But then our visions of the future began to diverge and eventually we had a falling out. When we did, our Board of Directors sided with him. So at 30 I was out. And very publicly out. What had been the focus of my entire adult life was gone, and it was devastating.
I really didn't know what to do for a few months. I felt that I had let the previous generation of entrepreneurs down - that I had dropped the baton as it was being passed to me. I met with David Packard and Bob Noyce and tried to apologize for screwing up so badly. I was a very public failure, and I even thought about running away from the valley. But something slowly began to dawn on me — I still loved what I did. The turn of events at Apple had not changed that one bit. I had been rejected, but I was still in love. And so I decided to start over.
I didn't see it then, but it turned out that getting fired from Apple was the best thing that could have ever happened to me. The heaviness of being successful was replaced by the lightness of being a beginner again, less sure about everything. It freed me to enter one of the most creative periods of my life.
During the next five years, I started a company named NeXT, another company named Pixar, and fell in love with an amazing woman who would become my wife. Pixar went on to create the worlds first computer animated feature film, Toy Story, and is now the most successful animation studio in the world. In a remarkable turn of events, Apple bought NeXT, I returned to Apple, and the technology we developed at NeXT is at the heart of Apple's current renaissance. And Laurene and I have a wonderful family together.
I'm pretty sure none of this would have happened if I hadn't been fired from Apple. It was awful tasting medicine, but I guess the patient needed it. Sometimes life hits you in the head with a brick. Don't lose faith. I'm convinced that the only thing that kept me going was that I loved what I did. You've got to find what you love. And that is as true for your work as it is for your lovers. Your work is going to fill a large part of your life, and the only way to be truly satisfied is to do what you believe is great work. And the only way to do great work is to love what you do. If you haven't found it yet, keep looking. Don't settle. As with all matters of the heart, you'll know when you find it. And, like any great relationship, it just gets better and better as the years roll on. So keep looking until you find it. Don't settle.
My third story is about death.
When I was 17, I read a quote that went something like: "If you live each day as if it was your last, someday you'll most certainly be right." It made an impression on me, and since then, for the past 33 years, I have looked in the mirror every morning and asked myself: "If today were the last day of my life, would I want to do what I am about to do today?" And whenever the answer has been "No" for too many days in a row, I know I need to change something.
Remembering that I'll be dead soon is the most important tool I've ever encountered to help me make the big choices in life. Because almost everything — all external expectations, all pride, all fear of embarrassment or failure - these things just fall away in the face of death, leaving only what is truly important. Remembering that you are going to die is the best way I know to avoid the trap of thinking you have something to lose. You are already naked. There is no reason not to follow your heart.
About a year ago I was diagnosed with cancer. I had a scan at 7:30 in the morning, and it clearly showed a tumor on my pancreas. I didn't even know what a pancreas was. The doctors told me this was almost certainly a type of cancer that is incurable, and that I should expect to live no longer than three to six months. My doctor advised me to go home and get my affairs in order, which is doctor's code for prepare to die. It means to try to tell your kids everything you thought you'd have the next 10 years to tell them in just a few months. It means to make sure everything is buttoned up so that it will be as easy as possible for your family. It means to say your goodbyes.
I lived with that diagnosis all day. Later that evening I had a biopsy, where they stuck an endoscope down my throat, through my stomach and into my intestines, put a needle into my pancreas and got a few cells from the tumor. I was sedated, but my wife, who was there, told me that when they viewed the cells under a microscope the doctors started crying because it turned out to be a very rare form of pancreatic cancer that is curable with surgery. I had the surgery and I'm fine now.
This was the closest I've been to facing death, and I hope its the closest I get for a few more decades. Having lived through it, I can now say this to you with a bit more certainty than when death was a useful but purely intellectual concept:
No one wants to die. Even people who want to go to heaven don't want to die to get there. And yet death is the destination we all share. No one has ever escaped it. And that is as it should be, because Death is very likely the single best invention of Life. It is Life's change agent. It clears out the old to make way for the new. Right now the new is you, but someday not too long from now, you will gradually become the old and be cleared away. Sorry to be so dramatic, but it is quite true.
Your time is limited, so don't waste it living someone else's life. Don't be trapped by dogma — which is living with the results of other people's thinking. Don't let the noise of others' opinions drown out your own inner voice. And most important, have the courage to follow your heart and intuition. They somehow already know what you truly want to become. Everything else is secondary.
When I was young, there was an amazing publication called The Whole Earth Catalog, which was one of the bibles of my generation. It was created by a fellow named Stewart Brand not far from here in Menlo Park, and he brought it to life with his poetic touch. This was in the late 1960's, before personal computers and desktop publishing, so it was all made with typewriters, scissors, and polaroid cameras. It was sort of like Google in paperback form, 35 years before Google came along: it was idealistic, and overflowing with neat tools and great notions.
Stewart and his team put out several issues of The Whole Earth Catalog, and then when it had run its course, they put out a final issue. It was the mid-1970s, and I was your age. On the back cover of their final issue was a photograph of an early morning country road, the kind you might find yourself hitchhiking on if you were so adventurous. Beneath it were the words: "Stay Hungry. Stay Foolish." It was their farewell message as they signed off. Stay Hungry. Stay Foolish. And I have always wished that for myself. And now, as you graduate to begin anew, I wish that for you.
Stay Hungry. Stay Foolish.
Thank you all very much.
Wednesday, April 30, 2008
Tuesday, April 8, 2008
Ten traits to look for when hiring a programmer
Programmers come with a wide range of skill sets, hail from many countries and cultures and can have differing backgrounds and experiences. Nevertheless, certain qualities can mean the difference between a great programmer and someone who's not so great. Here are 10 things to look for when hiring a programmer.
1. Curiosity Great programmers never accept things "as is"; they need to poke deep inside something, even when it appears to be working fine, to learn more. This is how many problems are solved before they are problems, and it's usually the quickest way to fix acute issues. A programmer without this mentality will usually end up lacking the knowledge underlying why they are doing what they are doing, which means they're working with blinkers on. Unless candidates are very shy, their curiosity, if they have it, will show strongly during interviews.
2. Clear thinking skills It may sound obvious, but programming is an exercise in logic. People who can add two and two to get four are common, but people who can take "2 + x = 4" and figure out that "x" is equal to 2 are much less common.
This is why I have always preferred programmers with strong maths or science backgrounds. It makes them a bit better at programming but, more importantly, it generally indicates good logic skills. When I discuss the job, I sometimes leave blanks in what I'm saying to see if the candidate can fill them in. In addition, if your hiring process includes formal testing, that's a good time to test logic skills.
3. Top-flight reading speed and comprehension Another "duh" when it comes to programmer productivity is that most of their work is not the typing of the code. A significant portion of a programmer's day is spent reading, whether it be other people's code, websites with examples, documentation or project specs.
Programmers who read slowly or, worse, don't understand what they're reading, will be inefficient at best and dangerous at worst. You probably don't want someone on your staff who misreads the spec and spends three weeks doing the wrong thing; that's just embarrassing when you need to explain the delay to the project sponsors. It's really hard to gauge reading skills during the hiring process unless you use a formal testing process.
4. Attention to detail Attention to detail is a close cousin to curiosity. A programmer who pays attention to detail will tend to be significantly more productive than one who doesn't. It is, unfortunately, extremely difficult to measure this quality during the hiring process. Still, sometimes things happen during the hiring process that show that a candidate has this trait. Maybe it's a casual remark or just a minor incident that occurs during the interview.
For example, I once had an interviewee casually compliment me on my shirt and mention that he was a fan of that designer; that spoke volumes about his attention to detail. Of course, a severe lack of attention to detail can sometimes be obvious too; the candidate who walks in with trousers unbuttoned or toilet paper stuck to a shoe is clearly not paying attention to detail!
5. Quick learner outside programming Unless your company develops programming tools, such as compilers and IDEs, your programmers are working with projects outside the realm of programming. Just as journalists need to understand a little bit about the subjects of their stories and good teachers need a working knowledge of the field they're teaching, good programmers are able to learn about the environment their software will work within. Of course, you don't need a CPA with a computer-science degree to work on your accounting software, but a programmer who can't understand the basics of the maths and business rules involved is going to be a liability.
I take candidates I'm seriously considering on a tour of the facility and provide a brief, simple, jargon-free overview of the company and how it works. Candidates who ask pointed questions that show they understand what I'm talking about, or who otherwise show comprehension, get extra credit in the overall hiring decision.
6. Self-learning skills It's rare for a programming shop to have the budget and time to provide training to its programmers. This is unfortunate, but it's a business reality. The result is that most programmers self-teach their skill sets (ideally with a mentor handy) once their formal schooling is over. Programmers who are good at self-learning are going to be better at programming.
During the interview process, I like to ask questions such as: "How did you learn to do that?", when the candidate talks about something difficult; or: "How do you get new skills?"; and: "Do you read any programming-related books, magazines, websites, blogs, etc?". Candidates who aren't just capable but who are eager to teach themselves new programming skills......tend to be much better to have on your staff than those who don't like to learn outside a formal training program.
7. Passion Some programmers are "daycoders": people who write code 9 to 5, Monday to Friday. They don't think about it in the slightest outside those hours. That's perfectly fine; not everyone can be a super geek who lives and breathes code. I have hired people like this in the past to fill a gap or to work on the sections of a project that are routine. But when I need to hire a top programming candidate (regardless of skill or experience level), I need to be hiring someone with a passion for the work.
Passion is a "make or break" during crunch time or on a project that requires tricky techniques, rare skills, and so on. After all, daycoders won't be motivated to learn the best way of doing things and will instead just do what they've always done, which may not be the best way of doing things. Daycoders are also difficult to retain without a steady stream of raises and a high level of perks, since they are there for the money, not for the work. Passion will be fairly obvious during the interview. Candidates who get excited when you talk about your project or who are talking about their past projects are the ones who display their passion for the role.
8. Adaptability Have you ever worked on a programming project that ended with the same specs it started with? Neither have I, and I am including short projects that lasted less than a day! Programmers who don't handle change well will probably not be very successful, except on long-term, waterfall-type projects that last years, usually under government contract. That is not to denigrate those kinds of projects or programmers, of course. But most projects are simply incompatible with a lack of adaptability.It's pretty obvious during interviews when candidates are not adaptable or handle change poorly, particularly if you ask questions such as: "Did the requirements change often?" Candidates who say something like: "Sure, but that happens on all projects and it's a fact of life", are winners. Those who roll their eyes and respond with: "Yeah, that's why I could never get anything done!" will probably not be a good fit for most environments.
9. Good communication skills "Communication skills" doesn't mean the same thing as "speaks perfect English": it means "being able to convey an idea accurately and effectively". Pictures, sounds and hand motions are all part of communication skills. Programmers who have a hard time getting their point across or understanding what others are trying to tell them will not be effective in the long run. This is a difficult ability to properly measure in a phone interview, but when candidates have difficulty communicating even in a face-to-face interview, you can be sure that they'll have a hard time on the job as well.
10. Who's the boss? Programmers are a notoriously independent group of people. Indeed, I believe that's one of their strengths and it's great not having to micro-manage people working on technical projects. However, a good portion of programmers struggle with the idea of "I am the boss and you are not." I know, it sounds tyrannical. In a way, it is. Managers often need to make decisions for nontechnical reasons and they may not be able to explain those reasons to their team (secrecy, politics, not enough time, etc).
A little bit of pushback, particularly on bad decisions, is something I encourage and fully support, especially if the boss doesn't realise that it is a bad decision and if the feedback is delivered correctly. But when the boss says, "I know from the technical perspective this is a bad idea, but this is how we need to do it," it's final. All too often, certain "rogue coders" will ignore their marching orders and go do their own thing. Even worse, they have a tendency to run their mouth to anyone and everyone about how stupid the boss is and how he or she obviously does not understand programming — which may or may not be true. This sinks projects and does nothing but cause animosity and hurt team morale.
This mentality can often be seen during the interview process, especially when you're asking about past work experiences. Rogue coders love to talk about their "evil, idiot, pointy-haired slave driver" former managers, even when it is wholly inappropriate to do so, like in a job interview. Well-adjusted programmers will say things such as, "I disagreed with some of my manager's decisions at a technical level, but I know that those decisions had to have non-technical issues factored into them."
1. Curiosity Great programmers never accept things "as is"; they need to poke deep inside something, even when it appears to be working fine, to learn more. This is how many problems are solved before they are problems, and it's usually the quickest way to fix acute issues. A programmer without this mentality will usually end up lacking the knowledge underlying why they are doing what they are doing, which means they're working with blinkers on. Unless candidates are very shy, their curiosity, if they have it, will show strongly during interviews.
2. Clear thinking skills It may sound obvious, but programming is an exercise in logic. People who can add two and two to get four are common, but people who can take "2 + x = 4" and figure out that "x" is equal to 2 are much less common.
This is why I have always preferred programmers with strong maths or science backgrounds. It makes them a bit better at programming but, more importantly, it generally indicates good logic skills. When I discuss the job, I sometimes leave blanks in what I'm saying to see if the candidate can fill them in. In addition, if your hiring process includes formal testing, that's a good time to test logic skills.
3. Top-flight reading speed and comprehension Another "duh" when it comes to programmer productivity is that most of their work is not the typing of the code. A significant portion of a programmer's day is spent reading, whether it be other people's code, websites with examples, documentation or project specs.
Programmers who read slowly or, worse, don't understand what they're reading, will be inefficient at best and dangerous at worst. You probably don't want someone on your staff who misreads the spec and spends three weeks doing the wrong thing; that's just embarrassing when you need to explain the delay to the project sponsors. It's really hard to gauge reading skills during the hiring process unless you use a formal testing process.
4. Attention to detail Attention to detail is a close cousin to curiosity. A programmer who pays attention to detail will tend to be significantly more productive than one who doesn't. It is, unfortunately, extremely difficult to measure this quality during the hiring process. Still, sometimes things happen during the hiring process that show that a candidate has this trait. Maybe it's a casual remark or just a minor incident that occurs during the interview.
For example, I once had an interviewee casually compliment me on my shirt and mention that he was a fan of that designer; that spoke volumes about his attention to detail. Of course, a severe lack of attention to detail can sometimes be obvious too; the candidate who walks in with trousers unbuttoned or toilet paper stuck to a shoe is clearly not paying attention to detail!
5. Quick learner outside programming Unless your company develops programming tools, such as compilers and IDEs, your programmers are working with projects outside the realm of programming. Just as journalists need to understand a little bit about the subjects of their stories and good teachers need a working knowledge of the field they're teaching, good programmers are able to learn about the environment their software will work within. Of course, you don't need a CPA with a computer-science degree to work on your accounting software, but a programmer who can't understand the basics of the maths and business rules involved is going to be a liability.
I take candidates I'm seriously considering on a tour of the facility and provide a brief, simple, jargon-free overview of the company and how it works. Candidates who ask pointed questions that show they understand what I'm talking about, or who otherwise show comprehension, get extra credit in the overall hiring decision.
6. Self-learning skills It's rare for a programming shop to have the budget and time to provide training to its programmers. This is unfortunate, but it's a business reality. The result is that most programmers self-teach their skill sets (ideally with a mentor handy) once their formal schooling is over. Programmers who are good at self-learning are going to be better at programming.
During the interview process, I like to ask questions such as: "How did you learn to do that?", when the candidate talks about something difficult; or: "How do you get new skills?"; and: "Do you read any programming-related books, magazines, websites, blogs, etc?". Candidates who aren't just capable but who are eager to teach themselves new programming skills......tend to be much better to have on your staff than those who don't like to learn outside a formal training program.
7. Passion Some programmers are "daycoders": people who write code 9 to 5, Monday to Friday. They don't think about it in the slightest outside those hours. That's perfectly fine; not everyone can be a super geek who lives and breathes code. I have hired people like this in the past to fill a gap or to work on the sections of a project that are routine. But when I need to hire a top programming candidate (regardless of skill or experience level), I need to be hiring someone with a passion for the work.
Passion is a "make or break" during crunch time or on a project that requires tricky techniques, rare skills, and so on. After all, daycoders won't be motivated to learn the best way of doing things and will instead just do what they've always done, which may not be the best way of doing things. Daycoders are also difficult to retain without a steady stream of raises and a high level of perks, since they are there for the money, not for the work. Passion will be fairly obvious during the interview. Candidates who get excited when you talk about your project or who are talking about their past projects are the ones who display their passion for the role.
8. Adaptability Have you ever worked on a programming project that ended with the same specs it started with? Neither have I, and I am including short projects that lasted less than a day! Programmers who don't handle change well will probably not be very successful, except on long-term, waterfall-type projects that last years, usually under government contract. That is not to denigrate those kinds of projects or programmers, of course. But most projects are simply incompatible with a lack of adaptability.It's pretty obvious during interviews when candidates are not adaptable or handle change poorly, particularly if you ask questions such as: "Did the requirements change often?" Candidates who say something like: "Sure, but that happens on all projects and it's a fact of life", are winners. Those who roll their eyes and respond with: "Yeah, that's why I could never get anything done!" will probably not be a good fit for most environments.
9. Good communication skills "Communication skills" doesn't mean the same thing as "speaks perfect English": it means "being able to convey an idea accurately and effectively". Pictures, sounds and hand motions are all part of communication skills. Programmers who have a hard time getting their point across or understanding what others are trying to tell them will not be effective in the long run. This is a difficult ability to properly measure in a phone interview, but when candidates have difficulty communicating even in a face-to-face interview, you can be sure that they'll have a hard time on the job as well.
10. Who's the boss? Programmers are a notoriously independent group of people. Indeed, I believe that's one of their strengths and it's great not having to micro-manage people working on technical projects. However, a good portion of programmers struggle with the idea of "I am the boss and you are not." I know, it sounds tyrannical. In a way, it is. Managers often need to make decisions for nontechnical reasons and they may not be able to explain those reasons to their team (secrecy, politics, not enough time, etc).
A little bit of pushback, particularly on bad decisions, is something I encourage and fully support, especially if the boss doesn't realise that it is a bad decision and if the feedback is delivered correctly. But when the boss says, "I know from the technical perspective this is a bad idea, but this is how we need to do it," it's final. All too often, certain "rogue coders" will ignore their marching orders and go do their own thing. Even worse, they have a tendency to run their mouth to anyone and everyone about how stupid the boss is and how he or she obviously does not understand programming — which may or may not be true. This sinks projects and does nothing but cause animosity and hurt team morale.
This mentality can often be seen during the interview process, especially when you're asking about past work experiences. Rogue coders love to talk about their "evil, idiot, pointy-haired slave driver" former managers, even when it is wholly inappropriate to do so, like in a job interview. Well-adjusted programmers will say things such as, "I disagreed with some of my manager's decisions at a technical level, but I know that those decisions had to have non-technical issues factored into them."
Subscribe to:
Posts (Atom)
