Feedback can really suck. That’s not an understatement. It can really stop you in your tracks, making you feel bad about your hard work, but that’s a good thing.
Giving Feedback to Students
I’ve been dealing with feedback in a few ways this semester. Firstly, I’ve been having to hand it out in the course I’m tutoring, DECO1800 a first year web app project course, which can be pretty daunting. It’s awkward when students have put in loads of effort building some really cool things, just to have me come around and tell them it might be worth changing some things.
I gave out some pretty harsh feedback this week commenting on one groups style and their user experience flow and they mostly just stared at me in disbelief, and promptly suggested I didn’t quite understand their app.
You just aren’t experienced with using this, can I tell you how it’s meant to work?
I’m just playing the user, and I’m telling you how I felt about what I just experienced. One of the important concepts you need to pick up in your first year at university is accepting what others say and making meaningful changes based on this information. In successive courses you are required, to get those precious marks, to say how you are going to change things to meet these critiques.
I’m not trying to crap on your ideas or your layout, but listen to me as a user, and think about why I gave this feedback.
Because you can learn a lot from listening to people.
Getting It Back
Now to the receiving end. I have received a lot of feedback on work this year, from my final courses DECO2800/3800/3801. Working in groups while satisfying requirements is not easy, but feedback definitely simplifies the process.
Contribute all the Java
The course DECO2800 had me working in a small group of 4 towards a project being undertaken by 32 students, so about 8 functional teams. We work on a project together and collate our code in a private repository on Github. We used issue tracking to suggest changes or features and then finally commit code against those.
Regular critiques of code our team wrote and our checkpoints have been rough so far but are always helpful.
Without feedback, it can be hard to understand what you set out to do and if your meeting those requirements, if you have to judge your own work.
Thanks to our classmates telling us what we did wrong and how we could improve our contributions, the project is actually coming along quite well.
The University gives students the opportunity to liaise with real clients on an issue they want solved in DECO3800 and DECO3801. In comparison to other students, real world clients are much harsher when something isn’t what they asked for.
If you never get told you’re doing it wrong, how do you know you’re doing it right in the first place?
This blunt feedback is exactly what the development team typically needs. So often people are afraid of getting feedback because they’re worried about having done something wrong, but would you rather spend lots of time building the wrong thing?
These courses have taught me much about listening to what people have to say about my software, letting people test things out, and watching where the pain points are.
Feedback can suck, really bad, but without it we would all be using poorly designed software. Because of that I can only thank feedback for how amazing it is.