Hehe szlamany,

I know where you’re coming from. But the thing here is that Dglienna hadn’t heard of the concept of linked lists until relatively recently, thus it is possible that the established programmer in my place had genuinely not heard of them in X years of being a programmer. Whereas I was thinking, “hmm, the guy don’t know about linked lists, exactly how long has he been programming?”

I’ve been there programming on the metal, as it were. I remember writing code that relied on in depth knowledge of how a TV picture is rasterised and the timing of the electron gun to tease 16 colours per character cell out of a machine that could only display 2 colours per character cell normally. I’ve not gone so far in the business field but have used C-Isam and written what I called a “screen driver” for unix/dos which was not a kick in the ass from what Access and VB give us nowadays.

They call programming, software engineering. And as such I treat myself as an engineer. I want to produce good code. Good in the respect that it does what is expected of it. Good in the respect that it works solidly. Good in that it is based on sound principles. Good in that it is relatively easy to maintain. And good in the respect that it doesn’t make anyone’s life harder, be they developer or user.

I can understand what Dglienna says. If you read some VB books on the market they don’t mention linked lists. For most tasks they are largely irrelevant. The same thing happens with sorts, why bother coding a quicksort from scratch when you can stick your data in a disconnected recordset and have it sort it for you.

Yes, I believe it’s good to have the knowledge of what’s going on behind the curtain. But it isn’t always necessary.

I’m just looking for advice here, and don’t want to turn this into an argument over what should be known and what doesn’t need to be know mate.

Rgds

Adagio2004