Every 2 weeks we hold Tech Talks here at Drivy. These are an opportunity for our now 17-strong team of developers to gather for 1 hour in a non-squad setting. The Tech Talks are emphatically not about tackling issues or solving problems, but are instead an opportunity to explore new ideas, ask questions, or to return to discussions started in a different context.
As a recent new hire to Drivy in a junior capacity, I quickly recognised that the Tech Talks were going to be a valuable addition to my onboarding experience. Any junior, joining an established tech team with rigorous working practices in place, will likely feel daunted as I did. One way I combatted this was by trying to learn as much from my colleagues as possible.
Imagine my glee then, when during a recent edition of the Tech Talks, we were invited to share our productivity tips 🎁. I’ve rounded up a selection of the tips and tricks that were shared, which covered a broad range of topics including Git, shell config and debugging. These tips may be highly valuable to other juniors out there - or indeed anyone looking to streamline their personal working practices. Plus it’s really interesting — and reassuring — to take a step back and see that everyone has their own way of working.
Disclaimer: these are tips that were shared by members of the dev team at Drivy. Many of the points have themselves been sifted from the Internet - no point reinventing the wheel as they say, especially when you’re aiming to move fast and break things 😉.
Renaud reminded us that the standard
overwrites the remote branch with your local branch, thereby potentially overwriting any work that may have been built on top of your original remote branch. The alternative is to
which affords more flexibility: if any new commits have been added to the remote branch in the meantime, the force-with-lease option will not update the remote branch.
To quote the documentation, ‘it is like taking a “lease” on the ref without specifically locking it, and the remote ref is updated only if the “lease” is still valid’. This is important if it’s possible that another team member has checked out your branch locally and continued working on it.
Nico has the following in his .bashrc file
With the following command:
he can subsequently see all commits that contain the string
rental_agreement in their diff, whether those commits have been deleted or not. Sometimes you might want to find dead code, or to see the evolution over time of a given method.
Nico also shared this tool with us, to help keep on top of GitHub notifications in your inbox. Octobox ‘adds an extra “archived” state to each notification so that you can mark it as done.’ Plus, if any new activity occurs on an archived item, it is moved back to your inbox so it won’t get forgotten.
Aliases were a new discovery for me, right on Day One of my Drivy adventure. There just wasn’t time to cover this kind of setup in depth at Le Wagon, the 9-week intensive bootcamp where I started to code.
So, for anyone who is in the dark as I was, an alias basically lets you abbreviate a system command or add default arguments to a command you use regularly. For example, to start up the server or to drop and recreate the database, you can create a shorter alias. You write them in the config file of whatever framework you are using for managing your z-shell config (usually
Here’s a quick tour of some of the useful ones that came up. This can give you an idea of how you might use aliases, although of course you’ll need to customise for your own setup and tools:
Whatever aliases you choose to set, remember to commit the file somewhere!
Git aliases go in the global .gitconfig file, and can save you time and effort on regularly used commands. The following were suggested by Christophe and Romain
Plus, less typing means less chance of making a mistake 😇.
It tries to match mis-spelled commands, and then create a new command using the matched rule like so:
Mike recommended BitBar to us, for putting the output from any script or program directly in your menu bar. You can either browse their plugins, or write your own if you’ve got what it takes 💪.
He uses it to be able to easily check the status of external tools, or to stop and and start Homebrew services, like so:
A real medley of text-editor plugins were mentioned. Some useful ones for Sublime were:
⌘ + shift + click on a Rails partial path, you can open that file in a new tab, as explained by Adrien.
Jean recommended Trailing Spaces. This plugin lets you highlight and delete any redundant trailing spaces in your code, either automatically upon saving or by hand at any time.
Another handy Sublime plugin is BracketHighlighter. It will match a variety of brackets, helping you to avoid unclosed or unmatched brackets. It too is fully customizable.
Jean reminded us that when pry hits its breakpoint,
can be used in the pry console as a shortcut for
Adrien shared a tip for pry_remote too. You can call:
on an object within the pry console, and get a list of associated methods:
This has just been a sample of the points touched upon, and of course there were other, more sophisticated ideas too - beyond the scope of a junior. But if there’s one thing that emerged from the veritable smörgåsbord of tips and tricks shared, it’s that there is no one standardized way of working. Joining an established tech team in a junior capacity can be very overwhelming, so it can be reassuring to remember that sometimes.