[ozim]

It is easier to write your own code than to understand someone’s else code.

It would be much better if we get more humble people who get down to work to understand why and how existing code or framework works instead of trying to work around it or simply throwing all away and writing their own code.

Thera are of course some exceptions - but those are like pro athletes - no you are not the one, learn existing code instead of making excuses about some edge cases you ran into so you have to rewrite all from scratch.

[hogrug]

It's a mixed bag.. If you spend much time in a poorly reviewed ecosystem then you are quickly taught that if you try to make things work in their broken crap you will lose a lot of time and have no code to demonstrate you were working at all.

If you always inject the same repair layer approach of your own crap then you ship more reliably and have your pleased client and your lock-in. The pleased client then has to decide if they should listen to a replacement who says you are insane but can't seem to ship anything.

[skydhash]

This view needs to be balanced. There's a lot of cases where the previous code didn't abstract the domain well, or the domain has changed (mostly at the application level). Fighting the ill-fitted abstraction is a real chore in this case and quickly lead to complex code.

I'm all for aggressive refactoring if it leads to something simpler.

[baobun]

It sounds like you are agreeing - that digging into the existing layers can be a good idea that is often neglected or resisted to a fault. That we should treat existing software less like black boxes.

There are caveats here too of course - forking every single thing and excessive NIH syndrome comes with their own costs and risks.