I am a Very Organized Person™️. Ask my closets, they’ll tell you. All of my belongings have a home – whether that’s a designated section, a tray, a box, a basket, a drawer, a recycled shoe box, etc. I’m a fan of color-coding, size matching, function grouping, you name it. Things have a place to live and I’ve always been this way.
However, it wasn’t until recently that I applied this mindset to my own code.
For the first few years of my coding career, I spent most of my time focusing on learning something new – new languages, new frameworks, new tools. My tools and settings were constantly changing and I had to adapt to it.
In the last year, I’ve realized that my environment has mostly stabilized. I’m still constantly learning, but my desk is stationary in my (well-organized) closet-turned-office. Most days I expect to touch Ruby/Rails/React code, and I am usually on the same operating machine every day. The codebase I work in or the client I work for may change, but I have more confidence and control over my environment than I did as a new-career dev.
At this stage of my career, I have found ways to apply my organizational mind to committing, writing, and prepping my code.
Commit to Organizing Your Code
Applying my organizational skills to my code didn’t happen all in one day — but realizing I needed to did. It was a day many developers have experienced: – a day you spend too much time unraveling code yarn balls with rebasing and merge conflicts. I ran into so many commit messages that were vague and honestly, unhelpful, and then I realized they were all mine. AHHH! I’m pretty sure I pushed myself away from the table and had a full-on identity crisis. I am a Very Organized Person™️! How could I let this happen?
After a breath and the obvious realization that this wasn’t a Real Problem, I calmly finished my rebase and fixed my merge conflicts. I then immediately turned my attention to tailoring and organizing how I commit my code.
Here are the rules I now follow when writing and committing my code:
- Commits will be ‘green’ (i.e. pass tests, lint, pass CI, run the code)
- Commits will be small and focused (extending the object-oriented single-responsibility principle)
- Commits messages will be 50 characters or less and ‘good’ (i.e. well-written, imperative form, descriptive, and specific of how the code was changed)
But the golden rule, the very shiniest, most golden rule: commit messages should finish this sentence: “If applied, this commit will…”. I mean it, say it out loud before typing your commit message! Rubber duck your way to a good commit message!
BONUS: Don’t know if your commit message is too long? Let your editor help you. By turning my vim syntax highlighting on, it tells me right away by changing colors if my commit message is too long.
Here’s how to set this up in your environment:
- First, ensure you have vim installed (and install if you do not have it installed):
`vim –version` - To set vim syntax highlighting to on, first set your .gitconfig editor to vim:
`$ git config –global core.editor vim` - Then, simply, turn on vim syntax highlighting:
`echo “syntax on” > ~/.vimrc`
Probably the single best way to organize committing your code is to keep your commits small and focused. However, if you’re like me — trying out things, experimenting with your code until you finally get it to a place where you can finish — use `git add -p`, or “patch” to turn your larger code changes into smaller, easier to digest commits. Fun fact – git refers to these smaller pieces as “hunks.” 😉 Ha!
This trick, and many others, I credit to the teachings of Mercedes Bernard.
Requiring Constant Validation: Sometimes a Good Thing!
To keep me organized while I’m writing my code, I try to run and test my code as much as possible while I write. That way, my code can’t run away from me and stop working while I try to catch what went wrong. This is the easiest way to end up with messy code.
I do this by:
- Opening up a console and testing my code there first before trying in the codebase
- Utilizing test-driven development
- Live reloading the page while front-end programming for visual confirmation of code success
- WRITING AND RUNNING TESTS once I have that small, focused, code that I think can be committed. Remember, we’re going for solid, ‘green’ commits!
Get Comfy to Get Organized
Finally, the best way to organize your code is to prepare to code. Where would a chef be without a stellar mise en place?? For me, this means that I prepare my screen the same way every time:
- Terminal on the left side, ⅓ of the screen, Code editor on the right side, ⅔ of the screen
OR - Code editor on the left side, ⅓ of the screen, Dev Browser on the right side, ⅔ of the screen
I religiously use Mac’s multiple desktops to my advantage. I’m also trying out a tool called Rectangle to quickly adjust where applications are on my screen.
I have found that if I have to have multiple codebases up at any time, I use a VSCode plugin Peacock to help me differentiate between the different codebases.
The tool I’m most excited to try out in 2022 to help me organize my work is Alfred – but more on that a different time.
Another way to set up correctly: take the time to set up your bash or zsh profile well. Make it look inviting and fun — remember, you’re going to be looking at this all the time! Take the time to set up aliases or helpful functions in your .zshrc. This will help you navigate your directories better, give nicknames to tediously long commands, etc.
Setting up correctly also means a few things physically – and this is important!!
- Phone on Work Focus mode – only the most urgent notifications should come through
- Headphones on with my best focusing playlist
- Sitting up straight and making sure my monitor is at eye level or below
- ** Sometimes I add a candle if I’m feeling fun! **
Implementing these processes and rules helped affirm my identity as a Very Organized Person™️ – and they also boosted my confidence in presenting completed features for review. By keeping my commits small, writing “good” commit messages, and testing well, I feel like I not only did the work, but I have the receipts to show it. I encourage anyone to start their journey to code organization – even if you’re not a “Very Organized Person.” Start small and add one step at a time to see the benefits.
