views:

1386

answers:

15

It is a seemingly taboo subject. I imagine I want people to tell me I have a bad idea or did something totally wrong... but no one ever does. Of course I am part of the same problem, a good friend of mine is really smart, reads tech blogs, and goes to conventions... but always seems to make things that are more complicated then they have to be.

Where is the constructive criticism in our industry or how do I tell someone I don't agree with them without coming across as a pompous know it all or just a dick?

+5  A: 

Don't insult their skill, just address the problems at hand and try to help where you can. In a workplace setting, talk to your boss if you believe a colleague is incapable of doing his job properly.

Cody Brocious
"talk to your boss if you believe a colleague is incapable of doing his job properly" - its hard on yourself to be snitch.
c0mrade
+25  A: 

If there is only one truth in programming, it is this:

EVERYONE is horrible at programming. Some are just marginally less horrible.

The only thing that stops people recognising this is hubris and pride.

TraumaPony
or you can rephrase that as "Everyone can get better at programming." :)
Gishu
i disagree... but this is close enough to a "poetic truth"!
DarenW
Can hardly agree. That's like saying "all carpenters are terrible, some are just less terrible than others".
John
__except__ __Jon__ __Skeet__
Stefano Borini
nice statement, but it answers not the question and is also not a practical advice for anything.
Chris
I diagree, that's just a coding equivalent of some sort of moral judgement like the Catholic notion of original sin. We are not all horrible at programming, but we all have strengths and weaknesses. That's not pride on my part, it's honesty. You are allowed to recognise your own acheivements and abilities for the positives they carry.
Unsliced
+13  A: 

The Dunning Kreuger effect makes the answer to this question much more subjective than you may think.

So I wouldn't worry about telling other people they are bad programmers. Instead try to focus on continually improving your own skills and abilities.

If you let your (good) results do the talking, other programmers will see this and most likely try to improve to your level.

Ash
My problem with this is that if you're splitting responsibility for a huge framework or codebase... even if your code is immaculate and tested for stability, none of that matters if another module/branch of the tree is diseased.
David
I know what you mean. I guess that if this is a common occurrence and appears unlikely to ever change, despite all of your efforts, maybe another finding company/project is the only answer.
Ash
The problem is of course, how can I improve my own skills and abilities without constructive criticism from others?
Andreas Magnusson
A: 

Teach them, to the best of your ability, to be better. Take what you've learnt from others an try and pass along this knowledge. You may end up learning something yourself.

Some people will be receptive to this approach, others won't. You can only try.

Lou
+2  A: 

Some people get defensive or are sensitive no matter how you approach them. It's really most satisfying, and probably most productive, to state technical criticism in a matter-of-fact way, and disregard peoples' hang-ups.

sledgebox
A: 

If you think you're good, you're almost certainly bad.

That's because our desire to keep a positive self-image makes it hard for us to hear criticism of that which we tie our self-worth to. If your self-worth is tied to being a good programmer, then that means you have just become resistant to learning your faults, and therefore will never become a better programmer. No matter what your native talent and ability, if you are compared with someone who is constantly improving, you will be left in the dust. But that person, in order to keep improving, has to remain aware of their shortfalls and therefore is unlikely to develop a big ego.

Furthermore the same tendency means that providing others with well-meaning advice is frequently going to cause them to get very upset. As a result you would be well-advised to not offer others advice unless you have good cause due to the setting (eg a formal code review) or past interactions to know that the advice is not going to cause problems.

That is an extremely condensed version of a meditation that I wrote some time ago on another site. If you wish to learn more about the basic problem I would suggest searching for material on cognitive dissonance. I first learned about it in a programming context from The Psychology of Computer Programming.

+3  A: 

Everyone before me has said it in one fashion or the other, but for me comes down to a constructive peer dialog, aka communication. It shouldn't/doesn't matter if the comments are from a senior or entry level person, the key is making sure everyone understands the problems being solved and the extent that one goes to solving the problem. What one programmer may initially see as a productive solution ends up being a rats nest because he didn't anticipate all the use cases that really needed to be applied and used by his target audience. For me, this is a sign of good developer if they can put themselves in the users shoes and create an experience that works for the user while at the same time creating something that has the flexiblity to be used in other fashions without having to go back to the drawing board and start all over again. I think Stackoverflow is a good example of this.

I have worked with what in my opinion is good programmers and bad programmers and the environment we work in is more free form and off the cuff development rather than working on long term projects. In the end success is described as something that the users actually use once its done and doesn't become an additional burden to his/her responsiblities. Constructive dialogs and taking an interest in the development of the solution creates a much better development experience for everyone. When this happens, I see more shared thought in what the solution has to accomplish prior to development rather than seeing someone run off on a tangent which in the end doesn't provide alot of value. Good developers are very comfortable in these conversations. Bad developers tend to get stuck on one of their ideas and go running off with development and forget about where they actually need to end up. This type of development adds unneeded cycles to our process and we do everything we can to avoid it.

Telling someone they have a bad idea after the fact doesn't help in the long run because nothing was really learned from the coding, only if he is given time to code it another way after the process fails in production is something learned. Where the real learning takes place is in the dialog that happens prior to the actual coding and the understanding of what the problem is. Catching a mistake after the fact is much more costly than having the dialog to prevent the mistake from happening.

I can only participate in a constructive dialog if I have been involved in the problem solving process with the developers. However, wanting to get involved and having time to get involved are two different realities of development and unfortunately more often than not, I see people not have the time/not make the time to do this communcation thingy.

Tim K
A: 

I you can't tell who the bad programmer is at your work, then you are.

Following that logic then if you can't tell who is the good programmer, then you are?? I don't know if it works the other way around.

Chris Pietschmann
+10  A: 

I beg to differ. We are NOT all horrible at programming.

Programming is a craft that is learnable and that can be done well. You need a lot of experience to do it well though. A computer science education helps in some ways but may make people write very complicated code. Being a hacker helps when you have to dig into the dirty stuff below the pretty APIs, but code from hackers can be frustrating to work on.

What helps IMHO is:

  • Code in the most careful way possible. Do not reference things you have not checked exist. Do not calculate with values you have been passed but not checked. Check any data you read from user-supplied files or databases. Bad programmers just won't care.
  • Get the structure right. For most applications, OOP is a useful way to structure your program. But you can also code well without OOP if you have the structure thought through. Bad programmers will try to convince you they'll do the structure later when they've built everything else.
  • Reuse code. Reuse code. Reuse code. As much as you can. Bad programmers will constantly waste time on coding inferior alternatives to well-established and proven system/framework/library functions.
  • Redundant storage of changing data. Surest sign and cardinal sin of a bad programmer. Whenever data is stored several times in the same application and that data changes, there will be inconsistent states of the buffers because some of them will be synchronized while others will not be because they were forgotten. (Way out if you absolutely have to: Follow the Model-view-controller pattern)
  • A good programmer learns from fellow programmers. A bad programmer gets irritated and won't learn.

Thorsten

EDIT: I find it interesting that this entry is consistently kept at the bottom of the page. While I have a certain understanding for masochist views of one's own profession, I'd be very upset if my physician or my bus driver said that "all bus drivers are awful at driving" or "all physicians are bad at their job." I'd leave the bus or hospital immediately. Why is it that programmers have such a bad view of their own profession?

Thorsten79
I'm guessing that you're not getting votes simply because you've not addressed the original question. For what it's worth, I agree that not everyone is horrible at programming. But in my experience all bus drivers *are* awful at driving ;-)
JV
A: 

I wouldn't tell someone he is a bad programmer. Soon enough, he will figure it out or won't be able to handle the pressure and the fast-changing world of programming and will end up either changing jobs, changing fields or moving into management.

As far as knowing if you are good or bad. Personally, I have been told that I am a good programmer but most of the time it comes from people that are "average", so the compliment doesn't weigh that much to me but if you are constantly being complimented by "experts" then you probably are good at some level.

Most of the time I think that I am good (ego) and then I see some code sample online written by someone much smarter than me and it makes me rethink my level of "goodness" (buzz kill) but best of all it pushes me to learn, improve and get better.

eibrahim
+2  A: 

How do I know if I’m a bad programmer? In my opinion, that question can be considered from two angles, subjective and objective. The subjective consideration invites comparison with others, with the idea of somehow bolstering our self-esteem.

“I’m better than Fred, but not as good as Joe.” I don’t believe this gets us anywhere.

Objectively, I think bad developers can be recognized by certain traits, which I summarize as: “Arrogance taken together with incompetence.” (I’m going to raise my hand at this point and cop to being guilty of doing this at times :) but I do try to guard against it.) Some signs and symptoms of bad programming:

You have delivered what someone asked for even though you know it isn’t what they actually need.

You prefer complexity over simplicity in a solution, when simplicity suffices, because the complex code will provide ‘job security’.

You think someone is stupid because they asked a question.

You think everyone who doesn’t know about (technical topic X) is an idiot.

You feel put-upon because a requirement has changed.

You have added pages and pages of patches to a program instead of re-thinking its design.

When users complain that your program is hard to use or confusing, you blame them for being too stupid.

You have delivered a perfect Magnum Opus, which is so fragile that it shatters the first time you have to make a change.

When someone shows you a better method, you feel angry and threatened.

As far as telling someone I think they’re a bad programmer, I wouldn’t. However, I do feel free to state my disagreements over technical issues, and I would provide my best support for my opinions. I don’t expect to get my way all the time. If someone is really not very good, that fact comes out on its own. I just try to make sure my own work is as good as I can make it under the prevailing conditions and make an effort to keep learning to improve.

+2  A: 

You are a bad programmer if:

  • You think you are a good programmer who already knows everything you should know.
  • You think you are a good programmer who doesn't need to improve yourself.
Svish
+1  A: 

It's more difficult to tell good from bad than you think. Of course, there are some versions of bad that are so obviously horrible that most people immediately recognize them. But in many areas, it's not that easy.

For example, consider a method that takes some parameters. One programmer writes many checks just to make sure that all parameters are correct. Eventually, 75% of the method's code is parameter checking. Another programmer omits (most or all of) the checks and only writes the code that does what the methods name says. Who is the better programmer? Some people say it's the first one, because doing all the checks is a sign of foresight and attention to the detail. Other people will tell you that the second programmer's version is faster and more readable, because it does the simplest thing that could possibly work, while the first programmer's version is cluttered with useless checks. I think there is no universal answer to that question, it depends on a lot of things.

ammoQ
A: 

Don’t tell someone they’re a bad programmer. Tell them how a specific piece of code they’ve written could be made better, and explain how their life will be easier as a result.

That’s still incredibly hard to do (as noted above, we get really emotionally attached to our code), but it keeps the conversation on topic and sounds slightly less like a personal insult.

It’s also really important to listen to what they say about their code. Maybe they’ve written it that way for a really good reason that you just haven’t spotted.

Paul D. Waite
+2  A: 

People need to get over being wrong. But, on a personal level, it's not generally their direct actions that cause this feeling.

Sadly, most societies don't handle "wrongness" well. Even this site is a classic example; where posters are downvoted for wrongness, and this affects their rating, which affects their sense of self worth (and public opinion of them), and pride. It follows that people can't even "risk" being wrong, lest they be downvoted.

This is not only true here; it's true in life more generally. If someone sees you as being wrong, their trust in you (whether they do it on purpose or not) goes down.

What I'm getting at is that change comes from within. You need to stop being afraid of being wrong. You need to actively try and accept people as being wrong, and still trust them (to a sensible degree). You need to be more accepting of peoples mistakes, and let people try things out, and fail, and learn, and continue to do so.

You want to tell someone they are wrong? Tell them.

me: Hey, Joe, that's wrong. Here's why: A, B, C.

Then you pass the same advice on to Joe. Hopefully Joe will pass it on; with any luck Joe will do it back to you one day:

Joe: Silky, you crazy lunatic, you totally got that wrong ...

And just be friendly with people, in general.

I don't think any reasonable person can be upset about accurate advice or comments that are presented in a friendly manner; and if you also do it this way, and still treat the person with respect, and let the same happen with you, I think it can only make for a better system in general.

Personally, this is the advice I adopt globally. I'll be honest; sometimes there are people that get mad at me for it; but bad luck. I do the same with everyone, and I'd expect nothing less done to me. We all benefit.

Noon Silk