[Slide 1.] Welcome to Informatics 191. [Slide 2.] Please close your laptops. Please turn off your phone ringers. Thank you. [Slide 3.] My name is Six Silberman. I am the teaching assistant for this course. [Slide 4.] This course is about delivering software of value. [Slide 5.] It is not about "imagining", "talking about", "mocking up", "planning", or "prototyping" software. You will *make* software. But you can make software alone in your basement. In this course you will deliver software *to a client*. In this course you will make mockups, documents, use cases, plans, and prototypes. These things are important. But they are *about* software. So is this course. In fact, the point of making mockups, documents, use cases, plans, and prototypes is to help you make software *of value*. Something has value if someone wants it. Does your software solve a real problem a real person really has, or make someone's life better in some other way? If it doesn't, your software may be elegant, efficient, extensible, but it will be valueless. Nobody will want it. Nobody will care. In this course you should make software somebody wants and cares about. Specifically, you should make software *your client* wants and cares about. And you will be better motivated if *you* care about it too. If you think a project is boring or pointless, don't pick that project. [Slide 6.] To succeed in this course, you only need to do two things. First, you must figure out what to deliver. Second, you must deliver it. The course schedule and assignments are designed to help you do these things. And we will do our best to help you. If you feel the schedule or assignments are preventing you, or *we* are preventing you, from doing these things, please talk to us. We will talk about the schedule later. For now, I will talk about seven things: [Slide 7.] Grades; code; time; face; talking; focus; and bullshit. [Slide 8.] Given past experience I can say: it's likely some teams will deliver A or A+ projects and many will not. It's likely that within many teams, some people will contribute more than others. Final grades will reflect this. I want to give you an A. But I can only give you an A if you deliver software of value to your client on time. We will try to keep teams on track to do this. But there are only two of us. And many of you have jobs and other hard classes. I can tell you how to deliver software of value. But I can't make you do it. You may make a rational choice not to spend the time needed. This will result in a lower grade, because that is our job. But please know that your grade has nothing to do with your worth as a person. It only reflects our estimate of your success in delivering software of value in this course. In this course, attendance and evaluations are graded. Attendance is graded because it is much harder to deliver software of value if you don't show up. Peer evaluations are graded because they help us help you. And your evaluations of us help us improve the course. If you don't believe any of these claims, ask someone who took 191 last cycle. [Slide 9.] 191 is not *about* coding. But every person will code. 191 is the informatics senior capstone project. Informatics is not only about coding. It is about software in its many overlapping contexts -- technical, organizational, social, and so on. You cannot win at 191 by code alone: you must figure out what is worth coding. But if you can't or won't code, you will not succeed. 191 is not about coding in the same way that a cathedral is not *about* bricks. To build a cathedral, you need bricks. But the cathedral is really *about* theology, politics, architecture, organ music, and stained glass. Brick laying is *taken for granted*. The cathedral is about what you can do *after* you know how to lay bricks. If you are building a cathedral with a team of thousands, you can have a few non-bricklayers. But if you have a team of four or even ten, every person must lay brick. And in 191, every person must write code. If you think of yourself as a non-coder, change your thinking as soon as possible. Do not fool yourself by thinking you will be your team's interface designer, project manager, or document writer. The designer who does not code makes designs that are hard to code. The project manager who does not code does not know how long things will take and cannot manage. The writer who does not code cannot describe code accurately. If you try to make it through 191 without learning to code, you will contribute less to the project than your teammates. You will feel inadequate and insecure. You will start avoiding meetings and classes. Your grade and morale will suffer. If you cannot code, learn now. As soon as you know what language and framework you will use, learn it. You learn a programming language or framework by building something in it. If this is your first time coding something real, build something *unrelated* to 191, *on your own*. This may take 10 hours, 30, or 60. The faster you accept this and start, the sooner you will be able to contribute to your project. Do not panic. 191 students have done this before. It is not even that hard. The main thing that is needed is for you to decide to do it. If you don't know what to do, ask me. I will help you. [Slide 10.] Coding takes time. Learning to code takes time. Delivering software of value takes even more time. Every person who wants to deliver software of value in this course should plan to spend about 15 hours per week outside class time on their project. Not every team; every *person*. By "plan", I don't mean in your head. Put recurring weekly events on your calendar, outside class time, called "191 work" that add up to at least 15 hours a week. Give the events a place. If you don't have a calendar, get or make one and use it. [Slide 11.] In person meetings are best for understanding what your client actually wants. Working together in person is also best for making code work. As soon as you know who your client is, schedule a weekly in-person meeting with them. If you can't get a weekly in-person meeting, get an in-person meeting every two weeks and a phone or Skype call the other weeks. Coordinate with your team so you are working physically together as much as possible. Many people think they can work as effectively remotely as in person. They are wrong. [Slide 12.] If you have a problem, talk. If you break something in your code, talk to your team. If you overscheduled yourself and are not sleeping enough, talk to your team. If you have a family emergency, talk to your team. If your whole team has a problem, talk to your client or to us. Do not be tempted to try to fix big mistakes on your own and hope nobody will notice. Odds are you'll make it worse. If something comes up in your life outside class, tell the people it will affect. Do not try to get everything done anyway. If you don't sleep enough, you will get sick. Then you really won't be able to contribute. I can't tell you how you should coordinate. I don't think you need to be available 24/7 on text, email, phone, and Facebook. I think it is better to have scheduled meeting and co-working times and say what needs to be said at those times. If that sounds crazy, consider it, but do whatever you need to do. But make sure you talk when you need to talk. And remember that it is easier to convey complex information by phone than by text, and easiest in person. [Slide 13.] When you work, work. You cannot multitask. There is simply no such thing. It is a lie we tell ourselves. If you don't believe me, google this string. [Slide 14.] ["multitasking bong hits"] When you work, close your email client. Close Facebook. Turn off your phone ringer. Not vibrate. Off. If you don't trust me, just try it for a week as an experiment. [Slide 15.] Finally, in this course, please try not to bullshit. By "bullshit" I do not mean lying. Most of you would not lie to your team, to your clients, or to us. You have been taught all your lives that lying is bad and most of you believe it. I believe it too. I expect you not to lie. To see the difference between lies and bullshit, suppose you are taking an exam. There is an essay question. [Slide 16.] You studied well, but you have no idea what the question is asking, much less how to answer it with a whole essay. So you write something. [Slide 17.] Your goal in writing is not to answer the question. You can't answer the question because you don't understand it. This could be just as much the professor's fault as yours. Your goal is just to get as many points as you can. What do you do? We all know the answer to this question. You "bullshit your way through". [Slide 18.] Right? This doesn't even mean anything. You won't get 99,000 points for this. But you might get like...80,000? B minus! Pass! There are no exams in 191. But here's a situation that will come up. Say you give a presentation about some software you built. Your sponsor, or somebody in the audience, asks you a question. [Slide 19.] You know the honest answer to the question is "no". But you would feel embarrassed saying "no". You know that you *should* have added this feature already, or at least thought of it, but you didn't have time. So you say this instead: [Slide 20.] [Slide 21.] Do not do this. [Slide 22.] Do this. [Slide 23.] [Slide 24.] Or this: [Slide 25.] In this course, you get no points for big words. You get points for delivering software of value. You can use any method to deliver, including being embarrassingly ignorant in public and causing more experienced people to give you advice, if it works. Please do your absolute best to be honest. Being honest goes beyond not lying. It also means not bullshitting. We feel pressured to bullshit when we don't know something but have to talk about it anyway. Nobody is immune. I do it too. But we can all make each other's lives and work better by helping each other clear away bullshit. You don't have to be mean or even use the word "bullshit" to do this. You can ask simple clarifying questions like "What do you mean by 'optimize'?" or "When will it be done?" You may notice that clarifying questions and clear answers often have short, precise words. The opposite of bullshit is not just truth; it's clarity. Telling the truth clearly -- "I don't know"; "we didn't do it" -- can be embarrassing. But you'll be happier in the end. [Slide 26.] If you have questions about bullshit, google either of these strings. [Slide 27.] I'll put all this another way. Every person on every team at all times should have two goals. First, achieve clarity on what is being built; why; how it will work; who will build each part, how, and when; and how the parts will fit together. If these things are not clear to you, make it your mission to figure them out. This could involve communicating with your client, communicating with your team, communicating with us, drawing a software diagram for yourself, learning a new programming language or framework, doing calendar Tetris, or going on a vision quest in central America. Do what you need to do. Second, build it. This will take time, focus, organization, and discipline. It may feel hard. But at its core the process is simple. It is absolutely certain that you can do it. And we will help you. [Slide 28.] [Blank slide.] You will not have complete clarity on this yet. Details are coming. I will take questions later. Thank you, and welcome.