5 ms·

If it's a joke "Ahah", if not it's just depressing. SO is a valuable resource to confront and understand concepts. Let's not encourage this copy/paste culture

agumonkey 11y ago
http://rm.rf http://rm.rf
asadlionpk 11y ago
Why not? If it gets the job done (probably faster too). I would even suggest that be realistic and allow copy/paste during interviews too!
- blueblob 11y ago
  I think it forgets to include a license for all of the snippets that you use.
  - jaflo 11y ago
    All StackOverflow "user contributions licensed under cc by-sa 3.0 with attribution required"
- joslin01 11y ago
  So that interviewers can gauge your ability on searching & referencing code examples from the web? Who's being realistic?
  - hobs 11y ago
    When I hired people for a very entry level position, this was 100% on the list of things you had to be able to do (use google effectively.) Its amazing how many people cant.
  - wanderingstan 11y ago
    Being able to search and use online code examples is a key skill in software development. The web has become the collective knowledge base for all of us.
  - thebouv 11y ago
    I've often told people that I'm just a good programmer, but a phenomenal Googler. Even in interviews. Being able to search and separate the wheat from the chaff is most definitely a skill. Unless you always want to be reinventing wheels.
    - micampe 11y ago
      Yeah but when you found the wheat you still need to know how to make bread.
      - NeutronBoy 11y ago
        You're not expected to invent the recipe for bread though - you're allowed to talk to people and find the best recipe, and if it's acceptable quality then you use that. EDIT: Unless your job is to invent a better bread recipe.
bikamonki 11y ago
The OS/SDK/Browser/Protocol/Firmware which you used to type this comment is a compiled copy/paste of a zillion lines of code, of which you probably typed none. If we encourage the DRY paradigm in the whole development cycle, copy/pasting a function is just a further reach of such paradigm. Now, if a programmer decides whether or not study and understand the pasted code has nothing to do with the quality of the final product. Furthermore, IDEs by design encourage copy/pasting to speed development, most offer functionality to store code snippets. In that sense SO is like a web extension of IDEs.
- jnardiello 11y ago
  > Now, if a programmer decides whether or not study and understand the pasted code has nothing to do with the quality of the final product. I deeply disagree with this and for such obvious reasons.
  - deleted 11y ago
    [deleted]
  - bikamonki 11y ago
    Why? A widely accepted answer(many points) is most likely correct/best practice/bug-free.
    - pavel_lishin 11y ago
      It may be bug-free, but it may not be the correct solution for the specific problem the programmer was trying to solve. It may also not do what is expected under different circumstances. It may be a hammer when you're looking for a screwdriver.
- OliverJones 11y ago
  This is like the car mechanic who goes to the used-parts dealer (the junkyard) and grabs the first part with the same size screw holes as the broken part.

agumonkey 11y ago

http://rm.rf http://rm.rf

asadlionpk 11y ago

Why not? If it gets the job done (probably faster too). I would even suggest that be realistic and allow copy/paste during interviews too!

blueblob 11y ago
I think it forgets to include a license for all of the snippets that you use.
- jaflo 11y ago
  All StackOverflow "user contributions licensed under cc by-sa 3.0 with attribution required"
joslin01 11y ago
So that interviewers can gauge your ability on searching & referencing code examples from the web? Who's being realistic?
- hobs 11y ago
  When I hired people for a very entry level position, this was 100% on the list of things you had to be able to do (use google effectively.) Its amazing how many people cant.
- wanderingstan 11y ago
  Being able to search and use online code examples is a key skill in software development. The web has become the collective knowledge base for all of us.
- thebouv 11y ago
  I've often told people that I'm just a good programmer, but a phenomenal Googler. Even in interviews. Being able to search and separate the wheat from the chaff is most definitely a skill. Unless you always want to be reinventing wheels.
  - micampe 11y ago
    Yeah but when you found the wheat you still need to know how to make bread.
    - NeutronBoy 11y ago
      You're not expected to invent the recipe for bread though - you're allowed to talk to people and find the best recipe, and if it's acceptable quality then you use that. EDIT: Unless your job is to invent a better bread recipe.

bikamonki 11y ago

The OS/SDK/Browser/Protocol/Firmware which you used to type this comment is a compiled copy/paste of a zillion lines of code, of which you probably typed none. If we encourage the DRY paradigm in the whole development cycle, copy/pasting a function is just a further reach of such paradigm. Now, if a programmer decides whether or not study and understand the pasted code has nothing to do with the quality of the final product. Furthermore, IDEs by design encourage copy/pasting to speed development, most offer functionality to store code snippets. In that sense SO is like a web extension of IDEs.

jnardiello 11y ago
> Now, if a programmer decides whether or not study and understand the pasted code has nothing to do with the quality of the final product. I deeply disagree with this and for such obvious reasons.
- deleted 11y ago
  [deleted]
- bikamonki 11y ago
  Why? A widely accepted answer(many points) is most likely correct/best practice/bug-free.
  - pavel_lishin 11y ago
    It may be bug-free, but it may not be the correct solution for the specific problem the programmer was trying to solve. It may also not do what is expected under different circumstances. It may be a hammer when you're looking for a screwdriver.
OliverJones 11y ago
This is like the car mechanic who goes to the used-parts dealer (the junkyard) and grabs the first part with the same size screw holes as the broken part.