Writing original code is laborious, extremely time consuming and in many scenarios unjustified (for majority of coders). It is not an excuse for ignorance but originality in coding isn't particularly productive (IMHO).
I do take time to understand the code I am using, but for most part spend finding the code (and libraries) I want to use even in the simplest cases. I've developed a habit to give credit in my code ... in fact I have an expansion ';c' on my mac for giving credit! :-)
I see a lot of very experienced programmers spend time writing and debugging even simple lines of code which are perhaps completely obvious to them. I think it is just that way coding is. It is perhaps very difficult to get it "First Time Right".
I guess its a balance between getting things to work vs. self-gratification.
Your comment mistakes the nature of your work. As a software developer you don’t get paid to provide code. You are paid to provide enhancements to business products. Changes to a product should be tested before they are shipped to the customer regardless of who makes them.
Avoiding writing original code is primarily an excuse to limit personal liability through diverting blame. Organizations that care about product quality would blame that developer/team for poor product quality regardless of who wrote the code.
One advantage of using open source libraries is that they are often more battle tested and cover edge cases you either didn't consider or have not encountered yet. The trade off is less time spent fixing bugs, but more time spent on maintenance (package upgrades for security vulnerabilities/features/bug fixes, updating your code for library API changes).
I have heard this excuse many times. Again, you are not paid to ship code. You are paid to ship product features.
Those open source libraries might be tested to exhaustion, but not in your application. Your application still needs to be tested either way. The presence of excess code does not eliminate defects but rather moves them to locations less obvious which means they are harder to find by the end user and just as costly to fix. That is the very nature of debt.
Regardless of who owns the code you or your team own the product.
Like you said, they aren't paid to ship code, they are paid to ship features. And those shipments usually have hard, arbitrary ship dates that does not reflect the time needed to code and test them. So in order to do your job of shipping features, at times you need to use pre-written and pre-tested code, because if not you'll fail to ship.
No matter how you look at it, someone wrote the code you use. Since you are heavily dependent on the fact that people write code for you and others to use freely, the end result is evidently more than simple self-gratification. The end result is things getting done.
I use TextExpander. I wanted to do some custom stuff and discovered this recently [federico-terzi/espanso: Cross-platform Text Expander written in Rust](https://github.com/federico-terzi/espanso)
I tried espanso a bit and it seemed to work pretty well and is customizable.
Keyboard (System Preferences -> Keyboard or Spotlight -> Keyboard) -> Text, add whatever expansions you want, though this wouldn't be able to automagically figure out the actual attribution; you'd have to type that in after whatever template you set up.
I am reminded of an old post (from HN I think) in similar vein that stuck on with me https://stackoverflow.com/questions/153234/how-deep-are-your...
I do take time to understand the code I am using, but for most part spend finding the code (and libraries) I want to use even in the simplest cases. I've developed a habit to give credit in my code ... in fact I have an expansion ';c' on my mac for giving credit! :-)
I see a lot of very experienced programmers spend time writing and debugging even simple lines of code which are perhaps completely obvious to them. I think it is just that way coding is. It is perhaps very difficult to get it "First Time Right".
I guess its a balance between getting things to work vs. self-gratification.