DEV Community: Mohammed Ismail Ansari

What I Learned Writing My First Book

Mohammed Ismail Ansari — Tue, 03 Aug 2021 05:31:22 +0000

Recently, I tried my hand at writing a book. It's a super-short one based on To-Dos and personal planning, but I explored a lot of elements around how I can write and self-publish a book of their own.

The book is available for free on Google Play only (due to technical reasons), but I've also made a video about the entire process and also my learning from the exciting exercise.

Spoilers: The book was written entirely using free and open-source software, so the video does include a lot of technical details about the process as well.

As usual, you may either watch the video itself or read the entire thing as an article over my website.

Regardless, do provide me your valuable feedback, be it positive or even negative.

Installing a Minimal Debian system the Arch Way

Mohammed Ismail Ansari — Tue, 03 Aug 2021 05:14:59 +0000

If you've read my previous post about me migrating my ThinkPad from Arch to Debian, you must also be knowing that it wasn't a conventional install. I chose a tool called debootstrap (much like Arch's pacstrap).

Why and How I migrated my ThinkPad from Arch to Debian

Mohammed Ismail Ansari ・ Jun 20 '21

#thinkpad #linux #archlinux #debian

I also created a mini tutorial/demo about how one can install Debian using debootstrap. As usual, you can either watch the video, or read the transcript of the video from my website.

Why and How I migrated my ThinkPad from Arch to Debian

Mohammed Ismail Ansari — Sun, 20 Jun 2021 20:59:09 +0000

This article outlines my migration from Arch Linux to Debian. The details about the migration are spanned across a few videos, but below is a reasonably short summary.

This is basically a continuation

I moved back from macOS to Linux and I'm loving it!

Mohammed Ismail Ansari ・ Mar 18 '21

#linux #macos #setup

Arch gave me a fresh new direction to explore and experience Linux the way I never did before. I created a couple of reusable artifacts and it in a way became a base for my second YouTube channel.

Arch was great, but...

Things kept breaking, and I found myself spending more time on fixing things than I expected, even with my prior experience with Linux before I spent four years on macOS.

So I started looking out for alternatives and found the exact thing I was looking for.

And then I installed Debian in an uncommon way

I couldn't lose the control I had over my Linux setup back with Arch by delegating it to a graphical installer. So I installed Debian in the way we usually do install Arch.

All this learning had to be documented somewhere so I created another video talking about the process in a little bit of detail.

This moved everything, so the gaps "shifted"

Moving to Debian meant re-setting up the entire machine, even deeper than what I had to do back when I moved the factory-installed Windows to a smaller partition to make space for my primary Linux partition.

The new setup took away a few issues I never got fixed, and in exchange, brought with it a few other ones. I talked about the similarities, differences, negatives, and most importantly, the positives of the migration in a separate video, adding another episode to my series Back to Linux.

Further

As I did last time, I'll keep my eyes open for ways to improve my setup and workflow, and will keep documenting my learning to be able to share them with the rest of the community.

Needless to say, I'm loving the alternate universe with Debian. Do throw in your ideas and thoughts in the comments and hopefully, we can learn something from each other.

I split my Emacs configuration and made it adaptive

Mohammed Ismail Ansari — Thu, 18 Mar 2021 22:13:28 +0000

This article is a transcript of a video that you can watch by clicking the below thumbnail. Hence, certain statements may not make sense in this text form, and watching the video instead is recommended.

Quick recap

I've been maintaining my Emacs configuration on GitHub for seven years now. It was my second project on GitHub (after project-euler-solutions) and was initially named EmacsConfiguration.

As I switched from Windows to Linux, I repurposed the project to contain my dotfiles and Emacs wasn't the only focus anymore. A few years later, recently, I extracted my configuration into a separate project so that my Emacs configuration could once again get all the attention it deserves.

Evolution of my `.emacs.d` over the years

Since the first commit in March 2014, the project has undergone several major changes.

Back when it started, it used to contain the source files of even the packages that I installed. This looked ideal and simplistic at first, but I soon realized a major problem. Every single package update (which depends on how often I update and how many packages the configuration holds) led to tens of updated files being pushed into the project, and especially the files that (a) I don't have control over (b) already reside in a home project of its own.

Thanks to some heavy inspiration from a friend (who also got me into Emacs in the first place), I solved this issue by shrinking everything down to a single Elisp script file such that the project only contained names of the required packages and not the packages themselves.

Moving a little further along with Emacs, I came across a few heavier packages like helm and had to implement a "light" mode such that not everything was loaded every time Emacs was started. This was even more important as I did not use Emacs Server and every Emacs launch was a totally new instance. Fun fact: I still don't use Emacs Server and instead use it as a regular application.

Several months later, I found lighter alternatives to those heavy packages (ex: ivy for helm) and simplified the configuration once more to avoid migraines while making changes to my own configuration.

Issue with the current state

The project, in its current state, was being used on at least four computers running three major platforms: Linux, macOS, and Windows (at work) but then I recently realized (a little too late) that my configuration was too focused on running Emacs as a graphical application and almost no time was spent making sure that it ran well inside a terminal as too.

This was OK until recently I had to work on my computers over the command line and could not run a graphical environment. Needless to say, my Emacs configuration was pretty unusable and I found myself using Vim instead. I also had this experience on my cloud servers where I host my portfolio and a few other web applications, so Vim was my only help.

Part of this was good as I finally became friends with Vim, such that I was able to do more than just enter "edit" mode and quit with or without saving the opened file. However, I decided that it was time to redesign my Emacs configuration from the ground-up such that I could use it even in the absence of a graphical environment.

Plan

The plan was to have two separate configurations, not the way I had it earlier when I shifted relatively heavier packages into a separate "full" mode, but this time with a totally different focus. As per the plan, the default mode was supposed to be command-line focused. There would be a condition, which when true, would load the other (and smaller) half of the configuration designed for graphical mode.

As it goes without saying, the configs for command-line mode would definitely run in a graphical environment but it wouldn't be possible the other way, which was in fact the reason for the entire activity.

The switch was imagined to be a variable state or a function call that would help me determine whether the current interface was a graphical one or an old-school command line.

Just as it sounds, the activity was a fun one. I parsed through each line in every single script file, re-arranged things in the way it was planned, and in some cases, threw away what I didn't need.

New state

As you can see, my init.el file now has two separate functions to start those two identical configurations, residing in their own respective directories. The basic configuration is first loaded and then a decision is made whether the second standard configuration is needed and if it is, it's loaded as well.

The next two steps are common to both, like loading Mass Effect quotes for my own custom screensaver for Emacs and then printing a welcome to my own self. I still have to think about how I can make this simpler, maybe that would be simply throwing them into the basic configuration? Not sure, but that's not that important for now.

A mini-demo

A video without a demo would be quite a theory lesson, so let's have a look at a super-quick demo.

When I start Emacs as I usually do, either from my application launcher or even from the terminal, it starts exactly as it used to before this activity of splitting the configuration. But the problem was never in this mode.

Let's now start Emacs ignoring the window-system, that is by running it like emacs -nw in a terminal, you can see how it's almost exactly the same configuration, just without color themes, variable fonts, and a few other visual preferences that one would only care about while using Emacs in a graphical environment.

Final thoughts

As you saw, this change was one of the most significant changes that I've made in my Emacs configuration since the start of the project. By splitting the scripts into two, I can now use Emacs in the presence and even in absence of a window system, with almost no loss in functionality.

I plan to adopt a very similar arrangement in both my starter packs: ample-emacs and super-emacs soon.

Setting up GUI on Linux with twiner

Mohammed Ismail Ansari — Thu, 18 Mar 2021 22:09:15 +0000

This article is a transcript of a video that you can watch by clicking the below thumbnail. Hence, certain statements may not make sense in this text form, and watching the video instead is recommended.

Thoughts on setting up a custom GUI

When you're a new Linux user, it's very easy to get into the impression that Ubuntu looks a certain way, Lubuntu looks some other way, and likewise. Linux isn't like that, it's about choices so that you can install virtually any Linux distribution and set it up to run virtually any graphical environment with only a few commands. There are obvious exceptions like not being able to run Pantheon on an Arch-based distro, something that I've tried and failed multiple times.

I remember the enlightening moment when my brother showed me that one can install a different graphical environment on a distro that came with a different one. But when I learned that you can also change the graphical login screen (which is the display manager) on a Linux installation, that was a total game-changer, such that I didn't have to be limited with LightDM on LXQT and other such light-weight distros.

One of the major parts of twiner is about choosing the graphical environment of your liking, and that's exactly what we'll look at in this video.

Starting twiner as a program

Once you have twiner cloned on your local workspace, you can start it by running start at the root of the project. twiner starts with a menu of tasks to choose from. Once a selection is made, appropriate scripts are run, and then you're returned to the menu where you started from.

You can run twiner in three modes. Running start with no parameters will run it in regular mode. Passing in debug and running it like start debug will run twiner in debug mode, where it will also echo the commands it runs as a part of its steps. The last mode is simulate, which as the name suggests is a mere simulation, so running it as start simulate and will not make any changes to the system but only echo the commands that would have otherwise run.

A quick look at the options

Out of the eight tasks that have been implemented in twiner at the point of this video, we've already seen most of them in action in the video about setting up my workstation. The ones towards the top of the list are pretty basic and also, for the scope of this video, we'll only look at the tasks related to setting up a GUI.

Also, like I said a few tasks being pretty basic, even the task that mentions adding additional software sources is nothing much really. On Arch, it almost only installs an AUR helper, on Fedora it installs Fusion repositories, and on Ubuntu, it simply updates the system. In the future, we can have it set up snap, flatpak and AppImage as a few additional ways of adding software to a computer.

Finally, you can also see two tasks marked as suggested as twiner can detect that these steps have not been performed on this system yet.

Task: Setting up GUI

The task for setting up GUI in turn depends on the next two tasks in the list. It by itself takes care of installing a display server and a graphics driver and then internally executes the next two tasks for installing a display manager and a graphical environment where you can choose from a list of desktop environments and window managers.

Demo: Setting up Gnome with GDM

One possible quickest demo for setting up a GUI could be starting from a bare-bones setup like the one we used in the last video. So if we run this task on a minimal ArcoLinux installation, we're taken through a couple of prompts. A lot of parts of this video will be fast-forwarded to save time, but don't worry as we won't miss any important action.

Hitting 'G' first installs Xorg and then soon asks us to choose a graphics driver to use. Let me choose Intel for this video.

After Intel driver is installed, it's time to install a display manager. At this point, twiner only provides a choice of two options. Let us choose GDM for this demo.

Next and the final step is to install a graphical environment. I've placed a bunch of desktop environments and window managers in the list and you can mix and match almost any of these with any of the display managers you installed in the last step. Let us choose Gnome shell.

After the process is complete, you're brought back to the menu as mentioned before. Let us quit twiner and restart the system. You can see a graphical login screen and also login into the Gnome shell.

Demo: Switching the display manager to SDDM

Let us see how you can change the display manager to a different one. As currently there are only two options in there, and we have GDM already installed, the only other option is SDDM. Hitting 'L' shows us the two options and then pressing 'S' does two things: it installs SDDM and then activates it for the next startup.

On the next restart, you can see that the login screen that we see is in fact SDDM.

Demo: Installing LXDE

Let us now also see how you can install a new desktop environment. Getting back to the menu and hitting 'D' gets me the same list of options we saw earlier. Hitting 'L' installs LXDE, and on the next log out, you can see LXDE in the list of available options to login into.

A few observations on the current setup

You might have noticed that though twiner helps you install stuff, it doesn't yet help you uninstall any of it. Though this can be easily added, I haven't spent time thinking about this use-case yet.

You might also have noticed that the choices that twiner presents to you are limited. It starts with the assumption that you're looking to set up your graphical desktop with Xorg and doesn't even mention Wayland. Part of this can be justified that if you're the person who's looking for Wayland on your computer, there's a high probability that you won't even be needing twiner to help you. Also, the choices for graphical environments and especially display servers can be increased, but I've almost only included the ones that I could test install myself and didn't want to include half-broken choices.

How I automated my workstation setup

Mohammed Ismail Ansari — Thu, 18 Mar 2021 22:01:27 +0000

This article is a transcript of a video that you can watch by clicking the below thumbnail. Hence, certain statements may not make sense in this text form, and watching the video instead is recommended.

Previously...

In the previous video, we talked about how I got tired of re-configuring my computers manually, got lazy, and wrote some scripts to perform most of it in an automated way. If you haven't watched the previous video, I highly recommend watching it first, as if you don't have the context, you most probably may not be able to appreciate the demo we're about to see in a moment.

If you already have the context, which was quite a lot of theory, let's finally see some action.

The Linux Distribution we'll use

My primary Linux distribution for quite a long time has been Arch, and that is the one we'll install during the demo today.

The base (or vanilla) Arch does not come with the regular graphical installer that most of us are familiar with. Instead, the entire installation happens within a command-line terminal and involves typing a lot of commands manually. Arch documentation is enormous for almost everything and hence they have a pretty detailed page dedicated for installation as well, which you can find here. After I successfully installed Arch for the first time on my Dell desktop, I created a couple of personal notes as Gists on GitHub for my own reference. You can find them here and here, each of them being for a very specific computer. Obviously, both of these links are mentioned in the description. They're mostly based around the steps mentioned in Arch's official setup guide, and though you should rather refer to the official material, it can serve as an example for quick reference, just in case.

One other thing about this basic Arch setup is that you need to install and configure many more things according to your preferences, all by yourself. Though I like to do it this way so that I have the most control over how I set up my Linux, not everyone would want to go through this lengthy and arguably difficult process. So, if instead of a basic system, you're looking for a ready-to-use out-of-the-box system that is still Arch, you can install one of the Linux distributions based on Arch, and there are plenty of them, just like there are so many of them based on Debian and Ubuntu. When speaking of Arch-based distributions, you cannot miss mentioning Manjaro as it's one of the best Arch-based Linux distributions out there and it comes with a range of official and community editions for you to choose from. Installing one of these Arch-based distributions is way easier as they come with the familiar graphical installer, which is often the Calamares installer.

Now, these two options are at the two opposite ends of the spectrum, and just in case if you need something in between, which is as close as possible to vanilla Arch and also comes with a graphical installer, you can use something like ArcoLinux, my favorite Arch-based distribution, which was in fact my entry point to the Arch ecosystem. We'll use ArcoLinux for the demo.

The virtualization tool

For obvious reasons, I won't re-install the operating system on my machine for the demo, and it's not feasible to record the screen while doing so either, so we'll do it in a virtual machine, which is probably the best-suited way to run such experiments. First of all, you don't have to make changes to your computer and you can still get a feel of the new operating system in a sandbox totally separate from the host computer. The best part is that any mistake that might happen during the process doesn't cost you hours (or days) to get back to where you started from.

VirtualBox is a pretty popular virtualization solution and has been the one that I've been using on my computers for several years as well. However, we'll use a new tool for this demo, it's called Gnome Boxes. Gnome Boxes is an easy and modern way of running virtual machines without much configuration. Back when I tried it for the first time, I felt strongly obligated to give it a shout-out on Mastodon and another user replied to my Toot saying Boxes creates a VM as easy as a picture viewer opens a picture. That tells you how easy it is to use. I also didn't know one can right-click on an ISO file and create a virtual machine: that's cute!

Demo: A quick Arco install

The first step for almost all operating system installations is downloading an ISO, mostly from the official website for that Linux distribution and that's exactly where we'll start the process. We'll download ArcoLinuxD, which is the only one among the three that can help us achieve a minimal install that we can work on. Though Gnome Boxes allows you to choose a distribution and it automatically downloads it for you from the web, I like to do it the old-school way such that I supply the ISO for my virtual machine.

So I choose to create a new virtual machine, provide it with the ISO to use, specify the template as "Arch Linux" and proceed with the suggested default. Just like I said, it was so easy to create a virtual machine with minimal prompts and questions.

For this video, I'll rush through a minimal installation of ArcoLinux where I unselect every possible checkbox, choose automatic partitioning which I never do on my main machine, and create a root user. This makes sure we have the cleanest possible installation that still works as we'll be installing all that we need in the upcoming steps. Let me fast-forward this so that we can save some time. Once the installation is complete, we reboot into our fresh system.

Demo: What we have on the first startup

On the first login, as expected, we find a minimal installation of ArcoLinux (basically Arch) that'll start on the command prompt.

Demo: Next steps at a glance

Now that we have a running Linux system, we can bring in my custom setup scripts and set up the rest of the system with a little help from twiner.

All that we need for this step resides under here and fortunately, with all the scripts arranged as an independent Bash program, we'll only be running a single command and the scripts will take care of the rest for us.

After the process is complete, we'll have a system that will very closely resemble my primary Linux installation, in fact, the system I've recorded this video on, with very little left to do manually, most of which would be mundane things like logging into my Firefox to sync my account and settings, and a few things here and there.

Demo: Starting my automated setup

Back when I first implemented a setup script in my dotfiles, getting it onto my new computer involved multiple steps. Not that the steps were very complicated in any way, but they had to be all typed manually.

So I created a single script with all those commands that just manages to take care of everything: cloning my dotfiles as a local workspace on the target computer, and then starting the setup. The scripts are in no way perfect, but at least they work every single time.

Once the script is in place, I now just have to start it all with only a single command. Though this command is still not short enough, I think one command is still better than seven. So I start the process by typing it in the terminal and hitting 'Enter'.

Demo: Detection of the current operating system

Apart from fetching twiner and loading it as a dependency, the first step in my scripts is to detect the running operating system. As I've mentioned earlier, the setup at present only supports Arch and macOS, when either of them is found, scripts for the appropriate one are loaded and run.

For this video, we'll only look at the sequence of steps for setting up my workstation on Arch. The steps for macOS are pretty much the same with a few minor differences here and there, but that could probably be for another video.

If the operating system is found to be outside the two this thing has been programmed for, the setup quits with a message right as you expect.

Demo: Initial steps for Linux

The first step for Arch is setting up the machine hostname so if I choose to do it, I can enter a hostname to use.

The only next step before we start installing the required packages is creating users. As we've already created a user for me during the actual ArcoLinux installation, we can safely skip this step.

Demo: Installing packages

The steps for installing the packages that constitute my daily workflow in Arch start with first installing yay, which is one of the best helper tools out there to ease up the installation of packages from the AUR. Once yay is installed, the setup first installs packages from the official archives through pacman and then installs the rest from the AUR through yay.

This step is the one where we'll have to wait for the most, so I'll fast-forward it as well.

Demo: A few more steps for Linux

We take care of a few more steps before we start setting up the GUI. One of them is switching the default user shell to fish-shell. This step is still not totally automated, and I have to do some typing here.

Demo: Setting up the GUI

The step where we configure our graphical environment is pretty lengthy on its own self. For this very reason, I've planned a separate video to cover this in detail. To be as concise as I can be, this step installs XServer as a display server, prompts for installation of graphic drivers from a small list of options, installs a display manager (also through a prompt) and then finally prompts for installation of a graphical environment from a reasonably long list of desktop environments and window managers.

Let me fast-forward the video for this step as well.

Demo: Installing peripheral drivers

Next, we install drivers for my peripheral devices, which at this point is only one: my Razer Ornata Chroma keyboard that I never use outside of my desktop.

Demo: Setting up startup services

Then I set up startup services, the first one of them is Syncthing (my local cloud) and then there's network-manager service so that I can connect to wireless networks on Arch.

Demo: A few platform-independent steps

After the completion of the platform-specific steps, there are a few more platform-independent steps. I'll skip all of these for the video.

We can generate an SSH key for the device
Then we can install all global NPM packages for my daily use
Then comes one of the most important pieces of my setup: my public projects on GitHub. We can use the previously installed NPM package git-getter to clone all of my projects utilizing the SSH key we generated in the previous step. This is currently broken unless the previously generated SSH key is already added to my GitHub account and that's pretty much impossible before I could start a web-browser on this computer and add the key.
Finally, I take care of a few more minor steps around my Emacs configuration which includes creating a fallback Emacs directory in case XDG config directory is not supported on the installed Emacs, and then linking my configs as a default config to my dotfiles. Don't worry if you don't really get what these last steps mean, you can safely ignore them thinking that they're too specific to my personal setup.

Demo: Reboot on done

This concludes the setup with a simple reboot.

And there we have a Gnome shell login where I choose my preferred environment and log in. So we made it!

More computer-specific scripts

If I run this setup on a generic computer, I can consider the setup complete at this point. However, there could be a few more steps to make sure my setup can utilize the hardware I'm running it on. Speaking of specific hardware, a great example can be my new Lenovo ThinkPad X1 Extreme (Gen 3). I have a reasonably lengthy script dedicated for the particular device, specific to an Arch install that takes care of the gaps for that particular hardware. As I've already mentioned in my video about how I configured my ThinkPad for Arch, it takes care of a lot of things like setting up the right DPI for the 4K screen, sets up hybrid graphics with Nvidia Optimus, fixes audio issues, enables some basic power-saving, etc. This is another of those things that are still under development, but at this point, it already makes the computer much more usable than it would be otherwise without these additional steps.

This script resides with a bunch of other scripts I keep in my dotfiles for a few other purposes and is also added to my $PATH so that I can invoke it without referring to its physical location. Not that it adds any value, but why not?

Thoughts

So as we saw, setting up a new workstation doesn't take a lot of manual effort anymore. Most of these steps are also made optional through prompts so testing a particular part of the setup on a temporary system is also pretty simple as I can perform only what I want and skip the rest. One other thing to note is that these scripts keep improving over time and what I demoed today is just a representation of its state at the time of this video.

One challenge to maintaining all this code is to watch for the things that keep breaking with the changing nature of the underlying dependencies including Linux. One way to make sure there's nothing broken is to run the entire script end-to-end every few weeks, finding out what all is broken, and fixing it. What I demoed today might look close to perfect, but the more I improve it, the more it feels lacking. I guess that's a good thing as there's no limit on how much one can learn and hence, implement new stuff as well.

There's still so much to improve and as Professor Harold Abelson once rightly said, "...the constraints imposed in building large software systems are the limitations of our own minds". Though my scripts aren't nearly as big as what he referred to back in 1986, you get the point.

What my workstation setup is to me

Mohammed Ismail Ansari — Thu, 18 Mar 2021 21:55:58 +0000

This article is a transcript of a video that you can watch by clicking the below thumbnail. Hence, certain statements may not make sense in this text form, and watching the video instead is recommended.

Setting up a computer (at least to me) is a very cumbersome activity, and even more so when it's a daily driver. In this short series of videos, I'll show you how my workstation setup is almost automated so the process is pretty quick and yet convenient so that I don't have to lose my mind every time I re-configure my daily driver.

Background

By daily-drivers, I'm not referring to work laptops owned by your employer, which is a topic for another day, but take for example my personal computer on which I spend more time than I do even on my cellphone, there's so much to take care of. Also, if you're a Linux user like me, the setup is not as straightforward as it usually is for Windows, full of quirks here and there, and a lot of additional steps added to the process.

What a setup feels like to me

For a few reasons, I find a computer setup even more tedious:

Activities like this tend to quickly make me feel overwhelmed. Part of this is because I plan a little too much, noting down every trivial step as if it would make the final result any better.
I expect things to be exactly the way I want them to be and tolerate almost zero deviation in my plan. So the plan that's (usually) already so detailed, becomes even more stressful, and then there's the fear of failure and a potential loss of the most valuable entity in this human life: time.
If at all the process spans across multiple sessions, the urge to drag it to the end doesn't let me sleep with peace; and focus on my other tasks gets affected as well.

These factors (along with a few more) drove me to create a system in place such that I don't lose my mind every time I configure a computer from scratch.

Two kinds of setups

During all these years, I've performed at least two different kinds of setups:

Full setup, which could either be on a new machine or hard-drive or it could be an old machine undergoing some low-level changes in the setup like the partition table such that there's total data loss. This is the one I'm usually scared of, as there are more steps and hence more number of things to go wrong.
Partial setup, which is a re-setup utilizing a decent part of a previous setup such that I don't lose everything, and can continue from somewhere in between by refilling the gaps on the existing setup. This is the easier of the two kinds.

My setup as a code

Since I moved out of Windows, one of the many things I loved about these UNIX-like operating systems (Linux and macOS) is that everything that can be done through a graphical interface as the normies do can also be done through the command-line. To me, the most obvious advantage of being able to do things over the command line is that one can create an automated script which when executed, can perform the same steps as many times as required, with virtually zero error.

I used this possibility of automation to convert my workstation setup notes (actually spreadsheets) into a single Bash script, which later-on evolved into a fully-fledged arrangement of scripts that can be considered as an independent program which as of today, constitutes a significant part of my dotfiles on GitHub. We'll have a detailed look at it in just a moment.

Principles of my setup

Time for some theory now! I promise to keep it as less boring as I can.

There's no such official standard I follow in my setup scripts, but now that I think about it, I see at least four principles being followed very closely:

Lean: This means that not only the scripts are as DRY as possible, but I've also tried to make sure that my software selection is such that it only includes a single software for a particular job. If at all I find a software that can replace two or more of the others already on the list, especially if it improves the results, I shorten the list by replacing the old candidates with a single new candidate. It also implies that I don't have a single software in the list that has no purpose in the system.
Reproducible: This was in fact the primary purpose to create this entire thing, so that I can re-create my software-setup with minimal effort or confusion, as many times as I need. This also means that every single persistent configuration change that I make on my computer needs to be done in a way that I can automate it. I shouldn't need to remember anything, the scripts should be capable of re-creating it for me. A simple example could be changing the default user shell.
Documented: This comes from the fact that I've placed plenty of comments for my own future reference, and also a lot of times the way the scripts have been arranged, that documents much of it. All this keeps evolving just like any other computer code does, but it always represents my most current computer setup for all the primary operating systems I use on all my personal computers, which at times could be two or three, each running a different operating system.
Portable: It goes without saying that as all this is hosted on GitHub, my dotfiles are completely portable and the setup can be executed on any computer with internet access. So not only do I carry my installation scripts, but I also have access to the same configuration files on each of my computers. An update is as close and simple as a git pull.

How it started

As I mentioned in my earlier videos that I used to be a Windows user for 14 years until I switched to Linux in 2013. I started documenting my workstation setup on my first laptop computer, the 2010 Dell Studio 1558. It used to be a reasonably detailed spreadsheet file, briefly mentioning the items my setup comprised of. Out of all the file versions I ever created, only one file was for Windows, but as I moved to Linux, a new file got created for every Linux distribution I hopped through, and the number was obviously not small.

I slowly started to introduce "category" as a column to group those applications (and games) and I learned that you could quickly aggregate a column of cells into an installation command that could install all of the applications at once. This definitely came from my younger brother, who was way ahead of me in the way he used Linux back then.

At one point, I eventually started maintaining a single bash file in my GitHub dotfiles with the command and so there was no need to maintain spreadsheets anymore. This arrangement also allowed me to document the commands required to configure additional package sources and remained as a single file for quite a long time until one day it all of a sudden exploded into multiple smaller files each for its own purpose.

There were at least two major overhauls to this project in the following years. The first one was when I switched to macOS and wanted to make it work on two different operating systems at once. Then it mostly stayed that way with minor updates until my turning back to Linux that happened in late 2019, where at one point there were four different operating systems supported at once. For obvious reasons, the only two to remain there today are Arch (my primary) and macOS (just in case).

Then came twiner

I keep mentioning Linux for Everyone repeatedly and also the latter half of 2019 which was the start of my return to Linux for the second time, and that was actually the time I got to learn more about Linux than I ever thought I would. I looked at Bash from a completely fresh perspective and started applying my learning to various projects of mine, including project-euler-solutions. What this project actually is, it's way outside the scope of this video, but you can find the link in the description and check it out yourself if you're interested to know anyway.

I never had a proper introduction to shell scripting before and as far as I remember, my first shell script was indeed the simple packages installation script for my Linux setup. Needless to say, I started improving my setup scripts and soon realized that most of the scripts that I was writing could be re-used. Around the same time, due to my failure of being able to run a regular Linux distribution on my Dell Precision T3600 desktop due to the incompatibility of the super-old hardware with the latest Xserver packages, I literally had to learn setting up a command-line Linux for graphical use. More configuration meant adding more code to my setup scripts, and all this extra code was a perfect candidate for my library of functions for Linux setup and this led me to create twiner.

Twiner (as I call it) is a collection of Bash scripts for configuring Linux. It can either be used as a standalone program or otherwise as a library to build your own. Currently, only three major flavors of Linux are supported: Debian/Ubuntu, Fedora, and Arch of course. These along with the derivative distributions of these major distributions cover the greater part of the Linux community, at least for the non-veterans of Linux.

I moved back from macOS to Linux and I'm loving it!

Mohammed Ismail Ansari — Thu, 18 Mar 2021 21:33:50 +0000

This article outlines my transition back from macOS to Linux with the help of references to the videos in the series I created last year. You can find the complete playlist here.

A recap of my computing experience

In the first video, I talked about my computing experience that started from Windows back in 1999, traveling through several Linux distros in the next few years, finally settling on macOS. After the brief history, I talk about the reasons for my return to Linux and also list down a few pros and cons of the move in relation to my new machine.

My return to Windows for a very short while

In the second video, I describe my experience with Windows after several years for how it feels especially on the new device, and then I also briefly talk about my experience re-setting it up to make space for my primary Linux installation.

Setting up my new machine with Linux

In the third video, I dive deeper into the details on how I configured my new machine with Linux with a backup Windows partition and also talk about the challenges that I faced and the steps that I took in a little detail.

Setting up Nvidia hybrid graphics

In the fourth video, I talk about how I configured Nvidia hybrid drivers for my device and also the challenges that I faced, the limitations of the setup and, my custom tweaks to the arrangement.

Gaps and Issues

In the (then) final video I talk about the gaps and issues in my setup that I wanted to fill in after successful migration from the macOS ecosystem to Arch Linux.

Further

After I posted the fifth video in the series, I've taken care of most of the gaps and issues in my setup and will be making another video to talk about the fixes soon.

I'm totally loving my new setup. Do throw in your thoughts in the comments and hopefully, I can learn about something I might have missed.

5+ ways how Rust makes you a better programmer: An initial review of my new favorite programming language

Mohammed Ismail Ansari — Mon, 09 Mar 2020 21:54:23 +0000

[This story was originally posted on my personal blog]

With my recent dive into Rust as a low-level programming language and brief experience in its eco-system, it managed to impress the programmer in me.

Through balancing powerful technical capacity and a great developer experience, Rust gives you the option to control low-level details (such as memory usage) without all the hassle traditionally associated with such control. - RustLang Book

It feels like it tries to protect me from the remotest potential trouble I might run into unless it feels that the code that I write is 100% safe.

In Rust, the compiler plays a gatekeeper role by refusing to compile code with these elusive bugs, including concurrency bugs. - RustLang Book

Upon reading the initial few sections of the Rust Lang documentation (and this would probably be the first time I'm reading the documentation for a programming language with such great detail), it didn't take me long to come up with the below-mentioned reasons for how Rust tries to make me a better programmer.

A mutation is only allowed when explicitly declared in advance

All variables in Rust are immutable by default. Once set, the value of a variable cannot be changed unless the variable was explicitly declared as mutable back when it was first declared.

let my_name = "John";
my_name = "James";

The above would fail to compile as the variable my_name is immutable. However, if you would have declared it to be 'mutable', it can very well be changed later on.

let mut my_name = "John";
my_name = "James";

This might appear to be very limiting at first but it helps eliminate potential bugs occurring when a part of your program assumes that it is the only one making changes to the value of a variable but it has been changed from elsewhere as well. It also automatically makes your programs concurrency ready.

You can use the same name for multiple variables

In many programming languages, a variable can be shadowed when an inner-scope uses a variable of the same as the one outside. For example, in the below arguably useless JavaScript snippet, the variable i is shadowed:

const i = 0;

if (someResult) {
    const i = 1;
    someFunction(i);
}

Even though a variable i exists in the outer scope with a value 0, the value passed to the function someFunction will be from the one in the inner scope and will be 1.

In Rust, you can shadow a variable in the same scope. It can help you condition or polish a value and store it in a variable of the same name rather than having multiple variations of a variable.

So, instead of

let spaces = "   ";
let spaces_len = spaces.len();

you can write

let spaces = "   ";
let spaces = spaces.len();

and then refer to the count of spaces using the variable spaces, rather than having to maintain two separate variables, one containing the actual spaces as a String and another one to hold the count as an int.

It encourages you to handle potential failures explicitly

Many operations in Rust return you a value of type io::Result, which is an enumeration of possible outcomes of an operation, Ok and Err, the first indicating that the operation was successful while the other indicating that something went wrong.

The below line would read user input from the terminal and store the result in the specified variable user_input:

std::io::stdin().read_line(&mut user_input)
    .expect("Failed to read line");

Though the call read_line would work on its own, calling expect on the result of the operation prevents Rust from complaining that a potential failure was not handled. Please note that this is not the best way to handle failures, but a practical solution would be way outside the scope of this article.

There is no way you can use multiple `return`s in a function

There is no return keyword in Rust. I relate it to the Lisp family of languages where everything is a list. Even a function is a list of expressions and the return value is the last item in the list.

Consider the below code in Lisp:

(defun add (a b)
    (message (concat "You passed "
                     (number-to-string a)
                     " and "
                     (number-to-string b)))
    (+ a b))

You would've noticed that the above function definition doesn't contain a return keyword and yet returns the sum of the two input arguments. This does not only save you a few key-strokes while typing the code but also makes you a better programmer by forcing you to design your functions such that they only have a single return path and hence are easier to be interpreted.

An equivalent code in Rust would look like below:

fn add(a: i32, b: i32) -> i32 {
    println!("You passed {} and {}", a, b);
    a + b
}

Notice the absence of a ; at the end of the last line of the function add, which makes it a return value. As Rust is an expression-based language, any line ending with a ; is considered as a statement (which almost always performs a side-effect) while a line that doesn't end with a ; becomes an expression, which can very well be used as the last line of a function to return a value.

This also introduces us to a whole new world of programming where even an if block can return a value!

UPDATE: This was a misinterpretation being an "early" review and me jumping to conclusions very quickly without referring to complete documentation. Thanks to @jimskapt for pointing it out, Rust does have a return keyword, just that I found that using an expression as a way to return values from a function is encouraged.

It is very strict with variable references

Rust does let you work with references but it protects you from potential failures arising out of mishandling references by complaining a little too much so that you're careful with the code that you write while handling unsafe memory.

Ownership

Only a single variable can hold a value. This means, copying a value from one variable to another is technically not allowed unless... it is cloned.

let my_age = 15;
let your_age = my_age;

println!("your_age: {}", your_age);
println!("my_age: {}", my_age);

The above code is not supposed to work, if you go by the previously mentioned rule, but it does and it's only because the value 15 is a scalar value that can be easily implicitly cloned by the Rust compiler without much trouble.

However, if the value would have been of a compound type (like a String or more), the result of the assignment to your_age would have been different. The first variable would have lost access to the value with the value's ownership being transferred to the second variable.

Any code trying to access the value of the first variable at a later point in the program would then fail. Consider the example below:

let my_name = String::from("Shepard");
let your_name = my_name;

println!("your_name: {}", your_name);
println!("my_name: {}", my_name);

Because the first variable does not hold a value that is easily 'cloneable', the moment the re-assignment is performed, the value gets 'moved' to the second variable and hence accessing the first variable is not allowed anymore. It can be said that the first variable loses ownership of the value it used to possess before the re-assignment.

There could be a very easy way to make the above code work though: by explicitly performing a 'clone' operation.

    let your_name = my_name.clone();

Apart from moving ownership between variables, there are many other ways a variable can lose ownership to a value, one of which is when a variable is passed into a function. It is said that the variable goes out of scope. Once that happens, the value can only be accessed from the variable if either of the below is true:

When the value is returned from the function being called:

Consider a function introduce that only prints a provided name:
```
fn introduce(name: String) {
    println!("I'm {}", name);
}
```
When a name is passed to the function,
```
let my_name = String::from("Shepard");

introduce(my_name);

println!("Like I said earlier, I'm {}", my_name);
```
The above code fails as the variable my_name loses ownership to the value as soon as the function introduce is called.

One cheap (but probably not the right) way to fix this is to return the value to the outside scope from within the function. The introduce function would then become:
```
fn introduce(name: String) -> String {
    println!("I'm {}", name);
    name
}
```
and then we would also capture the returned value in a variable (probably with the same name?)
```
let my_name = String::from("Shepard");

let my_name = introduce(my_name);

println!("Like I said earlier, I'm {}", my_name);
```
A reference of the variable was passed in the first place:

This is called 'borrowing' a value, instead of 'moving'. Consider an introduce function that accepts a reference instead of a value:
```
fn introduce(name: &String) {
    println!("I'm {}", name);
}
```
And then we pass in a reference to the name instead of the value itself:
```
let my_name = String::from("Shepard");

introduce(&my_name);

println!("Like I said earlier, I'm {}", my_name);
```
But then there are other limitations with passing around references and this needs to be done carefully as well.

Only one mutable reference to a variable is allowed in a scope

A reference like the one we saw in the previous example cannot be used to change the value of the variable. For such cases, a 'mutable' reference needs to be passed around.

However, Rust imposes restrictions on that as well: you can only have one mutable reference to a variable per scope, just for safety.

The below would fail to compile:

let my_name = String::from("Shepard");

let ref1 = &mut my_name;
let ref2 = &mut my_name;

And obviously, that's because Rust doesn't want you to get into trouble when the changes to the value pointed by the two references are performed from two different parties, thus potentially resulting in unexpected results.

You cannot pass around a reference to something may not exist

Consider the below function that returns a reference to a variable that will soon be no longer existing

function get_my_name() => &String {
    let my_name = String::from("Shepard");
    &my_name
}

The variable my_name is only valid within the scope of the function and passing around the reference of a variable that will not exist is not a good idea.

Only safe references are allowed

When Rust comes across a situation where an invalid memory is being accessed, the program fails instead of allowing the memory access and cause further damage.

let numbers = [1, 2, 3, 4, 5];
let index = 10;

let number = numbers[index];

The above code fails at the point when an 'out-of-bounds' index is being used to fetch a value from the array.

Some other notable great features of the Rust eco-system

The language itself lets you code faster

Though the language might feel very difficult to initially begin with, there are features like implicit typing of variables that make it easier to work with those limitations. There are many similarities with older languages like 'C' but newer constructs like tuples and vectors make it very useable in today's programming scene.
Its tooling is awesome

Having spent over 8 years with Node.js and then stepping into a systems programming language like Rust, I didn't expect an ecosystem this modern. I found many things that I could relate to:
- Npm -> Cargo (Build tool, package manager)
- package.json -> Cargo.toml (Manifest file)
- npmjs.com -> creates.io (Package registry to access thousands of useful crates)
Packages would now be a crate, be it a binary or a library.
rustfmt

rustfmt is a tool for formatting Rust code according to a universally agreed-upon coding style. This would help developers focus on the logic of our programs rather than argue about how the code should be looking like. I've faced a lot of that in the JavaScript world where there are more standards than one could think of.

Much more to learn about Rust...

It's been a few months since I've started looking into Rust but given my learning schedule which has tremendously slowed down since we moved into this year, I could not dive deeper into the language yet.

I did create a playground for myself though, where I plan to practice the language and am hoping to create some useful tool with Rust soon.

A few clean-ups to relieve stress

Mohammed Ismail Ansari — Wed, 19 Feb 2020 00:14:24 +0000

[This story was originally posted on my personal blog]

I've always had this itch of organizing the stuff that I come across every day, sometimes to an extent that it's over-organized for me to access later. It's partly because my mind keeps on shifting its perspective of how I see (and want to see) things around me and otherwise it's something that comes straight out of me being an over-thinker for things that do not need that much of thinking. I might arrange objects in a particular way, only to completely remodel the entire space, arguably making my previous attempt to make things 'right' look like a complete waste of my productive time.

The following are a few items that I enjoy cleaning up and believe to be reducing my stress.

To-Do list

My To-Do list keeps growing like crazy. It does help me track ideas and the things that I might need to be doing, but as it grows it tends to scare me with what's upcoming (especially the looking at the count of items in the list), often leaving my mind in a state where I find it very difficult to focus on the tasks that I currently have at hand.

To me, cleaning a To-Do list could either mean scheduling items that are still in the unscheduled state, better organize them by re-assign tags that make more sense to me (at that particular instant), or even deleting the items that I might have added a while back and do not seem to be worth doing or even making any sense at the time of the clean-up. And yes, it also helps me look past the mess I have in front of me.

I can discover tasks that were planned way back but got lost among other 'less important' ones. Finally, it also helps me discover the 'filler' tasks that I could potentially pick up when there's relatively nothing else to do, which I know is rarely the case, but who knows?

Digital notes or lists

My digital list collection is another place to look for those buried lists and plans that never got converted into tasks and eventually scheduled and picked up to be worked upon. On the other hand, there's so much that does not need to be worried about or carried around anymore.

It mostly does not cost anything to keep this kind of useless data around, especially if you're on a free plan on the platform or service (Dynalist in my case) that you're using to maintain these lists, but when taken out, it does help me to find what I might be looking for faster and easier.

Web-browser bookmarks

No matter how much time I spend on my collection of web bookmarks in Google Chrome, it doesn't take long for the tree to grow out of control and very overwhelming to look at.

Bookmarks can get accumulated quickly, especially with my pattern of web-browsing. It goes like: anything interesting that I come across and/or I feel needs more time and dedicated attention gets thrown into a subtree that I usually revisit regularly. As the second step, these deferred bookmarks get further categorized and sorted according to priority and subject. When the time finally comes to visit the web-resource it points to, it either gets deleted after sharing it with people who might find it interesting or stashed into the rest of the well-organized tree for almost forever.

My tree has been growing since I first started using Google Chrome, which is almost a decade now. Funny enough, I used to maintain an excel worksheet of internet URLs that I wanted to store as a future reference instead of saving them as 'favorites' on my Internet Explorer as they would otherwise be lost. As the bookmarks on my Google Chrome are associated with my account and the task of maintaining the collection for me is now taken care of by Google, it is the right place to maintain that kind of data. I recently conducted a moderately deep clean-up in my bookmarks collection and what I got from the result of the time-consuming (and arguably boring) activity is what I believe to be one of the cleanest bookmark collections I've seen to date, not that I have a habit of peeking into people's bookmarks.

Projects kitchen

On all my computers, I have a projects graveyard where I perform coding experiments and most of the code residing there never makes its way out. Although some developers share their collection on GitHub or other similar places, I keep mine private and call it 'kitchen' on every single workstation of mine. Most of the ideas developed and polished there get life in the form of some other public project but the mess in the kitchen tends to keep growing quickly.

Visiting these directories every once in a while and getting rid of waste helps me come across any unfinished experiments or at least helps me free some space on the tiny SSD on my MacBook Pro. Regardless, cleaning the kitchen feels great.

Digital data on hard-drive or cloud

My digital data on the cloud tends to get out of hand as well. During my early years of using computers to store data, this kind of data used to be stored in smaller hard-drives and USB flash drives that were far easier to run out of storage capacity on. With my not-so-recent move to virtually infinite cloud-storage, space is not an issue anymore, and I expect it to be that way for at least another decade before I start running out of space again. However, re-arranging files and deleting unrequired data gives me a sense of satisfaction greater than what I achieve after refactoring a piece of code that I wrote a decade back.

Apps, extensions, etc. from my setup

It could be unused software on my computers, apps on my phone(s) that I might have never used and forgotten about, plugins on my text-editor or even extensions on my web-browser, the list can go on. Apart from the most obvious advantage of speeding up my work environment by removing the redundant bloat that not only do I not need anymore but also do not remember the reason to exist, it makes space for new stuff to come in: think new apps, extensions or productivity tools, etc.

More...

There's much more:

Email subscriptions so that I do not need to delete multiple emails from the same sender every day as if it was a daily ritual
Games library so that I don't feel bad for myself every time I come across it on discovering the huge list of games that I own but do not have time to play anymore
Browser autofill info so that I have a shorter list of credentials, addresses, payment methods, etc. to choose from while filling a web form
Physical desk so that I have to move lesser stuff around for being able to access other stuff
My car not because it helps me in any way, but I just like doing it down to the smallest detail possible

As you might have guessed, the list does not end there.

And beyond...

More than the amount of stress relief I tag these activities with, I also believe that they grant me some sort of a short-term productivity boost. I feel a little more focused and motivated towards doing what I'm currently doing, and that too with a fresh perspective until there's need for another round of clean-up.

How I manage to meet most of my deadlines and still keep myself 'mostly' motivated

Mohammed Ismail Ansari — Fri, 27 Dec 2019 04:59:07 +0000

[This story was originally posted on my personal blog]

In this age of technology overload, to say that it's difficult to keep up with life would be quite an understatement. In fact, it's very easy to miss things going around you. You can imagine those things to be the ones that matter to you, and that is different for different people. They could be things like technology trends, utility payment due-dates, doctor appointments, and even family events, you name it.

For a couple of years now, I've been driving my daily life with the help of a group of things that I collectively use as a system. Following these self-imposed guidelines has been helping me meet most of my short-term goals with relative ease, punctuality, and an ample peace of mind.

My system in place

There are always going to be failures and my system is not flawless either, it just helps minimize slippage of my tasks and responsibilities. Talking about failures, I fail too often with varying degrees of blunders. Sometimes that does shatter my confidence but otherwise, it helps me adapt in a positive manner.

My system comprises of many habits, tools, and services that are a part of my daily life. Though it has been working for me for a few years now, it keeps evolving as I learn more about my responsibilities and my own self in general. I'll describe a few major elements of my system in this post.

My To-Do list

GTD (Getting Things Done) is the biggest of all the elements of my system. My To-Do list defines and drives the most part of my life with inputs from my own self. Some inputs are automated and recur according to a pattern and/or a suitable frequency.

I've written multiple posts in the past mentioning my To-Do list. I've mentioned recently how I hopped through quite a lot of tools to finally settle down on Remember The Milk and I've also earlier described my quest in a little more detail where I explained my reason to switch to Remember The Milk. I won't spend time to repeat the advantages of maintaining a task list once again as that's something you can easily find elsewhere on the web as well.

In the past few years, I've evaluated countless platforms. It's natural that a system that may work great for one may not at all be suitable for the other. For me, most options fell in one or more of the below categories:

Too simplistic: I need to be able to organize my task list using projects, tags, etc. and browse through my tasks in more than one way. A tool that merely allows recording action items as a flat list definitely doesn't help me.
Too expensive: Though a free service is always the best, I don't mind paying either a small monthly fee or a medium-to-high one-time fee. The number of features available in the free-tier also matters to me.
Platform limited: Given that I work with at least three platforms daily, I need my tasks to be accessible virtually everywhere. A tool that's available for only a few platforms is unusable for me.
Unintuitive: I expect data-entry and retrieval to be as convenient as possible. Spending more action-points to record a task leaves lesser to actually spend doing it.

Todoist seemed to be very well designed and not only seem to provide the features that I'd wish to have in a task management tool, but it also introduced me to a few more that I never thought could be useful. Out of so many interesting features Todoist provides, below are a few that 'almost' made me switch:

Nested projects vs flat lists
Combining multiple filters and viewing multiple lists in a single view
Subtasks are actual tasks
Better integration with the outside world
Affordable price, sort of

However, even with the above outstanding features, there was still one hurdle: most of the basic features need a subscription to Todoist premium. This matters to me even more given the fact that even though I've been wishing to upgrade my Remember The Milk account to 'Pro' since a couple of years, I'm still on the free plan and am almost satisfied with the feature set that they provide on the free plan there.

Having wasted my 30-day trial a few years back, I deleted my account on Todoist and restarted my trial to evaluate it once more with a far better understanding of Todoist and my workflow as well. However, during the process of manual data-migration (yes I prefer to do it manually as I cannot afford to miss details from my sensitive tasks), a few things didn't feel right. Data entry felt too cumbersome as it needed quite many more keystrokes as compared to that needed to create a task in Remember The Milk. I also could not figure out the condition for when Todoist sets alarms (notifications) on my tasks and when it doesn't. After about an hour of mental struggle, I reverted to Remember The Milk once again, which was naturally the safest way out of the situation and it also saved me several hours of migration.

With so many custom tools in my workflow, I've thought of creating my own custom solution more than once. I even have a private skeleton repo on GitLab with minimal setup and have it sitting as a task in my To-Do list. However, I've learned that as my mind is getting older, I'm finding a little too difficult to focus on a single project and take it to closure. Yes, it will give me all the features I'd ever like and that too without a monthly recurring expense but to create something as featureful as Remember The Milk and write all the code on my own while being a parent feels just way too much of work now. Furthermore, it will be like spending time on a project that will most probably not be released for the public and will die a slow death just like most of my other projects.

Inbox Zero

I've been following a practice known as Inbox Zero for a few years now and I should say it helps more than I thought. A few advantages include:

I don't have to look at hundreds of unread emails with a mix of information that matters to me and that which doesn't. There could be emails waiting for an action from my side, emails that need immediate attention about things like a credit card fraud transaction, emails about limited-time deals and discounts about things I do not plan (or want) to buy and other promotional emails that manage to get past the spam filters and sneak their way into my inbox.
My email inbox also acts as a secondary To-Do list that contains my on-going interactions with people. This helps me stay on top of my communication with my friends, utility and service providers, and even my potential employers.
When things are well tagged and sorted into sub-folders, finding an email doesn't feel like walking through a junk-yard looking for a specific item buried somewhere under a pile of well... junk.

I started to implement this in my mailboxes at work which was very helpful to track my professional deliverables but then after the unification of my email accounts, I've been following it for my personal email mailboxes as well. Things are so much simpler now!

Lists

It doesn't take long to realize that grocery shopping lists are not the only lists in one's life. Your life is surrounded by many more lists for almost everything that you do daily. I started with a wishlist of video-games that I wanted to play and movies that I wanted to watch but then extended it to track many other things.

A very small part of the list of things that I have as lists are:

things that I plan to learn
things that I need on a trip
wishlist of items that I plan to purchase in the long-term
things that I can spend time on when there's nothing else to do
list of my online accounts all over the web (which is the most difficult one to maintain)

I have also recently started creating lists for life sub-routines that need to be executed on a particular event like getting a new credit card or buying a new daily-driver phone or car, and many more.

To store these lists and to make sure they are accessible almost everywhere I go, I have moved between a few services like Google Keep, Evernote, Dropbox Paper but finally settled for Dyanlist for a few months. They offer a free plan that works for my use-case. These lists now act as an extension for my To-Do items from Remember The Milk because not everything can be noted down as subtasks.

Calendar

I've been using Google Calendar for tracking events like my driver's license renewal, vehicle oil changes, etc. Though I have moved most of this as well to my To-Do list, I recently started using my calendar for a new experimental use-case.

I have created themes for every single day. These are 'all-day' events that help me with a 'flavor' for the day suggesting things that I can be spending time doing on that particular day. I figured it's very easy to get drawn away with only working on a software that I'm fascinated about for a few days or learn a particular technology that has totally taken over my mind. There are so many things that need to be done and there is an equally high number of things you want to do or learn. Spending continuos time on one particular thing is definitely helpful for focus but that can adversely affect tasks in other areas. These day themes (as I have planned) will hopefully help me focus on one thing at a time and still cover the maximum area of my activities.

Now I have a dedicated day that's themed to read and learn from internet posts and videos, a day to write posts, a day to spend time learning "that specific technology on my mind", a day to maintain my open-source projects, and a few other days likewise. I can cheat and work on a thing that is outside of a particular day's theme but at least it's not as unplanned as it used to be before.

The combination of all of the above and more

The above four items drive most of my activities. On a very high level, my lists and emails tell me what to do and my To-Do list and Calendar tell me when to do them. There are obvious overlaps between them and they all work together to help me drive my day a little more systematically.

Apart from that, there are other things that I find to be boring and verbose. For that, I have some automation on my computers and phone. I have almost all my computer configuration scripted and documented so that I can regenerate the exact same setup on a particular platform with the least effort anytime, any number of times. This gives me peace of mind and helps me keep moving forward to improve my setup without the fear of not being able to reproduce it again from scratch. In a time of machine failure, my hardware will not be cheap but even more expensive could be the cost to replicate my setup.

And then there are 'time-leaks'

Just like we software developers have to worry about memory-leaks in our programs, one thing that I fear about in my routine is time-leaks. I classify time-leak into two categories:

Digital time-leak

This mostly comprises time spent on mundane tasks like trying new software from sources like Google PlayStore and F-Droid, browsing profiles on LinkedIn, reading non-conclusive posts on social media like Twitter, Reddit (and Facebook), and watching digital media through channels like YouTube, Imgur, and occasionally, Instagram.

Though most of my online subscriptions are purely for educational purposes, deviating from the intended reason for the visit a platform is extremely easy.

Real time-leak

There's too much stuff outside the digital world that makes me lose my time. Most of that comprises tasks that I cannot automate, which is mostly all that stuff that I need to do to live a normal life in the 21st century. The other major chunk falls into the category of tasks that I like spending time on, with the most noticeable one being the "hours" I spend cleaning my car. Though that is one of my most favorite things to do outside my computer screen, I tend to get into detailing even when the plan was to just give my mechanical companion a waterless carwash.

An analogy to a "scripted" routine

In the last few years, I have realized that not having to remember "what needs to be done" and focusing only on "how it can be done, better" is pretty helpful, to say the least. That extra breathing space for the mind can be used for creativity.

With most of my daily tasks scripted, I (being a gamer) look at my life as a multiplayer campaign of a role-playing video-game. I don't need to worry about which missions I need to complete and I still get to enjoy completing them, one after another not only progressing through the game but also leveling-up with those experience points as I do it.

Further from here

I plan to keep making changes to my system, trying to make myself more efficient and for that my tools may need to keep evolving. This may mean that there could be more control added, more guidelines for my own self on how to spend my time.

At the same time, I feel there should be a balance between the scripted and non-scripted parts of life. With all the productivity that I need in my life, I also want to be able to have a choice of my own. If everything becomes scripted, life might as well turn into a movie I'm playing a role in and every single event would happen only according to the script, every single moment of time.

My first decade as a professional software developer

Mohammed Ismail Ansari — Fri, 06 Dec 2019 15:27:33 +0000

[This story was originally posted on my personal blog]

Today (at the time of this writing) I completed my first decade of being a professional software developer. Though I usually hate using the term 'journey' for things unrelated to travel, I'll make this one an exception for all the mental displacement I went through during this period.

Summary

In this article, I reflect back on how I started as (or ended up being) a software developer, what all I experienced in this professional world till this day and how I saw myself change in almost every aspect of my approach towards programming, computers, and technology in general.

My background with computers and software development

Not so long ago...

'First Contact'

My first encounter with a personal computer was in 1995 when I saw it from across a glass window covered in cloth over the monitor screen and an "anti-glare" layer of dark glass over the screen. The owner of the computer was kind enough to let me play a couple of boring games on it for about an hour and that was it.

Computers at my school

A few months later, computers were introduced to my class at school. It was my fifth grade and my second experience with a personal computer, only this time officially. 'Computers' was a course in every grade until the ninth grade with syllabus consisting of the same repetitive topics, the first chapter in every grade being "Introduction to Computers" over and over again. While the world outside the campus was already using Microsoft Windows 98 and Microsoft Office, they "pretended to teach" us outdated software like Wordstar, Logo, Basic and QBasic, etc. with no context what-so-ever.

Our teachers had no idea what they were talking about, all of their speech during the lectures was based out of some hand-written notes and just tried to act smarter than the rest of the faculty for them being next-gen because they knew computers, or at least they believed they did. We did have practical sessions where they divided the class into two parts, each half taking their turn in the computer lab with three kids sharing one computer, taking turns to play PacMan or Snake (or Dragon Ball) for the entire one hour, wasting that precious time that could have been utilized to teach us basics like for example what those hundred keys on the keyboard were for. The computer fees were significantly higher by magnitudes compared to the rest of the entire curriculum and all that money just to play arcade games on a monochromatic screen without being taught what a computer was. Oh wait, they did teach us what a computer was, over and over again, in fact, that being the first statement in the first chapter for every grade and the answer was, "A computer is an electronic machine". That's all that you need to know, don't you?

I remember memorizing QBasic programs for practical exams because neither did they tell us, nor did I ever learn how the let statement was different from an input statement. Yes, they did teach us the difference between a variable and a constant in the first chapter, in every single grade till the ninth grade, but never explained to us or showed a real example for us to realize the role of a variable in a computer program.

The first desktop computer in my family

The very first computer to get introduced in my (entire) family tree (or even the neighboring trees if I think about it now) was a pre-owned desktop computer at the end of the year 1999. It had brand new white-colored peripherals including a Samtron 15" color CRT monitor and a really heavy three-button ball-mouse. The processor was an 80486 running a few Megs of RAM with a dual-boot of Windows 95 and Windows 3.1, which I had no idea about and learned what it all actually means after about a year of playing DOS-based games through memorized commands typed on an MS-DOS Command Prompt Window. Along with the well-known 'C' drive, the computer also had 'A' and 'B' drives for 3.5" and 5.25" floppy drives so I never really had the question that a kid would have today: why the drive letters start from 'C'.

It was already my two years of 'learning' computers at school by then, but I still wasn't that comfortable with computers, given the kind of curriculum we had at school.

What I thought of a computer before 1999

For me, computers almost had only two primary uses: creating those boring monochromatic documents that I saw people at my dad's workplace create, and playing fun video-games that a few computer technicians made us believe spoilt computers.

I had a Little Master TV video-game system at home that I had limited exposure to, and that was the only thing that I imagined our new computer in the house will replace. During a few conversations during recess at school, some kids talked about a few video-games that I had never heard of. I later learned that they were mostly Prince of Persia and Dangerous Dave but before I did, all that I could relate those to was Super Mario, which wasn't exactly my favorite game.

On the day the computer-guy assembled our first computer at home, I was surprised to learn that the same audio disc that we played on our Sony music system could also be played on a computer. There were a lot of unknowns though, as the need for a music player software like Winamp or Windows Media Player, which were almost the only two options that I knew of at that time.

Computer books and magazines

I had a near-regular supply of outdated Computers@Home magazines at home via a family friend between 1999 and 2001. It formed my second most read written material after my mathematics textbooks from school.

It was quite similar to Digit and PCQuest, which were two of the very few computer magazines available in India back then. Getting my hands on a new magazine issue every month was exciting and something that I looked forward to. I read all the answers to the questions from readers they featured every month. Yes, I don't remember people talking about online forums back then. People literally mailed them questions and waited for an answer to be printed in the next magazine issue. Every issue came with a compact disc containing goodies that ranged from essential software like WinZip and WinRar to Windows Media Player and Winamp themes to video-game demos. Not having an internet connection at home, the disc was our only source to update Winamp to the latest version.

We also took a subscription for a year so that we received the latest magazines along with the latest software versions without that one-month delay and this time we didn't have to return magazine (and the disc) after reading. I still have them stashed at home back in India just for memories.

Computers, Indian kids and Indian parents

I come from a (lower) middle-class Indian family where computers were (and to an extent still are) considered hazardous to kids as they are believed to be a distraction from studies. It's almost as if (and it may sound hilarious) access to a computer at home could potentially ruin the 'career' of a child.

As soon as I realized the potential of computers, my interaction was not limited to just playing video-games anymore. In fact, I used the desktop at home to learn things, contrary to what my elders must be imagining that I was losing a few marks in my exams with every minute spent with the machine.

Discovery of my resonance with computer programming

There was no doubt anymore that computers were helping me so much. I was learning things at a rate I never did before. It was partly because I was not the regular kid who would go out and play with my friends after school and learn a few things here and there, but I was one who didn't know what to do with my time once I'm home apart from drawing weird little shapes on paper with a worn-out pencil and counting them in different order every time.

I improved my hand-writing by closely observing computer fonts, learned English as a spoken language from dialogues in video-game demos from those monthly compact-discs (we almost never bought full games and that wasn't a time where there used to be free games). Neither did I have an idea that I'd have a career with computers, nor did I know of a way to convince my parents that computers aren't hurting my academics but are helping me and hence my interaction with computers remained limited.

Being a computer/gadget geek at school

With my interest in all things computers, I always had an edge among my friends in school. In ninth grade, I took the initiative to understand most part of what those QBasic programs meant. I finally appeared for my computer practical exams without re-memorizing the same programs that were taught in previous grades and managed to clear the tests writing all programs on my own. That's what I call progress!

My non-CS education

I took up engineering after my high-school which was fairly rare in India in the early 2000s, where most of us (especially kids from my community) were to choose between either science, commerce or arts. It was almost the start of a trend for Computer engineering over there right when I was in the decision phase and I definitely decided not to pick that option mostly because it was too mainstream. There were a few other majors that I could've gone with including Automobile engineering (for my love for cars) for which there were no colleges in my city and Mechanical engineering (out of my interest in physics) for which a few people scared me about how difficult it would be for me given how physically weak I was in school. Almost no one from my community had ever traveled away from home for education so how could I?

I started with my course of Diploma in Industrial Electronics engineering which was fairly easily available in colleges nearby. I joined as a computer nerd with plenty of interest in learning about computers but with almost no understanding of computer programming. With the limited exposure that I got with computer programming subjects in my college, I had no resources to reach out to in order to learn more. I was probably the only one in my entire classroom who enjoyed our first programming subject: "Programming with C" while the rest of us were really scared of it. Their fear must be partly due to the way it was presented to us. I consider myself lucky to get past it and still end up liking it. There were instances when I was the one to reach out to for solutions to errors in programs during practical sessions, sometimes even by the educator.

In 2009, I graduated as an Electronics Engineer looking for a career in computers. It was exactly the other way around for most of my friends and classmates where they were being pulled towards this profession out of limited opportunities in Electronics or anything else in general but they were still scared of programming and had limited to no interest in working with computers.

My first job as a software developer

And the decade finally starts...

On December 7th, 2009, I started working with Infosys Limited in India, the second-largest software exporter in the country at that time.

My entry into the 'corporate' world

As it is mostly the case for engineering graduates in India, my first job was through a campus placement drive where I was offered a job more than a year before I completed my degree in Electronics engineering. Out of about 480 of us appearing for the recruitment drive that day, I made it to the final 11 to get a job offer. I later learned that I barely passed the tests before the final HR interview, but somehow managed to convince the interviewer that I was worth hiring for even an entry-level role as a software developer, even with terrible communication skills and close to zero general knowledge.

The job started with a six-month training on a specific random technology stack that they thought would work for my group. The entire batch of hundreds of candidates from all over the country was divided into groups and put into technical training for a very specific technology, which followed after a mandatory three days of "introduction to computers", once again! The ones among us with a computer science background were exempted from the 'basics' and were assigned projects way quicker than us. Needless to say, the training was by far my best days at the company where I got to learn quite a lot about software development at the pace that suits me, sort of what I always dreamed of during my engineering, which was spending a little more time with variables and methods than with filters and amplifiers.

How things were different than what I imagined them to be

The training ended in about six months and we were again randomly assigned to projects according to some fictitious business requirements. The assignment made no sense at all, where a colleague of mine who went through rigorous training on Java for around six months was now assigned a project based on .Net. On the other hand, after nailing my .Net stack training, I was assigned a project based on some alien technology where programming was not even remotely involved. It was Siebel CRM, completely out of a random.

It wasn't that I was afraid to learn something different, but looking at a few people who were working on the technology (and in the team) for a few years, it was not that difficult to figure out that it was not the kind of work (or place) I'd want to spend time at. Many people in the team had lost the ability to think like a programmer or to an extent, even write a basic computer program!

Me being trapped in a toxic work environment

I worked on a couple of projects at my first job. The first one gave me a few very haunting months of my professional career. Nothing 'taught' to me during the training was even remotely helpful in my first project assignment, be it technical skills or professional skills. Work-life balance was worse than terrible and most of my team-mates including my manager made me feel that I don't belong there in the first place and looked down at me.

I couldn't believe that someone like me, who aced in almost every effort related to programming during my school and even the technical training right before this job was now facing issues to deal with work pressure on the kind of job that I was supposed to be comfortable at. I spent most of my time learning .Net, having fun writing my own programs and sort of preparing for my next job during late hours after work until around 01:00 AM every day.

Leaving my first job

I couldn't continue working like that where work was punishment every single day. Out of the disrespect and demotivation at my first job along with irrelevance to technology, I switched my job. After wasting around two years of my career working on (or pretending to work on) things that didn't make any sense to me, I took a job as a .Net developer with zero professional (but plenty of practical) experience on the stack.

Further into my professional career

Life gave me another chance to work with an entirely different crowd, and this time it was a team of exceptionally talented people at my second job. Except for the initial few weeks of imposter and insecurity, life was now fun again. I got to work with people who not only helped me at work but also encouraged me throughout my term at that job.

Another unplanned shift in my career

My second job brought an unplanned shift in my career. Just like my first job, this one was not exactly around what I wanted to do: the job title was ".Net development" but now I was a front-end developer. Because I started with CSS, I was unofficially referred to as a UI developer for quite a few months, later stepping into the rest of the front-end. I quickly became one of the best with CSS at the organization.

I was still missing writing VB in Visual Studio, the feeling of being able "fly with code", talking to the computer and communicating exactly what I want from the program. However, on the other hand, going back to basics like HTML, writing my first CSS style-rule, and finally realizing what JavaScript was all about was just priceless.

A few months into the front-end world, I started replacing all my previous personal web-implementations with front-end code written using open technologies. JavaScript helped me reduce my dependency on ASP.Net, plain HTML and CSS helped me get rid of Silverlight controls written in XAML.

Massive switch in my expectation from computers

Moving from proprietary technologies like VB, C#, WPF, Silverlight, and .Net in general to a few as open as JavaScript that can run almost without any external dependency, my tool-set began to change as well. The only thing 'Microsoft' in my entire stack was all that was required to compile and run my ASP.Net websites.

My brother (my first human contact, my partner in all things related to technology, my teacher who also taught me computer hardware, and my successor who's better than me in almost everything I do) tfKamran, just like he always comes up with new stuff, also introduced me to the world on Linux. That new direction changed the way I looked at computers for the rest of my life.

This did not happen all of a sudden but over a period of a couple of years during which we carried an instance of Ubuntu Gnome on a USB flash drive with us for cool stuff that we only knew one could do on Linux. Somewhere in 2013, I took the leap and replaced Windows on my first primary personal workstation with Ubuntu Unity 13.04. This did get me scared about my .Net dependent development tasks for which I had a VM running Windows 7 for over a year on my constantly changing Linux distros, while the rest of my setup could now reside naturally and with ease on Linux. A little further into the timeline, I replaced my entire .Net dependent code with JavaScript running on Node.js and gave up Windows entirely, except for a few video-games running via a dual-boot with a reasonably sized Windows partition on the same hard-drive.

Working with Linux taught me so much more than I would probably have ever known about computers. From running commands in a terminal for everyday tasks instead of using the graphical interface, to maintaining my workstation setup scripts and whatnot. Not to mention that inexhaustive list of choices for Linux distros, desktop environments, and window managers, etc. This also helped me cope with the Carpal tunnel syndrome that I acquired during my first job as I had limited use for a computer mouse with my increasing use of keyboard shortcuts.

A few years later, both of us switched to macOS with him leading once again as always. This did not change our operating system this time but just added another dimension to our computing experience. I still have at least one instance of Linux residing in a virtual machine on my MacBook Pro to still be able to play with toys like Fedora, i3wm, etc. just like the old times.

Finding resonance also at the workplace

Working on cool cutting-edge technology and with a great team brought my love for programming at work back to life. Adding to that my first best friend from work who was also my team-lead, coding at work was enjoyable again. Apart from our project deliverables, I also participated in various official and non-official technical training, coding-competitions and other technical fun activities in the company.

I gained a new hobby: presenting technical talks in front of a group of people, which is something that given my personality, I never thought I would be able to. In fact, once I literally turned-over a request for a front-end training in the organization saying that I won't be able to pull it off especially in front of an audience full of people whom I have never interacted with before. Later after a few months, I received "the best trainer" award for a quarter, just proving the point that things were different now.

My introduction to open-source and free software

I was introduced to open-source software right in the middle of the decade. Some of it came to me due to the kind of work I was doing and the rest with the tools I was using for the job.

Discovering GitHub

Many of the libraries that I worked with for my front-end development role were found on GitHub. For me, it was a portal where downloading a library was an exception. They kept suggesting that one could clone the source which was something that I had no idea for what it meant or how it would help me either.

My first project on GitHub was one to contain my solutions for problems on Project Euler. All my solutions were in JavaScript, a language that I used to hate not any longer than half a year ago. During the same time, a random conversation at work (with the same person who made coding at work fun) about another alien term "Emacs" changed "the world" around me, giving birth to my second GitHub project that I used to store my personal configuration. I literally didn't know that a practice to store one's Emacs configuration as a GitHub project existed until I posted a "barely-working" configuration and later found a few very mature ones. Fast-forward to last month, I just made my 500th commit to the repository and decided to create my 71st project for the very same thing, in order to once again extract my Emacs configuration to a separate repository of its own.

From `txt` to `md`

I started with not knowing the purpose of an md extension for a text file to hold plain text and ended up realizing the importance of the Markdown language, learning it, using it and even teaching and promoting it at work. Now I had my own README.md files for all my source projects on GitHub and also made a few attempts to use the language for much more than just documentation.

At the time of this writing, I had already made five attempts to create my custom presentation tool out of which three of them used markdown as a language directly or indirectly.

Being an active contributor to the community

At the end of the decade, I ended up owning over 70 open-source repositories at GitHub around a few different areas of software. There are:

Front-end libraries
Node.js libraries and apps
Small web-apps
Emacs starter-kits, extensions and color themes
Google Chrome extensions
Project templates and boilerplate code
Documentation projects, lists, and training-material
Docker images
My dotfiles and Emacs configurations, the kind of stuff where it all started
... more

Many of them are libraries and extensions that are hosted on package managers and archives for their respective platforms.

I finally crossed 1k reputation on StackOverflow and a little on a few other StackExchange communities. I created a few failed YouTube video series on my channel and wrote a bunch of boring posts on DEV.to with almost a thousand followers. It's hard to believe that there are real people that find me worth listening (or reading) to. :)

A few noteworthy experiences

Ten years is a big time to be able to recollect experiences from those exactly a hundred and twenty months. Below is a very small list mentioning a few significant ones.

Humiliation and discouragement at the start of my professional career

My first professional project assignment not only still upsets me, but also haunts me to a certain degree. Leaving out the fact for how a high-performer from the on-job training could prove out to be a low-performer on the real job, there were way too many issues at the set over there. Workaholic managers who didn't care about the personal life of their teams, arrogant team-mates who made every effort to scare and intimidate new joiners, people who ensured job security by keeping their code as encrypted as possible to make it almost impossible for someone else to do the job, and the list goes on. I expected (and still do) team-members to help new people and get them on board, not only as a gesture of good-will but also for their own good in the future. The culture over there was exactly the opposite.

I was asked the reason for not using my brains at work and was even indirectly asked to consider changing my profession. Well, here I am, I just completed a decade being a software developer and that person works right in the neighboring state. I'd love to meet him one day and talk about my incredible experiences after I left his degrading team.

Realizing that I'm not a "star"

I was told at my first job that no matter how many times my colleagues and I will change our jobs and wherever we go in the future, we'll always be standing out from the crowd because of our talents and skills. However, my second job was an eye-opener where I got to meet a few very talented and hard-working people, only to quickly realize that I'm not kind of "star" they told me I was.

There were people who were far better at their job than me and my training batch-mates from my previous job. It was just that they were not only getting appreciated for that kind of performance but were also getting compensated well for the job without the toxic environment I had to spend months of my life in.

Being asked to slow down at work

This was another shattering moment for me when I received instructions at work to slow down and not work a little too hard outside my boring daily job. Not able to contain my passion for computer programs and technology, I was just trying to do my job a little better than they would've expected from me at that role, not realizing the kind of insecurity it poses to people who've been there in the organization since a few years before me. I'd not use any names here (nor would it be of any positive help), but all I'd say is that it was really devastating.

People stealing credit for their own career path

This is something that I'm sort of used to now. This hasn't happened to me just once or twice. Moreover many instances ended up the other party getting publicly applauded and even offered a promotion. It's also a mistake at my part that I tend to take every question asked at work seriously, even those discussed in small-talks and side-conversations and end up not only losing the credit for it but see it reach the masses through someone else who did not even have the courtesy to pass a small credit or acknowledgment for my selfless help.

A few things that I learned

Learning technology was relatively easy but the decade was full of learning other things as well.

Cool things vs Real-world code

It's very easy for a technology enthusiast to drown in fascination with new things showing up on the surface of the earth every day. As you get familiar with new stuff, get a little comfortable with it and realize the good things that it brings in your software, you tend to use it in every single implementation you create. At work, not everyone welcomes (or even accepts) change that quickly which makes it a little difficult to introduce "that cool thing" in a team of more than a single person, which otherwise would have been just you.

Having said that, it's not impossible to do that either. I've seen people pull that off without much reasoning and end up changing the entire codebase just because they 'think' something awesome is out there and we should use it. On the other hand, I've been into situations where I could literally see a solution to a particular problem but failed to convince my team to use it either I wasn't assertive enough or they didn't trust me due to being new at the job.

Loving your job vs Being good at your job

I'll start by stating that even after spending hours with code outside of work daily for over 15 years now, I think I'm still a mediocre developer. My passion for software and technology may not be having an effect on how professionally effective I am. I've learned that one won't always be great at something one loves to do.

One example of this comes from my unpopular interest in mountain biking. I love it but suck at it at the same time. I've spent months trying to get even a basic bunny-hop to work but failed to lift the rear-wheel in the air by more than even an inch. In fact, I did end up hurting myself at multiple places back in late 2018, eventually indefinitely postponing my learning.

Speed vs Experience

I've learned that there are at least two ways to solve a problem: speed (which in most cases is pure brute-force) and experience (which I relate to smart-work). I realize that over the past few years, I may have lost the speed at which I code, but I've gained experience and resilience so that I can take those shorter routes facing more resistance and reach the desired goal with lesser effort and maybe even earlier.

Skills or Number of years

During the earlier years of my career, I used to believe that the number of years you spend in this industry dictates your growth. Then I came across a few people who proved me wrong by growing way beyond their year count in the profession. Later I thought that it must be your skills that help you grow, only to learn that I was wrong even this time.

Now I realize that there is no single variable for success but it's a combination of many factors that you don't get to see in the final result. I've also seen a person with far superior skills not receiving the kind of attention/respect/ears/(or whatever) one would expect for being good at their job compared to a person who has spent more years with the same company and has been around for long at the same place. This could be exactly the opposite where a new member of the team may end up stealing the show even though they may not be adding that kind of value that the older team-members may be adding.

It's all very complicated and I'm still not sure what it is. Maybe it needs more of talking, maybe a little more bragging, or maybe stealing other people's work for your own credit? Just saying.

The purpose of writing this article

One of the main reasons for me to write this article was to reflect back at the last decade to not only realize and appreciate how great the 'journey' has been but to also look at and find inspiration in my own story. I know that working for a decade in an industry is not that big of a deal where we have some experts with several decades of experience, but I still consider this an achievement for me, especially after surviving the big reset last year, that could have prevented me from completing this decade.

NOTE: Some parts of this article may sound like a brag and some like a rant but that is purely unintentional. I'm still trying to make myself worthy in the software industry, still trying to figure out what this is all about and I'm not even remotely there yet.

DEV Community: Mohammed Ismail Ansari

What I Learned Writing My First Book

Installing a Minimal Debian system the Arch Way

Why and How I migrated my ThinkPad from Arch to Debian

Mohammed Ismail Ansari ・ Jun 20 '21

Why and How I migrated my ThinkPad from Arch to Debian

This is basically a continuation

I moved back from macOS to Linux and I'm loving it!

Mohammed Ismail Ansari ・ Mar 18 '21

Arch was great, but...

And then I installed Debian in an uncommon way

This moved everything, so the gaps "shifted"

Further

I split my Emacs configuration and made it adaptive

Quick recap

Evolution of my .emacs.d over the years

Issue with the current state

Plan

New state

A mini-demo

Final thoughts

Setting up GUI on Linux with twiner

Thoughts on setting up a custom GUI

Starting twiner as a program

A quick look at the options

Task: Setting up GUI

Demo: Setting up Gnome with GDM

Demo: Switching the display manager to SDDM

Demo: Installing LXDE

A few observations on the current setup

How I automated my workstation setup

Previously...

The Linux Distribution we'll use

The virtualization tool

Demo: A quick Arco install

Demo: What we have on the first startup

Demo: Next steps at a glance

Demo: Starting my automated setup

Demo: Detection of the current operating system

Demo: Initial steps for Linux

Demo: Installing packages

Demo: A few more steps for Linux

Demo: Setting up the GUI

Demo: Installing peripheral drivers

Demo: Setting up startup services

Demo: A few platform-independent steps

Demo: Reboot on done

More computer-specific scripts

Thoughts

What my workstation setup is to me

Background

What a setup feels like to me

Two kinds of setups

My setup as a code

Principles of my setup

How it started

Then came twiner

I moved back from macOS to Linux and I'm loving it!

A recap of my computing experience

My return to Windows for a very short while

Setting up my new machine with Linux

Setting up Nvidia hybrid graphics

Gaps and Issues

Further

5+ ways how Rust makes you a better programmer: An initial review of my new favorite programming language

A mutation is only allowed when explicitly declared in advance

You can use the same name for multiple variables

It encourages you to handle potential failures explicitly

There is no way you can use multiple returns in a function

It is very strict with variable references

Ownership

Only one mutable reference to a variable is allowed in a scope

You cannot pass around a reference to something may not exist

Only safe references are allowed

Some other notable great features of the Rust eco-system

Much more to learn about Rust...

A few clean-ups to relieve stress

To-Do list

Digital notes or lists

Web-browser bookmarks

Evolution of my `.emacs.d` over the years

There is no way you can use multiple `return`s in a function

From `txt` to `md`