About | ACP | Buy | Industry Watch | Learning Curve | News | Products | Search | Substack
Home » Learning Curve » Red Hat Diaries


Those with no traction are slipping again.

Get It

Try It

Technically Sound's been having fun with the mall rats. It seems the perennial failures are complaining again - and passing the blame. [The only thing they ever pass.]

And TS's worried because his esteemed IT department will soon make him take a course in Vee Bee Net. And you have to feel for him.

The story's the same as always: teachers are no good, Java is great, no it isn't great, shit we still can't write a fucking real program boo hoo. Good thing we got so much time to hang out here at Slashdot.

Some of the posters - who obviously didn't spend the afternoon optimising their RSS readers and reading every post in the thread - actually say some interesting things. Lucidly and succinctly. After which they're no doubt back at work again.

Computer science education in the US sure is in a lot of trouble judging from this crew.

What a bunch of wimps. Some of the stuff they write is so nauseating and pretentious it should not be quoted no matter the demand.

A while back a banking officer came to us with a request. He was going to switch horses midstream and take on managing a software development project. What book should I read? he asked.

This one, we told him.

That's an old book, he pointed out.

Yes but it helps you learn the two things you need to learn to manage software projects, we told him.

What are those? he asked.

You'll see, we told him.

He got the book and brought it to his office and browsed through it a few times, even did a few of the legendary hands on labs.

I think I'm beginning to understand how computers think - if that makes any sense, he reported to us.

Yes it does, we told him. You're learning the first of the two things.

A few days later he was back again.

One of our programmers passed by in the corridor and saw what I was reading, he told us. Looked shocked. White as a sheet. He came in and asked what I was doing. I told him. Oh no, he told me, you don't want to read that book anymore - you want to learn Java!

You just learned the second thing you needed to know, we told him.

We're dealing in graphical interfaces today but using Neanderthal tools. There's only ever been one dude really understood what that means and there's only one living language at all connected to that. Everything else is just the same big mistake it was thirty years ago when that dude turned his back on it all.

But the mall rats prefer to blog and say n'importe quoi to prove C Northcote Parkinson right. If you don't take the time to learn to 'think computer' you'll not really succeed anywhere.

Programming is ultimately about languages. Being a programmer is ultimately about being (at least) bilingual. And it's not about speaking a human language and Java - it's about speaking and understanding that first language and then speaking and understanding 'computer'. Languages are more than languages as most people (who are at least bilingual) can attest: they're about culture and ways of thinking. If you don't know how a computer 'thinks'; if you yourself cannot 'think computer'; you'll never be any good.

You'll always be a secretary. A monolingual one.

The dragon book's there for a reason, to cite a single example. The mall rats probably don't know what the dragon book is. They'll never come into contact with it. Yet people will have to build the software the mall rats need to write their programs; others will have to learn the machine code to create the firmware; still others will have to use real programming languages to write the systems and the drivers - and when they're gone what's left?

A few mall rats with too little ambition, too little brains, too little chops. and much too much time on their hands?

I'm just worried that too few students these days know assembly and C, which leaves us in a predicament when the current generation of kernel devs retire.
 - 'hedleyroos'

If you aren't rigorously checking preconditions on every operation you perform you're not going to cut it as a kernel dev anyway. Pointers are the least of your problems. Race conditions can become exceptionally hard to reason about. The prudent kernel dev architects the system such that this doesn't transpire. That requires a whole different galaxy of aptitude beyond not leaking pointers.
 - 'epine'

See Also
Technically Sound: Programming and Education Quotes

About | ACP | Buy | Industry Watch | Learning Curve | News | Products | Search | Substack
Copyright © Rixstep. All rights reserved.