With pre written programs available, needing just editing, should programmers also learn writing them from scratch?


I'm going to hedge my bets with "it depends on the library."

If it's something specific like a Twitter client library, then you probably don't need to know how to write a Twitter-specific client from scratch. What you probably should know how to do is write a client for XML or JSON REST APIs, write basic HTTP transport, etc.

When you're building an application, having a wide ecosystem of libraries you can piece together is a definite plus, and probably shows you've made a good choice of language/platform/framework.

OTOH, you need to understand what's going on "under the covers", because not every (any?) library is going to account for every edge- or corner-case you might encounter in your specific business domain. So writing a similar library "from scratch" (or using lower-level components like the language's stdlib) is a wothwhile excercise. If nothing else, it will make you a more competent and more capable developer.

Should you use your library instead of a well-tested, open-source library that's in production successfully elsewhere? Probably not.

But that doesn't reduce the value of knowing how that library was built.


You seem to believe that software developpement is a solved problem. It is not.

People in all businesses have a lot of reasons to be unsatisfied by existing technologies. New hardware and new markets are created every day. New solutions to old problems are found. There will always be a need for new softwares/librairies.

Beside, you never actually write anything "from scratch". You use compilers and standard libraries. You should instead ask your self if you'd rather programm in high level or "low level" languages, depending on want you want to achieve.


It doesn't hurt, and its value will depend on the specific stack in question, but overall? Not really.

In the framework case, except for purely academic purposes (or if you want to contribute to the framework's development), I'd say you don't need to learn to write them from scratch, but you should have a general understanding of language the framework is for. That's the whole point of a framework. On the other hand, I don't need to know the ins and outs of FCKEditor in order to add it to my website, and even do moderate customizations to it.

Now, does that mean people shouldn't understand that the return value of a LINQ query is very often an IEnumerable type (or what IEnumerable is)? It's always good to have some understanding of the underlying structure of the higher-level technology that you're using.

Did you ever do any coding with .Net stuff before version 3 and the introduction of Entity Framework and LINQ? Did you ever have to do the raw ADO.NET calls to connect to a database, run the raw SQL query, get the data and store it somewhere, and make sure to disconnect from the database? This stuff wasn't really that hard, per se, but it did take time and testing - time better spent on doing something with that data. It was tedious, it was error-prone, and everyone had to do it, usually multiple times per application. Why not create a utility that deals with all that for you?

That's where Entity Framework (and really, any ORM or similar system for any language) comes in, and before that, people often built model-like classes to handle the connection tasks itself. By automating that system, you can spend your time using the data, instead of debugging the act of getting the data (and getting it into a state that's usable in your system).

If you want to take the idea of "writing everything from scratch" to it's absurd, though logical and very real extreme, then let's just go back to programming with physical chips and logic gates. I can tell you from experience that doing so will give you a very good understanding of how computers work, and the importance of binary.

But why? Why should everyone have to spend their time putting logic gates together, when that's already been done countless times, and refined to the point close enough to perfection to be reliable on a regular basis, without having an intimate knowledge of the details?

This goes all the way up the stack, from the physical gates and switches, through the binary, the assembler, and up the stack into the C and similar-level languages, and all the way up into the .Net framework you use today.

Have a general understanding of some of the underlying systems, and it would probably be a good rule of thumb to understand more about the systems closer to "the surface" of your current technology (ie - jQuery makes a lot of syntax changes to JavaScript, so there's often a stark contrast between the person that has a solid understanding of JS and one who just uses jQuery; in this case, the understanding of the technology the next level down is a major boon, but knowledge of the systems that JavaScript depends on (the layout engines in browsers, the languages underlying them, etc) becomes increasingly unnecessary), but that understanding need not be expert-level. Technology is a huge field, even narrowed down to programming. It's impossible for any given individual to know everything about every piece of technology that their current one depends on.

Not the answer you're looking for? Browse other questions tagged or ask your own question.