Code Like I Do
It’s critically important to be comfortable in your development environment. Over time, I’ll post here some of the tips and tricks that work for me. I hope you can adapt some for yourself.
The Rule of 3
You should never have to solve the same problem three times, and this is especially true of your development environment. The first time you encounter an error, bug, inconvenience, or even a menial task, take a minute to catalog it’s nature and it’s details. The second time you encounter the problem, compare it to your cataloged notes from the first time and try to establish the most general case of problem. The third time you encounter the problem, write a script, create a macro, or build a system to solve it permanently.
CLI Over GUI
Likelihood is that you’ll have to use a command-line interface for some part of your development process (even if it’s just for sys. admin. stuff), so you might as well get comfortable with one. You’ll probably find not using a mouse to be awkward at first, but as you grow accustomed to it, you’ll begin to appreciate not having to context-switch your hands to and from a mouse all the time. Also, a CLI is highly programmable, so any enhancement you may want, you can probably create very quickly (if it doesn’t exist already). Another advantage is that a CLI is so lightweight that it can be served over the internet. This means your exact development environment can be accessed from any computer with an internet connection and ssh software (even a smartphone!). Because they’re so static, GUIs really just can’t keep up with your evolving programming needs.
Show What You Need, Hide What You Don’t
Screen space is limited, and so is your eyes’ ability to track and focus. That said, at any given time, everything on your screen should serve a meaningful purpose, and everything you use frequently should have a fixed position. To the left is a screenshot of my typical work environment. I use tmux (similar to screen) to split my terminal into multiple panes. These are the panes I use most often:
- Primary work area: I generally have Vim (my code editor) open here, but sometimes I’ll have something else that takes up a lot of space and requires a lot of attention, such as a diff, or a manual page.
- Clock: I always keep this clock open in the corner of my view. It’s ugly, but it helps me keep on track, especially during deadlines.
- Secondary work area: here I keep any reference files, CSS or configs, or a bash prompt, if I’m running commands frequently.
- Status line: this is a minimal readout of information I like to have at hand. From left to right it shows what session (project) I’m working on, how many workspaces I’m using, and which one is active, my unread mail inbox, and the date and time.
Everything else stays hidden until I need it. Even if you use an IDE or other GUI to work on your code, you should still try to have designated areas for your most used applications, widgets, and notifications, and hide anything else.