
Why most programmers hate code that they don't write? - grillorafael
Hi!<p>I work as a Front End developer in Dublin and I was wondering the following:<p>- All companies that I worked, I never saw a programmer saying good things about someone else&#x27;s code.<p>Since I realised this thing, I always look at someone else&#x27;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.<p>What I say about not the code itself would be something like:<p>Trying to avoid to criticise micro optimisations and&#x2F;or things that I know it is bad but I do it anyway for reasons that might be due to time constraints.<p>The thing is, It is very easy to criticise someone&#x27;s code but it is very hard to at the same time have a great code quality AND meet all constraints to deliver that.<p>And the point is, at the end, someone will look and still think it is bad.<p>I would like to know your thoughts about this problem and how to address them in a better way.
======
greenyoda
_" 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).

~~~
grillorafael
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.

~~~
meric
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.)

------
JoeAltmaier
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.

~~~
grillorafael
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"

------
askRich
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](https://en.wikipedia.org/wiki/IKEA_effect)

[2]
[https://en.wikipedia.org/wiki/Fundamental_attribution_error](https://en.wikipedia.org/wiki/Fundamental_attribution_error)

[3] [https://en.wikipedia.org/wiki/Mere-
exposure_effect](https://en.wikipedia.org/wiki/Mere-exposure_effect)

