The good news is that most of what I love about fish can be added to zsh with a few plugins. Here’s how.

1. Abbreviations

This is my favorite fish feature and the one I missed most when I had to use zsh. Fish expands abbreviations inline as you type — so gs becomes git status right in your prompt before you even hit enter.

Zsh doesn’t have this built in, but zsh-abbr does exactly the same thing:

# With Homebrew
brew install olets/tap/zsh-abbr

# Then add to ~/.zshrc
source $(brew --prefix)/share/zsh-abbr/zsh-abbr.zsh

Then add your abbreviations:

abbr gs="git status"
abbr gd="git diff"
abbr ga="git add"
abbr gc="git commit"
abbr gp="git pull origin $(current_branch)"
abbr gP="git push origin $(current_branch)"

Type gs and press Space and it expands to git status. Your history is readable, and when you’re pair programming your colleague can actually see what you’re doing.

If you already use Oh My Zsh, the built-in globalias plugin does something similar without any extra install.

2. Syntax highlighting

Fish colors your commands as you type — unknown programs show up in red so you know right away if you made a typo. zsh-syntax-highlighting brings that to zsh.

# With Homebrew
brew install zsh-syntax-highlighting

# Add to the END of ~/.zshrc (must be last or it won't work)
source $(brew --prefix)/share/zsh-syntax-highlighting/zsh-syntax-highlighting.zsh

One thing to watch out for: it has to be the last thing sourced in your .zshrc. If it’s not working, that’s probably why.

3. Oh My Zsh

Oh My Zsh is basically Oh My Fish but for zsh. It’s a framework for managing plugins, themes, and functions, and it’s honestly even more popular.

sh -c "$(curl -fsSL https://raw.githubusercontent.com/ohmyzsh/ohmyzsh/master/tools/install.sh)"

I have a current_branch function that returns the current git branch name, which I use in my abbreviations above. Here’s the zsh version:

# ~/.zshrc or ~/.oh-my-zsh/custom/functions.zsh
function current_branch() {
  ref=$(git symbolic-ref HEAD 2>/dev/null) || \
  ref=$(git rev-parse --short HEAD 2>/dev/null) || return
  echo ${ref#refs/heads/}
}

And kp to kill processes interactively using fzf:

function kp() {
  local pid
  pid=$(ps -ef | sed 1d | fzf -m | awk '{print $2}')
  [ -n "$pid" ] && echo $pid | xargs kill -${1:-9}
}

Oh My Zsh also has a bunch of themes that show your git branch, whether you have uncommitted changes, and other things right in your prompt.

4. Autocomplete

Fish shows a gray suggestion as you type based on your history and you just hit the right arrow to accept it. zsh-autosuggestions does the same thing.

# With Homebrew
brew install zsh-autosuggestions

# Add to ~/.zshrc
source $(brew --prefix)/share/zsh-autosuggestions/zsh-autosuggestions.zsh

One thing I actually prefer about zsh here: ctrl+r for history search works out of the box, no setup needed. In fish you have to wire it up manually.

If you want the fzf-powered version of ctrl+r anyway, add this after installing fzf:

source $(brew --prefix)/opt/fzf/shell/key-bindings.zsh

Final state of ~/.zshrc

All the source lines need to go in your ~/.zshrc. Zsh reads that file automatically every time you open a new terminal, so once it’s in there you never have to think about it again.

Here’s what your ~/.zshrc should look like with everything set up:

# Custom functions
function current_branch() {
  ref=$(git symbolic-ref HEAD 2>/dev/null) || \
  ref=$(git rev-parse --short HEAD 2>/dev/null) || return
  echo ${ref#refs/heads/}
}

function kp() {
  local pid
  pid=$(ps -ef | sed 1d | fzf -m | awk '{print $2}')
  [ -n "$pid" ] && echo $pid | xargs kill -${1:-9}
}

# Abbreviations
source $(brew --prefix)/share/zsh-abbr/zsh-abbr.zsh

abbr gs="git status"
abbr gd="git diff"
abbr ga="git add"
abbr gc="git commit"
abbr gp="git pull origin $(current_branch)"
abbr gP="git push origin $(current_branch)"

# Autosuggestions
source $(brew --prefix)/share/zsh-autosuggestions/zsh-autosuggestions.zsh

# fzf key bindings
source $(brew --prefix)/opt/fzf/shell/key-bindings.zsh

# Syntax highlighting — must be last
source $(brew --prefix)/share/zsh-syntax-highlighting/zsh-syntax-highlighting.zsh

After saving the file, run source ~/.zshrc once to apply everything to your current session. After that, new terminal windows will pick it all up automatically.

Why stay on zsh at all?

Zsh is POSIX-compatible, which means bash scripts just work. You don’t have to remember to type bash script.sh when a colleague shares a script with you. That’s the main thing fish can’t offer.

With the plugins above though, you’re really not giving much up.

This isn’t a post saying GitLens is bad. It’s not.

It’s a post about a different extension that’s going in a different direction — simpler, more focused — and that might fit your workflow better depending on what you’re actually after.

GitLens does a lot

GitLens wants to be a full git client inside VS Code. Commit graph, worktrees, interactive rebase, AI explanations, multiple side panels, hundreds of settings. If you use all of that, it’s an incredible tool.

But if you only need blame and file history, you’re loading a lot of stuff you’re not using. It runs on startup, keeps background processes going, and has a real memory footprint. On a big repo or a slower machine, that adds up.

That’s not a criticism — it’s just a different set of trade-offs than what I was looking for.

What Don’t Git Lost does instead

Don’t Git Lost is built around one question: what happened to this file, and why?

Right now it focuses on three things, and each one is sharp:

Inline blame — a quiet annotation at the end of whatever line your cursor’s on. Author, time, commit message. No setup needed.

Commit hover card — hover the annotation and you get the full picture: author photo, full commit message, exact date, a link to the commit, and — when it was part of a PR — a link straight to the PR.

Time-travel navigation — toolbar buttons to step through every commit that touched the current file, with a gutter overlay or a diff editor showing exactly what changed.

No commit graph, no background scanning, no paid tier. The extension is growing — but always toward useful and focused, not toward more panels and settings.

How it feels to use

Move your cursor to any line → blame shows up.

Hover it → commit card with the PR link right there.

Click the PR → full context in the browser: description, screenshots, the whole discussion around why that change was made.

Or just stay in the editor: hit ← in the toolbar to walk back through the file’s history one commit at a time, with a gutter overlay showing what that commit changed. Same tab the whole time, no mess of open editors.

It takes seconds and you don’t lose your place.

It’s much lighter

Don’t Git Lost is lazy on purpose. Blame runs on cursor movement. The toolbar only loads history when you click it. Nothing happens at startup. Nothing scans your repo in the background.

If you’ve felt GitLens adding weight to your VS Code, this is a noticeably different experience.

It might be for you if…

• You want inline blame without a full git client
• The question you keep asking is “why does this line look like this?”
• You prefer tools that do one thing really well and keep getting better at it
• You want the PR link right there when you hover

Install Don’t Git Lost from the VS Code Marketplace or Open VSX. Free, works out of the box.

~/Work
├── back-end
├── front-end
└── docs

That docs folder has everything: architecture decisions, runbooks, onboarding guides, API contracts. The team keeps it in Markdown, versioned in git. It’s actually pretty good.

The problem is that I kept forgetting it was there, or I’d have to open a separate VS Code window just to read it. Sometimes I’d just open GitHub instead — and then I’m in a browser, which is never just one tab.

What TeamDocs does

TeamDocs adds a Team Docs icon to your VS Code Activity Bar. You point it at your docs folder:

"teamdocs.path_to_docs_folder": "~/Work/docs"

And that’s it. From that point on, your docs are always there in the sidebar — doesn’t matter which project you have open.

Click any Markdown file and it opens as a rendered preview, not raw source. Headings, code blocks, tables — all formatted.

The search is the best part

The Activity Bar view is nice for browsing, but the real time-saver is the search command.

Run Team Docs: Search and type a few characters to find any file instantly — same fuzzy picker as the rest of VS Code.

I use it mostly for two things:

• Checking a past decision while writing code (“did we agree on UUIDs or integers for this?”)
• Finding a runbook mid-incident without opening a browser

Why it’s worth it

Opening a browser tab to check something in the docs is never just opening a browser tab. You’re suddenly exposed to Slack, email, GitHub notifications. The doc check takes 30 seconds, the recovery takes longer.

Having the docs in the same window isn’t revolutionary. It just quietly removes one of the most common reasons to leave the editor.

Setup

1. Install TeamDocs from the VS Code Marketplace or Open VSX
2. Set teamdocs.path_to_docs_folder to your docs folder
3. Click the Team Docs icon in the Activity Bar

Takes about a minute. Works across every project and workspace after that.

At some point switching between them in VS Code became its own small friction point.

The usual options weren’t quite right:

• File → Open Recent: a long list of full paths that never reflects what I’m actually working on
• VS Code Workspaces: overkill for just “open this folder”
• Project Manager extension: requires registering each project when I clone it and removing stale entries when I’m done — I want zero maintenance

The setup I’ve used for the past year takes two minutes to configure and has required zero upkeep since.

The idea: your directories already organize your projects

Most developers already keep code in organized directories. I have ~/Projects for personal work and ~/Work for repos I work on at my day job. Every subdirectory of those folders is a project.

What I wanted: treat every folder inside those roots as a project I can jump to. The list stays current automatically.

That’s what Folder Projects does.

Setup

Install Folder Projects, then add your root directories to VS Code settings:

"folderprojects.roots": [
  "~/Projects",
  "~/Work"
]

That’s it. Run Folder Projects: List Projects to Open from the command palette and you get a fuzzy-searchable list of every subdirectory across both roots.

I also ignore a few things I never want to see:

"folderprojects.ignore": [
  ".*",
  "node_modules",
  "*/archived"
]

Hidden directories (.git, .cache) are excluded by default. The */archived pattern catches a subfolder I use to park old repos without deleting them.

The workflow

Cmd+Shift+P is already wired to my muscle memory, so adding a fp prefix to fuzzy-search projects feels natural. I also bound the command to Cmd+Shift+O — one shortcut, type a few letters, open.

There’s also an Activity Bar view if you want to browse instead. Each root shows as a collapsible section with its projects listed underneath.

Why not Project Manager?

Project Manager is great if you want to explicitly curate your list — tag projects, save specific folders, access remote paths.

The tradeoff is maintenance. Every new clone needs to be saved. Every abandoned project needs to be removed. I wasn’t consistent about it.

Folder Projects has no curation step. Clone a repo into ~/Projects and it’s immediately available. Delete it and it’s gone. The list is the filesystem.

The result

I’ve cloned dozens of repos since setting this up. None required any configuration to appear in the list. The ignored patterns have never needed updating.

The whole thing runs in the background and I never think about it — which is exactly what I want from tooling.

Install Folder Projects and spend two minutes on it. That’ll probably be the last time you think about it.

The instinct is to reach for git:

git log --follow -p -- app/models/user.rb

You get a wall of diffs. You scroll, squint at SHAs, try to mentally map the changes to the question you started with. By the time you find the commit, you’ve lost your context.

There’s a better way, and it stays inside the editor.

Inline blame: the answer at a glance

The first thing I wanted was to know who wrote the line my cursor was on and roughly when. Not a full audit — just enough context to know whether this was ancient code or something that changed last week.

With Don’t Git Lost, every line your cursor rests on gets a quiet annotation at the end:

Jane Doe, 11 years ago • First working version of cleaned-up production logs.

That one line usually answers the first question.

If the code is eleven years old, it predates half the codebase and probably made sense in a context you’d need to research. If it’s from last Tuesday, you know who to ask.

The annotation hides on uncommitted lines, debounces as you move (no flickering), and you can configure the format to show exactly what matters to you.

The hover card: the full story without leaving the editor

When that one-liner isn’t enough, hover it.

A card appears showing:

• The author’s photo (pulled from GitHub, GitLab, or Bitbucket)
• The complete commit message and exact date
• A short SHA with a copy button
• A link to open the commit in the browser
• A link to open the PR — when the commit was part of one

The PR link is the one I use most. When a commit message says something vague like “fix edge case in billing,” the PR usually has a full description, screenshots, and the discussion that explains why this fix was chosen over the alternatives.

All of that in a hover. No terminal, no browser tab, no context switch.

Time-travel: stepping through the file’s whole history

Sometimes a single commit isn’t enough. You want to walk the file backwards and see how it evolved — which commits touched it, what each one changed, and in what order.

Don’t Git Lost adds five buttons to the editor toolbar when you’re in a git-tracked file:

• ← and →: step to the previous or next commit that touched this file, with a gutter overlay showing what that commit changed (added lines in green, removed lines in red)
• ◁ and ▷: same navigation, but opens in a proper side-by-side diff editor
• ⌂: return to the current working copy

Each step updates the same tab — no pile-up of diff editors. The status bar shows which commit you’re currently viewing so you always know your position in the history.

This is the feature I reach for when the blame annotation points to a commit that itself looks odd. I step back through the file’s history until I find the version where the pattern was first introduced, then check the commit message and PR for context.

A real example

Last week I was looking at a data migration in a Rails app. There was a loop with an unusual guard clause — checking a condition that the data model should already prevent.

The blame annotation showed it was added two years ago. The commit message: “add guard for legacy records.” That told me something, but not enough.

I hovered the annotation and clicked the PR link. The description explained it all: when the migration first ran, there were records in production that violated the model constraint because a previous migration had been inconsistent. The guard was protecting against exactly that case.

Without the PR link, I’d have left a comment asking about it, or dug through git manually. With it, I had the answer in fifteen seconds — without leaving VS Code or losing my place in the code.

Setup

Install Don’t Git Lost from the VS Code Marketplace or Open VSX Registry. No configuration required — inline blame and the toolbar buttons are on by default.

For private repos, VS Code’s built-in GitHub account covers GitHub. For GitLab or Bitbucket, add a token in settings (takes about a minute).

If you’re in Cursor, the toolbar buttons may default to the ... overflow menu — pin them once via “Configure Editor Title Menu Icons” and they stay visible permanently.

The terminal isn’t going away, and git log has plenty of uses. But for the specific question of “what happened to this line, and why?”, staying in the editor is faster — and more importantly, it keeps your mental context intact.

Fuzzy Ruby Server provides go-to-definition and find references features. It works flawlessly on my personal projects and very well at work as well. Sometimes it doesn’t know which class definition to go to, but it shows a list with a preview that you can select. At work, we have over-complicated namespaces and repeated class names, so it makes sense it can’t figure it out by itself.

I heard good things about and would recommend Ruby LSP, but I always have trouble making it work. At work, I use Docker, which is not supported unless you want to also run VSCode inside Docker. However, even on my own computer, I often see errors and can’t easily figure them out.

Fuzzy Ruby Server just works™️ with very good accuracy.

change-case

Change-case provides many commands to change the case of the selected text between snake, camel, pascal, constant, kebab, and many others.

This extension is especially useful when working with Rails and React; however, I find myself using it frequently within Ruby code as well.

Ruby Around the Block

This extension provides a Ruby Block Toggle command to toggle between { } and do end syntaxes for Ruby blocks.

vscode-run-rspec-file

rails-rspec-file-toggler

This extension provides a command to toggle between spec and implementation, and it works really well.

endwise

This extension adds the end in Ruby methods, classes, blocks, etc. Very small, yet coding without it is a hassle.

Standard Ruby or RuboCop

Depending on what linter/formatter you use, they provide format-on-save, which is very helpful. I don’t care about spacing or which type of comma to use. I just code, save, and then I see my code all fall in line.

erb

Provides syntax highlighting for ERB templates.

jbuilder highlight

Provides syntax highlighting for jbuilder templates.

Bonus: Non-Ruby related, yet very useful extensions

Tailwind CSS IntelliSense

Auto-complete when writing Tailwind classes, even when using @apply.

Thunder Client

Feature-rich alternative to Postman.

Project Manager

Save a folder or workspace as a Project in the extension and access them easily from a list.

If you keep your projects organized in root directories, Folder Projects is a lighter alternative — no manual registration, your directory structure is the project list.

Open In GitHub

Provides a command to quickly copy the GitHub link of the currently open file. Very helpful when you want to share the file or point to a line of code to send to someone on your team.

You can select a section in code, run the command, and send it. When the person opens it, it will be highlighted.

Git Mob co-author commits

Provides a list of co-authors to include in your commits. This is especially useful when pair programming.

Code Spell Checker

Gives you warnings of misspelled words in VSCode in whatever you are writing. Specially useful for blog posts!

TeamDocs

Provides a way to check your team’s markdown documentation without having to leave your code.

At work, we have a repository with all our documentation, such as ADRs, decision docs, setup docs, and guides. With this extension, I can preview all the docs by using the Activity Bar or by using the TeamDocs: search command.

In the Activity Bar

The search command

Previewing markdown docs

Have fun 💻 👋🏼

This is a very common first question. Usually, it is the first step to get to know more about you.

This question can be asked in many different ways, such as “Could you give us an overview of your career?” or “Could you explain your past experiences?”, but what interviewers are really asking is “Why do you think you are a fit for this job position?”

It’s your job to answer that by using your Elevator Pitch ™️.

ℹ Info
An elevator pitch quickly summarizes your experiences and skills in a short period of time, like the time it takes to go up in an elevator. It can either elevate the tone or level of the interview or diminish it.

A good elevator pitch will:

1. Connect your skills to the job position or company stack

If the job description is asking for a Ruby engineer and you have experience with Ruby, avoid talking too much about Java.

If you have more experiences in Java than in Ruby, try to highlight the skills that are interchangeable.

2. Only talk about your last couple of most impactful experiences

Avoid going through all your experiences. Bring to the front the ones where you had a great impact, such as leading the research, planning, and/or implementation of a large feature, refactor, or optimization.

Some folks make the mistake of going through all their experiences starting from their first few jobs usually as interns.

Others only talk about their current job, even if they didn’t have many opportunities to do impactful work.

Talk about the most impactful and relevant experiences, connecting them to the job position. They are usually the most recent few ones.

3. Talk about things that you can talk in depth

The elevator pitch is useful for bringing subjects to the table that we can discuss in pursuit of identifying if the candidate is a good fit.

Some folks overly use “big words” such as system design, architecture or performance optimization, but when asked about it, they can’t go deep.

If a senior engineer talks about doing great optimization in a project, but when asked more about it, they can only talk about making sure the app is hitting indexes or avoiding N+1 queries, that’s disappointing.

Example of an elevator pitch

Job example: Senior full stack meant to work with Ruby on Rails, Postgres, React and TypeScript on an app that serves 3M daily users. Requirements include writing code, leading projects and mentoring other less senior engineers.

H. I’m Lucas. I’ve been working with Ruby on Rails for the last 10 years, mostly working with React. A couple of years ago, I picked up TypeScript which has been a fun ride.

I’m a tech lead in my current job and my responsibilities include defining an implementation plan for features that we want to build setting the technical direction for our Ruby on Rails back-end, sometimes creating tasks, writing back-end code in Ruby and front-end in React &TypeScript, increasing observability of our services making sure our metrics are visible and actionable, having 1:1s with my peers and participating in the upstream process to help validating how feasible features are and estimate their effort.

I’m often drawn into complex problems which I love to solve. A cool project I worked recently was to optimize a task/script that would take several months to finish reducing it to be able to finish in 13 days.

I currently work on a Loyalty platform for ecommerce and another cool project I worked recently was a React app to be placed during checkout that would allow customers to use exchange their Points for discounts🍀. That proved to be quite successful being responsible for XX% of all Point exchanges.

That’s me in a nutshell.

Take-aways:

• I only talked about my most recent role.
• I mentioned an impactful back-end project and an impactful front-end project leaving room for follow-up questions.
• I gave some metrics to show how impactful the projects were.
• If asked, I could talk about either project for hours because I was deeply involved in them.
• If asked, I could talk in depth about each of the responsibilities I mentioned. I didn’t include all my responsibilities, only the ones I could connect to the job position and that I had great experiences to share related to them.

Conclusion

When you hear “tell me about yourself,” what the interviewer is really asking is whether you’re a good fit for the role. Your elevator pitch is how you answer that — concisely, confidently, and with the right details front and center.

Write it down, practice it, and try to use your natural language so it doesn’t sound rehearsed. A good answer to this question sets the tone for the whole interview.

Good luck 🍀

With the Search Editor built-in in VSCode, the search results show up in a new editor which can use all the editor space making it much more comfortable to read and find what you’re looking for.

The result also features previews with syntax highlighting in addition to the features anyone would expect from a search engine like folder inclusion/exclusion, Regex support, match case, etc.

It’s very similar to how Sublime Text does searches and it works well.

To open a New Search Editor, type the command > Search Editor: New Search Editor or add a shortcut to your keybindings.json.

Mine are:

• cmd+k s to search.action.openEditor which opens a new editor if none is already open so you can go back to your search without using the mouse.
• cmd+k shift+s to search.action.openNewEditor which opens a new editor regardless if there is already one open.

[
  {
    "key": "cmd+k s",
    "command": "search.action.openEditor"
  },
  {
    "key": "cmd+k shift+s",
    "command": "search.action.openNewEditor"
  },
]

Done. Enjoy doing searches in VSCode.

Native Tabs groups all your VS Code windows into a single tabbed interface — one window, all your projects, a keyboard shortcut to move between them.

macOS only. Native Tabs is a macOS feature and won’t appear on Windows or Linux.

Notice how each project is in a different tab:

How to set up Native Tabs

Add this to your settings.json:

"window.nativeTabs": true

Or search for “Native Tabs” in Settings and toggle it on.

Restart VS Code.

How to move between Native Tabs

Add these to your keybindings.json to move between tabs and create new ones without touching the mouse:

[
  {
    "key": "ctrl+shift+h",
    "command": "workbench.action.showPreviousWindowTab",
    "when": "!terminalFocus"
  },
  {
    "key": "ctrl+shift+l",
    "command": "workbench.action.showNextWindowTab",
    "when": "!terminalFocus"
  },
  {
    "key": "ctrl+shift+t",
    "command": "workbench.action.newWindowTab"
  }
]

These are my bindings — use whatever feels natural to you.

That’s the full setup. Here’s what I pair it with:

Extensions that pair well with this workflow

Native Tabs organizes your windows — these two handle what happens inside them:

Folder Projects

Point it at your code directories, switch to any project instantly from the command palette. No Finder, no terminal.

Don't Git Lost

Adds inline blame and file history to the editor toolbar. Hover any line to see who wrote it, the commit message, and a link to the PR.

Note: Unfortunately, Native Tabs is only available on macOS. =/

Combine commands with pipe |

Here are some commands from my own history:

pbcopy

I can copy the results of commands using pbcopy on Mac, but there is a similar command on other systems.

No need to switch to the mouse to copy any output from a command.

Examples:

• git diff | pbcopy to share a quick idea with a colleague at work
• cat ~/.ssh/id_rsa.pub | pbcopy to copy a key and add it to Github
• ruby weekly_report.rb -p7d | pbcopy to run a script, generate a weekly report and copy the output

I can also use pbpaste, but I don’t find that as useful as pbcopy because I’m usually pasting the content on Slack, Jira, Github, etc, not the other way around.

grep

grep is useful for filtering the output of the previous command and searching the content of files

Examples:

• gem list | grep rubocop to see the version of the rubocop gem I have installed on my machine
• cat Gemfile.lock | grep rubocop to see the version of the rubocop gem I have installed on a Rails project

xargs

xargs executes a command for each line of the previous output.

For example, sometimes I have too many branches locally on my git repository so I delete them in steps to make sure I don’t delete a branch I’m currently working on.

$ git branch | grep fix | xargs git branch -D

git branch lists all branches, grep fix filters them using the term “fix”, finally, xargs deletes all these branches in one go.

awk

I find awk helpful for extracting data from more complex outputs. This means I can extract only one column of the previous output to continue working with my pipes.

For example, when I need to delete files in my git repository, I simply do this:

git status -s | grep '??' | awk '{ print $2 }' | xargs rm -rf

There might be a nice git command to do the same, but I don’t need that because at some point I wrote the command above so it made to my history and now it’s a quick ctrl+r away which brings me to the next topic.

History search

All the commands I type on my terminal are saved into a history file. Then I search on said file using ctrl+r and it brings up the commands I used before to my current terminal.

This means that the command above is just a few keystrokes away. Try it yourself!

Note: ctrl+r is available by default on shells like bash or zsh, but it needs to be added when using fish.

GPU-accelerated terminal emulator

After I started using a GPU-accelerated terminal, I couldn’t look back to iTerm and others.

As a developer, the terminal is my second most used tool – the code editor being the first – and I need it to be really fast. Not just fast, really fast.

I currently use Alacritty and it gets the job done, but there are a few features I miss from it like splits, tabs, search, etc. For all of that, I need to use tmux which I was already using before so I’m ok with it for now.

However, another option that caught my eye as a GPU-accelerated terminal and that implements all these features I mentioned – and much more! – is Kitty 🤩

I’m considering moving away from Alacritty+tmux and going all in into Kitty because it could be a much easier way to allow me to:

• organize and name all my terminals
• predefine them on list and open them all in one go
• move around within tabs, splits, etc using shortcuts – this is gold 🏆

Sometimes the apps at work can use multiple terminals and even more when I have to work on multiple apps at the same time (e.g. API + front-end + admin + backoffice app + ???). In addition to that, they also output a lot of content and a GPU-accelerated terminal emulator comes in handy for that.

Bonus #1: Turn off all animations

I turn off all animations I can or simply avoid Mac features that have them. I know they look great, but the way I see them, they just take time out of me. They are also not fun for my computer to render, especially when I’m sharing my screen over the internet with my colleagues. 😕

Bonus #2: Automate moving windows around

This is not terminal-related, but one tool that heavily improves my productivity is Hammerspoon.

The app itself is a bridge between the operating system and a Lua scripting engine, which can be used to manage, move, and resize windows around.

This is my script (link) as an example. I have shortcuts to move windows to predefined spots on my screen, in addition, to resizing them to occupy 50%, 75% or 100% of the space. Multi-monitor support is also available. ✨

Wrapping up

These are some things I’ve picked up during my life as a developer that helped me do my work. If you have any more tips, let me know on twitter! I hope that you have found something new to help you boost your productivity as well. 🚀