April 20, 2007
Stephen Waits wrote:
> David B. Held wrote:
>>
>> compiler actually does.  The "Java Syndrome" helps students treat the 
> 
> Ahh, thanks for giving it a name.  I'll add that to our vocabulary here.
> 
> We've been seeing this get worse and worse in the past 5 years.  It's to the point now where entry-level candidates we interview, from some high-profile schools, cannot write a basic recursive function (factorial) or demonstrate any knowledge about pointers, memory, or anything to do with bits.

I have had similar problems interviewing new graduates who learned with Java rather than C++.  Fortunately, it's not universal.  One interviewee I remember was taught using Java but reasoned correctly about the C/C++ questions using their knowledge of architecture.  I've never had an interviewee do that before, even the ones who know C/C++.

> Basically, seems like the students aren't learning much about the machine any more.  Were they ever?  Or were us "old-timers" (I'm 35, not quite an old timer, but whatever) just so excited about the whole thing that we all spent way too much time learning stuff on our own?  (I also quit college so I could learn more

Well, I think it is less important what a student is taught than what they learn ;-)  But simple exposure to explicit memory management, stack-based vs. dynamic data, etc, makes a noticeable difference.  If nothing else, the average graduate taught with C, C++, or Pascal will have some basic concept of what it means for data to be on the stack vs. the heap.

> I fear for some of the guys coming through here, that some day they may find themselves inside a paper bag.

Same here.  However, if a field doesn't interest someone enough to inspire them to learn about it on their own time then they are probably in the wrong field.  If someone is pursuing CS for the money, they are in for a disappointment.


Sean
April 20, 2007
Stephen Waits wrote:
> Daniel Keep wrote:
>>
>> To be honest, I wouldn't know the most efficient way to return or pass
>> out a vector because I've never had any kind of grounding in the effects
>> of the various ways of doing it.  For instance: at what point does
>> passing by reference become faster than by value?
> 
> 10 second lesson on optimization:
> 
> * Memory access is slow.  Both reading and writing.  It's generally been that way for a long time, and appears to be staying that way.
> 
> * Optimize what is slowest.

Optimizers (within the compiler) put a weird spin on some of these however, because they take care of most fine-grained optimizations automatically.  I think these are good things to keep in mind, but they are subordinate to what you mention below:

> * Know what's slowest by profiling.
> 
> * The largest gains generally come from larger algorithmic changes.


Sean
April 20, 2007
Daniel Keep wrote:
> This is one thing I really lament about my uni education thus far.  Two
> topics that basically have *never* been covered in even minimal detail
> have been optimisation and debugging.

Most great programmers didn't learn programming from taking college courses. They learned it on their own. Programming has the nice characteristic that it is fairly straightforward to learn on your own.

Want to take advantage of what a university can offer? Taking the basic course in each of following will pay you lifelong dividends:

1) Calculus
2) Accounting
3) Physics
4) Chemistry
5) Statistics
6) Electronics
April 20, 2007
Stephen Waits wrote:
> Basically, seems like the students aren't learning much about the machine any more.  Were they ever?  Or were us "old-timers" (I'm 35, not quite an old timer, but whatever) just so excited about the whole thing that we all spent way too much time learning stuff on our own?  (I also quit college so I could learn more)

A guy in my dorm in college built a CPU board out of random logic (NAND, NOR gates) just for fun. Those are the kind of guys you want to hire!

I think it was Niven who wrote that a real scientist was one who'd fearlessly peer through the gates of hell if he thought he could learn something.

It isn't hard to tell the real engineers from the "just a job" folks in a job interview. The real engineers:

1) did weird projects in their spare time, just for fun, not for credit

2) regard getting a degree as incidental, and wind up leaving it forgotten in the bottom of a drawer

3) took the hard classes that weren't required

4) didn't duck the calculus classes

5) can enthusiastically describe their projects

6) can tell you how bright an LED can glow if you file down the housing a bit and stick it in liquid nitrogen

The charlatans:

1) did nothing that wasn't required

2) generally complain that their hard work goes unrecognized

3) are much more interested in the salary & benefits rather than what the work is

4) have difficulty describing just what their last project was and what their contribution to it was

5) complain about outsourcing or foreigners taking their jobs

6) never made beersicles from pouring beer into liquid nitrogen
April 20, 2007
On Fri, 20 Apr 2007 10:27:14 -0700, Stephen Waits wrote:

> Daniel Keep wrote:
>> 
>> To be honest, I wouldn't know the most efficient way to return or pass out a vector because I've never had any kind of grounding in the effects of the various ways of doing it.  For instance: at what point does passing by reference become faster than by value?
> 
> 10 second lesson on optimization:
> 
> * Memory access is slow.  Both reading and writing.  It's generally been that way for a long time, and appears to be staying that way.

'Slow' compared to Register access rather than Disk access <G>
In other words, try to use the data that is in registers rather than get it
(again) from RAM, and try to use registers as temporary/intermediate areas.

> * Optimize what is slowest.
> 
> * Know what's slowest by profiling.

A concentrate on slow functions that are used frequently rather those that
are rarely used. I've seen people spend way to much time on shaving off
milliseconds from a program's initialization section rather than deal with
other areas that are run thousands of times each time the application is
executed.

> * The largest gains generally come from larger algorithmic changes.

YES! Time spent working on getting the best algorithm is always going to pay dividends. Improving the efficiency of a bubble-sort for million-element array is probably a waste of time.

-- 
Derek Parnell
Melbourne, Australia
"Justice for David Hicks!"
skype: derek.j.parnell
April 20, 2007
Walter Bright wrote:
> It isn't hard to tell the real engineers from the "just a job" folks in a job interview. The real engineers:
> 
> 1) did weird projects in their spare time, just for fun, not for credit
> 2) regard getting a degree as incidental, and wind up leaving it forgotten in the bottom of a drawer
> 3) took the hard classes that weren't required
> 4) didn't duck the calculus classes
> 5) can enthusiastically describe their projects
> 6) can tell you how bright an LED can glow if you file down the housing a bit and stick it in liquid nitrogen
> 
> The charlatans:
> 
> 1) did nothing that wasn't required
> 2) generally complain that their hard work goes unrecognized
> 3) are much more interested in the salary & benefits rather than what the work is
> 4) have difficulty describing just what their last project was and what their contribution to it was
> 5) complain about outsourcing or foreigners taking their jobs
> 6) never made beersicles from pouring beer into liquid nitrogen

Nicely said.

This is basically what we go by too; except, maybe for the liquid nitrogen parts.  Sounds like somebody had some fun back in the day...  :)

--Steve
April 20, 2007
Derek Parnell wrote:
> On Fri, 20 Apr 2007 10:27:14 -0700, Stephen Waits wrote:
>>
>> * Know what's slowest by profiling.
> 
> A concentrate on slow functions that are used frequently rather those that
> are rarely used. I've seen people spend way to much time on shaving off
> milliseconds from a program's initialization section rather than deal with
> other areas that are run thousands of times each time the application is
> executed.

Yes, exactly what I meant; only said more eloquently.  There's only so much I can teach in 10 seconds!

--Steve
April 20, 2007
Stephen Waits wrote:
> This is basically what we go by too; except, maybe for the liquid nitrogen parts.  Sounds like somebody had some fun back in the day...  :)

There was making a flamethrower out of a lawnmower, too, and the time some friends discovered how a stereo could be used to shake the whole building, and lots of other stuff <g>.
April 20, 2007
Walter Bright Wrote:

> Stephen Waits wrote:
> > This is basically what we go by too; except, maybe for the liquid nitrogen parts.  Sounds like somebody had some fun back in the day...  :)
> 
> There was making a flamethrower out of a lawnmower, too, and the time some friends discovered how a stereo could be used to shake the whole building, and lots of other stuff <g>.

Yeah, I enjoyed playing with thermite, and would maim to get my hands on a huge roll of aerogel.  Apart from women, it's software and physics that interest me the most; and I'm not much for small talk.

: )
April 21, 2007
Walter Bright wrote:
> Daniel Keep wrote:
>> This is one thing I really lament about my uni education thus far.  Two
>> topics that basically have *never* been covered in even minimal detail
>> have been optimisation and debugging.
> 
> Most great programmers didn't learn programming from taking college courses. They learned it on their own. Programming has the nice characteristic that it is fairly straightforward to learn on your own.
> 
> Want to take advantage of what a university can offer? Taking the basic course in each of following will pay you lifelong dividends:
> 
> 1) Calculus
> 2) Accounting
> 3) Physics
> 4) Chemistry
> 5) Statistics
> 6) Electronics

I couldn't agree more. Software development is and always has been a craft(*) - part science, part art. Colleges have never been really good at teaching crafts -- no such thing as a "Bachelor of Crafts in Software Development" <g>

Personally, the best developers I've ever known (again, personally -- please note the next paragraph) have almost w/o exception been formally trained/educated for something else, and most of the CS majors went into management (but then again maybe they're truly the smart ones <g>).

That said, there are *alot* of super-smart CS students and graduates in this group, I gather. If it's truly what you love doing, a CS or related degree can only help because you get to goof-off for 4 years doing what you like and learning too <G>

(*) Alan Cooper ("The Father of Visual Basic") for the insight that Software Development is really more of a craft than a science.