views:

337

answers:

10

We don't teach children calculus first. We first teach them arithmetic, then algebra, then geometry, the analytical geometry, then finally calculus.

Why then, do we teach our computer scientists frameworks and IDE first. Some curriculum do force students to learn computer science fundamentals, but the vast majority of graduates that I see could not compose a framework of their own to save their lives.

Where then is the next generation of tool builders?

How can we promote the understanding necessary to create frameworks and development environments?

This is of course a generality. Not all education is lacking, but it seems to be the majority and it brings down the quality of our profession as a whole.

+3  A: 

Get rid of HR departments that require X years experience in Y. The universities are just tailoring their course to the HR department's requirements.

I employ graduates who can code in something (I really don't care what language) and who can learn.

Airsource Ltd
Definitely part of the problem.
dacracot
+3  A: 

I see your point, although I think the math analogy doesn't quite fit. You have to know basic arithmetic to be able to get anything done in any other math discipline.

When I began programming frameworks were mostly unheard of. If you wanted a binary tree, by God, you went and wrote one. In C or Assembler. That was basically it, so to get anything done at all you had to know a lot.

Today, Frameworks and IDEs and designers make it possible for "noobs" to create actually pretty brilliant things without knowing the first thing about how to build a framework, or a compiler, or manage memory allocation.

The real issue is, what about all the dingbats that think they are awesome, great programmers because they used Frontpage or Access? Managers have a hard time telling the difference between that kind of programmer and one that really knows software development as a discipline.

So, specifically, why is it that way? Because everyone wants a job and nobody hires programmers that know how to build a binary tree. They want programmers that know .Net or J2EE, etc.

Geoff
I worked for a company that had two development groups. One, called "core", built tools for the other group. That other group were the "code monkeys" that assembled core tools into functionality. What we found was the latter never performed. The core team did 90% of the assembly anyway.
dacracot
+3  A: 

I would argue that there is probably enough work out there for 9 to 5 programmers who can start at the framework level and go up from there. The truly good ones - mostly your program as a career and/or program as a hobby - are going to get the knowledge they may have missed in college over time anyway. You can't force everyone to be a wonderful programmer no matter what curriculum you teach. Inquisitive students are going to learn about the fundamentals whether its taught to them in class or entirely on their own.

cfeduke
True as far as it goes - the smart will learn anyway. But, it's difficult to learn DFAs or NFAs or LALR parsing "on the job" - and these are all things I've used "on the job".
Bevan
A: 

Learning the abstraction is easier than learning the details when it comes to programming. It's harder to teach someone to hand-code assembler to print "Hello World" than it is to have them throw together a form with a button on it that shows a "Hello World" message when the button is clicked.

You didn't know how to build the engine of a car before learning to drive, did you? Because it's not necessary in order to drive. In the same vein, you don't need to learn how a linked list or binary tree works in order to maintain a list of names and search them.

There will always be those who want to get under the hood and learn the "why" of things, but I don't think it's required to get things done.

Tim Sullivan
It is when things don't go as planned or a feature is not available that I worry about. The shallow knowledge developer has no where to turn.
dacracot
Yes they do, they turn to the deep thought developer. Not every guy on a team has to be brilliant. In fact, that's sometimes a bad thing. Every team needs Do-Bees.
A: 

I always screen applications by asking difficult questions that they could only answer if they understood how something really works. I think it is a real shame colleges and universities are teaching people framework based development but not focusing on core software principles. I agree that what matters more than anything is someone who understands how programming works and has the drive to learn anything they can about it.

j0rd4n
A: 

Most universities I know of have an introduction to computer programming course that teaches basic programming concepts. Unfortunately it is impossible to teach programming without actually writing code.

The problem is that some prefer to teach this course using some OO language such as JAVA or C# and so the students must use Visual Studio (or the Java equivalent). It is very hard to explain the basic concepts when the IDE forces you to work in a certain way.

I think that the first language students learn should be functional language such as C. This way you have less layers of abstraction between them and the basic CS concepts.

Dror Helper
We use some Java and I don't see how you could get any more simple than VIM editor and single .java code files. What you say isnt true for Java nevermind the fact it is OO. You simply don't use OO principles until later in the course(s).
Simucal
A: 

Agree with cfeduke.

I looked at the work for the same CS courses I did from 2 years previously, and they were way harder. 5 years previously, way way harder.

The CS bar is being lowered more and more, presumably because there are more and more jobs that don't require any working knowledge of any of the complicated CS subjects. There are huge numbers of jobs for people to just cut code.

Since traditionaly people who wanted to be programmers did CS courses as coding has gotten easier this is still the case.

What really needs to happen is for CS to not be a requirement for professional software development. Instead there needs to be another curriculam that focuses more on getting people out the door and cutting code.

This would leave CS to be that course for you next generation of tool builder.

SCdF
+3  A: 

I think the analogy is a bit off. A better analogy would be "We don't teach our kids to use calculators to add and subtract, why teach programmers to use an IDE to program?"

metanaito
+1  A: 

There are tool makers and tool breakers. And of course there are tools, but let's not go there.

If you have a good look at an automotive workshop, you will see a lot of funny little tools that you don't see on the shelves in hardware stores. Like the ones for pushing back brake caliper pistons. Or the clamps for compressing valve stems so you can get the collets out with one hand while talking to your mates about nailing the new secretary (instead of watching them fly across the room when the spring slips out from your screwdriver).

These were designed by mechanics. They're really effective, generally small and cheap, and totally incomprehensible until you seen them in action.

Most of the profound changes in automotive technology were bottom-up, but top-down is also needed. Individual mechanics can't make fundamental technology changes like the switch from cast iron to alloy heads. A new broom sweeps clean, an old broom knows the corners. You need both.

But I digress: the point is that the mechanics couldn't design these tools if they lacked fundamental skills and knowledge. My father built me an entire motorcycle from scrap iron when I was a kid. As an adult, because I lack his skills and knowledge and modes of thought, I can barely maintain the bike I bought from Honda, much less take to it with an oxy like Mr T in a creative frenzy.

With code, I am as my father was with steel. Donald Knuth is my constant companion, and when the wireless protocol for our GPS loggers needs to be implemented in .NET it's me they come to see. The widget monkeys wouldn't know where to start.

Peter Wone
+1  A: 

I think the problem is in fact the GUI paradigm in general.

Microsoft made using computers much easier, they popularized the Graphical User Interface. They brought this interface metaphor, (the desktop, the file) to the domain of programming as well and very effectively too with their Visual Basic tool.

But just as the GUI obscures what happens "under the hood" so does the IDE obscure the manipulation of bits and bytes. The question is, of course, risk to reward ratio - how much understanding do programmers lose in exchange for productivity?

A cursory look at "The Art of Computer Programming" might show why IDEs are useful; "The ultimate packing density is achieved when we have 1-bit items, because we can cram 64 of them into a single 64-bit word. Suppose, for example, that we want a table of all odd prime numbers less than 1024, so that we can easily decide the primality of a small integer. No problem; only eight 64-bit numbers are required:

p0 = 011101101101001100101101001001001100101100101001000101101101000000 p1 = . . ."

Programming is really hard, you can see how an IDE might help. :^)

jeremiah