It’s the end of the Fall semester, and I am a little bummed. More on that later. For now, I will amuse myself by sharing with you, dear reader, the advice that my students are leaving to future students. Specifically, this came from an anonymous survey in my HCI class. The class was project oriented, 15 weeks on a mobile phone application. In the survey, I asked for “Advice to Future Students,” and the students were told that any responses would be shared.
I will be linking my 315 and 222 students here in the Fall.
The only advice that I can give. Any course taken by Dr Gestwicki is very immersive and practical. If you want to fully utilize his course, dont take any other course or atleast dont burden yourself with too many courses other than the required minimum. I personally felt that I had only used 10% of him this semester and still I found it very enjoyable and wonderful. So imagine how I would feel, if I had utilized him to the full. You can make a living out of any of his courses. Attend all of is meeting( I wouldnt say that as classes) and always dont hesitate to ask him any doubts, even if they are silly. Go and knock his office doors often :)
Tackle the bigger problems first, making about pages, and splash screens is trivial compared to the main functionality of your program.
Consider your scope very very carefully. Consider how you are going to meet that scope. Consider what you want to do and make sure you refine that as much as possible. If you have someone that’s taken software engineering before have them help you figure out a development process that will work for your team. Try and do everything you can to involve all the team members.
start your project eariler,
go to developer guide, if you have some problems with andorid coding
communicate your team more than once per week
My advice would be to always get your work done in a timely manner. This, of course, does not pertain to the specific class alone. Nobody likes the person that never does their work. Don’t be that person, is my advice.
Read your documents and any extra material that you think you may need or even peaks your interest. In this field its always good to stay up to date on the latest information as well as branching out and learning new languages, ideas, and methods for accomplishing a goal.
Also, get to know people a bit before you decide to work with them. Just because you are friends with someone doesn’t mean you know their work ethic or their abilities.
Read before start
A good group makes all the difference, and bigger isn’t always better. Having a good tight group of 4 or so people will keep you organized and agile.
Let me begin with an overarching caveat: when you take a class like this, the majority of your work – perhaps 90% or more – will be dealing with other people. You will pick your project, the difficulty level, and almost every aspect of how it should get done. Furthermore, everyone in a 300/500 level CS course should be able to write code and solve problems. Skill is not the problem. Getting people to do the work is.
Take the hiring phase of this course seriously, even though you may have little time/resources to do so. Once you’ve formed a team, get to know the PEOPLE on your team ASAP, not just WHAT they can supposedly do. Find out if they have a lot of other courses this semester. Find out if their other courses are difficult or easy. Find out whether they will consider this a blow-off class or not. If you find yourself among a team of slackers, leave the team or fire those people immediately. Otherwise, you will probably ruin what could have been a fantastic learning experience in this class.
Additionally, find out how your teammates think. This is especially important (in my experience) if your team includes students from other parts of the globe; not everyone thinks like you. The words ‘testing,’ ‘development,’ ‘design,’ etc. can mean slightly/very different things depending on your background. In fact, even if your team consists of just one nationality, your teammates’ past project experiences may foster inconsistent team-wide expectations. Create a terms list for your team ASAP defining project-related terminology. Make sure everyone is on the same page.
Lastly, make sure you adhere to the following three rules when it comes to working as part of a team:
1. Communicate early.
2. Communicate often.
3. See rules 1, 2, and 3.
The internet will lie to you, only incorporate those ideas and algorithms into your project that you understand.
It is best to address the problem of an unproductive team member early rather than late and to do this in as creative and friendly of a way as possible.
Satisfactory results are not always correct results. Test at the margins; the beginning and end of files, the extremes of input – large and small, and test your project with both an expert and a novice.