Epistles to a Software Developer: Abstraction

[Originally written on February 28, 2020]

Dear Eri,


Greetings! How do you do today?

“Registration” Think of what exactly happens when you register a thing. It involves three steps: accepting submitted information, recording it, and storing it. Three steps described in one word. If I say “grooming kit”, what do you imagine? List all the items in your bag? Baby powder? Lipstick? Face powder? Mascara? Hand sanitiser? The list may never end and may vary person to person.

You see, describing multiple things in one word is a timeless technique called abstraction. See how one word is jam-packed with ideas? If I say “Shopping Mall” or “Winemaking”, sensations will gush into your mind; bonus if your imagination is vivid. Abstraction is derived from the Latin word “abstrahere” which means “to draw or pull away”. Drawing a pack of things requires a handle or something to hold on, which is your one word (or phrase) to describe a cohesive collection of things such as a “music band” or brewing a coffee.

Take note that things can be contained in a word, phrase, or a sentence. You might be asking “What is ‘abstraction’ in software development”? If you remember what I taught you about IPO, you can abstract the example I gave you in one phrase: “Temperature Conversion”. Since whitespaces are not available when naming a variable or a user-defined function, name it as “convertCelsiusToFahrenheit” or whatever perfectly describes the function. Abstraction will be your bread and butter when it comes to writing software. Most things are abstractions of abstractions. One word like a function name describes a series of steps… and those steps are called function calls which also describes a series of steps… the deeper you go, the higher your mental energy depletes. Not intrinsic to OOP, but you’ll do this mostly when you do OOP. Abstractions, when done right, make a beautiful readable code.

Let’s go back to “Registration”; as an exercise, see that “accepting”, “recording”, and “storing” are abstractions abstracted by “registration”. Let’s start with “accepting”, the steps to accept the thing is to receive it, validate it, and let it in. Well then, how do you record a thing? Vinyl? Paper? Photograph? Neural implants? There’s so many ways, but choose what suits your requirements. The data from “accepting” is used by “recording” then by “storing”. Grab a pen and paper and list all the logical steps to “accept”, “record”, and “store”. I expect that you’ll draw a “tree” or a “ramifactive” image. Align all the items by their “level” as you write them. After exhausting your imagination, please explain what “Layers of Abstraction” is, strictly from your experience from the exercise. No references other than your mind and memories. How many layers will you make?



Cheers,

Haytham Merger

Epistles to a Software Developer: Functions

[Originally written on February 4, 2020] 

Dear Eri,

Good day! I was quite too busy, so this letter’s late. I’ve been implementing a certain kind of architecture in a company backend app that I’m building from scratch. I don’t know your college curriculum, but before you learn any new language, you must know what IPO truly means: “Input Process Output”. It describes most of the systems in general. For example, I wanted grated cheese for my Filipino-style spaghetti: the block of cheese will be my input, the grating is the process, and the sprinkled cheese is my output. You get what I mean.

To visualise an IPO, you must visualise what you want, what to do to get what you want, and the things you’ll need to do what you want. Let’s say that you want to do a simple temperature conversion app; let’s be specific: from degrees Celsius to degrees Fahrenheit. Now, imagine three boxes of equal size. Line it up horizontally. In each gap, you place a rightward arrow. In the first box is your input, a temperature in degrees Celsius. In the second box, the formula. In the third box, the temperature in degrees Fahrenheit. A simple exercise. Draw it now on paper if you want. Visualise clearly.

After visualising the IPO diagram well, you’ll want to make a code. You see, most programming languages have a structure that can do the process in the diagram you just made… In OOP languages, you may call it a “method”, in most languages you call it a “function”. Those two aforementioned will always have these parts: the parameters, the processes, and the “return value”. Respectively, they’re the input, process, and output. (Although some functions lack either “input” or “output”; IPO is just a mental model, remember) Now, can you write a function in C++ or your preferred language? (HINT: it’s a separate block of code from the “int main” function). Call it afterwards. If you know your preferred language well, this will be trivial. Always read the docs or tutorials on the internet if you don’t know anything.

Most console apps (the ones you run from Windows CMD, Powershell, or Linux command line) have “arguments” or “args” inside a parenthesis written after the name of the function when you see their source code, especially in Java or C#; the program needs an input to run, and the output is usually an exit code, where any non-zero value signifies an error in the program. You must practise the use of consoles/command lines as early as you can in your college life, preferably that of Linux

I wish the best of luck upon you, Lucilla Eri.

Regards,
Haytham Merger

Epistles to a Software Developer: Prerequisites

[Originally written on January 20, 2020]

Dear Eri, Good day! I hope you are doing fine. We have been exchanging messages these past days. I have taught you some things with regards to software development, yet they are random and unstructured. My mentee, a girl who just finished senior high, STEM strand, is now an IT student. You wanted to take a degree for an aspiring veterinarian, yet you chose IT. It is still fine, just think in systems and parts. I am by no means a master, yet, however, I know what it takes to tread the path of a software developer. I’ll guide you through your years, especially on self-studying. I’ll be sending you letters when I have a lot of time. The field of software development will be full of symbols, diagrams, and mental models. Yes, you have to be clear with your mental models, that’ll be your bread and butter. A decent skill in maths is necessary. Most of all, you’ll need to be always logical when it comes to the technical aspects. Since most of the manuals, tutorials, and documentation are in English, you might as well improve your English skills with regards to reading and writing; a well-honed reading comprehension skill is a must. Hone your “Googling” skills. Also, your abstract reasoning will be put to the test; I told you what your bread and butter is. With regards to mental models, I always use the IPO model which stands for Input Process Output. Now, now, you don’t have to always draw it on a paper; I use it because it is easy to visualise in my head. Some other complicated diagrams exist, like the Flowchart, or UMLs. For now, just practise the use of the flowchart diligently. This path requires you to efficiently interpret diagrams and symbols, and that can be achieved by practice. I repeat, IPO and Flowchart; the rest can be learned well later. A pen and paper will aid you in learning if you diligently take notes; typing doesn’t have that feel and memory reinforcement. A whiteboard will also do, but use your camera and take photos of what you’ve written there for future reference. Stick to one programming language for the meantime and you’ll be surprised how easily you’ll learn another. I recommend Java or Python. This is what your mentor can teach you for now. I’ll send another letter next week. See you soon! Regards, Haytham Merger P.S In my university, they teach C++ to Nursing students in the very 1st semester.

MILF Analysis

Good day! I’ll introduce myself as a Software Engineer who aspires to be a Software Architect.
Before you start writing an understandable English text, you must have read an English text before, or you’ll have nothing to imitate. You’ll always need example. When reading a source code, I have an acronym in mind: MILF. It’s like a guideline to know what to check first.

The MILF I shall be talking about is neither a group of Philippine Islamic separatists nor a kind of a performer with a beautiful maternal aesthetics. It is an acronym that stands for Machine, Intention, Logic and Language, and Files. Whenever someone spots a bug, proposes some addition of feature, or modification of a feature, I get to the topic and that will be my scope. Today, I shall give you an insight on how I analyze other people’s source code, or even the source code of my past self.

The Machine

Will this be run on a desktop or laptop? On a smartphone? On an embedded device? On a virtual machine (an imaginary computer inside a real computer)? On most cases, you skip this step unless the constitution of the Machine and the OS affects the intended functionality in a huge way, like how file permissions are affected or the view of the web page changes when you use a mobile phone. Also take note whether the file is a system file or an application.

When thinking of the machine, you must think of the environment. The environment depends on the machine. Always. The background always appear first when you write a novel or a short story.

On what machine this is supposed to work well? Speaking of “suppose”…

The Intention

The most important part we have. When looking into a particular function, you ask yourself: “What is the intention of the developer when the code was written?” As much as possible, the intention is clear, concise, and precise. This is where you see things go right or go awry.

Intention of the Writer

Let’s start with a simple objective. The programmer just wants to fetch from a user table and display it in a browser.

<?php
$sth = $dbh->prepare("SELECT name, colour FROM fruit");
$sth->execute();

/* Fetch all of the remaining rows in the result set */
print("Fetch all of the remaining rows in the result set:\n");
$result = $sth->fetchAll();
print_r($result);
?>
// source: http://php.net/manual/en/pdostatement.fetchall.php

It basically just fetches data from a database, the intention is just to fetch a list of fruits. However, some things might go awry. However, the code shall not work if:

• the database of the fruit table is absent
• the fruit table itself is absent
• the logged in user of the database has no permission for the action
• something is amiss on the database engine
• Some random time-travelling witch from Uganda cast a spell on your machine for no apparent reason other than amusement.

And it cannot be solved by merely changing the snippet, you have to deal with the problems stated above by tinkering with your database settings or contents, or countering that spell by offering a yellow rat, or something. When an error arises due to dependence of some outside influence, or when you have written an implementation by mistake, it is called a side effect.

Side Effects

Side effects exist when some things in the environment are added into the mix. When doing System.out.println("Hello World"); in Java, the developer’s intention is to just print “Hello World”. However, some problems might arise in the terminal which is out of the intention. The functional call I mentioned uses either /dev/stdout of Unix or CON of DOS, which are system files. Side effects can be a “bug” or a “feature”, like a Glutathione pill that is supposed to enhance the health of your liver, but it also whitens your skin. Or when the rugby manufacturers use toluene to enhance the adhesiveness of rugby but was abused by some street rascals for a heavenly experience because the manufacturers were not aware on the effects of toluene (or chose to ignore it because it’s a “feature”). Side effects and environment go hand in hand; you cannot eliminate it, but you can mitigate or contain it. Functional Programming afficionados would like to avoid or contain side-effects: they have monads or something.

Side effects happen when you use the following:

• Third party libraries
• The involvement of DBMS
• System calls and files usage such as print (Python), scanf(C ), System.out.print(Java), and the like.
• Any variables for function calls involved with the compiler, linker, interpreter environment. An example is PHP’s $_GET, or PDO functions.
• Any function that uses or calls any of the above.

If something in the runtime of a code goes wrong, look where the side effects were induced. When you need to use one of the items mentioned above, study and try the effects. Remember that PHP snippet earlier? The side effect happens in $sth->execute();.

Getting to Know the Writer’s Intention

The first thing you do when you analyze the intention is to read the code. Some snippets of code are clearly written that you can derive the intended effect with a minimal comment.
When you shall read someone else’s source code, you shall have an idea or gist of intention first from either of the following:

• How a certain feature of a program is run from the end user’s view
• Or the logs generated when something’s on debugging mode.
• The API documentation, the end user’s manual, or any supplementary sources
• The source code itself if it is concisely made and well-commented enough
• Or the words of the authors and contributors themselves

When you fail to have a good look through the first four ways aforementioned, the last one of the list is the last resort. Ask the contributor through e-mail, chat, or in person. It is your last resort unless the person has free time, you are in a hurry, or you are in the same team. Healthy communication is always a must. Free coffee or beer please.

Now that you have confirmed the intention of the contributor, you must confirm if the source code gives the intended results which leads to…

The Logic and Language

I don’t want to dive in too much into epistemology, but Language and Logic go hand in hand. Is language dependent on logic? Is logic dependent on language? Well, that’s for another day. However, I can assure that the logic of a source code depends on how the programming language was used. The use of programming language is shaped on how the logic in one’s mind was made. You must assure that the logic of the code matches logic intended by the contributor.

How well do you form your sentences? How well do you group your statements into paragraphs? How well do you form your article? How well do you form your statements? How well do you form your functions? How well do you form your… AAAAAAAHHHHH! You get what I mean, master both your command of the language and your logical skill so you can read codes well. Always know the syntax of the language and the semantics of your intention.

The possible mechanics varies per language. C programmers might be well versed in low-level programming. Most PHP programmers of 2005 just create sophisticated HTML templates. Java programmers will think in objects and interfaces. Japanese language has no future tense, unlike in English where you can say “I will write” while leaving the question “when” not answered specifically.

A source code itself has its own logic just as the contributor has his own intended logic. The two must match or at least the code logic must fulfill the requirements. Do they match?

There’s a room with two people. Assuming that there is a need to engineer a mechanical rice cooker that turns off by itself by a timer, how will a Victorian-era English baron argue with a shinobi from Japan who can’t speak English?

The Files

I assume that when you read other’s source code, you start with one file. You start to read the file block-by-block. You are well aware of the language, and figuring out the logic. Does the code stands alone? It it just a sheet? A leaflet? A booklet? A book? A tome? A library? As much as possible, be mindful on how many files in the system are participating in runtime, it’s what we call stack tracing. What are the files directly involved? Which brings us to…

Scope

This is a no-brainer. The scope determines if your refactoring is an overkill. Again, the scope of the code you read must accord to the scope of the contributor’s intent. The scope of your changes must also accord with the scope of your original intent. When you when you plan to refactor, you must make the scope of your intent appriopriate to the scope of the issue.

Includes, Require, Import, Use

Depending on the language, there’s always that one langauge construct or library function that points to a file using a pathname, a namespace, or a class name. Always look for that. Also, be wary of libraries that uses magic methods, it can impede your stack or file tracing if the library is not that documented.

Conclusion

I’m actually using this technique to analyze the source code of many libraries and the related systems. It’s a gist on how I grasp the involved files whenever a bug is reported. I call it the MILF analysis. How do you like my approach?

This is my original approach. I also have another approach. Here’s the other one

Cold Tension

Why am I prone to overthinking when I'm hurt or when I realise something is amiss?

Is it an evolutionary trait? Evolutionary traits don't have to efficient, they only must serve a purpose. Such traits arose out of need. For example, loneliness is some sort of a mechanism that prompts you to be with the herd; isolation is dangerous in the Stone Age (Kurzgesagt, 2019).

Are early humans also prone to overthinking? Perhaps. If they can think, they can overthink.

Speaking of purposes, a human overthinks because they need to be wary and know what to do next for defensive purposes.

All I know for certain. I might get exhausted from being defensive. One thing is for sure, exhaustion with defenselessness and a presence of a destructive intent nearby means doom or death... or even depression if there are no threats nearby.

Dog eat dog

It goes in my mind.



_{More on loneliness: https://www.youtube.com/watch?v=n3Xv_g3g-mA}