Please never stop doing this. I get paid $$$++ to swoop in after people like you are done and whole teams grind to a halt productivity-wise because the codebase is so bad.
You are doing god's work, son. Thank you.
You are doing god's work, son. Thank you.
I'm going to go ahead and suggest that a tremendous number of encryption mistakes are made specifically because people copy-paste library invocations without understanding what they're invoking and why. When you just sling a chunk of code into a project without understanding what you're doing and why, the potential for bugs goes through the roof.
To the GP: Swizec has it, please don't stop.
For example, I have a friend who sometimes fixes bugs in compiled software running banking systems with no access to the original code and woefully out of date documentation. He gets paid some 300eur an hour in a country where the median developer salary is only about 30k eur per year (about 14eur/h)
Sure, that particular type of problem likely/hopefully isn't caused by copy-paste programming, but it is caused by the sort of endemic issues copy-paste programmers to produce.
Because of space constraints then, file names were limited to 8 characters (someone correct me) and lines of code has fixed lengths. That already made commenting a nightmare. I have 'reverse engineered' scripts that were written more than a decade before I was born. Most have outdated documentation, filenames are a mess to figure out, and over time there have been automated conversion tools that were used to update language versions.
As I said, most of these systems still run some core functionality of the bank, and the people who wrote them ain't there no more, so banks have to shell out lots of money to either fix and maintain these, or to figure out what's happening so they can move to newer systems.
A form of anecdote could be that because IBM still make some form of x64 flavour Mainframe OS indicates that large corporates still have code that's potentially double my age.
A competent programmer borrowing code would likely factor it in in a way that won't present maintenance burden later on, and first of all would know when borrowing is appropriate. An incompetent programmer may produce problematic code even regardless of whether it's borrowed or original.
(Though I'd agree that incompetent programmer borrowing chunks of code from different sources without thinking is ‘worse’ than same programmer just writing bad code by himself—more predictability in the latter case.)
In my case, I regularly see borrowed code in projects that I maintain. As long as it's contained in an isolated module, documented (unless it's short and obvious) and used appropriately, I don't see a problem.
Interestingly, front-end code I work on seems to suffer from much worse-quality borrowing—it's like Python people lose all their discipline once they turn to JavaScript.
Sure, you copy paste a line of code after inspecting it, and save yourself some half hour of time on a piece of code that is not core to the problem you're solving.
But I have never seen a programmer who says "I am in the business of getting shit done, so I copy paste code" to produce good code. Anecdotal evidence and whatnot, and my argument could be a bit of a strawman, but this is the sort of canary in a gold mine that I've found.
When a developer on my team says "I just want to get shit done", is when I start preparing for a lot of internal screaming down the line. Happens every single time. Every. Single. Time.
So no, while copy-pasting on its own is not the problem, it is a good symptom to look for.
> whole teams grind to a halt productivity-wise because the codebase is so bad
He's being insulting, sure, but that doesn't mean he's making an ad hominem argument.
I'm sort of in between "get shit done" and "fix other people's shit" in my work. Because I like to take pride in my work, and because I don't want to leave the full timers with yet more contractor mess, I take care to do my job as well as I can. And I prefer projects where I can be proud of everything I do.
But in the 'trenches' of unsexy work, where my ideals meet reality, neither I nor the full-timers always have the time, money, or expertise to do things right, and are sometimes even forced by management to just get it done.
And I don't always mind. I can be happy with the result because it serves its purpose, and I made both the managers and many customers happy, even though I cringe at the underlying mess we produced. I know it is likely to cause much more work down the road, and I would generally advise against 'ship first, refactor later', but I'm also okay with the idea that I provide work for specialists to fix my mess.
Can I call myself a 'programmer'? Or am I more of a 'code monkey'? Do 'real' programmers thumb their nose at my sometimes shoddy code?
I don't really care. I'm happy with my work, and with my solutions. My aim is to move towards being able to provide full, high-quality solutions, because that makes me happier. But it also makes me happy to creatively solve problems in a way that might be imperfect, or frowned upon by some.
The most important reason for me to provide good, solid, readable code is because I care about the full-timers I meet who don't enjoy fixing my mess, and because I don't want my client to get into trouble later. That's why. It's primarily (but not exclusively) because I work with humans and I don't want to abuse my 'privilege' as a contractor and (relatively) skilled communicator to give other people headaches and crying fits over having to fix my junk. I've seen that happen, and it sucks.
(sorry, not necessarily directing this at you specifically)