Ask HN: How deep do you go?
When you’re learning about a new topic or technology that you want to incorporate into your workflow, how do you know how to scope the learning and when to stop?
46 comments
Everyone learns a new thing and it seems magical. We tend to over-apply it while we're finding its limits. So I try to do that intentionally, up-front, when there's nothing at stake.
I plan to fail. As spectacularly as possible. Then I have to figure my way out of it - time to finally read those docs in detail!
I usually try to do a (toy) project that seems ridiculous. I try to misapply the tech if possible to some domain it's unfit for. Finishing the project isn't important. I just need to fail a lot and learn.
Once I stop failing so often or once the failures are smaller, that means I'm familiar enough to not embarrass myself too much.
I plan to fail. As spectacularly as possible. Then I have to figure my way out of it - time to finally read those docs in detail!
I usually try to do a (toy) project that seems ridiculous. I try to misapply the tech if possible to some domain it's unfit for. Finishing the project isn't important. I just need to fail a lot and learn.
Once I stop failing so often or once the failures are smaller, that means I'm familiar enough to not embarrass myself too much.
this is what makes all of my side projects so much fun and so educational.
I get caught up in the most ridiculous yak shaving and never make any real progress.... but always have a blast.
I get caught up in the most ridiculous yak shaving and never make any real progress.... but always have a blast.
I totally agree with this too! Sometimes its nice to have a project that's meant to go nowhere, but it teaches you a ton and you get a lot of that yak shaving out of the way.
By the end you might have so little to show, but I found writing down what I learned a great way to "mark" the project with a healthy milestone :)
By the end you might have so little to show, but I found writing down what I learned a great way to "mark" the project with a healthy milestone :)
Minsky labelled our minds "difference engines". This means,
we work best with a goal. The moment some sort of goal is
set, the mind keeps diffing goal and your current position
continuously. Given this framework, I always tend to have
a higher goal, some result I hope to see. With such context,
then it is simply a matter of asking "is it working now? am I there yet?".
If it is not, learn more. If it is, then I sort of know enough.
And if I have a stronger urge, I may go on a curiosity-ride
for as long as (economically) possible :)
Breadth first thinker here: Understand the jokes, these are the edges and shape of its applicability, and mnemonics for its concepts. Get very good depth first in a few other foundation areas so that you know what discipline and rigor of real depth looks like, figure out how to identify people who also have depth in something, and then use their minds to scale yours.
I have absolute respect for depth of skills, and arguably even a rare appreciation for them, but with the caveat that there are diminishing returns and limited scalability on them, and this is the problem I typically index on solving. That is to say, I often tell people deadpan (to the point of it almost being my catchphrase), "I don't know very much, but I have opinions about everything."
I have absolute respect for depth of skills, and arguably even a rare appreciation for them, but with the caveat that there are diminishing returns and limited scalability on them, and this is the problem I typically index on solving. That is to say, I often tell people deadpan (to the point of it almost being my catchphrase), "I don't know very much, but I have opinions about everything."
0. Is it interesting to me and has useful applications? As deep as possible while still gaining new applicable knowledge.
1. Is it really interesting to me but no, or few, applications? Then I won't stop until I hit a wall. Then I rotate out topics to avoid frustration, potentially abandoning some paths if they're just too much for self-study with no application.
2. Is it useful to me (professionally or personally) but less interesting? Until I hit a point where there is little to gain from deeper study.
1. Is it really interesting to me but no, or few, applications? Then I won't stop until I hit a wall. Then I rotate out topics to avoid frustration, potentially abandoning some paths if they're just too much for self-study with no application.
2. Is it useful to me (professionally or personally) but less interesting? Until I hit a point where there is little to gain from deeper study.
It depends, I think I go deeper than most people. Mostly it's intuition and curiosity based, but trying to reverse engineer what I do...
There are usually a lot of abstraction layers, all of them leaky to differing degrees. I like to have a broad picture of the big abstraction layers pretty much all the way down, and then details proportional to how much they manage to bubble up through the abstraction layers.
For example if I was trying to teach someone how to program in a reasonably high level language (rust, python, etc). I'd (eventually) want them to know that assembly and machine code exists - if we're talking about python also that bytecode exists, but I definitely don't care if they know how to read/write it because there's a strong abstraction layer between the language and the concrete machine. On the other hand I'd (eventually) want them to know not just that file handles exist, but that they're integers allocated by the OS and how syscalls work with them, because the abstractions on top of file handles are quite leaky, and it's often useful to understand what they are when looking at various forms of debug output (especially strace output).
And this is a luxury. If you're learning a technology that you need to use immediately, skip out learning on things deeper in the stack until you have free time and are already productive. Even if you're not in a hurry, generally learning lower level things is motivated by wanting to know how the higher level things work.
There are usually a lot of abstraction layers, all of them leaky to differing degrees. I like to have a broad picture of the big abstraction layers pretty much all the way down, and then details proportional to how much they manage to bubble up through the abstraction layers.
For example if I was trying to teach someone how to program in a reasonably high level language (rust, python, etc). I'd (eventually) want them to know that assembly and machine code exists - if we're talking about python also that bytecode exists, but I definitely don't care if they know how to read/write it because there's a strong abstraction layer between the language and the concrete machine. On the other hand I'd (eventually) want them to know not just that file handles exist, but that they're integers allocated by the OS and how syscalls work with them, because the abstractions on top of file handles are quite leaky, and it's often useful to understand what they are when looking at various forms of debug output (especially strace output).
And this is a luxury. If you're learning a technology that you need to use immediately, skip out learning on things deeper in the stack until you have free time and are already productive. Even if you're not in a hurry, generally learning lower level things is motivated by wanting to know how the higher level things work.
I think for me it depends on whether it is something that I kind of need and therefore I have to learn enough about it vs one that I might be considering as 1 choice of many that I am not tied to.
In the first instance, I try and build a simple but complete model to ensure that there aren't any gotchas. For example, I am looking at Hashicorp Vault. It does a number of things that will be useful and which all need to happen. I will spend some time, therefore, getting one example of each of those working. This will prove the docs are good, there aren't any weird limitations and it is something I can work with.
If, on the other hand, I am only evaluating something, I can very easily drop it just because of some poorly maintained docs or an error in the first 5 minutes after following the installation instructions.
Like another poster, I then try and keep the breadth as narrow as possible so I am not learning things I don't need, but using my experience to spot things that might need some more careful learning. For example, I quickly spotted that K8S default networking was very open so I invested more time working out options for having it more locked down.
In the first instance, I try and build a simple but complete model to ensure that there aren't any gotchas. For example, I am looking at Hashicorp Vault. It does a number of things that will be useful and which all need to happen. I will spend some time, therefore, getting one example of each of those working. This will prove the docs are good, there aren't any weird limitations and it is something I can work with.
If, on the other hand, I am only evaluating something, I can very easily drop it just because of some poorly maintained docs or an error in the first 5 minutes after following the installation instructions.
Like another poster, I then try and keep the breadth as narrow as possible so I am not learning things I don't need, but using my experience to spot things that might need some more careful learning. For example, I quickly spotted that K8S default networking was very open so I invested more time working out options for having it more locked down.
I research everything that i can about the topic for say couple of days. Then i pick a tutorial or boilerplate, modify it in my own way to learn how it works (and more importantly - why things are why they are).
Once it stops crashing, i try to slowly refactor it for my use case. Crucial part is not taking too big chunks that you lose focus and not getting stuck on irrelevant things. It can get messy but as long as you have loaded it up in your work memory, it should be ok. Later i'll rewrite everything once i understand the domain better.
Once it stops crashing, i try to slowly refactor it for my use case. Crucial part is not taking too big chunks that you lose focus and not getting stuck on irrelevant things. It can get messy but as long as you have loaded it up in your work memory, it should be ok. Later i'll rewrite everything once i understand the domain better.
I'm a depth-first learner. I prefer to have the time and focus to learn as much as possible about a new area, as deeply as possible, and in one "chunk".
Obviously sometimes that isn't well-supported by my immediate needs. In those cases I tend to be incremental - I work on the problem that I need to solve until I run into a roadblock. I solve that roadblock and continue until the next one. This approach makes it more difficult to estimate "time to completion", but it's proven to be most efficient for me so far.
Obviously sometimes that isn't well-supported by my immediate needs. In those cases I tend to be incremental - I work on the problem that I need to solve until I run into a roadblock. I solve that roadblock and continue until the next one. This approach makes it more difficult to estimate "time to completion", but it's proven to be most efficient for me so far.
Being a results merchant, I go only as deep as I need to in order to get results.
If the result needs improving, then I have a target to go deeper into. This keeps me from investing in unused knowledge. I find its turtles all the way down, so just tackle what you need.
One of my bosses/clients was struck by my being neither a bottom-up nor a top-down person, but more of a come at it sideways type.
How broadly and deeply I go depends on how well I know a topic already. The less I know, the broader and deeper I go, in a not-particularly-predictable way, until I feel like I just went past the point where I could have taken action.
At that point, I have a glom of unconnected data and factoids. Then I do something (code, cut, brew, cook, wheel, weld, bend, hammer, whatever), with every expectation of failure and every hope for at least a step forward.
Then something doesn’t pan out and the failure crystallizes knowledge.
Until going hands on, I had no context to appreciate what part of breadth or depth was practical, what was theoretical, and/or what was background/historical.
Suddenly confronted by practical problems, I backtrack up and in, sort of, to find paths that I can evaluate as to utility, whether to the immediate task or to a firm theoretical foundation.
Lather, rinse, repeat, until things start to take shape and I start to understand the subject.
How broadly and deeply I go depends on how well I know a topic already. The less I know, the broader and deeper I go, in a not-particularly-predictable way, until I feel like I just went past the point where I could have taken action.
At that point, I have a glom of unconnected data and factoids. Then I do something (code, cut, brew, cook, wheel, weld, bend, hammer, whatever), with every expectation of failure and every hope for at least a step forward.
Then something doesn’t pan out and the failure crystallizes knowledge.
Until going hands on, I had no context to appreciate what part of breadth or depth was practical, what was theoretical, and/or what was background/historical.
Suddenly confronted by practical problems, I backtrack up and in, sort of, to find paths that I can evaluate as to utility, whether to the immediate task or to a firm theoretical foundation.
Lather, rinse, repeat, until things start to take shape and I start to understand the subject.
I start with wikipedia or the intro to the documentation. Then I read deeper on whatever seems interesting until I think I know enough to be productive.
Then I start using it. If I get stuck, I find more specific information until I'm not stuck. Rinse and repeat.
So in short, I read the smallest amount of info possible to start and then let my practical experience guide me after that.
Then I start using it. If I get stuck, I find more specific information until I'm not stuck. Rinse and repeat.
So in short, I read the smallest amount of info possible to start and then let my practical experience guide me after that.
As deep as I have to.
Usually, I know in advance what I want to build with the new technology and what quality level my customer needs. I'm always super impatient to try new knowledge out in practice. So I'll learn for a day, then try it out in the evening. And then I only go back to learning as long as the results are still too bad to solve my problem.
Usually, I know in advance what I want to build with the new technology and what quality level my customer needs. I'm always super impatient to try new knowledge out in practice. So I'll learn for a day, then try it out in the evening. And then I only go back to learning as long as the results are still too bad to solve my problem.
Optimize for engagement. Are you engaged with the topic? Keep going. Are you bored/way over your head? Try to find something else in the field that's more engaging.
To be honest, I find that this idea is really underappreciated.
To be honest, I find that this idea is really underappreciated.
Helpful rule of thumb: understand at least the level below the one you’re working on in good detail - that is, how it does what it does, not just what it can do.
It helps you understand the shape of what is possible, debugging becomes far easier and sooner or later you will probably have to fix it anyway, or live with horrible inelegant workaround at your target level of abstraction.
I’ve never regretted going deeper; being able to keep going down all the way into the kernel is a superpower. But I’ve often regretted not going deeper earlier.
It helps you understand the shape of what is possible, debugging becomes far easier and sooner or later you will probably have to fix it anyway, or live with horrible inelegant workaround at your target level of abstraction.
I’ve never regretted going deeper; being able to keep going down all the way into the kernel is a superpower. But I’ve often regretted not going deeper earlier.
I use a concept called timeboxing combined with deep work. If you wanna learn something, estimate, how much time you gonna need, how much time you really have a day and then split the estimation into timeboxes of at least 1h, better 2h or even more.
Focus on your work / task and if you finish early and are still interested, dig deeper. If not, stop as soon as you get where you want to.
Works pretty well, but Focus is the main point. No tiktok, youtube, twitter, smartphone or whatever ;)
Focus on your work / task and if you finish early and are still interested, dig deeper. If not, stop as soon as you get where you want to.
Works pretty well, but Focus is the main point. No tiktok, youtube, twitter, smartphone or whatever ;)
No general rule for me, just combination of needs and interests, if I like something, I have time, I dig, if I need something I dig, if at a certain point my will start waning or my needs have reached a certain satisfactory point I stop.
As a general rule: there is no too much knowledge. The trick is just avoid dispersion, concentrating on something leaving something else aside. And there is no magic formula IME for that...
As a general rule: there is no too much knowledge. The trick is just avoid dispersion, concentrating on something leaving something else aside. And there is no magic formula IME for that...
I will read the full surface-level of the docs just so I understand all the nouns and verbs. It's okay if I don't understand something at this stage - it's all about learning the existence of unknown unknowns. Just need to get them to known unknowns.
Once I have the outline of the possibility space I start to dig in on the topics that seem most relevant for my objective and try them out.
Once I have the outline of the possibility space I start to dig in on the topics that seem most relevant for my objective and try them out.
3 in the morning is a good top limit
When the birds are chirping, or I can't understand the code I'm reading anymore, I always say!
I usually try for 5 books or articles on the topic. I describe each of those in a blog below:
https://jondouglas.dev/five-to-thrive
Think of your progression as the following:
- I’m a little familiar
- I’m a bit more excited
- I’m seeing the big picture
- I’m understanding the main ideas & opinions
- I’m getting an idea of where the future is headed.
https://jondouglas.dev/five-to-thrive
Think of your progression as the following:
- I’m a little familiar
- I’m a bit more excited
- I’m seeing the big picture
- I’m understanding the main ideas & opinions
- I’m getting an idea of where the future is headed.
I get lost with a depth-first approach, so I aim for a broad superficial understanding and build from there as needed.
I would say never stop learning but also never stop practicing. I flip back and forth between study and coding (or music, or any other practice) to get some hands on in using what I just learned. Often, I stop in the middle of "real work" to learn something, or stop reading in order to try something.
It depends what you want in life.
For workflow stuff, I more or less do the generalized version of the xkcd Worth the Time (0). There's always initial friction bringing something new into a workflow, both from a learning and practice standpoint, which I treat as an expected upfront cost. But pretty much once I start spending more time (actively) learning about a tool than I get back in saved time, that's about the end for that workflow update. I can always revisit it if I hear about a new feature of the tool, and of course I'm passively picking up stuff as I use it.
(0) https://xkcd.com/1205
(0) https://xkcd.com/1205
If it's something I need to learn for work, I go shallow... because usually at work we focus on trendy buzzwords (e.g., k8s, graphql, protobuffers, etc.). So, it usually take me a few days to get the enough knowledge to keep pushing code to production.
If it's something I want to learn to satisfy my curiosity (e.g., Golang, TCP/IP, architectural patterns, linux kernel, etc.) it takes me months and I usually stop after building a couple of projects and after reading a couple of reference books.
If it's something I want to learn to satisfy my curiosity (e.g., Golang, TCP/IP, architectural patterns, linux kernel, etc.) it takes me months and I usually stop after building a couple of projects and after reading a couple of reference books.
Interestingly Jim Keller spoke about this on (I believe) the Lex Friedman podcast.
He said something along the lines of 'Most people are pattern matchers, they are good at applying known patterns to problems they face. However, the best people know when to pattern match, and, also, when to go deep and apply first principles thinking.'
He then cited Elon Musk as a great example of this.
He said something along the lines of 'Most people are pattern matchers, they are good at applying known patterns to problems they face. However, the best people know when to pattern match, and, also, when to go deep and apply first principles thinking.'
He then cited Elon Musk as a great example of this.
I don't learn "technologies", I chip away at "topics". For instance, when I learned OpenAPIv2 it wasn't because I wanted to use OpenAPIv2, it was because I wanted to solve some pains I was experiencing with managing multiple REST backend versions and I saw OpenAPIv2's architecture could help me decompose the painful areas. Knowing what you want to solve, or learn, is key to that, and just like regular projects can be subject to scope creep if you don't have strong boundaries for it.
I look for things that are immediately applicable to me.
A tangential example is to think about how Amazon Basics (household items) took over without any advertising (maybe shopping placement was privileged inside Amazon platforms though). It solved people's problems that were being dismissed as too basic to solve.
When I think about workflow adjustments, its usually one thing I'm looking for. If the solution has some other cool things about then, now I'm getting somewhat exposed to them too.
If its not immediately applicable, I'm not really prioritizing it.
A tangential example is to think about how Amazon Basics (household items) took over without any advertising (maybe shopping placement was privileged inside Amazon platforms though). It solved people's problems that were being dismissed as too basic to solve.
When I think about workflow adjustments, its usually one thing I'm looking for. If the solution has some other cool things about then, now I'm getting somewhat exposed to them too.
If its not immediately applicable, I'm not really prioritizing it.
If I just start learning, I don't stop until it's too late and I'm probably burnt out on the topic. If I have a goal but haven't started working on it, I study what I think I need to accomplish that goal until I think I understand or realize it's not what I needed in the first place. If I need to know something to complete a concrete task, I learn the very least I possibly can to do what I need to do, and return to learning if I fail, until I succeed.
I stop when I get bored. I have no conscious ability to regulate the way I seek out or use information. This has obvious disadvantages but also means I know lots of stuff.
I like going all the way.
I started brewing beer last year. Now I'm growing my own hops and grain. If that goes well, I'll be malting it and turning it into beer.
But generally, I only go as deep as I need for it to work. I only go deeper if there's a problem or a true interest.
I started brewing beer last year. Now I'm growing my own hops and grain. If that goes well, I'll be malting it and turning it into beer.
But generally, I only go as deep as I need for it to work. I only go deeper if there's a problem or a true interest.
Usually I'll learn until I've figured out the reason I started down that path in the first place. And then move on to the next shiny object until something breaks, then learn what I did wrong, fix, and repeat.
As deep as the rabbit hole takes me. Nowadays I became very picky as to what "new" thing I decide to incorporate into my workflow, so when something checks all the marks, I'll go all in.
On fun/personal learning, I go as deep as I want, until I decide it's far enough
For work/assigned learning, I go as deep as is either required or "seems" to be relevant to the task(s) as hand
For work/assigned learning, I go as deep as is either required or "seems" to be relevant to the task(s) as hand
I immediately play with it and slowly build up a prototype publicly so I get input from other engineers. I think a short feedback cycle on anything complex is key, so you don't over-invest.
As long as it's supported by Emacs then the world is your oyster.
If you know enough Emacs LISP, then everything is supported by Emacs.
Just deep enough to get the job done.
This requires that you have a real practical job to do in the first place.
Rinse and repeat with more and more difficult tasks.
This requires that you have a real practical job to do in the first place.
Rinse and repeat with more and more difficult tasks.
Definitely making the mistake all the time to go all in on a new topic :) But it is better to do it step by step and practice it.
Until I reach a point I find boring, like the technical details, unless it's one of my obsession points like ISA and OSDEV
tl;dr: Fundamentals, then just enough to get me through that next step.
In general, I take an iterative approach: learn the basic fundamentals for basic situational awareness, and then learn enough to get going, and keep learning as I encounter roadblocks.
Sometimes, if I feel like doing a massive deep dive into a topic, I generally allow myself to do so.
In general, I take an iterative approach: learn the basic fundamentals for basic situational awareness, and then learn enough to get going, and keep learning as I encounter roadblocks.
Sometimes, if I feel like doing a massive deep dive into a topic, I generally allow myself to do so.
More want to understand initially.
I aim for the center, and I know I'm done when there's nowhere left to go.
I aim for the center, and I know I'm done when there's nowhere left to go.
If I can’t connect it to what I consider my first principles, then I don’t really know it.
So all of the way, I guess.
So all of the way, I guess.
As deep as the situation requires. Then rabbit-hole about 5x beyond that.
Once you can do something practical and useful with it.
If you find out, let me know. :-)
I recognize that I get a dopamine hit from learning new things and so tend to just keep digging in. That said, for a lot of things, there seems to be very roughly three levels of "understanding";
1) Surface level - this describes the basic principles of the thing, how it relates to other things, and how it influences or is influenced by other significant things.
2) Engineering level - this level then has the information needed to develop a new thing, or modify an existing thing, or counter or enhance a thing. Sort of the fundamentals of the thing's makeup and/or construction and lets you find or make new things of a similar type.
3) Foundation level - this level then is where the nature of the thing, how it fits into the overall understanding of things in the universe and usually the process by which it's nature has come to be understood. This level will have a set of tools and processes that have evolved from the general set of tools to evaluate the nature of these things more specifically.
So level #1 is pretty easy and when I'm not thinking I'm going to contribute new original work to the topic or technology is where I'll stop if I'm just trying to use what ever it is to get something else done.
Level #2 is where I end up most often because I'm curious and learning something to that level can often inform how applicable it will be in other efforts. So if a technology is generally useful to a wide variety of applications I'll get down to this level, if it is pretty specialized for one kind of application, I'm less likely to go into its engineering.
Level #3 I don't go as often. The calculus is what will I learn vs what else could I have learned in the same time. My basic education focused on physics, electrical engineering, computer science, and some chemistry with the math necessary to support that. When level #3 is pushing into fields that are adjacent to that base like geology, biology, and philosophy I find there is a bigger hit to go back and pick up more fundamentals and that can be time consuming. So I have to ask myself do I really want to know this topic at a fundamental level or not?
But all of that to say that I am not a good role model here, I often spent more time learning about something than my employer's would like. A common experience in my work career was an increasingly irritated/impatient manager that I had not gotten "anything" done, followed by surprise that I had solved problems they didn't even know they were going to have. You don't get credit for knowing more than you "need" to know to accomplish a task. (Well I would give credit for that to people who worked for me, but it was rare that someone I worked for to credit that).
So two answers;
In your job, stop when you know enough to make progress to please your task masters.
In your life, never stop learning new things.
I recognize that I get a dopamine hit from learning new things and so tend to just keep digging in. That said, for a lot of things, there seems to be very roughly three levels of "understanding";
1) Surface level - this describes the basic principles of the thing, how it relates to other things, and how it influences or is influenced by other significant things.
2) Engineering level - this level then has the information needed to develop a new thing, or modify an existing thing, or counter or enhance a thing. Sort of the fundamentals of the thing's makeup and/or construction and lets you find or make new things of a similar type.
3) Foundation level - this level then is where the nature of the thing, how it fits into the overall understanding of things in the universe and usually the process by which it's nature has come to be understood. This level will have a set of tools and processes that have evolved from the general set of tools to evaluate the nature of these things more specifically.
So level #1 is pretty easy and when I'm not thinking I'm going to contribute new original work to the topic or technology is where I'll stop if I'm just trying to use what ever it is to get something else done.
Level #2 is where I end up most often because I'm curious and learning something to that level can often inform how applicable it will be in other efforts. So if a technology is generally useful to a wide variety of applications I'll get down to this level, if it is pretty specialized for one kind of application, I'm less likely to go into its engineering.
Level #3 I don't go as often. The calculus is what will I learn vs what else could I have learned in the same time. My basic education focused on physics, electrical engineering, computer science, and some chemistry with the math necessary to support that. When level #3 is pushing into fields that are adjacent to that base like geology, biology, and philosophy I find there is a bigger hit to go back and pick up more fundamentals and that can be time consuming. So I have to ask myself do I really want to know this topic at a fundamental level or not?
But all of that to say that I am not a good role model here, I often spent more time learning about something than my employer's would like. A common experience in my work career was an increasingly irritated/impatient manager that I had not gotten "anything" done, followed by surprise that I had solved problems they didn't even know they were going to have. You don't get credit for knowing more than you "need" to know to accomplish a task. (Well I would give credit for that to people who worked for me, but it was rare that someone I worked for to credit that).
So two answers;
In your job, stop when you know enough to make progress to please your task masters.
In your life, never stop learning new things.
About six inches.
The Church of the Subgenius has a useful concept called the "Short Duration Personal Savior" (or ShorDurPerSav, the proper Tibetian term):
https://subgenius.fandom.com/wiki/ShorDurPerSav
>In the Church of the SubGenius, SubGenii often worship Short Duration Personal Saviors (ShorDurPerSavs). ShorDurPerSavs offer all of the features and services of regular personal saviors, but are disposable. Thanks to their planned obsolescence, no SubGenius worships the same ShorDurPerSav for very long before switching to another one. The most common ShorDurPerSav is J. R. "Bob" Dobbs, followed by Connie Dobbs and then The Fightin' Jesus. Other common ShorDurPerSavs include Jehovah 1, Francis E. Dec, Eris Discordia, Adolf Hitler, Emperor Norton, The Bleeding Head of Arnold Palmer, Robert Anton Wilson, L. Ron Hubbard, Alien Sex Goddesses, Satan, the number 23, Barack Obama, and Cthulhu.
>[...]
http://www.subgenius.com/bigfist/goods/shordurpersavs/X0012_...
>From: Purple Kitty <[email protected]>
>-= SHORT DURATION PERSONAL SAVIORS - A LESSON =-
>BEGINNER LEVEL - CLEARED FOR ALL BOBBIES - BEGINNER LEVEL - CLEARED FOR
>Shockingly, some Bobbies are still unclear as to what a Short Duration Personal Savior is. The concept of the Short Duration Personal Savior (or ShorDurPerSav, the proper Tibetian term) is a new one-- traditional religions tend to emphasize "unwavering servitude" over convenience. But is absolute devotion to one savior always best? Buddha is a wonderful role model for certain aspects of life, but when that po'bucker shoves you out of the way as he walks by, don't you wish that you worshipped George Foreman instead, if only for the next few minutes?
>Well, you can! The Church of the SubGenius heartily endorses the concept of disposable saviors, or ShorDurPerSavs. Choose your messiah to fit the situation. If peace and compassion are what you need right now, follow the teachings of Gandhi. Later, when you need to cut a business deal, emulate the wisdom of Sam Walton. When you need a witty remark on the spot, let Samuel Clemens into your heart to inspire you. And when you need Slack in your life, sell your soul to "Bob".
>"Bob" is the most frequently invoked of our infinitely varied Short Duration Personal Saviors, with good reason. He has Slack--he IS Slack. He symbolizes the "easy life", where one follows the Path of Least Resistance and gains Slack effortlessly. But no one is expected to worship "Bob" 24/7! If you're trying to get that PC to work, choosing "Bob" as your ShorDurPerSav will hinder you far more than helping you! "Bob" couldn't use a PC if he wanted to (though he sold more of them last year than IBM and Packard Bell put together)! Read through Stephen Levy's _Hackers_ and let the TMRC be your ShorDurPerSavs! There ARE no limits!
>[...]
https://subgenius.fandom.com/wiki/ShorDurPerSav
>In the Church of the SubGenius, SubGenii often worship Short Duration Personal Saviors (ShorDurPerSavs). ShorDurPerSavs offer all of the features and services of regular personal saviors, but are disposable. Thanks to their planned obsolescence, no SubGenius worships the same ShorDurPerSav for very long before switching to another one. The most common ShorDurPerSav is J. R. "Bob" Dobbs, followed by Connie Dobbs and then The Fightin' Jesus. Other common ShorDurPerSavs include Jehovah 1, Francis E. Dec, Eris Discordia, Adolf Hitler, Emperor Norton, The Bleeding Head of Arnold Palmer, Robert Anton Wilson, L. Ron Hubbard, Alien Sex Goddesses, Satan, the number 23, Barack Obama, and Cthulhu.
>[...]
http://www.subgenius.com/bigfist/goods/shordurpersavs/X0012_...
>From: Purple Kitty <[email protected]>
>-= SHORT DURATION PERSONAL SAVIORS - A LESSON =-
>BEGINNER LEVEL - CLEARED FOR ALL BOBBIES - BEGINNER LEVEL - CLEARED FOR
>Shockingly, some Bobbies are still unclear as to what a Short Duration Personal Savior is. The concept of the Short Duration Personal Savior (or ShorDurPerSav, the proper Tibetian term) is a new one-- traditional religions tend to emphasize "unwavering servitude" over convenience. But is absolute devotion to one savior always best? Buddha is a wonderful role model for certain aspects of life, but when that po'bucker shoves you out of the way as he walks by, don't you wish that you worshipped George Foreman instead, if only for the next few minutes?
>Well, you can! The Church of the SubGenius heartily endorses the concept of disposable saviors, or ShorDurPerSavs. Choose your messiah to fit the situation. If peace and compassion are what you need right now, follow the teachings of Gandhi. Later, when you need to cut a business deal, emulate the wisdom of Sam Walton. When you need a witty remark on the spot, let Samuel Clemens into your heart to inspire you. And when you need Slack in your life, sell your soul to "Bob".
>"Bob" is the most frequently invoked of our infinitely varied Short Duration Personal Saviors, with good reason. He has Slack--he IS Slack. He symbolizes the "easy life", where one follows the Path of Least Resistance and gains Slack effortlessly. But no one is expected to worship "Bob" 24/7! If you're trying to get that PC to work, choosing "Bob" as your ShorDurPerSav will hinder you far more than helping you! "Bob" couldn't use a PC if he wanted to (though he sold more of them last year than IBM and Packard Bell put together)! Read through Stephen Levy's _Hackers_ and let the TMRC be your ShorDurPerSavs! There ARE no limits!
>[...]