MongoDB, Mongoose, and the Fun Thing That is Data

I never thought I’d say this, but I had lots of fun handling (read: tinkering, manipulating, playing around with) data and databases this week.

(Isn’t that a super geeky thing to say? I mean, who says that? What kind of human being actually says he likes “managing data”. What a nerd.)

And yet, it’s true. I had lots and lots of fun this week learning about MongoDB and Mongoose.

What Kind of Animal is a Mongoose?

So that’s what we’ve been studying all week at Lambda School. In particular, we covered these topics:

  1. Importing data to the MongoDB database.
  2. Modeling relations between collections.
  3. Embedding documents in schemas.
  4. Linking collections together through refs (references).
  5. Populating data in endpoints.
  6. Querying data.
  7. Creating middlewares.
  8. Custom validations.

Essentially, MongoDB is a database. And Mongoose? Well, it can be defined in several technical ways: a JavaScript framework that you can use to interact with your Mongo database; an Object Data Modelling (ODM) library that helps you model your data; and etc. But what was most helpful for me was to think of it simply as a tool or technology that helps you use MongoDB more effectively and efficiently, in the same way that Express is a tool or technology that helps you utilize Node.js better.

The Problem That MongoDB Solves

Why use MongoDB if you can use Node.js? Well, the problem with Node.js is that as soon as your server goes down, your data goes down with it as well. So there’s no data persistence. With MongoDB, the data persists even if you “kill” the server. So that’s the problem MongoDB solves.

If you’re wondering what it looks like, here it is (running on Windows terminal):


The text “[initandlisten] waiting for connections on port 27017” indicates that your Mongo server is up and running.

Once you have that, you need to open a second terminal to run your “Mongo Shell”. It looks like this:

Mongo Shell

You can now navigate through your Mongo databases from here. All you need are a few basic commands:

  1. show dbs (to show the list of databases)
  2. use <insert database name here> (to choose a particular database)
  3. show collections (to open a database and list the collections within it)
  4. db.<insert database name here>.find().pretty() (to display the documents or data within each collection)

The First Things You Need to Know When Studying MongoDB

So the most important terms you need to learn when first studying MongoDB are these:

  1. Databases
  2. Collections
  3. Documents

Documents are simply data (e.g., json files) that are contained within collections, and collections, in turn, are directories contained within databases.

You can do CRUD operations on your data in the MongoDB database through the Mongo Shell in the same way that you can do CRUD operations on your data through Postman and Compass. That is to say, Mongo Shell, Postman, and Compass are these super cool tools that help you create, retrieve, update, and delete data or documents inside your MongoDB database.

Postman looks like this:

Postman June 9, 2018

And Compass looks like this:

Compass June 9, 2018

They’re pretty intimidating to use at first, but are fun to play around with when you get used to them.

They’re certainly very useful to use together when you’re creating your back end applications and testing your endpoints.

Sprint Challenge

By the way, I’m so happy I was able to get to a Minimally Viable Product during our weekly Sprint Challenge today. I worried that I won’t be able to do it because I initially got stuck in trying to wrap my head around the concepts of models, schemas, refs, and data population. I was overjoyed when I was able to create new databases and collections and store documents into them, and when I successfully tested them in Postman. How can technical things like these be so happiness-inducing?


Lambda Ambassador Program

I’ve signed up for Lambda School’s Ambassador Program because I literally cannot stop talking about my school. If you’re interested in getting into their Full Stack Web Development and Software Engineering course, go here:


A Fitbit for Programming

I just discovered (well, technically, it was shared to us by our Program Manager), this awesome tool called WakaTime. It’s a plugin for text editors or Integrated Development Environments (IDEs) that can track the amount of time you’ve spent coding. I started using it three days ago and this is what my stats look like:

WakaTime Stats as of June 9, 2018

Isn’t that super cool? It gives you data on how long you’ve been programming per day, what projects you’re working on, the language/s you used, and the editor you utilized. It’s gives you a super simple way of tracking your productivity.

It’ll probably enhance my development habits from here on out, much in the same way that Fitbit enhances the habit of running in runners.

One of the Best Ways to Learn Programming is to Teach Programming

It is a truism that one of the best ways to learn any new piece of knowledge or skill is to teach it to somebody. That has been one of the main reasons why I’m writing about my experience as a Software Engineering/ Full Stack Web Development student in Lambda School — to retain most of what I’m studying by teaching others about it or talking to people about it in public; in this case, through the medium of the Medium blog.

Last week, we began the back end side of programming by studying Node.js and Express.

What Are Node.js and Express?

In essence, Node.js is a tool that lets you write JavaScript codes outside the web server environment. (Note to Software Engineers: If I’m incorrect about that definition or any of my definitions here, please let me know in the comments.) Its purpose is to create web servers.

We used Express, a popular Node.js library and/or framework, to quickly build web servers. It was fun/fascinating stuff. Basically, we wrote codes that performed CRUD (or Create, Retrieve, Update, and Delete) operations on endpoints. CRUD corresponds to specific HTTP Resource Methods like POST, GET, PUT, and DELETE.

Wait a Minute, Mr Postman

In order to test whether our CRUD operations work (i.e., whether we are really able to create/post new items to our databases, retrieve/get those items (and specific arrays within those items), update/put those same items/arrays, and delete each one of them), we used this cool tool called Postman.


Postman was a big help to me in understanding how CRUD operations or HTTP resource methods worked. And writing the codes for each of those methods wasn’t that difficult because basically there’s a boiler plate for them. The only thing you need to do is understand how they work.

Last Month, I Had Zero Clue About What React Was. Today, I Built a React App.

Tons of things have happened since I last wrote about my Lambda School experience. I have so many things to share and I don’t know where to start.

Well, how about with this:

Front End Project

Building a React Web App From Scratch

That’s a note-taking web app I built using React. It looks quite plain, I know, but what’s amazing about this is that four weeks ago, I didn’t even know what on earth React was. (Remember how worried I was about learning applied JavaScript? It turned out that React was even more challenging to understand, at least initially, than the Document Object Model). Was it a language like JavaScript? Was it a framework? Was it a kind of software? (You can tell by the quality of my questions how much of a newbie I was.)

Now, of course, I know a bit better. It’s actually a JavaScript library for creating or rendering user interfaces.

Obviously, I didn’t build this up in a day. We were given the whole week this week to create and develop it. Our goal was to at least reach a Minimum Viable Product (MVP), and if there’s still time, to add more advanced features like refactoring React to include Redux (another JavaScript library that’s used to manage the state or data of more complex React applications), make the data persist (i.e., make the information that the user inputs into the app, in this case, the “notes”, stay within it), give it some search functionality, give it the ability to convert text into Markdown format, and many others.

Unfortunately, I didn’t get to do any of those stretch goals. But I was happy just to reach MVP.


Just to digress a little bit, I used to just hear about “MVPs” and “bringing a product to market” from podcasts and blogs. For example, I’m a big fan of the Y CombinatorMasters of Scale, and Indie Hackers podcasts. I hear about MVPs, users, product-market fit, “creating something people love”, and so on, all the time. So it’s super surreal that I’m actually starting to do these things already — that is, create a product or software, think about its UI and functionality, be sensitive about what users might want, and etc. To be sure, I still have tons and tons to learn about React and Redux, and miles and miles to go before I come to a place wherein I can say that I’m confident about my ability to build a good product, but at least now I have begun my journey.

Awesome Peers

Anyway, many of my peers were able to add several of those advanced features in their apps. A few of them were even able to do all those stretch tasksWe had a cohort-wide Demo Day earlier and many of their presentations were mind-blowing. It’s challenging enough to add Redux into your React codes, but to include all those other features? Truly impressive. Every single day at Lambda, I feel like I have walked into a room full of brilliant folks, geniuses even. To be honest, I sometimes imagine that I have wandered into a Harvard or Stanford classroom where everyone is just super smart and mentally quick.

Team Standup May 26, 2018

Of course, we’re kind of a mixed bag in our cohort. Some have prior, even professional, exposure or experience with programming. Others, like my wife and I, have only begun to code last March when the mini-bootcamp started. But there were a few who even with relatively-recent programming background was able to achieve impressive feats.

Thank You

So many people have reached out to me to thank me for writing about my journey with Lambda School. Some of them are incoming Lambda School students. I have nothing but gratitude for these guys, and to you dear reader, for reading my articles in the first place.

Next week, we’re going to begin learning about back end stuff. It will probably be more challenging than the material on front end, but it will be exciting nonetheless.

Trusting the System

Today, Lambda School’s fifth batch of students graduated. They demonstrated and defended their capstone projects in front of a panel. I was able to witness it a little bit. One comment from one of the students really struck me. He said to simply “trust the system”. A lot of the stuff that he was learning didn’t make a lot of sense to him during the second month of their curriculum. Heck, it didn’t make much sense to him during the fifth month, either. But suddenly, everything just clicked for him. Everything just made sense and came together: He already knew how to program and he didn’t even realize it.

So, yeah, I want to just “trust the system”, too.

The Fastest, Surest Way to Become a Software Engineer

If you’re interested in becoming a Software Engineer but still quite “ on the fence” about where to learn, let this article be the sign for you. Lambda School is probably the surest and fastest way of achieving that goal. The number of applicants is increasing, so the rate of acceptance will probably decrease a bit. You can increase your chances of getting in if you’ll do the pre-course work or the web development 101 course, which is free. Go here:

My wife and I attended the bootcamp in March. They’ve recently revamped the format to allow the would-be student to get to really experience what it’s like to be in Lambda School. So today’s applicants will get to watch an hour of lecture from an instructor, get to work on a mini-project or assignment for another hour, and have the chance to work with a team and project manager for the last hour to simulate a real team in a tech company.


The Office was a co-working space somewhere uptown frequented by web developers, software engineers, and startup founders. It buzzed with activity and energy during the day, and at night, as you can imagine, the place was bleak and desolate. Ryan liked to go there in the evenings because A, the bulk of his clients were based in the Western Hemisphere, and B, he detested people, or rather, he abhorred direct social interaction.

He parked his car in his usual slot, grabbed his backpack and “lunch” from the backseat, and made his way to the rear entrance. As usual, the Office was going to be all his again tonight. He will hole himself up in his cubicle and code for hours, prowl its dark corridors during his breaks, and convert its couches into his makeshift bed.

He held his proximity card in front of the electronic reader and pushed the glass door open. The scent of coffee immediately greeted his nostrils. The staff always made sure he had enough caffeine every night by preparing the coffee maker for him before they logged out of their shifts.

He closed the door behind him and slowly walked down the hallway.

What he saw, upon turning a corner, almost struck him dead. A girl was walking directly in his direction, carrying a mug in her hand. He couldn’t make out her face clearly, but it was surely a female, and he could see that she, too, was frightened out of her wits by the suddenness of their unexpected encounter. Her gasp was audible to him from where he was standing. The next moment, however, the girl let out a laugh and exclaimed, “Gosh, you scared me!” She had an accent he’s not familiar with.

Extending her hand, she said, “Grace.”


“I’m Grace,” she repeated when he did not respond. “And you are?”

For ten long seconds he could not, for the life of him, recall his own name. No one had ever asked him that before. Not point-blank, that is. He scanned his brain but was unable to retrieve the word that designated his person.

“whoAmI[‘name’];,” he muttered in panic. “console.log(whoAmI[‘name’]);”

“I’m sorry?” the girl said.

He didn’t hear her.

“const whoAmI = {
name: ‘ ‘,
age: ’25’,
location: ‘Cebu City’
},” he said. “console.log(whoAmI[‘name’]);”

She laughed again, and this didn’t help him at all. Blood rushed to his cheeks and all he could say was, “The name property is the object is empty incomplete. It can’t return my name.”

They didn’t speak much after that for he had marched straight to his cubicle, his head bowed down, and did not dare go out again. She did not have her own cubicle, so she took as her spot one portion of the long table directly outside his space. This table was reserved for those who did not want to rent their own private office.

He tried to code but couldn’t get any of his syntaxes right. He could hear her footsteps outside his door. She was talking to someone on her phone.

He stared at his monitor but couldn’t make sense of what his client was really asking him to do. He must have read the instructions a dozen times by now and checked the mockup twice as much, but none of it was registering to him.

He closed all of his applications, restarted his machine, and started afresh. He always did this whenever he felt like he was hitting a brick wall. It was a sort of ritual for him: whenever he was stumped by something — a User Interface he couldn’t render, a feature he couldn’t create, a problem he couldn’t solve — he always resorted to deleting his app’s codebase and begin again from scratch.

In a way, this kind of behavior paralleled his personal life: every time he couldn’t make things work out with someone, for example, he reacted by “deleting” this person from his life. This was what he did with Tanya, almost a year ago now. After telling him that all they could ever be were “friends”, he simply stopped seeing her, ignored her calls, and suppressed all memory of her down to his subconscious mind. He’s pretty sure he’s going to forget her name, eventually, give or take another year.

The knock on the door jolted him out of his musings.

“Hey, sorry about earlier,” the girl called out. “Did I embarrass you? I felt as if I did. If so, I apologize.”

This girl was very sharp. He had spent less than a minute in her presence and already she has read him through and through. Among all the other species of females, he thought, this type was the most dangerous.

“Are you there?” she said.

He had to make some sort of a reply. “Yeah,” he said finally after clearing his throat. “No need to say sorry. It was my fault.”

“Truth is, I’m really glad I’m not alone tonight,” she said behind the door. “This place gives me the creeps, to be honest.”

She waited for his reply.

“Are you new here, too?” she said. He still hasn’t opened the door.

“Yeah, I mean, no,” he stammered. “I’ve been here a while.”

“Oh. I’m new here. Obviously. Tonight’s my first night,” she said.

She waited again.

“So,” she continued. “Where are you connected?”

“I work freelance,” he said.

“Great,” she said. “Are you a developer?”

What gave me away, he thought. “Yes,” he said.

“I guessed as much,” she said.

He felt like the rudest human being on earth for not opening the door for her. Even a weirdo like him knows that he should at the very least open up and invite her in, but he figured that if he only waited for a few seconds more, this conversation, awkward as it was fast becoming, was eventually going to wind up, and she will go away and leave him alone.

It did not end, however, and she did not go away. They talked for a few minutes more. Their conversation was interspersed by numerous bouts of silence, long pauses, and embarrassing “dead airs”, but it stretched on and on and on. He found out that she has just started her own startup and that she was scouting for a technical co-founder. He learned that she’s originally from Sweden, but that she grew up in Germany, finished university in Amsterdam, and is currently traveling Asia to do two things: first, to “find herself”, a very cliche and unoriginal undertaking, she said, and second, to build a company around a tech product she has developed as an intern in Google. She’s a software engineer, too. She did the first phase of her goal last year and is now intent on doing the second.

And the funny thing was, he didn’t mind all this interaction at all. He found that the more he listened to her, the more at ease he felt around her. The more she spoke, the lighter his mood became. And the more he opened up and responded to her, the more he “found” himself, if that makes any sense. He loosened up and rediscovered the joy of “small talk”.

In fact, he got too comfortable that he finally stood up and slid his door open.

You can understand a program. It has its own logic, rules, and algorithms. You can comprehend a component. It has its own language, codes, and syntax. You can definitely cognitively grasp an app, which is composed of programs and components. You can break it down into smaller pieces and make sense of it. You can hold it up in your mind’s eye and peruse it. And that is what he’s been doing all these years — staring at applications upon applications. Analyzing them, thinking about them, and deriving satisfaction from having understood them.

He felt like he can stare at this girl for hundreds of years and not come close to any satisfaction of understanding her. There’s something about her that glows and bursts forth out of her face and skin. Seeing her more clearly now under the orange light above her head and at a closer distance than earlier, he is utterly, completely perplexed. She was her eyes yet she was not her eyes. She was her nose and lips yet she was not her nose and lips. She was her shoulders and arms yet she was neither of those. Her meaning was not contained within any of the physical parts that compose her. You cannot break her down. You cannot make sense of her. She doesn’t have definite properties that you can analyze and map as data, but it’s undeniable that some sort of language was flowing from her, whether she opened her mouth or not.

He took a deep breath and leaned on to his desk for he was quickly losing his balance.

“Ryan,” he said. “Yes, that’s my name. My name’s Ryan.” He remembers it now.

I Went From Dreading JavaScript to Liking It In One Week

A week ago, I expressed apprehension about learning JavaScript. I had the impression that it was going to be a very tough programming language to understand.

Well, I’m actually wrong. It is not really that difficult to understand. You only need to learn its basic terms, concepts, and principles, and voila, you’ll have a working understanding of how it operates.

What We Learned So Far

Throughout this week, that is exactly what we learned in Lambda School — we were taught the fundamental concepts, terms, and principles in JavaScript that will enable us to do effective web development and functional programming.

What were these lessons and concepts? They are numerous, but these are some of the most important:

  • Data Types
  • Variables
  • Arrays
  • Objects
  • Functions
  • Callbacks
  • Closure
  • Function Scope
  • Block Scope
  • Array Methods
  • .forEach, .map, .reduce, and .filter
  • The ‘this’ Keyword
  • Implicit, Explicit, Window, and New Binding
  • Prototypes
  • Constructor functions
  • The ‘class’ Keyword
  • The ‘extend’ Keyword
  • The ‘super’ Keyword
  • Classes

Easy at First

The lessons started out as easy. Data types, variables, arrays, and functions are pretty simple concepts to understand. Data types are the different kinds of data that are dealt with in JavaScript, such as numbers, strings (which can be letters, numbers, and etc., that are enclosed in quotation marks), and Boolean values (i.e., true or false). Variables are just like boxes that can contain values. Arrays are similar to variables but they can contain multiple elements or data, each of which sits on an index. Functions are like little programs that are composed of statements that can do specific tasks.

But as we progressed, our lessons became a bit more challenging. Callbacks are “Higher-Order Functions” or functions that can take in other arguments. Closure refers to the function and the environment within which it is created or defined, including the variables in that environment (i.e., the global scope). Methods are functions that are created inside objects. And so on.

For someone encountering JavaScript for the first time, or relatively recently,  the above ideas are not easy to grasp. A friend in our cohort mentioned to me that it took her many months, or maybe even over a year, to actually begin to understand JavaScript.

What Helped Us Learn

What helped us learn JavaScript are the following:

  1. Reading the curriculum materials/ resources/ documentation prior to class.
  2. Listening intently to the lecture and absorbing as much information as we can.
  3. “Learning with our fingers” (i.e., coding, coding, and coding).

The last one was especially effective for us. As I mentioned before, we would show up to our little office for 2-3 hours before class just so we could review and type out the sample codes in our machines. Then after class, we’d linger for 2-3 hours more just so we could type more. None of this means that we’re good at what we’re doing. It only means that we’re still at the beginner level so we need to catch up by putting in more hours and effort to hammer away at the keyboard.

Awesome Instructor

We are so fortunate because our instructor is such an awesome guy. He is extremely good and experienced in Web Development and he has the ability to teach the concepts in ways that beginner programmers can easily understand. Josh Knell has been in the industry for a very long time. He’s been an adjunct professor in Computer Science and teacher at coding bootcamps for several years. One of the most helpful advice that he reiterates is “Fingers on the keyboard and brain on the lesson”, or words to that effect, which is a really good rule of thumb when learning programming.

One other thing that I really appreciate is that he doesn’t assume that his students can get the lessons right away, or that we can master the concepts quickly or in one go. He always goes to the basics and emphasizes the fundamentals, while at the same time assuring us that we’re doing great.

Layer by Layer

The way the curriculum is designed is that it builds itself up one layer at a time. For instance, on the first day of the week, we powered through the absolute basics — data types, values, functions, and so on. On the second day, we learned about callbacks and closures. On the third and fourth day, we learned about constructor functions, prototypes, and classes. On the fifth day, we tied everything together and applied what we’ve learned in a Sprint Challenge.

So by the end of the week, we already had a good grasp of the week’s lessons. We were given a bird’s eye view of how the pieces come together.

My favorite lesson is the one on constructors and classes. They’re very fascinating. Sets of data, which is what objects contain, are very interesting. They can make a geek out of you. (I’m actually struck by the idea that the process of learning computer science and software engineering is actually a process of becoming a total geek, but that’s a topic for another article.)

Coding Thousands of Miles Apart

Pair Programming

By the way, I really enjoyed Pair Programming. My partner lived in San Diego, so our time difference was huge. But I really loved the experience. It was so surreal to be able to work with someone who’s half-way around the world from you. We did it for almost 4 hours, which is insane, but we hardly felt that time passed. I learned a lot from her, and it made me appreciate more the process of programming.

I think Pair Programming serves multiple purposes:

  • To bring you out of your comfort zone and compel you to become better. You wouldn’t want to be ill-equipped and unprepared when working with a fellow programmer, would you? So the expectation that you’re going to pair-program is going to push you to prepare and practice so that you’ll be able to work at the same level with your partner.
  • To help you develop your communication and interpersonal skills. Social skills are crucial for engineers since they’ll always be working as a team under project managers.
  • To help you learn from your partner and/or impart knowledge and skills to him or her. The students in our cohort are very diverse in terms of background, occupation, profession, gender, age, and location. Some have prior experience with computer science, and some do not. Some are very new to programming, and some have more advanced exposure to the field. There’s always an opportunity to teach and learn.

Cool Tools

I just love our tools! I love to edit with VS Code and tinker with Nodemon. I love the sheer act of typing at the terminal. And I love to add, commit, comment, and push files up to GitHub. I find them to be strangely addictive. Or am I just being too weird and nerdy? Good. A geek is exactly what I want to become (although I already sort of am).

Applying JavaScript

Next week, we’re going to learn how to apply JS on web development. We’ll be talking about Document Object Model (DOM).

I have no idea what that is (or at least I only have a vague clue) but I’m eager to find out.

Quote of the Week: John Collison

John Collison

“Help each user personally. Sure that won’t scale to a very large size, but when a startup is just starting out, it really helps you have an advantage as a small and nimble company.”
— John Collison

Quote of the Day: Steve Jobs

Steve Jobs

“My passion has been to build an enduring company where people were motivated to make great products. Everything else was secondary. Sure, it was great to make a profit, because that was what allowed you to make great products. But the products, not the profits, were the motivation. Sculley flipped these priorities to where the goal was to make money. It’s a subtle difference, but it ends up meaning everything: the people you hire, who gets promoted, what you discuss in meetings.

Some people say, “Give the customers what they want.” But that’s not my approach. Our job is to figure out what they’re going to want before they do. I think Henry Ford once said, “If I’d asked customers what they wanted, they would have told me, ‘A faster horse!’” People don’t know what they want until you show it to them. That’s why I never rely on market research. Our task is to read things that are not yet on the page.

Edwin Land of Polaroid talked about the intersection of the humanities and science. I like that intersection. There’s something magical about that place. There are a lot of people innovating, and that’ s not the main distinction of my career. The reason Apple resonates with people is that there’s a deep current of humanity in our innovation. I think great artists and great engineers are similar, in that they both have a desire to express themselves. In fact some of the best people working on the original Mac were poets and musicians on the side. In the seventies computers became a way for people to express their creativity. Great artists like Leonardo da Vinci and Michelangelo were also great at science. Michelangelo knew a lot about how to quarry stone, not just how to be a sculptor.

People pay us to integrate things for them, because they don’t have the time to think about this stuff 24/7. If you have an extreme passion for producing great products, it pushes you to be integrated, to connect your hardware and your software and content management. You want to break new ground, so you have to do it yourself. If you want to allow your products to be open to other hardware or software, you have to give up some of your vision.

At different times in the past, there were companies that exemplified Silicon Valley. It was HewlettPackard for a long time. Then, in the semiconductor era, it was Fairchild and Intel. I think that it was Apple for a while, and then that faded. And then today, I think it’s Apple and Google—and a little more so Apple. I think Apple has stood the test of time. It’s been around for a while, but it’s still at the cutting edge of what’s going on.

It’s easy to throw stones at Microsoft. They’ve clearly fallen from their dominance. They’ve become mostly irrelevant. And yet I appreciate what they did and how hard it was. They were very good at the business side of things. They were never as ambitious product-wise as they should have been. Bill likes to portray himself as a man of the product, but he’s really not. He’s a businessperson. Winning business was more important than making great products. He ended up the wealthiest guy around, and if that was his goal, then he achieved it. But it’s never been my goal, and I wonder, in the end, if it was his goal. I admire him for the company he built—it’s impressive—and I enjoyed working with him. He’s bright and actually has a good sense of humor. But Microsoft never had the humanities and liberal arts in its DNA. Even when they saw the Mac, they couldn’t copy it well. They totally didn’t get it.

I have my own theory about why decline happens at companies like IBM or Microsoft. The company does a great job, innovates and becomes a monopoly or close to it in some field, and then the quality of the product becomes less important. The company starts valuing the great salesmen, because they’re the ones who can move the needle on revenues, not the product engineers and designers. So the salespeople end up running the company. John Akers at IBM was a smart, eloquent, fantastic salesperson, but he didn’t know anything about product. The same thing happened at Xerox. When the sales guys run the company, the product guys don’t matter so much, and a lot of them just turn off. It happened at Apple when Sculley came in, which was my fault, and it happened when Ballmer took over at Microsoft. Apple was lucky and it rebounded, but I don’t think anything will change at Microsoft as long as Ballmer is running it.

I hate it when people call themselves “entrepreneurs” when what they’re really trying to do is launch a startup and then sell or go public, so they can cash in and move on. They’re unwilling to do the work it takes to build a real company, which is the hardest work in business. That’s how you really make a contribution and add to the legacy of those who went before. You build a company that will still stand for something a generation or two from now. That’s what Walt Disney did, and Hewlett and Packard, and the people who built Intel. They created a company to last, not just to make money. That’s what I want Apple to be.

I don’t think I run roughshod over people, but if something sucks, I tell people to their face. It’s my job to be honest. I know what I’m talking about, and I usually turn out to be right. That’s the culture I tried to create. We are brutally honest with each other, and anyone can tell me they think I am full of shit and I can tell them the same. And we’ve had some rip-roaring arguments, where we are yelling at each other, and it’s some of the best times I’ve ever had. I feel totally comfortable saying “Ron, that store looks like shit” in front of everyone else. Or I might say “God, we really fucked up the engineering on this” in front of the person that’s responsible. That’s the ante for being in the room: You’ve got to be
able to be super honest. Maybe there’s a better way, a gentlemen’s club where we all wear ties and speak in this Brahmin language and velvet code-words, but I don’t know that way, because I am middle class from California.

I was hard on people sometimes, probably harder than I needed to be. I remember the time when Reed was six years old, coming home, and I had just fired somebody that day, and I imagined what it was like for that person to tell his family and his young son that he had lost his job. It was hard. But somebody’s got to do it. I figured that it was always my job to make sure that the team was excellent, and if I didn’t do it, nobody was going to do it.

You always have to keep pushing to innovate. Dylan could have sung protest songs forever and probably made a lot of money, but he didn’t. He had to move on, and when he did, by going electric in 1965, he alienated a lot of people. His 1966 Europe tour was his greatest. He would come on and do a set of acoustic guitar, and the audiences loved him. Then he brought out what became The Band, and they would all do an electric set, and the audience sometimes booed. There was one point where he was about to sing “Like a Rolling Stone” and someone from the audience yells “Judas!” And Dylan then says, “Play it fucking loud!” And they did. The Beatles were the same way. They kept evolving, moving, refining their art. That’s what I’ve always tried to do—keep moving. Otherwise, as Dylan says, if you’re not busy being born, you’re busy dying.

What drove me? I think most creative people want to express appreciation for being able to take advantage of the work that’s been done by others before us. I didn’t invent the language or mathematics I use. I make little of my own food, none of my own clothes. Everything I do depends on other members of our species and the shoulders that we stand on. And a lot of us want to contribute something back to our species and to add something to the flow. It’s about trying to express something in the only way that most of us know how—because we can’t write Bob Dylan songs or Tom Stoppard plays. We try to use the talents we do have to express our deep feelings, to show our appreciation of all the contributions that came before us, and to add something to that flow. That’s what has driven me.”
— Steve Jobs