I've been reviewing my progress over the past five years in Barcelona and Focus On Emotions. There's a ton of stuff that I've put into practice since I moved here. Most of this would be a bit overkill for simple projects, but I consider these practices are vital for any project involving more than one developer. All of these techniques were put to practice in personal projects first, and then brought into my regular job as Director of Software Development. Having a team to work together through the issues we found implementing these was really helpful.
What I've learned
Software Configuration Management
We checked every project into Version Control and applied a bunch of SCM related practices. We switched from Subversion to Git in 2011. There were many reasons, easier security handling, speed and Git's decentralized model being some of them.
We still used a golden repo where every other working copy was pushed to at the end of the day, or when we're kicking off an integration. That repo also pushed the changes to Bitbucket via a the Git post-receive hook. We've been using Bitbucket as a collaboration and visualization tool rather than a SCM storage service.
Along the way, we also adopted Semver as the sane guidelines for release versioning. Semver adoption is now almost the de-facto standard, at least for Open Source projects.
We also had a few different strategies to deal with branching. We opted to implement the wildly known git-flow and I doubt I would've ever need anything more complicated
The systems we worked on relied heavily on progressive enhancement. Both on the implementation and on the feature releasing cycle. We used a feature toggling approach for every new feature
For Open Source projects, GitHub is typically used as the SCM storage and collaboration platform.
Software Quality Assurance
Measuring Software Quality in metrics. I'm not talking about code coverage, but about cyclomatic complexity, deep of inheritance tree, object coupling... Most of the metrics were provided by PHP Depend, generated in our build process on Jenkins.
For Open Source projects, Code Climate provides a great service.
I spent my first years as a developer without writing a single test. The commitment to make code clean, understandable and reliable was only fulfilled when we managed to test every project we started. We did unit testing, end-to-end testing on some of the apps that relied heavily on the user interaction and acceptance testing using Behat for BDD.
We did CI on the development and master branches of our apps. We set up a local Jenkins server, using a computer monitor with loudspeakers. The monitor would feature a carousel of wall display lists of the jobs, alternating between the development and the stable branches. Different changes of the build states would trigger different sounds. The quick feedback from the CI system made us be more confident in our code than ever.
Open Source projects usually run their CI in Travis CI
The set of practices meant to easy up and speed the deployment of new versions of our projects.
We switched from manually created VMs in VirtualBox to Vagrant-managed VMs, provisioned by Puppet. Bringing up a new machine to test a new configuration or deploy a different environment for another app took now a couple of minutes, instead of hours (and multiple human errors).
We also wrote deployment automation tools using Apache ant, then moved to Phing then moved to Grunt.
How I learned
Most of this stuff I learned by reading a lot. I've tried to step up my game in these years and I managed to find more sources of knowledge than I could possibly manage.
My primary sources is always the Internet. Sites like Hacker News, Reddit and a carefully curated collection of blogs that I read via Feedly. Twitter is also fantastic, if you follow the active people in your community.
Podcasts are another great way to stay up to date. They're perfect for commuting.
Books are fundamental. No matter how insightful a blog post or podcast might be, they always reference written material. There are a lot of must reads in our field, so I started as early as I could.
Conferences and meetups are perfect for networking, speaking to other developers and share. I've tested the waters myself by giving a couple of talks in the past years and I must say that, even frightening, it's a lot of fun and you get to help out other developers.
Thoughtful, carefully prepared practice of everything you learn is critical. It's just not enough to read and vaguely retain the information. To truly understand, we must apply whatever we're learning.
Tell me and I forget, teach me and I may remember, involve me and I learn.
― Benjamin Franklin
Pet projects are a great way to practice. they work out even better if you collaborate with others. One of the potential pitfalls of pet projects is taking things too seriously. Remember, you're learning, getting better at something specific. The goal isn't for your pet project to be popular, grow into a company and get bought by Google. You're just learning, take it easy. Usually, it doesn't even matter if your pet project sees the light and gets released into the public. Keep in mind though that having a long list of unfinished ideas can be demoralizing. In time, I learned to downsize the complexity of my ideas and only released small things that I was ok with.
Put yourself in the position of the rest of your team. Try to think like they think, to understand their problems and help them.
I've always liked to know as much as possible about the platform running my software. When I started as a freelance software developer, my websites and webapps where running in a shared hosting environment. The amount of problems and frustration made me realize how hard it is to be a good Systems Administrator. I moved all my clients into VMs. This meant I was now doing Systems Administration too, but it provided me with a ton of learning experiences.
The same goes for frontend development, mobile, etc...
What I still have to learn
I've never had the opportunity to work in a project when I could release as often as we made changes. I'm looking forward to doing so.
It's easier said than done. TDD requires a certain level of work stability, self-discipline and focus I've just never been able to find. I'm making an effort to change this.
Such a huge topic. Digging into DDD feels like going down the rabbit hole. This paradigm could very well be as big as the Agile methodologies have been.
Even though we worked in a few Mobile projects, all of them where part of the Digital Signage platform we built. I'd love to work on a project where the mobile client is the main focus.
None of the projects I've worked have reached the numbers that high traffic systems support nowadays. Millions of daily active users. That's a whole new level, and I want to reach that.