It’s been a long while again, with many life changes and some career maturity added since my last post. You can thank my friend ctmartin for this one coming to fruition. This post will be a bit less technical, and more about some of the knowledge I’ve accumulated since our last interaction. Some following posts may go into more depth about these subjects, so stay tuned.
Since my last post, I’ve been thrown into the wonderful world of automation. My tools of choice have been Terraform and Ansible. I’ve used Terraform for provisioning AWS and Vultr resources for projects. Ansible, I’ve used to install web services on VPS instances and deploy websites. Once I got past the initial learning curve for both, they’ve saved me quite a bit of time managing environments for development and production deployments of a few websites. I set up an Ansible playbook to replicate my local work environment. The repository for that can be found at desnudopenguino/work-environment-ansible. I have also used these tools to manage the deployments of one of my projects, Yet Another Crypto Faucet Rotator. If you haven’t had any experience with Ansible, Terraform, or any other DevOps automation tools, I highly suggest you look into them.
I mentioned the wonderous service called AWS above. Over the past several months, I had the opportunity to work with many of the services offered by AWS including EC2, RDS, DynamoDB, Lambda, Route53, and S3 to optimise a system for a client. Some of their services are extremely useful, even if you aren’t running your base web presence through them. Also some of their services have a free tier which you can use up to a point, which works well for smaller dev deployments or tests of how a service could interact with your already existing infrastructure.
And now onto the meat and potatoes of this post, my experiences refactoring and adding to already existing projects. Over the past four years, I’ve been a freelance web developer working with local businesses to improve the functionality of their websites. In the beginning, I was a starry-eyed developer ready to carve my own masterpiece out of the digital landscape. Then I landed a gig picking up where someone else abruptly left off, and the fun really began. I started the project with the end goal of refactoring the current code into a more succinct, and manageable codebase, but as new features were requested, and budgets came into play, that fell by the wayside. I did manage to clean up about 3/4 of the original code, but I’m not entirely sure if that makes it better or worse than it was when I started. From the outside, the site works much better, but if someone else has to come in and edit anything in the codebase, it will be a bit more challenging.
Fast forward to about a year and a half ago. I picked up another client with the same issue. Their developer was leaving fast, and they needed someone to continue development. This one was much more interesting, because the original developer chose some very interesting methods to solve some of the problems they encountered. I jumped into the code and sank the website a few times during development, but through it all, I was able to keep things running. Along with a technological visionary pushing me into some uncharted water, we were able to develop some very cool solutions to the issues we faced.
Through these two projects, I have grown exponentially as a developer, and had the opportunity to work with some really awesome people. Below are a few useful things I’ve learned.
- Sometimes keeping the same flow, even if it isn’t optimal or what you are used to, isn’t a bad thing. As developers we are continually evaluating our work and refactoring it. We have to be mindful of what the past developer(s) were thinking and doing when they wrote their code. We must also keep in mind that someday in the future, someone else may inherit the code that we and our predecessors have written. Keep it simple!
- There is, however, the other side of this coin, which is that when a refactoring project like this is finally complete, life should be better for all parties involved. Bad design decisions perpetuate themselves until they are removed from the code. Bite off small chunks at a time if resources allow it. Johnny Cash’s “One Piece At A Time” comes to mind here.
- I think this one goes without saying, but NEVER STOP LEARNING! As programmers, we have an enormous buffet of tools at our finger tips to attack any problem from any direction. Don’t be afraid to step out into the unknown and pick up something you swore you’d never touch, or that you don’t feel comfortable with. We can become so specialized with our tool that we become inflexible to the demands of the ever-changing world of programming. Likewise, don’t let the breadth of your knowledge hamper your depth. It can be just as easy to have superficial knowledge of a ton of tools, but not truly understand how any of them work to achieve the goals you have. What I’m trying to say here is find a balance between sharpening your already existing skills and learning new ones.
I enjoy life as a freelance developer, and wouldn’t trade it, the experiences, or the people I’ve met, for anything. It’s not always easy, but it is good.