I don't know if I'm using the word the same way, but I understand the benefit of mastery to be that you automate and abstract away things and can get to a point where you're just firing off mental routines instead of having to consciously focus on the specific task. This means that in a multi-faceted task I can focus primarily on the elements I haven't mastered, since the things I have mastered come easily and automatically. As a consequence, anything that relies in part on the mastered skill gets easier.
Totally agree. The key idea here is automaticity, the ability to execute low-level skills without having to devote conscious effort towards them. Automaticity frees up limited working memory to execute multiple lower-level skills in parallel and perform higher-level reasoning about the lower-level skills.
For instance, think about all the skills that a basketball player has to execute in parallel: they have to run around, dribble the basketball, and think about strategic plays, all at the same time. If they had to consciously think about the mechanics of running and dribbling, they would not be able to do both at the same time, and they would not have enough brainspace to think about strategy.
That is a much better way of putting it, thank you.
(edit) One thing neither of us directly mentioned in our comments, but which I feel is important is this bit from your article intro:
> Insufficient automaticity, particularly in basic skills, inflates the cognitive load of tasks, making it exceedingly difficult for students to learn
A real-world example for myself was when I was learning a small lick on guitar with an uncomfortable-to-me rhythm. I initially just played it slowly so I could get everything right, trying to speed it up every now and again to check progress. I progressed, but slowly. What ended up demolishing the challenge is the separation of the rhythm element(s) from everything else involved in the lick, and practicing those individually. By themselves they were easy to knock out (matter of minutes), and after those few minutes when I revisited the entire integrated lick I could suddenly knock it out of the park.
Great example. Yeah, I fully agree that in general, the fastest way acquire a complex skill is to focus your practice on the particular components that are giving you the most trouble. That's the main theme behind deliberate practice: find the bottlenecks and concentrate your practice time on them.
I've been surprised to find that this isn't a common viewpoint. In fact, I have a long-term bet with a friend that I'll learn something faster using deliberate practice 'n stuff then he did trying to learn everything at once.
I got a kick out of Windows' responses to me installing Chrome on some machines at work.
First, search (good) Bing for Chrome. Get a sponsored result from MS saying something like "Oh, really, no reason to install that, Edge is x, y, z marketing bs, you should just use it instead."
Second, go to Chrome download page. Windows then pops up a notification bubble or something in the top right again extolling Edge, finishing with "and it's Microsoft Trusted!"
I gave edge another shot last year, because it's just chrome right? Sure. That's what it started out as. Until MS middle-managers trying to get promotions added enough shit to onboarding that it repelled me back to Chrome
Not really, but I'll give you an example and then if you can give me an idea of why you're curious I can try and provide a few more if you think that'd help.
A good one that I think is fairly typical of my annoyances - 'each' - the each keyword uses an iterator attached to the data structure it's iterating, so if you return or throw part way through doing so the iterator is left half way through and the next attempt at iteration will ... not do what you thought it would.
The reason for this is that 'each' was originally introduced back in the mists of time to allow iteration over a dictionary (hash) backed by a DBM file of some sort, and those files only -permitted- a single iterator at the same time.
Of course, people then started to use it for other things, but by that point making it behave a less surprising way for that would've broken existing code that used it for its original purpose (Larry and I chatted about this once and our conclusions mostly came down to 'alas').
Backwards compatibility is a hard master, and perl (and most cpan modules) work very hard not to break it, which leaves assorted things like that lying around.
My 'solution' is to accept this as fact and simply not use 'each', instead iterating over the keys and pulling the values out in the loop body, and honestly that's fine for me but it's moderately annoying having to keep telling newbies they need to pretend the keyword doesn't exist.
Things that freenode/libera #perl have found to be footguns often enough that we regularly teach people not to do that are collected in https://metacpan.org/pod/Perl::Critic::Community so you can find them with static analysis (and yes, of -course- each is on that list :) and might also be enlightening.
(I personally quite like using the behaviour covered by ConditionalImplicitReturn, but that one probably still belongs on the list because I suspect the vast majority of the time it gets used by accident and becomes a footgun with a delay fuse ... i.e. "if you know enough to use this safely, you should also know enough to turn that rule off" applies)
Part of the trouble I'd have producing a comprehensive such list is that so much of this knowledge has been baked into my brain/fingers long enough that there's not really any thought involved in avoiding triggering them anymore - my primary reason for mentioning it was "I am absolutely not blind to its faults, though every language has some somewhere" because I wanted to explain why I like perl overall without sounding like an Evangelism Task Force member.
But yeah, if you want to point me in a direction I'm still happy to dig through my brain and see if I can find you a representative example :)
> Now maybe my mental model of self is wrong and I need to learn LISP and create a mental model for setf and that will lead me to an awakening of a correct mental model of self?
> Part one of the less popular and much more brief third edition of the Radiotron Designers Handbook [0] is probably my favorite writeup but is very dense and covers a good deal of stuff in those ~80 pages.
I'll have to check out the RDH section. So far I've been working through "Theory and Application of Electron Tubes" by Reich, which as a physics person I've quite enjoyed. I'm guessing the RDH section is a compact summary of the stuff in Reich's book.
> Aiken Amps White Papers [1] is pretty good and the first amplifier I designed (and built) was completely done through those pages, still have that amp and have sold it twice and bought it back twice.
I'd already stumbled across his stuff before, but didn't realize there was a nice organized listing of everything, so thanks for that. Looks like he has a useful bibliography too, from which I just found several interesting reads:
https://aikenamps.com/index.php/a-bibliography-of-must-have-...
Radiotron is the big book by RCA, 4th edition is the bible of tube design and ~1500 pages, but the vast bulk of it is not very applicable to audio frequency amplifiers and it goes into transmitters and receivers and so on. Part one of the 3rd edition is audio frequency amplifiers and would be better described as concise than a summary, it gives you most everything but skewed towards practical application. From what I remember RDH3 and Reich cover about the same stuff overall, but it has probably been a decade since I looks at RDH3 and even longer since I last looked at Reich. RDH3 was written at a time when there was an exploding new market and it targets people who were looking to exploit that market so avoids a lot of the digressions which are interesting but academic when it comes to designing amplifiers.
Howard Tremaine's books are quite good and it looks like Aiken left off his Passive Audio Network Design, which was probably sensible but it can not be beat if you want to really understand the stuff in the guitar and better understand the stuff between the tubes which are often passive audio networks. But it might be a bit too in depth for most, I really enjoy passive design and probably have a blind spot here.
> Part one of the 3rd edition is audio frequency amplifiers and would be better described as concise than a summary, it gives you most everything but skewed towards practical application.
Ah, I see, good to know.
> Howard Tremaine's books are quite good and it looks like Aiken left off his Passive Audio Network Design, which was probably sensible but it can not be beat if you want to really understand the stuff in the guitar and better understand the stuff between the tubes which are often passive audio networks. But it might be a bit too in depth for most, I really enjoy passive design and probably have a blind spot here.
I haven't heard of his stuff yet, I'll have to look into them, thanks! No worries about it being too in-depth, I'm usually more concerned with things not going in-depth enough! I get practicality and conciseness being a concern and all, but I like knowing the why's behind the what's.
Note for those who are as confused as I initially was: Passive Audio Network Design is by Howard Tremaine, not Aiken.
Edit: Just scooped up the only copy of Passive Audio Network Design I could find. Should be here by Monday!
>No worries about it being too in-depth, I'm usually more concerned with things not going in-depth enough! I get practicality and conciseness being a concern and all, but I like knowing the why's behind the what's.
Generally I agree but unless you are going to get into the design and production of vacuum tubes a good amount of the knowledge is kind of useless. The thing is tubes are far from ideal and even if you sift through 100 tubes to find those few which kind of line up with the ideal they start drifting from that ideal the second you put them to work and they all drift away from that ideal in their own way. We can compensate for this with exotic topologies but if we do that we end up designing away everything inherent to the tube sound and end up with something that costs and weighs twice as much and sounds like transistors*. The truth when it comes to the simple topologies used in successful tube amps is that the curves and a few simple equations (ohms law, parallel/series resistance/capacitance and rc filter) will get you just as close if not closer to your goals as the theory and math and do it in a fraction of the time and once you really get it all down it all turns into a few rules of thumb. But getting it all down is rather nebulous and personal, those rules of thumb are essentially cliches and seeing the wisdom of a cliche is always hard earned.
This is ultimately the genius of Leo and why Fender became the biggest name in amps, he realized that even if the math and theory said 120k was the ideal value tubes are not ideal and are not constant so 100k is close enough so make all the plate resistors in the preamp 100k unless there is a very good reason not too and exploit the economy of scale when buying resistors. Most of Leo's amps from a given era are pretty much the same, he let the speakers and cabinet give the difference in sound. Well worth spending some time analyzing his amps.
>Passive Audio Network Design is by Howard Tremaine, not Aiken.he
Yeah, that was not worded well, I was referring to Aiken listing Audiocyclopedia and not Passive Network Design. Audiocyclopedia is a great book as well but I think that one is best left for when you have a good understanding of things, it is closer to cookbook than guide but gives better explanation than most cookbooks. Passive Network Design is great and will give you all the nuances of things like tonestacks as well give you the knowledge required to build a 1940s style recording studio if you feel so inclined.
*The actual "sound" of transistors is more that those topologies which are exotic in tubes are common in transistors because doubling your transistor count only adds a couple ounces in weight if any and maybe a couple dollars. If you treat design with transistors as you do tubes you get fairly tube like in dynamics and we see this demonstrated in the rather naive 1:1 translation of tube amps to transistors that runoffgroove got big with.
Edit: when going into ideals I forgot to mention tolerances of passives, 5% for resistors and 10 or 20% is common for capacitors and these all drift away from their spec as well and capacitors start leaking DC throwing off your bias. You play the odds like Leo did and a good number of your amps actually get closer to the ideal as they age when you add in the less than ideal tubes and wear on the speaker and variations in line voltage, etc and is kind of amazing these amps work at all after a decade or two. When it comes to tubes as long as you hit the dart board you are probably good.
About a year ago I submitted the book this is from, and a user, @fuzzfactor, offered to provide more relevant info on the linked section if desired (https://news.ycombinator.com/item?id=34299135). I saw that comment after the reply window closed, so I'm submitting just that section to hopefully catch their attention and generate some discussion on it.
Fux's Gradus ad Parnassum is something you can find. A lot of the partimento stuff was practical in nature, and consisted of some rules and several exercises. A great online source on Partimento and historical solfege:
Emacs has had AI since before it was cool again.
M-x doctor