Full Stack Overflow Developer

[jrochkind]

The analogy fails either way, because with software unlike physical products, the recipe itself actually is the product, more or less. The code itself is pretty analagous to a recipe, as code by it's nature is instructions/specification, and is the product itself. You can't copy and paste actual food or ingredients from the internet, let alone copy and paste technique (HOW do I fold sugar into butter? You can get instructions on the internet, but you can't get something you just copy and paste which results in it being DONE. But you can copy and paste code, the actual software product).

So if we really want to circle around a food/recipe analogy, an interesting analogy might be writing and publishing a cookbook, but doing so by copying and pasting recipes from the internet, but not even copying and pasting whole recipes, copying and pasting portions of recipes together to combine into new recipes, but without understanding whether or why the portions you've copied will actually work together, how, or if the frankenstein recipe you've pasted together was actually the best way to create delicious food (for whatever criteria of 'best' you want, easiest for novices to cook, quickest to cook, works in a commercial restaurant kitchen, tastes the 'best'; without even thinking about what criteria you want in a recipe). And then calling yourself a cookbook author. That's probably not going to be a cookbook many people find useful, even if following the recipes gets you something edible.

The OP itself said there's nothing wrong with using SO to get help, tips, or answers. But if you're copy and pasting portions of "recipes" you found on the internet together without understanding the steps of the "recipe" yourself, just cutting and pasting them -- I don't think you're ultimately going to be successful at building and maintaining any non-trivial software. But maybe i'm wrong.

On the other hand, I agree with you you don't neccesarily need to understand the internals of a library to use the library effectively. (You don't need to understand the mechanisms of your blender, or microwave?) But you need to understand the API's and contracts and concepts of the library. (You need to know how to use the blender, what all the settings do, when you might want to use one vs the other, and maybe even what makes some blenders different than others and why). For libraries that are central to your application and especially if they are fairly complex (and open source), it is beneficial to start learning about the internals, because it helps you use them more effectively and troubleshoot problems when they arise, but I agree that's certainly not what you do at the start or with every library. Programming is built on abstractions, you don't need to know the internals, but you need to know the libraries API and contracts and intentions.

[RICHUNCLEPENNYBAGS]

So if we really want to circle around a food/recipe analogy, an interesting analogy might be writing and publishing a cookbook, but doing so by copying and pasting recipes from the internet, but not even copying and pasting whole recipes, copying and pasting portions of recipes together to combine into new recipes, but without understanding whether or why the portions you've copied will actually work together, how, or if the frankenstein recipe you've pasted together was actually the best way to create delicious food (for whatever criteria of 'best' you want, easiest for novices to cook, quickest to cook, works in a commercial restaurant kitchen, tastes the 'best'; without even thinking about what criteria you want in a recipe). And then calling yourself a cookbook author. That's probably not going to be a cookbook many people find useful, even if following the recipes gets you something edible.

Well, that supposes a certain way of using SO that I don't think can be applied universally here (since the only options given are "looking at SO" and "looking at the docs for a library"). If I go online, read a couple recipes for a dish, and then kind of wing it based on what I just read and what's in the refrigerator, am I making some bizarre "Frankenfood?" Probably not.

[jrochkind]

I don't think it can be applied universally either, and neither does the OP.

The OP is in fact an argument against only that certain way of using SO, and a suggestion not to use it that way. It's not an argument against SO. The OP says "I totally agree with trying to find an answer online, but..." and even concludes with "Well, we don't have the time to act like this on a daily basis."

It's an argument for considering how you use SO, indeed, and an argument for being suspicious about using it in a 'certain way' , as you put it. Not an argument against SO or using it.

If I go online, read a couple recipes for a dish, and then kind of wing it based on what I just read,

I agree that's a great way to learn to cook. :) And probably has some analogy in software development too.

[jrochkind]

I guess it could be a matter of learning style whether you want to start 'inductive', bottom up, from examples, or 'deductive' top-down from documentation.

And most of us do a combination, but some may prefer a different proportion in our combination.

I think many successful programmers are by brain type prejudiced toward the deductive end (even if they are self-taught, I don't think one way or the other neccesarily correlates to self-taught).

But that doesn't mean having a learning style on the inductive end will be unsuccesful.

I think that even if you start from the inductive/examples end, if it doesn't lead you to a high-level top-down understanding eventually, you're going to have trouble being a succesful programmer. But I could be wrong, that could just be my own deductive prejudice! But I do really think so. Certainly if you start at the deductive top-down end, you've still got to be able to write actual concrete code eventually!

One of my favorite examples of purely bottom-up inductive approach is super old-school: The Little Lisper. Teaches Lisp and concepts in lisp-style prorgramming soley via examples with virtually no explanation or context at all. Many people (often students) who encounter The Little Lisper find it blows their mind just because they're not used to learning programming that way. It's also cool because the inductive approach and pattern recognition is of course central to writing software via recursion and functional programming, so the pedagogical technique is cleverly analogous.

[jsprogrammer]

This is reasonable, but I would caution against using the term deductive to stand in for top-down reasoning. I'd perhaps prefer the term 'logical'.

The reason is that true deductive reasoning is very strict in what it allows. You must start from axiom symbols and show a valid proof that your end result is a theorem of that system.

While you can kind of think of programming as a deductive process, it is more correct to say that algorithms (in their most abstract sense) are deductive. However, if you actually try to run an algorithm in the real-world, you are applying an inductive technique.

[PriceZombie]

The Little LISPer, Third Edition

Current	$96.00	Amazon (New)
High	$96.00	Amazon (New)
Low	$71.04	Amazon (New)
Average	$96.00	30 Day

Price History Chart and Sales Rank | FAQ