Being a passionate developer to me means getting a drive from the ability to create sophisticated products from a blank page and a few lines of code. I’ve reached the point in my professional growth where I realize it is not only important to build awesome and functional products, but it is also important to build them smarter and more efficiently.
Thinking like this began when I was first introduced with the opportunity to work on high level projects with a legitimate development team. My first team started off as a team of three. It goes without saying that I felt I was the least experienced on the team; the other two developers already had tons of experiences from past projects and was already contributing to their own personal projects and tools. However, the first important thing that I’ve learned from working with teams was how all of us had a particular strength that served the team as a whole.
As we started taking on individual responsibilities we got to a point that we were responsible for our own mid-size projects. Now essentially, this meant when we were able to do so, we quickly learned how to execute tasks our other team members would normally be responsible for on a larger level, for ourselves. If things got too crazy any other teammate could easily jump on your project to offer quick support (the beauty of working with teams). Sooner or later we became comfortable on taking on these tasks on our own.
This ‘freedom’ has pushed me to learn and refine a lot of best practices and come across some useful resources for working with projects that benefit the individual developer as well as development teams.
Tools and Templates
Working in teams allowed us to experiment with different strategies and approaches for tackling a particular project. I’ve personally come to love using Github in combination with my SublimeText Editor for powerful combinations of tasks that keep me sane. The following points are some that I’ve come across that has become invaluable to me.
- Shell Scripts — Writing shell scripts for repetitive tasks is a development gem in itself. Every time we would get ready to test a build, or send some code to our staging servers for review, we would shell in to our remote server using SSH and pull our latest changes to the location. We did this on top of other tasks every time we wanted to push a build. Eventually we did a lot of this with databases and this became a nightmare when trying to make sure they we all synced across each developers local machine. Over time we came up with a few scripts that improved our workflow individually as well as a part of a team. Since we’ve came up with scripting solutions, our lives have been that much better. I’ve actually collected a few and made them into a project that I can go to, depending on the project’s need. I’m currently diving deeper in shell scripting whenever I get the chance (starting with this great book).
- Gists —Saving gists has also become a valuable part of my workflow. Gists is an awesome tool that is a part of Github that allows you to save small pieces of code as commits in your log, allowing you to build a library over time. The thought of being able to go your own library of useful scripts you’ve used in the past alone is gratifying (and a huge time saver). I have Gists functionality as apackage in my SublimeText editor and I use to save use pieces of code I come across as solutions to development problems.
- Open Source Templates — Over time I began to realize that a lot of my Gists have some similarities with each other, so I started grouping them together and I eventually had the idea of making my own templates. Using Fetch (awesome tool!) saves me a ton of time implementing these templates on the fly by adding them as packages I can download straight from Github into my editor. My first attempt at an open source projects is a collection of existing frameworks and personal snippets that I continually go to for custom development. I shamelessly call it ‘flapjack’ for custom full-stack development (don’t judge me). I also have Fetch installed as apackage for my SublimeText Editor and I highly recommend it.
These are just a few of mine, but of course, any individual developer has his or her own tools or techniques she prefers over the other; this stems from developers who start to form their own methodology of how to tackle a project. However, you’ll come to realize working on teams supersedes your particular preference on tools as you learn to work together.
To wrap things up, get in the habit of collecting and learning from the things that help you build things better. Adopt them as a part of your work habits and you’ll feel (and be) a better developer in no time.