I started applying for internships during my freshman year and I got rejected so many times that I created a folder in my email and labeled it “Companies that missed out on me” just to remind myself that one day, during my speech at the awards ceremony for my Alan Turing award in computer science, I would know who I’m referring to when I say, “To those that didn’t believe in me…” and “I got rejected X times but never gave up…” this kind of story. 

Getting rejected hurt. I was confused. I lay in bed wondering, is anyone ever going to hire me? Is computer science for me if I can’t even get a callback? Some companies wouldn’t even reply with a rejection, I would just never hear back. Some days, I told myself that I wasn’t doing enough so I started doing “cold introductions” on linked in. I would send people messages saying, “Hey Mr. / Mrs. X, I see you work at Company Z,  if you need an intern, I’m available… Attached is my resume.”. For some reason, I had it in my head that if I didn’t get an internship during my summer breaks, I was failing and incompetent – this couldn’t be further from the truth, not having an internship doesn’t mean you are incompetent. 

At that time, I was desperate. Desperate freshman (freshwoman?). For some of the rejection letters I got, I started responding to them and asking, “Why did you reject me?” For the most part, I never got replies. Some did reply though. Among the ones that did, one told me “well, we are looking for a candidate that is local and you aren’t” another said, “You are not a US citizen so you don’t meet the minimum criteria” another said, “Your skills don’t align with what we are looking for right now.” From these responses, I realized that for some of these applications, there is nothing I could have done differently to change the outcome. 

This was lesson number 1: Sometimes, the reason why you get rejected has nothing to do with you, so don’t let rejection define you.

This is why you should not let a rejection demotivate you from continuing to apply to other places. Furthermore, don’t call yourself a failure because you didn’t get that opportunity. If it was out of your control, then you can’t blame yourself for not getting it. Move on and look for the next opportunity.  

On another occasion, one particular response I got was, “Your resume doesn’t highlight your skills well enough in a way that I would be able to match them to our requirements. Re-organise how you present them, good luck with your search”. 

Lesson number 2: Get as many people to proof-read your resume and receive as much feedback as you can on how to improve it’s presentation. 

Sometimes, the way you sell your skills might be selling yourself short. Meet with guidance counselors, compare your resume to your peers that you know are getting interviews and callbacks. Ask anyone and everyone you know that you feel might give you beneficial feedback. (Hint: Some of your professors would be happy to look at your resume and give you feedback. Ask them for 3 mins of their time and most likely, they won’t say no. They are happy to help)

During another period of many rejections in my sophomore year, I stumbled upon this website for a startup that did “Blind hiring for interns”. Essentially, you had to remove your personal details and any self-identifying information and submit your resume to this start-up. After, they would present your resume to companies that had signed up with them that needed interns for the summer. The idea behind this program was that they recognized that a lot of bias could have played a role in the reason as to why some people didn’t get hired.  When I submitted my resume, I got over 10 callbacks from different companies. From 0 to over 10 callbacks. 

This taught me something: To ignore the fact that race, gender, nationality, and people’s personal bias can play a role in why you aren’t called back would be unjust. But don’t let this make you give up or stop you from applying to other places. There are still employers that want people like you, but you won’t find them if you give up too soon. So KEEP APPLYING.

It’s important for you to realise that there is so much more to who you are as a candidate than how some people may perceive you. This should also encourage you to look into company culture and reputation as you choose the companies that you apply to.

For my freshman year, I ended up working at an unpaid internship for the summer and because I did, I had something to add on my resume when applying for my sophomore year summer internship (including personal projects I was working on). That year,  the job hunt was a little easier but still many rejections. Junior year might have been the most interesting time. Because I had 3 past internships (2 during the summer and 1 during the school year) and personal projects I worked on, I got so many interview requests for summer internships that I ended up not responding to half of them. These requests were from both Big N companies and small start-ups. Sometimes I looked at my inbox and it felt like a dream. It didn’t stop there though, even before I started my senior year, I had big N companies, hand pick my resume for full-time roles post graduation. 

Here’s my point: Start applying for internships NOW regardless of what year you are in. In the beginning, getting rejected is so normal and it happens to everyone. So, don’t give up. If you feel like you are further along but never had an internship, there’s a popular Chinese proverb that says “The best time to plant a tree was yesterday. The second best time is now.” Start applying to as many places as you can. For seniors that have never had an internship, maybe consider graduating a semester later (if you can) and possibly find an internship that you can add to your resume to make the job hunt post-graduation much easier? If you can’t, that’s okay, do as many personal projects as you can now. The way to get hired is to show your prospective employer that there’s something you bring to the table. Your experience is what gets you noticed. Good luck with the job hunt! As always, if you have any feedback you want to share, please write to me at nekesame@buffalo.edu

Links to some sites that might help with the job search and interview prep:

American Red Cross Communications Paid Internship

HBO 2019 Fall Intern: Business Affairs – Film Programming

https://www.techinternship.io/discover

https://www.pramp.com/dashboard#/

https://triplebyte.com/

This week, our very own Prof. Andy Hughes wrote an article that is thought-provoking. After reading it, I thought twice about how to approach my office hours with my instructors henceforth. Furthermore, it changed the way I thought about my major too. I hope you enjoy it as much as I did.

What should a computer scientist know?

Now that computer science has become so popular, there is a large population of students that enter the field without knowing exactly what it entails. Many come in with a narrow-minded vision of computer science based on their limited exposure to the field. Have you ever had someone ask you to fix their printer after hearing you study computer science? What about build a website? Or write an app? The images of computer science that are broadcast in media usually differ drastically from reality, generalizing computer science to all things computer and IT related. This leads to a rude awakening for some students when they set foot into their introductory courses and find that much of the foundations don’t require a computer at all.

Introductory computer science courses introduce students to the tools needed to start building solutions by teaching language to control computation. Simultaneously, they begin introducing techniques needed to decompose problems as instructions for computers; many of these problems are trivial to explain in English or perform by hand but become tedious or difficult to communicate to a machine. Once you know how to communicate these tasks to a machine, you know how to write code.

The ability to write code does not make one a computer scientist, though. It is only a tool used to convert solutions for a problem into implementations. You wouldn’t call yourself a chemist once you know how to weigh and mix chemicals to perform a reaction someone else provides to you. A computer “scientist”  should have an understanding of computing in order to design processes to solve problems. The design process draws heavily from mathematics and logic, the roots of computing. A program is only a verifiable experiment to realize your solution.

Is this topic relevant to me?

Due to the tight coupling with mathematics, there are fundamental reasoning skills introduced early on in the curriculum that serve as a cornerstone for many computing courses. Commonly, these are introduced on their own as a mathematical concept and are only motivated mathematically. When the relevance isn’t immediately obvious, disinterest grows easily. At the first signs of this, you should ask yourself or your instructor(s) how these more theoretical concepts could align with the interests you have.

It is important to keep a curious mind and ask questions based on your interests. For example, prime numbers are used on every secure browser session, probability and linear algebra contribute to recommendations on YouTube and Instagram, and set theory is heavily relied upon when searching and filtering through Amazon products (among other things). These examples are complex problems, so to approach these problems you must understand all of the bits from the ground up. Unfortunately, an introduction to the concepts fundamental to these problems only provides you with the most basic toy problems/applications so that they are more generalizable, as there are many other applications for these key ideas (like sets). Discrete structures is one such culprit but depending on where your interests lie, you can gain great insights into the course topics if you push beyond the scope of the coursework where it is introduced. Whenever you feel something is not relevant to you, ask your instructor to help provide more context. This is the best usage of office hours.

There is great benefit to knowing why something is relevant to you. It is much easier to learn something when you are properly motivated. Is this relevant to me becomes a question that can be easily self-answered with a “No” and is not nearly asked enough of instructors. When this question is asked along with sharing your interests and concerns, it may spark a discussion that grows insight and sheds light on connections that may otherwise be left in the dark.

So what is the right answer?

By now, I hope you are convinced that there is no general answer to what a computer scientist should know because the full answer is individualistic. There are common skills that all computer scientists should have, which come from core courses (algorithms, data structures, programming skills, mathematical reasoning). The question of “What else should I know?” may be one of the most important questions to be asking and reasking during your tenure in university, and beyond. You should be seeking the answer to this within the scope of your interests and, most importantly, always continue to ask more questions. This will best equip you to adapt to any problems that come your way.

A new week is upon us and so is a new article. From someone new. Not me, not faculty, but a fellow student. Remember when I mentioned you are going to hear from a lot of different people? Well, this week, our fellow student in the CSE program wrote an article that I think is not only timely, but also insightful. I meet lots of people who tell me they want to do computer science because they want to learn how to hack, or when they are being honest, they say they want to code like they see people in the movies. On a more serious note, many people, including the students in the program, might not understand what Computer Science is about and fortunately, this week’s article starts to bring some insight to a much bigger conversation and topic that I hope we can expound on as time goes on. So, if you feel inspired after reading this and want to share your views with us about this same topic, please write to me at nekesame@buffalo.edu. Also, if you have more questions about the program, feel free to reach out too. If I can’t answer your questions, I will be sure to point you to someone who can. I look forward to hearing from you and enjoy the rest of your week!

What is Computer Science?

What are some things that you think of when you hear the words “Computer Science?”  Words like code, programming, systems, algorithms, and so on often rise to the surface whenever Computer Science is mentioned.  While all of those things are important, there is more to computer science than just those things. Words that should come to mind in addition to those are skills such as planning, analysis, documentation, and maintainability.  

On the surface, Computer Science seems like only programming and not much else. After all, this is what is shown in the media.  Movies and TV shows like to depict computer scientists as people who are with their computers all day, constantly writing things and always knowing how to respond to every situation.  They never show things like the planning of systems and the comparison of ideas on how a system should be developed. In reality, those things are just as important as programming.  

Think about this: when you receive a problem or an assignment, do you jump right in and start working on the questions? Or do you look at the questions and take time to plan out what your solution will look like and whether or not it will be correct?  Planning your solution to whatever problem is a crucial part of Computer Science. You can sit at a computer for hours trying things and developing your solution to wind up with a mangled mess of code that, while functional, not very practical. However, you can take those same hours to plan out your solution and save yourself some stress by working out those potential problems before even opening up an editor rather than in the middle of development.  Anybody can write a program, but not everybody can plan a program.  

Program maintainability is probably the most important part of writing good code, as this illustrates the difference between a programmer and a computer scientist.  Programs are not a one-and-done thing; they evolve over time, which is why maintainability is important. If code is a mess of logic and various other components, it might work for what it was meant to do, but it can never go through evolution because nobody can understand where to begin deciphering what is going on. You might be thinking ‘Well, I know what is going on so I can just explain it to people if they need to use it,’ but think about what would happen if you wrote code like this in the workplace.  If you write this kind of code and then leave the job, you can no longer explain that program to people. This may cause the company to spend time and resources deciphering code that they already have, just to be able to modify it to work for another kind of problem. This can be solved by planning your programs, and providing good documentation on what everything you are writing means. Anybody can write a program, not everybody can design a program.

Documentation is the most essential thing to writing maintainable code.  If somebody were to need to use your program to figure out a task they were working on, the first thing that they would look at to figure out what you wrote would actually be your comments of the code, not the code itself!  The only things that people will care about when they go to use your program are:

1. Whether or not your program does what it needs to accomplish.
2. Whether or not your solution is efficient.

The goal of writing documentation is to communicate information effectively and efficiently to the potential user of it, as well as communicating how to use it.  Think about this: if you are developing a program and have the option of using two pre-written programs as part of your solution, would you use the one that takes you a few minutes to read about, or would you spend an hour or so looking through the code trying to figure out what it does? People think in different ways as well. Two people can be given the same problem, yet think about it in completely different ways.  Documentation can help somebody who does not think in the same way you do in order to understand what you wrote. Anybody can write a program, not everybody can understand another person’s program. 

Analysis of your programs and algorithms is also an essential part to why computer science is different to programming.  This is due to a number of reasons, the most important of which are run time and space usage. Efficiently writing a program involves making the most efficient use of space and saving the most time possible while maintaining the functionality of the program.  If you were a hiring manager at a company, and two candidates were applying to the same job, would you take the one that answered all of the problems with a program that works, or would you take the one that provides an efficient program that works for all of the problems posed to them?  Anybody can write a program, not everybody can write a good program.  

In conclusion, being a computer scientist is not just about knowing how to program; it is about being able to effectively write a program that works efficiently through thorough analysis and planning of how to write the solution. The program should be easy to understand through documentation, and that is able to evolve as the need arises.  I hope that this helps you to better understand what computer science is.  

Ever wondered what programming professionally would be like? I have some answers this week.

Remember when I mentioned faculty members would contribute to Engineer’s lounge? This week, it’s happening. Prof. Alan Hunt wrote an article that I think is timely and important for anyone that ever hopes to program professionally. Whether it’s at an internship, research position or full-time job, and you ever wonder, what will I do when I have to deliver actual products for businesses with the code I write? This article might be able to give you a good idea about what to expect and how to navigate the challenges that come with working professionally as a programmer just starting out. I hope you enjoy it as much as I did. 

Developing Good Judgement

As a hiring manager who has worked with many developers at the start of their careers, and as a developer myself back in the mists of time, I have seen a common theme when a particular development effort falls short – the developers didn’t understand what problem they were trying to solve.

While you’re in school, this is almost never an issue – the problems you are solving are clearly defined, tailored to be finished in a semester, and have expected outcomes that your “boss” has calculated before you even start working on the project.  The primary goal of these problems is to illustrate some aspect of computing theory, or to provide practice in applying ideas learned in your coursework. In other words, the problem that you are trying to solve is the problem of making yourself a better computer scientist!  Unfortunately, upon graduation, the majority of computer science students will get jobs in the industry where none of these things hold true; problems are frequently poorly defined, indefinite in nature, are difficult to measure, and have stakeholders with competing agendas trying to move the project in different directions.  The primary goal of these problems is to solve a business problem, and what it may be can vary from supporting HR in their applicant screening process to helping finance generate monthly reporting to building software that is sold to your customers. In each of these cases, learning and using technology is a means to an end, rather than the end to be achieved.

One place that you see this disconnect frequently is in technology selection and architecture decision making.  The temptation to use the “bleeding edge” of technology is strong for inexperienced developers, who want to do what’s trendy, without taking much time to assess whether or not the tools they are choosing are actually the best tools for the job at hand, and whether or not there are potential hidden costs and ongoing maintenance issues introduced due to those choices.  Let’s imagine a scenario where the project is a relatively small one and is unlikely to require extensive expansion in the short term. Selection of a constellation of frameworks that are not used consistently in the environment to build it will take more time initially (due to the learning curve, cost of tool installation, setup, and configuration, and cost of making the code comply with the framework structure).  It will also take more time in the long run, as each time a change needs to be made, the learning curve is likely to reapply, and the overhead of complying with the framework still exists. Furthermore, it limits the people who can effectively maintain that project to those familiar with the framework, or requires that they go through the same learning curve as the initial developers. Now let’s make matters worse – after six months, there is a critical update in one of the tools used, requiring that it be patched to a new version to fix a security flaw.  Of course, upgrading that tool means that another part of the framework needs to be upgraded, which in turn requires another upgrade… and at the end, the amount of effort expended produces no additional value to the business, it simply reduces risk introduced by the initial technology choice.

A second place that you see this disconnect frequently is in the tendency to accept the requirements that are given to you as complete, correct, and effective in solving the underlying issue that the application is being developed for.  This is sadly almost never true! Requirements originate with customers or business users who are trying to define the problem that you need to solve for them. They frequently make assumptions in that process based on what’s “obvious” to them, in the same way, that you wouldn’t bother to tell another developer to not duplicate code or that they should use descriptive variable names.  They may also not understand what is simple to achieve and what is very difficult, so they may ask for something that is not important to them, but is very hard to build – which can only be done at the expense of things that are more important! They may not even understand themselves all of the intricacies of their problem, and so will provide incomplete information. When this happens, the developer can do two different things.  The first is to provide exactly what is asked for, and then shrug when it doesn’t solve the problem and say that they did their job. They will be right – but no one will be happy, and they will create an unfortunate reputation for themselves. The other possibility is to understand the problem that they are being asked to solve, and ask questions, confirm assumptions, examine the current process and tools, and build incremental prototypes and solicit feedback throughout the process so that no one is surprised at the end.  This may mean that you need to learn enough about finance, or warehousing, or logistics, or pricing, or quality control to ask good questions and to make sound assumptions. Guess which one happens most often?

The core of these problems is that success in the real world depends on developing good judgment.  Knowing how to pick tools, anticipate problems, assess risks and benefits, know when to question and when to push back against your managers and customers are not easy things to learn.  There is an old joke that is surprisingly true… “Where does good judgment come from? Experience. Where does experience come from? Poor judgment.” The only way to really internalize the ability to solve the right problem is to solve lots of problems.  Poorly. And then from each issue that you run into, find ways to avoid making the same mistake the next time. I always told my teams that if you ever look at something you wrote five years ago, and don’t think that it’s junk, you’re not making the progress you need to as a developer.  It’s important to understand that the cycle of trying, failing (or creating a mess you have to clean up later) and then doing it better the next time is a necessary one. No book, no Wikipedia article, no course and no stack overflow post can teach you judgment. It’s acquired through practice, and a constant desire to make each application you write better, more scalable, more maintainable, and more user-friendly.  Like with any profession, mastery will not appear overnight, but the more code you write, and the more you work with non-technical people to solve real problems, the more capable you will become.           

You have heard it before and you will not stop hearing it, as long as any part of your school or future work experience will involve programming, writing clean and good code is important. I’m not going to go through all the details about writing good, reusable code because there’s a lot of material out there (that I recommend you seek out) that would help you extensively with this. I’m only going to go through the most basic things that I think might be relevant and helpful to some since I have come across many people who have questions about why they need to go the extra mile of writing “good code” if their program already works. As a student starting out, programming can be daunting and that’s understandable but it’s equally important for you to invest time into learning how to write good code because it will only pay off well. There’s no demerit, that I know of, that will come as a result of learning how to write good code. On the other hand, there’s not enough time and space for me to write about the downsides of writing bad code. Always remember that time spent writing good code is never wasted time. 

Why good code matters:

1. For your own well being and sanity. There’s nothing more frustrating than looking at your own code days after writing it and not knowing what’s going on in the whole program. And it happens all the time even to the best of us if you don’t have well-written code. When you take the time to write appropriately commented, well-chosen variables names and well-indented code (insert many other things that comprise of good code), you spend less time debugging and your code becomes easily reusable if you ever need it in the future.
2. It will save you so much time when you go to TA office hours when you need help with debugging your code. Well-written code is so much easier to read and also easier for someone else to follow what your program is doing. This saves you so much more time because the faster they find the bug, the faster you finish your programming assignment, the more time you get to play! 
3. If you ever work in a team at an internship or full-time job, good code is vital because your eyes will not be the only ones that see your code. Good code makes collaboration much easier and in general, helps people understand what you are doing collaboratively and increases productivity in team projects. An important question to ask yourself when writing code is this “If someone else read the code I’ve just written, would they be able to understand what this code is doing?”
4. Most interviews for internships or full-time positions require that you have a technical interview where you exhibit your programming skills. Your interviewer will most likely judge you based on the quality of the code you write and your thought process behind it. If your code isn’t clear enough and your interviewer has to spend a lot of time asking you questions about what your code is doing and not on the concepts that are relevant to CSE or CE, then that might hurt your chances of getting hired. So always write clean code that is easy to understand and follow.

How to write good code:

Do not start writing any code if you don’t know what you are going to write. Let me put this way, if you can’t fully explain to someone else/yourself what your code is supposed to do at each step, then you shouldn’t start writing it. First, computers are dumb machines that only do what you tell them to. Not what you want them to do or hope for them to do. Only what you tell them. So if you intricately don’t understand what you want the program to do beforehand, you will not get the results you expect from your program when you start coding.

Think of it this way, when you get into a car to go to the beach, you don’t just start the ignition and start driving to random directions and hope that somehow the car will get you to the beach. What happens is you plan your route in advance and only start driving when you have an established plan about the direction you want to take.

If it never makes sense for you to start driving before planing the direction you should take, the same applies to code, it should never make sense to start coding in your IDE before planning out exactly what you are going to tell the computer to do. 

As with driving routes, things can change, you may learn of a road accident that requires a detour or think of an alternative route that might be shorter than the one you initially planned so you make some adjustments on your journey. That is perfectly fine. It happens in code too. Along the way, you might discover that there are better ways of implementing something than what you had initially written out and so you tweak your program accordingly. Just remember, there won’t be anything to tweak if you never had a plan, to begin with. So I’ll say it again, always plan out your code before opening your coding environment.  

If you are at the point where you are thinking “Okay, I get it. I need to plan before writing any code, but I don’t know how to plan, where do I start?” That is a perfectly good place to be and the right question to be asking. If you go ask your TA’s or professor about how to approach this, they would be willing to teach you ways on how to plan your code. The worst place to be is a place where you don’t know you need to plan. But that’s not you now. So ask for as much help as you can get, you are on the right track!

In conclusion, read as many books as possible on programming, it will help you improve your skills. One of my favorite books on good programming practices is Clean Code by Robert Cecil Martin, give it a try, it might help. Of course, there are many books out there and if you have any resources that you think might be useful for this topic that I haven’t talked about, please leave them in the comment section below.

I hope you have a great rest of the week! 

Note: Because we want Engineer’s Loungue to be a useful resource to you the students, please send an email to nekesame@buffalo.edu about any questions / topics you would like to hear more information about that you feel would be helpful for you during your college experience as a CE & CSE major. We will try our best to point you to resources that would be helpful and also in cooperate more topics in the articles about things you would like to learn about. The goal is to get as much help to you guys as possible during the course of your programs that would allow you to be successful.

The first week of the semester is always the most laid back week of the whole semester. But this can also be the reason why your grade slips. So start studying from the very beginning. What people don’t realize soon enough is that towards the end of the semester, you have less energy, higher levels of burn out, stress levels are higher and over-all, things can be difficult. So it never makes sense to think that you will do your best work towards the end as an excuse for wasting time now. So start now. Read those 2 pages you have just accumulated of coursework. 

My name is Mercy Nekesa and I am in charge of the Engineer’s Lounge. The goal of the Engineer’s Lounge is to be a place where Computer Engineering and Computer Science students will learn about things that are important to their future careers and their day to day college experience that they otherwise wouldn’t get from the classroom.  I am convinced that there is so much more we can share and learn from each other as scientists and engineers. If you are faculty, or student or an engineer in industry that has anything valuable to share with CE and CSE students that will help them in their careers here at UB and in the future, please reach out. We would love to hear from you.

A lot of people, rightfully so, are nervous about the Computer Science or Computer Engineering classes they are taking this semester because they don’t know what to expect and are anticipating the hardest of circumstances when it comes to the material so things are a bit uncertain. Sometimes, that can be a good thing. I think a bad place to be is when you are overconfident about your capabilities in a course you haven’t taken yourself. I don’t care how many friends told you they took the course and thought it was “easy”, “doable”, “did the bare minimum and still got an A-”. You are not your friends and oftentimes, people can have vastly different backgrounds that might have prepared them better to easily understand the class material which might not be the case for you. They got an A and you might end up with a D-. Bare minimum looks different on everyone. So always do your best. When you are nervous, channel that energy into staying on top of the class material from the beginning of the semester. Don’t allow yourself to fall back in classes you know, and your professor even warned you, will require a lot of work. They are not lying, for many it takes a lot of hard work to excel in these programs. Most times, even much more than you anticipate. So stay on top of it.  Here are some basic tips for the start: 

1. Please do the ungraded homework. Here’s the logic, there is absolutely no reason, a professor will ever give you material that they think is absolutely useless. No. reason. at. all. Ungraded homework is usually a good way to prepare you for the course and even though you feel you are prepared enough and do not need the practice in the beginning, humor yourself and do it. Most times, you might find that you overestimated your capabilities and there are things you thought you knew but not quite well. The longer you do CS & CE, the more you realize that even the simplest of concepts that you thought you knew so well can have so many more details that you missed understanding initially. So more practice with the material is not wasted practice. 
2. Take every day as it comes and don’t spend time right now worrying about homework 6  that your professor said is the hardest homework when he was going through the syllabus. Your goal should be to do what’s in front of you right now and do it well. By doing it well, here’s what I mean:

I’ve learned the hard way that if I look at the course material thus far when an assignment is given out, I might be able to solve the larger percentage of the problems on my own. 80% of the questions I asked when I needed help on homework were questions that could have been answered by reading the textbook, or lecture slides, or assigned readings materials for the course at that point. Very rarely are you given homework that was far left field from any of this so get into the habit of asking yourself these questions before you ask for help.

1.     Did I read the assigned reading for the week?

2.     Did I understand the lecture material?

3.   Did I read the homework question carefully and understand it well?

If no, what did I not understand about the question? Refuse to accept the answer “everything” from yourself. What does everything mean? Define it. Break your questions into small pieces until you are able to figure out what the actual problem is. Sometimes the problem might not even be about the real question being asked. It might be you don’t understand the definition of the terms used when asking the question. So start from there. 

 Finally, pace yourself and have realistic expectations. Know when you have reached your limits and it is time to take a break. The most important thing is your mental health, take care of yourself first before anything. You are the most valuable person. Not the courses you are taking. Those grades can be replaced, you can’t. So take good care of yourself.  

I hope to have weekly articles for you throughout the semester from myself, faculty and other students who have generously offered their time to write something. Please be on the lookout for them and I hope you have a good start to your semester!