Why most programmers hate code that they don't write?
3 comments
"All companies that I worked, I never saw a programmer saying good things about someone else's code."
I think that this may have to do with the fact that reading code (even code that you yourself wrote a while ago) is harder than writing code. When you're writing code, you have an image fresh in your mind of what you want to create, but when you're reading code, you're struggling to build up a mental model of what that code does. And if, because of this, you perceive the other person's code as being harder to understand, it might bias you into thinking that it's bad code.
People who have a lot of programming experience become better at reading other peoples' code - it's a learnable skill, like sight-reading music.
I read a lot of other peoples' code, and I find code that's all over the spectrum: worse than mine, about the same as mine and better than mine (sometimes a lot better). I have co-workers who write sloppy code and other co-workers who write very clean code.
A programmer who has never seen code that they can say good things about is probably fairly inexperienced (hasn't read very much code in their life).
I think that this may have to do with the fact that reading code (even code that you yourself wrote a while ago) is harder than writing code. When you're writing code, you have an image fresh in your mind of what you want to create, but when you're reading code, you're struggling to build up a mental model of what that code does. And if, because of this, you perceive the other person's code as being harder to understand, it might bias you into thinking that it's bad code.
People who have a lot of programming experience become better at reading other peoples' code - it's a learnable skill, like sight-reading music.
I read a lot of other peoples' code, and I find code that's all over the spectrum: worse than mine, about the same as mine and better than mine (sometimes a lot better). I have co-workers who write sloppy code and other co-workers who write very clean code.
A programmer who has never seen code that they can say good things about is probably fairly inexperienced (hasn't read very much code in their life).
I really liked what you said and I agree in every level. But what do you do and/or what do you think when you start reading someone else's code to avoid this precocious judgment?
Because what I usually see is very quick reactions like in less than 5min of reading, people start complaining.
Because what I usually see is very quick reactions like in less than 5min of reading, people start complaining.
I think you hold off negative thoughts and make a list of what's good about the code first, and then write down your negative thoughts. The key question is, is there a good interface to it, if not, can one be built to wall around the bad code? Remember, often an overwhelming advantage in having bad code is, it's already written and it works.
See it as an opportunity, rather than a burden. Each line of existing code is a potential line of code you don't need to write, rather than a potential line of code you need to re-write.
On a broader scope, try to work to become an unnecessary employee in the company, rather than to become indispensable. The former attitude helps me try to see what's good about my colleagues because I'll need every strength the team has if I were to leave the company in good hands. I want the company's engineering team to stand on its own feet without my help so I can quit and feel good about the organisation I've contributed to.
On the other hand, being underpaid and wanting to become more indispensable so you get paid more will lead you to keep seeing your colleague's weaknesses.
(And the justification to be so "altruistic" and "loyal" is to have negotiated hard in the beginning in the first place so you're so well paid you want to do right by the company.)
See it as an opportunity, rather than a burden. Each line of existing code is a potential line of code you don't need to write, rather than a potential line of code you need to re-write.
On a broader scope, try to work to become an unnecessary employee in the company, rather than to become indispensable. The former attitude helps me try to see what's good about my colleagues because I'll need every strength the team has if I were to leave the company in good hands. I want the company's engineering team to stand on its own feet without my help so I can quit and feel good about the organisation I've contributed to.
On the other hand, being underpaid and wanting to become more indispensable so you get paid more will lead you to keep seeing your colleague's weaknesses.
(And the justification to be so "altruistic" and "loyal" is to have negotiated hard in the beginning in the first place so you're so well paid you want to do right by the company.)
Levels of experience vary all over the map. Orders of magnitude differences. When experienced people get called in to deal with problem code, it's most likely been written by someone with less experience. There is very often room for critical comments. Just statistics.
Yes, I agree with you. But I don't know If I was clear enough but I'm not talking about capabilities. I'm talking about the outcome code of time and other constraints.
Like: - Lack of staff - Short time to do tasks - Priority change - Unexpected problems
We can always blame that manager for most of these problemas but Is not simple as that in the real life. We cannot just say "I'll spend 3 days more on this task and make it perfect. It is not my fault that someone quit and we have a shortage on staff"
Like: - Lack of staff - Short time to do tasks - Priority change - Unexpected problems
We can always blame that manager for most of these problemas but Is not simple as that in the real life. We cannot just say "I'll spend 3 days more on this task and make it perfect. It is not my fault that someone quit and we have a shortage on staff"
And even between two very programmers with a lot of experience, I saw things like that happening.
Sometimes it even looks like some creativity difference instead of some real issue.
Sometimes it even looks like some creativity difference instead of some real issue.
There are multiple different psychological theories that might explain why we dislike code that we don't write. I do agree it is an interesting thing to think about.
Two that I can immediately think of are
1. Ikea Effect(1) - We place a higher value on things we create vs. things we didn't create
How it applies: We place more value on code we wrote compared to what others wrote.
2. Fundamental Attribution Error (2) - We tend to look at our own accomplishments as evidence of our own ability, and our failures as events caused by external influence. When it comes to others it's the reverse, we look at others accomplishments as the result of external events, and their failures as evidence of their internal lacking of ability
How this applies: Let's face it, if you're working as a software developer, you don't always have the time to write 100% perfect code (which is not an excuse to write bad code) but a reason why we often settle for "good enough" code. We probably accept this rationalization when reading our own code but are less lenient when reading others code. This then frames their judgment of the code in a negative light. "I hate this code because the developer took shortcuts/didn't do things the right way... " Even though we do the same.
3. Mere Exposure Effect (3) - We like things we're familiar with.
How it applies: Since we wrote our code, know how it works (most of the time right...) and what we were thinking when we wrote it, that familiarity is pleasurable vs code that we don't know how it works (yet), and have less of an idea of the mindset that the developer had when writing it.
Those are just a few... there are probably more theories you can apply to this problem but I do agree it's a real thing.
[1] https://en.wikipedia.org/wiki/IKEA_effect
[2] https://en.wikipedia.org/wiki/Fundamental_attribution_error
[3] https://en.wikipedia.org/wiki/Mere-exposure_effect
Two that I can immediately think of are
1. Ikea Effect(1) - We place a higher value on things we create vs. things we didn't create
How it applies: We place more value on code we wrote compared to what others wrote.
2. Fundamental Attribution Error (2) - We tend to look at our own accomplishments as evidence of our own ability, and our failures as events caused by external influence. When it comes to others it's the reverse, we look at others accomplishments as the result of external events, and their failures as evidence of their internal lacking of ability
How this applies: Let's face it, if you're working as a software developer, you don't always have the time to write 100% perfect code (which is not an excuse to write bad code) but a reason why we often settle for "good enough" code. We probably accept this rationalization when reading our own code but are less lenient when reading others code. This then frames their judgment of the code in a negative light. "I hate this code because the developer took shortcuts/didn't do things the right way... " Even though we do the same.
3. Mere Exposure Effect (3) - We like things we're familiar with.
How it applies: Since we wrote our code, know how it works (most of the time right...) and what we were thinking when we wrote it, that familiarity is pleasurable vs code that we don't know how it works (yet), and have less of an idea of the mindset that the developer had when writing it.
Those are just a few... there are probably more theories you can apply to this problem but I do agree it's a real thing.
[1] https://en.wikipedia.org/wiki/IKEA_effect
[2] https://en.wikipedia.org/wiki/Fundamental_attribution_error
[3] https://en.wikipedia.org/wiki/Mere-exposure_effect
I work as a Front End developer in Dublin and I was wondering the following:
- All companies that I worked, I never saw a programmer saying good things about someone else's code.
Since I realised this thing, I always look at someone else's code in a different way. I try not to thing of how bad the code actually is but I try to criticise architecture problems and things that might be optimised. Not the code itself.
What I say about not the code itself would be something like:
Trying to avoid to criticise micro optimisations and/or things that I know it is bad but I do it anyway for reasons that might be due to time constraints.
The thing is, It is very easy to criticise someone's code but it is very hard to at the same time have a great code quality AND meet all constraints to deliver that.
And the point is, at the end, someone will look and still think it is bad.
I would like to know your thoughts about this problem and how to address them in a better way.