[apples_oranges]

This reminds me of a discussion about NFTs recently. I caught myself having an opinion without really knowing how they work. So I googled it and only found vague descriptions. Then I looked for an actual ETH blockchain contract that implements NFTs on Github [1], read it, and it was all very simple and clear. (So for me it was "How to Learn complex Things Quickly by realizing they are not that complex at all.")

So in some cases I'd put "Read the Source Code" at the top.

Code is not quite mathematical notation, but it is a concise way to express something..

[1] I read this one: https://github.com/larvalabs/cryptopunks/blob/master/contrac...

[itsokimbatman]

"How to Learn complex Things Quickly by realizing they are not that complex at all."

This is such a good observation. When I was first getting into my field, I looked around at the smart senior people around me and thought there was no way I could ever do what they did. Total case of imposter syndrome.

Things like compilers, operating systems, etc. all seemed like magic, and I thought I was too dumb to do that kind of stuff.

But once I started working, I didn't really have a choice... it was either learn or get fired. And digging down into the code made me realize just how... simple? ... some things are. Being able to pull back the curtain and realize there's no magic there. Want to talk to this piece of hardware? Just write this bit pattern to this particular address, then put your data over here, and then send it this command and it works.

Not to say I immediately figured everything I read out. Sometimes it took me hours or days to work through something, especially if it was heavily templated C++ code.

One of the things that really surprised me was looking into build systems for large projects. When I thought about how I'd do it, I could only imagine a disgusting, hacky series of scripts and code generators and things that any sensible developer would scoff at. But when I actually looked at how some projects are put together... they're a disgusting, hacky series of scripts and code generators.

Learning that there's nothing magical about any of this was life changing. I still deal with imposter syndrome, but I feel much more confident that I can learn if I just make myself dive in, even if it seems scary at first.

[the_only_law]

I’ve gone through the demystification phase a number of times. Unfortunately it’s always very surface level. There’s been a ton of things I’ve been trying to read about and learn about the past couple years. I could probably give a pretty decent, albeit rough description of most of them and how they work, but I could not implement them myself from scratch or anything.

And I still look up at some people and wonder how the hell I could ever get to that level. People who seem both wide and deep in knowledge. Even people who cross outside different domains and seem well versed across all sorts of fields. I recall being among some reverse engineers quoting seemingly from memory undocumented behavior of random Windows API calls.

[bostonsre]

At least for me, reading is not enough. It gives some good context, but actually using that knowledge to accomplish tasks helps to solidify that knowledge. Viewing my knowledge as a network of interconnected nodes also helps me reason about it. Reading a key/value dictionary from start to finish doesn't leave enough interconnected nodes for that information to persist long. Knowledge seems to solidify when it is connected and linked to other bits of knowledge but islands of knowledge seem hard to retain. E.g. Those seemingly random windows api calls are easier to remember when you know of their Linux equivalent, in what cases you call those methods, what other methods call that method, what methods that method itself calls, what happened last time you called those methods, etc. I doubt they remembered them because they read the source code once and have a photographic memory.

[nneonneo]

Or, having been there, maybe they remembered them because they were interesting/weird tidbits that caused them to have to debug something for hours. Or perhaps they ran into those weird things last week. (I will never forget, for example, that certain glibc functions such as system() use movaps to copy data from the stack - because it’ll crash the program when you call them from an unaligned stack ROP...)

[iagovar]

I hope to get there some day. I'm learning to code currently (until now, I was only capable of scripting, which is code, but you know what I mean) and I feel like there's just massive knowledge out there just to make simple things.

Managing systems and environments make my head spin very fast. I try to keep it simple but now im peaking into the node/react ecosystem and I feel all over the place.

[depressedpanda]

> I try to keep it simple but now im peaking into the node/react ecosystem and I feel all over the place.

If you want to keep things simple you should probably stay away from modern frontend web dev.

Or, if you must do web, start with vanilla HTML, CSS and ES2015+. A solid understanding of the basics will always be valuable, and you can always build upon that knowledge when you reach the pain points that node, webpack, React etc help you solve.

[Jgrubb]

I'll get blown up for this but you're not all over the place, the node ecosystem is.

[jimpudar]

Also related - don't read random tutorials on "how to do X", go and find the official documentation for X and RTFM. In my experience this is the easiest and most direct way to learn any new technology.

[cratermoon]

> go and find the official documentation for X and RTFM.

Yes and no. The official documentation can be obtuse and bad for new learners. (I'm looking at you, gradle[1]). Ideally, the official documentation includes tutorials, but also three other forms: 1) how-to guides showing the steps for accomplishing a common goal. Think of them as extended FAQ answers. 2) simple reference docs. Your typical api-centered doc, or man page cli flag list. Answers the question of "what was the function/class/flag to do that?" Assumes you already know how. 3) explanations, the discursive articles about how and why. A lot of people can get by with never reading these, but once in a while they can clear up some problem you're having. The tutorials, which should exist, would be short guides for learning by doing. They aren't how-to guides, because they don't assume you know anything yet. They are often the best entry points for picking up something entirely new.

[1] https://www.bruceeckel.com/2021/01/02/the-problem-with-gradl... and https://melix.github.io/blog/2021/01/the-problem-with-gradle...

[the_only_law]

I’ve had the opposite experience. I’ve attempted to read a number of specs, and by the way I’m completely unable to parse them, you’d assume I was illiterate. On the other hand, I’ve found good, technical articles detailing how the same things worked and have found them much more digestible.

[JJMcJ]

Sometimes the official docs are just right. Django is good, for example. I had to do small Ubuntu sysadmin task recently, the tutorials I found were incomprehensible. The official docs were crystal clear.

But we've all seen the reverse, as well, and a combination of SO, YouTube, Reddit, and random tutorials is the only way to figure it out. Especially when you encounter the "This describes version 3.1, and everything in 4.5 is completely different, good luck" official docs.

[bigwavedave]

For me personally, the answer is a combination of the two. Having the docs open side-by-side with a good technical write-up usually helps me understand a lot faster and better than either resource does on its own.

[jimpudar]

If you're competent enough to judge the technical article's credibility, this can be a good supplement to the official docs. I see junior developers running into this problem more often because they don't know how to tell the difference between a quality writeup and a garbage tutorial written by somebody trying to pad their blog.

There are definitely cases where the official docs (or RFCs) are practically incomprehensible to a newcomer, but I usually will try and come back to them quickly after getting a foothold using a blog post or YouTube video.

I find that even with the best technical writeups, there are often things applicable to MY use case that may not have been relevant to the author. The official docs (or sometimes the source) is the best place to find out about those.

[treyfitty]

Eh, I have the opposite experience. When I was a beginner in a any language, RTFM didn't work for me because:

A) Reading a manual requires some requisite knowledge due to esoteric references.

B) RTFM is a skill in and of itself.

C) Manuals rarely mention corner cases or "gotchas" which can cause confusion to a beginner.

D) Manuals never comment on best practices, which tutorials do.

[elevaet]

The F'ing M is often an afterthought, and sometimes you need to dig into the source code to understand how the thing works, or at least to find the right handles to grasp.

Not necessarily the right approach for beginners, but I've wasted a lot of time trying to find the thing in the documentation, when I should have just lifted the hood in the first place.

[evrydayhustling]

This! There is very little selective pressure reducing the quantity or visibility of bad intros/tutorials. But for successful projects, the community puts a lot of pressure on the improvement and accuracy of core documentation. Truly complementary tutorials often ended up getting linked from or incorporated into primary project docs/pages -- so it is safer to explore from there than a Google search.

[idolaspecus]

And it's much, much rarer but equally as important corollary: UTFM (Use TFM). UTFM means: when you're designing a system, adhere your design so f**ing tightly to standard usage. RTFM/UTFM with standard tooling gets you so, so far to building high-quality software.

Edit: I actually just made up (as far as I know) UTFM, but I really wish it were a thing.

[pm90]

I recently found the need to teach myself Java. While the Java Docs and official Java tutorial seem to be decent, especially once you know what you’re doing and want to dig deeper, the “Baeldung articles” have been really useful as starting points as a survey of options available. Since this seemed like a pretty random website, I’ve been cautious and cross referencing everything I read. But I have to admit, it was pretty damn useful.

So unofficial tutorials do have their place in introducing design patterns or listing trade offs between different approaches. But I do agree the source of truth should still be the official docs.

[atoav]

I think very often the most crucial information is not given when teaching people complex topics:

- Why is this important? What problem does it really solve?

- Why this solution and not another one?

- What do I really need and use this for in practise?

To realize it is not that complex at all you have to be able to sort it into a box first. Many teachers may take a big effort to break the complexity down into small pieces, but if you don't know where the whole thing fits this can break the whole teaching effort.

I will never forget when I realized my (really bad) maths teacher managed to not tell us the perfectly good and understandable reason why integrals are a cool thing that solve real problems for a year of needing to deal with them. She really broke down the steps etc, but totally forgot to tell us what the thing was actually for, and why the stuff we already learned couldn't be used to solve certain problems.

[lbotos]

I work as a support engineer and I often say "sufficiently advanced technology is indistinguishable from magic. My job is to explain magic." I had this same realization as you a few months ago when I was learning about DeFi and Eth proof of stake.

[JJMcJ]

More times than I care to admit, I've been totally confused, and then decide to actually watch that 14 minute video on YouTube, and read the entire doc page, and the mystery disappears.

RTFM: words to live by.

[iamcreasy]

I think code is equivalent to a math notation. A mathematical notation is unclear in the first read as it tried to cover all edge cases, while being rigorous at the same time. A piece of code that implements the math formula is somewhat similar in a sense it's trying to implement a core idea while also covering the edge cases. Both needs training, patience and some background knowledge to parse accurately.

[eindiran]

The ERC-721 standard is also quite clear and fairly consise:

https://eips.ethereum.org/EIPS/eip-721

Cryptopunks was used as the jumping-off point for defining what an NFT standard needed to do.

[908B64B197]

> So in some cases I'd put "Read the Source Code" at the top.

"Read the source" is often seen as an aggressive or dismissive response, but sometimes it's pretty much the best way to figure out software.

[shishy]

Right, often the actual thing isn't so complex but sifting through all the abstractions people created over it is.

[th0ma5]

If you didn't get the sense that they are just a glorified bookmark list then it wasn't clear enough.

[astrange]

The people who named them don’t seem to realize they are not “non-fungible” since you can start another chain. And of course the NFT of a real thing is not the real thing, it’s a URL to a picture of the thing, so they don’t necessarily have the same owner.

[th0ma5]

If you used private key encryption on both sides you could securely transfer data between two parties, and prove that you did so in a way that is very hard to dispute. But like Snowden says, it is still unencrypted going in and coming out at the endpoints. It is very hard to watch my creative friends wish that digital data behaved like real world items.

[astrange]

I think you can explain it pretty easily at least. A blockchain is a Google Docs spreadsheet. An NFT is an entry with the name of an item next to the name of an owner. Magic prevents other people from editing it, but you can just start another spreadsheet and put your name in there.

Plus if it's the NFT of a physical item then you can just steal the real thing.

[shoto_io]

I think for most people, learning is iterative. You need to peel off the complexity layer by layer. You are lucky enough to understand what a blockchain is. That's an unknown concept for many who want to understand what an NFT is. I guess most people (including me) will have a hard time understanding the link you've posted.

[okprod]

So in some cases I'd put "Read the Source Code" at the top.

Only if source is available