I enjoy writing my own code more than I enjoy reading other people's code which is probably not right.
To understand other people's code, I have to put away my own thoughts of how things work and try understand the thinking model and mental model of the person solving the problem.
And if they're smarter than me, then I have an uphill battle.
I think experts get too deep into values that aren't practically valuable to businesses or me and as a result go into the deep end creating a manifestation of something they think is beautiful or elegant but for me is a mess I am now forced to understand, with reluctance.
They say that one person's trash is another person's treasure and I think it applies to code too.
One person's elegance at runtime is another person's unextendable mess that leads to slow velocity and developer morale.
They say code IS the documentation but I don't agree. I don't want to bounce between 50 tiny files to understand where the core part of your algorithm is and what I need to do to get the behaviour I need.
I think if you're reaching for advanced language features to solve the problem before better data modelling, that's a warning sign.
> I enjoy writing my own code more than I enjoy reading other people's code which is probably not right.
Right or wrong, I think this is true for most programmers. Would be interesting to understand why this is so. Probably related to the problem in the article: we're writing code that is too clever, so reading it takes too long or is too mentally taxing. If we could read code as fast as we read text, it would be less annoying.
Is code more dense than English? Why do I understand more overall from this blog post than I would if I studied the codebase of the CLR for hours and hours.
I think it's to do with mental models. If developers were on all the same page of understanding the underlying mental models, we could all understand eachother's code because we all understood the same underlying things.
Yes, I would say code is usually denser than English. But sometimes it's not. This unevenness is I think part of the problem. You breeze through some parts, and stop and think through some others. It's unnatural.
>I think experts get too deep into values that aren't practically valuable
This describes the majority of practices today. Individuals pushing their own values, selling it and hoping it sticks despite having zero evidence to back it up. Even most things 'proven' are fairly context-dependent.
The majority don't even bother making a simple cost-benefit analysis these days. As if any significant social change is just going to break even from moment one and staying 'we should do X because it will give us Y' is a good enough argument. It is crazy how casually some of them advocate for practices that won't break even in the span of a few years at best. That's a lifetime in the field of software development.
To understand other people's code, I have to put away my own thoughts of how things work and try understand the thinking model and mental model of the person solving the problem.
And if they're smarter than me, then I have an uphill battle.
I think experts get too deep into values that aren't practically valuable to businesses or me and as a result go into the deep end creating a manifestation of something they think is beautiful or elegant but for me is a mess I am now forced to understand, with reluctance.
They say that one person's trash is another person's treasure and I think it applies to code too.
One person's elegance at runtime is another person's unextendable mess that leads to slow velocity and developer morale.
They say code IS the documentation but I don't agree. I don't want to bounce between 50 tiny files to understand where the core part of your algorithm is and what I need to do to get the behaviour I need.
I think if you're reaching for advanced language features to solve the problem before better data modelling, that's a warning sign.