I find it frustrating how this article vacillates between "criticism" and "mean and/or unconstructive criticism". The article's thesis is that all public criticism is bad, but in supporting this, the author uses attacks that apply exclusively to unconstructive harsh criticism.
For example, while people may refer to a project as "their baby", the "calling someone's baby ugly" analogy stretches the metaphor to the breaking point. A baby's appearance is set and there was nothing the parents could do to affect it in the first place. Constructive criticism of a project, on the other hand, can serve to improve the project, as well as being instructive for anyone working on similar projects in the future.
Of course, the author then does say that "disagreeing" is OK as long as you do it tactfully. OK, fine. But that there's a word for that: "criticism".
Finally, we have this notion:
>Along this same idea, it is good to not talk about problems without offering up solutions. Doing this is called complaining.
Proposing solutions before discussing the problem is a cognitive antipattern (see http://lesswrong.com/lw/ka/hold_off_on_proposing_solutions/). If you try to solve a problem without carefully thinking about it and discussing it first, you will arrive at inferior solutions.
We should try to respect other people's feelings, but we cannot do so at the expense of progress.
At the same time, I think it's worth noting that a disturbing amount of the criticism made within the programming sphere is not aimed at solving a problem, but rather exposing the obvious wrongness of the original product and its author(s).
I fully support the idea of discussing a problem, but the key term here is discussion. Sitting around talking about how terrible component Foo is because it's obvious to even the most casual observer that it has not a single redeeming characteristic is strictly demonizing.
For me, it's all about the community. Recognize that every program we criticize almost certainly had someone pour a ton of effort and thought into it, and use that knowledge to temper your criticism. Make it a learning experience for the original author, and strengthen your team/organization while you're at it instead of tearing down people in the name of improving the project.
I completely agree. In particular, it's important to realize that it is possible to be mean and constructive at the same time, and that being constructive is not an excuse for being mean.
But to go so far in the other direction as to denounce all criticism is a huge error.
I didn't take away from the article a denouncement of all criticism. Perhaps I read into it what I believe, or was more charitable/liberal in interpreting/extrapolating the intended meaning from the clumsy wording.
Either way, my take away was that honest feedback and delivery/tone are orthogonal. You can be harsh in your feedback/criticism/expression-of-opinion, or you can do so in a way that disarms the other and is trust-building. The former is more likely to be ignored or misinterpreted, the latter is more likely to be understood. (The article presupposes this, and I agree. And one person's ability to take harsh criticism well does not translate to people receiving harsh criticism from that person also having the ability to take it well.)
If and only if you cannot find a way to convey your feedback in a trust-building way, the author asserts that your will be counter-productive in helping the other. Thus there are practical benefits to remaining silent, including: save your time/energy, not risk burning a bridge, not pointlessly inflict emotional harm (ok, the last one is not so practical as it is considerate).
But that's a very specific and unlikely circumstance, and the author explains in the article many simple techniques not to find yourself in such a circumstance.
We might be mincing words here. But, I think we are agreeing on the basic idea. In my article, I am attempting to say "don't be mean, be nice, and provide positive encouragement, if you disagree, be objective and gentle." I think you are saying the same thing as well, but we are getting hung up on the word "criticism." This is of course my fault, because I was the one who introduced it into the original post.
One powerful set of words I have found when I disagree with someone's viewpoint or find what I perceive to be a weakness in their work is to say.
"Hmm, I like what you said X and Y, but I keep feeling like we might be able to figure out a better way to do Z. What do you think?"
Acknowledging what was good and attributing it to the person, but suggesting an improvement to what was less than good and taking partial ownership for the solution.
That was almost exactly my thoughts after reading the article. Almost, because I didn't know much about the solution proposal part, that's what I learned today.
But I don't think the author didn't know these. I think he did, but was trying too hard to defend Microsoft. If you take a look at the blog, it's not hard to see that he's a Microsoft fanboy. I'm not saying that to launch an ad hominem attack, or to denounce him. We're all fanboys, and that's natural. But natural rarely means the best that can be. He's a great example.
I'm really glad that I read the comments on HN before writing something. Feels good to know there are still sane people on the earth.
Sorry, but my son was actually an ugly baby... at least for the first few weeks after birth. People who think their babies are always beautiful are the same empty people that demand that everyone be a winner, because they can't stand the objective evaluation that they may, in fact, be losers.
When I code, I always assume I'm wrong and missed something. Find a coder that thinks his new "baby" isn't ugly, and I'll show you an amateur that can't be trusted for production work.
My son was gorgeous. My brain might not have worked properly at that moment (temporary insanity), but he was the most beautiful thing I have ever seen. No matter how I look at it, even in retrospect.
Uh, the only people you trust to work on production code are those that think their work is "ugly" (which, in the context of the article, was a euphemism for harsh, one-sided, a-hole ripping condemnation)?
Oh, but you cited evidence. Assuming you trust yourself to work on production code, it's a universal truth that all trustworthy people must think they're spawn is ugly because you yourself were able to do that with your son. Congratulations?
We should embrace criticism. If it is valid, one learns. If not, one may clarify.
Saying somebody's baby is ugly is not criticism - it is simply useless. Attempting to compare proper criticism to it is even more useless.
This post to me is an antithesis to rationality.
Obviously, twitter is a medium more suitable for quick dismissals or approvals than a well-founded critique of a language. In such, I somewhat agree with the original poster. Nevertheless, to take an early 20th century sales coach's bastardization of good manners as our guideline for how to give criticism in the crafts seems a poor course to stake out for society.
This is patently absurd. The author fleshes out a rich and detailed argument for comparing/contrasting rather than one-sided criticism as a way to provide feedback, but your best refutation of it is to point at the one sentence in which he cited someone you feel is of dubious credibility and proclaim "Therefore he's dumb!"
Oh, but you said "proper" criticism. I get it now.
Well, when reading the text, the reference to Dale Carnegie's work - as well as the author's reflections on that - constitute the pivotal point of the chapter "Why criticism is bad". Without that, what is left except feelings and such?
He even repeats a claim that 99% of people one criticizes "will not see themselves to blame anyway."
That is not how we reached our modern science and academia.
Furthermore, he advises: "It is amazing how often it is you end up in a chair across from someone at a table interviewing you for a job you really need who happens to have worked on an open source project you publically condemned. Whoops."
If one's criticism is well-argued, this may in fact be the tipping point that secures the job. If the criticism was a one-liner on twitter, it may spark a dialogue that generates mutual respect.
My issue with the post is that it throws the baby - ugly or not - out with the bath water.
> This post to me is an antithesis to rationality.
That might be overstating it a bit, no? If you're trying to offer constructive criticism, at any rate.
I disagree, though -- the central point is that you should realistically imagine your critique from the POV of the creator receiving it.
Sure, people should be able to rationally evaluate any critique, no matter how harshly framed, and filter out a few useful bits from it. In reality, most people have egos that are rather more humanly fragile than that, and you should act accordingly.
This, to me, is the heart of rationality: recognizing the reality of the situation (including emotional/psychological factors at play among the actual humans involved!) and acting in that context will bring you far more effective results than if you assume people are as they should be (but aren't).
Criticism is healthy when it comes to company life. If someone's baby is ugly, it doesn't matter.. You see, your kid is not a product or service (I HOPE!!!!).
Calling someone's baby ugly is not constructive criticism. What can a parent do? Give his kid plastic surgery? And even if they could, why would they. They don't have to profit from their kid. Only on a happiness way, which doesn't mean their kid has to look good to make them feel good.
So, if your company gets criticism, it might be healthy to listen to it. If it's based on nothing, let it slide. If it's well constructed, think about it and try to improve (if it falls under the direction you'd still want to go). If someone plainly says, your product or service is going to fail, he's either right, OR, you'll have someone to prove wrong. But just saying it's crap doesn't help you. Why do you think it's crap? Why do you think I will fail? Maybe they'll give you valid points that you completely overlooked. It might save you a lot of time, stress and money. But don't give up if you believe otherwise. PROVE THEM WRONG. RUB IT IN THEIR FACES!
Honesty is good, let people speak their minds. Listen. Laugh about it, or do something with it. Giving someone critisism doesn't mean they don't like your baby. They might just have a really good point..
I don't know, I really hate all the vapid congratulations and "oh, that's great" and whatnot I get from friends, usually the older more polite ones. That seems to be the world this person wants.
These things do not tell me what's broken, what to work on next, etc.. There's a possibility they aren't just being nice and thing x they complimented is good and then in the big clue game of life I can search for something else to work on. Even then it isn't as good, though. Telling me about something that is broken results in no search, just me having to decide if it is worth the hours to fix/improve it.
I'm not thinking of flattery at all. I'm thinking of people too polite to say what they really think, and so what they do say is useless. He goes on and on about how hard it is to be critical and kind at the same time, the truth is, most people will just take the shortcut and just be kind. They are cutting things out and inserting meaningless pleasantries, not adding false compliments to get something.
Ok, and why do you think they are inserting meaningless pleasantries? Because they want something in return, even if it's more meaningless pleasantries. :)
>No one is going to hear you, until they know they have been heard
This is the key part I think. Everything else is just a matter of strategy or personality, and being blunt or socially awkward is less an issue than not to see the things from the perspective of the people who built it.
> It turns out that it is just not an effective way to convince anyone of anything or to change behavior. It is demonstrated in animals as well as in humans.
Citation needed? I mean, I just want to read the paper where criticizing animals was shown to:
> It can have a horribly diminishing effect of destroying someone’s self worth and stopping a person from believing in themselves.
Yeah, the author used some strong language. He obviously should have started off each sentence with "In my humble opinion".
"Effective" is a value word, so no study can prove it without first defining it (which would probably require 4 or 5 studies itself). However, I believe he's merely referring to cognitive dissonance, which can be briefly stated as the reason we tend to resolve mental stress by ignoring logic.
Also he said it "can" have a horribly diminishing effect. He might only have been claiming 1 in 10922. That's a pretty weak proposition, ergo there are dozens of studies that proved it. In my humble opinion.
The problem with developers is they have no idea what is ugly or not. That's why they wear so many geeky and trade polo shirts! Typescript is not ugly at all, and the majority of web application developers in my office liked the look of it. It is more the self proclaimed uber geeks who have a my way or the highway mentality. No hire.
M'eh. If everyone likes your language it's probably terrible.
When I finally took a look at TypeScript I was amazed at how inoffensive it is. It's nothing but an improvement. It might not be the best improvement imaginable, but JS in its entirety is still there. How do you get upset about this?
All of these blog posts about Typescript are a waste of space. All we've seen are visceral reactions and observations with toy problems.
If you try to use it for a real application, you see three things:
1) Typescript tries to change certain javascript idioms. For example, the first thing I do when writing a node module is the commonjs module interface, which is not what TS wants you to do. A common source of criticism is the fact that the typescript pattern doesnt match all of your idioms, which is fair but shouldn't be a reason to immediately throw it out
2) There are some places which break javascript. For example, parseInt(0.3) is an acceptable javascript call, and it is acceptable according to the spec, but typescript requires that a string be passed as the first argument. Again, it's nascent and hopefully those quirks will be fixed.
3) If you are even remotely professional about your development, the type hints have little value. You already keep a careful map of the code in your head, and you are careful not to make the mistakes that typescript would catch.
I would disagree with item 3. I am a professional developer. Not remotely professional, but flat-out professional. And I make mistakes. I know other developers, wait, greater than remotely professional developers, that also make mistakes. Even though I'm a professional developer and I've got a careful map of the code in my head, and I'm careful not to make mistakes, I still make mistakes. I've seen other developers do the same thing - make mistakes. I'm always stunned, but it keeps happening. I have found that type hints, code completion, intellisense, helps me discover mistakes sooner, often before I make them. I have found that mistakes found sooner are cheaper to fix. Type hints have huge value for productivity. Often, BTW, you are using a class (or JS function, whatever) that you didn't write, so you don't necessarily have this careful map in your head, your trying to figure out what this beast is that you're using, and hints are extremely helpful there.
I think Typescript is great, from what I see so far. And it's not like Anders is trying to hijack JS. I see it as a development tool. If the next guy doesn't want to use TypeScript, fine, have at the JS, it's nice code that it produces.
There's a really interesting documentary about Edsger Dijkstra in which they looked back at his old notebooks. He wrote by hand, and when a correction was needed he'd tape a segment on top of it, and sometimes youd see stacks of these corrections. When all of the fragments were removed, the top version almost always was same as the original.
The point of the anecdote is that most professional developers I've met are incredibly disciplined and take time to understand the intricacies of what they are working with before starting. The types of mistakes that Typescript can catch stem either from carelessness (like mistyping) or memory loss (forgetting a function signature), but those can be obviated.
"I have found that type hints, code completion, intellisense, helps me discover mistakes sooner, often before I make them"
Code completion shields you from spelling mistakes. Intellisense saves you the need to remember the signature of various functions (most of which you should know anyway). Type hints help with nondescript names, but hopefully your variable names have the types implicitly embedded (e.g. 'count' or 'cnt' are almost always integer types)
I'm not saying most people don't suffer from these problems from time to time, but most professional developers I know are very careful and write good code the first time.
"Often, BTW, you are using a class (or JS function, whatever) that you didn't write"
Again, most APIs use sufficiently descriptive names that there should be little confusion. If there is ever a point where something is not clear from the outside, oftentimes there are issues on the inside that should be addressed (minimization notwithstanding).
I think Typescript misses the point. A high quality linter for javascript could pick up on most of the issues that TS picks up on. Furthermore, there are some quirks that break compatibility, which does to an extent suggest hijacking.
However, when working with good type inference (i.e. Haskell)... 1: it's possible to relax on the discipline a little; mental resources are limited (at least for me). 2: typed-based dispatch; refactoring based on static types; etc.
I think you're misremembering the documentary. It was Dijkstra himself reminiscing about a composer, whose scores had corrections taped over them. He was illustrating the difference in mindset by comparing Mozart to Beethoven.
Static types are attractive to me. I haven't tried Typescript for other reasons:
1) I use CoffeeScript for the concise code, which Typescript doesn't have. The trade is a lot of verbosity for static types - verbosity above the static type declarations.
2) I don't know much about Typescript's type inference system, especially how it will develop. Not well documented, no vision. (Clojure's vision is one that I would consider exemplar.)
3) Suppose there are cases where Typescript is more appropriate. I don't know whether it is easy to expose functions to normal Javascript (while retaining types). Typed subsets of a language have often been problematic to expose to untyped parts of a language when more powerful inferences are being used (e.g. Typed Racket doesn't play well with Racket Macros). Especially if you want to pass typed => untyped => typed.
4) There's a cost to learning a new language. There's an overhead to remember an additional language.
5) Chances are, someone else is going to try it. Someone who actually has a good use case. If I wait, maybe they will talk/blog about it, and I can make a more informed decision later.
I haven't been persuaded to try Typescript in a substantial piece of code. The blog posts, they don't really address the issues of concern to me. Not yet.
Unlike what the author has experienced, I haven't seen any universal hatred for typescript. Most opinions have been balanced and recognize it is the first iteration of the language. Especially from people who actually work with Javascript.
Interestingly, the .Net/MS community seems to be far less open to typescript. Perhaps that is where the author is coming from.
I tend to avoid complimenting or insulting ugly offspring. Instead, I note whether you can deduce their parentage from their physical characteristics and/or their demeanor. Parents tend to accept these comments as compliments.
To apply this analogy to software ... I just don't. I don't know the "parents" in most cases. I simply evaluate the software, look at whether it meets my needs, evaluate whether its shortcomings prevent me from using it. And if I don't like it I just move on. If you're looking for criticism and suggestions from me on your software, A) you're at least an acquaintance (or I've prepaid for your app) and B) you should be able to accept that criticism. I'm not in the habit of grabbing a random app and calling it ugly.
This article needs to differentiate between vapid criticism and constructive criticism. Constructive criticism always provides good, meaningful advice for how to fix potential issues, is not unnecessarily harsh, and is willing to work with opposing criticism. People disagreeing about how to fix something can be just as bad as disagreeing on whether its broken in the first place. Constructive criticism is healthy and does not usually destroy anyone's self-worth, unless they simply can't take criticism at all in which case they will never improve.
The kind of environment/attitude the author is proposing is not one that engenders excellence. The problem is not criticism, it's ad hominem attacks ("this programmer is obviously a moron" compared to "this is a stupid way to do this"). Criticism is a sine qua non for progress, and people who can't handle it have no place in an adult environment.
"Doing them a disservice" is by definition not kind, I think.
Note that the phrase isn't "you can never be too flattering."
This interpretation does make it a very vague instruction ("okay, so what's the 'kind' thing to say when someone shows me a project I think is poorly done?"), but it's pretty damned obvious to anyone but the most stubbornly obnoxious that the kindest thing is never "rip it to shreds with cutting sarcasm and mockery".
By extension: seeking the kindest way you can respond means thinking hard about what response will be most helpful and supportive of them. That might mean being supporting but giving them strong nudges towards working directly with potential customers... but regardless, it's about having a conversation that you can exit on friendly terms.
It's certainly possible to do even when you have important negative feedback to offer.
Best to be honest and direct with your feedback than worry about whether or not you are going to bruise the delicate ego of whomever you are giving the feedback to.
No that doesn't excuse being a dick but if I have the choice of getting honest but harsh criticism of something I've built versus somebody grinfucking me, I'll take the harsh criticism every single time.
Honesty comes first, definitely agree. I don't think that was ever questioned. What was questioned was delivery. Delivery is important because it overcomes the innate skepticism of many people (which can also have emotional and professional ramifications). Honesty and delivery are orthogonal concerns.
Also, the article is about giving feedback, not taking it. The fact that you prefer to take harsh/honest criticism rather than overly-friendly/dishonest feedback is irrelevant (and is also a false dichotomy). You appear to state this to refute any a need to be concerned with delivery at all; your personal preference doesn't change the reality for the rest of society.
So, regarding giving feedback, if your objective is to improve the recipient's chances of success, it behooves you to communicate your (honest) feedback in a way that reduces as much distrust as possible. Techniques for this are given in the article.
But again, I agree, honesty underpins all of this.
This is a pretty long-winded way of accusing people who don't like TypeScript of being big meanies. How about addressing the actual arguments and building a logical case for your position? Or is that not cool any more?
I actually like what I've seen of TypeScript so far, but a lot of the blog posts, both pro and con, seem like more fecal matter clogging up the intertubes.
My Baby != My Work, My Baby == My Family Member, surely?
Can't we have different standards for discussing the other guy's work and family?
We must respect the other fellow's religion, but only in the sense and to the extent that we respect his theory that his wife is beautiful and his children smart.
H. L. Mencken
For example, while people may refer to a project as "their baby", the "calling someone's baby ugly" analogy stretches the metaphor to the breaking point. A baby's appearance is set and there was nothing the parents could do to affect it in the first place. Constructive criticism of a project, on the other hand, can serve to improve the project, as well as being instructive for anyone working on similar projects in the future.
Of course, the author then does say that "disagreeing" is OK as long as you do it tactfully. OK, fine. But that there's a word for that: "criticism".
Finally, we have this notion:
>Along this same idea, it is good to not talk about problems without offering up solutions. Doing this is called complaining.
Proposing solutions before discussing the problem is a cognitive antipattern (see http://lesswrong.com/lw/ka/hold_off_on_proposing_solutions/). If you try to solve a problem without carefully thinking about it and discussing it first, you will arrive at inferior solutions.
We should try to respect other people's feelings, but we cannot do so at the expense of progress.