Dealing With Feedback

Try to dumb it down and help them understand why it wont work. All else fails, let them do it there way and , just be ready to correct when they discover your right... been down that road :)

> restrict the view of content in the "library" but allow users to find any content when they search for it.

Hard to say without more context however that sounds like really good feedback to me. Most libraries show only a few of their options everything else is viewed by search or category sorting.

My experience is that these types of things always boil down to breakdown in communication. Management clearly expects something different than the developer does. I would take one of the stakeholders that you are on good terms with aside, and explain that you need more information and reasoning for their thinking. Have them explain to you why they need it a certain way. Once you are on the same page, provide that person feedback with your thoughts as to why it would be better to do it differently, but at the same time, explain the fallout if they do implement it the way they want. Bottom line is to always provide management with choices, so they can make informed decisions. They need to know the risks and costs involved in each scenario, and then make the decision. That's their job. Your job is to provide them the insight into the situation, then execute on their decisions.

I'll be honest: I have quit jobs before because of this. If it turns out this situation keeps coming up, and you do your best to provide them the information they need to make informed decisions, and you repeatedly find that they do make the wrong calls over time, chances are you and they aren't a good fit. And there's nothing wrong with that. It's good to know yourself as a programmer, so that you can hopefully find a company that you work well with.

Best of luck! ~Mike

PS: I'm not advocating you pack your things and leave, I just wanted to illustrate my experiences. :)

Don't be scared to say I don't get what you mean. However, what they're asking for in this occasion isn't anything major. Content is in the database, it's just how much you choose to pull out to the front end.

Yeah. I didn't provide the full context of the situation but wanted to focus more on dealing with feedback that didn't have any ground to stand on really. It has happened quite a bit too. Just because someone said so.

I'll do my best to explain why andaybe find some research that says why it makes sense.

Thanks.

The second half of Design is a Job has great advice on feedback. It is mostly focused on working with external clients though I feel the lessons could be applied to many situations. It also discusses mitigating "bad" feedback in the first place.

One focus is explaining why your solution meets the goals of the project - ideally as you show the work to your client or supervisor.

e.g. "Our goals are a, b, c and I have achieved this by 1, 2, 3 etc".

The handover is very vital as if you don't have a chance to explain the thinking behind your work you haven't been able to communicate why you made those decisions.

It's also important to be open to being wrong, it is possible to overlook things. Through good communication you can each understand better where the other is coming from. In the end you both want the best solution to the problem/goal.