Always be shipping
Like a compelling headline or a purposeful user path, there’s nothing quite as satisfying as a well-written line of code. In digital, we all struggle with “good enough”– for the perfectionist copywriter, designer, or developer, when is something “done” and ready to ship off to production? With time and experience, we all figure out exactly when to close our documents and browser windows, let go, and get our work out there.
Release, revisit, revise
Letting go doesn’t always mean moving on. Taking the time to revisit old work is what separates those of us who have passion for our craft from those for whom it’s just a job.
For developers, looking back at old code shows progression in our ability to learn, apply new things, and break things down. Revisiting your own code — or even someone else’s– that may have worked flawlessly at the time can breathe fresh life into an established platform, integration, or system.
More flexibility, less risk
As developers, we want to know that when we make changes, it’s not going to break down the bigger picture. Sometimes, when we take a step back and look at an old project with brighter, more seasoned eyes, we can find new ways to approach a problem.
Recently here at Envisionit, we handled an integration with a client’s app and a customer relationship management system that hadn’t been modified since 2015. The integration was working smoothly, but a new set of requests for additional functionality came through and began to complicate the whole picture.
This integration updates a CRM record whenever it’s modified within our client’s app. Anytime we’d update a CRM record, we were forced to send over the entire set of data rather than only the data that had been changed.
Then, a new requirement came through to update a date field in the CRM after a certain event occurred in the app for 2 out 3 record types, and the value to be updated was only readily available after the event. Different record types now needed to have different values sent, and this forced us to have many unnecessary conditionals to support all record types.
Our solution was to use the CRM’s other API and update fields as needed. Now we can handle additional feature requests much more easily, we have fewer conditionals, code is readable, and it’s much easier to test.
The result is that the integration is more flexible, and deploying new changes is increasingly less risky.
A delicate balance between speed and quality
Being humble, focusing on the final outcome, always striving to do better, and not taking our work too personally are all things that drive us here at Envisionit. And While creatives and the account team are the ones on the front line, this runs even deeper for our developers.
For one of our clients, we’d initially built a small frontend app using an old Javascript framework. While it served its purpose, it was becoming increasingly more difficult to add new features. So, our solution was to completely rebuild it in a new Javascript framework. This not only allowed us to apply our knowledge gained over the past few years, but it made things easier for us and our clients as well. Even after building in the new framework, there could be improvements–and as we become more efficient, our software becomes so, and provides even more value to our users.
Finding ways to look at old code from a new perspective
While we don’t pretend to know everything, we do have the ability and the drive to learn something new every day. So how do Envisionit developers stay on their toes and keep from getting rusty?
There are certain tried-and-true sources that are my go-tos and help me stay sharp. Attending conferences is a great motivator, and one of the best ways to expose yourself to new ideas– I always learn new things when I spend time with different types of people with various professional backgrounds. I also use feed.ly to aggregate all of my favorite blogs into one programming feed, and I attend local dev meetups to meet peers and stay up-to-date on what’s going on in the dev world.
Being in a state of constant learning, staying humble, and being open to new ideas will not only benefit your own code, but the code of your coworkers and clients–ultimately to the benefit of your end user.
