Live data from Hacker News

Healthy Self-Doubt

nerdygirl.com

121–129 of 129 posts

Re: Healthy Self-Doubt

#121

Earlier quoted context omitted.

Well, knowing something is not arrogance. Stating that you know something is arrogance, unless you take precautions. I'm not saying it's bad, I'm saying the situation perfectly matches the dictionary definition of the word "arrogance". Everyone around here surely knows that it's often sufficient to prefix the opinion with "everyone here surely knows that ". Because if you say raw "X" very confidently, people immediat…

I'm a fairly literal person ("on the spectrum"). If I know something, I say "I know this." If I don't know something, I say "I don't know this." If I think I have insight into something, I say "This looks like..." My experience, here, and in many other places, is that people seem to have a deep-seated need to "put down" other people. We jump on openings from others with an almost fanatic zeal. You won't find much (if…

> people seem to have a deep-seated need to "put down" other people

Well, of course they do. All the time. It's a fine way to improve status in a social group and to get more meat after we kill our next mammoth.

Re: Healthy Self-Doubt

#122
post #48
post #23

For most of my career I worked with a small group (20 to 30) group of highly educated and mostly brilliant people. I barely graduated high school. As the years passed and we all began to age, I realized that the amount of knowledge we all had obtained during our tenure was an irreplaceable resource for the company. In order to help the younger incoming people bypass this learning curve I set up a wiki where group mem…

I've seen a lot of people waste time on writing documents that just sit there unread. No one wants to RTFM, esp one written a few years ago that is likely not accurate.

Then that's poor documentation.

Documentation, like comments, is most useful when it answers "why" sometimes "how" but rarely "what". And "why" changes much more slowly.

It's why I find API documentation to border on useless. I need examples and rationale, not variable names.

Re: Healthy Self-Doubt

#123

Earlier quoted context omitted.

I don't understand why you're mad that someone cited the Oxford definition to you. It's not trolling. You're wrong, and you can see this by looking at any number of published news articles where more often than not, average is used to mean median. You can see this from the way that we use average to mean typical. 'Typical' features are more likely to be median or mode than arithmetic mean. 'Average' is itself a collo…

TIL "average" in English can also mean things that aren't "the average" (mean)¹, but I also feel like "news articles" aren't a good way to source the "correct" usage of statistics terms. ¹ This makes "average" a particularly weird "false friend" vocable, because the average recipient might well take it to mean what you think it means, but might also understand it as a very closely related, but subtly different thing.

The fact that you used "the average recipient" to mean typical here really brings it home.

Re: Healthy Self-Doubt

#124

Earlier quoted context omitted.

> 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 us…

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.

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.

Re: Healthy Self-Doubt

#125

Earlier quoted context omitted.

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 t…

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 un…

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

Re: Healthy Self-Doubt

#126
post #23

For most of my career I worked with a small group (20 to 30) group of highly educated and mostly brilliant people. I barely graduated high school. As the years passed and we all began to age, I realized that the amount of knowledge we all had obtained during our tenure was an irreplaceable resource for the company. In order to help the younger incoming people bypass this learning curve I set up a wiki where group mem…

One of the things that I find really hard to do is to figure out where to start. I started programming when I was 8 years old, in BASIC, on a Vic-20. We were too poor to buy many games, but I discovered somehow that the public library had books that had game source code printed in the back. I learned how to type so that I could get free games quicker. Then I started understanding how the games actually worked and figured out how to change the code to cheat. Then... started making my own from scratch.

A couple years later I got a C compiler (Mix C) that came with a fantastic reference manual. This was on the family’s shared XT, so I started optimizing my computer time by writing code on paper and then typing it in when it was my turn. I started figuring out how to debug on paper too, so as to further optimize my computer time.

Then when I was around 12 we got a Pentium 1. Windows 95! This was really cool, but the C compilers for Win95 were either expensive or extremely hard to use (GDI in DJGPP? Yeesh). But I heard about this thing called Linux, and downloaded just enough Slackware packages to get going. From there, learned Perl, made money through high school doing web development, and started a CS/EE dual degree in 2002.

Anyway, that’s the long prelude to the problem: employees that work for my clients often enough ask me “how can I get better at Linux and lower-level software development?” I have no frickin’ clue what to tell them. I know the path that worked for me, but that path started a decade before I took my first university course. There’s this huge deep well of experience that I didn’t learn for the sake of learning, but rather because somewhere along the way it solved a problem for me.

Easy example: debugging something weird in giant source trees (eg the Linux kernel). “How did you figure that out?” “Well, I used find and grep to figure out all of the files that referenced that constant, and looked through each one of them to figure out which one we were actually calling.” “What do you mean when you say ‘find’? And what’s ‘grep’?”

It’s like that joke about “to make an apple pie from scratch, you must first create the universe”. I have absolutely no clue how to figure out how much of a universe a reader might have, and I’m almost certain I’m going to be making a bunch of incorrect assumptions about “common background knowledge” that will just further bewilder the reader.

Re: Healthy Self-Doubt

#127

Earlier quoted context omitted.

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 un…

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

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.

Re: Healthy Self-Doubt

#128

Earlier quoted context omitted.

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.

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…

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

Re: Healthy Self-Doubt

#129
post #23

For most of my career I worked with a small group (20 to 30) group of highly educated and mostly brilliant people. I barely graduated high school. As the years passed and we all began to age, I realized that the amount of knowledge we all had obtained during our tenure was an irreplaceable resource for the company. In order to help the younger incoming people bypass this learning curve I set up a wiki where group mem…

I didn't feel like I had anything worth sharing until recently. Something I've discovered is that it's often the stuff we consider "basic knowledge" that is the most useful to others. I think that perhaps one of the reasons skilled people don't share basic things is because they don't think they have to.

Once you get over that initial fear of being patronizing or talking down to people, you're able to really start communicating the things they most need to know.

Post reply on HN