Evaluating Your Rate of Change

Steven Jimenez
Tech Like Us
Published in
4 min readDec 1, 2015
Forbes Image — http://b-i.forbesimg.com/theyec/files/2013/07/fORBES4.jpg

Since I have started my career in the Bay Area, I have been hungry to learn and grow. It can be difficult to not feel the need to “keep up.” It can be especially difficult with the abundance of programming languages to choose from and the new JavaScript frameworks being unleashed into the wild. One way of measuring your progress is to look back at your old work. It’s like reading old college essays, going through diary entries, or even looking back on your past Facebook statuses. It hurts to look, but at the end, you can get a feel for what you have improved on.

Where I Started

In 2014, I was a student with about 2–3 years of experience in programing. Web development was one of my main interests so I started learning some JavaScript. College didn’t require web development classes, so most of my knowledge either came from both the internet and from colleagues. Terminology such as AJAX requests, modules and MVC frameworks were foreign and sounded intimidating.

Going Through Old Work

Realizing how bad my code was…

It wasn’t until recently that I peeked into a small GitHub repository project that dated back to 2014. This project was on my resume, and it was something that I used to show off during interviews. It was a web application that encrypted and decrypted cipher text using the Caesar Cipher. I converted the project to a better looking and up-to-date repository (See links below to view repos). To be specific, I changed my old JavaScript code and beautified it to the new ecmascript syntax, also known as ES6 or ES2015. Also, I created a module using tools such as Browserify and Babel. Going through my old repository was an upsetting experience. While refactoring my code, I noticed the novice patterns and mistakes I made a year ago. How the hell did I think this was good code?

Feeling embarrassed or upset at your old work is okay. If you are satisfied with your old work, then you must have mastered your field, or you aren’t looking to enhance your skills. Growth and progress doesn’t happen overnight. Depending on the type of work, your skills and tools you use may change over time. Failure to adapt to these changes will hurt you. If you keep an open mind and are able to take criticism from others, then new ideas and skills will merge into your current work.

Evaluating Your Current Work

My work is better right? right?

After I looked at my refactored repository I had a feeling of accomplishment. Yes, I was excited about practicing and writing ES6 syntax, but what satisfied me most was acknowledging my growth and the new tools I have learned to use. It is pretty amazing what one can learn in a short amount of time. Within the year I learned concepts and tools such as using package managers, creating modules, bundling code, and learning the best practices. There isn’t any one way to evaluate your work. In Software Engineering one can evaluate work based on the tools used, the quality of the written code or by looking at type of problems that were solved. What is important is noticing a difference or upgrade between works.

Where I am now

It will soon be 2016, and today I continue to have the same hunger and drive that I had in 2014. Terminology that are unfamiliar doesn’t intimidate me, instead if fuels my want to understand. Through my experiences at work, I have realized that architecture, performance and design are important within an application. So my focus has only extended to other areas. There is so much that I want to improve on, but I know that I have to take it one step at a time.

Your Challenge

So I challenge you to search within the directories or repositories you have in whatever code vault you have. It can be an old project stored on your local machine or a repo you pushed up on GitHub. When you do find the perfect candidate, take the time to refactor that code using any language. It doesn’t have to be the same language; you can use a different set of tools. The important thing is to evaluate the differences between the old and newly refactored code. My example is specifically about programming because I am a software engineer, but this practice can be applied to different careers.

--

--