Being Self-Reliant with Technology

Let’s talk about “self-reliance” as it relates to career and learning. The three aspects of this we’re going to discuss are:

  • Research
  • Failure
  • Asking for Help


You’re sitting at your desk, and you’ve got a piece of code that isn’t working, or some other challenge… it’s not even technical! You’re stuck and you’ve run out of ideas, so you need to turn somewhere else for answers.

The first instinct of many people in this situation is to simply ask someone else, but I virtually guarantee that others have already done that, and you can likely find your answer on Google! Obvious, right!?

The problem many people encounter when turning to Google (or any form of research like this) is that they will try to be too specific in what they are looking for, and a lot of the time it will result in little to nothing being found. What you can do, instead, is search for variations of your issue - for example, take parts of an error message or the error code so that you can get a broad understanding of what you could be looking at.

For tech purposes, Stack Overflow is a common resource that people will turn to directly, or which will come up in searches. Very frequently, you’ll find an answer to your question on Stack Overflow, but it may not be the answer. By this I mean that the solution you find may work, but it may not be the most efficient way to address the problem.

The goal of your research should not only be to find an answer, but to learn from the plethora of information you find so that you can determine the best approach forward.


Next up, we’re going to about failure.

Isn’t this what got us here to start!? Yes, but it’s also the best way to learn!

Continuing with the example of some broken code - you’ve now done some research, found ten or twenty different ways to code around the problem, and now you need to implement those and find out:

  • Do they work?
  • Which is the best for your purposes?
  • What can you change to make it work even better?

It may seem intuitive that you want to test your code before using it in the real world, but this meme exists for a reason:

test in production

Work in your local (or cloud based) development environment, break things until you find what works best!

Asking for Help

We’ve done research, and now we’ve tried, and failed, to solve the problem. On the plus side, we’ve learned a ton about the situation and some ways to address and avoid similar problems in the future, but are still stuck… it’s time to ask for help!

Yes, you could have started out with this, but the reason it’s the last step is that the goal here isn’t only to solve a problem - it’s to learn from solving it. The great part about having done your research, and having tried things, is that you’ve not only saved yourself time in the future but you’re going to save time for the person you’re going to be asking as well.

The first questions that you will get almost every time when asking for help are “What’s the issue, and what have you tried?”.

By having tried many things and researched before involving someone else and using their time, you can answer this with an educated statement around what has not worked, what may have gotten you part of the way toward an answer, and what you think might be the path forward.

Chances are that the person you’re asking for help already is going to follow, or already has in their past experience, the exact same steps here. It’s due to this experience, that you’re now trying to build, that you’ll be able to work together to get a quick and good solution.


I know this all seems like it’s common sense, but you’d be surprised at how many people skip this process and just jump to asking other people - especially skipping the “Failure” after not finding an exact answer after some preliminary research. At the end of the day, yes, getting your solution was slower than just asking, but think of all of the time that you’ve now saved yourself in the future, as well as the time that would have been working through these same steps with someone else.