DEV Community: Hamza Tamenaoul

Have you heard of the bus factor ?

Hamza Tamenaoul — Wed, 15 Nov 2023 23:20:08 +0000

In software development, many risks can jeopardize the success of a project, or even threaten its survival. One of the main responsibilities of a good project manager is to take those risks into account, and measure them. As one of my teachers always stressed, "a metric that can't be measured, can't be controlled".

One of the most important metrics in a software project is the Bus Factor, even though it is not much spoken about.

What's the concept ?

When defining the metrics of software reliability, one of the first questions we should ask ourselves is: what are the points of failure of the system ? And it is a very important one, since it easily creates bottlenecks.

Therefore, the Bus Factor tries to ask the same question, but this time about the development team: What is the minimal number of team members that we can not afford to loose to a bus accident ? (Indeed, it is a dark question to think about !).

Although having multiple members of your team getting hit by a bus is statistically very unlikely, on the other hand having some of them leave unexpectedly, either because of a resignation, a lifestyle change, a family situation evolution, etc..., is highly probable. We are all familiar with the turnover figures in the software industry. And it is precisely for these reasons that this factor is very important.

Diving in maths ?

Let's take a simple example to understand the metric's calculation.

Let's assume a project has a DevOps team made up of 3 members. Let's assume that every team member perfectly knows everything there is to know about the team's perimeter (a transversal DevOps team for example).

In that case we can see that if the 3 members of the DevOps team get suddenly hit by a bus, we loose the ability to work on the project while we can get by with one DevOps (although he will have to dramatically increase his energy drinks consumption). And therefore you can guess that the bus_factor = 3. Meaning we can afford to loose 2 DevOps engineers before the DevOps team stalls.

For a more realistic example: Let's assume now the project having a Front End team of 5 people. While 4 of them share the same knowledge about the application, the 5th person masters one critical side of the code. Therefore, it might seem that the bus_factor = 5, but in reality the global factor of the Front End team is limited to 1.

How do we deal with it ?

The reason we decide to measure the Bus Factor is to try to maximize it. The higher the Bus Factor is, the lower we are exposed to an unexpected loss of knowledge, eventually leading to a sharp increase in development and maintenance costs. Ideally we should aim for the ideal number which equals the number of our team members. On the contrary, a lower Bus Factor means a higher exposure. And the closer we are to 0, more red bells will ring.

Knowledge should always be shared among team members to increase the Bus Factor as much as possible !

In the midst of excitement when working on new software projects, or just complex features, we often forget some basic project management concepts. And best practices are here to make sure we stick to them. The bus factor is among them, emphasizing the importance of practices like Code Review and pair programming, that take it into account implicitly.

If a team member gets hit by a bus, would that destroy your software project ?

Hamza Tamenaoul — Fri, 30 Oct 2020 10:50:05 +0000

In the software development business, there exists many risks that endanger not the only the success of a project, but even its survival. One of the roles of a good project manager is to take those risks into account, and be able to measure them. As one of my teachers in engineering school always stressed, a metric that can't be measured can't be controlled nor dealt with.

And one of the most important metrics in a software project is the Bus Factor.

What's the concept ?

When designing scalable and reliable software, one of the first questions we should ask ourselves is what is the single point of failure of the system ? And it is a very important one, since as you already know, it can easily cause a bottleneck and therefore stop the whole application.

Well the Bus Factor tries to ask the same question, but this time about the development team. The question of What is the minimum number of team members that should get hit by a bus before we loose a necessary knowledge about the project. (It's a very dark question to ask !)

Although having many members of your team getting hit by a bus is statistically very unlikely, however having some of them leave the team unexpectedly, either because of a new job, new lifestyle, new family situation, etc..., is highly probable. And it is precisely for this reason that this factor is very important.

How do we measure it ?

Let's take for example that a project is composed of three distinct entities: the Front End team composed of 5 people, the Back End team of 10 people, and the DevOps team of 3. Let's assume that every team member perfectly knows about what its team is working on only.

In that case we can see that if the three members of the DevOps team get suddenly hit by a bus, we loose the ability to work on the project. And therefore you can guess that the Bus Factor of this team is 3.

How do we deal with it ?

The reason we decide to measure the Bus Factor is to try to maximize it. The higher the Bus Factor is, the lower we are exposed to an unexpected loss of knowledge. Ideally we should aim for ideal number which is the number of our team members. On the contrary, a lower Bus Factor means a higher exposure, and the closer we are to 0, the worse we are.

You should always share knowledge between your team members to have the highest Bus Factor possible !

In the midst of excitement when working on a new Software project, we often forget some basic project management concepts. And best practices are here to make sure we don't forget some of them like the Bus Factor. This shows the importance of practices like Code Review or pair programming that take into account this kind of factor, and help prevent a low metric.

Why you don't need to remap the escape key in Vim !

Hamza Tamenaoul — Mon, 21 Sep 2020 12:45:48 +0000

Vim by its nature is very heavy on the <Esc> key usage. It's very important in the modal editing philosophy of the editor. But when we are talking about Vim, we are talking about minimal hand movement in the first place, since it is the reason behind all of its design choices. For this reason many have found the usage of the <Esc> very unintuitive to use, and prefer to map it to a more easier to access key combination. Many tutorials over the internet suggest changing it to a combination close to the home row like jk, a combo I did not personally find useful.

However the designer of Vim did not forget about the user that might find exhausting to use <Esc>. When diving in the documentation of Vim, we can notice in the intro page by typing:

:help escape

We can read on this page a more clever key combination that is already built in the default Vim configuration.

<Esc>   escape  CTRL-[  27  escape  <Esc>

We can see that <Esc> is also mapped to <C-[>. And this is very interesting since Vim by default gives us a more easier to use key combination for the escape key out of the box.

It can take some time to get used to using this key combination, but it will quickly become your favorite since, you can start from it to make other more interesting key combinations; like an escape key of the built-in terminal.

What do you think about this key combination, or do you already use a more interesting one in your configuration.

Interface implementation difference cross languages

Hamza Tamenaoul — Mon, 25 May 2020 10:31:40 +0000

This article was originally published on my blog.

Interfaces are one of the most important features of a lot of programming languages. A lot of their features won't be available without that small keyword.

But working with different languages we can spot two different paradigms in how interfaces are implemented in them. I have decided to name them the "Implicit implementation" and the "Explicit implementation".

Explicit implementation

Explicit implementation is the most straight forward one from the two to spot. The most prominent example is this approach used by the java language.

The idea is fairly simple, after you define an interface, you need to explicitly specify that you are implementing it by the current class. As an example.

interface Geometry {
  float area();
}

class Rectangle implements Coordinates {...}

Although this approach make the code easier to read, since by just glancing at the code we can guess that this class have the methods and attributes defined in the interface.

The limitations of explicit implementation

Let's imagine you have this code in Typescript.


class Point {
  x: number;
  y: number;
  ...
}

interface Coordinates {
  x: number;
  y: number;
}


function getX(_object: Coordinates): number {
  return _object.x; 
}

To test it we can execute:

const point: Point = new Point();
console.log(getX(point));

Any Typescript developer know that this type of code works. However in the java world it does not. For the languages that rely on the explicit implementation scheme, an error will be thrown at you. for them, even if the Point class have apparently the requirements to be considered as a Coordinates implementation, it is not.

You may not see the problem, but it become crucial when the class you wanna use is from a library but the interface is yours.

Implicit implementation

To solve this sticky situation, more and more languages rely on implicit implementation. In those type of languages, like Typescript or go, the compiler see if the class fulfill the requirements specified by the interface, and not if it implements it.

This languages have decided to sacrifice readability, unless you know all the interfaces of your code, you can not know if a class follow an interface specification or not.

A quick demonstration from the go language.

type Geometry interface {
  area() int
}

type rectangle struct {
  x, y int
}

func (r rectangle) area() int {
  return r.x * r.y
}

func getArea(_object Geometry) {
  return _object.area()
}

For testing purposes:

func main() {
  r := rectangle{x: 1, y: 2}
  getArea(r)
}

And as expected it works without much effort, and without the hassle of having to explicitly declare the implementation of the interface.

I hope that this article was a quick peek to discover one of the many questions a languages designer have to ask himself before starting to make it's own language. (Although I agree that interfaces may not be the first thing he will start with ;) !). However it shows the two most common approaches, one more focused on readability, the other on functionality and extensibility. For you, which one of those implementations do you prefer ?

Framework vs library vs package vs module: The debate

Hamza Tamenaoul — Thu, 16 Apr 2020 16:44:04 +0000

This article was first published in my blog

As a software developer, this is one of the questions that is often asked, and one of a big source of confusion. In the debate about the difference between frameworks, libraries, packages and modules, what does each one of them represent.

Module

Is the smallest piece of software. A module is a set of methods or functions ready to be used somewhere else.

Package

Is a collection of modules. This may sound funny, but usually what a package does, is gather a number of modules holding in general the same functional purpose. Making it easier to include all the related modules at once.

Library

Well library at it's core, is a collections of packages. It's purpose is to offer a set of functionalities ready to use without worrying about the subsequent packages. So a library is what you include when you want to add some functionality to your code. It does not force any coding style on you either.

Framework

It's a set of libraries. But this time, the framework does not just offer functionalities, but it also provides an architecture for the development work. In other words you don't include a framework. You integrate you code into it. He is the wire frame of the project. That's why a framework forces its coding style on you.

I hope that this quick summary was enjoyable !

The different types of method specifications

Hamza Tamenaoul — Fri, 10 Apr 2020 12:26:17 +0000

This post was originally published in my blog

Specs, specs and specs. The often forgotten aspect of software design. Defining the specification of the project is the first step in any successful software project. And yet it is often overlooked. It gives us not only the opportunity to understand the need of the client, but also to synchronize the work inside a team of developers more easily and avoid any negative side effects.

My goal here today is not to talk about what is their importance or why are they so useful. But it is about showing some key aspect to have in one's mind during the specification design phase.

N.B: To make things simpler, I am going to focus here on method specification, but a generalization can be applied to more advanced structures like classes or modules.

What are specifications

the specification of a method is the definition of the following:

The prototype of the method to define the parameters of the method and their type.
The preconditions are what conditions should be fulfilled before the method procedure could start.
The postconditions are what conditions are guaranteed on the outputs of the method.

By convention the preconditions follow the keyword requires, while the postconditions follow the effects's keyword.

The importance of the specification can be felt at the implementation phase. it forces us to agree on the method and its side effects, and by then have no disappointment after the development phase from the its client (The client here refers to the user of the method).

Deterministic vs Non-deterministic specifications

You can find two types of specs: deterministic and non-deterministic.

A deterministic specification is a specification that is precise enough so that any implementation of that specification from the implementation space will yield the same results. That means that regardless of how the method was developed, or the person that have developed it, we can trust that the client will get from all of the implementations the same result.

A non-deterministic specification, on the contrary, gives more freedom to the implementer, since in the implementation space of the method, we can have implementations that won't give the same results. So the client can't trust these different implementations since he is not sure that they will converge on the same results.

A small example to understand. Let's consider the following spec.

int find(vector<int> arr, int val)
requires: the val exists at least once in the array
effects: returns the index i such as arr[i] = val

This is a non-deterministic specification. In this case we cannot be sure if the index that will be returned is the smallest or the biggest one found for example. An implementation may start from the lower bound, another one from the higher bound.

To make a deterministic specification we can say:

int find(vector<int> arr, int val)
requires: the val exists at least once in the array
effects: returns the lowest index i such as arr[i] = val

The goal of any determinization is to remove the ambiguity. And it is the same goal here: Removing the ambiguity from the statement, so that the implementers can agree.

Stronger vs weaker specifications

Now that we have our specification in place, what if we want to make a stronger or weaker one. Well the answer to that question is very tricky, since we need to understand first what do we mean by a stronger specification or weaker one.

A weaker specification is a specification that demands more from on the client and put less responsibility on the method, while a stronger one puts more strains on itself, and relieves the client from some of the task's responsibilities. Mathematically speaking, in a given implementation space for a method, the more stronger the specification is, the more smaller the space is, while on the contrary, the weaker the specification, the bigger that space. In other words, a weaker specification asks more of the inputs (A.K.A the client), and less from outputs, whereas a stronger reverse this statement.

For a given specification, to make it weaker (or stronger), you need either to put more (less) preconditions, or less (more) postconditions.

This may sound counter intuitive, but if we take into account the definition above, the weaker the preconditions, the more responsibility we put on the method since it has to handle the test cases it did not before. While the more postconditions we put, the less headaches the client will have with the effects of the method.

For illustration let's take the example we used earlier:

int find(vector<int> arr, int val)
requires: the val exists at least once in the array
effects: returns the index i such as arr[i] = val

To make this specification weaker, we can ask from the client more efforts. To do so, we can write it as such:

int find(vector<int> arr, int val)
requires: the val exists once and only once in the array
effects: returns the index i such as arr[i] = val

While to make it stronger, we can impose more conditions from the outputs. For example, we can do:

int find(vector<int> arr, int val)
effects: returns the index i such as arr[i] = val or -1 if the val is not found

Writing good specifications

Good specification is crucial, specially in the context a team work. It provides the developers with the necessary tools for them to be on the same page and not diverge in their implementations. It is mandatory for a specification designer to take into account these two key concept, to pay attention to what specification is he writing, and to ask the good questions. Is it all right if this specifications is non-deterministic, or it may put the integration of the modules at risk ? Do we need a stronger specification on this class, or this weak one shall do it ? These are some of the most important questions that he shall bare in mind during the whole process.

There are other key aspects in designing a specification that were not mentioned in this post, like defining exceptions, but still it is already enough for now I guess. Maybe I will write about them in another piece.

Happy coding, and stay safe !

Hey you ! Have you thought about specifications ?

Hamza Tamenaoul — Wed, 08 Apr 2020 19:19:34 +0000

This post was originally published in my blog

My goal here today is not to talk about what is their importance or why are they so useful. But it is about showing some key aspect to have in one's mind during the specification design phase.

N.B: To make things simpler, I am going to focus here on method specification, but a generalization can be applied to more advanced structures like classes or modules.

What are specifications

the specification of a method is the definition of the following:

The prototype of the method to define the parameters of the method and their type.
The preconditions are what conditions should be fulfilled before the method procedure could start.
The postconditions are what conditions are guaranteed on the outputs of the method.

By convention the preconditions follow the keyword requires, while the postconditions follow the effects's keyword.

Deterministic vs Non-deterministic specifications

You can find two types of specs: deterministic and non-deterministic.

A small example to understand. Let's consider the following spec.

int find(vector<int> arr, int val)
requires: the val exists at least once in the array
effects: returns the index i such as arr[i] = val

To make a deterministic specification we can say:

int find(vector<int> arr, int val)
requires: the val exists at least once in the array
effects: returns the lowest index i such as arr[i] = val

The goal of any determinization is to remove the ambiguity. And it is the same goal here: Removing the ambiguity from the statement, so that the implementers can agree.

Stronger vs weaker specifications

For a given specification, to make it weaker (or stronger), you need either to put more (less) preconditions, or less (more) postconditions.

For illustration let's take the example we used earlier:

int find(vector<int> arr, int val)
requires: the val exists at least once in the array
effects: returns the index i such as arr[i] = val

To make this specification weaker, we can ask from the client more efforts. To do so, we can write it as such:

int find(vector<int> arr, int val)
requires: the val exists once and only once in the array
effects: returns the index i such as arr[i] = val

While to make it stronger, we can impose more conditions from the outputs. For example, we can do:

int find(vector<int> arr, int val)
effects: returns the index i such as arr[i] = val or -1 if the val is not found

Writing good specifications

Happy coding, and stay safe !

Why some think ++i is faster than i++ ?

Hamza Tamenaoul — Mon, 25 Nov 2019 11:43:01 +0000

Originally posted in my portfolio.

A while ago, I have noticed reading some competitive programmers' code that a lot of them in their for and while loops tended to prefer using ++i instead of i++. For example you could see in their code:

for (;;++i) ...
while (--i) ...

So a question scratched my head to figure out why and if there is any real performance boost by using such expressions (since they were top competitive programmers).

The answer lies in the dark caves of compilers and assembler generation

So let's try to figure out what happens !

Analysis

Accessing an array index with an expression

Let's I have the following code:

// I have two variables 'a' and 'b'
arr[a+b];

When reading this instruction what does the compiler do ?
If we write what the compiler does in pseudo code it would give us something like this.

Get the value of a
Get the value of b
Calculate the expression a + b
Access the array position with the calculated index

Accessing the array index with a pre-increment

Now this time let's see what happens with ++i:

// I have a variable 'a' 
arr[++a];

the compiler translate this with:

Get the value of a
Increment that value
Store the new value
Access the array position with the calculated index

The breakthrough

Have you noticed a trend here ?

The compiler evaluate the expression inside the brackets before accessing the element. Which is different from what the usual i++ do !

if we have now:

// I have a variable 'a' 
arr[a++];

You can guess now how the compiler would translate that given the knowledge of what this instruction does:

Get the value of a
Store the value of a temporarily
Increment that value
Store the new value
Access the array position with the calculated index

Given the added storage - that might be interesting in the context of an array access but usually unnecessary in the context of a loop - we get an added instruction that could result, depending on the machine the code is executed on, a slight performance drop.

Closing words

You can guess by now that this syntax, in the context of modern machines the performance hit is generally not something to worry about. In addition to this I have found that usually compilers now optimize this kind of instruction to see if the value is really needed to be stored or can be dismissed. But this kind of questions is really helpful in understanding more how compilers work.

WSL 2.0: More of the good juice

Hamza Tamenaoul — Tue, 02 Jul 2019 15:06:48 +0000

This article was originally published in my blog.

Microsoft made big announcements during its last Microsoft Build. A lot of new and exciting products for developers have been announced. While the main focus of the people was centered on the new windows terminal, a terminal with a lot of long awaited enhancements and the new VS Code features, what held my attention was the improvements on the Windows Subsystem for Linux or what was called the WSL 2.0.

Why should you get excited about WSL 2.0

WSL 1.0 was amazing

While I was doing my whole development work on Linux, mainly Xubuntu and Arch, I had to always install it along side of windows, since Linux didn't support a lot of the tools I was using on nearly a daily basis (Specially games). But upon discovering WSL, everything changed, I suddenly found myself able to migrate my development work completely to windows, except for some system development with C, and living inside CMD (I have tried a lot windows terminal emulator, but I always found CMD to be the best one, any suggestions ?).

WSL 1.0, besides some of it's limitations, like not being able to install a lot of Linux applications or it's very slow speed, was quite successful at delivering the promise it gave us; A Linux development environment on Windows.

Where WSL 2.0 will make it better

The Big problem of WSL 1.0

The biggest complain about WSL 1.0 was its slow speed, some commands took ages to complete, when they should have needed few seconds. This was due to the compatibility layer that WSL 1.0 was introducing, a layer whose role was to primarily translate Linux syscalls into Windows syscalls, so it didn't find a use to having a Linux kernel.

WSL 2.0 solution

The solution is quite simple and obvious, shipping a linux kernel directly into Windows and let it do the work. That's the engineering feat that the WSL team was formidably successful at accomplishing. So now the programs run as if they were running on the Linux kernel, because they finally do. This will enable a lot of the tools that wouldn't be able to run using the compatibility layer to run, and most notably Docker.

How does it work

The Linux kernel runs in a very lightweight virtual machine, and all of your WSL instances will run on top of it. This has an incredible impact on the performance of WSL. Since only a single instance of the virtual machine with the kernel is running, having a lot of instances of WSL won't result in a huge performance drop, a feature accentuated by the really lightweight nature of the VM containing the kernel.

Adding to this, the WSL team dropped the usage of the weird compatibility layer they were using for files, and instead use native Linux filesystems directly in WSL, that way the filesystem performance are significantly enhanced.

This doesn't mean that you would not be able to access your files on windows directly or vice versa, they are using a network protocol to share files across Linux and Windows. It's the method that uses Vagrant to have access to some part of your host filesystem in the guest by using Samba for example, but this time with WSL 2.0, you have access in both ways.

Conclusion

With WSL 2.0, Windows give us more of the great experience that it gave the developer community with WSL 1.0. It is an impressive achievement not only because of what it enables Windows users to do, but also because of the incredible engineering feat it represents.
for more information you can check the WSL.

If you are interested in knowing more I invite to you to see the WSL Team keynote.

I created a JavaScript free portfolio

Hamza Tamenaoul — Sun, 31 Mar 2019 13:14:24 +0000

Visit my portfolio

I always wanted to make a portfolio, I always saw as the medium by which I could showcase my work and my skills. So I wanted it to be a true representation of how I work.

I tried a lot of concepts, build five portfolios before throwing them to the trash can, and emptying it. Finally, I thought what would define how I love making software. Three worlds came out: simple, minimal, beautiful. This is how my portfolio needed to be.

Simple

The simplicity came from making from it's structure, it's layout, the choice of the technologies used in it. Why would I use JavaScript if everything that I wanted to do could be done using plain CSS. Why would I use frameworks like Bootstrap or foundation, if I could handle everything myself.

Minimal

In the choice of the information that it provides, the choice of colors and design. Basically, it's overall spirit.

Beautiful

In this case, this is a subjective matter, but looking at the current design trends, and some award winning portfolios. I think describing it as beautiful fits it.

I am not done making it, there is still a lot of work to be done, I have a lot of projects to add and things to tweak. But I judged that it has reached the point where it could be published. So I thought I would submit it to the people of this wonderful community to seek their opinion and critic.

*nix Bash shell vs Windows PowerShell: Two paradigms

Hamza Tamenaoul — Fri, 15 Feb 2019 20:43:12 +0000

Originally posted in my portfolio.

PowerShell and Bash Shell, have quite a lot of differences. The first one is a complete scripting environment, the second is only a command line interpreter. One is suited for the management of windows servers, the second is more suited for development environment. These differences might look obvious when discovering them for the first time. But what really held my attention, was the fact that PowerShell use Objects, when Bash Shell uses plain text.

Let's take a simple linux command.

$ ls -l

The output of this command will be returned in a plain text format, that input will can be for example piped to another command like grep

$ ls -l | grep Desktop

In this example the bash would take the output of the ls -l command a string parse it looking for the pattern set in the parameter.

Windows PowerShell behaves differently. Let's try to repeat the same example in it.

PS > dir

Now, if we want to look for a specific pattern on the text, we will pipe the result to the Select-String command.

PS > dir | Select-String -pattern "Desktop"

At first glance you will notice a difference in how the output is displayed. Unlike grep which displayes the line where it found the pattern with the pattern highlighted. But it's not simply a display style or choice. The output is the object that matches the pattern.

To see this behaviour in action let's assume that for the linux command the output is:

drwxrwxrwx 1 hamza hamza    4096 Nov  4 18:29 Desktop
drwxrwxrwx 1 hamza hamza    4096 Nov  4 17:15 Documents
drwxrwxrwx 1 hamza hamza    4096 Nov  4 17:15 Downloads    
drwxrwxrwx 1 hamza hamza    4096 Nov  4 17:15 Favorites
drwxrwxrwx 1 hamza hamza    4096 Nov  7 10:56 IntelGraphicsProfiles
drwxrwxrwx 1 hamza hamza    4096 Nov  4 17:15 Links
drwxrwxrwx 1 hamza hamza    4096 Sep 22 01:26 MicrosoftEdgeBackups
drwxrwxrwx 1 hamza hamza    4096 Nov  4 17:15 Music
drwxrwxrwx 1 hamza hamza    4096 Oct 20 12:26 OneDrive

Then if we use:

$ ls -l | grep drw

We will get the same output but this time with drw highlighted. But for the first PowerShell command if we get:

Mode                LastWriteTime         Length Name
----                -------------         ------ ----
d-r---       04/11/2018     17:15                Contacts
d-r---       04/11/2018     18:29                Desktop
d-r---       04/11/2018     17:15                Documents
d-r---       04/11/2018     17:15                Downloads

and do a search on this output using:

PS > dir | Select-String -pattern "d-r"

We will get nothing in return. Because the column Mode column is a non searchable parameter by Select-String of the output Object of dir (the alias of Get-ChildItem).

If you call Select-String with wrong arguments, it will send an error message for each file object it iterates throw.

Learning about the differences in different technologies is very interesting, a way to discover how different people give different solutions to the same problems. By understanding the power of each technology and it's short falls, you will start to see technology in a whole new way.

The history behind "grep"'s name

Hamza Tamenaoul — Mon, 07 Jan 2019 23:54:38 +0000

Originally posted in my portfolio.

grep, a tool that is widely used in the Unix world, a tool that no one could live without. It's one of the first command to which every linux beginner is introduced from its start, so its function is no secret to no one. However, what's the history behind its weird name ?

The answer to this question requires us to go back to the early days of Unix, days of resource scarcity, may they be processing power or memory resources. Software developper of the time had to play by the rules and develop very light programs that get the job done. And one of those tools was the ed text editor. But this editor is nothing like the modern editor we have today (VIM looks like JetBrains IDEs next to it). To see a line of text from the text buffer you needed to type p preceeded by the line number. And for searching the buffer for an occurence of a regular expression we could use like in VIM /regularexpression. But for us to search for all the occurences and print them we'll use g/regularexpression/p, written simply g/re/p. And that's how the world grep was born.

The history of Unix is full of these stories. Amazing stories about those early days of computing.