Not sure what everyone else thinks, but this question strikes me as a sub-set of the problem of code re-use. We're basically talking about code re-use via code samples online (re-using the ideas or possibly copy/pasting code).
Four questions you could ask:
1) Is the functionality core or non-core?
Some functionality is so core to the business and the product you're trying to build that it's essential that you have a strong guarantee that it will work correctly. One good way to get such a guarantee is to write the code yourself. That way you will understand it thoroughly and be able to verify that it works correctly. This will require strong knowledge of both the domain area and the coding tools/language. You can still get use out of tools and code samples, but those are for convenience, not something you should be relying on.
On the other hand, some functionality is less core. It is general to many other businesses or products and not specific to yours. This means that many businesses probably have had a similar need in the past, and have converged on a few or one optimal solution that covers all bases. In this case, it's better to harness the "wisdom of crowds" and use the solution that's already been given, rather than waste a lot of valuable time "re-inventing the wheel".
If you're doing some very particular, domain-specific and complex kind of string manipulation or comparison, perhaps you're better off modelling the problem using object-oriented and/or functional techniques, and producing string input/output at the endpoints, rather than using a regular expression.
2) Is the functionality cutting-edge or mature?
This is very similar to question 1. Basically, are you the first (or more likely, one of the first) developers to build this kind of thing? Or is this a problem that's been around for a long time, for which a mature solution has developed over time?
For example, the problem of adding or subtracting days from a date to get a new date is by no means new. At the same time, it's non-trivial to implement. There is enough nuance to the problem that it would take significant effort to solve. But because it's been a problem for so long, many mature solutions to the problem have emerged, embodied in libraries and code samples. It makes sense to re-use a mature solution to this problem, which takes into account all the nuances and gotchas, rather than go through all that problem solving on my own.
On the other hand if you're working in a scientific setting, perhaps trying to apply a new machine learning technique to a new kind of data-set, perhaps you need to be one of the early contributors to a general solution. Rather than (or in addition to) standing on the shoulders of others, you have to support others on your shoulders. Then you want to understand the whole thing very thoroughly, rather than rely on code samples. That understanding could take years of research to develop!
3) Is the feature time-critical or correctness-critical?
If, in your business scenario, it's more important that you just get the feature out quickly than with perfect correctness, then copy/pasting and using tools is the way to go. Even if there are bugs or maintainability in the future, you will (hopefully) still have a running, profit-generating business and address them as they occur.
Whereas if you spend so much time trying to get the product perfect and end up being unable to sustain enough of a pace as to get the business to a profitable level, then that extra effort ends up being a waste. You would have been better off going fast and making a few minor mistakes that can be fixed later.
On the flip-side, if you already have a solid, profitable business and what matter is correctness, then the extra time invested is a kind of insurance against bugs that could undermine the business. You want to invest the time and effort to understand the code well and write it yourself, thus protect the business.
4) Is the code at a level of abstraction that matters to you?
Some parts of the software you build are core and some parts are peripheral. Some things you need to know the details of practically by heart in order to do you job correctly, other things you only incidentally need to know of and you just learn what you need to implement them then move on.
For example, most developers don't know the internal construction of Git. I mean how the source-code of Git actually works. It's enough for them to know the command-line interface to Git, including not just the commands, but what they do and how they work together.
But developers do (or should) know a lot about the internal construction of their own code, including the patterns and algorithms embedded in that code. For example, they should be able to identify a Factory pattern in their own code and use it correctly, or identify a recursive function and use it correctly.
They should also probably have fairly in-depth knowledge of at least one or two layers beneath their working layer. For example, many web developers know a bit about how browsers render content and about the HTTP protocol.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Great question, Ben!
Not sure what everyone else thinks, but this question strikes me as a sub-set of the problem of code re-use. We're basically talking about code re-use via code samples online (re-using the ideas or possibly copy/pasting code).
Four questions you could ask:
1) Is the functionality core or non-core?
Some functionality is so core to the business and the product you're trying to build that it's essential that you have a strong guarantee that it will work correctly. One good way to get such a guarantee is to write the code yourself. That way you will understand it thoroughly and be able to verify that it works correctly. This will require strong knowledge of both the domain area and the coding tools/language. You can still get use out of tools and code samples, but those are for convenience, not something you should be relying on.
On the other hand, some functionality is less core. It is general to many other businesses or products and not specific to yours. This means that many businesses probably have had a similar need in the past, and have converged on a few or one optimal solution that covers all bases. In this case, it's better to harness the "wisdom of crowds" and use the solution that's already been given, rather than waste a lot of valuable time "re-inventing the wheel".
If you're doing some very particular, domain-specific and complex kind of string manipulation or comparison, perhaps you're better off modelling the problem using object-oriented and/or functional techniques, and producing string input/output at the endpoints, rather than using a regular expression.
2) Is the functionality cutting-edge or mature?
This is very similar to question 1. Basically, are you the first (or more likely, one of the first) developers to build this kind of thing? Or is this a problem that's been around for a long time, for which a mature solution has developed over time?
For example, the problem of adding or subtracting days from a date to get a new date is by no means new. At the same time, it's non-trivial to implement. There is enough nuance to the problem that it would take significant effort to solve. But because it's been a problem for so long, many mature solutions to the problem have emerged, embodied in libraries and code samples. It makes sense to re-use a mature solution to this problem, which takes into account all the nuances and gotchas, rather than go through all that problem solving on my own.
On the other hand if you're working in a scientific setting, perhaps trying to apply a new machine learning technique to a new kind of data-set, perhaps you need to be one of the early contributors to a general solution. Rather than (or in addition to) standing on the shoulders of others, you have to support others on your shoulders. Then you want to understand the whole thing very thoroughly, rather than rely on code samples. That understanding could take years of research to develop!
3) Is the feature time-critical or correctness-critical?
If, in your business scenario, it's more important that you just get the feature out quickly than with perfect correctness, then copy/pasting and using tools is the way to go. Even if there are bugs or maintainability in the future, you will (hopefully) still have a running, profit-generating business and address them as they occur.
Whereas if you spend so much time trying to get the product perfect and end up being unable to sustain enough of a pace as to get the business to a profitable level, then that extra effort ends up being a waste. You would have been better off going fast and making a few minor mistakes that can be fixed later.
On the flip-side, if you already have a solid, profitable business and what matter is correctness, then the extra time invested is a kind of insurance against bugs that could undermine the business. You want to invest the time and effort to understand the code well and write it yourself, thus protect the business.
4) Is the code at a level of abstraction that matters to you?
Some parts of the software you build are core and some parts are peripheral. Some things you need to know the details of practically by heart in order to do you job correctly, other things you only incidentally need to know of and you just learn what you need to implement them then move on.
For example, most developers don't know the internal construction of Git. I mean how the source-code of Git actually works. It's enough for them to know the command-line interface to Git, including not just the commands, but what they do and how they work together.
But developers do (or should) know a lot about the internal construction of their own code, including the patterns and algorithms embedded in that code. For example, they should be able to identify a Factory pattern in their own code and use it correctly, or identify a recursive function and use it correctly.
They should also probably have fairly in-depth knowledge of at least one or two layers beneath their working layer. For example, many web developers know a bit about how browsers render content and about the HTTP protocol.