Why should you use processes just as the computer

Over the years, we have written many guides about how to use your computer to do cool things (according to our definition). In all of that time, however, we didn’t pay much attention to how to use those guides or any technical reference material. We assumed that readers would have the necessary knowledge to use resources such as mine.

However, assumptions can have serious consequences. Even the most comprehensive guide can be susceptible to pesky variables if it is not built on solid foundation. It is impossible to cover all of them, so if you have enough time and enough tinkerers, anyone can hit a snag. Their cognitive toolset is all they have at the moment.

It made me realize how crucial it was to have a solid foundation for technical projects. I know of no one who hasn’t followed the correct procedures to tackle a project. This is also true for me. I must consciously ensure that my processes are sound even now.

This is my goal. You will learn the steps, how to execute them, and in which order. These steps can be applied to all programming languages and systems as well as entire disciplines.

A Single Step-by–Step Starts the Journey of a Thousand Bytes

Let’s begin by describing the basic sequence. We can then revisit some of their considerations.

Step 1: Identify all pieces that you will require. Because pieces can be literal parts for hardware-based projects, or software-based packages, we use the term “pieces”. The tinkerer will know which pieces make sense.

You are basically taking inventory. You take inventory when you open a box of furniture that is to be assembled. The same applies here. Your manifest may be different from your DIY furniture. It’s possible that writing the manifest is the first step. You shouldn’t proceed until you have listed every atomic unit that you need to list.

Step 2: Find out how the pieces fit together. This is a more complicated task than it sounds. We will be looking at it in detail. You should know for now that you need to read as much documentation as possible to get a clear understanding of the workings of each piece and the connections between them. Take notes if you haven’t.

Step 3: Decide the order in which you want the pieces to be assembled or implemented. There may be multiple ways to assemble the pieces. You have options, but you need to choose one and stick with it. This is where you and your project will determine what you should choose. However, it is important to adhere to all requirements.

Step 4: Create a step-by, detailed instruction that outlines the steps you took in Step 3. This is pseudocode, which you would use if you were actually developing software. Pseudocode sounds exactly like it does: It looks and acts just like code, but it’s not. It is a combination of programming language syntax and natural language (e.g. English) semantics. It is a middle ground between machine and human.

After each step, make sure to test what you have done. This creates an incremental workflow for your project. Do not move forward until the test passes. Your workflow will become iterative by repeating each step until you have everything that is safe and load-bearing for the next steps.

Step 5: Prepare the environment for the instructions you wrote in Step 4. You will need to open all manual pages and notebooks and install the software you are going to use (but not run it or configure it yet), as well as log into any accounts and devices that you may have.

It is not the size of the step that matters, but how you use it

These are just a few of the things we should keep in mind as we go through this process.

To ensure credibility, you should carefully audit the information that you find on the internet. The harsh reality of economics means that most technical information found online is incorrect. Tech is a lucrative industry due to the high demand and low supply of tech professionals. Tons of resources were produced quickly to train the influx of tech professionals.

Here is where the market forces come in. Quality is affected when demand exceeds supply. Quality is lower when production speed increases without an increase in raw materials or price. The majority of tech resources were free. There are no more raw material than before. Training quality also dropped.

It gets worse. It’s not just that educational material is written quickly and for a audience with lower technical literacy; the “experts” who have been trained on these materials are the ones who write the next generation of educational resource. This vicious circle of decreasing training quality goes on.

There are many quality reference materials out there but they get buried deeper and deeper. You will need to find reliable resources for yourself.

You can do a few checks on a source to make sure it meets the required standards.

Are they a for-profit organisation? It’s likely not to be very helpful. Many tech companies are selling to an inexperienced audience. Companies that have valuable tradecraft to share avoid giving it away free.
Is the source of your information a non-profit organization? This could prove to be very useful. It could be useful to check the reputation of the organization and whether or not it is associated with the hardware/software you are using.

Do you use your source organization for training purposes? Be cautious if it is a for-profit organization. This is because the priority of these companies is job placement and not trainee quality. It’s most likely solid if it’s a non-profit training group. These groups are usually interested in advancing technology or promoting it.

Who wrote the source? You can trust the source if the author is a tech company but gives the information away for free. It’s important to think about the author of the advice you are reading and why.
If you don’t know what code does, never run it. Although this should be obvious, it is important enough to mention anyway. This is something that we all know, but we sometimes forget to do. You might regret it if you’re not careful.

Write Good Pseudocode

Quality pseudocode correlates with quality project. Good pseudocode requires being as precise as possible. This is known as “decomposition.”

Let’s look at a real-world example to understand: If someone told you to make spaghetti, your past experience would likely have taught you the right steps. This task is actually composed of about 12 steps. First, you will need to buy a package of pasta. Next, you will need to prepare a large pot for the pasta. Finally, add water.

You must break down your pseudocode process into these small steps that seem to be easy. This is because your process is new and more complex than it’s familiar and easy. Your granularity will be just right when you break down your process into its smaller parts.

It is important to address a syntactic aspect as well.

Every atomic step should have its own line. Make sure your looping and conditional steps are clearly visible. This is usually done with indentation.

If you are using conditional statements, indent the condition below it with the same indentation level as the line above it (except if it is a loop or other conditional statement).

If you are using looping statements, indent the condition that the loop iterates at the same level as the line above.

You can go the distance even if your feet are tired

It is tempting to take the easy route and cut corners. Don’t give in. My music teacher used a self-diagnostic to describe a saying that said, “How good would it be if you did all you were supposed to do?” You’ve spent hours researching what the “right” thing is. It’s not because you don’t know what the right thing is.

Why? It takes more time upfront but it is more efficient later on because everything is properly set up. Do not choose to be less than what you are capable of based on the circumstances.