I’ve made a few references lately to avoiding Jurassic failures. In some tech circles, including cryptocurrency projects, it seems very popular to make bad decisions and not claim responsibility. And yes, I’ve been writing and talking and thinking a lot about crypto this year. I’m not alone, but I’m the only one on this blog who you’d be able to make that observation about.
The Jurassic reference of course is to Jeff Goldblum’s character Dr Ian Malcolm in Jurassic Park.
Your scientists were so preoccupied with whether or not they could, they didn’t stop to think if they should.
The Jurassic Park reference is a bit more universal than the one I used to use, which was to Wangdi something. I had a Nepalese classmate in college named Wangdi, and the main thing I remember of him from those years was his disc soccer/disc golf prowess. Well, that, and the time he had someone spread three soccer discs in a throw which he would normally have caught with ease, but in this case he tripped over a sprinkler head about two steps into his run and faceplanted in the quad.
- Don’t always do things just because you can
Corollary: Don’t always do things just because you saw them on the Internet
2. Don’t try to start out at full speed; watch where you’re going and work your way up
Corollary: Set a reasonable plan and try to follow it. Don’t get distracted by squirrels
3. Plan to spend at least one minute for every $100 spent, learning how your item works
Corollary: If you can’t do that, don’t expect others to do it for you for free
Between these two warnings, you can take something away. First, don’t always do things just because you can (or because you saw them on the Internet). Second, don’t try to start out at full speed; watch where you’re going and work your way up.
And third is my One Percent Rule, not to be confused with Arthur Conan Doyle’s Seven Percent Solution. For every $100 you spend on an endeavour, spend at least one (1) minute learning or trying to understand it on your own before demanding help in free volunteer forums or from overworked support staff. So if you’re spending $3,000 on a GPU, but you’re not willing to spend 30 minutes learning how to use it, maybe don’t spend it. See also the first and second rules above.
How do these rules manifest in the real world?
I’ve seen someone enter support forums asking how to flash a BIOS, and two weeks later ask to be taught how to build a $10 million mining farm. Another had a similar trajectory, from “why didn’t I get paid out within a day of starting mining?” to “Help me set up a mining pool so my friends and I can share rewards.”
Neither of these topics is impossible, and I know people who’ve done $10 million datacenter deployments as well as mining pools. But neither is the sort of thing you go into from a standpoint of “I heard about this on the Internet, it’s cool, make it happen for me.”
Most of my readers will know you have to have some understanding of power, cooling, airflow, equipment density, maintenance, and a wide range of expenses involved with deploying any compute infrastructure, whether it’s streaming cat videos to the Internet, storing data in distributed databases or big data platforms, or mining Ethereum.
For the mining pools, it’s pretty easy to set up a full node, but to keep a platform going that serves end users (even if they know you; maybe especially if they know you) is going to require an extensive awareness of how the platform works, from the crypto coin network itself to the pool software to the client end software. I’ve supported two mining pools as a volunteer where I knew the pool operator (singular) and saw how much time he put into keeping it running.
And for the mining pools, it may sound like fun to create your own pool for a few friends, but it will probably reduce your rewards, rather than increase them. Like building a free hosting service, a mining pool is not for the faint of heart and you may set yourself and your friends up for disappointment if you don’t watch and learn before trying to make it happen.
Are you thinking of another list of three useful things, Robert?
In fact I am. Quite astute of you to perceive that, I dare say.
In dealing with support cases across the world of tech, I’ve found these three very useful recommendations to improve your experience as a recipient of support. Think about them before asking for help, and apply them to get the best possible result.
30 Seconds on Google #30secondsongoogle
If you’re looking for something, try searching for the answer first. You’re not as unique as you think you are. “Error 511” or “Windows disk 100%” or “overclocking RX580 ethereum” can likely get you the answer you’re looking for, and in many of these cases it’s not a matter of opinion, but of fact and experience.
I see this in Las Vegas and travel forums as well, with brilliant questions like “what will the weather be like on August 23, 2024?” or “How do I get from the airport to downtown?” or “Is there a Denny’s in Las Vegas?”
If you’re afraid to Google something, use DuckDuckGo or Bing.
Corollary (I like these corollaries): If you’ve gone to the effort of joining a forum, whether it’s Discord or Telegram or Facebook Groups or web forums, go the extra step and use the search function in that forum. Again, you’re not as unique as you think you are. And many questions, whether “What’s the best steakhouse” or “can I overclock my Zotac Ion video card” or “Can I use Windows drivers on Linux,” have been answered over and over.
Don’t ask to ask. Just ask.
I see people multiple times a day introducing themselves with “Is there an admin here?” or “I need urgent help” or just posting a screenshot and waiting. Don’t do that.
State your question or problem. Give the facts. Give screenshots if relevant (preferably not screenshots taken with a potato). And of course, mention what you’ve changed recently, or what has changed recently, since that’s usually an element… whether it was a software upgrade, a new power supply, a magic command you saw on a TikTok video, etc.
Corollary: Don’t ask vague undefined questions like “is it good” or “is it normal” or “what should I buy.” Good and normal are vague, especially when they’re referring to one of a dozen or a hundred candidates for normal. And in the tech frame, asking what computer or GPU you should buy is like asking what vehicle you should buy. Without more details, there is no right answer.
Respect the helpers.
This is somewhat self-serving, but in many cases you are asking for help from other users like yourself, most of whom are volunteering their time to help you, often because you didn’t observe the five items above. If you put in a little bit of effort, they’ll likely more than match it, but if you get annoyed because they’re asking questions that you don’t want to answer, think about why they’re asking. There are a couple of questions I see on the mining channels several times a day, and at least half the time I can tell you the answer before you even get the second sentence out, because I’ve seen the issues and know what almost always solves them.
I can’t speak for all volunteers, but I help out because I like to share my knowledge, and sometimes I even learn something from helping someone out with an adjacent problem. I don’t get paid to do it, and I don’t work for the organization whose products and services you’re desperate for help with. But you’re more likely to get a timely response if you work with me or another of the dozens, hundreds, or even thousands of other community members, rather than demanding dedicated 1:1 attention from one of a tiny number of admins.
Where do we go from here?
I want to acknowledge my friend Tom Hollingsworth here, who has nothing to do with this post’s content. He wrote a couple of weeks ago about his planned consistency for blogging which he’s mentioned before, and which I’ve occasionally Wangdi’d on trying to emulate. But if you’re thinking about blogging, or making videos, take a look at how his plan comes about, and see how it works for you.
I have a bad habit of keeping blog posts in three places.
At least 60% of them are in my head. The Chia blog I wrote earlier this week was bouncing around for over a week. I’ve had others that take weeks or months to move to the next stage.
About 20% of them are in my drafts folder.
Maybe more than 20%, but some of those have staled out, and some are duplicates that I reformatted and posted already. In any event, I’ll get the spark to write on the keyboard rather than the highway, and get something out, and usually come back and push them out into the world.
The other 20% are what you see here and at rsts11travel. Things that I’ve either been internally motivated to write, or had someone light a fire under my butt and inspire me to finish and push out. Again, the Chia post was one of those, with a friend mentioning that he hadn’t seen anything relatively simple about Chia yet. I wrote that, in about two hours of stream-of-consciousness from the 60% bucket, and have a few items of feedback to incorporate.
I want to shift about 20% toward the blog in the coming weeks. I have some Tech Field Day content to share, as well as continuations of a couple of Fall 2020 series that I never got the last episodes posted.
Is there something you’ve heard me talk about that you’d like to read more on? Or something you think I should check out? If so, leave a note in the comments. Same if you have suggestions for getting content flowing.
Pingback: Setting Yourself Up for Success in Tech - Gestalt IT