Hacker News Reader

Comment by simonw | Hacker News Reader

One of the many things I find inspiring about Julia is how quick she is to admit to mistakes she has made or things that she hasn't understood.

If she didn't understand it, I can 100% guarantee that there are large numbers of people out there who also didn't understand it - many of whom were probably too embarrassed to ever admit it.

I think this is a useful trait for senior software engineers generally. If you're a senior engineer you should have earned enough of a reputation that the risk involved in admitting "I didn't know that" can be offset by everything you provably DO know already. As such, you can help everyone else out by admitting to those gaps in your knowledge and helping emphasize that nobody knows everything and it's OK to take pride in filling those knowledge gaps when you come across them.

View on HN

Personally, I think that the idea that programmers should know everything is kinda bizarre.

Programming is about finding the answer. If you already knew everything, you could just sit down and type any program from your knowledge.

We all know that you can't know everything otherwise, why even write documentation or use git?

Unfortunately, it's difficult to move past this idea, and it's so pervasive that stating "I don't know" can negatively affect your standing for some.

Right! The best thing about our chosen career is that it's completely impossible to know everything - there's always a new corner of software engineering to dig into, be it how the Linux kernel works, or programming with Haskell, understanding Transformer LLM architectures, or how the Svelte compiler works or whatever.

... and be able to code in React

Many people have the same expectation of their doctor: he must know everything or he is completely useless and I should find a new doctor.

It is also insanely difficult for a doctor/surgeon to admit a mistake without being punished severly.

This is what jumped out to me reading this article too - unashamedly admitting to having gaps in knowledge that some others might take for granted.

Bucketing some of those gaps as “probably useful but not to me right now” is also great. It shows a purpose to focus on what matters right now, with a hint to return to when it does pop up again later.

Lots of folks I work with and respect sometimes get trapped in the weeds having to understand every little thing. It’s good to be curious, but sometimes filing it away for later and shipping is more important now.

One of the many things I find inspiring about Julia is how quick she is to admit to mistakes she has made or things that she hasn't understood.

Agreed. I think 90%+ of the complaints people have about technical blog posts would go away if authors were more willing to admit what their blog post is really for and what their limitations are.

Writing an "Ultimate Guide to X" as a learning experience is fine if you admit that (and, ideally, use a more humble title) but pretending to be a long time expert in framing when someone isn't leads to problems and a poor reputation. You, too, are fantastic at framing your content properly, and have a great reputation amongst people I know for it.

I recently included a big goof in a blog post. I accidentally consumed all my errors and didn't log them anywhere, so I was just flying mostly blind.

It was also in a language I don't have much experience in (Elixir), doing 3D rendering in OpenGL (which I also don't have much experience in), on a Mac (so no tools to debug OpenGL stuff). Definitely wasted more time than I'd like to admit, but I won't be making that mistake again. :)

most of the time when people don't ask questions in industry, it isn't because they already know the answers, it's because they don't care what the answers are

blogging is culturally different because there's way more exhibitionism involved

Don't you think, as others in this thread are saying, that one reason people don't ask questions is because they're afraid to admit their lack of knowledge?

We've probably all been in one of those meetings where something is being proposed, and everyone is nodding vaguely along but you're not sure the proposal is correct. Do you ask a clarifying question (and risk seeming foolish for not knowing something obvious) or just let it pass because everyone else seems happy with it?

> Do you ask a clarifying question (and risk seeming foolish for not knowing something obvious) or just let it pass because everyone else seems happy with it?

Two different kinds of foolish here: etiquette or technical

In some meetings if it's management and senior leadership grilling a design, if some unrelated IC butts in with a bunch of questions that are 5 steps behind everyone else it's sort of a faux pas

Right -- there isn't a single answer, it's very context dependent. I do think many ICs lean too far in the direction of keeping quiet, though.

(Managers too, come to think of it. You can feel overawed by skilled ICs and chicken out of asking naive but crucial questions.)

I thought you were talking about Julia the language and was so confused.

This is the kind of mistake that I doubt even a junior Go developer would make. If one is a senior engineer and one has Go on their CV, then one must know the memory management top to bottom.

This kind of downplaying of hard skills and trying to argue that one can help by admitting gaps in their knowledge is at best weird.

Reply on news.ycombinator.com