was chatting with a friend about some of the challenges with teaching yourself programming topics:
* you have random gaps that you don’t even know about
* it's hard to assess your level, you might know a lot about one subtopic and be a total beginner elsewhere
* it's very difficult to guess what other fellow autodidacts know about the subject
I've had to learn how to suss out what shared knowledge base I have with another programmer on any given topic quickly so that we can talk
(1/?)
I also think a lot about what it means to be "self taught" in programming, for example I "taught myself" about how TLS works under the hood by writing a toy implementation of TLS 1.3. But I used this guide https://tls13.xargs.org/, and I probably could not (or would not) have done the project if that guide didn't exist
so if we want to make it easier for people to teach themselves effectively, what kinds of resources do we need to provide?
(2/?)
we have a lot of amazing "teach yourself" resources in programming (like nand2tetris or all of the great guides to writing your own compiler / programming language).
But I think a lot about -- which programming topics *don't* have great guides for how to "teach yourself" that thing? What's missing? How can we fill in the gaps?
(3/?)
also, how can we help people who are self-taught in an area recognize what knowledge gaps we might have? Not in a gatekeeping “EVERY REAL PROGRAMMER SHOULD KNOW X” way, but more "hey, if you feel like you're missing something, here are some ideas for where to start"
(4/?)
I used to get a bit mad when people referred to me as "self taught" (“I have TWO computer science degrees!! I literally have the most normal possible CS education!”) but I've learned to embrace it. There's no way you can learn everything in your CS degree, careers are long, and we're all gonna have to teach ourselves a lot of stuff anyway.
(5/?)
With decades of experience, I would say that these points still apply, regardless of experience:
https://mastodon.social/@[email protected]/111839840688452630
Well, except that I now know so much that I can easily identify *huge swaths of things that I don't know about*. 🙄
And on the "issue of being self-taught" ...
I first learned programming informally -- from friends and from reading. And then a formal computer science degree -- *after* rewriting bad production code written by a "seasoned professional."
...
And yes, continuous learning is vital. Not long ago, my boss and I found it funny that we were required to submit college records "showing that we're professionals" before being allowed foreign work visas. We both agreed that *none* of the tools and technologies we were to be working on even existed when we graduated from college. I'm an expert on many things I've learned at work.
@b0rk Loud agreement with all of this.
When I'm considering what book to write next, I always consider sysadmin culture's knowledge gaps. I write them specifically to cover what every sysadmin must know about the topic.
Nothing replaces getting in there and playing around with a protocol. We invent toolkits to make e.g. creating a TLS connection easier, rather than materials to help people understand what TLS is doing. The well-meant toolkit is confining, where the understanding is liberating.
@mwl @b0rk Slightly tangential to this: I found that programming a “secure” protocol (in this case, SNMPv3) was slightly maddening.
I had to get it precisely correct, or it wouldn’t work at all, and nothing “under the hood” was any help at pointing out what might be wrong (except, perhaps, Wireshark in some instances).
It didn’t help that I was struggling to make sense of OpenSSL and its various APIs (and documentation) at the same time.
@b0rk I feel like there are 3 things there.
1. The basic things we need are system desing (or systems thinking) and breaking down a solution into step by step code.
2. Then we need to learn the technology the solution relies on. Java, DNS, K8s, etc. That's almost infinite and it changes every decade, so it can't be measured in "completion percentage".
3. Finally, there's the problem domain. Each industry has its own quirks we need to learn to be effective in it.
@b0rk I've had similar thoughts about teaching. I don't have much formal training in education, but I do a lot of teaching and teaching-adjacent things.
In other words I'm a "self-taught" teacher, with all of the doubts about knowledge gaps that comes with that.
The first couple times I held my own in a conversation with "real" teachers felt like I had been running by myself and finally found out that my times weren't as bad as I was assuming. I still don't feel like a "real" teacher though.
> I used to get a bit mad when people referred to me as "self taught"
No - you should still be mad at that one.
It's completely absurd.
So what's wrong with a EVERY REAL PROGRAMMER SHOULD KNOW X approach? I would have loved to have one of those when I was starting out.
@SnerkRabbledauber I just fundamentally don't think it makes sense, @galaxykate has a great thread about this on twitter https://twitter.com/GalaxyKate/status/1751618131187884089
there are too many different kinds of programmers and programming is too big
But as a CS worker for decades I see all the time how a lack of understanding the basics leaves people confused and stuck when something doesn't do exactly what they expect.
@SnerkRabbledauber @b0rk There's a big difference between the mindset of "REAL PROGRAMMERS SHOULD KNOW" and "These concepts are used extensively in multiple fields"
For example: A lot of people say crap like "REAL PROGRAMMERS SHOULD KNOW HOW MEMORY WORKS". While I'll allow that "knowing how memory works" has made some of my code better over the years, I know plenty of people who are much more prolific devs than I am who have almost no understanding of it, because they don't NEED it.
I'm just sharing what I have learned in 30 years in the field. If you want to have real power over your tech you should want the basics, no, you should DEMAND the basics. Cutting corners and skimping on enriching your brain may work if you're lucky, but it also hands over your power to others. How comfortable a person is with that exchange will vary.
@SnerkRabbledauber Right, that's the question Julia is asking, she's just saying to avoid the mindset of "you're not a real programer if you don't know X".
To expand on my earlier example, it's the difference between "EVERY PROGRAMMER SHOULD KNOW HOW MEMORY WORKS" and "Understanding the types that drive your program, whether they're passed by reference or by value, and how to manipulate that to save (?:dev|run)time" isn't particularly subtle. That's all I was trying to get across.
Oh man, there is no bigger can of worms than regex! :)
It is true that what constitutes "the basics" has moved up the abstraction ladder over the years. Where to draw the line is not clear. So I guess we agree at some level.
@SnerkRabbledauber I think you just hit on one fundamental though: abstraction. If more folks had a good understanding of where their layer of abstraction sits, I think that'd solve a lot of problems.
But, then, I have a whole series of blog posts I've been drafting for like two years on the concept of abstraction, so maybe I'm biased.
Very good point.
I know, reasonably enough, how memory works in an Apple II. I know very, very little of this from 2007: https://lwn.net/Articles/250967/ — and even less from whatever has changed since then.
@mattdm well, you see, memory is like a book, and you can write things in the book or read them out of it, and your cache is like what's in your brain, and the hard drive is like a library.
Or something, who even knows anymore.
@SnerkRabbledauber @b4ux1t3 I think the point is, what on earth ARE the basics? My husband has been neck deep in network protocols and if I need to know how UDP works*, I’d ask him. But if he needs to make a minimal web page exist, he asks me. And we’ve both been in the field for a while now. Just very different parts of it.
* I have literally never needed to know this
@thatandromeda @SnerkRabbledauber check this extremely technical document for everything you need to know about UDP.
I always thought the UDP one should be a hose instead of a bottle.
206 always gets a laugh from me.
@b4ux1t3 @thatandromeda @SnerkRabbledauber this tbh isn't a helpful metaphor
you should be thinking of udp as Fancy IP
it's a datagram with a port and a useless checksum we can forget about
Aye, there's the rub.
I would not include network protocol details by any means. But an understanding of the concept of protocols, packets, and generally what happens when establishing connections, etc. are very good to know. If you work on the web you most likely have that level of knowledge. The fact that you know UDP exists demonstrates that.
I would contend that the "ignore the basics" approach is designed to produce consumers instead of producers. An education that includes the basics empowers the learner and vastly increases their options. Allowing more freedom to make technology do exactly what they want it to do.
@b0rk I think the simplest representation might be a thorough vocabulary list, with some kind of rank for each term. (E.g., "stack" and "heap" have a higher knowledge rank than "code" and "compile".
Filter the list by rank, read all the terms. If you don't understand one (thoroughly), view the material related to that. When you run out of terms, re-filter with the next rank up.
@b0rk I hit a lot of brick walls when trying to teach myself all sorts of computing topics, and the one I think of most often is the way "Kids and the Commodore 128" presented FOR loops.
They said it would count some variable from one number to another, and gave an example of how this could be used to slow a program down by inserting do-nothing FOR loops in the middle of a GOTO loop. As a result, my gradeschooler brain refused to accept the real utility of the things: they'd just poisoned my conception of the construct with a terrible framing.
I think the biggest question I had when encountering new topics was always rooted in "But *why* do we need this thing? What is it actually used for?" I needed examples of sequence processing that weren't just toys.
The O'Reilly Python book was kind of a dud, because it taught all the language features through the lens of some kind of FTP file-uploader program that, well...it didn't do anything a good ftp client didn't already handle. It was extremely difficult to care about the unfolding narrative of the large single example program the book was built around.
By contrast, the O'Reilly Learning Perl book was phenomenal at teaching the language through little ten-line examples that did amazing and useful things. I stopped bouncing off Unix concepts when I read that book, because it taught me the ways in which Perl smashed a bunch of Unix conventions into one big interpreter (which I first used on DOS, for funny historical reasons). I later took what I learned into a professional Linux career.
I think Learning Perl and the Unix-Haters Handbook were probably the two most important books for actually teaching me what Unix was about. The latter gave me more context about the way Unix was designed than any document trying to advertise it to me!
@b0rk this is probably a stretch, but I wonder if there’s a highly regarded based on real world experience curriculum, whether uni based/bootcamp/online-course that makes programmers feel like “I got the basics!” fairly soon into their first few years working in the real world. Might be good as a starting point.
I also suspect there are diffs across different programmer types. Like if you want to jump into web-based engineering, JavaScript is an obvious starting point. But if you want to get into coding drone software or embedded device development, that’s a very different set of basics you’ll want to know.
Julia Evans
Ido 🚴🏼
Anil Madhavapeddy
Ángela Stella Matutina
Jeff Grigg
Michael W Lucas 
Fear and Tooting in Las Vegas
Whyrl
Kevin Coulombe
Grant Gould
Kevin Workman
PierrePaul
Phillip of Mastodon
Yet Another EU Nerd
Karl
Bynkii
Garrett Wollman
GodEater
Paul Wouters 🇪🇺🇨🇦
Lea
Snerk Rabbledauber
b4ux1t3 
#1️⃣
Matthew Miller
Andromeda Yelton
Noah Kennedy
pr06lefs
DavidWMaxwell
Space Hobo
AJ
Sena
Jayenkai [ J-N-K ]
Breno Guimarães