How do you manage the mental complexity, file organization, context-switching, etc. when you are working on multiple codebases, perhaps multiple languages, etc.
Any tricks to keep things from getting too scattered?
For further actions, you may consider blocking this person and/or reporting abuse
Latest comments (21)
I've been using mani-cli to handle many repo and run the same tasks in different repositories (eg git pull, back to master). Pretty useful to add tags to repo and list them depending on those tags (eg personal projects, work projects, tools...).
Very cool to do a better and faster grep -r as well, given an extension, folder pattern...
I try to work on one project at a time and go through my to-do list. In terms of technical stack, I try to have a similar project setup so I can jump between them and the codebase is more a less the same. If the languages are different like JavaScript or Python I also try to have similarities with the codebase so it's an easy transition.
Gitpod (cloud edition) helped me a lot to handle multiple projects just in an Apple Silicon (M1 and M2)-based small MacBook Air 💻 🍎
I'm a consultant & work with multiple clients, and each client can have multiple codebases, each with its own team, process, linting/PR policies, branching regime, etc. In short: it's bananas. Context switching on this scale is plainly outside human capability.
So I automate a huge amount, and I make use of TextExpander's ability to run shell scripts to create snippets that change their output based on what I'm currently working on. I have Keyboard Maestro & Alfred hotkeys set to help me open Jira tickets quickly, create ticket branches, create PRs according to the team's policy, etc.
My premise is that every common action should be automated as much as possible. That 1️⃣ ensures it's done correctly each time, 2️⃣ saves me time in doing it, and 3️⃣ lets me track changes to how I do it so I can be intentional about doing it differently.
I was actually just about to write something here about how I manage calendars & to-do lists, and I think my client/ticket/repo management system is worth a writeup at this point too.
How do you dive into large code bases? cupping massage calgary
All of my work projects exist in ~/work, open source goes in ~/git. I have tmux bindings to bring up a fuzzy project switcher popup, so I can select the project with fzf. to get between between two projects I often use alt-b to back to the last session I was in. This happens instantly, so I can quickly reference one while changing a second project.
You can see most of my tmux setup in this post.
Jump to running tmux sessions with fzf
Waylon Walker ・ Aug 9 '21 ・ 1 min read
Another critical tool to managing more projects is mu-repo. I have ~60 data pipelines that are all quite similar that I manage. I make heavy use of rg, and sed to make batch changes, and mu-repo to diff, commit, and push all the changes from every repo at once.
waylonwalker.com/mu-repo/
The most important thing for me aren't the technical details. I accept that different projects will rely on different technical stacks so I make sure the readme's define the things I or other Developer's will need to remember.
More important than that is the context-switching from a productivity standpoint. Timeboxing is an invaluable technique for me to make sure I don't get overwhelmed, but also that each project gets my attention and time.
Saying "No" to starting/joining new projects is critical. Timeboxing works well for a few concurrent projects, but it can't be expected to work if I'm participating in too many concurrent projects.
Finally, it's important to define "What is done?". In other words, when will a project be completed as far as my involvement and what will my exit strategy be so I can go on to other things.
Window managers aside, I take a naive "a little here, a little there" approach, and let unit tests help keep me on the right track.
---- And many will disagree with the following, but to each their own: ----
And I'm not afraid of littering my codebase w/ TODO statements because I use them as tokens to identify places to clean up.
In my professional life, I don't push these TODOs to develop and they really come in handy to help reduce the brain drain of multiple context switches.
In one URL: jetbrains.com/toolbox-app/
Some comments may only be visible to logged-in visitors. Sign in to view all comments.