It's harder to read code than write it

*bad code. Bad code is hard to read and relatively easy to write. Good code is enjoyable to read, and kinda hard to write that is it takes time to learn how to do it, but then its enjoyable.

It is an engineer's job to write readable and maintainable code. Write well documented and at times rightly abstracted code that helps you come back to the project or have another engineer have a look at it.

Let's say you write code in JavaScript.
Stop, and start using TypeScript instead. Strongly typed JS is very powerful, all my side projects are written in TypeScript because they self documenting in nature.

Write meaningful comments on complex logics.

Write up READMEs.

Use function names or variable names as a chance to document what you are building.
Instead of writing this:

const fooBar = 4.99;

Write this:

const thePriceOfTheMonthlySub = 4.99

Or instead of writing this:

if( someVar === someFetchedRes) return...

write this:

if ( isResponseTheSameAsLocalData(x, y) ) return

See how in this example we abstracted the compare into its own method with it's name literally spelling out what it does?

These patterns will help you with readability of your code.

Oh... and TESTS! write TESTS!

That is why I do not work at a company any more so that I skip trying to understand others' code. The problem might be one but there are always multiple ways of solving it and every programmer does it in his/her own way.

Reminds me of this excellent article here:
https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/
The writer points out that often it just seems that way because code can look messy, especially if it's had multiple bug fixes. The value in reading code is huge. Think of how much you learn from it. Writing off old code just to create new means you miss all that knowledge.

Imo: It's harder to read other people's code than write it

If P != NP, then it's the writing that has to be harder, in the optimal case.

If reading is harder than writing, then the writing was very poorly done.

@PavatiDasani Yes, it is right!

Its very hard to read others code that is the reason mostly people want to write their own code.

One thing that really helped me is that I started using the Github search.

I would write in the function that I was confused about and look at the different implementations of the code until something was appealing for me to understand and related to my problem.

"from rdkit import Chem"

There's enough examples of different code I could learn from to piece something together. I also got used to a lot of different styles.

One of the reasons is that there are less information about how to read code together with examples. Because it is not easy to learn how to read code, a lot of programmers avoid reading code. But reading code is a fun. Let's dive into it!

The hard to read code you mean is a consequence of spaghetti code. Splitting the code into smaller functions, and preferably without side effects, you will have less cognitive load. The code will be much easier to read and modify, closer to plain english.

I think, as other people have realized, this is too much of a generalization.

There are definitely cases where this is the opposite. For example, I have seen well written code in a language/framework I am not familiar with, but I was able to easily read and follow along. For me to write code in this language/framework would involve me constantly looking up language and framework reference/documentation, and even then I may not be doing it the most idiomatic way.

The "write" part, I would think would have to be talking about new, reasonably self-contained code. Otherwise, in order to write code within existing code, you have to read and understand the existing code first. Writing here involves reading so writing must be more difficult in these situations.

On this point about self-contained code above, I think a lot of the difficultly comes down to gaining context. When you right new code you build up context about the code yourself gradually as you write it. When you read an existing, extensive code base it can be daunting to even try to load all that context into your head.

This is a noob problem. Wait until you get thrown to customers labs and you got to solve problems on issues you never seen before, on code you never seen before, on technology you never worked on before. Do that 100 times and you've seen them all. If not, do it 200 times...

Disagree! I've found the opposite to be true.