These are my personal recommendations to an ECE undergrad at CMU.

This page does not reflect the opinions of anyone else, and there is no guarantee of suitability. I believe every word I say, but that doesn’t mean you should too.

I try to keep it light, but this is serious. Enjoy.

Copyright 2007~2024 James C. Hoe.

The most important advice about advice I already gave in the disclaimer above. (“I believe every word I said, but that doesn’t mean you should too.”)

When finding yourself in a new situation, getting good advice can be most helpful toward avoiding the very bad decisions and the avoidable mistakes. They are not so useful in making the “right decision” for you. (Don't confuse getting advice and letting others decide for you.)

When you ask for advice, it is important to understand what you are receiving. Most advice you will get is in the form of a retelling of personal experiences (possibly with embellishment and omissions). A more thoughtful teller may offer personal interpretation and insights on top of the narrative. In any case, the advice offered is likely to be highly personal and subjective to the teller. It behooves you to ask the same question to many experienced people. Decide which answers are most relevant to you and your situation. In the end, you have to add your own interpretation and distillation to extract the “common knowledge” and “common sense” (that you lack because you are inexperienced) to help you avoid the known pitfalls. You still have to make the “best decision” for yourself.

I do not recommend cloning someone else's success story; great successes are not repeatable exactly. The secret to success is luck; the non-secret is hard work, understanding what works for you, and avoiding avoidable mistakes.

Lastly, the best advice comes from first-hand experience. Beware of second-hand experts and their advice.

There is a very simple theme in my advising. The purpose of coming to study at CMU is to learn (about yourself and about an area of study); the purpose of learning is to know and to get to do what you want to do after CMU.

Know what you are working towards; start by asking yourself what you want to do after CMU if you don't know.

• As a freshman, ask: which of what you have done is because you wanted to and not because “it was due”.

• As a sophomore, ask: do you know what you want to do for the rest of your life. (It helps to exaggerate the perspective a bit.)

• As a junior, ask: how does what you want to do fit into your career and life after CMU.

• As a senior, ask: what you should be doing next to achieve the career and life you want.

Your 4 years at CMU would have been well spent if you discovered what it is you really like to do and started to become good at it.

Degree requirements are not like levels in a video game. You don't win a diploma by simply clearing enough levels, one-by-one, as presented to you. (The diploma should never have been the objective in the first place.)

Collegiate learning is a proactive exercise. You need to be in front and driving.

The degree requirements as a whole have the designed objective of preparing you for professional success after CMU by (1) initially helping you build a foundation of knowledge and breadth of exposure; (2) next helping you identify an area of interest; and (3) finally helping you start to specialize in an area of choice.

You need to view the requirement structure correctly and plan your undergrad study as a complete strategy from the start. You may have to do a lot of speculation, but even when deciding your first-year courses, you should have asked yourself what you want to do after CMU and what you plan to take in your senior year.

As you complete each course, think about how it has (or failed to) build toward what you want to do after CMU; has it caused you to change your mind about what you want to do after CMU.

The same ECE degree requirements produce students of all kinds with different expertise and proficiency. Your path in a future technical career is determined by the expertise and proficiency you gain. The diploma is a glorified receipt.

Currently, you need 379 units for a BS degree in ECE (true as of Jan 1, 2020).

Without any AP credits, you should not have to take more than 4 courses per semester for 8 semesters. Most of you have AP units, so this means you could actually take less than 4 courses some terms. Or you could take 4 courses per semester that included other more “well-rounded“ courses beyond the 379 needed to graduate.

Regardless of what the policy says, as far as I am concerned, if you go beyond 4 “real” courses, you are overloading, and the quality of learning suffers. (There is a reason you see the prefix “over” in the word “overloading”. It is a warning that you are operating beyond the intended range.) Ask yourself: are you here to learn as well as you can or as fast as you can?

What most students do not realize is that there is typically more than a factor 2 difference (to be conservative) between the absolute performance of the best “A” student and the lowest “A” student in a course. Just because you got an A, you should still ask yourself: did you get as much as you can out of that course? If you are taking 66 units, you don’t have time to get as much as you can out of your courses.

You might be tempted to think that by overloading you are getting more “units” per dollar (of tuition) out of CMU. Don’t confuse that with how much learning and retention you are getting for your dollars. Overloading is not worth it.

The issue of overloading is a question of serving “form” vs. “function”.

Taking many courses (form) is not the same as being able to learn from those courses (function). Even getting all A's is not a guarantee of learning quality.

Overloading shouldn't be your modis operandi, but, at a critical juncture, it is okay to push the limit, as long as the function is achieved not just form. This is the judgement call.

There are so many different courses you could take as an ECE undergrad at CMU. This can get really confusing. The suggestions below are simply a representation of what “I” would have taken had I been an undergrad in ECE today.

ECE Pre-Core

• 18-100: Introduction to ECE (12 units)
• 18-200: Emerging Trends in ECE (Sophomore Seminar) (1 units)
• 18-202: Mathematical Foundations of Electrical Engineering (12 units)

ECE Core

• 18-220: Fundamentals of ECE: Electronic Devices & Circuits (12 units)
• 18-240: Fundamentals of ECE: Digital Logic & Computers (12 units)
• 18-213: Introduction to Computer Systems (12 units)
• 18-290: Fundamentals of ECE: Signal Transmission and Processing (12 units)

I strongly discourage anyone from taking more than 2 core courses in a semester. It is not a goal to finish all 4 core courses in your sophomore year. Take them in the order of your interest so you can get to the right 300-level courses sooner.

ECE Breadth

• 18-320: Microelectronic Circuits (12 units)
• 18-341: Logic Design Using Simulation, Synthesis, and Verification (12 units)

ECE Concentration

• 18-447: Introduction to Computer Architecture (12 units)

ECE Coverage

• 15-410: Operating System Design and Implementation (12 units)

Capstone Design

• 18-500: ECE Design Experience (12 units)

Other

There are still the Free Elective units. They should not all be technical, but it does give me the time to take a few more courses (without overloading). Here are examples of some courses I would consider choosing (as a student interested in computer architecture).

• 18-340: Hardware Arithmetic for Machine Learning
• 15-411: Compiler Design
• 18-422: Analysis and Design of Digital Circuits
• 18-740: Graduate Computer Architecture

I would be tempted with

• 18-330 Introduction to Computer Security
• 18-349 Introduction to Embedded Systems
• 18-403 Microfabrication Methods and Technology (this I actually did as an undergrad)
• 18-461 Introduction to Machine Learning for Engineers
• 18-464 ULSI Technology Status and Roadmap for System on Chips and System in Package

I would make it a point to take a few fun, non-ECE courses (freshman-level intro courses are just fine).

I would also include a senior project. If I were interested in going to graduate school, I would start my senior project the summer before the senior year. I would not try to do undergraduate “research” during the semester with a full course load. Lastly, I would do a technical internship in the industry during the summer before my junior year.

I do not recommend undergrads (especially those who intend to pursue a PhD) to hurry into or to take a lot of graduate courses. You do want to take THE one in your specialization (18-740 in my example) before you apply for PhD. (Okay, maybe just one more, 18-643.) As an IMB, I trust you are mature enough to pick what you need and what is good for you for whatever you have planned for your own career future.

Again, this simply reflects what I would have done as an undergrad. If you don’t like what you see here, don’t be shy about asking another professor closer to your area to tell you what she/he would do.

In general, I advise students against the strategy of “I am interested in X, and therefore I am going to take every course CMU has on X.” (To simplify this conversation, I assume you are without any doubt interested in X. You would be surprised how often even this basic assumption fails to play out.) Courses can only provide foundation knowledge; you do not become really good at X by just taking courses. In your time at CMU, you should certainly take courses in your chosen area of specialization, but how valuable is the N+1 course after having taken N courses already? Are you not going to be better off doing a research project? (After all, once properly prepared, doing things on your own is how you become really good at it.) Furthermore, think harder about what other topics you may also be interested in or can supplement your career objectives. It may be counterintuitive, but, to become an expert on X, you are going to need to know a lot more than just X.

I am assuming this question is asked by someone who is interested in the computer systems area (think 18-213/15-213) that is in this overlapped region between ECE and CS. If someone in applied physics or theory is asking this question, come talk to me directly; I am curious to meet you.

What is clear is that a systems person should absolutely take classes from both ECE and CS. Besides basic data structures and algorithms, topics like OS and compilers are all par for the course. If so inclined, taking a course in theory or programming languages is helpful in acquiring a new way of thinking that does not come naturally to a systems person.

Separate from my recommendation to take courses from both departments, I don't see any good reason to go through the trouble of achieving both degrees. The more competitive you are as you advance in your study and career, the more you should expect to be judged by what you can do and not what your credentials would suggest you should be able to do. For the best jobs and graduate schools, they will figure out exactly how good you are in a hurry, and no one is going to care whether you have CS or ECE or both degrees.

I am, however, a proponent for double-major or minor of very dissimilar disciplines (Business, Drama/Art/Music, Sciences…) if you are driven to do so by your unique interest, talent, or goal, and not for trophy hunting.

I assume you have the mental “horsepower” if you are at CMU in the first place. It is easy to do well if 1) you enjoy what you are studying AND 2) you apply good study “mechanics”. If the former is false, you have a big problem. But, the latter just takes discipline (see next).

Students (even seniors) often ask in class the question “do I need to know X for the exam?” This is a sure sign that this student is still under the high-schoolish mentality of studying for grades rather than studying to learn. Instead, ask the question “do I need to know X if I want to have a career in Y?” Similarly, when you receive a low grade in a course, worry less about how it impacts your GPA; worry more about what the grade is telling you—you didn’t learn the material as well as you should or as you thought you did.

Come to CMU to learn. The goal to “do well” is to have learned well. Getting good grades is only a symptom.

• Care about the subject you are studying
• Do the reading assignments before lecture
• Attend lectures (and pay attention)
• Ask questions when you don't understand
• Do homework or lab with intent to learn (not simply to produce something to turn in for points); don't wait until the last minute to start
• Have a place where you can work without distraction
• Get enough sleep, eat healthy, and exercise

Seems obvious, no? Easy to follow through? No.

Studying correctly will make learning more pleasant and productive—all the while taking LESS (not more) time. Nothing is more frustrating (and a big waste of time) than showing up to a lecture and not understanding what the professor is talking about. (Did you do the reading assignment beforehand?) Nothing is more frustrating (and a big waste of time) than struggling with a homework assignment that you fundamentally have no clue about. (Did you wait until the night before the deadline so you cannot get help in office hours? Did you skip the relevant lecture in the first place? Did you do the reading assignment?) These unpleasant scenarios and others like it can be avoided if you had the discipline and mechanics to do the right thing in the first place; trying to make up afterwards is a forever uphill battle. Every topic you don’t understand well now will make it that much harder to understand the next topic that depends on it, so don’t let it snowball.

When I look across a classroom, the most telling difference between the thriving students and the struggling students is their ability to recognize what is actually important. This comes across in what they focus on in the answers they give and in the questions they ask. More importantly, this translates to how they prioritize what they do.

An important part of collegiate maturation is to learn to recognize what is actually important. Focusing on the unimportant is against Amdahl's Law.

Calling Amdahl's Law a “Law” is no exaggeration. No effective optimization can violate Amdahl's Law. If you are working very hard but not getting the desired effect, double check what you are working very hard on.

Rule of Thumb #1: If the professor said something that doesn't sound right or is not clear, there is a pretty good chance he/she overlooked to explain some important detail/assumption or made an outright mistake (yes, it does happen, and no, we are not always testing if everyone is awake).

Rule of Thumb #2: If the professor said something that doesn't sound right or is not clear, there is a pretty good chance the rest of the class is confused by it too.

In both cases, it is your duty and privilege to ask for clarification. (Caveat: this works much better if you go to lectures prepared, i.e., having done the reading assignments.)

You cannot really “study” for a final at the last minute. If you really could make a big difference by cramming in just the days before a final, we wouldn't need semester long courses. You can only “review” before the final what you studied and learned over the whole semester. (Studying something for the first time is not re-view.)

A great way to review for a final is to work out old “practice” exams. The most effective way to do this is to complete the review first and then test yourself with the practice exams to see how prepared you really are. (If you are not prepared, keep studying.) It is useless to study an old exam itself; it is even worse to study an old exam's solutions. Keep in mind, it is not good enough to understand the solutions; you need to be able to come up with the solutions without prompting. It is not good enough to know how to solve those exact problems; you need to be able to solve problems of the same nature, in general.

Lastly, I often see students studying lecture slides. Lecture slides contain very little information on their own; they are more like mental tabs to remind you of what was said in the book or in the lectures. If you have not read the book or did not attend the lectures, there is very little you can extract on your own from the lecture slides themselves. If you are not doing the reading assignments or you are not attending lectures, then you are really missing out on learning.

When you see an exam question, you should first reflect on whether you know the answer or how to answer. Occasionally, you may find your knowledge gap is large enough, you don't understand the question.

When responding, you should know for yourself whether you are giving an answer or a guess. (Ironically, the less you know the difference, the more obvious the difference is in the eyes of the grader.)

Except for “honest” misunderstandings you hold, you shouldn't need the answer key or graded papers to know you don't know. It is the same when doing homework. Do something about the weaknesses identified/exposed by the exam questions (even if it is the last final of your last term at CMU).

Miscellaneous Gripes:

• A not-false statement is not the same as a correct response. There is no partial credit for answering “1+1=2” to “What is the meaning of life?”.
• A correct answer to the wrong question is the wrong response. There is no partial credit for answering “1+1=2” because you assumed or misunderstood “What is the meaning of life?” as asking “What is 1+1 equal to?”
• Unless the entire class answered “1+1=2”, not being able to understand the question correctly is a part of your assessment.
• “A state of a living thing marked especially by capacity for metabolism, growth, reaction to stimuli, and reproduction” (according to Webster) is not any more correct an answer than “1+1=2” to “What is the meaning of life?”
• You cannot get credit for what you were thinking in your head when you wrote down “1+1=2” on the exam paper.
• If a 5-point short-answer question asks “what is the meaning of life?”, it is irrelevant, for the purpose of the intended assessment, that you might have, could have come to an enlightened answer if only you had a week more to work on it.
• Having the “text” of the correct answer enveloped in a novel of drivel is not a correct response. You can't get full credit for the answer, “A hundred prisoners are each locked in a room with three pirates, one of whom will walk the plank in the morning. Each prisoner has 10 bottles of wine, one of which has been poisoned; and each pirate has 12 coins, one of which is counterfeit and weighs either more or less than a genuine coin. In the room is a single switch, which the prisoner may either leave as it is, or flip. Before being led into the rooms, the prisoners are all made to wear either a red hat or a blue hat; they can see all the other prisoners' hats, but not their own. Meanwhile, a six-digit prime number of monkeys multiply until their digits reverse, then all have to get across a river using a canoe that can hold at most two monkeys at a time. But half the monkeys always lie and the other half always tell the truth. Given that the Nth prisoner knows that one of the monkeys doesn't know that a pirate doesn't know the product of two numbers between 1 and 100 without knowing that the N+1th prisoner has flipped the switch in his room or not after having determined which bottle of wine was poisoned and what colour his hat is [ classic Click-and-Clack "drivel" ], . . . . . . to live and to leave the world a better place than you found it . . . . . . .”

It is possible to do worse than being wrong. It is possible to be wronger than wrong. See also this related comment.

Students bring 3 kinds of exam regrades.

• The first kind is where the student, with the benefit of the answer key, still holds technical misconceptions or one of the above fallacies.
• The second kind is where the course staff made a mistake. These mistakes are not randomly distributed. “Good answers” are very easy to recognize; we rarely mess up on an on-the-point answer. If you encounter this scenario, in addition to getting your points back, double check if your answer is misleading somehow. You can have a correct but bad answer.
• The most common regrades by far are appeals on “wobbler” answers that are not entirely right or wrong. A lot of subjectivity is involved in inferring what the student really know or really meant. If you encounter this scenario, you should focus on understanding why you are not complete right and not how many points you deserve for being not completely wrong.

If find yourself a frequent victim of regrades, realize it could be a reflection of you. You should discuss your answers more deeply with the TA or the instructor. There is more to be gained than point adjustments.

Clarity, correctness, conciseness, (courtesy,) concreteness, (consideration) and completeness.

On a short-answer question on an exam, just answer what the question asks. Say the most important part of the answer first. The grader knows the answer. We just need to know if you know. (Think of it more like exchanging spy passphrases.) Unless it is asked for as a part of the question, you don't need to motivate your thinking or develop the idea from scratch.

The assessment doesn't care if you know more than what was asked for. A loosely aimed “shotgun” answer tells the grader you don't know the answer.

Courtesy and consideration are nice, but not as important as chirography on an exam.

My second least favorite duty in teaching is to assign grades. My least favorite is to deal with cheaters. I talk about them together because my objection to them stems from the same root problem—the need to understand the real objective of taking a course.

Grades: It troubles me greatly that some students put so much more emphasis on getting the grades over actually learning the knowledge. Some degree of this is difficult to resist (e.g., cramming the night before the exam), but we all know what this can also mean when taken to the far extreme.

You would do much better if you worked on learning the materials. Your grades reflect how well you have learned and not the other way around. One day you will leave CMU, and you will have to make a real living with what you have learned; your GPA and diploma can offer little solace to you or your boss if you cannot perform on the job.

The A/B cut-off is a perennial point of contention at the end of a term. Keep in mind, if you are performing near the boundary between A/B, (1) whether you receive an A or B, subject to noise and chance, is a correct outcome (don't be there); (2) whether you receive an A or B, it does not change how well you have really done and how well you will be able to do in the future (don't stay there). The purpose behind taking a course doesn't end with the term and letter grade.

Cheating: For anyone even contemplating cheating, you should understand it is just not worth it. First of all, cheating cannot fix the fact that you really don't know or aren't able to do what you will need in the subsequent courses and in your later life. Second, although the chances of getting away with any one isolated instance of cheating are typically quite good, any one incident is also unlikely to have a noticeable positive impact on your semester letter grade. For that, one has to be cheating systematically, and one will surely be caught for that. Third, think back to when you were little and how your mother could always tell when you lied. She couldn't read your mind; you were just more obvious than you think. By watching a student over the course of a semester, we (professors) have a very good sense of what is a student's expected performance and trend. You will get the grade you worked for.

For someone who is feeling the pressure to cheat, the wrong thing to do is to succumb (obviously). The right thing to do is to recognize it as the warning sign of a deeper problem. Somehow you have let your study fall behind and out of control. If you continue on the same course, your problem will only snowball. The only way to recover is to identify the problem and to change what you are doing to regain control. Cheating is a poor patch job that does nothing to fix the root of the problem.

I use the following definition in my course syllabus: “To put it plainly, if what you are about to do is not a truthful reflection of your knowledge, ability, and effort, you are about to cheat. More importantly, if what you are about to do is going to get you a better grade without helping you learn the course material, you are about to cheat.”

This, of course, also applies to B-/C+, C-/D+, etc.

There is no difference in the meaning of A- and B+. If you get an A- or B+, either way, you are good, but there are those in your peers who are decidedly better in that course.

It makes no difference if it is recorded as plain A or B on the transcript, you still ARE that same “you”.

If term after term, you find yourself near the cut-off for A- and B+, don't be surprised with a 3.5 GPA in the long run. Then again, keep in mind, maintaining a 3.5 cumulative GPA is very good—not just good—and means something quite different from receiving one A-/B+ one time in one course.

Don't fixate on getting over the grade cut-off. Set your sights on improving, wherever you are.

Undergrads, even some seniors, often misunderstand what homework assignments are about. (See my earlier comment on getting out of the high-school mindset ASAP.) Instructors do not assign homework because we see the necessity to take up your time or to have something to grade.

Homework assignments (especially in upper-level courses) are given as exercises for you to actually work with what you saw in the lectures or read in the text. This is one more chance for you to catch the difference between what you think you understood and what you really do. (The homework assignments from your younger days were drills to become good at basic skills.)

Even in an ideal world with ideal students, I would not do away with homework because it is an effective teaching/learning tool. In the ideal world, I would give out homework (and provide solutions) with no consequences on grade. (Then again, in the ideal world, I wouldn't have to assess grades to begin with. You learned what you learned; you make do with what you learned.)

If you ever find yourself rushing through homework the night before it is due (even though it covers multiple weeks of past materials and you had weeks to do it), stop and rethink your strategy and mindset. You could do it anytime—before or even after the due date—for the same learning effect. Why did it suddenly become important the night before it is due? (BTW, if you have skipped reading assignments because you are not directly assessed on it, see above.) Still worse, if you ever resorted to “cheating” to finish a homework, you really need to ask yourself why and what for.

Do your homework to learn from it, not to finish it.

Divide-and-conquer is a tried-and-true strategy for finishing a large team project in real life, when it is only the end product that counts toward success.

Divide-and-conquer is not an effective strategy to learn from working on a group lab in a course. In this case, it is the process that has value; no one has any use for the end product of your lab. In a lab, you should work in a team to learn from each other, to help each other learn better. Just make sure what your partner “learned from doing” also find a way to register in your brain.

If you apply divide-and-conquer to doing homework, you really are confusing motion with progress.

The following is real data correlating homework points (worth only 20% of final grade) and final course performance. Multiple choice:

a) higher homework grade (worth 20%) causes higher final grade.

b) higher performing students are better at doing homework (but everyone could get help in office hours and piazza).

c) doing homework carefully causes one to learn deeper, work out better solutions, get better course grades, and actually be good at what the course is about.

d) wanting to learn causes a student to….

Homework performance is a pure reflection of learning for learning's sake. Everyone could have the time and resources to work out the perfect solutions, but it would not be worth the effort if the motivation is a better grade.

How much of what you do for a course is on your own volition and not for assessment?

In the above, homework scores and final grades are correlated, but they are not causal of one another. If you want good course grades, don't do homework for the points. Do your homework with the purpose to reinforce your understanding of the course materials. Better learning is one of the things that can lead to good grades causally.

Then again, good grades only correlate with how well you can in real life apply what you learned. So, work hard to become good at what you want to do in life and not for good grades.

In basic courses (think grade-school arithmetic but really any rote knowledge or skills courses), there can be a finiteness to the learning objective. On a test with 100 additions to calculate, if you produce all of the same sums as the answer key, you are “perfect”. Anyone who gets more than 90% right is considered pretty good. If we give everyone a calculator, almost everyone will be pretty good.

In an upper-division college course, that isn't the case.

Take 18-447 (computer architecture), even if you can memorize the lectures and the textbook verbatim, can you design a good computer to usage needs and requirements. Can you set good requirements?

Even with the ability to google search the entire indexed human knowledge, not everyone will be good at coming up with the “right” computer design? Not everyone will even be equally good at coming up with fruitful google queries (i.e., asking the “right” questions).

There is no 100% mark for what we do in 18-447. There is no answer key to the problems you learn to solve in 18-447. Good or bad is relative and only a matter of competitiveness. The difference is in how well your preparations help you understand the fundamentals to synthesize anew. The difference is also how much time and effort you chose to put into achieving higher quality.

Students get stressed out around mid- or end-semester when demands (assignments and exams) from different courses line up. The natural reaction, when pressed up against the deadline, is to ask for extensions.

1. If you didn't feel the same sense of urgency when the assignment was handed out, then you probably created the urgency by not starting to do the work when you had the time.
2. If you actually don't have enough time to do your work, extension is not a solution. When you take an extension, you are just piling work on top of what you should be doing the next period. This can feel like a solution to only the would-be procrastinators. (I also don't recommend anyone living off revolving-credit as a financial management strategy.)
3. If you actually don't have time, instead of asking for extensions, ask yourself if you are taking too many courses, too hard courses, or otherwise have more than you can handle going on in your life? Fix the real problems before they blow up in a big way. (Ditto about your finances.)

Take a time diet.

The impact of an extension on an undergrad course project is inversely proportional to how close to the deadline the extension is issued.

I make several references to the “high school” learning mindset. The core of it is one's ready acceptance of rote learning as real learning. One could excel through rote at the foundational materials, but that is not going to be enough to move you forward through college and beyond.

Rote learning, without developing understanding, is fragile. A rote learner does not ask why things work the way they do; what exists beyond what has been seen; and what is new to figure out. A rote learner's knowledge is bounded by what is presented.

If you worked as hard as you did in high school but can't seem to get traction in college, maybe you are not really learning.

In the acquisition of knowledge, there is a point where any more advanced material is simply inaccessible to you. Don't worry about that; almost no one ever gets that far anyway.

Long before that point though, there is an earlier point where the sophistication of the material cannot be taught anymore. Anything beyond that point, you can only learn on your own.

You are nearing this point. Whether you advance beyond this point is only a choice of wanting to learn and, for many of you who never considered it, the realization that you can learn on your own. This is equally applicable to an academic or industry career future.

Don't stop learning after CMU. Learn to learn on your own. In learning on your own, you might just learn something that no one else has learned before.

In most real-life roles, your value and competitiveness are determined by both how high are your strengths and how low are your weaknesses.

You, of course, need to develop your strengths (which hopefully align with your interests).

If you have large blindspots in your knowledge and skill set, for the same incremental effort, you might make a bigger difference by tucking up your greatest weakness (however much you detest it).

As a student, this applies to preparing for an exam or a job interview. When you apply for an RTL job, all serious candidates will be indistinguishably good at RTL. What else you can do becomes the differentiating factors. What you don't suck at might end up making all the difference.

Asking for and getting help on Piazza is very powerful. Reading other people's questions and answers is itself a valuable source of good insights.

Don't come to piazza and state, “I don't understand X.” Did you try? If you tried, on what specific points are you stuck on in trying to understand X? If you really can't get off the ground, the problem isn't X, but what comes before X.

You probably have also seen Piazza posts declaring no more than, in effect, “My lab doesn't work,” usually too close to when the lab is due. Without providing more information, it is very hard for anyone to help.

Take responsibility for YOUR problem.

The more you can narrow down the problem to specifics (from the blanket declaration “It doesn't work”) the more likely that someone has a quick answer. Share what you have already tried to diagnose the problem. Do you have any hunches? What was the last thing you did before your lab broke?

Of course, always read the lab handout and follow the instructions correctly—if it worked for everyone else, what did you do differently? Do try “googling” for the answer. Then, some debugging problems are just too involved for the quick back-and-forth format of Piazza. Start early to run into the problem early so you can take your problem to an office hour. If you are starting a lab without a firm understanding of the course material covered, study the course material first.

A level of due diligence in diagnosing the problem on one's own first is an important self-discipline. The ability to debug is a prime trait of a good designer/engineer. It is all part of problem solving.

• if you come to CMU to get a degree.
• if you study for grades or take classes for requirements.
• if you don't need a textbook because you go to lecture.
• if you don't go to lecture because you read the textbook.
• if you don't need your textbook anymore after the course is over.
• if you ascribe significant difference to the meanings of A- vs B+.
• if you ask “is X covered on the midterm?”
• if you work on homework and lab to “finish” them.
• if you study differently in the first week and the last week of the semester.
• if you see a problem in having 3 midterms on the same day 3 weeks from now.
• if you misunderstood the last point.
• if you don't know your current course instructors by name.
• if you never had a 2-way exchange with an instructor.
• if you never spoke with an instructor on something not about the course.
• if you assume everything you read in a textbook or hear in a lecture is unimpeachable.
• if you can't follow instructions in lab/project handouts.
• if you can follow only exact instructions in lab/project handouts.
• if you don't know how to approach a problem with more than one acceptable solution.
• if you don't know how to approach a problem with multiple competing objectives.
• if you don't know how to approach a problem that does not have a good solution.
• if you never answer “I don't know” to a question.
• if you are never the reason why things didn't work out.
• if you are never #2 because #1 is just better at it than you.
• if you have never done anything not asked of you.
• if you have never finished anything before it is due.
• if you want to be an “Electrical and Computer Engineer” after you graduate.
• if you do not think about what you want to be doing 5/10/15 years from now.

You may have heard that computer architecture is the interface between hardware and software. Actually, it is more generally everything between how computers are used and the technologies to build them.

Think back to 18-213, the computer you thought you knew is actually an abstraction—propped up by the programming language and the operating system, you never touched the computer. In 18-240 you learned how to build many interesting hardware building blocks, but you may not yet appreciate the universe of things you can assemble from them. If you ever wondered what happens between 18-213 and 18-240 in the making of a computer, you need to study computer architecture. (How to design a processor is only one of the things covered there.)

Ultimately, to be a computer architect is to be someone who understands what computers do and, in a principled way, knows how to do it well under the ever-changing technology and other constraints.

You can compare the 2023 18-447 lectures to those from 2009 (when we dropped computer arithmetic and added parallel computing). There is about 60% overlap in topics; about 50% overlap in slides.

It is quite interesting to see how much an undergrad course had to evolve in just 10 years. We are in an exciting field during an exciting time.

It is also interesting to look at the materials that have not changed the slightest, to ask (1) why the staying power (e.g., von Neumann) and (2) is it time to revisit things (e.g., making programmable logic a fixture in computer organization).

Unlike the above, here, we are talking about the architecture of a programmable system where some notion of “hardware/software interface” makes sense.

The 1964 IBM System/360 paper by Amdahl, Blaauw, and Brooks defines “architecture” as a description of “the attributes of a system as seen by the programmer, i.e., the conceptual structure and functional behavior, as distinct from the organization of the data flow and controls, the logical design, and the physical implementation.” A later book by Blaauw and Brooks entitled “Computer Architecture” gives a conforming definition, “the minimal set of properties that determine what programs will run and what result they will produce.” In both writings, it is elaborated that a central tenet of their definition is that performance and time should not be attributes/properties made explicit to the programmer by an architecture. They also make clear that an architecture could include specifications of (1) when, while still valid, programmer-visible behaviors are allowed to be undefined, and (2) when a program is invalid (such that the architecture does not apply at all), neither of which is the same as the well-defined concept of “exceptions”.

The above is probably the most commonly adopted general definition. This definition was motivated by the desire for binary compatibility across System/360 models. It is not universal or even the most appropriate in all contexts. A very practical and precise definition of “architecture” could be simply “whatever the architecture specification you are reading says”. Not all architecture specifications stay within the spirit of the common definition.

This is a surprisingly interesting question to test the above. The answer depends on many assumptions. The most important assumption is your definition for “architectural”. For simplicity, assume the common definition above for “architecture” and by derivation for “architectural”. By convention, disallow anything performance- or time-related to be architectural.

The common definition is based on what the program/programmer can see so we have to decide the meaning of “programmer”. (Don't worry. We can rely on established judicial precedent for the meaning of “is”.)

I am not aware of any modern commercial time-sharing systems where the TLB is architecturally visible to a user-level program. Keep in mind, the abstraction enclosing a user-level program/process is a joint effort by the hardware and the privileged OS kernel. Thus, we have to assume the kernel code is not collaborating with the user code for this answer.

Of the examples I am aware of (including architectures that prescribe a HW pagetable walk after a TLB miss), the TLB is a readily visible feature to the privileged code. With a HW managed TLB, a kernel still needs to understand it has to first shoot down a TLB-cached PTE entry before modifying the page table. By observing which physical locations actually change when storing to virtual addresses, kernel code can experimentally discern TLB details such as size, associativity and replacement policy. More importantly, some kernels rely on TLB details to function correctly.

Some ISA specifications explicitly carve out memory management as a separate specification or leave it open as an implementation choice. Even then, does this make those TLBs not “architectural”? Maybe it is better to ask if a TLB is a user or kernel program visible feature without using a timer.

Do you think a physically-addressed cache is a program visible feature without using a timer? (Whether yes or no, the interesting part of the answer is in your delineating assumptions.)

You may find these slide decks useful for an introduction to the FPGA technology: Lecture 1 (perspective), Lecture 2 (basic), Lecture 3 (less basic), and Lecture 4 (current). They are from the first 4 lectures in my course ECE 18-643: Reconfigurable Logic - Technology, Architecture and Applications.

See what I think FPGAs should become (Youtube).

To begin the answer, I assume you understand the basic roles of HW and SW in traditional computer architecture. Computing directly in hardware is very fast, very efficient, that is, until you need to do something different than what the HW does. On the other hand, building a general-purpose piece of hardware (a processor) whose moment-by-moment functionality is set by SW allows for an easy and flexible way to realize a computation.

SW is not as fast as HW, but it is more than good enough for many scenarios. Whenever SW is good enough (in speed/energy/size/weight/cost/etc.), we should use SW to get the job done. HW should be introduced only when SW is not good enough. Traditionally, only a small number of very common compute tasks (needed by everyone all the time, mainly in communications and display graphics) have warranted dedicated HW.

The combination of general-purpose SW execution plus a small number of hardened functionalities has been a very effective partnership until recently. With increasingly stringent performance and energy requirements, there are more and more things for which SW is not good enough. The HW/SW partnership doesn't work very well when too many different compute tasks need to be hardened, even worse when the tasks are important to only someone, sometimes but not to everyone, all the time. It is even worse when the tasks that need hardening cannot be anticipated or finalized at HW design time.

This is the opportunity for reconfigurable logic to enter as a third partner in computing. Reconfigurable logic is not as fast/efficient as HW nor as easy to program as SW, but it is programmable like SW but faster and more efficient than SW. Things that are already well handled (performance and economics) in HW or SW should stay in HW or SW. The opportunity for reconfigurable logic is in new computing requirements where SW is not good enough but HW is not fully justified. Reconfigurable logic is by nature a middle-ground option.

For reconfigurable logic to fulfill its maximum value proposition in the partnership, it is most important that new-generation reconfigurable-logic designers (1) learn to exploit runtime dynamic programmability; (2) develop a computing mindset; (3) have tools catered to mapping computation to not-fixed HW design. A new reconfigurable logic design discipline with compute-motivated abstractions and dynamism needs to exist beyond traditional “digital design” of gates, wires, and clocks.

Designing hardware is not inherently more difficult than programming. Slow hardware is as easy to develop as slow software. Designing good or even just good enough hardware can be hard, but so is getting performance from software.

Among all design solutions that correctly meet the same functional specification (give the right answer), a design can be judged better or worse by deployment-specific metrics of goodness, encompassing any combinations of performance, power/energy/thermal, cost, weight, size, noise, and anything else one might care about besides computing the right answer.

It's just that we never design hardware just to be correct. If you are ever asked to implement something just to give the right answer, do it in software. Even if the good-enough bar is raised, as long as you can do it well enough in software, you should keep doing it in software. You should only contemplate using hardware on problems that are too hard for software. Maybe in that sense, one could say hardware is harder than software.

I don't understand why people expect high-performance HW design should ever become easy when performance has never been easy in software (except in certain bounded domains where domain-specific knowledge can be neatly packaged into tools and libraries). I do think HW design currently suffers from being unnecessarily hard—from poor use of abstraction and tools that don't always work as advertised. These unnecessary difficulties (which RTL designers somehow all find acceptable as “cost of doing business”) need to be removed. That still will not make performance and efficiency easy (except with domain-specific tools with carefully selected degrees of freedom in design input and output). Really good designs require inventiveness and creativity that is not even always teachable to another human being.

(This is related to the above. By High-Level Synthesis (HLS), I mean modern commercial C-to-HW tools. Concretely, I am speaking about Xilinx Vitis HLS and Intel AOC—which I use—as examples)

If you have never done so, write a C program to multiply two 4096×4096 matrices of doubles to run on a decent CPU (your choice). Estimate how long it should take to run before you time it for real.

If one copied a textbook triple-loop (for i,j,k, C[i][j]+=A[i][k]*B[k][j]), you will find that your program takes tens of minutes, many orders-of-magnitude slower than what the CPU's advertised peak FLOP rate (multicore and AVX included) would suggest or what a good GEMM routine (e.g., https://en.wikipedia.org/wiki/GotoBLAS) actually can get.

(If you do try this, try switching the loop order and see what happens. If you are really serious, study and implement the tiled iterative algorithm in https://en.wikipedia.org/wiki/Matrix_multiplication_algorithm and see how many tries it takes you to get in the same ballpark theorized for the “ideal cache”.)

In the above, is the C language, the compiler, or the program/programmer the reason for the orders-of-magnitude difference in performance?

When HLS produces lower quality results than RTL, who is likely at fault? In a design contest pitting HLS against RTL, if I get to see the RTL design solution, I will be able to produce a bit- and cycle-true replica RTL from Vivado HLS with only a few esoteric exceptions. HLS does not hinder you from expressing most RTL designs you can come up with; it just may not make sense to express RTL through Vivado HLS if I have to specify the same amount and level of detail in HLS as in RTL. In a compute acceleration design setting, given two comparable designers equally skilled in RTL and HLS respectively, all else being equal, the HLS designer will iterate through the design optimizations (both algorithmic and hardware mapping) much faster than the RTL designer.

HLS is still evolving, but it is a practical and enabling technology worth learning by hardware designers and by HPC programmers who understand spatial concurrency and memory organization. It needs to be used in the right place and used correctly.

My thoughts on how hard is it to use an FPGA for compute acceleration in 2023?

It is very important to differentiate Verilog the simulation language and Verilog the RTL synthesis language. (One is not simply a “subset” of the other. See what I mean here.) It is very important to understand RTL before learning how to express RTL in Verilog for simulation or for synthesis. Learn and practice the coding discipline so the behavior of the logic synthesized from your Verilog RTL don't disagree with the simulation behavior described by your Verilog. I really like the HDLBits website.

True or False:

An instruction opcode X is used infrequently in an embedded workload (less than 1 in 500 executed instructions). Amdahl’s Law would say NOT to worry about optimizing the executions of instruction opcode X on a processor designed specifically for that workload.

(!eslaf si sihT)

This material is available for anyone who wants a deep dive into superscalar, speculative, out-of-order register dataflow.

This is a good example of something that cannot be taught, only learned.

Many aspects of computing grow exponentially. Seeing an exponential function on a log-linear scale belies how quickly an exponential function grows. I was taught to imagine looking at an exponential function on a linear scale; from far back enough, you can always make the plot look like a flat line transitioning to a vertical line; the x-axis value of where the transition happens just depends on how far back you stand. In other words, for a technology growing on an exponential trajectory, at any moment in time, as quickly as the technology grows, the past is being made obsolete just as quickly.

It is also important to keep in mind that the integral of an exponential is also an exponential. For an imagery, suppose back in 1980 you had a very important sequential computational problem that required an enormous number of compute cycles. In 1980, you began running and kept upgrading to the latest processors whose performance doubled at a fixed time period. If you finally finished today, you could instead only start today and be finished in just 1 time period (and save the cost of the processors and electricity over the last 40+ years). You could recast this scenario to a large parallel problem to consume the accumulated cycles of the #1 supercomputer or the totality of #1 to #500 supercomputers. You could also adapt the scenario to the growth in data transmission and storage.

There are no dull moments with exponential growth.

It is very good to do undergraduate research, especially if you plan to go on to graduate school. It will give you a taste of “research”, and it will give your research advisor something concrete to write about in the recommendation letter (if you do a good job that is). If you are planning to go to industry, undergrad research can help you uncover your interest, and it can give you hands-on experience practicing what you learned in the classrooms.

I strongly recommend that you try out research during the summer when you can devote the time and really get something out of the experience. You have to have realistic expectations though. Many of our freshmen and sophomores are already very skilled in programming and maybe even hardware design, but “research” is about a lot more than implementation skills. The more courses you have taken, the more you will develop the maturity of thinking and the depth of understanding that are needed for productive research. The summer after your junior year is the ideal time to do a research project; make sure you have taken the key Depth course in your area of interest by then. (For example, if you are interested in my work, the key course to have taken is 18-447.) In the earlier years, look around for “projects” (as opposed to research) opportunities. There are a lot of projects on campus that could make use of good programming or hardware design skills.

I generally advise undergraduate students against doing formal research projects during the semester (where there are hard commitments or you are graded). Undergraduate course work is hard enough at CMU. Try to do both at the same time, at least one side is going to suffer. (Experiences say undergraduate students will prioritize course HW, projects and exams over research since a research project usually doesn't have set week-to-week graded deadlines.) This doesn't mean you shouldn't do things outside of classrooms. Look into, for example, Build 18 (http://www.build18.org/), the Robotics Club, the Mobot Race. It is also just fine to think of something cool to hack together on your own. Especially during the semester, you should look for things that are relaxing and fun to do but won't add extra pressure to your course load. (If you say “but I am already doing well enough and still have all this time”, see what I have to say about overloading. If you are really that good, you really should try to do even better.)

If you appreciate the difference, you should try undergrad research experience before you graduate.

If you don't understand the difference, you really must try undergrad research experience before you graduate.

The fruitful kind is full-time in the summer. Research is not a casual pastime.

If you are thinking about pursuing a PhD, your goal for doing undergraduate research is to (1) learn if you like research; (2) learn if you like a research area; (3) learn if you are good at research; and (4) convince a letter writer of your potential to develop in #3. Focus on convincing yourself and a letter writer that going to graduate school is the right thing. It is very important to give appropriate emphasis to form vs function in undertaking undergraduate research.

To train to become a practicing physician in the US requires 4 years of undergrad, 4 years of medical school (which includes 2 years of clinical rotation internships in hospitals), up to 7 years in residency plus fellowships depending on the intricateness of the specialty. As an undergrad interested in medicine, it is valuable to volunteer at hospitals or get certified as an EMR/EMT to become exposed to the field or to discover your interest. Don't expect to cut open any patients right away. It will take more than basic EMT certification just to be qualified to poke someone with a needle under a physician's “order”.

One of the things you learn in graduate school is how to do research. There is no universal consensus on what counts as “doing research”. A lot of what I have done has been labeled “engineering” or “implementation”.

I have come to frame doing research as 1) asking a question and 2) looking for the answer. The quality of a research project depends as much on asking a good question as on finding a good answer.

• In an undergrad education, you become good at answering questions, usually questions designed to have answers and solvable by following what you just heard in lecture. This is not research.
• Starting out in grad school, you first learn to solve “under-specified” problems. These problems will still be handed to you by your advisor, but you will have to learn how to fill in the missing details on your own to make the problem precise to solve. You might try filling in the details in a few different ways to see different answers. This starts to feel like doing research.
• At some point you become curious about a question of your own. You work on asking your question in a thesis proposal. When you follow through on answering your own question in a dissertation, you have now done “original and independent research”. Whether you do good or bad research, you get to graduate.
• The hope is after graduating, you will continue to work on becoming better at asking and answering questions. The further along you go, the more the emphasis shifts toward asking the “right questions”. There are a lot more people capable of answering good questions than those capable of asking them.

As noted above, you will be much more likely to succeed in securing a position if you approach the professors with very specific goals and a little bit of track record. Do not do the following.

• Do not send the same generic email to multiple professors. Do not tell a computer architect professor that you are very interested in nothing in particular or something not in computer architecture. You are not going to get a position by saying “I am very good at everything;” “I will do anything;” or “just give me something to work on.” In general, professors are not looking for availability of labor; we are looking for genuine interest and commitment.
• Do not contact a professor if you don't already know what he/she does. Visit his/her research website; read a few papers. It helps a lot to be able to say something specific and to offer some ideas of what you would like to do.
• Do not be unprepared to answer the question “why do you want to do a research project?” (An honest answer like “I need the units to graduate” will work in some circumstances.)
• Do not leave out your resume in the initial email (or not have it when you visit). There may not be a second exchange; get your foot in the door.
• Do not be invisible or do a mediocre job in a course, then ask the instructor for a position at the end of the semester.
• Do not be fixated on a particular project or a particular professor.

As with many other things desirable and scarce in life, persistence, patience, and boldness count in getting what you want. Don't be discouraged if you don't hear back or get turned down. Try, try again. On the other hand, you do have to have something real to offer when you approach a professor. Your own eagerness or desire is not enough; you will not get anywhere if you are not willing to invest the time up front to polish your resume, to investigate the research opportunities, or to do an impressive job in a course.

I do work with undergraduates on research. Almost without exception, the following are true.

1. The student is planning to go to graduate school. (I changed my mind on this. Everyone should try “research”.)
2. The student is interested in computer architecture and hardware.
3. The student has taken 18-447 (and done well).
4. The student has substantial experience with C (or some other programming language) AND Verilog (or some other HDL).
5. The student is available for full-time research (for pay) in the summer before the fall of her/his graduate school application.

I only have the resources to work with 1 or 2 students each year. So I prioritize for those who fit the above criteria. I have stopped working with undergraduate students during academic semesters, except for 1. someone continuing from a summer project, or 2. someone who just needs a “consulting” mentor for his/her honors senior project of his/her own design. I am generally very willing to talk to you (CMU undergrads) especially if you come during my posted office hours.

Pursuing a PhD is not a small decision. Go talk to a professor in your area of interest. Make sure you understand what it is all actually about. Also, you should read this.

You can apply before you commit, but before you commit to studying for a PhD, ask yourself this one important question: “what do I plan to do afterwards that requires a PhD?” Don't start if you don't have an answer. There are no industry positions out there where having a PhD degree, in and of itself, is a necessary or sufficient condition. (If you need inspiration.) If you want to become a “professor”, make sure you know what professors actually do. I am in front of a class for only 4 hours a week; most of what I do is not visible to undergrads who only see me in class.

While you are deciding, find out which school and professor is working on what in your area of interest. For computer architecture, a convenient starting point is IEEE Micro Magazine's annual Top Pick's issue. Skim through the article titles to see what topics interest you. Try to read a few of these “highlight” articles. To probe deeper, you have to dig into the referenced full papers in the conference proceedings. (Search on IEEE Xplore and ACM Portal.)

The Synthesis Lectures on Computer Architecture is a valuable background resource for starting work in an area.

The statement is a good start but deficient at multiple levels. First, it would be much better if you “knew” you wanted a PhD. Second, to want a PhD has to be predicated by what subject you want a PhD in. Third, there needs to be forethought about, afterwards, what you want the PhD training to lead to.

A PhD is not an honorific or a piece of paper. It is what you build yourself to be capable of (in original and independent problem solving and knowledge discovery). It is a starting point to something.

It does earn you some benefit of the doubt . . . (continued next)

“A 'thesis' is a supposition of some eminent philosopher that conflicts with the general opinion…for to take notice when any ordinary person expresses views contrary to men's usual opinions would be silly.” (according to Aristotle)

Don't lose sight that, to the ordinary person, an eminent philosopher also sounds pretty silly. (Just for laughs.)

Rule #1: Unless the professor knows you by name without prompting (and for good reasons), don’t bother asking him/her for a letter. Rule #2: If a professor appears reluctant to write you a letter, it is of little use to try to persuade him/her. An impersonal, lukewarm “form” letter will not help you and may actually hurt your case. If you know you are going to need recommendation letters in the future, start building relationships early. A good letter is earned.

For formal letters, make sure you ask your letter writers at least one if not two months ahead of the deadline. Be sure to provide very clear instructions to your letter writers. Provide pre-addressed and stamped envelopes if appropriate. Remind your letter writers again a couple of weeks before the deadline. If possible, take it upon yourself to verify the letters have been received by the destination.

Much of the above still applies, but references for industry jobs are much less formal. Be sure to ask for permission before you list someone as your reference. It is customary to just say “Reference available upon request” on your resume. Usually companies won’t even bother to ask you for your list of references until after you have gone through a first interview and done well.

Many undergrads are conditioned to answer every question, whether they know the answer or not. This may be okay on a class exam since the consequences are lower bound to not getting any points.

Out of school, in any kind of interview, in making up an answer to a question, you are sharing with the interviewer much more than the question's intended assessment scope, without lower bounds. Don't risk giving an answer that is "not even wrong". If you don't know the answer or don't understand the question, don't feel compelled to give an answer. Saying you don't know sets a lower-bound.

Even more dangerous, giving an answer you don't know to be correct in real-life situations has real-life consequences (think, medical doctors, bridge designers, teachers, etc.).

You should also be aware that some questions are not questions. Be especially careful with these.

See also this related comment.

If you do pursue a PhD study, the first of the many trials and tribulations you have to face down is the “Qual”. This usually comes early in the process. The PhD qualifier exam in ECE is part performance audition (you give a mock conference presentation), part improv (you need to field Q&A), part psychoanalysis (how you answer is more important than the answer), and part stress testing (the questions get harder until you crack).

Some common pitfalls to avoid:

1. Watch out for under-constrained or ambiguous questions, whether posed by design or by mistake. (Don’t answer a question you don’t understand. It is okay to ask for clarifications.)
2. Don’t feel compelled to answer quickly; don’t just say whatever comes to mind. (Be comfortable taking the time to understand the question and develop an answer. Thinking out loud is a good way to reduce dead air time. Sometimes you will get helpful guidance from the questioner, but be aware of what you are revealing in the process.)
3. A “yes/no” question demands a “yes/no” answer. (Fight the urge to run ahead of the questioner. Even if you feel the need to supplement, begin with a “yes” or “no”. If the answer is “it depends”, be sure you understand the next point.)
4. Don't give fluffy, non-committal answers. (Trying not to be incorrect is not the same as answering.)
5. Don’t pad answers with extraneous information. (Just answer the question. Answer only what you know to be the answer.)
6. Don’t agree with everything said; don’t change your mind just because something is suggested. (Stick to what you know; stay within what you know.)
7. Don’t stubbornly defend an answer you can’t justify. (You were not supposed to give that answer to begin with. Also, it is not clear how you would go about defending an answer you can’t justify.)
8. Don’t be afraid to acknowledge you don’t know or you were wrong when that becomes fully apparent to you. (Coming across as incapable of realizing something is awry does not make you look better.)

These missteps are usually not direct causes for failing a qual; otherwise just about everyone would fail. Students do tend to, one way or another, work out these issues before they stand for their thesis defense. The most important step to start on is to form a clear demarcation in your mind between what you understand and what you don't.

P.S. Until you develop your own style, imitate others.

College is all about finding your knack.

Hopefully you don't know anyone like this or this.

In case what I said depresses you, here is my favorite pirate joke. (You have to tell it right, with the pirate voice.)

I don't see myself as speaking to motivate on this page, but you can say I am offering life lessons to anyone that will listen.

Didn’t find the answers you were looking for? Try emailing me the question directly. How to contact me.