This 3-part series on Developer Growth focuses on how we can continue to grow as developers and why we should strive to get better every single day.
As developers, we might get to a point in our careers where we start to stagnate. We know our main language(s) pretty well, we have a job we are satisfied with and we enjoy our day to day coding. We tend to forget what it took for us to get to where we are today, and fail to realize that there is more ahead of us.
Part 1 - Write code every day
We've all heard the famous saying "You are not an expert until you have achieved 10,000 hours of work in your chosen profession". Maybe not in those exact words but you get the gist. It's easy to simply go to work every day and write some code, fix some bugs and pump out some features. Unfortunately, that is not a recipe for success in our field.
Here are 4 reasons why you should write code every day.
1. Using side projects to become a better developer
I've been fortunate enough, throughout the various stops in my career to have been able to work with various languages, tools and technologies. Some, I've learned on the job, others, I had to show that I had at least a beginner level of understanding to be able to secure the position.
There is a direct correlation between doing side projects and landing the job that you want. If you want to be a Rails developer, you need to at least know some Ruby and have played around with the Rails framework. You want to develop iOS apps? Bust out xCode and Cocoa and get to hacking because no one will hire you with no experience at all.
This experience is gained on your personal time via side-projects. Work is a playground to a certain extent. You have to work within the guidelines / technology stack used by your company. In your own work though, you are free to test out any language or tool as you please, be it the best choice or not for the job. Anything goes for the sake of learning.
2. Exercise your developer reflexes
Becoming a better developer is done through repetition. How many times have we built authentication systems? How many times, as a Rails dev, have we encountered errors running "bundle install"? How many times have we ran into incompatibilities trying to install a package on a *nix box? How many times, writing PHP, have we forgotten which argument occupies which position for any given command?
When we first start as developers, we tend to have Google, search Stack Overflow as well as various guides and resources open at all times. As we continue to perform the same tasks and write the same kind of code over and over again, we end up relying on those external resources a lot less. Of course we will need to refer to them at some point (or else we are no longer learning) but certain things will have become second nature.
Another side effect of writing code almost on a daily basis is that you typically end up knowing what the best tool for the job is. You've played with various scripting and web languages, have pulled out your hair and experienced enough blank stares that when faced with a similar project / feature / bug, you will know how to handle it. You'll have gained experience by doing it the hard way.
3. Move toward being a full-stack developer
Some may think that the concept of a "Full-Stack Developer" is a myth. I believe that to be incorrect. Being able to hack in both the backend and the front-end is an invaluable skill to have. As you grow as a developer, you need to start thinking outside of your little backend/front-end bubble. How does your code interact with the other side? What can you do to make things easier? Reusable? Streamlined? Efficient? Where should this data processing happen? Front-end? Backend?
The only way you will know that is by experiencing it on your own. Sure, you can pick up some front-end tickets/stories at work and slowly make your way up the chain but how will you know your code is production-ready? The vast majority of the time, you're not being paid to learn a new language, you're being paid to crank out some beautiful, efficient, well-thought out code.
On your own time, you can experience all you want and eventually apply that to your actual job. Not only will you make your own life easier, you'll help out your colleagues and your company as well. Front-end guys are being overloaded with work? Jump in and give them a hand. Back-end features are piling up? Help out with some of the smaller tasks: database schema design, cron jobs, small scripts, etc... In the end, everyone wins - and most importantly, you do.
4. Do the DevOps thing
As a developer, you should have an idea of what happens to your code after you commit it. Even if you have no interest in server automation and central logging systems and monitoring, you should know how your code affects the server as well as how the server affects your code.
Imagine you're facing a bug relating to a slow query. Some might automatically think to start modifying the initial query until it performs the way they want it to. But what happens when it's due to a MySQL configuration? What happens when you need to structure your code / queries knowing that there is replication done in the background? You need to push some items to a queue system but you're not getting the advertised "operations/sec" value. What then?
Having at least some knowledge of how an application works from a code / server setup / technology setup aspect is very important. Not only will you save yourself some time debugging issues (let's face it, they come up every single day), you'll be able to clean up with your developer tool-belt. Knowing tool A does not play well with tool B when you need to achieve feature X will save you tons of hours and help you keep a few more hairs on your head.
Conclusion
In essence, write code every day, you will pat yourself on the back for it eventually. By no means do you need to put in a full day of work after you've gone home. Spend however much time you can afford but try and make a conscious effort to work on side projects with the goal of hitting roadblocks, learning through failure and eventually coming out a stronger and better developer.
Part 2 next month will be about blogging and contributing to open source and why that's important to our professional growth.
About the Author
Follow on Twitter More Content by Luckner Jr Jean-Baptiste
