Tips I've learned working at a software consultancy

The biggest challenge of working at a consultancy is working on many projects at the same time and dealing with context switching between them.

On any given week, I will work on 3–6 projects. To deal with so many projects happening in parallel, it is critical to develop a few skills that make everyone’s life easier. These skills generally apply to programming on teams, but their importance becomes absolutely critical when working in a consultancy environment.

1. Don't keep knowledge in your head. Did you run into a bug when starting up your environment? How did you fix it? Document it somewhere. Put it down in the README. If not for the next person that runs into this bug, document it for yourself when you run into it in 3 weeks and you don't remember what you did to fix it.
2. Write tests to protect your code. You just finished writing some kick ass code that delivers a great feature for your client. High fives all around. Except in three months you're not even working on this project, someone else on your team comes along and tweaks some other feature of the application. That change ends up introducing a bug into your code. Protect your code with tests. So that the next person who works on the project doesn't break the great work that you did.
3. Use the README for everything. Everything relevant to the project should go in the README. Where are the staging and production hosts? Are there scheduled tasks that run every day or every week? What 3rd party services does this project use and where are the credentials for those accounts. Writing details like this in the README saves the whole team big chunks of time. (see example below)
4. READ the README. We've all done it. You get onto a new project, all excited and start asking what you think are super insightful and forward thinking questions. Then someone tells you to read the README. You do it once, you feel like an idiot, and it never happens again.
5. Follow a style guide. Two developers can argue for days about coding style. The truth is it doesn't matter (see bikeshedding). Pick a style guide and stick to it. There are some good ones for ruby and javascript.
6. Write detailed commit messages. No more commit messages like “slight update” or “bug fix”. These don't help anyone. Commit messages are critical for current and future team members to understand your code. Link to the issue in your issue tracker, separate the subject of the commit message (no more than 50 characters) from the body, and in the body of your message answer these two questions: What is this change?Why is it necessary? More tips about writing great commit messages can be found here.

README example from scoreboard.ly

Developing these basic skills brings up the level of everyone on the team. It minimizes the amount of wasted time when you're not creating value for your client.

The Author

Dylan Jhaveri is a lead developer at The Must Win All Star Web & Mobile Consultancy.

Dylan is a product minded end-to-end developer who has never met a challenge he didn’t find stimulating. When he’s not hacking on new tech or leading projects he can be found surfing SF’s cold waters and travelling.