The big secret about “tech people”, fixing things and how to control your technology

The big secret about “tech people”, fixing things and how to control your technology

Hardik Gandhi   January 15, 2018

Hint: it’s neither hard nor dangerous

In this article, I’d like to talk about the “divide in technology” and how you can become proficient at solving tech problems even if you have never done it before.

The Gap

There is a fundamental divide in how people deal with tech problems. It seems that some people see computers, smartphones and other technical devices as “black boxes”, most of the time doing what they want, but at times showing frustrating errors or just plainly stopping to work.

Others (with a winking eye referred to as “tech people”) see those devices as a system of parts: hardware, software and things that run on the internet. While errors and failures are certainly annoying, they are merely symptoms that some part of the system is malfunctioning. And since it’s technology, the various components can be fixed.

The difference between those groups is that the first group is intimidated by technology — you might hear someone say “Oh, he (the computer) doesn’t like me”, as if it’s a personal thing and the technological system can be blamed. The other group doesn’t put the blame on the system as a whole, vicious entity, but instead treat it as it is: a collection of parts.

It’s no shame to belong to group one, after all, technological education and systems thinking is rarely taught and if you never had someone else introduce you to the topic, you were likely never exposed to the ideas behind it. However, I encourage you to read on and discover it’s quite easy to understand and to switch over to the “tech” side in no time.

Why should you do this? Because it gives you power and control over the things you own. You are absolutely capable of fixing and repairing both software and hardware problems, once you understand the basics. And each time you succeed in fixing something, you will gain confidence and experience. Plus, it’s actually pretty fun.

Everything is just a collection of parts

As mentioned in the intro, every piece of technology is a quite elaborate collection of parts, divided into hardware and software. The hardware is the actual thing that you carry around, most of the times small boards or chips that fulfill a certain function.

Two good things: those components are similar on almost all systems (I’m talking about computers, tablets and smartphones).

They all have a processor unit (doing the computations), a permanent storage (where all your photos are for instance) and a temporary storage (supplying the files that are in use right at the moment to the processor).

Those three are absolutely necessary for the basic functions. Then, of course, you have things that support everything else: batteries, screens, sensors, input devices (keyboards, trackpads), wireless chips and a series of boards connecting everything together.

The second good thing is that you don’t need to understand how each of those components work (or even how the system works at all) and you can still fix the system as a whole.

On top of this, there is software: an operating system and applications running on this system. Again, you don’t need to understand how this all works, just be aware of its existence.

Have you tried turning it off and on again?

It seems like a tired old joke, but it’s quite true. More than half of all errors on almost all systems can be “fixed” by turning off the system and restarting it.

This allows the system to begin with a blank slate, it reloads the software and starts all calculations afresh.

It is truly the one thing that a “tech person” will do first when trying to fix a problem. Switch everything off (completely, ideally also disconnect the power), then back on. You will be surprised how many errors are never showing up again! This technique can be adapted to resetting and reinstalling software, but we’ll get into that in a later article.

Turn it off. Turn it back on. Fix most of your errors.

You can’t really break something

I find that most of the time, people are not trying to fix things because they are afraid to damage those things permanently.

Another good thing (this article is full of positivity): you can’t really break something as long as you don’t physically break part of the system. Keeping your technology dry and reasonably clean is a good way to start.

It’s also quite unlikely that you damage your software beyond repair. Rest assured that there is almost always a way to completely reset everything. Which brings us to the next point and then we will go into the details.

Store your files securely

As mentioned above, your files are stored on the permanent storage (hard drive) of your device. Luckily, in the last decade it has gotten incredibly easy to also store all your files in the “cloud”, meaning a separate computer somewhere on the internet, owned by a company.

The most famous of these services, like Dropbox, iCloud, GoogleDrive and OneDrive are reliable and widely used, while alternative might be suited to special needs.

I won’t go into any detail on how to choose the best service, you should be fine with typing “best cloud storage providers 2018” into Google.

The point is: while I said you can’t break anything on your system, you might lose your files, programs, settings and achievements if you don’t save them on another device first.

Use a cloud storage, external hard drive or another computer to move important documents out of your system for the time of the repairs.

Things change, for better or for worse, it’s never just you

You know the saying: never change a running system. Many software developers don’t seem to heed this, they are constantly updating, improving, iterating and changing.

Most of these changes are benign, while sometimes they break the very thing that you rely on for your work. It is annoying, it costs energy and time.

Yet, we all have to accept it, sort of the price we pay for getting accelerated technological progress.

And despite the myriads of different technological configurations, operating systems, smartphones and programs there are, there is a high chance that someone, somewhere has already had the same problem and found a solution and shared it with the world.

Which brings us to…

The big secret

This is the big one. The secret you have been waiting for. How do “tech people” actually fix things?

The answer, of course, is a simple process.

They google the error and then follow whatever other people have tried.

Yes, that’s all. That is how most of the errors get solved and how most things get repaired and in fact, how most things are learned.

You just google what you are trying to do and then spend some time going through the answers. It might not be the first answer that helps you, but chances are that somewhere in the first five answers, something will.

The art is within the right phrasing of the question. I’ll walk you through an example: recently, my 3D software “Blender” started to display black boxes instead of the usual interface. It was mildly annoying, so I tried to fix it.

Here is how you construct the google query: type the program name first, then add a short and succinct description of what’s wrong. For instance: “blender 3d displaying black user interface”. Here is what Google gives me:

Click on the first answer.

And I simply go to the first answer, which is a site called stackexchange.com. It is a platform/ community where lots of tech questions are answered and it is quite trustworthy. Reading the question that someone else asked, I think that they have the same issue. And behold, below there is an answer.

Turn off nVidia shadowplay, thanks J. Larsen!

I know that shadowplay is a program for my graphics card, so I turned it off.

It fixed the issue, no more black boxes.

If I didn’t know how to turn it off, guess what: I’d google it (“turning off nvidia shadowplay”). There are tutorials for everything online.

This principle works with any error message, too.

Just don’t click it away angrily, look at it, read it and if you don’t understand it, copy the exact words into Google, combined with the software from which it came, for instance “windows 10 error 0x80200056”. It looks like gibberish and I have no clue what it means, but other people do!

Put it into Google, read the first answer (like seriously, read it like a really good recipe) and follow it.

Remember, you are quite unlikely to break anything, so just follow the steps.

And then there is this case:

https://imgs.xkcd.com/comics/wisdom_of_the_ancients.png

Yes, there is a chance that your problem is absolutely rare and unique. It happens to all of us. We live with it. We reinstall the whole system. We buy a new computer. But we can always say that we tried.

I’ll probably go into a little more depth on this next week, but for now, you have a basic understanding of your tech!

The more you fix and try and change, the more confident you will become.

Soon, you will be one of the “tech people”.

JavaScript — Shorthand Variable Assignment

JavaScript — Shorthand Variable Assignment

Hardik Gandhi   January 10, 2018

A three minute introduction into shorthand variable assignment

This article will take a (very) quick look at shorthand variable assignment in JavaScript.

Assigning Variables to Other Variables

As you’re probably aware, you can assign values to variables separately, like this:

var a = 1;
var b = 1;
var c = 1;

However, if all variables are being assigned equal values, you can shorthand and assign the variables like this:

var a = b = c = 1;

The assignment operator = in JavaScript has right-to-left associativity. This means that it works from the right of the line, to the left of the line. In this example, here is the order of operation:

• 1 — First, c is set to 1.
• 2 — Next, b is set equal to c which is already equal to 1. Therefor, b is set to 1.
• 3 — Finally, a is set equal to b which is already equal to 1. Therefor, a is set to 1.

As you can now see, the shorthand above results in a, b, and c all being set to 1.

However, this is not a recommended way to assign variables. That’s because in the shorthand variable assignment shown above, we actually never end up declaring variables b or c. Because of this, b and c wont be locally scoped to the current block of code. Both variables b and c will instead be globally scoped and end up polluting the global namespace.

Using Commas When Assigning Variables

Lets look at a new example. Consider the following variable declarations and assignments:

var d = 2;
var e = 3;
var f = 4;

We can shorthand this code using commas:

var d = 2, e = 3, f = 4;

As you see, we are separating each variable assignment with a comma which allows us to assign different values to each variable.

For ease of reading, most coders who prefer using the comma method will structure their variable assignments like this:

var d = 2, 
    e = 3, 
    f = 4;

Best of all, in the shorthand variable assignment shown above, we are declaring all three variables: d, e, and f. Because of this, all variables will be locally scoped and we’re able to avoid any scoping problems.

---

Want to Learn More Shorthands?

Check out my other articles on shorthand coding techniques in JavaScript:

• JavaScript — The Conditional (Ternary) Operator Explained
• JavaScript — Short Circuit Conditionals
• JavaScript — Short Circuit Evaluation

Closing Notes:

Thanks for reading! If you’re ready to finally learn Web Development, check out: The Ultimate Guide to Learning Full Stack Web Development in 6 months.

If you’re working towards becoming a better JavaScript Developer, check out: Ace Your Javascript Interview — Learn Algorithms + Data Structures.

Why people shouldn’t learn to code

Why people shouldn’t learn to code

Hardik Gandhi   January 10, 2018

As a scholar, I like arguing against myself. Thesis, anti-thesis, synthesis: the Hegelian dialectic can be one of the more productive and entertaining paths to truth.

And so, in this post, I attack the central thesis of my research: that the ability to program a computer, and the computational thinking that can come with it, is a power that must be democratized.

Why do I believe this? I believe that a severe concentration of power nearly always leads to injustice, and justice is one of my core values. That only 20 million people write the software that shapes the digital experiences of the 7.5 billion people on Earth is concentration of power second only to global income inequality. My research aims to lower the barriers to acquiring the power to code, which I hope will more evenly distribute this power, which in turn will reduce injustice.

Agree with me? Great! But that’s no fun. And it leaves this position open to attack, with no sense of how robust it actually is. My position might even be wrong.

So let’s consider three anti-theses to my thesis.

Ability is an arms race

One critique of my thesis is that the ability to code is an arms race. No matter how easy we make it to learn to code, this greater ease will only amplify the abilities of those who already could. The privileged few who learn to code now will learn younger and faster. All of those talented new engineers that didn’t have jobs before still won’t get jobs at Google because everyone else will be that much more talented. No matter what we do, power will remain concentrated, because the underlying social structures that protect that power will remain unchanged.

This is an instance of Kentaro Toyama’s argument about technology as an amplifier rather than a catalyst of social change. The argument is that technology of any kind, whether a learning technology, a better pedagogy, a simpler programming language, or a better developer tool, will only intensify whatever social structures exist. It’s up to us to change our behavior, our values, and ultimately, our institutions, if we want to redistribute power. More effective learning will not.

Software is evil

Another critique of my thesis is that the software itself is a net loss for humanity. Communication technologies have eroded our relationships, democratization of publishing has eroded truth, platforms have eroded innovation, and automation has eroded our livelihood. There may be some good things that come from digitizing information and automating decisions, but on the whole, they take more than they give. We should therefore have less software, not more, and so we should have fewer people that can code, not more. Like nuclear weapons, we should use software sparingly, if it all.

This argument abounds in pop culture of today. As all dystopian sci-fi has for a century, Black Mirror is popularizing this position, portraying how even small changes in how we use software can lead to plausible and horrifying outcomes.

Software is dangerous

One of the critiques I’ve heard most is the idea that software is too powerful to be democratized. As in medicine, engineering, and law, some knowledge should be regulated, only accessible to people with appropriate training. The risk of allowing everyone have the ability to code is that we increase harm. And perhaps were already seeing the result of unregulated access to the ability to code: software fails, people die. In fact, I analyzed 30 years of software failures reported in the news, finding that about once per month, the news reports at least one death, injury, or threatened access to food or shelter due to software problems. Is all of this faulty software really worth this increasingly frequent harm?

Some countries such as Canada do regulate software engineering. These efforts are often poorly implemented and premature, but not necessarily wrong in principle. We don’t want a billion people to know a little bit about heart surgery. Why would we want a billion people to know a little bit about software development?

---

Now, to synthesis. How can we reconcile these conflicting stances?

All four of these arguments have a kernel of truth. The small number of developers in the world really do concentrate power, and that does lead to injustice like algorithmic bias, poor software accessibility for people with disabilities, and innovations that primarily serve the privileged classes that created them. And yet, software does cause harm and can be evil. It’s entirely possible that by helping more people learn to code, we’ll just end up with more people with brittle knowledge of how to create software, more bad software, and the same people in power.

The fatal flaw that puts these positions in conflict is that none of them make explicit who will learn to code and what they will do with that knowledge. I envision a world in which a vast majority of educated people understand enough about code not to become engineers, but to advocate for justice. Some of those people will become software engineers, but they will be different, more diverse people, who represent society, unlike the engineers we have now. This larger group won’t make any more software than we would have made otherwise (and therefore won’t cause any more harm or evil than we would have had otherwise). Rather, this new majority of computationally literate citizens will be a political force that demands justice.

This literacy could not be more pressing. For the next century, we will be heavily debating net neutrality, privacy, the regulation of automation. We will be trying to parent in the presence of social media. We will be trying to make objective journalism sustainable and desirable. We need every parent, politician, and person in power to understand what code is and what it isn’t. And we need the 20 plus million developers in the world to reflect everyone, so the software they create serves everyone.

The other fatal flaw in all of the positions above is that they don’t make clear what “learning to code” means. What does everyone need to understand about software to be in a position to advocate objectively? It’s not necessarily knowing a programming language. It might mean knowing what programming languages are and are not capable of. It might mean understanding the intersection between computing and policy. It might mean understanding how software is engineered and who engineers it, so everyone can comprehend what any particular policy proposal they’re voting on would actually mean in practice. Some of these ideas have made it into our curricular standards and assessments, but most have not. We need to understand what this knowledge is and invent ways of teaching it effectively.

Software is not going away. It will continue to be evil and dangerous. It will continue to bring joy and prosperity. But it will not bring social change, and it will not provide universal access to knowledge about computing. That’s up to us.