To assist with your success in this course, a number of resources will be made available to you in order to facilitate your learning and application of the material taught. Different students will pick up the material with varying speed and facility. There is likely to be a handful who grasp it easily and quickly, a handful who struggle considerably, and everywhere in between. Students who grasp the material easily may only need to use a few of the resources, whereas others may need to work harder, longer, and delve deeper into the resources in order to achieve similar results.
The grades I assign will be based upon completion of course requirements, but it is ultimately up to you to make decisions about how much time and effort you put into things. Some may choose to put in lots of time and effort, where as others may not, for any number of reasons. Regardless of what you choose, when I evaluate your work, I will do so keeping in mind that you had available to you a considerable range of resources, such as the following:
Classroom Lectures:
Actual lectures, as presented in class, will likely be the most important source of information on the topics and materials covered. Although you will have access to much of the information (e.g., lecture slides) from the class page, it is really not a replacement for being in class, where I will be elaborating on content, providing both planned and spontaneous demonstrations, answering student questions, and sometimes providing other types of "bonus" information. If you are not present, then you will miss out on these things.
Lecture Notes:
My lectures are based off of my PowerPoint slides, which I make available on the course webpage, in PDF form. You are encouraged to print them out and bring them to class with you so that you can write your own notes from the material covered in class, as well as marking any parts you deem especially important. In addition, you may wish to read the notes on your own, before class, to make note of any questions or parts you did not understand. (NOTE: Because I occasionally make changes to my presentation slides, when necessary or helpful, you may find some differences between your printed version and what you see in class. If this is the case, just make a note of it and update, if needed.)
Code Demos:
Along with each lecture is a ZIP file, containing compressed Java code files corresponding to the topics discussed in class. In class, I will typically open, compile, and run these code files, using them to provide concrete illustrations of various concepts and topics. In addition, these code files will often contain nifty tips and tricks that you can use to accomplish various tasks in homeworks and projects.
In fact, when giving assignments, I will often be asking you to accomplish tasks of a similar nature to those done in demo code files. Therefore, it is in your best interest to consistently download and unzip these files to study the code -- ideally, before they are presented in class, so that you can come up with any questions or issues.
Another thing you may wish to do is experiment with the files. You can make edits (perhaps small edits, to start), save, and attempt to recompile and run again. Notice how your edits affect the program's behavior: whether it still compiles, whether it still runs without issue, whether it still gives correct results.
Textbook:
The textbook is another source of information that you may find helpful. As mentioned earlier, the materials I provide (lectures, code demos, etc.) are your primary source for information, in the context of the class. However, a textbook can be very useful to have, as a reference. First, the textbook will naturally present things differently than I will, so you may benefit from exposure to multiple explanations of a topic. In addition, it provides lots more examples and demonstrations in the form of code; in fact, you can download a ZIP file containing the textbook's source code. Moreover, it provides many practice exercises (of varying complexity) for all the topics we discuss in class. Finally, the textbook will cover additional topics beyond what we can reasonably cover in this class, so it can be helpful if you find yourself wanting to explore other topics beyond those we address in class.
Questions in Class:
As instructor, my goal is to present the material and write directions as clearly and understandably as possible -- based on what seems most logical and what has worked well in the past. However, I cannot always anticipate what may require more/better explanation, and I may (erroneously) assume something is so obvious as not to necessitate explicit mention. To this end, it is very important that you ask questions and seek clarification when you do not understand something. That way, you have a better chance of mastering the material, and I can also have a better idea of where people are at in understanding the material.
Google Group:
In additions to the questions that arise in class, sometimes they may arise outside of class with regard to a homework, a project, an upcoming exam, or something else. When these are questions that are not unique to you or your situation -- question that other students may conceivably have -- the Google group is a great place to post your question, for a number of reasons:
A student (who knows the answer) may see your message before I do, meaning you get a response much sooner.
Other students with the same question will get to see the response, eliminating the need for multiple students to ask the same question.
I can step in and offer further clarification and explanation, if beneficial or warranted.
It fosters a sense of "community" amongst students by encouraging interaction amongst yourselves.
Group Participation:
Sometimes, we will have group activities in class. Regrettably, there is never enough time to do this as much as would be ideal, but we will do what we can. By working together, you will be able to learn from one another, help each other improve, and capitalize more effectively upon your respective strengths. Besides, sometimes it is nice to take a break from lecture to converse with one another, even if only for a short while.
Grades and Work Quality:
The following table is not a guarantee of any particular grade for any student. Rather, it serves as a rough guide to the quality of work that would be typical of students passing the class with a particular grade.
A
Work is consistently completed and handed in, on time, in the form and manner specified in the directions.
Homework is submitted typed, printed, stapled, and single-sided, and it also includes all the required components, as stated in the homework assignment.
Projects are submitted on time, on the Linux system, in the specified folder location, with the required files. Files have the correct names and formats.
Code is neat and easy to read: well-formatted, good use of white space, properly indented, with meaningful variable and class names, observes Java conventions.
Code has no compiler errors, nor does it crash, stall, or infinitely loop when it runs.
Programs consistently give correct results and produce neat output for the input data given.
Student demonstrates superior understanding of the concepts and topics pertaining to the problem and applies them in the most sensible way.
For discussion questions, in homeworks and projects, student addresses them in a thoughtful and thorough manner.
On exams, student consistenly answers questions in a complete and correct manner, demonstrating superior understanding of the topics being evaluated.
Student appears to consistently and accurately understand all topics and concepts covered -- independently or with assistance.
When student meets setbacks, takes immediate action to remedy the situation.
B
Work is usually completed and handed in on time in the form and manner specified in the directions.
Homework is mostly submitted typed, printed, stapled, and single-sided, and it usually includes all the required components. Infrequent deviations from these requirements.
Projects are submitted on time, on the Linux system, in the specified folder location, with the required files. Files have the correct names and formats. Few, if any, delays or mistakes in this process.
Code is reasonably neat and sensible. Mostly follows standards of formatting and neatness. Occasionally presents minor flaws in presentation or minor difficulty understanding.
Code has no compiler errors, and it is very unlikely to crash, stall, or infinitely loop when it runs.
Programs consistently give correct results and produce acceptable output for the input data given.
Student demonstrates above average understanding of the concepts and topics pertaining to the problem and applies them well, for the most part. May infrequently misunderstand a concept or apply it in a less-than-desirable manner.
For discussion questions, in homeworks and projects, student addresses them in a reasonably thoughtful manner.
On exams, student usually answers questions in a complete and correct manner, demonstrating above average understanding of the topics being evaluated.
Student appears to accurately understand the overwhelming majority of topics and concepts covered.
Student is good about spotting problems or limitations in his/her performance and takes steps to address them. Shows obvious follow-through and improvement in this process.
C
Work is often completed and handed in minorly late, with occasional deviations from the directions.
Homework is occasionally typed, printed, stapled, and single-sided, and it usually includes some of the required components. Sometimes deviates from these requirements.
Projects are completed minorly late but possibly not turned in, in the correct manner. Not on the Linux system, in an incorrect folder location, with missing or incorrectly-named files. A number of delays or mistakes in this process.
Code could use much improvement in neatness and readability. Sometimes neglects standards of formatting and neatness. Occasionally presents flaws in presentation or moderate difficulty understanding.
Code has minor compiler errors, and/or it is at risk of crashing, stalling, or infinitely looping when it runs.
Programs, when they compile and run, give partially correct results and produce mediocre output for the input data given.
Student demonstrates average understanding of the concepts and topics pertaining to the problem but shows moderate limitations in the ability to apply them. May sometimes misunderstand a concept or apply it poorly.
For discussion questions, in homeworks and projects, student addresses them in a mediocre manner.
On exams, student answers questions in an occasionally incomplete and/or incorrect manner, demonstrating average understanding of the topics being evaluated.
Student appears to moderately but imperfectly understand the range of topics and concepts covered.
Student makes occasional efforts to remedy problems -- but may leave something to be desired in terms of follow-through and improvement.
D
Work is often completed and handed in late, with frequent deviations from the directions.
Homework is infrequently typed, printed, stapled, and single-sided, and it sometimes omits a few of the required components. Often deviates from these requirements.
Projects are completed moderately late and/or not submitted correctly. Considerable delays or mistakes in this process.
Code is often messy and difficult to read. Frequently neglects standards of formatting and neatness, and demonstrates considerable difficulty understanding.
Code has moderate compiler errors, and/or it is at risk of crashing, stalling, or infinitely looping when it runs.
Programs, when they compile and run, give minimally correct results and produce less-than-desirable output for the input data given.
Student demonstrates below average understanding of the concepts and topics pertaining to the problem with glaring limitations in the ability to apply them. Often misunderstands concept and/or applies them poorly.
For discussion questions, in homeworks and projects, student addresses them in a minimal and sub-standard manner.
On exams, student answers questions in an frequently incomplete and/or incorrect manner, demonstrating below average understanding of the topics being evaluated.
Student appears to fail to understand a considerable range of topics and concepts covered. May be related to failure to learn previous topics that currently serve as foundations for the present topic.
Student makes infrequent efforts to remedy problems and/or does not appear to follow-through or improve substantially.
F
Work is often completed and handed in late or not at all, with very frequent deviations from the directions.
When homework is turned in, it is likely to deviate substantially from the specifications in the directions.
Projects are completed very late (or not at all) and/or not submitted correctly. Considerable delays or mistakes in this process. (No obvious efforts to address obstacles in the project completion process.)
Code is very often messy and difficult to read. Pays no obvious consideration to formatting and neatness, and demonstrates a great amount of difficulty understanding.
Code has substantial compiler errors, and may make mistakes in syntax and semantics around issues covered early and/or frequently in the course. Program may also present huge risk of crashing, stalling, or infinitely looping if/when it runs.
Programs, when they compile and run, give incorrect results and produce messy, incorrect output for the input data given.
Student demonstrates little or no understanding of the concepts and topics pertaining to the problem with an extremely limited ability to apply them. May fail to understand/apply even basic concepts and procedures.
For discussion questions, in homeworks and projects, student neglects them or does not address them in a remotely meaningful manner.
On exams, student usually answers questions incompletely and correctly, demonstrating little or no understanding of the topics being evaluated.
Student fails to understand most topics and concepts covered. May be related to failure to learn previous topics that currently serve as foundations for the present topic.
Student makes few or no obvious and meaningful efforts to remedy problems and/or does not appear to follow-through or improve substantially.
Avoid Compiler Errors:
Recall that your programs can have at least three different types of errors: compiler, runtime, and logic. Of these three, the one most important to avoid is the first -- compiler errors -- for multiple reasons:
Compiler errors have a way of "cascading," in the sense that one error can actually trigger another, which can trigger yet another, and so forth. This creates a kind of "domino effect" and makes it that much harder to figure out where you initially went wrong.
To determine if your program logic is correct, you have to be able to run the program, which requires a runnable .class file, which in turn requires that your code can be compiled. In other words, if your code will not even compile, you will not have a way of determining if your program logic is correct!
Frequent compiler errors (where you are unable to immediately spot and correct the error) suggest that you are not understanding either (A) the basics of the Java language covered thus far or (B) how the parts of your program relate to one another. (Or both.)
Sometimes, you will likely need to come to office hours for help with an assignment or project. In such cases, you will get the most out of that time if we can focus on program logic and execution, rather than combing the code to spot compiler errors.
Fortunately, there are a number of things you can do to either avoid compiler errors entirely or make it easier to find and fix them, when they do arise:
While writing your code, consider saving and compiling frequently -- such as every line or two. What this will do is narrow down the possibilities for what created the error because it will, invariably, be related to the small amount of code you wrote since the last save-and-compile.
Alternately, if you have already written a lot of code, what you might try is commenting out all or most of the code, saving and compiling, uncommenting pieces of the code, and then saving/compiling again. This will accomplish something similar to the previous.
Use an IDE (such as Eclipse) that automatically checks for errors as you code and gives you error messages when you make a mistake.
I will say more about this below, but be very meticulous about syntax and semantics. Pay close attention to what you are taught about Java language grammar and data types. Be attentive to code examples given in class, and see what kinds of patterns and commonalities you notice from one example to another.
Memorize certain things, if you need to.
You could also create a personal reference sheet for yourself and update it frequently.
Syntax and Semantics:
Syntax: How you put together the different language elements (idenifiers, symbols, etc.) together in order to write your program Semantics: What the different parts mean (e.g., operation or data type)
In order to write programs that not only compile but also run and give correct results, you need to be very aware of -- and meticulous about -- the specificities of Java syntax and semantics. If you have no experience with programming, it may not even occur to you that certain details would matter, and you might not think about such things or even be tempted to ignore them. However, that would be a grave mistake because it will impede your learning and take a toll on your performance in the course. Instead, you should be mindful about things such as the following:
Often you will have code within pairs of symbols -- such as parentheses (), curly braces {}, and square brackets []. Here the important thing to remember is this: What is opened, must be closed. In other words, you will run into problems if you have an unclosed opener, an extra closer, or a pair closed in the wrong place. In general, it is good to type both the opener and the closer before typing whatever goes between them. This will help you avoid mistakes and remind you of the significance of that portion of the code.
Be conscientious about the type of each piece of data in your program -- whether it is a literal, a variable, an expression, the result of a method call, or whatever other form it may take. Is it a numeric type? If so, is it a whole-number type (byte, short, int, or long) or a decimal type (float or double)? If not, is it a char or boolean? Or...is it one of the many object types?
In addition to knowing what type your data is, you also want to be aware of how that type works. What operators can you use with it? Can you do arithmetic with it or not? (For example, note what happens when you do integer division, as opposed to decimal division.) Can you use it in string concatenation?
Know your operators. What type of operands do they take? How many operands? What type of value does the operator evaluate to? In complex expressions, what is the order of evaluation for different operators?
How Code Fits Together:
This is largely about learning how to "think like a computer," which is -- in many cases -- very different from how humans think. For example, you will want to think of a program as a structured set of steps executed in order to accomplish a particular goal. In many cases, those steps will consist of multiple "sub-steps", which may -- in turn -- consist of their own "sub-steps." (This is particularly so in the case of steps that entail the evaulation of complex expressions.) In addition, a program can also be thought of as a collection of components...that may operate more or less independently of one another. As such, those components can often be assembled in different ways to produce different programs.
Be Strategic:
The general idea here is expressed in the adage "An ounce of prevention is worth a pound of cure". In other words, I am encouraging you to work smarter so that you do not have to work harder:
Plan things out as we go along, rather than trying to do everything "on the fly".
Organize, organize, organize! For this class, I would recommend having, on your computer/flash drive, an IT114 (or CS114) folder. Within that, I would have subfolders for various purposes:
Homework
Projects (with subfolders for the individual projects)
Lecture notes, if you choose to download the PDF files
Code demos (with subfolders for each set of demo files)
Textbook code, if you choose to download it
Throughout the course, you will be shown various tips and tricks to make your life easier: in the code demo files, during classroom demonstrations, randomly pointed out in passing, etc. You will find it helpful, most likely, to take note of these things as they come up so that you can make use of them later, where appropriate.
Notice the image below. Its purpose is to illustrate how concepts covered in this class build upon one another. Assume that each square represents a concept we cover, and the numbers represent the order they are covered. If a square has lines drawn to squares below it, then that means that higher concept builds upon the ones below it. For example, consider concept #15 in the image; my explanation of #15 will be based upon earlier concepts #6, #7, and #8. #15, in turn, will be essential for understanding concept #21, and so forth.
As such, if you do not adequately learn concepts covered earlier in the semester, this will also give you major problems with subsequent material. Moreover, I will not be able to help you as much with something if you do not understand the previous material it is based upon. For this reason, you should take care to learn a concept or skill at the time we are covering it, rather than neglecting it. If you are having difficulty with a particular topic, then you should treat that difficulty as an urgent problem that needs to be solved now, rather than later.
Checklists:
Different assignments may have multiple and varied requirements and expectations. Some of these may be spelled out in a particular location in list form, but others may not. (This is to reflect real-world scenarios where specifications may not be spelled out as clearly as you would always like.) In this case, if you find it difficult to keep up with different aspects, you may find it helpful, upon beginning an assignment, to read through it from start to finish, writing your own checklist as you go along.
Furthermore, you may also wish to make more general checklists that you can reference as needed when doing your work. For example, for writing a Java class, you may want to make a list of things to check on (correct file name, matching class name, good code indentation and formatting, etc.). Or, for a statement, you might check and make sure that you have all the parts, of the right types, in the right order, etc.
Problem-Solving Mode:
Computer Science and Information Technology, like most technological and engineering fields, centers around one primary goal: Problem Solving. We will be doing plenty of that in this class. Though much of the class will involve the acquisition of facts and information, evaluation (for grading purposes) will usually require the application of that knowledge. To that end, given topic X, you will of course need to know it conceptually, but then there will be a deeper question:
Given what I know about X ... and given how I have seen X applied successfully in situations A, B, and C ... how can I now apply X to situation D? (Where situation D is similar to A, B, and C in some ways but also different from them in other ways.)
Imagine that this is a baking class, and I am teaching you how to write cake recipes. As the instructor, I would...
...teach you about the components: flour, sugar, butter, eggs, baking soda, baking powder, etc.
...explain how they work individually and in combination.
...show you multiple examples of how they are used successfully in other recipes.
After all that, your task would be to invent a cake recipe of your own -- one that would bake successfully and meet certain specifications. Your job would be to take what you have been given before (both general knowledge about the components and previous examples of their concrete applications) and apply them towards novel problems.
And, so it will be with our material in this class. As such, your best bet is to get yourself into a problem-solving mindset, which will entail a number of things:
Look over the directions and see what needs to be accomplished. This is one part where a checklist, as mentioned above, could be particularly helpful to you.
Examine what you are given to work with: Supplied code, concepts covered so far in class, previous examples of concrete applications (of those concepts), etc.
Determine what you do not yet have and need to locate or create.
Identify the parts of the problem that you understand well and can deal with easily. Develop some preliminary ideas about how you might approach those parts, while keeping in mind that you may need to change your approach.
Identify the parts that you find more challenging -- those parts that may require more time, more thought, or outside help.
Second Chances:
In many cases, throughout this class, you will have various opportunities to compensate for a less-than-desirable performance earlier in the semester. For example, the homework component may be set up so that you can do more than the required number (for example, 8) but only have the best 8 count towards that portion of your grade. Also, there may be an extra exam at the end of the semester that would allow you to make up for earlier deficits (grade-wise) in the semester.
For students who have a rough start but are able to improve and catch up, these are good opportunities to reduce (or even cancel out) any negative impact on your grade by the earlier performance. However, this only works if you accomplish sincere and meaningful improvements in (1) your understanding of the material and (2) the quality of your work. If you do make these improvements, then the opportunities will provide a good chance to bring up your grade. On the other hand, if you partake of the opportunties without providing higher quality work, it likely will not help you.
Personal Inventory:
As mentioned earlier, different people will experience different levels of comfort and ease with the material we are covering this semester. Some will pick it up quickly and easily, while others may require more time and effort to accomplish the same. At the same time, because people are so diverse, you may be able to leverage your individual qualities to your advantage in learning the material. To that end, consider asking yourself questions such as the following:
Where did I do the best in school? (For example, math/science vs. art/lit/humanities.)
What kind of thinker am I? Am I more inclined to think in words, pictures, or patterns? Do I tend to think inside or outside the box?
How do I learn best? Reading words on a page or listening to them spoken aloud? Stationary images or videos? Working on my own or with others?
Do I understand concepts and ideas more deductively (grasping the general, abstract idea before looking at the specific, concrete examples)... ...or inductively (seeing several specific examples before forming more general, conceptual ideas)?
Am I more of a morning person or a night person? What time of day do I do my best work?
Common Pitfalls:
There are a number of issues I see arising repeatedly among beginning programming students, and they do not necessary mean that anyone is at fault -- though we all have a responsibility to try to avoid them. I will list some of those here so that you can be aware of them and possibly recognize them before they happen. Titles should be taken figuratively, not literally:
Frosting the Cake with Cheez Whiz:
This one tends to cover cases where there is a substantial gap in understanding between the instructor's communication of requirements and the student's understanding of those requirements. To illustrate, imagine that you are hosting a social gathering, and you ask a guest to bring a cheesecake. And, you say no more because you presume that "cheesecake" is self-explanatory.
Meanwhile, you (the guest) leaves and starts to plan the dessert, but you are thinking "Cheese? On a cake? That's weird, but if that's what the host wants, so be it!" At the gathering, you show up and present your host with a chocolate layer cake...coated in Cheez Whiz!
To an extent, this is a standard hazard of all human communication: the message the sender intends versus the message receiver interprets. It can never be avoided entirely, but we can do our best. Just as I will strive for clarity in writing directions, you should always strive for clarity in understanding them. If anything seems unclear or weird, you can ask me, and I can clarify.
Painting the Yellow Block Green:
Imagine that a student has been given (1) a tray of colored blocks and (2) a sheet of paper with instructions. The directions read:
Place the purple block in the center.
Place the red block to the left of the purple block.
Place the blue block to the right of the purple block.
Place the green block on top of the purple block.
Place the yellow block on top of the green block.
The student look at the biggest grouping of blocks and get started. Everything goes fine until the fourth step, with the green block, which the student does not see among that grouping of blocks. All they see is the yellow block. So, they get up, go to the art supply store, buy some green paint and a paintbrush, go home, paint the yellow block green, and then place it on top of the purple block. However, they still have the fifth step to complete, but they no longer have a yellow block. Besides, the time is up, so the student has to submit the incomplete work. As the student soon finds out, there was already a green block on the tray in one of the corners, but they did not notice because they did not think to look there!
This analogy pertains to situations where a student ends up not finishing an assignment, spending too much time on one part, or doing much unnecessary work because of a failure to be observant and mindful. Just as the hypothetical student above could have avoided the extra work and finished on time by surveying the entire tray, you can often make your life easier and perform better by looking the entire problem over and being aware of the "forest", even when you are focusing on a single "tree".
Forgetting to Release the Parking Brake:
As you write your programs, you will see more and more how the different parts of a program are related to one another. Code near the end of the program may use a variable you wrote near the start. Code in one file make make use of a method or class defined elsewhere, in another file. A change made to code in one part of a program may fix (or break!) code written in another part.
This is a difficulty that many students run into. In the process of tweaking and improving your code, you may make some kind of change or addition at one point in your code -- without realizing that this modification will necessitate a corresponding modification elsewhere in the code. And, similar to starting a car and driving without remembering to release the parking brake, this can create problems.
For example, imagine that you declare a variable as type double, write more code that makes use of that variable, and then later decide to change the variable to type int. This could create any of the three types of errors: compiler (if you use the variable where its current type is incompatible), runtime (if changing the type creates a divide-by-zero situation), or logic (if it causes the program to output incorrect results).
Probably the best way to avoid this is to think of your program as a holistic, interdependent unit. You might often ask yourself, "Does this part of the program depend on any other part? Or, does any other part depend on it?" If you make a change, ask yourself if this change is going to require any other changes, elsewhere in the program. Also, when making a change, consider saving, recompiling, and running immediately to see if that most recent change has created any new issues. Again, it mostly boils down to being observant and mindful.
Sawing the Tree with a Butter Knife:
This refers mostly to situations where you end up creating much extra work for yourself and/or solving a problem in an inefficient or unnecessarily tedious manner. (Pretty much exactly like using a small, dull butter knife to saw a tree!) This, like many of the pitfalls, are to be expected when you first start learning to program. After all, you are given a set of tools (in the form of various coding constructs) and then told to use them to assemble some new thing that works in a specific manner. As such, given a specific task, you may (understandably) approach it in the best way that is obvious to you at the time. The more elegant solution may not occur to you.
To an extent, this is the kind of thing that you get better at, with time and experience. The more lines of code you write, the more you start to remember various tricks that can accomplish certain tasks. At the same time, I can offer at least a couple of tips. First, and this relates to previous points, try to think of any things you have seen earlier in the semester (lectures, textbook, demo code files, etc.) that seem like they might be relevant; ask yourself if you have seen a similar problem, and if so, would that other problem's solution apply here? Second, you might consider subjecting your solution to a "sanity check", in which you ask yourself, "Does this solution seem reasonable? Or is there possibly a much more reasonable solution that I just can't remember right now?" And, ask a question in class, on the Google group, or privately.
Cutting the Cake with a Chainsaw:
This is similar to the previous, in the sense that you may be creating unnecessary work for yourself, but the defining factor is that -- given the particular task in question -- the solution is just...too much. It is like using a chainsaw to cut a cake; it may get the job done, but it is way more beyond what is necessary and could potentially create other kinds of problems. It could include things such as:
Declaring an excessive number of variables, to the point that it makes the code less understandable.
Skipping too many lines, beyond what is necessary to make the code look neat and presentable.
Writing unnecessarily numerous or verbose comments, beyond what is actually helpful, to the point that it junks up the code.
In a program with a loop, creating a new Scanner object each time the loop code runs, when you could just create one -- before the loop starts.
Adding embellishments to code that do not actually accomplish anything useful.
Two caveats I should make here: First, this advice about avoiding excess should not deter you from following directions in an assignment; if you are instructed to solve a problem in a particular way, please be sure to do so, even if there may be a simpler solution. (For example, I may be asking you to do the more complex solution in order to practice a particular coding technique.) Second, in avoiding the mistake of doing too much, take care that you do not veer off into the other extreme, doing too little, which could result in a program that works incorrectly, does not meet requirements, etc. What you want is to get into the "Goldilocks zone" where your solution is "just right."
As with the previous, you will improve with time and experience because you will have a much better idea of what is available -- in the Java language -- for you to accomplish your goals. Just try to be aware of what you are doing and why, and often ask yourself, "Is this the best way available to me, right now, in terms of what we've learned so far? Or, is there a different, and better, way I should try?"
Have Fun!
This is important for two reasons. First, the topic -- no matter your level of interest -- will sometimes feel very dry and boring; as such, anything you can do to make the task more pleasant and enjoyable will give you a better experience in the moment. Second, there is the "positive reinforcement" (read more here) angle to consider. In short, that means that if a behavior is met with a reward (even a psychological reward), it is more likely to be repeated in the future. And so it is with your studies in programming. If you find ways to make studying more fun, amusing, and otherwise enjoyable, then you will have a greater motivation to study more. It is a way of training yourself to do better.
