[ChrisMarshallNY]

> should know better about something

It's been my experience that this is quite subjective.

For example, the standard leetcode binary tree tests.

When I mention that I'm not particularly good at them, I will usually get some variant of "Well, this is basic stuff that any programmer should know." –often delivered quite condescendingly.

But I've been writing ship code for over thirty years. I have a public portfolio with hundreds of thousands of lines of ultra-high-quality code, dozens of articles on software development practices, and multiple shipping apps for years (I write code every day –my GitHub ID Activity Log is solid green).

It's just that I started as an EE, and have been primarily self-taught. Since I have never encountered a binary tree in my professional experience, learning them has not been a priority. I'm certainly not interested in spending time learning impractical (to me) stuff, at the expense of learning what I consider the important stuff.

I'm also constantly trying out stuff I don't already know. It makes life interesting. I write about that here: https://medium.com/chrismarshallny/thats-not-what-ships-are-...

[sokoloff]

I don’t care if someone can bang out working binary tree on a whiteboard with the fluidity of Bob Ross, but I do care that people know that data structure and associated algorithms exist and could implement them given a dev environment, google, stack overflow, and a day or so.

[ChrisMarshallNY]

> data structure and associated algorithms

That's the thing. 99% of programming is Big Data (and windows, thereof), so everyone is on about that.

I tend to write stuff that is on a much more humble scale, like device control software, or systems that are used by thousands (not millions) of people.

I guess that I could say that "Any programmer should know about ring buffers," as that was a staple of my device driver stuff (I came up through hardware). In point of fact, only low-level drivers need concern themselves with ring buffers. Even programmers dedicated to writing device control software don't have to mess with them. The same with hardware handshakes, IRQs, etc.

We tend to view everything through the lens of what we know.

[jlokier]

> In point of fact, only low-level drivers need concern themselves with ring buffers.

As a side point, ring buffers are also useful in some high-level, high-performance code that is multi-threaded or using multi-processors.

io_uring is an example of this used to speed up Linux kernel-userspace communication (although it's not a great example for illustrating the general principle because it's so specialised).

DSPs use ring buffers extensively. Mainly for signal data, but sometimes for communicating tasks and messages between coprocessors.

[ChrisMarshallNY]

Cool! I did not know that, but it makes sense, as ring buffers were developed specifically to handoff between thread/clock contexts.

I haven't played that low in the dirt for many years. I suspect it's a very different world from the one I once knew.

I'm grateful for the abstraction. Low-level comms stuff is pretty damn hairy.

[tonyarkles]

Heck, I’m using ring buffers in some high performance image processing stuff right now. There’s non-constant-time processing in the pipeline, and dropping frames is acceptable if we hit some kind of pathological case where the image processing stuff can’t keep up. Pseudo-real-time is more important than processing every frame, but processing as many frames as possible is still desirable. By adjusting the size of the ring buffer relative to the input rate, we can put a bound on the maximum age of a buffered frame (camera runs at a fixed fast rate) while guaranteeing we’ll never exceed N*frame size memory usage.

[ChrisMarshallNY]

That also makes sense. We used to call that behavior "isochronous." Do they still call it that?

[sokoloff]

I agree that programmers should know about (the existence of the concept of) ring buffers, hardware handshakes, interrupts, synchronous vs asynchronous and serial vs parallel data communications, error detection/correction systems, grey codes, Karnaugh maps and logic glitching, split clock domains, etc.

If you tell me “I don’t want to know about anything that I don’t need clearly and presently to accomplish my next task”, you’ve told me something important.

[vvanders]

The parent is not wrong, coming up on two decades in this industry(and much more to keeping before that), the number of times I've encountered a binary tree is near zero. Only thing close was BSP trees in some engines we've licensed. There are parts of CS that get heavily over emphasised and parts that are neglected but super important.

It's also been my experience that the hardware things you mention are not well understood by most developers(it's a level of abstraction that honestly they don't need to worry about unless you want the last bit of performance from a piece of hardware).

[tonyarkles]

Binary trees I agree. Binary search and friends? That’s come up quite a bit for me.

[ChrisMarshallNY]

Never, for me, but I am sure that's because of the type of programming that I have done.

There's a chance that it may have been used in some of the convolution filters we developed, but I was no longer coding pipeline stuff (manager), by the time we got there.

[ChrisMarshallNY]

> If you tell me “I don’t want to know about anything that I don’t need clearly and presently to accomplish my next task”, you’ve told me something important.

Oh, wow. I'm busted. I guess I should just sell my computer and take up turd farming.

Except...

> "I'm also constantly trying out stuff I don't already know."

That might indicate that "clearly and presently to accomplish my next task" keeps changing.

[BurningFrog]

Yeah, binary tree type interview questions are probably a good way to weed out broken employers.