[scrapheap]

> I don’t care how smart or ahead you are, but hard work always beats talent.

Although you do need some talent or working hard will just be making problems for everyone else, and all management will hear about is you being the cause of problems rather than a solution to them.

> Be Open to all feedback

Actually I'd suggest people don't just accept all feedback - before taking any feedback on board review it and see how it holds up. There's a lot of people out there that will give negative feedback, not because it's true, but for other reasons (e.g. it makes them look better to an onlooker, it pushes blame for a failure away from their team and onto yours, they're just an a**ole).

[vettyvignesh]

>Actually I'd suggest people don't just accept all feedback

If you read the whole para :)

What I suggest: listen to everyone and everything, but internally filter what’s actionable versus what should be addressed. More importantly, after receiving feedback, thank the provider regardless of whether they were right or wrong. Then share recent instances where you made corrections based on their suggestions.

[scrapheap]

Which, to me, heavily implies that you should be taking all feedback as being valid with your best interests in mind. My point is that feedback isn't always valid and sometimes you need to reject it, as accepting it can also mean that you're also accepting something that you don't want (usually blame for someone else's mistake).

So for example, you get feedback from someone that your API to delete users was badly designed because a bug in their untested script called it on 100 high profile users accounts and it deleted them. You don't accept that feedback, you push back and ask why their script called an API to delete users for 100 users that they didn't want to delete - if you just accept the feedback without pushing back then they can legitimately say to their manager that you've admitted that the fault was with your API and not with their development practices.