Shake Your Process Up
Process, either your cringe at the word or accept it with open arms. TBQH I wasn’t one that pushed for process. I knew which principles I liked. New process meant adopting and changing the status quo; changing what I was familiar with, and I, like most, am resistant to change. As developers, we push to continually grow and learn technically, and our process, whether personal or within a team, should be no different. Change is inevitable, so what changed?
Where it All Began
Let me start by giving you some brief background. I started out my development career on a small product team. Our team was fast and loose with our process. We understood the importance of process but our team was small enough that the information could be shared easily between each other and what wasn’t documented was in someone’s head. When I joined the team, three other developers joined at the same time. The team grew and so did our approach. We made many small wins that first week, like improving ticketing, incorporating a CI, and choosing the AGILE bits we wanted, but areas like documentation suffered. Yet, everything seemed to be going smoothly. Our team continued to grow into a much larger team after an acquisition with Wombat. At the time our process stayed relatively the same, but pain points began to creep out of the woodwork. Over the past couple years I have had the opportunity to work within a couple teams as each refined its own process. Whether it’s Development, QA, Product Management or Technical Project Management, we all form a larger entity that constantly faces challenges to our productivity. Here are some workflow approaches I am using and some our team has adopted.
Learn a New Groove
New Favorite Quick Tip
Improving speed and productivity so I can be lazy. Ah, the developer’s code. This year I picked up a new nifty trick that I hope you can learn to appreciate as well.
VIM. Yes I said it VIM.
I know not everyone jumps at wanting to use a lightweight text editor that makes you feel like you’re living in the 80’s. What if I told you that when you’re searching your command-line history you no longer have to click that up arrow over and over to find that command you can’t remember. You could leverage a mo’ bettah search. (NOTE: I use a mac with bash). You can set your terminal to vim mode. This allows you to use the navigation and commands of vim in the terminal. You can set vim mode like the following:
$ set -o vi. Now to find that exact command you wanted to run. Wack
ESC + /. Your prompt will look like the following:
?_ Begin entering a partial match for the command you want. Hit
n to go to the next result and when you find it hit enter. Example search of
? ssh_ can filter down to
sh priv/scripts/run_admin_server.sh --ssh.
This is super handy when there is a command you want to re-run but you can’t seem to remember how it starts. I honestly use this all day. Give it a try and let me know what you think!
Readability and understanding at a glance is one of those things that I highly valued in Ruby Lang and continue to love in Elixir Lang. This same principle can be applied to your git flow. Recently our team discussed using more meaningful commit messages. Adding a meaningful commit message answers questions before they are asked, gives you a reference to specific detailed changes in history, and allows other developers to understand what changes the code makes before ever opening the code. So what makes a meaningful commit? Let me show you what it shouldn’t be. EX:
Adds Bulk CSV Sync This commit doesn’t really give us any information on CSV sync, how it should be used, and what changes have been made to our overall system. A better commit would look like:
Syncs Users from CSV uploaded to S3 * uses a standard CSV to bulk sync users * Prepares users in CSV into format that works with End User Sync * Removes whitespace on emails * Adds in S3 interface for file upload/download * Adds in correct group syntax for bulk_csv upload going through end_user_sync Adds CSV Validator * Validates Email Address by checking against companies approved domains * Returns analysis of CSV for ** returns create/update counts, error counts and error messages ** error messages return Row number error was found in. * Checks for duplicate Email Addresses * Adds validation endpoint
This message is clear, although not super concise, it provides inherent knowledge of the CSV process. Now you can pinpoint exactly which commit to peek in if you had issues with a CSV validation. Here are 2 useful points I’m working to incorporate in my commits taken from this ThoughtBot blog useful-tips-for-a-better-commit-message. 1) Why is this change necessary? 2) How does it address the issue?
Branching off our commits being more meaningful, our pull requests should also be very well documented. First consider adding a pull request template your project.
### Description: ### Ticket (your_ticketing_url) ### Mix Tasks? - [ ] YES - [ ] NO ### Version Bumped? - [ ] YES ### Description GIF ![replace me](https://media1.giphy.com/media/fV7xZPk6aeiUU/giphy.gif)
Did you catch the GIF section? Don’t forget to have some fun, one of our developers added this GIF section where you can add a gif to each PR. While a template can be helpful, a well thought out description of the changes is, in my opinion, more valuable. It allows code reviewers immediate insight into the changes they are about to review. Furthermore, other departments like QA and Technical Project Management can ensure that the current technical implementation is in line with our current goals. So how can we create a better pull request description to aid these various groups? One of our developers likes to use a todo list. Something I am going to adopt and try out.
## TODOS - [x] Re factor UserClient delete - [x] Handle bulk deletes - [x] Create multiple user roles for testing - [x] Decide which users to exclude/include for delete - [x] Figure out if we want to send error message and if so (or not), what that message should be - [x] Failing specs - argh
Also screenshots can be helpful if they give more insight to the code. I have used screenshots of DB query results made to show issues that caused bugs. If you are making frontend changes consider adding screenshots of the changes made.
Keeping all parties informed
Recently we made a decision to have all conversations in public channels. The sole purpose: to trace conversations. We all forget details, so let’s make retracing our steps easier on ourselves by putting them in one place. Some may be thinking, why not just use email? To be frank, I get far too many notifications in my email already and I find it much easier to search our Slack channels. Slack channels may not be the best answer for your team, but find a place where the conversations can be tracked down. Another way I like to keep all parties well informed is to put my pull request links into our tickets, again giving our QA and PM easy access to the current state of a ticket.
One caution, try to keep it simple, nobody wants to read a wall of text that isn’t fully relevant.
DO NOT have a process just for the sake of process, it must provide intrinsic value. Even if your team doesn’t decide to adopt some principles, like more valuable commit messages for example, you can still incorporate this in your day-to-day, or your next open source contribution.