davidktw
Arch-Supremacy Member
- Joined
- Apr 15, 2010
- Messages
- 13,547
- Reaction score
- 1,299
What makes you think the new comer is good enough to even take over the “easy” existing code?
That is why documentation exists.
You are quoting something we all understand, but trust me I have seen fallacy over these statement all the time, that some code are so easy and so verbose at the same time end up doesn’t look easy to read at all.
The part that makes something easy is context.
I have shown you E=mc^2, it is so short and so easy to read. The context is where make it so difficult to understand.
What makes something easy to debug is to make the programmer understand the context first. But again, good codes are only readable, it has to be performant too.
There are a lot of times performant codes are not easy to read. Getting competent is also just as important in the engineering world. Don’t think easy is only about readability. Things are easy too when the person whom took over is competent
So while I may agree with your statement, I may also disagree with your statement because you are just steering to only half the picture.
In your words, if you need to implement the sorting algorithm in your program, i bet you will just be using bubble sort? Because it is so easy. You will skip over the quicksort completely because some parts of it are difficult to understand and difficult to write comparing to the bubble sort.
There isn’t always the case where there exist something readily available to you like having a “sort” function. I am not talking about reinventing the wheel, I am talking about a custom algorithm that fit your use case. Trust me competency and context wins over just mere readability. Readability alone has been so often a fallacy.
There is nothing in the Linux kernel source that is readable and hence easy. If you are maintaining it, you better be competent.
In the context of this thread, I am showing you a road to competency. If you just want to talk about readability and ease, you can start your own thread to demonstrate it. Things only get easy when a person gets better.
BTW the problem you quoted about having new programmer take over old code is a process problem, not an engineering problem. It should be resolve where how do you enable knowledge transfer, and how do you keep a team of developers that know the system where so that there is always ways knowledge transition from one set of developers to another set.
These knowledge can exist as frameworks, as a product, as components, as documentation and many things. The code doesn’t necessarily need to be simple, it can be necessarily cryptic when it is about performance, but it has to be well encapsulated and techniques well documented.
Last edited:
