It's very easy to couch constructive criticism in a few words of sincere praise/recognition of their work, and it generally results in them doing better work in the future. In fact, they'll be much more likely to listen to your criticism if you haven't immediately put them on the defensive. Once either side gets at all defensive, it's extremely difficult to have any kind meaningful conversation. If you always say "this is crap", then you're literally asking them to defend themselves.
If you haven't already, I would recommend reading "How to Win Friends and Influence People" by Dale Carnegie.
In an ideal world...
Justifying the statement "this is crap" with hard evidence as to why, and then congratulating the individual on what they might have done best is all you need to make good criticism. I don't see a need to get around the fact that their work is crap with flowery language.
What you're really saying is that you have the rewards system of a child. The application the author wrote is very simple and has no use - what kind of feedback is she looking for?
Additionally, phrases like "What you're really saying is that you have the rewards system of a child" are exactly what I'm talking about. That statement is intentionally worded as an attack, so I have to make a conscious effort to not get defensive. If you want an actual discussion about how rewards systems may change as people grow up, we can talk about that. That was an extremely ineffective way of starting the conversation, though.
A great deal of the criticism is not intended to make you a better coder, and it probably won't do so. It's intended to make the critic appear superior or at lest feel superior.
Yeah, I've done that. It's a bad habit to get into, and a hard one to get out of.
"There is always something that can be improved, and beating around the bush with flowery language doesn't really help to fix it."
"Great. Now tell me something I don't know."
Saying "I don't know" is often a defense mechanism. It saves you from having to know. If you don't know, and you wash your hands of it, whatever happens isn't really your fault is it? And you're not going to know either.
But if you say "I don't know, but" and try to figure it out, or find out more, etc. ... that does take guts. That is actually admitting you're fallible AND it gives you a chance to improve and get to know.
Those are the people you want to hire.
You need people who recognise their ignorance and do somethign about it. Not people who use their ignorance as an excuse.
I'll be leaving my job here in a few weeks for what I consider my dream gig. I expect to be criticized on nearly every project, because that makes me a better coder.
I'm not sure if it's just adapting to the environment or if I actually like the general cynicism. A pat on the back is nice, but I strongly believe in the "this is always shit" mantra of software dev. There is always something that can be improved, and beating around the bush with flowery language doesn't really help to fix it.
> but it’s pretty tough to come back from, “I don’t know” on your first interview question.
Argh, don't ever answer a question with just "I don't know". At least speak to how you would figure it out.