Other Software > Developer's Corner
Is "easy" learning a valid (quality) experience?
CodeTRUCKER:
Is "easy" learning a valid (quality) experience? I had that thought challenge me when I read this post.
The statement, "... It's just so much faster and easier if you can see it done rather than having to figure it all out yourself..." just provoked a *ping* inside my mind somewhere and I began to think. Now, this is not a criticism of the poster. He is well respected for his contributions and he certainly is nobody's fool, so I am hesitant to criticize his comments. I know he is not suggesting anything resembling cheating. I do have some thoughts that apply to a broader spectrum.
My concern is that how common it would be for new (maybe old?) coders to just cut-and-paste from the resource and others, not bothering with the learning part. Human nature has cheated us all out of greater value. I have no power to do so, but I wish that every "new and improved" thing, technique and gizwort had an appropriate warning label to prevent beginners from choosing a pathway just because it is easier for the moment.
So, what do you think? Do the "new and improved" shortcut techniques of learning coding equate to the quality of programming that is produced from paying dues in the trenches?
Renegade:
This seems a bit like the old "buy vs. build" debate. (This is strongly related, though it does stray somewhat -- in any event, it's still in the same "thought mode".)
I'm solidly on the "buy" side of things. If I can purchase the functionality that I need (e.g. to cut down the time to market), then I will. I think that there are significant benefits to buying:
* You're likely not an expert in the subject -- Buying gets you an expert
* Time to market -- Much faster
* Resources can be used elsewhere
* Don't reinvent the wheel -- ok - not a benefit, but all the same...
The first there is what I think is the most important. Here's an example.
Imagine you're going to write a simple MP3 player. Well, in order to do that, you need to have an MP3 decoder to decode the encoded data in MP3 files (sorry about the verbosity there). Now, you *could* write one, but why? It is a non-trivial thing to do any kind of compression, and especially complex compression like MP3. The chances of you being able to actually create an MP3 encoder or decoder that even begins to approach the level of the Fraunhoffer or LAME (RareWarez) MP3 software is highly unlikely. There are many casualties there that attest to it, e.g. Xing and Blade. The only real solution is to use an existing MP3 codec.
The same thing goes for pretty much all encryption and all compression. Both those are extremely technical fields where the level of expertise required is simply massive.
Actually, I'd go so far to say that unless someone is an expert in the area of cryptography (or a mathematical savant), if they attempt to write cryptography software, they are not merely a complete fool, but completely irresponsible and totally wreckless. That can be extended to other areas in security as well.
Ok, well to sort of get somewhat back on topic...
I think the same principle applies to learning as well. If you repeat things long enough (copy & paste), eventually it's going to sink in.
A lot of things are merely matters of logic. Those you really need to be able to tackle with brain power. But a lot of things aren't a matter of logic at all; they're matters of knowing completely arbitrary rules.
For example, looping structures are all pretty much the same and follow the basic structure:
Loop
...do stuff...
End Loop
An exit condition is either at the top or bottom, and possibly in the 'between' part. There's no point to copying & pasting that. You need to know it flat out.
The same goes for conditional structures, e.g.:
If... then... elseif... else...
Or
switch... case 1, case 2... (or select case)
But things like opening a file or writing out an XML serialization are completely arbitrary with no predictable pattern. That is, they are always language specific, even if different languages are significantly similar.
Those things you really need guidance in using. A small set of rules won't help you in many cases.
Asynchronous calls are another area where you just have to roll with what you're given. Callbacks or events or delegates or whatever they're called... The ways to get them done differ significantly in different environments. The only thing you can really do is know when to use them and when not to use them. Doing networking? Well, you probably need to use non-blocking methods, or asynchronous calls.
Some concepts don't even exist in some languages, so you have to work your mind around the new way and come to terms with it. After that, you're good to go but you'll likely need to do some copy & paste along the way until it's familiar enough to just write it out.
Still... Yeah... I can totally see how blindly copying & pasting can be one of the worst things you can do. Understanding something doesn't mean being able to do it though. But if you can get that basic understanding about what things are for, then try to be responsible in copying & pasting, it seems like a good way to get things done.
While I rarely literally copy & paste, quite often what I'm doing is very much about the same thing. I look at an SDK or API, read the samples, then start coding/typing. But what I'm really doing is basically just copying. This is the ACME SDK, and they say I need to do X, Y and Z in order to achieve A, so... I'm sure anyone that's worked with different SDKs, APIs or frameworks knows what I mean.
Here are 3 lines from a piece of software I'm working on right now:
--- Code: C# ---ProcessStartInfo psi = new ProcessStartInfo();// openssl genrsa -out my-private-key.pem 1024psi.Arguments = string.Format("genrsa -out \"{0}\" 1024 -rand \"{1}\"", file, randomDataFile);
The second line I literally copied & pasted from some documentation in some other software of mine. That was copied and edited from other documentation. Sometimes there's only 1 way to do things, and you basically either retype it or copy it outright.
The third line is just retyping, editing, and adding in some extra things from the second line.
But this is starting to get very long... I'm going to leave it at that for the moment. (Decidedly incomplete.)
CodeTRUCKER:
This seems a bit like the old "buy vs. build" debate. (This is strongly related, though it does stray somewhat -- in any event, it's still in the same "thought mode".)
...
-Renegade (November 07, 2010, 12:54 AM)
--- End quote ---
Good argument, but wrong target. :)
What I am really shooting for is the validity of "Instant Breakfast" learning versus "paying the dues" of old-school methods. "Does the new methods produce the "right" results?" (I'll leave the definition of "right" to the reader.)
In the old days I remember when a function on the computer failed I was able to actually read the memory dumps and find the problem and guess what? I could fix it! Now days there is never time to fix a computer when something goes south. "Reboot!" is the dogmatic mantra.
I realize that trying to compare a couple of hundred punched cards in PL-1 with the 50 million lines of code (to say nothing of the fifty or so layers of dependency in the architecture) of Vista is ludicrous, but I knew what was really happening in those three hundred statements. Does anyone really know anything for sure about what is really happening in those 50M lines?
In 1964 "Fail-Safe" prophesied our present circumstance when Gordon Knapp explained to Sen. Raskob and Gen. Bogan...
"Look, it's just that the more complicated these electronic systems are... the more accident-prone they become."
So, here we are in 2010. The new has certainly produced quantity, but how does it stack up on quality? (Again, I'll leave the reader the chore of defining, "quality.")
Renegade:
You're absolutely right.
I would blame a lot of it on modern society and modern economics though. We simply don't have the time or money to be so leisurely with a lot of things. Made in China? Might as well stick that on just about every piece of software out there.
Well, not all. But enough.
For NASA and all that space shuttle code, it's nuts. They have like 50,000 lines of documentation for every line of code. When they say mission critical, they mean it. That stuff is so far beyond reproach that the only thing all of us out here in "the real world" can do is bleat "we're not worthy". But that's an entirely different world.
Back to economics...
It's simply too difficult now to truly run through all the nitty-gritty. If you're a full time programmer, and you are not a generalist, but you are a true specialist, then it's likely that you do have that luxury.
For most errors, god only knows what you'll dig up. It's often easier, cheaper, and faster to just work around a problem.
I've got a problem right now that I really should solve, but it's simply so bloody esoteric and I would have to go out and master an entire new skill set with new tools to solve it. There's no way I'm going to be able to do that. Food. Table. They win out. Would I like to be able to solve it? Sure. Will I attempt to? No way. I know that going down that path is a downward spiral into insanity. :)
The quote you have there is SOOOOOO on the money! The bigger the system, the bigger the problems. And the biggest problem I think is that no one (and I mean no ONE) can understand them. They're too big for one person now. So we all rely on each other. i.e. The chain is only as strong as the weakest link. Actually, that's a bit of a bad analogy, but it's kind of true.
Like you mentioned though, way back it WAS possible to understand the complete system. We just can't do it anymore. Which I why I think "buy is better than build", or "copy until you 'get' it." We can only dedicate so many resources to things. At some point we need to cop out and take the easy way so that we can make it to the destination.
Maybe I could sum it up as saying that there's simply such a vast QUANTITY of things to learn, that the QUALITY of a lot of learning must suffer for it.
mahesh2k:
Maybe slightly tangent reply to what you guys are discussing. One way to look at this is : code reuse. You can't waste your time inventing same things over and over in different way. We wasted a lot of time in development by making monopoly in what we do to give it feel of uniqueness and forgot about important points like - reuse, invent wheel argument etc. These days because of open source -software industry is improved as they reuse code. Now that you wish to re-use so you prefer to learn from blocks rather than from scratch. This approach works when you want to get things done but when you want to do particular thing in dedicated manner in that case 'easy' learning approach is similar to band-aid.
Navigation
[0] Message Index
[#] Next page
Go to full version