DEV Community: Tyler N

Why Terminal-Based Development Is Best For Me

Tyler N — Thu, 11 Jun 2026 01:49:12 +0000

One day, I was working on a Python project. I had my 'reliable and speedy' Windows and my 'fast and optimized' VS Code. But, the only issue with this, is that those adjectives, are false. To have three browser tabs and one VS Code window open at the same time was like a death wish to my 16GB of RAM. And, as you may have guessed, this wasn't just 'one day', but rather, every single time I wanted to do any sort of development in the Microsoft ecosystem (minus the browser, I viewed Microsoft Edge as terrible and Chrome as just the only replacement, despite its lag).

At that rate, imagine how slow it was for me to code. I was running the newest Windows, the newest VS Code, didn't have any unnecessary background apps, and followed every single 'secret' step to 'optimize' and 'speed up' Windows and its associated applications. I was doing everything right, but it still was too slow. Oftentimes, a large portion of my 16GB of RAM, was used simply by thousands of background services that added up to use a large amount of memory.

So, approximately three months ago, on March 10th, 2026, I decided to experiment with dual-booting a Linux distribution on my main computer. I shrunk my Windows partition with the Disk Management application and proceeded to allocate around 300GB of space on my 1TB SSD (solid-state drive) for Debian 13.3, (Trixie), a Linux distribution notable for its stability, large software repository, extensive architecture support, strict free and open source software (FOSS) philosophy, and upgrade reliability. And, so far, I have only used 62GB of space on the 300GB partition, meaning that I could have been very comfortable with 100GB. This data usage is including large media files.

I originally thought I would only use Linux as a side project or hobby, and that I would often boot to Windows, too. But, two facts made me never boot Windows again with the intent to use it for purposes other than data collection. Those facts are:

I have never experienced lagginess on Linux that I deemed to not have a reasonable cause.
It was not as hard to use as I thought it would be.

To elaborate more on fact two, at least to me, the complexity of Linux is decided by your Desktop Environment (DE). On Windows, you are locked down to one Desktop Environment (DE) that can be very laggy, but is extremely simple to use for basic tasks. On the other hand, Linux generally allows users to choose their own Desktop Environment (DE), with the exception being certain immutable distributions and Operating Systems like Android OS and Chrome OS (yes, they rely on Linux). On Linux, users can choose themselves the correct balance between accessibility, usability, and speed for their specific circumstances by making an educated choice on which Desktop Environment (DE) to utilize.

I originally tried my best to find the 'perfect', light-weight IDE for Linux. I tried Sublime Text, and I was fine with it for a while. But, I eventually decided to strip out the IDE, and instead, simply code in the terminal.

When using the terminal to code via a code or text editor (like micro or nano), the tools you write code with generally do not significantly contribute to the resource usage of your computer, with the exception of certain advanced code analysis tools to prevent security, speed, and other issues or errors, along with certain other applications. For example, if you can have 5 browser tabs open without any lag, adding on something like micro will not make your experience any more laggy.

With my new development workflow, I am able to code—minus the lag. I can have 10 different terminal tabs open, and it's not even as hard on my laptop as resting a feather on its lid, (figuratively). It's 2 cents compared to the resource utilization on the rest of the computer.

And, my choice of using Linux also greatly contributed to reduced lag when using my computer, both in general and in development workflows, —in addition to utilizing terminal based code editing. Because of Linux's open-source nature, every single line of code is scrutinized by the public, and every issue is eventually caught and handled (if you are going to comment about copy fail and similar issues, it was in fact, eventually fixed). On the contrary, Windows' proprietary nature allows for extreme telemetry and non-optimization, despite their claims of speed. Windows is even thinking about utilizing more system resources—instead of actually optimizing—to make the Windows experience faster.

My General Workflow for Making Python Projects on Linux While Utilizing the Terminal

I generally use the micro code editor or the nano text editor, both terminal-based applications.
I may have the Firefox FOSS (free and open-source) web browser open to a documentation page or a forum of some sorts. Web browsers like Google Chrome, Apple Safari, and Microsoft Edge are not FOSS (free and open-source).
Now that I have started my Python project devto-followers2md, I have recently started checking my code with Ruff, a fast Rust-based Python linter and code formatter. I also started using pyright, (yes, I know it is very ironic, it is made by Microsoft), and will be working on making sure the project aligns with its standards too.

(If you are wondering more about my Python project, I have an awesome article about it coming out this week, most likely on Sunday afternoon or evening, here on DEV.to. When it comes out, I will insert the link for it, here).

The Final Anecdote (for now)

Due to Windows' confusing file storage locations (including Microsoft OneDrive), I was forced to boot Windows in order to recover my coding folder that was not visible when I decrypted my Windows partition with my BitLocker recovery key. I tried to copy it to my Google Drive account, but it was transferring at a rate close to ZERO megabits per second, so that was a no go. I tried to transfer to a flash drive that generally works just fine, and it said my 16GB or so of data would take 16 hours, then 20 hours, then just weeks to copy. That, also, was not going to work. It turns out that the Antivirus system, BitDefender, completely crashed, on every level. Because Windows does not allow the administrator to force kill the antivirus process or its associated programs, the antivirus GUI dashboard and control center hung and never closed due to the crash of its antivirus process. Possibly, the antivirus software was attempting to scan files when it was not able to, causing this issue. I eventually was able to transfer it (very slowly), with the terminal!

Conclusion

While I switched from Windows to Linux and greatly benefited from it, I acknowledge that it is not the right move for everyone. People may be locked into it because of their jobs, or they may have a certain circumstance making Linux not the best for their specific workflow. And, of course, I acknowledge macOS, too. Since macOS is built on a UNIX foundation (like Linux), it is much closer to Linux than Windows is.

Windows users who want to experience Linux can utilize WSL, which lets Windows users utilize a Linux environment on their Windows computer. (It is made by Microsoft, so if you are wondering, no, it is not unofficial or dangerous). WSL is free to use, but is not completely FOSS (free and open-source).

What is your favorite coding workflow, and, what OS do you use? Do you agree with what I said?

I'll share my OS:

OS: Debian GNU/Linux 13 (trixie) x86_64
Kernel: Linux 6.12.90+deb13.1-amd64
DE: KDE Plasma 6.3.6
WM: KWin (Wayland)
Shell: bash 5.2.37
Display: 1920x1080 @ 60 Hz
CPU: 12th Gen Intel(R) Core(TM) i7-1255U (12)
GPU: Intel Iris Xe Graphics [Integrated]
Memory: 16GB

How I used Inkscape to make Assets for GitHub and DEV.to

Tyler N — Sun, 31 May 2026 21:00:48 +0000

Developers often ignore their profile picture by keeping default geometric placeholders or blank banners because design tools can be intimidating. Up until recently, my GitHub profile was simply a green, Pacman-like geometric pattern, which doesn't show anything about me, or a spec of my creativity. I didn't know how to use any design software, except basic Photopea. With almost no design knowledge, I wanted to make myself an awesome profile picture, without spending money on proprietary software subscriptions, so I turned to Inkscape, (a free, open-source vector editor).

Standard raster images (like PNGs and JPGs) are just grids of colored pixels that blur when scaled. Vector files (like SVG) are built on mathematical coordinates and nodes. In fact, SVG vector files are really just XML data. Because I chose to design my profile picture with vector graphics, it is able to stay completely crisp, no matter how I resize it. The pixelation issues that occur when you enlarge standard images simply does not exist in vector graphics.

The way I got a basic understanding of Inkscape without watching long videos or signing up for paid courses was by applying a different philosophy of learning that I find is also highly effective when learning programming languages or concepts.This philosophy of learning emphasizes applying concepts as you learn them, rather than learning concepts and only applying them once you completely understand them. This approach is even more powerful in Inkscape because you see visual results directly on your canvas. Unlike coding, where your code must be correct before you can run it (generally), design lets you learn simply by doing.

The way I applied this philosophy of learning to Inkscape was by following along with a simple and short (~15 minutes) tutorial, and using tools the second the instructor explained them. I frequently paused to experiment more with the tools, which worked very well, except for the Bézier tool and it's paths, which I still sadly can not use well (I tried to make a smiley face with it, and I made an upside down ^ symbol, which is why I made it with the calligraphy tool). When there was something I truly did not know how to do (like wrapping text around an ellipse), I simply searched for it online and applied it immediately.

To design the profile picture, I centered a large ellipse onto a 500 by 500 pixel canvas with a smooth blue to pink linear gradient, leaving the corners transparent. From there, I built the features: 3D boxes for eyes, ovals for ears, the hair, and my initials for the nose. I even layered a duplicated calligraphy path to make depth for the smile. Finally, I exported the finished asset as a PNG file to preserve transparency.

I then updated my GitHub and DEV.to profile picture to be my newly designed profile picture. My custom Hugo blog even updated its main page automatically once I reran my GitHub actions workflow, since it pulls my profile picture dynamically from GitHub.

I also use Inkscape to make cover images for my DEV.to articles, like this one with a canvas size of 1000 by 420 pixels, for a clean, professional look. Because the original asset is a vector, I can shrink it into the corner to be a small logo or blow it up to be the center of attention of an article cover, and it always stays crisp.

Learning how to use an open-source creative tool is just like learning how to use a CLI utility. You don't need to master the entire tool; you only need to learn the parts you are actually going to use.

What do your profile pictures look like? Did you make them yourself, or are they still placeholders? If you are still using a placeholder, are you planning on making one now? If you are confused by Inkscape, I'm sure someone in the comments could help you.

Also, if anyone has any experience using Inkscape or other graphic design software, I would love to hear your thoughts!

Git for GitHub: How to use simple Git commands to manage a GitHub repository

Tyler N — Thu, 28 May 2026 21:18:19 +0000

Recently, I was working on creating a website on a cloud-based IDE (CodeHS). One night, I was editing, and then when I was done, I simply turned off my monitor and disabled my mouse and keyboard. Then, the next day at school, I continued to work on the website, and made significant changes. When I got home, I made more significant changes, but then realized something very important. What I realized is that when I continued to work on the project at home, the cloud-based IDE hadn't refreshed to the new code, and overwrote the work I did at school when I saved my new work.

So, what is the purpose of me telling you this? Is it to say that you should always close your code editor when you're done working, or some other trick to prevent this from happening? No, it definitely is not.

After the initial panic, I realized that the cloud-based IDE had a history section, which has a detailed log of every change that happened to every file. I then looked back at my old copy, copied the changes, and put them back into my new code.

Now, imagine you aren't using a cloud-based IDE, and your just editing a file on your computer, in an IDE, or simply your terminal. To clarify, Git is not cloud-based, it is local, (sitting on your computer), that connects to the cloud (GitHub). What happens when something breaks? For some environments, this could be catastrophic, and make you loose a lot of work. When you make an update to a file, the last state and all the states before it are gone.

But, this isn't the only thing that can happen. When you use a version control system (VCS), like Git, you can always go back to your previous commits, (snapshots of your code).

The work I almost lost wasn't very important; that work didn't effect anyone, except myself. Imagine what would happen if I was working on something more important, or even just working on something for a job.

Before learning how to manage your project, it helps to understand what Git actually is. Git is overwhelmingly the most popular version control system (VCS), and is completely free to use.

"By far, the most widely used modern version control system in the world today is Git. Git is a mature, actively maintained open source project originally developed in 2005 by Linus Torvalds, the famous creator of the Linux operating system kernel."

Source: Atlassian

In this guide, you will learn how to use the Git version control system (VCS) to manage a GitHub repository by initializing a project, linking it your GitHub repository, and using it to manage your GitHub repository.

Section 1: Installing and Setting Up Git

In this section, we will navigate to our terminal and install Git.

Step 1: Opening your terminal

Windows: Press the Windows Key, type Powershell, and hit enter.
macOS: Press Cmd + Space, type Terminal, and hit enter.
Linux: Press Ctrl + Alt + T to open your default shell.

Step 2: Installing Git

In your terminal, run the following command to determine if you have Git installed

git --version

If a version number appears, you are ready to go to step 3.
If the command is not recognized, follow the steps below to install Git.

Windows Installation:

To install Git on Windows, you can do so in one of the following ways.

Run the following command to install Git with Winget: winget install --id Git.Git -e --source winget
Run one of the standalone installers found at Git-scm

macOS Installation:

To install Git on macOS, you can do so by installing Git with homebrew.

If you do not have homebrew, install homebrew with the following command:

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

Once you have homebrew, run:

brew install git` to install Git.

Linux Installation:

To install Git on Linux, use your distributions package manager.

Debian/Ubuntu: sudo apt-get install git
Fedora: sudo dnf install git
Arch: sudo pacman -S git

Step 3: Setting up Git (Identity Configuration)

The next step to using git is to set variables that let Git know who you are. These are permanently attached to every commit you do, which allows platforms like GitHub to attach it to your profile card.

# Set your display name (can be your real name, your GitHub username, or many other things)
git config --global user.name "Your Name"

# Set your email (MUST match your GitHub email)
git config --global user.email "your-email@example.com"

Section 2: Tracking Version History

In this section, we will initialize a local git project and learn how to use basic git commands to track the files.

Step 1: Initializing local Git Project

In this step, we will initialize our local Git project. First, navigate to the directory you would like to store your project, and run the following command.

git init -b main

-b main ensures the default branch is named main, matching GitHub's default layout.

Step 2: Stage and Commit files

In this step, we will stage our files, (which means to tell Git to start tracking the files), and to commit our files (making a snapshot of the file on our local machine.)

To stage the files, type the following command:

git add .

The . symbol is our current directory, which tells Git to stage all the files in your current location.

Next, we will commit these files and add a commit message. It is standard practice to use the imperative mood (e.g. "Add css rule to fix whitespacing", not "Added css rule to preserve whitespacing") for commit messages, as this follows the convention used by Git itself.

git commit -m "Initial commit"

The -m flag stands for message, which is why we put our commit message after it.

Section 3: Making GitHub repository and linking with local project

In this section, we will make a GitHub repository and link our local project with it.

Step 1: Initializing Repository

In this step, we will make a GitHub repository, which is where we publish our project. If you do not have a GitHub account, please make one.

Navigate to the GitHub homepage and sign in if you are not already.
Click the green New button located at the top right of the Top Repositories menu that is on the left side of your screen. If you are unable to find this button, click on this link instead, which will take you to the same location.
Set a repository name, and make sure that all of the Add ... boxes are unchecked.
Click Create Repository
Remember the URL for your repository

Step 2: Linking local project to repository

In this step, we will link our local project to the GitHub repository we just made.

Navigate to your local project, and run the following command, while ensuring to replace <REPOSITORY LINK> with the link you remembered in 3.1.5

git remote add origin <REPOSITORY LINK>

Step 3: `Push`ing

In this step, we will push to our repository on GitHub. This means that your local project and all the changes you made, along with your commit messages, will be put on GitHub.

Navigate to your local project, and run the following command

git push -u origin main

The flag -u stands for upstream, which links your local branch to the remote branch so that in the future, Git knows exactly where to send your code.

Section 4: Wrapping up and Next Steps

You have successfully initialized a local project, tracked your changes, and pushed your code securely to the cloud on GitHub.

Now that your local project is linked to your remote GitHub repository, your workflow becomes way more simpler.

What to do in the future

In the future, your workflow isn't as complicated as it just may have been. You just need to remember 4 simple commands for the most part.

First, you need to know the git status command. This command shows you:

The branch you are on
How many commits above or behind you are compared to the GitHub
Changes that have not been staged to commit
Untracked files It is recommended to look at the output of this command before you start working.

When you want to stage files (tell Git to track them), you simply run the command git add <FILES, or . for every file in the directory>

When you want to commit these files (to save a snapshot of them to your local machine), you simply run the command git commit -m "COMMIT MESSAGE" Keep in mind that at this point, the new changes have not left your computer.

Then, when you want to put them onto GitHub, you just run the command git push If you want to be extra sure that the git push -u origin main was remembered, you can always just run git push origin main if you want to be sure.

And, that's your workflow now. See how simple it is?

Important Note: .gitignore

It is standard practice to add a .gitignore file in your root directory. The purpose of the .gitignore file is to tell Git what files to not track, keeping it from the public (GitHub). You simply type specific rules into the file with one line for each. Here is quick tutorial.

You can use # signs to indicate that everything after it on the line is a comment
If you type a literal name (i.e. secret.txt), that specific file will be ignored
Patterns ending with a / (i.e. private/) match only directories and their entire contents
* Matches any amount of characters. For example, *.txt matches all files ending in .txt, and log* matches all files starting in log
** matches directories recursively. For example, **logs matches any directory named logs in the project
Lines starting with ! re-include a file that was excluded by a previous rule
Using a / anchors the pattern to where the .gitignore file resides, NOT the root of the computer

Section 5: Ending Notes

In this tutorial, you learned how to use Git to manage a local project and to link that local project with GitHub.

Now that you see how you do it, I think it's important that I explain a bit more about why we do it.

Imagine you are working on an Automated Market-Making (AMM) System, which is a system that place buy and sell orders for many stocks simultaneously, that pocket small price differences without human intervention, and you accidentally make an error in the code, which is costing the company money.

If there was no version control system (VCS), the company could experience significant downtime and financial loss. With the usage of a version control system (VCS) like Git, the company can easily revert back to slightly older working code and restart the program, saving the company a lot of money.

Keep in mind that with Git and GitHub, there are many features that allow code to be collaborated on by many people at the same time, and also provides features to make sure code can be checked by other collaborators before it is approved.

This is why version control systems (VCS) are so important in the development workforce.

Even if you do not have a coding job and are just coding on your own, you can still loose significant progress when you do not use version control systems (VCS), (like we just discussed).

Also, I want to put out that while I may not write the best commit statements, I am working to make better ones. A good standard for writing commits that I found is the Conventional Commits standard. I will not describe the standard here, but I recommend to read this summary to learn more about it.