The Beginning of the End

Early in my career a coworker of mine told me, "Nobody likes to have their baby called ugly." I never really understood what that meant until I was working for a large company and the product that I was working on was set to be sunset. It was being replaced with a new product, which of course, out of spite I hated. I felt like all of the hours, the years even, that I worked on this product were wasted. The beautiful app I had created was no longer going to serve a purpose. It was on software death-row and I was upset about it to say the least.

Change is Constant

During this whole process of the product that I was working on being sunset I had the VP of Engineering pulled me aside and had a very profound conversation with me. He gave me a short piece of advice that I think changed my life, he said "Only one thing is ever certain, change is constant." Let's think about that for a second. It is a 100% true statement. No matter where we are in our careers, what we build, what we work on, we can always be certain that something will change. Whether it is upgrading a piece of software, or changing libraries for some arbitrary thing your app does, change is constant. Bugs will be found and need to be solved. New customer requests will come in and need to be produced as a feature. New products come along that might be that one step ahead of yours that mattered, and all of these things evoke a change in something that impacts how you work.

Changing Languages: Ruby to JS

During this process I went from a Ruby on Rails dev with about 5 years of experience to being a JS dev with maybe 1 year of experience with slightly questionable relevance. When the idea of this first hit me, I was scared and concerned. I am dropping down the totem pole by going to this new language. I am not going to know what I am doing. My career is going to suffer because of this "change" (pun intended).

Well, I was completely wrong. At the core of what we do as developers, engineers, programmers, whatever noun you want to use, we figure shit out. We are paid solid sums of money to figure problems out. Those problems to not end behind the keyboard. We have complex problems to solve outside of the software itself.

The way to change languages with the most finesse is to fully immerse yourself in it. Use the technique which allows you to learn the best. If you are an audible learner, listen to a podcast. If you are a visual learner, pick up some courses that are on sale at Udemy. If you learn by reading, grab a book. If you are a person that learns by doing, do some combination of the three, get behind that keyboard and start pounding out that code.

Syntax is merely a tool that allows us to express and utilize that big engineering brain that we have. If you are a talented engineer the syntax should not stop you from writing elegant and effective code, it should only impact the velocity at which you write it. That velocity can also be aided in the action of fully committing to the language. Over a period of time that will likely be much shorter than you think, that syntax will become second nature and you will thrive just like you did before. As far as a timeline, I would say typically within 30 - 90 days, you should be able to write some decent code. At 6 months some pretty great code, and at 1 year you will most likely be at the point where you were in your previous language. Mileage and time may vary from person to person, but I think those time ranges are a decent indication.

As a rule of thumb, unless moving to some archaic dead language, embrace the move. At the very least it is another thing you can put on your resumé and a notch in your belt of experience. While the transition will be a little bit bumpy, you will come out of it a better person and engineer.

Strategies for Accepting Change

Be Optimistic

Rather than focusing on the negative nature of the change,I was super guilty of this at first, accept the new adventure and chance to learn. Every change will run through its course and typically end up making you a better person/engineer.

Be Humble

When coming into anything new, remain humble and take the learn first approach. Use all of the resources you can gather to help you with the transitions. This includes any learning materials, courses, groups, coworkers or friends. Odds are that if you are an engineer with some time under your belt and have willingness to meet others, you will know someone that has delved into your new things. Utilize those things as tools to help you transition and lower the learning curve ahead.

Be Confident

Take the change head on. Be confident in your abilities as an engineer and put a new skill to the test. The ability to adapt is one of the most important skills an engineer can have. Managers and their superiors look greatly into this trait, and it is one of the key things that they look for when determining whether you're ready to go into your next level of engineering or maybe even into management.

Conclusion

Change exists in every aspect of our lives. It is how we adapt that makes us great and notable. The act of adapting makes us stronger. If you can, comment below on any changes whether in respect to changing language or something else at work has affected you please do.